Router-ping vs. VLAN-vært: hvilken PBR-politik gælder?
Et ping, routeren sender, er ikke en pakke fra en VLAN-vært, selv med den grænseflade som kilde. Test værtens flow, før du udvider politikkens omfang.
VLAN 10 skal bruge VPN, og VLAN 20 skal bruge WAN, så den første test er et ping fra routeren med VLAN 10's grænsefladeadresse som kilde. Det lykkes, route-map-tællerne stiger, og alle konkluderer, at designet virker. Det gør det ikke. Det ping blev genereret lokalt, og lokalt genereret trafik når et andet policy-tilslutningspunkt end en pakke, der ankommer på VLAN-grænsefladen.
Tre betingelser afgør, hvilken politik du egentlig tester: hvor pakken oprettes, hvor den kommer ind, og hvad den matcher.
Hvor pakken kommer ind, afgør, hvilken politik der kører
En grænseflade-route-map, der er tilknyttet med ip policy route-map, gælder for pakker, der ankommer på den grænseflade, som IOS XE PBR-vejledningen beskriver. En vært i VLAN 10 sender sin anmodning, rammen ankommer på VLAN-underinterfacet, og routeren evaluerer politikken der. Routerens egen pakke ankommer aldrig på den grænseflade, fordi den blev født i routeren.
At vælge VLAN-adressen som kilde ændrer headeren. Det ændrer ikke oprindelsen.
Hvorfor pinget med kilde stadig ikke er værten
Kildeadressen betyder noget for et ACL-match, og det er præcis det, der gør testen så overbevisende. Pakken matcher en kildeklausul, tællerne stiger, og outputtet ser rigtigt ud. Hvad testen ikke kan vise, er indgangsgrænsefladen, ankomstkonteksten eller om en værts pakke ville tage samme gren.
En test, der gengiver matchet men ikke konteksten, beviser halvdelen af designet, og med et halvt bevis er det, hvordan designs sendes live med den forkerte politik tilknyttet.
Hvornår en lokal politik er det rigtige svar
Cisco dokumenterer ip local policy route-map for trafik, som routeren selv genererer. Det er et separat omfang, og det er det rigtige værktøj, når kravet virkelig vedrører routerens egen trafik. Det er ikke et manglende trin, som ethvert VLAN-styringsdesign har brug for. Bred matching der kan også påvirke administrations- og støtteforbindelser, hvilket er en meget større ændring, end det ser ud.
Lokalt genereret TCP har en ekstra forudsætning: det kræver en anvendelig destinationspost i routingtabellen, selv når politikken vælger en anden sti. Et ICMP-resultat beviser ikke samme adfærd for TCP.
Hvad du i stedet skal teste på værten
Kør testen fra en autoriseret vært i VLAN 10 med dens rigtige kildeadresse, destination, protokol og port. Registrér indgangsgrænsefladen og route-map-matchet sammen med resultatet, så beviset navngiver den politik, der kørte. Gentag derefter for en vært i VLAN 20, og bekræft at den tager den anden sti.
Begge stier har brug for fungerende next hops, returrbarhed og, hvor det er relevant, VPN-dækning. PBR vælger en videresendelsesbeslutning; det opretter ikke fjertjenesten og giver ikke applikationen tilladelse.
Hvad resultatet kan og ikke kan bevise
Et vellykket vært-flow beviser, at politikken matchede, og at den valgte sti virkede i det øjeblik. Det beviser ikke, at routerens egen trafik styres, og det beviser ikke, at applikationen var autoriseret, fordi det er forskellige spørgsmål med forskellige beviser.
Behold pinget i journalen som bevis om en lokal pakke. Gå derefter efter beviset for værtens flow i stedet for at udvide politikkens omfang, indtil de to tests tilfældigvis ligner hinanden.