Hvilken VRF når VPN-peer’en, og hvilken bærer pakken?

Hver tunnel inde i en kundes routingkontekst skal stadig nå sin fjerne peer, og det opslag kan ske i en helt anden tabel. At gøre dette forkert giver en af de mest forvirrende fejl i VRF-bevidst IPsec: tunnelen kommer op, ruterne ser ud til at være der, og trafikken dør, fordi et af de to opslag brugte den forkerte kontekst. Kør de fire trin nedenfor i rækkefølge, og hold de to destinationer skrevet ned hver for sig.

To opslag, én tunnel

Den ydre indkapslede pakke er adresseret til peer’ens transportadresse, og den routes før der findes nogen beskyttelse. Den indre pakke er adresseret til en kundeserver og routes efter dekapsulering, inde i kundens kontekst. Det er to destinationer, to opslag og ofte to forskellige tabeller.

Ciscos dokumentation for VRF-bevidst IPsec kalder dem frontdørs-VRF’en og den indre VRF. Frontdøren bærer den krypterede transport, og den indre kontekst bærer den beskyttede trafik. Intet ved at navngive en tunnel efter en kunde får nogen af ruterne til at dukke op.

Så list fire fakta, før du ændrer en konfiguration: peer’ens transportadresse og den kontekst, der når den, derefter serverens præfiks og den kontekst, der når det. Hvis du ikke kan udfylde alle fire, er du ved at gætte. Gætteri på dette område er dyrt, fordi en rute, der føjes til den forkerte tabel, kan få én strøm til at virke, mens den stille ødelægger en anden. De fire fakta tager ti minutter at samle og sparer en dag med optagelsesanalyse.

Bekræft transportopslaget for peer’en

Start med frontdøren, fordi en tunnel, der ikke kan nå sin peer, aldrig vil sende en eneste beskyttet pakke igennem. På IOS skal du spørge efter ruten til peer’en inde i transport-VRF’en i stedet for i den globale tabel.

show ip route vrf wan-blue 203.0.113.20
show ip vrf brief
show crypto ikev2 sa

Den første kommando svarer på, om peer-adressen kan nås i den kontekst, den anden viser de VRF’er, der faktisk findes, og den tredje viser, om der blev dannet en sikkerhedsassociation. En peer-adresse, der kun slås op i den globale tabel, er den klassiske frontdørsfejl, og den viser sig som en IKE-forhandling, der aldrig starter.

Kontroller også interface-tildelingen. Den dokumenterede adfærd kræver, at tunnelens frontdørs-VRF og WAN-interfacets VRF er enige; uenighed kan lade en pakke komme ud og alligevel forhindre, at svaret behandles i den rigtige kontekst.

Bekræft det indre opslag for serveren

Når frontdøren er bevist, skift til kundens kontekst, og stil det samme spørgsmål om serverens præfiks. Dette opslag afgør, om en dekapsuleret pakke kan videresendes.

show ip route vrf customer-blue 10.60.4.0
show crypto session detail

Den første kommando viser den indre rute, og den anden viser sessionstilstanden sammen med de kontekster, som platformen har knyttet til den. Hvis ruten findes, men sessionsdetaljerne nævner den forkerte indre kontekst, videresender tunnelen til en tabel, der ikke kender kundens præfiks.

En rute i den globale tabel er ikke bevis for noget af de to opslag. Globale ruter bruges, når en pakke ikke er knyttet til en VRF, og et tunnel-interface, der er tildelt en kundekontekst, ændrer den tilknytning. Hvis den indre rute mangler, dekapsuleres pakken og droppes derefter på grund af manglende videresendingspost, hvilket ligner pakketab i stedet for en routingfejl.

Placer indstillingen, hvor modellen forventer den

Den samme dokumentation skelner mellem konfigurationsmodeller, og en indstilling, der hører til den ene, hører ikke nødvendigvis til den anden. For tunnel-interfaces, der bruger tunnelbeskyttelse, defineres den indre VRF på tunnel-interfacet. For crypto map-baserede designs er den indre VRF en del af crypto map-posten. At flytte en lignende kommando mellem modeller uden at kontrollere dens rolle er måden, hvorpå et fungerende design bliver periodisk ustabilt.

Routing og identitet er adskilte anliggender. Nåbarhed erstatter aldrig en peer-profil, som enheden accepterer, og en omdøbning af VRF må ikke ændre de legitimationsoplysninger, der tilbydes. Kontroller begge efter enhver ændring, fordi en tunnel, der forhandler med den forkerte profil, stadig kan danne en association og ikke videresende noget.

Endelig skal du registrere de fire fakta og de kommandoer, der beviste dem, i ændringsloggen. Den næste ingeniør arver tunnelen og ikke ræsonnementet, og en kort note, der navngiver begge kontekster, er mere værd end et diagram, som ingen opdaterer.