PBR Troubleshooting: Reihenfolge, Match-Kriterien und Side Effects

PBR Troubleshooting (Policy-Based Routing) ist eine der anspruchsvollsten Aufgaben im Routing-Betrieb, weil PBR bewusst die „normale“ Pfadwahl außer Kraft setzt. Während klassisches Routing auf der Longest-Prefix-Match-Logik der Routing-Tabelle basiert, entscheidet PBR anhand von Regeln, Match-Kriterien und einer definierten Reihenfolge, wohin Traffic gehen soll – unabhängig davon, was das IGP oder BGP für „besten Pfad“ hält. Genau das ist in vielen Designs gewollt: selektives Breakout ins Internet, Zwangsführung über eine Firewall-Instanz, Steering zu WAN-Links, Traffic Engineering für bestimmte Applikationen oder saubere Trennung von Management- und User-Traffic. Im Incident wird PBR jedoch häufig zur Fehlerquelle, weil die Side Effects subtil sind: Asymmetrisches Routing über stateful Geräte, unerwartete Blackholes bei Next-Hop-Ausfall, selektive Paketverluste nur für bestimmte Ports, oder latente Latenzspitzen, die nur bei bestimmten Flows auftreten. Wer PBR ohne System debuggt, tappt schnell in die Falle, dass „Routing stimmt doch“ – und übersieht, dass PBR den Verkehr bereits vor der Routing-Entscheidung umleitet. Dieser Artikel zeigt Ihnen ein methodisches Vorgehen für PBR Troubleshooting: Wie die Reihenfolge tatsächlich wirkt, welche Match-Kriterien die häufigsten Fehler verursachen, wie Sie PBR-Entscheidungen beweisen und welche Nebenwirkungen Sie beim Design und Betrieb aktiv absichern sollten.

PBR in der Praxis: Wo PBR im Paketpfad „eingreift“

Der wichtigste mentale Schritt im PBR Troubleshooting ist, PBR als Entscheidung vor oder anstelle der normalen Routing-Tabelle zu verstehen (je nach Plattform). In vielen Implementierungen wird PBR auf einem Interface in Ingress-Richtung angewendet: Pakete treffen ein, werden gegen eine Policy geprüft (Match), und falls eine Regel greift, wird eine alternative Weiterleitung (Set/Action) ausgeführt. Greift keine Regel, fällt das Paket zurück auf klassisches Routing (Fallback). In einigen Designs existiert zusätzlich „PBR mit Verify/Track“, bei dem der alternative Next Hop nur genutzt wird, wenn er erreichbar ist.

• Ingress-Entscheidung: PBR wird häufig am eingehenden Interface angewendet und steuert den nächsten Hop oder das Ausgangsinterface.
• Match → Set: Match-Kriterien wählen Traffic; Set-Aktionen bestimmen die Weiterleitung oder markieren Pakete.
• Fallback: Wenn kein Match (oder Set nicht möglich), geht Traffic über die normale Routing-Entscheidung.
• Stateful Side Effects: PBR kann Hin- und Rückweg auseinanderziehen, was bei Firewalls/NAT kritisch ist.

Die häufigsten PBR-Fehlerbilder: Woran Sie PBR-Probleme erkennen

PBR-Probleme wirken selten „global“. Typisch sind selektive Ausfälle, die sich wie Applikationsfehler anfühlen. Diese Muster sind besonders häufig:

• Nur bestimmte Ziele/Ports betroffen: z. B. nur SaaS-Endpoints, nur TCP/443, nur DNS, weil Match-Kriterien oder ACLs zu eng/zu breit sind.
• „Ping geht, HTTPS nicht“: ICMP fällt oft nicht unter dieselbe Policy oder folgt anderem Return-Path; stateful Geräte droppen TCP.
• Asymmetrie und „out of state“: Firewall-Logs zeigen fehlenden Session-State, weil Rückweg nicht über dieselbe Instanz läuft.
• Blackholing bei Next-Hop-Ausfall: PBR steuert auf einen Next Hop, der nicht mehr erreichbar ist; ohne Track/Verify gehen Pakete ins Leere.
• Intermittent Issues: PBR greift nur bei bestimmten Flows (Hash/Session), oder eine Regel matcht nur sporadisch (z. B. DSCP/Marking nicht konsistent).
• Performance-Probleme statt „Down“: PBR zwingt Traffic über einen längeren Pfad oder über eine überlastete Appliance.

Reihenfolge ist alles: Wie PBR-Regeln tatsächlich ausgewertet werden

