Welke VRF bereikt de VPN-peer en welke draagt het pakket?

Elke tunnel binnen een routingcontext van een klant moet nog steeds zijn externe peer bereiken, en die lookup kan in een heel andere tabel plaatsvinden. Dit verkeerd doen levert een van de meest verwarrende storingen in VRF-bewuste IPsec op: de tunnel komt op, de routes lijken aanwezig en het verkeer sterft omdat een van de twee lookups de verkeerde context gebruikte. Voer de vier stappen hieronder in volgorde uit en houd de twee bestemmingen apart opgeschreven.

Twee lookups, één tunnel

Het buitenste ingekapselde pakket is gericht aan het transportadres van de peer en wordt gerouteerd voordat er enige bescherming bestaat. Het binnenste pakket is gericht aan een klantserver en wordt na decapsulatie gerouteerd, binnen de context van de klant. Dat zijn twee bestemmingen, twee lookups en vaak twee verschillende tabellen.

De documentatie van Cisco voor VRF-bewuste IPsec noemt ze de voordeur-VRF en de binnen-VRF. De voordeur draagt het versleutelde transport en de binnencontext draagt het beschermde verkeer. Niets aan het vernoemen van een tunnel naar een klant laat een van beide routes verschijnen.

Noem dus vier feiten voordat u een configuratie wijzigt: het transportadres van de peer en de context die het bereikt, dan het prefix van de server en de context die dat bereikt. Als u niet alle vier kunt invullen, staat u op het punt te gokken. Gokken op dit gebied is duur, want een route die in de verkeerde tabel wordt toegevoegd kan de ene stroom laten werken terwijl hij een andere stil kapotmaakt. De vier feiten kosten tien minuten om te verzamelen en besparen een dag aan capture-analyse.

Bevestig de transportlookup voor de peer

Begin bij de voordeur, want een tunnel die zijn peer niet kan bereiken zal nooit één beschermd pakket doorlaten. Vraag op IOS de route naar de peer binnen de transport-VRF op in plaats van in de globale tabel.

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

Het eerste commando beantwoordt of het peeradres in die context bereikbaar is, het tweede somt de VRF's op die werkelijk bestaan, en het derde toont of er een beveiligingsassociatie is gevormd. Een peeradres dat alleen in de globale tabel wordt opgelost is de klassieke voordeurfout, en die uit zich als een IKE-onderhandeling die nooit begint.

Controleer ook de interfacetoewijzing. Het gedocumenteerde gedrag vereist dat de voordeur-VRF van de tunnel en de VRF van de WAN-interface overeenkomen; een mismatch kan een pakket laten vertrekken en toch verhinderen dat het antwoord in de juiste context wordt verwerkt.

Bevestig de binnenlookup voor de server

Als de voordeur bewezen is, schakel over naar de context van de klant en stel dezelfde vraag over het prefix van de server. Deze lookup bepaalt of een gedecapsuleerd pakket verder kan worden doorgestuurd.

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

Het eerste commando toont de binnenroute, en het tweede toont de sessietoestand samen met de contexten die het platform eraan heeft gekoppeld. Als de route bestaat maar de sessiedetails de verkeerde binnencontext noemen, stuurt de tunnel door naar een tabel die het prefix van de klant niet kent.

Een route in de globale tabel is geen bewijs voor een van beide lookups. Globale routes worden gebruikt wanneer een pakket niet aan een VRF is gekoppeld, en een tunnelinterface die aan een klantcontext is toegewezen verandert die koppeling. Als de binnenroute ontbreekt, wordt het pakket gedecapsuleerd en vervolgens weggegooid wegens het ontbreken van een doorstuurvermelding, wat op pakketverlies lijkt en niet op een routingfout.

Plaats de instelling waar het model hem verwacht

Dezelfde documentatie onderscheidt configuratiemodellen, en een instelling die bij het ene hoort hoort niet noodzakelijk bij het andere. Voor tunnelinterfaces met tunnelbescherming wordt de binnen-VRF op de tunnelinterface gedefinieerd. Voor op crypto map gebaseerde ontwerpen maakt de binnen-VRF deel uit van de crypto map-vermelding. Een vergelijkbaar genoemd commando tussen modellen verplaatsen zonder de rol te controleren is hoe een werkend ontwerp onregelmatig wordt.

Routing en identiteit zijn gescheiden zaken. Bereikbaarheid vervangt nooit een peerprofiel dat het apparaat accepteert, en een VRF-hernoeming mag de aangeboden inloggegevens niet wijzigen. Controleer beide na elke wijziging, want een tunnel die met het verkeerde profiel onderhandelt kan nog steeds een associatie vormen en niets doorsturen.

Ten slotte legt u de vier feiten en de commando's die ze bewezen vast in het wijzigingslog. De volgende engineer erft de tunnel en niet de redenering, en een korte notitie die beide contexten noemt is meer waard dan een diagram dat niemand bijwerkt.