Router-ping versus VLAN-host: welke PBR-policy geldt?

VLAN 10 moet de VPN gebruiken en VLAN 20 de WAN, dus de eerste test is een ping vanaf de router met het interfaceadres van VLAN 10 als bron. Die slaagt, de route-map-tellers lopen op en iedereen concludeert dat het ontwerp werkt. Dat doet het niet. Die ping is lokaal gegenereerd, en lokaal gegenereerd verkeer bereikt een ander aanhechtingspunt van de policy dan een pakket dat op de VLAN-interface aankomt.

Drie voorwaarden bepalen welke policy je echt test: waar het pakket wordt gemaakt, waar het binnenkomt en waarop het matcht.

Waar het pakket binnenkomt, bepaalt welke policy draait

Een interface-route-map die met ip policy route-map is gekoppeld, geldt voor pakketten die op die interface aankomen, zoals de IOS XE PBR-gids beschrijft. Een host in VLAN 10 verstuurt zijn verzoek, het frame komt aan op de VLAN-subinterface en de router evalueert de policy daar. Het eigen pakket van de router komt nooit op die interface aan, omdat het in de router is ontstaan.

Het VLAN-adres als bron kiezen verandert de header. Het verandert niet de oorsprong.

Waarom de ping met bronadres nog steeds niet de host is

Het bronadres is van belang voor een ACL-match, en precies daarom is de test zo overtuigend. Het pakket matcht een bronclausule, de tellers lopen op en de uitvoer ziet er correct uit. Wat de test niet kan laten zien, is de inkomende interface, de aankomstcontext of of een hostpakket dezelfde tak zou nemen.

Een test die de match maar niet de context reproduceert, bewijst de helft van het ontwerp, en met een half bewijs gaan ontwerpen de deur uit met de verkeerde policy eraan.

Wanneer een lokale policy het juiste antwoord is

Cisco documenteert ip local policy route-map voor verkeer dat de router zelf genereert. Dat is een apart bereik, en het is het juiste hulpmiddel wanneer de eis echt over het eigen verkeer van de router gaat. Het is geen ontbrekende stap die elk VLAN-stuurontwerp nodig heeft. Brede matching kan daar ook beheer- en ondersteunende verbindingen raken, wat een veel grotere wijziging is dan het lijkt.

Lokaal gegenereerde TCP heeft een extra voorwaarde: er is een toepasselijke bestemmingsvermelding in de routingtabel nodig, zelfs wanneer de policy een ander pad kiest. Een ICMP-resultaat bewijst niet hetzelfde gedrag voor TCP.

Wat je in plaats daarvan op de host moet testen

Voer de test uit vanaf een geautoriseerde host in VLAN 10, met zijn echte bronadres, bestemming, protocol en poort. Leg de inkomende interface en de route-map-match naast het resultaat vast, zodat het bewijs de policy noemt die heeft gedraaid. Herhaal dit daarna voor een host in VLAN 20 en bevestig dat die het andere pad neemt.

Beide paden hebben werkende next hops, terugwegbereikbaarheid en, waar van toepassing, VPN-dekking nodig. PBR kiest een doorstuurbeslissing; het maakt de externe dienst niet aan en verleent de toepassing geen toestemming.

Wat het resultaat wel en niet kan bewijzen

Een geslaagde hoststroom bewijst dat de policy matchte en dat het gekozen pad op dat moment werkte. Het bewijst niet dat het eigen verkeer van de router wordt gestuurd, en het bewijst niet dat de toepassing geautoriseerd was, want dat zijn andere vragen met ander bewijs.

Bewaar de ping in het dossier als bewijs over een lokaal pakket. Haal daarna het bewijs van de hoststroom, in plaats van het bereik van de policy te verbreden tot de twee tests toevallig op elkaar lijken.