Policy-Based Routing (PBR) konfigurieren: Cisco Use Cases

Wer in Cisco-Netzwerken Routing betreibt, kennt das Standardprinzip: Der Router entscheidet anhand der Routingtabelle (Longest Prefix Match), wohin ein Paket als Nächstes gesendet wird. In der Praxis gibt es jedoch Szenarien, in denen diese „klassische“ Pfadwahl nicht ausreicht – etwa wenn bestimmter Traffic über einen anderen Uplink laufen soll, wenn ein Gastnetz grundsätzlich über eine separate Security-Kette gehen muss oder wenn Cloud-Traffic lokal ins Internet ausbrechen soll, während Unternehmensanwendungen über MPLS bleiben. Genau dafür ist Policy-Based Routing (PBR) konfigurieren gedacht. PBR erlaubt es, die Weiterleitung von Paketen anhand von Regeln (Policies) zu beeinflussen – typischerweise basierend auf Quelle, Ziel, Protokoll, Ports oder Markierungen wie DSCP. Cisco setzt PBR üblicherweise mit Route-Maps um, die über ACLs oder Match-Kriterien Traffic klassifizieren und anschließend per „set“-Aktionen den Next Hop oder das Ausgangsinterface bestimmen. Wichtig ist: PBR ist ein mächtiges Werkzeug, aber es kann auch schnell zu schwer nachvollziehbaren Pfaden, asymmetrischem Routing oder Security-Problemen führen, wenn es ohne klare Use Cases, saubere Filter und konsequente Verifikation eingesetzt wird. Dieser Leitfaden erklärt die Grundlagen, zeigt typische Cisco Use Cases und liefert praxistaugliche Beispielkonfigurationen inklusive Troubleshooting, damit PBR stabil, wartbar und sicher im Alltag funktioniert.

Was ist Policy-Based Routing und wie unterscheidet es sich vom normalen Routing?

Beim normalen Routing entscheidet der Router anhand der Routingtabelle. PBR greift an einem früheren Punkt ein: Es prüft – abhängig von der Plattform und dem Datenpfad – Pakete auf einem Interface (meist ingress) und kann den Weiterleitungsentscheid überschreiben. Dadurch können Sie „verkehrsabhängiges Routing“ realisieren, ohne die globale Routingtabelle zu verändern.

• Standardrouting: Zielnetz bestimmt den Pfad (Routingtabelle).
• PBR: Policy bestimmt den Pfad (Route-Map + Match/Set).
• Einsatzgebiet: Sonderfälle und Ausnahmen, nicht „alles überall“.
• Risiko: Komplexität, asymmetrische Pfade, schwierigeres Troubleshooting.

Eine gute Cisco-Orientierung zu PBR liefert der Anchor-Text Cisco Policy-Based Routing (PBR) Grundlagen. Für Route-Maps als zentrales Werkzeug sind Befehlsreferenzen über den Anchor-Text Cisco IOS XE PBR Konfigurationsguide hilfreich.

Typische Cisco Use Cases für PBR im Enterprise

PBR ist dann sinnvoll, wenn Sie eine klare Regel haben, die sich nicht elegant über Routingprotokolle, VRFs oder reine Default-Route-Strategien abbilden lässt. Die folgenden Use Cases sind im Alltag besonders häufig.

• Dual-WAN/Multihoming ohne BGP: Bestimmte Quellnetze sollen über ISP A, andere über ISP B.
• Guest VLAN vs. Corporate: Gasttraffic wird immer über eine separate Firewall/DMZ-Kette geroutet.
• Cloud Breakout: Microsoft 365/Cloud-Dienste sollen lokal ins Internet, interne Apps über MPLS/WAN.
• WAN-Optimierung: Bestimmte Anwendungen (z. B. Backup) über einen günstigeren Link, Echtzeitverkehr über den besseren.
• Security Inspection: Verdächtiger Traffic wird zu einem IDS/IPS oder Proxy gelenkt (falls architektonisch sinnvoll).
• Lastverteilung nach Policy: Nicht „per Flow Hash“ wie EtherChannel, sondern nach definierten Kriterien.