Die meisten PBR-Implementierungen arbeiten mit einer klaren Reihenfolge: Die Policy besteht aus Sequenzen/Statements, und die erste passende Regel gewinnt (First-Match-Wins). Das klingt trivial, ist aber die Ursache vieler Incidents, weil Teams Regeln „unten anhängen“ und erwarten, dass sie nur ergänzen – während oben bereits ein zu breiter Match alles abfängt.

Typische Reihenfolge-Fallen

• „Catch-all“ zu früh: Eine generische Regel (z. B. „match any“) steht vor spezifischen Regeln und überschreibt sie.
• Negatives Matching fehlt: Ohne explizite Excludes wird Traffic erfasst, der niemals gesteuert werden sollte (z. B. Management, VoIP, VPN-Tunnel).
• Mehrere Policies greifen: Plattformabhängig können QoS/ACL/PBR in unterschiedlicher Reihenfolge wirken; Änderungen an Markings beeinflussen Match-Ergebnisse.
• Shadowing durch Address-Families: IPv6-Traffic wird nicht oder anders behandelt als IPv4, weil PBR nur für eine Family aktiv ist.

Nachweis statt Vermutung

Beweisen Sie die Reihenfolge mit Zählern/Hitcounts pro Regel (sofern die Plattform das bietet). Wenn eine Regel „nie“ hit, ist sie entweder falsch positioniert oder matcht nicht. Wenn eine Regel „alles“ hit, ist sie zu breit oder steht zu früh.

Match-Kriterien: Wo die meisten Fehler entstehen

PBR lebt von Match-Kriterien. Je präziser und stabiler diese sind, desto weniger Überraschungen gibt es im Betrieb. Gleichzeitig sind viele Match-Kriterien in realen Netzen nicht so stabil, wie man denkt (z. B. DSCP-Remarking, NAT, Proxy, Tunnels). Die häufigsten Match-Klassen:

• Source/Destination IP: klassisch, relativ stabil, aber in NAT-Umgebungen kann „Source“ am PBR-Punkt anders aussehen als erwartet.
• Ports/Protokolle (L4): nützlich für Applikationssteering, aber anfällig, wenn Apps dynamische Ports nutzen.
• DSCP/ToS/Traffic Class: stark für Klassensteuerung, aber nur, wenn Marking end-to-end konsistent ist.
• Ingress Interface/VLAN: stabil, aber bei Umverkabelung/Trunk-Änderungen schnell falsch.
• Application-ID (plattformabhängig): bequem, aber abhängig von DPI/Signaturen und CPU/Performance.

DSCP/Marking-Falle: Matcht die Policy das, was wirklich am Interface ankommt?

Ein sehr häufiger Fehler ist, dass Teams PBR auf DSCP matchen, aber upstream wird DSCP genullt oder ummarkiert (z. B. an WLAN-Edges, Firewalls, oder QoS-Policies). Ergebnis: Die Regel greift nie, oder greift plötzlich „überall“, wenn Markings falsch gesetzt werden. Für einen formaleren QoS-Kontext ist die Übersicht zu Differentiated Services in RFC 2474 hilfreich.

Set-Aktionen: Next-Hop, Interface, Marking – und die wichtigsten Side Effects

Wenn ein Match greift, führen Set-Aktionen zu einer alternativen Weiterleitung. Die häufigsten Varianten sind „set next-hop“, „set outgoing interface“ oder „set ip precedence/dscp“ (und dann klassische Routing-Entscheidung). Jede Variante hat eigene Side Effects:

• Set Next-Hop: flexibel, aber gefährlich ohne Tracking; Next Hop kann unreachable werden.
• Set Outgoing Interface: sehr direkt, kann aber zu Blackholes führen, wenn ARP/ND/Adjacency nicht passt.
• Set Marking: indirekt; Sie markieren und lassen Routing/ECMP entscheiden. Gut, wenn Sie Policy im Netz konsistent umgesetzt haben.
• Set VRF/Next Table (plattformabhängig): mächtig, aber fehleranfällig; VRF-Leaks und falsche Return-Paths sind häufig.

Der Klassiker: PBR steuert zu einem Next-Hop, aber der Rückweg geht anders

Der häufigste PBR-Side-Effect ist Asymmetrie. Ein Paket wird per PBR über Firewall A oder WAN-Link A geschickt, die Antwort kommt aber über Firewall B oder WAN-Link B zurück. Bei stateful Geräten führt das zu Drops. Das ist kein „PBR Bug“, sondern ein Designproblem: Entweder müssen die stateful Geräte State synchronisieren (Cluster) oder Sie müssen Symmetrie erzwingen (z. B. per PBR auch im Rückweg oder per Routing-Design).

