Router-Ping vs. VLAN-Host: Welche PBR-Policy greift?

VLAN 10 sollte das VPN nutzen und VLAN 20 das WAN, daher ist der erste Test ein Ping vom Router mit der Schnittstellenadresse von VLAN 10 als Quelle. Er gelingt, die Route-Map-Zähler steigen, und alle schließen daraus, dass das Design funktioniert. Das tut es nicht. Dieser Ping wurde lokal erzeugt, und lokal erzeugter Verkehr erreicht einen anderen Punkt der Policy-Anbindung als ein Paket, das auf der VLAN-Schnittstelle eintrifft.

Drei Bedingungen entscheiden, welche Policy Sie wirklich testen: wo das Paket entsteht, wo es eintritt und worauf es passt.

Wo das Paket eintritt, entscheidet, welche Policy läuft

Eine mit ip policy route-map angehängte Schnittstellen-Route-Map gilt für Pakete, die auf dieser Schnittstelle eintreffen, wie der IOS XE PBR-Leitfaden beschreibt. Ein Host in VLAN 10 sendet seine Anfrage, das Frame trifft auf der VLAN-Subschnittstelle ein, und der Router wertet die Policy dort aus. Das eigene Paket des Routers trifft nie auf dieser Schnittstelle ein, weil es im Router entstanden ist.

Die VLAN-Adresse als Quelle zu wählen, ändert den Header. Sie ändert nicht den Ursprung.

Warum der Ping mit Quelladresse immer noch nicht der Host ist

Die Quelladresse ist für einen ACL-Treffer entscheidend, und genau das macht den Test so überzeugend. Das Paket passt auf eine Quellklausel, die Zähler steigen, und die Ausgabe sieht richtig aus. Was der Test nicht zeigen kann, ist die Eingangsschnittstelle, der Eintrittskontext oder ob ein Host-Paket denselben Zweig nehmen würde.

Ein Test, der den Treffer, aber nicht den Kontext reproduziert, beweist die Hälfte des Designs, und mit einem halben Beweis gehen Designs mit der falschen Policy live.

Wann eine lokale Policy die richtige Antwort ist

Cisco dokumentiert ip local policy route-map für Verkehr, den der Router selbst erzeugt. Das ist ein getrennter Geltungsbereich und das richtige Werkzeug, wenn die Anforderung tatsächlich den eigenen Verkehr des Routers betrifft. Es ist kein fehlender Schritt, den jedes VLAN-Steuerungsdesign braucht. Eine breite Übereinstimmung kann dort auch Management- und Hilfsverbindungen betreffen, was eine viel größere Änderung ist, als es aussieht.

Lokal erzeugtes TCP hat eine zusätzliche Voraussetzung: Es braucht einen passenden Zieleintrag in der Routing-Tabelle, selbst wenn die Policy einen anderen Pfad wählt. Ein ICMP-Ergebnis beweist nicht dasselbe Verhalten für TCP.

Was stattdessen auf dem Host zu testen ist

Führen Sie den Test von einem autorisierten Host in VLAN 10 aus, mit seiner echten Quelladresse, seinem Ziel, Protokoll und Port. Protokollieren Sie die Eingangsschnittstelle und den Route-Map-Treffer zusammen mit dem Ergebnis, damit der Nachweis die Policy benennt, die gelaufen ist. Wiederholen Sie das dann für einen Host in VLAN 20 und bestätigen Sie, dass er den anderen Pfad nimmt.

Beide Pfade brauchen funktionierende Next Hops, Rückweg-Erreichbarkeit und, wo zutreffend, VPN-Abdeckung. PBR wählt eine Weiterleitungsentscheidung; es erzeugt nicht den entfernten Dienst und erteilt der Anwendung keine Berechtigung.

Was das Ergebnis beweisen kann und was nicht

Ein erfolgreicher Host-Flow beweist, dass die Policy gepasst hat und der gewählte Pfad in diesem Moment funktionierte. Er beweist nicht, dass der eigene Verkehr des Routers gelenkt wird, und er beweist nicht, dass die Anwendung autorisiert war, denn das sind andere Fragen mit anderen Nachweisen.

Bewahren Sie den Ping im Protokoll als Nachweis über ein lokales Paket auf. Holen Sie dann die Nachweise für den Host-Flow, statt den Geltungsbereich der Policy zu erweitern, bis die beiden Tests zufällig gleich aussehen.