Grundbausteine: ACL, Route-Map und Policy auf dem Interface

Die typische Cisco-PBR-Implementierung besteht aus drei Teilen:

• Traffic matchen: meist über eine ACL (Quelle/Ziel/Protokoll/Ports) oder erweiterte Match-Optionen.
• Aktion definieren: über eine Route-Map mit set (z. B. Next Hop setzen).
• Policy anwenden: Route-Map wird auf einem Interface angewendet (klassisch ingress) – je nach Plattform mit ip policy route-map.

Warum Reihenfolge in Route-Maps entscheidend ist

Route-Maps werden sequenziell ausgewertet. Der erste passende Eintrag entscheidet. Deshalb ist es Best Practice, zuerst sehr spezifische Regeln zu definieren, danach allgemeinere, und am Ende eine „permit“-Regel, die den Rest entweder unberührt lässt (kein set) oder bewusst behandelt.

Schritt-für-Schritt: PBR-Grundkonfiguration mit „set ip next-hop“

Ein klassisches Beispiel: Clients aus dem Netz 192.168.10.0/24 sollen ins Internet über ISP-A (Next Hop 203.0.113.1). Alle anderen Netze nutzen das normale Routing.

Schritt 1: ACL für den zu steuernden Traffic

configure terminal
ip access-list extended PBR-SRC-CLIENTS
permit ip 192.168.10.0 0.0.0.255 any
end

Schritt 2: Route-Map erstellen

configure terminal
route-map RM-PBR-ISP-A permit 10
match ip address PBR-SRC-CLIENTS
set ip next-hop 203.0.113.1
route-map RM-PBR-ISP-A permit 100
end

Der zweite Eintrag (permit 100) dient als „Durchlass“ für alle übrigen Pakete: Kein Match und kein Set bedeutet, dass normales Routing greift.

Schritt 3: Policy auf dem Ingress-Interface aktivieren

Beispiel: Die Clients kommen auf GigabitEthernet0/1 rein.

configure terminal
interface gigabitethernet0/1
ip policy route-map RM-PBR-ISP-A
end

Wichtiger Praxispunkt: Return Path und asymmetrisches Routing

PBR entscheidet meist nur über die Richtung „hinaus“. Wenn Antworten über einen anderen Pfad zurückkommen, kann das Probleme verursachen – besonders bei stateful Firewalls, NAT oder Session-basierten Policies. Deshalb gilt:

• Rückwege planen: Der Rückweg muss plausibel und konsistent sein (Routing, NAT, Firewall-States).
• NAT beachten: Bei Internetzugang hängt die Nutzbarkeit stark davon ab, wo NAT stattfindet.
• Stateful Geräte: Wenn Hinweg über Firewall A, Rückweg über Firewall B läuft, brechen Sessions häufig.

Best Practice: PBR bevorzugt dort einsetzen, wo Sie den gesamten Pfad kontrollieren oder wo Rückwege durch Design ohnehin stabil sind (z. B. zentraler Egress).

Use Case: Dual-WAN nach Quellnetz (ISP-A für Corporate, ISP-B für Guest)

Ein häufiger Enterprise-Use-Case ist die Trennung von Corporate- und Guest-Traffic. Corporate soll über den hochwertigen Link (ISP-A), Guest über den günstigeren Link (ISP-B). Beispiel:

• Corporate VLAN: 10.10.10.0/24 → Next Hop ISP-A 203.0.113.1
• Guest VLAN: 10.20.20.0/24 → Next Hop ISP-B 198.51.100.1

ACLs

configure terminal
ip access-list extended PBR-CORP
permit ip 10.10.10.0 0.0.0.255 any
ip access-list extended PBR-GUEST
permit ip 10.20.20.0 0.0.0.255 any
end

Route-Map mit Reihenfolge

configure terminal
route-map RM-PBR-DUALWAN permit 10
match ip address PBR-CORP
set ip next-hop 203.0.113.1
route-map RM-PBR-DUALWAN permit 20
match ip address PBR-GUEST
set ip next-hop 198.51.100.1
route-map RM-PBR-DUALWAN permit 100
end

