Kva VRF når VPN-peer-en, og kva ber pakken?

Kvar tunnel inne i ein rutekontekst hos ein kunde må framleis nå sin eksterne peer, og det oppslaget kan skje i ein heilt annan tabell. Å gjere dette feil gir ein av dei mest forvirrande feila i VRF-medviten IPsec: tunnelen kjem opp, rutene ser ut til å vere der, og trafikken døyr fordi eitt av dei to oppslaga brukte feil kontekst. Køyr dei fire trinna nedanfor i rekkjefølgje, og hald dei to måla skrivne ned kvar for seg.

To oppslag, éin tunnel

Den ytre innkapsla pakken er adressert til transportadressa til peer-en, og han blir ruta før det finst noka vern. Den indre pakken er adressert til ein kundeservar og blir ruta etter dekapsulering, inne i konteksten til kunden. Det er to mål, to oppslag og ofte to ulike tabellar.

Dokumentasjonen til Cisco for VRF-medviten IPsec kallar dei frontdør-VRF-en og den indre VRF-en. Frontdøra ber den krypterte transporten, og den indre konteksten ber den verna trafikken. Ingenting ved å namnsetje ein tunnel etter ein kunde får nokon av rutene til å dukke opp.

Så list fire fakta før du endrar ein konfigurasjon: transportadressa til peer-en og konteksten som når henne, deretter prefikset til servaren og konteksten som når det. Viss du ikkje kan fylle ut alle fire, er du i ferd med å gjette. Gjetting på dette området er dyrt, fordi ei rute som blir lagd til i feil tabell kan få éin straum til å verke medan ho stille øydelegg ein annan. Dei fire faktaa tek ti minutt å samle og sparer ein dag med opptaksanalyse.

Stadfest transportoppslaget for peer-en

Start med frontdøra, fordi ein tunnel som ikkje kan nå peer-en sin aldri vil sleppe gjennom ein einaste verna pakke. På IOS spør du etter ruta til peer-en inne i transport-VRF-en i staden 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 svarar på om peer-adressa er nåbar i den konteksten, den andre listar opp VRF-ane som faktisk finst, og den tredje viser om det vart danna ein tryggleiksassosiasjon. Ei peer-adresse som berre blir slått opp i den globale tabellen er den klassiske frontdørfeilen, og han viser seg som ein IKE-forhandling som aldri startar.

Kontroller også grensesnitttilordninga. Den dokumenterte åtferda krev at frontdør-VRF-en til tunnelen og VRF-en til WAN-grensesnittet er samde; uoverensstemming kan la ein pakke gå ut og likevel hindre at svaret blir handsama i rett kontekst.

Stadfest det indre oppslaget for servaren

Når frontdøra er prova, byt til konteksten til kunden og still det same spørsmålet om prefikset til servaren. Dette oppslaget avgjer om ein dekapsla pakke kan sendast vidare.

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

Den første kommandoen viser den indre ruta, og den andre viser tilstanden til økta saman med kontekstane som plattforma knytte til henne. Viss ruta finst, men øktdetaljane nemner feil indre kontekst, sender tunnelen vidare til ein tabell som ikkje kjenner prefikset til kunden.

Ei rute i den globale tabellen er ikkje prov for noko av dei to oppslaga. Globale ruter blir brukte når ein pakke ikkje er knytt til ein VRF, og eit tunellgrensesnitt som er tildelt ein kundekontekst endrar den tilknytinga. Viss den indre ruta manglar, blir pakken dekapsla og deretter sloppen på grunn av manglande vidaresendingspost, noko som ser ut som pakketap og ikkje ein rutefeil.

Plasser innstillinga der modellen ventar henne

Den same dokumentasjonen skil mellom konfigurasjonsmodellar, og ei innstilling som høyrer til den eine høyrer ikkje nødvendigvis til den andre. For tunellgrensesnitt som brukar tunellvern, blir den indre VRF-en definert på tunellgrensesnittet. For crypto map-baserte design er den indre VRF-en ein del av crypto map-posten. Å flytte ein liknande kommando mellom modellar utan å kontrollere rolla er måten eit fungerande design blir periodisk ustabilt.

Ruting og identitet er separate saker. Nåbarheit erstattar aldri ein peer-profil som eininga vil godta, og ei ny namngjeving av VRF-en må ikkje endre legitimasjonen som blir tilboden. Kontroller begge etter kvar endring, fordi ein tunnel som forhandlar med feil profil framleis kan danne ein assosiasjon og ikkje senda noko vidare.

Til slutt, registrer dei fire faktaa og kommandoane som prova dei i endringsloggen. Den neste ingeniøren arvar tunnelen og ikkje resonnementet, og eit kort notat som nemner begge kontekstane er verdt meir enn eit diagram som ingen oppdaterer.