Vilken VRF når VPN-peer-en och vilken bär paketet?

Varje tunnel inne i en kunds routingkontext måste fortfarande nå sin avlägsna peer, och det uppslaget kan ske i en helt annan tabell. Att göra detta fel ger ett av de mest förvirrande felen i VRF-medveten IPsec: tunneln kommer upp, rutterna ser ut att finnas och trafiken dör eftersom ett av de två uppslagen använde fel kontext. Kör de fyra stegen nedan i ordning och håll de två destinationerna nedskrivna var för sig.

Två uppslag, en tunnel

Det yttre inkapslade paketet är adresserat till peer-ens transportadress och routas innan något skydd finns. Det inre paketet är adresserat till en kundserver och routas efter dekapsulering, inne i kundens kontext. Det är två destinationer, två uppslag och ofta två olika tabeller.

Ciscos dokumentation för VRF-medveten IPsec kallar dem frontdörrs-VRF:en och den inre VRF:en. Frontdörren bär den krypterade transporten och den inre kontexten bär den skyddade trafiken. Ingenting med att namnge en tunnel efter en kund får någon av rutterna att dyka upp.

Lista därför fyra fakta innan du ändrar en konfiguration: peer-ens transportadress och kontexten som når den, sedan serverns prefix och kontexten som når det. Om du inte kan fylla i alla fyra är du på väg att gissa. Gissning på detta område är dyrt, eftersom en rutt som läggs till i fel tabell kan få ett flöde att fungera medan det tyst bryter ett annat. De fyra fakta tar tio minuter att samla in och sparar en dag av fångstanalys.

Bekräfta transportuppslaget för peer-en

Börja med frontdörren, eftersom en tunnel som inte kan nå sin peer aldrig kommer att släppa igenom ett enda skyddat paket. På IOS frågar du efter rutten till peer-en inne i transport-VRF:en i stället för i den globala tabellen.

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

Det första kommandot svarar på om peer-adressen är nåbar i den kontexten, det andra listar de VRF:er som faktiskt finns och det tredje visar om en säkerhetsassociation bildades. En peer-adress som bara löses upp i den globala tabellen är det klassiska frontdörrsfelet och det visar sig som en IKE-förhandling som aldrig startar.

Kontrollera även gränssnittstilldelningen. Det dokumenterade beteendet kräver att tunnelns frontdörrs-VRF och WAN-gränssnittets VRF stämmer överens; en avvikelse kan låta ett paket gå ut och ändå hindra att svaret behandlas i rätt kontext.

Bekräfta det inre uppslaget för servern

När frontdörren är bevisad, byt till kundens kontext och ställ samma fråga om serverns prefix. Detta uppslag avgör om ett dekapsulerat paket kan vidarebefordras.

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

Det första kommandot visar den inre rutten och det andra visar sessionens tillstånd tillsammans med de kontexter som plattformen kopplade till den. Om rutten finns men sessionsdetaljerna anger fel inre kontext vidarebefordrar tunneln till en tabell som inte känner till kundens prefix.

En rutt i den globala tabellen är inte bevis för något av de två uppslagen. Globala rutter används när ett paket inte är kopplat till en VRF, och ett tunnelgränssnitt som tilldelats en kundkontext ändrar den kopplingen. Om den inre rutten saknas dekapsuleras paketet och släpps sedan på grund av att det saknas en vidarebefordringspost, vilket ser ut som paketförlust och inte som ett routingfel.

Placera inställningen där modellen förväntar sig den

Samma dokumentation skiljer mellan konfigurationsmodeller, och en inställning som hör till den ena hör inte nödvändigtvis till den andra. För tunnelgränssnitt som använder tunnelskydd definieras den inre VRF:en på tunnelgränssnittet. För crypto map-baserade konstruktioner är den inre VRF:en en del av crypto map-posten. Att flytta ett liknande kommando mellan modeller utan att kontrollera dess roll är hur en fungerande konstruktion blir periodiskt instabil.

Routing och identitet är separata frågor. Nåbarhet ersätter aldrig en peer-profil som enheten accepterar, och ett byte av VRF-namn får inte ändra de uppgifter som erbjuds. Kontrollera båda efter varje ändring, eftersom en tunnel som förhandlar med fel profil fortfarande kan bilda en association och inte vidarebefordra något.

Slutligen, registrera de fyra fakta och de kommandon som bevisade dem i ändringsloggen. Nästa ingenjör ärver tunneln och inte resonemanget, och en kort anteckning som namnger båda kontexterna är värd mer än ett diagram som ingen uppdaterar.