Policy anwenden

Wenn beide VLANs am gleichen Ingress-Interface (z. B. SVIs auf einem L3-Switch) ankommen, setzen Sie die Policy dort, wo der Traffic ingress verarbeitet wird (plattform- und designabhängig). Beispiel für ein SVI:

configure terminal
interface vlan 10
ip policy route-map RM-PBR-DUALWAN
interface vlan 20
ip policy route-map RM-PBR-DUALWAN
end

Wichtig: Ob Sie die gleiche Route-Map auf mehreren Interfaces nutzen oder getrennte Policies erstellen, ist eine Designentscheidung. Häufig ist eine zentrale Route-Map mit klaren Sequenzen wartbarer.

Use Case: Cloud Breakout nach Ziel oder Anwendung

Ein typisches modernes Szenario: Bestimmte Cloud-Ziele sollen lokal ins Internet (Direct Internet Access), während interne Applikationen über ein zentrales WAN gehen. In der Praxis ist die reine Ziel-IP-Filterung schwierig, weil Cloud-IP-Ranges dynamisch sind. Dennoch kann PBR in zwei Fällen sinnvoll sein:

• Statische Zielmengen: Wenn Ziele stabil sind (z. B. definierte Partnernetze, feste SaaS-Endpunkte).
• Markierungsbasierte Steuerung: Wenn ein vorgelagertes System Traffic markiert (z. B. DSCP) und PBR darauf reagiert.

PBR auf DSCP-Basis (konzeptionelles Beispiel)

Wenn Ihre Umgebung DSCP markiert (z. B. Cloud-Verkehr bekommt DSCP AF11), können Sie das matchen und anders routen. Die genauen Match-Optionen sind plattformabhängig, aber das Prinzip lautet: „Markierung matchen, Next Hop setzen, Rest normal routen“. Für DSCP/ToS-Hintergrund eignet sich der Anchor-Text RFC 2474 (DiffServ).

PBR mit Fallback: Next Hop nur setzen, wenn er erreichbar ist

Ein häufiger Wunsch im Enterprise: „Route diesen Traffic über Next Hop A, aber wenn A down ist, nimm B oder Standardrouting.“ Dafür gibt es auf vielen Cisco-Plattformen Mechanismen wie „set ip next-hop verify-availability“ oder Tracking/Objektverfolgung, je nach IOS/IOS XE-Featureumfang. Das Grundprinzip bleibt:

• Primär-Nexthop: bevorzugt
• Fallback: nur wenn primär nicht erreichbar
• Monitoring: Tracking/IP SLA o. Ä. entscheidet über Verfügbarkeit

Dieser Ansatz ist deutlich robuster als starres PBR, weil er bei Ausfällen nicht in einen „Blackhole“-Zustand läuft. Prüfen Sie dazu die plattformspezifischen Optionen im Anchor-Text Cisco IOS XE PBR Konfigurationsguide, da Syntax und Verfügbarkeit je nach Version variieren können.

Verifikation: So prüfen Sie, ob PBR tatsächlich greift

PBR ist nur dann sinnvoll, wenn Sie sicher verifizieren können, dass die Policy greift. Im Betrieb sind diese Checks besonders hilfreich:

• show route-map (Match-Zähler: werden Sequenzen getroffen?)
• show access-lists oder show ip access-lists (ACL-Hits: passt die Klassifizierung?)
• show running-config interface <IF> (Policy korrekt auf Interface angewendet?)
• show ip policy (plattformabhängig: zeigt angewendete Policies)
• traceroute von einem Testclient (zeigt Pfad und Exit)

Praxis-Tipp: Die Zähler in Route-Maps und ACLs sind oft der schnellste Realitätscheck. Wenn die Zähler nicht steigen, matcht Ihre Regel nicht – häufig wegen falscher Wildcards, falscher Reihenfolge oder weil das falsche Ingress-Interface gewählt wurde.

