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

Hver tunnel inne i en kundes rutingkontekst må fortsatt nå sin eksterne peer, og det oppslaget kan skje i en helt annen tabell. Å gjøre dette feil gir en av de mest forvirrende feilene i VRF-bevisst IPsec: tunnelen kommer opp, rutene ser ut til å være der, og trafikken dør fordi ett av de to oppslagene brukte feil kontekst. Kjør de fire trinnene nedenfor i rekkefølge, og hold de to destinasjonene skrevet ned hver for seg.

To oppslag, én tunnel

Den ytre innkapslede pakken er adressert til peer-ens transportadresse, og den rutes før det finnes noen beskyttelse. Den indre pakken er adressert til en kundeserver og rutes etter dekapsulering, inne i kundens kontekst. Det er to destinasjoner, to oppslag og ofte to forskjellige tabeller.

Ciscos dokumentasjon for VRF-bevisst IPsec kaller dem frontdør-VRF-en og den indre VRF-en. Frontdøren bærer den krypterte transporten, og den indre konteksten bærer den beskyttede trafikken. Ingenting ved å navngi en tunnel etter en kunde får noen av rutene til å dukke opp.

Så list fire fakta før du endrer en konfigurasjon: peer-ens transportadresse og konteksten som når den, deretter serverens prefiks og konteksten som når det. Hvis du ikke kan fylle ut alle fire, er du i ferd med å gjette. Gjetting på dette området er dyrt, fordi en rute som legges til i feil tabell kan få én strøm til å virke mens den stille ødelegger en annen. De fire faktaene tar ti minutter å samle og sparer en dag med opptaksanalyse.

Bekreft transportoppslaget for peer-en

Start med frontdøren, fordi en tunnel som ikke kan nå peer-en sin aldri vil slippe gjennom en eneste beskyttet pakke. På IOS spør du etter ruten til peer-en inne i transport-VRF-en i stedet for i den globale tabellen.

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

Den første kommandoen svarer på om peer-adressen er nåbar i den konteksten, den andre lister opp VRF-ene som faktisk finnes, og den tredje viser om det ble dannet en sikkerhetsassosiasjon. En peer-adresse som bare slås opp i den globale tabellen er den klassiske frontdørfeilen, og den viser seg som en IKE-forhandling som aldri starter.

Kontroller også grensesnitttilordningen. Den dokumenterte atferden krever at tunnelens frontdør-VRF og WAN-grensesnittets VRF er enige; uoverensstemmelse kan la en pakke gå ut og likevel hindre at svaret blir behandlet i riktig kontekst.

Bekreft det indre oppslaget for serveren

Når frontdøren er bevist, bytt til kundens kontekst og still det samme spørsmålet om serverens prefiks. Dette oppslaget avgjør om en dekapsulert pakke kan videresendes.

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

Den første kommandoen viser den indre ruten, og den andre viser sesjonstilstanden sammen med kontekstene som plattformen knyttet til den. Hvis ruten finnes, men sesjonsdetaljene nevner feil indre kontekst, videresender tunnelen til en tabell som ikke kjenner kundens prefiks.

En rute i den globale tabellen er ikke bevis for noen av de to oppslagene. Globale ruter brukes når en pakke ikke er knyttet til en VRF, og et tunnelgrensesnitt som er tilordnet en kundekontekst, endrer den tilknytningen. Hvis den indre ruten mangler, dekapsuleres pakken og slippes deretter på grunn av manglende videresendingspost, noe som ser ut som pakketap og ikke en rutingfeil.

Plasser innstillingen der modellen forventer den

Den samme dokumentasjonen skiller mellom konfigurasjonsmodeller, og en innstilling som hører til den ene, hører ikke nødvendigvis til den andre. For tunnelgrensesnitt som bruker tunnelbeskyttelse, defineres den indre VRF-en på tunnelgrensesnittet. For crypto map-baserte design er den indre VRF-en en del av crypto map-posten. Å flytte en lignende kommando mellom modeller uten å kontrollere rollen er måten et fungerende design blir periodisk ustabilt.

Ruting og identitet er separate saker. Nåbarhet erstatter aldri en peer-profil som enheten vil godta, og en ny navngiving av VRF-en må ikke endre legitimasjonen som tilbys. Kontroller begge etter enhver endring, fordi en tunnel som forhandler med feil profil fortsatt kan danne en assosiasjon og ikke videresende noe.

Til slutt, registrer de fire faktaene og kommandoene som beviste dem i endringsloggen. Den neste ingeniøren arver tunnelen og ikke resonnementet, og et kort notat som navngir begge kontekstene er verdt mer enn et diagram som ingen oppdaterer.