Sessió BGP activa, camí del client trencat: MPLS sobre DMVPN

El peeratge fa setmanes que està actiu, el recompte de prefixos sembla correcte i, tot i així, el trànsit d'un client continua prenent el camí llarg o no arriba mai. S'estan jutjant dues coses diferents amb el mateix indicador. Una sessió BGP informa que dos peers poden intercanviar missatges per una connexió TCP; no diu res sobre si l'overlay pot transportar un paquet etiquetat per a aquell client concret.

Aquest buit es veu més fàcilment en un disseny MPLS sobre DMVPN, on el camí pel hub i el camí directe pel spoke poden comportar-se de manera diferent per motius que no tenen res a veure amb el peeratge.

Què demostra realment la sessió

BGP funciona sobre TCP, així que cada peer necessita una ruta cap a l'adreça de l'altre extrem abans que passi res més. Si trieu una loopback com a extrem, heu creat un requisit d'abastabilitat, no una garantia de reenviament. La sessió pot llavors mantenir-se activa per una interfície que el trànsit del client no faria servir mai.

Anoteu quatre fets als dos extrems abans de treure conclusions: l'adreça d'origen de la sessió, l'adreça de destinació, el context d'encaminament on se situa i quina interfície triaria el nucli o l'encaminador per a aquest parell. Aquests fets descriuen el pla de control. Els paquets del client hi afegeixen un VRF, una pila d'etiquetes i un mapatge d'overlay.

Quatre mecanismes, no un

La documentació de Cisco sobre MPLS sobre DMVPN separa les peces amb claredat. MP-BGP distribueix les etiquetes d'overlay del client entre els dispositius de la vora del proveïdor. MPLS fa servir aquestes etiquetes per seleccionar el context de reenviament d'un paquet. NHRP assigna una adreça d'overlay a l'extrem de transport que necessita un túnel dinàmic. IPsec protegeix el camí entre peers allà on s'aplica.

Qualsevol dels quatre pot ser correcte mentre un altre és incorrecte, i la combinació és el que transporta el trànsit. Un intercanvi de rutes pot completar-se mentre falta la vinculació d'etiqueta per a un VRF, mentre el mapatge NHRP apunta a una adreça de transport obsoleta o mentre el túnel existeix però cap política permet el paquet interior. Cap d'aquestes condicions fa caure la sessió.

Compareu el camí pel hub amb la drecera, una variable alhora

Fixeu l'host d'origen, l'host de destinació i el VRF, i després seguiu el mateix flux dues vegades. Al camí pel hub, anoteu el següent salt, l'etiqueta de servei que identifica el context del client remot i el mapatge d'overlay a transport en ús. Al camí directe previst, anoteu les mateixes tres coses. La diferència entre les dues llistes és la fallada, o bé la seva absència.

Mantingueu el flux constant durant la comparació. Canviar l'host d'origen, el VRF o la destinació entre observacions produeix dues històries sense relació, i és la manera més habitual que aquest exercici surti malament.

Mantingueu les proves de loopback en un compartiment propi

Un ping amb origen a la loopback d'un encaminador és una prova útil i exerceix un cas diferent del d'un flux des d'un host. L'adreça d'origen pertany a l'encaminador, el seu context d'encaminament pot ser global en lloc d'un VRF, i el camí de resposta pot diferir del que prendria un prefix de client. Per tant, la loopback que respon i l'aplicació que funciona per la drecera són resultats separats, i només el segon descriu el client.

Proveu tots dos i etiqueteu-los per separat a les notes. Quan no coincideixen, heu après alguna cosa concreta sobre on divergeix el disseny, i això és més del que us dirà mai una sola marca verda.

Les afirmacions sobre versions i sobre defectes necessiten proves pròpies

Els informes de camp de vegades recomanen canviar una màscara d'host o una adreça d'origen de BGP, i aquests informes només val la pena llegir-los al costat del defecte sobre el qual es van escriure i de les versions afectades. Una solució temporal d'una versió no és una afirmació que l'arquitectura no admeti cap prefix /32.

Feu servir documentació que coincideixi amb la vostra fase de DMVPN, plataforma i versió, i recordeu que un capítol pot cobrir diverses disposicions, inclosa FlexVPN. Un exemple d'una disposició no es trasllada en silenci a una altra. Trieu els extrems de sessió per al disseny del pla de control que realment necessiteu i després verifiqueu per separat el camí de reenviament del client, perquè reescriure cada màscara de loopback no substitueix l'esbrinar quina tasca ha fallat.