Häufige Fehler und Fixes beim PBR-Setup

Viele PBR-Probleme folgen wiederkehrenden Mustern. Wenn Sie diese kennen, sparen Sie viel Zeit.

Policy greift nicht

• Falsches Interface: PBR wird auf dem falschen Ingress-Interface angewendet.
• ACL matcht nicht: Quelle/Ziel/Ports falsch oder Wildcard-Fehler.
• Route-Map Reihenfolge: Ein früheres „permit“ matcht bereits und „verschluckt“ den Traffic.

Fix: Zähler prüfen (show route-map, show ip access-lists), dann Interface-Placement korrigieren.

Traffic wird umgeleitet, aber Verbindungen brechen

• Asymmetrisches Routing: Rückweg kommt über eine andere Security-Kette.
• NAT/Firewall-State: NAT findet am falschen Punkt statt oder State passt nicht zum Rückweg.

Fix: Pfaddesign prüfen, NAT/Firewall-Placement klären, ggf. PBR nur auf bestimmte Flows begrenzen oder Rückwege anpassen.

Blackholing bei Next-Hop-Ausfall

• Statischer Next Hop: PBR setzt einen Next Hop, der nicht erreichbar ist.

Fix: Fallback-Mechanismen nutzen (Tracking/Verify-Availability) oder Policy so gestalten, dass bei Nichterreichbarkeit Standardrouting greift.

Zu breite Regeln führen zu unerwarteter Pfadwahl

• „permit ip any any“ in ACL oder zu breite Prefix-Listen
• Policy drift: Nach Änderungen matcht plötzlich mehr Traffic als gedacht

Fix: Regeln minimal halten, Use Case dokumentieren, regelmäßig Zähler und Pfade überprüfen.

Best Practices: PBR sicher und wartbar einsetzen

• Nur klare Use Cases: PBR ist für Ausnahmen und Policies, nicht als Ersatz für sauberes Routingdesign.
• So restriktiv wie möglich matchen: Nur die benötigten Quellen/Ziele/Ports.
• Reihenfolge dokumentieren: Route-Map Sequenzen mit nachvollziehbarer Logik.
• Fallback planen: Next-Hop-Ausfälle dürfen nicht zu Blackholes führen.
• Asymmetrie vermeiden: Pfade in beide Richtungen berücksichtigen, besonders mit stateful Firewalls.
• Monitoring: Route-Map/ACL-Hits, Linkstatus und Pfadtests regelmäßig überwachen.
• Change-Disziplin: Jede PBR-Änderung mit Testtraffic verifizieren.

Als herstellerneutrale Orientierung für sichere Konfigurationsverwaltung und „Least Privilege“-Denken bei Policies ist der Anchor-Text CIS Controls eine sinnvolle Ergänzung.

Praxis-Checkliste: Vor dem Rollout in Produktion

• Ist klar dokumentiert, welcher Traffic umgeleitet wird (Quelle/Ziel/Ports/Markierungen)?
• Ist der Next Hop erreichbar und existiert ein Fallback bei Ausfall?
• Ist der Rückweg konsistent (Firewall/NAT/State berücksichtigt)?
• Steigen ACL- und Route-Map-Zähler wie erwartet, ohne „Beifang“?
• Ist das PBR-Interface korrekt (Ingress-Punkt der Flows)?
• Sind Tests für mehrere Anwendungen durchgeführt (DNS, HTTP/HTTPS, VoIP, VPN, kritische Applikationen)?

Konfiguration speichern und nachvollziehbar absichern

Nach erfolgreicher Verifikation sollten Sie die Konfiguration speichern, damit PBR-Einstellungen nach einem Neustart erhalten bleiben:

copy running-config startup-config

Für weiterführende Cisco-spezifische Optionen und plattformspezifische Unterschiede ist der Anchor-Text Cisco IOS XE PBR Konfigurationsguide eine gute Quelle, um Syntaxvarianten (z. B. Verfügbarkeitsprüfung des Next Hops, zusätzliche Match-Kriterien) sauber abzugleichen.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.