Site icon bintorosoft.com

Policy-Based Routing (PBR) auf Cisco: Traffic gezielt steuern

Red Snapper

Cloud computing devices

Policy-Based Routing (PBR) erlaubt es dir, Traffic nicht nur anhand der Routing-Tabelle (Longest Prefix Match) zu leiten, sondern gezielt nach Regeln wie Quellnetz, Ziel, Protokoll oder Ports. Das ist besonders nützlich, wenn bestimmte Anwendungen über einen anderen Uplink, ein VPN oder eine spezielle Firewall-Zone laufen sollen. Dieses Tutorial zeigt ein praxistaugliches Beispiel und erklärt, wie du PBR sauber konfigurierst und verifizierst.

Was ist PBR – und wann ist es sinnvoll?

Normalerweise entscheidet der Router anhand der Routing-Tabelle, wohin ein Paket geht. PBR setzt davor an: Pakete, die eine Policy matchen, erhalten einen abweichenden Next-Hop oder ein bestimmtes Ausgangsinterface.

Wichtige Einschränkung

PBR ist kein Ersatz für sauberes Routing-Design. Es ist eine Policy-Schicht für Sonderfälle und sollte dokumentiert und sparsam eingesetzt werden.

Grundprinzip: Match + Set + Apply

PBR besteht aus drei Bausteinen: Du definierst, welcher Traffic gematcht wird, was mit diesem Traffic passieren soll, und auf welchem Interface die Policy wirkt.

Praxisbeispiel: VLAN10 über ISP2, alles andere über ISP1

Beispiel-Design: Der Router hat zwei Uplinks. Standardmäßig geht alles über ISP1 (Default Route). Nur Clients aus VLAN10 (192.168.10.0/24) sollen über ISP2 (198.51.100.1) ins Internet.

Vorbereitung: Default Route (Standardweg über ISP1)

R1# configure terminal
R1(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1
R1(config)# end

Schritt 1: Traffic definieren (ACL für VLAN10)

Mit einer ACL beschreibst du, welchen Traffic PBR beeinflussen soll. Typisch ist eine Quellnetz-ACL. Achte darauf, dass die ACL nur den gewünschten Traffic matcht.

R1# configure terminal
R1(config)# ip access-list extended PBR_VLAN10
R1(config-ext-nacl)# permit ip 192.168.10.0 0.0.0.255 any
R1(config-ext-nacl)# end

Schritt 2: Route-Map erstellen (match + set)

Die Route-Map verknüpft Match und Aktion. Im Beispiel setzt du den Next-Hop auf ISP2. Best Practice ist, zusätzlich eine Fallback-Logik zu definieren.

Route-Map mit set next-hop

R1# configure terminal
R1(config)# route-map PBR-IN permit 10
R1(config-route-map)# match ip address PBR_VLAN10
R1(config-route-map)# set ip next-hop 198.51.100.1
R1(config-route-map)# end

Optional: Fallback-Next-Hop (wenn primär nicht erreichbar)

Mit mehreren Next-Hops kann der Router im Idealfall eine Alternative nutzen. In vielen Designs bleibt zusätzlich Standardrouting als „Plan B“ sinnvoll.

R1# configure terminal
R1(config)# route-map PBR-IN permit 10
R1(config-route-map)# set ip next-hop 198.51.100.1 203.0.113.1
R1(config-route-map)# end

Schritt 3: PBR am Interface binden (inbound)

PBR wirkt typischerweise inbound am Interface, an dem der zu steuernde Traffic in den Router hineinläuft – z. B. am VLAN10-Gateway (SVI/Subinterface/Interface).

Apply auf VLAN10-Subinterface (Router-on-a-Stick)

R1# configure terminal
R1(config)# interface gigabitEthernet0/1.10
R1(config-subif)# ip policy route-map PBR-IN
R1(config-subif)# end

Apply auf L3-Interface/SVI (falls Gateway dort liegt)

R1# configure terminal
R1(config)# interface vlan 10
R1(config-if)# ip policy route-map PBR-IN
R1(config-if)# end

Verifikation: Funktioniert PBR wirklich?

Bei PBR ist Verifikation entscheidend: Du willst sehen, ob ACL/Route-Map matcht und ob der Traffic tatsächlich den erwarteten Next-Hop nutzt. Nutze Counters, Traceroute und CEF-Checks.

Route-Map und Match-Counters prüfen

R1# show route-map
R1# show access-lists PBR_VLAN10
R1# show running-config interface gigabitEthernet0/1.10 | include ip policy

Pfad prüfen (aus VLAN10 heraus)

Teste aus einem Client in VLAN10 mit Traceroute. Alternativ nutzt du am Router eine Source-IP aus VLAN10 (falls sinnvoll).

R1# traceroute 8.8.8.8 source 192.168.10.1
R1# ping 8.8.8.8 source 192.168.10.1

Policy-Status auf dem Interface prüfen

R1# show ip policy
R1# show ip interface gigabitEthernet0/1.10

Typische Stolperfallen bei PBR

PBR ist mächtig, aber fehleranfällig, wenn Match-Bedingungen zu breit sind oder wenn NAT/Return-Path nicht bedacht wird. Viele Probleme wirken wie „Internet kaputt“, sind aber asymmetrische Pfade.

Quick-Checks bei Problemen

R1# show ip interface brief
R1# show ip route | include 0.0.0.0
R1# show arp | include 198.51.100.1
R1# show route-map
R1# show access-lists PBR_VLAN10

PBR und NAT: das Zusammenspiel sauber planen

Wenn du Internet-Traffic über unterschiedliche Uplinks leitest, muss NAT konsistent sein. Typisch ist, NAT-Regeln pro Uplink zu definieren oder die NAT-Policy so zu gestalten, dass sie zur aktiven egress-Schnittstelle passt.

NAT-Status prüfen (Pflicht nach PBR-Änderungen)

R1# show ip nat statistics
R1# show ip nat translations

Best Practices: PBR betriebssicher einsetzen

Mit klaren Regeln und guter Dokumentation bleibt PBR wartbar. Ziel ist, Sonderwege kontrolliert zu steuern, ohne das gesamte Routing unübersichtlich zu machen.

Konfiguration speichern

Wenn Tests erfolgreich sind, speichere die Konfiguration, damit die PBR-Policy nach einem Neustart erhalten bleibt.

R1# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

Sie erhalten

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.

Exit mobile version