Verify/Track: Warum PBR ohne Next-Hop-Healthchecks häufig scheitert

PBR ohne Tracking ist wie ein Navigationssystem ohne Stauinfo: Es steuert zuverlässig – auch wenn die Straße gesperrt ist. Wenn der definierte Next Hop down ist, kann klassisches Routing oft ausweichen; PBR zwingt jedoch auf den Next Hop. Viele Plattformen bieten daher „verify availability“ oder Tracking-Mechanismen (z. B. IP-SLA, BFD, Track-Objekte). Operativ ist das entscheidend, weil es PBR resilient macht.

• Symptom ohne Track: Link/Next Hop fällt aus → Traffic blackholed, obwohl alternative Routen existieren.
• Symptom mit Track: Policy fällt auf Fallback zurück (klassisches Routing), wenn Next Hop nicht erreichbar ist.
• Hygiene: Track-Targets müssen realistisch sein (nicht nur „ping Gateway“, sondern End-to-End bis zum relevanten Service).

Interaktionen mit ECMP und LAG: Warum PBR manchmal „nur manche“ Flows betrifft

PBR kann mit ECMP und Link Aggregation (LAG/Port-Channels) interagieren. Wenn PBR nur markiert und dann das Routing/ECMP entscheidet, können Flows auf unterschiedliche Pfade verteilt werden. Wenn PBR direkt Next-Hop setzt, ist ECMP oft umgangen. Beide Varianten haben Trade-offs.

• PBR setzt Next-Hop: ECMP wird meist ausgehebelt, Traffic wird auf einen Pfad konzentriert (kann Hotspots erzeugen).
• PBR setzt Marking: ECMP bleibt aktiv, aber Sie müssen sicherstellen, dass Hashing und Marking konsistent wirken.
• Flow Pinning: Auch nach PBR bleibt Flow-basiertes Hashing (bei ECMP/LAG) relevant; einzelne Flows können an einem schlechten Member kleben.

Forensik und Evidence: So beweisen Sie PBR-Entscheidungen

PBR Troubleshooting wird schnell, wenn Sie die Entscheidung sichtbar machen. Je nach Plattform stehen dafür unterschiedliche Werkzeuge zur Verfügung (Policy counters, route-map match hits, hardware programming status). Unabhängig vom Vendor gilt: Sie brauchen einen Nachweis, dass ein konkreter Flow eine konkrete Regel getroffen hat und welchen Next Hop er erhalten hat.

• Hitcounts pro Regel: zeigen, ob Ihre Match-Kriterien überhaupt greifen.
• Flow-Beispiele: 5-Tuple (src/dst IP, src/dst Port, Protokoll) plus Zeitpunkt und Interface.
• Capture am Ingress: zeigt, ob das Paket mit den erwarteten Merkmalen eintrifft (DSCP, Ports, IPs).
• Capture am Egress: zeigt, ob der Verkehr tatsächlich über den gewählten Pfad geht.

Für Capture-Workflows sind die Wireshark-Dokumentation und die tcpdump-Manpage hilfreiche Referenzen.

Typische Root-Cause-Muster und schnelle Fix-Richtungen

Regel greift „zu viel“: unerwarteter Traffic wird umgeleitet

• Indiz: Hitcount der Regel sehr hoch, obwohl sie nur „Spezialtraffic“ treffen sollte.
• Wahrscheinliche Ursache: Match zu breit (z. B. nur Subnetz, ohne Ports/Excludes) oder Reihenfolge falsch.
• Fix: Regel präzisieren, Excludes ergänzen, Sequenz neu ordnen, danach Verifikation mit Counters.

Regel greift „nie“: PBR scheint wirkungslos

• Indiz: Hitcount bleibt 0, obwohl betroffener Traffic existiert.
• Wahrscheinliche Ursache: falsches Interface (PBR in falscher Richtung), falsche Address Family, DSCP wird vorher ummarkiert, NAT ändert Source vor Matchpunkt.
• Fix: Matchpunkt verifizieren (Ingress), Capture nutzen, Match-Kriterien an echte Paketmerkmale anpassen.

Traffic blackholed: Next Hop down oder unerreichbar

• Indiz: Nur PBR-gesteuerter Traffic fällt aus; klassischer Routing-Traffic funktioniert.
• Wahrscheinliche Ursache: set next-hop zeigt auf nicht erreichbaren Next Hop; kein Track/Verify.
• Fix: Tracking aktivieren, Fallback definieren, Next-Hop Reachability prüfen (ARP/ND/IGP/VRF).

