Sesión BGP activa, camiño do cliente roto: MPLS sobre DMVPN

A sesión de peering leva semanas activa, o reconto de prefixos parece correcto e, aínda así, o tráfico dun cliente segue collendo o camiño longo ou nunca chega. Dúas cousas distintas están a ser xulgadas co mesmo indicador. Unha sesión BGP informa de que dous peers poden intercambiar mensaxes por unha conexión TCP; non di nada sobre se o overlay pode transportar un paquete etiquetado para ese cliente concreto.

Esa fenda vese máis facilmente nun deseño MPLS sobre DMVPN, onde o camiño polo hub e o camiño directo polo spoke poden comportarse de forma distinta por motivos que nada teñen que ver co peering.

Que demostra realmente a sesión

BGP funciona sobre TCP, así que cada peer necesita unha ruta cara ao enderezo do outro extremo antes de que ocorra calquera outra cousa. Se escolle un loopback como ese extremo, creou un requisito de alcanzabilidade, non unha garantía de reenvío. A sesión pode entón manterse activa por unha interface que o tráfico do cliente nunca usaría.

Anote catro feitos nos dous extremos antes de sacar conclusións: o enderezo de orixe da sesión, o seu enderezo de destino, o contexto de encamiñamento no que se atopa e que interface escollería o núcleo ou o router para ese par. Eses feitos describen o plano de control. Os paquetes do cliente engaden por riba un VRF, unha pila de etiquetas e un mapeo de overlay.

Catro mecanismos, non un

A documentación de Cisco sobre MPLS sobre DMVPN separa as pezas con claridade. MP-BGP distribúe as etiquetas de overlay do cliente entre os dispositivos da borde do provedor. MPLS usa esas etiquetas para seleccionar o contexto de reenvío dun paquete. NHRP mapea un enderezo de overlay ao extremo de transporte que necesita un túnel dinámico. IPsec protexe o camiño entre peers onde corresponde.

Calquera dos catro pode estar ben mentres outro está mal, e a combinación é o que transporta o tráfico. Un intercambio de rutas pode completarse mentres falta a vinculación de etiqueta para un VRF, mentres o mapeo NHRP apunta a un enderezo de transporte obsoleto ou mentres o túnel existe pero ningunha política permite o paquete interno. Ningunha desas condicións bota abaixo a sesión.

Compare o camiño polo hub co atallo, unha variable cada vez

Fixe o host de orixe, o host de destino e o VRF, e despois siga o mesmo fluxo dúas veces. No camiño polo hub, anote o seguinte salto, a etiqueta de servizo que identifica o contexto do cliente remoto e o mapeo de overlay a transporte en uso. No camiño directo previsto, anote as mesmas tres cousas. A diferenza entre as dúas listas é a falla, ou a súa ausencia.

Manteña o fluxo constante durante a comparación. Cambiar o host de orixe, o VRF ou o destino entre observacións produce dúas historias sen relación, e é a forma máis habitual de que este exercicio saia mal.

Manteña as probas de loopback no seu propio compartimento

Un ping con orixe no loopback dun router é unha proba útil e exercita un caso distinto do dun fluxo desde un host. O enderezo de orixe pertence ao router, o seu contexto de encamiñamento pode ser global en lugar dun VRF, e o camiño de resposta pode diferir do que collería un prefixo de cliente. Así que o loopback que responde e a aplicación que funciona polo atallo son resultados separados, e só o segundo describe o cliente.

Probe os dous e etiquéteos por separado nas notas. Cando non coinciden, aprendeu algo concreto sobre onde diverxe o deseño, e iso é máis do que lle dirá xamais unha soa marca verde.

As afirmacións sobre versións e sobre defectos necesitan a súa propia evidencia

Os informes de campo ás veces recomiendan cambiar unha máscara de host ou un enderezo de orixe de BGP, e eses informes só paga a pena lelos xunto ao defecto sobre o que se escribiron e ás versións afectadas. Unha solución temporal dunha versión non é unha afirmación de que a arquitectura non admita ningún prefixo /32.

Use documentación que coincida coa súa fase de DMVPN, plataforma e versión, e lembre que un capítulo pode cubrir varias disposicións, incluída FlexVPN. Un exemplo dunha disposición non se traslada en silencio a outra. Escolla os extremos de sesión para o deseño do plano de control que realmente necesita e despois verifique por separado o camiño de reenvío do cliente, porque reescribir cada máscara de loopback non substitúe o descubrir que tarefa fallou.