Router-ping kontra VLAN-vert: hvilken PBR-policy gjelder?
En ping som ruteren sender, er ikke en pakke fra en VLAN-vert, selv med det grensesnittet som kilde. Test vertens flyt før du utvider policyns omfang.
VLAN 10 skal bruke VPN, og VLAN 20 skal bruke WAN, så den første testen er en ping fra ruteren med VLAN 10s grensesnittadresse som kilde. Den lykkes, route-map-tellerne øker, og alle konkluderer med at designet virker. Det gjør det ikke. Den ping-en ble generert lokalt, og lokalt generert trafikk når et annet policy-tilknytningspunkt enn en pakke som ankommer på VLAN-grensesnittet.
Tre betingelser avgjør hvilken policy du egentlig tester: hvor pakken opprettes, hvor den kommer inn, og hva den matcher.
Hvor pakken kommer inn, avgjør hvilken policy som kjører
En grensesnitt-route-map som er tilknyttet med ip policy route-map, gjelder for pakker som ankommer på det grensesnittet, slik IOS XE PBR-veiledningen beskriver. En vert i VLAN 10 sender forespørselen sin, rammen ankommer på VLAN-undergrensesnittet, og ruteren evaluerer policyen der. Ruterens egen pakke ankommer aldri på det grensesnittet, fordi den ble født i ruteren.
Å velge VLAN-adressen som kilde endrer headeren. Det endrer ikke opprinnelsen.
Hvorfor ping-en med kilde fortsatt ikke er verten
Kildeadressen betyr noe for en ACL-match, og det er nettopp det som gjør testen så overbevisende. Pakken matcher en kildeklausul, tellerne øker, og utdata ser riktig ut. Det testen ikke kan vise, er inngangsgrensesnittet, ankomstkonteksten eller om en vertspakke ville ta samme gren.
En test som gjengir matchen men ikke konteksten, beviser halvparten av designet, og med et halvt bevis er det slik design går live med feil policy tilknyttet.
Når en lokal policy er det riktige svaret
Cisco dokumenterer ip local policy route-map for trafikk som ruteren genererer selv. Det er et separat omfang, og det er riktig verktøy når kravet virkelig gjelder ruterens egen trafikk. Det er ikke et manglende trinn som enhver VLAN-styringsdesign trenger. Bred matching der kan også påvirke administrasjons- og støttetilkoblinger, noe som er en mye større endring enn det ser ut som.
Lokalt generert TCP har en ekstra forutsetning: det trenger en anvendelig destinasjonsoppføring i rutetabellen selv når policyen velger en annen vei. Et ICMP-resultat beviser ikke samme atferd for TCP.
Hva du i stedet bør teste på verten
Kjør testen fra en autorisert vert i VLAN 10, med dens virkelige kildeadresse, destinasjon, protokoll og port. Registrer inngangsgrensesnittet og route-map-matchen sammen med resultatet, slik at beviset navngir policyen som kjørte. Gjenta deretter for en vert i VLAN 20, og bekreft at den tar den andre veien.
Begge veiene trenger fungerende next hops, returbarhet og, der det er relevant, VPN-dekning. PBR velger en videresendingsbeslutning; det oppretter ikke fjertjenesten og gir ikke applikasjonen tillatelse.
Hva resultatet kan og ikke kan bevise
En vellykket vertsflyt beviser at policyen matchet, og at den valgte veien virket i det øyeblikket. Det beviser ikke at ruterens egen trafikk styres, og det beviser ikke at applikasjonen var autorisert, fordi det er forskjellige spørsmål med forskjellige bevis.
Behold ping-en i journalen som bevis om en lokal pakke. Gå deretter og hent beviset for vertens flyt, i stedet for å utvide policyens omfang til de to testene tilfeldigvis ser like ut.