Asymmetrie: Firewall/NAT sieht nur eine Richtung

• Indiz: Firewall-Logs „out of state“, SYN geht raus, Rückpaket kommt woanders rein.
• Wahrscheinliche Ursache: PBR nur im Hinweg, Rückweg via normalem Routing/anderem Exit.
• Fix: Symmetrie-Design (Cluster-State-Sync, PBR auch im Rückweg, oder Routing so umbauen, dass Return-Path passt).

Performance-Probleme: PBR zwingt über „teuren“ oder überlasteten Pfad

• Indiz: Latenz steigt nur für PBR-traffic; Queue Drops auf dem gesteuerten Pfad.
• Wahrscheinliche Ursache: PBR leitet über Engpass, QoS/Policer, oder langen Umweg.
• Fix: Pfadkapazität prüfen, QoS korrekt, PBR selektiver machen oder dynamisches Steering (Track/Performance) nutzen.

Side Effects, die Sie bewusst einplanen müssen

PBR ist mächtig, aber es hat Nebenwirkungen, die Sie nicht „wegdebuggen“ können – sie müssen im Design berücksichtigt werden.

• Statefulness: PBR kann Asymmetrie erzeugen; Firewalls/NAT benötigen Symmetrie oder State-Sync.
• Observability: Klassische Routing-Tools zeigen oft „richtige“ Routen, aber nicht die PBR-Entscheidung. Ohne Policy Counters wirkt alles widersprüchlich.
• Operational Risk: Eine kleine Regeländerung kann großen Traffic umleiten. Change-Disziplin ist wichtiger als bei normalem Routing.
• Failover-Logik: Ohne Track/Verify kann PBR Failover verhindern, obwohl Routing es könnte.
• Fragmentation/MTU: PBR kann Traffic über Pfade mit anderer MTU zwingen; große Pakete droppen, kleine gehen.

Runbook-Baustein: PBR Troubleshooting in 15 Minuten

• Minute 0–3: Scope klären: Welche Flows/Ziele betroffen? Nur bestimmte Ports? Gibt es stateful Geräte im Pfad? PBR-Interface und Richtung identifizieren.
• Minute 3–6: Reihenfolge prüfen: Policy-Sequenzen und Hitcounts. Greift eine zu breite Regel? Greift die erwartete Regel überhaupt?
• Minute 6–9: Match-Kriterien verifizieren: Capture am Ingress (DSCP, Ports, IPs), NAT/Remarking berücksichtigen, IPv4/IPv6 getrennt prüfen.
• Minute 9–12: Set-Aktion verifizieren: Next-Hop Reachability (ARP/ND/IGP/VRF), Track/Verify aktiv? Pfadgesundheit (Drops/Errors/Queue).
• Minute 12–15: Side Effects prüfen: Asymmetrie/Firewall-State, ECMP/LAG Interaktionen, MTU-Fallen. Danach minimalen Fix anwenden und mit denselben Beispiel-Flows verifizieren.

Sichere Baselines: PBR so betreiben, dass es stabil bleibt

• Policy-Governance: PBR-Regeln versionieren, reviewen, mit klaren Sequenzen (spezifisch vor generisch).
• Excludes standardisieren: Management, Routing-Protocols, Monitoring, Voice/Realtime (je nach Design) explizit ausnehmen.
• Tracking nutzen: Next-Hop Healthchecks mit realistischen Targets; Fallback auf normales Routing definieren.
• Observability: Hitcounts, Drops, Pfadmetriken und „PBR decision visibility“ als Standard-Dashboard.
• Change-Disziplin: kleine Änderungen stufenweise ausrollen, Rollback bereit, Vorher/Nachher Messungen.
• Stateful Design: PBR nur dort, wo Return-Path kontrollierbar ist, oder State-Sync/Cluster nutzen.

Weiterführende Quellen für Grundlagen und Analysepraxis

• RFC 1812 für grundlegende Anforderungen an IPv4-Router (hilfreich für Verständnis von Forwarding/Filtering-Verhalten)
• RFC 2474 für Differentiated Services (DSCP), relevant wenn PBR auf Markings matcht
• RFC 1191 für Path MTU Discovery unter IPv4 (wichtig bei MTU-Side-Effects durch PBR-Pfadwechsel)
• RFC 8201 für Path MTU Discovery unter IPv6
• Wireshark Dokumentation für Flow-Forensik, DSCP/Ports, Timing und Pfadnachweise
• tcpdump Manpage für effiziente Captures und Filter im Incident

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.