Router-ping kontra VLAN-värd: vilken PBR-policy gäller?

VLAN 10 ska använda VPN och VLAN 20 ska använda WAN, så det första testet är en ping från routern med VLAN 10:s gränssnittsadress som källa. Det lyckas, route-map-räknarna ökar och alla drar slutsatsen att designen fungerar. Det gör den inte. Den pinget genererades lokalt, och lokalt genererad trafik når en annan policy-anslutningspunkt än ett paket som anländer på VLAN-gränssnittet.

Tre villkor avgör vilken policy du egentligen testar: var paketet skapas, var det kommer in och vad det matchar.

Var paketet kommer in avgör vilken policy som körs

En gränssnitts-route-map som kopplats med ip policy route-map gäller för paket som anländer på det gränssnittet, som IOS XE PBR-guiden beskriver. En värd i VLAN 10 skickar sin begäran, ramen anländer på VLAN-undergränssnittet och routern utvärderar policyn där. Routerns eget paket anländer aldrig på det gränssnittet, eftersom det föddes i routern.

Att välja VLAN-adressen som källa ändrar headern. Det ändrar inte ursprunget.

Varför pinget med källa fortfarande inte är värden

Källadressen spelar roll för en ACL-matchning, och det är precis det som gör testet så övertygande. Paketet matchar en källklausul, räknarna ökar och utdata ser korrekt ut. Vad testet inte kan visa är ingångsgränssnittet, ankomstkontexten eller om ett värdpaket skulle ta samma gren.

Ett test som återskapar matchningen men inte kontexten bevisar halva designen, och med ett halvt bevis är det så designer går live med fel policy kopplad.

När en lokal policy är rätt svar

Cisco dokumenterar ip local policy route-map för trafik som routern genererar själv. Det är ett separat omfång, och det är rätt verktyg när kravet verkligen gäller routerns egen trafik. Det är inte ett saknat steg som varje VLAN-styrningsdesign behöver. Bred matchning där kan också påverka hanterings- och stödanslutningar, vilket är en mycket större förändring än det ser ut.

Lokalt genererad TCP har en extra förutsättning: den behöver en tillämplig destinationspost i routingtabellen även när policyn väljer en annan väg. Ett ICMP-resultat bevisar inte samma beteende för TCP.

Vad du i stället ska testa på värden

Kör testet från en auktoriserad värd i VLAN 10, med dess riktiga källadress, destination, protokoll och port. Registrera ingångsgränssnittet och route-map-matchningen tillsammans med resultatet, så att beviset namnger den policy som kördes. Upprepa sedan för en värd i VLAN 20 och bekräfta att den tar den andra vägen.

Båda vägarna behöver fungerande next hops, returbarhet och, där det är tillämpligt, VPN-täckning. PBR väljer ett vidarebefordringsbeslut; det skapar inte fjärrtjänsten och ger inte applikationen tillstånd.

Vad resultatet kan och inte kan bevisa

Ett lyckat värdflöde bevisar att policyn matchade och att den valda vägen fungerade i det ögonblicket. Det bevisar inte att routerns egen trafik styrs, och det bevisar inte att applikationen var auktoriserad, eftersom det är olika frågor med olika bevis.

Behåll pinget i journalen som bevis om ett lokalt paket. Gå sedan och hämta beviset för värdens flöde, i stället för att utöka policyns omfång tills de två testerna råkar se likadana ut.