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

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.

• Traffic aus VLAN/Netz A soll über ISP2 statt ISP1
• Bestimmte Anwendungen sollen immer durch ein VPN/Tunnel
• Gäste-/IoT-Traffic soll über eine separate Security-Zone laufen
• Migrationen: temporäre Umleitung ohne Routing-Design umzubauen

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.

• match: Welche Pakete sind betroffen? (ACL, DSCP, Länge, …)
• set: Wohin sollen sie? (Next-Hop, Interface, VRF, …)
• apply: Wo wirkt es? (Policy wird am Interface inbound gebunden)

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.

• VLAN10: 192.168.10.0/24 (PBR: ISP2)
• Rest: Standardrouting (Default Route via ISP1: 203.0.113.1)
• PBR-Apply: am VLAN10-Gateway Interface inbound

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.

• Policy am falschen Interface angewendet (muss inbound am Traffic-Eingang sein)
• ACL matcht zu viel (z. B. auch VPN-/Management-Traffic)
• Asymmetrischer Rückweg über anderen Uplink (Stateful Firewalls brechen Sessions)
• NAT passt nicht zum gewählten Uplink (PAT zeigt auf falsches WAN-Interface)
• Next-Hop ist nicht erreichbar (kein ARP/keine Route im Transit)

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.

• Policies so eng wie möglich matchen (nur benötigte Quellen/Ports)
• Management- und VPN-Traffic explizit ausnehmen (separate ACL-Einträge)
• Rückweg/Stateful Devices berücksichtigen (Symmetrie planen)
• Counter-basierte Verifikation nach jedem Change
• Fallback definieren (mehrere Next-Hops oder Standardrouting als Plan B)

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

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

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.