O laboratorio MPLS L3VPN non fai ping? Comprobe estes cinco saltos

Dous routers de cliente, un par de caixas provider edge e un ping que morre sen mensaxe de erro. Nun laboratorio MPLS L3VPN pequeno, o fallo case sempre se senta nun dos cinco puntos de control, e cada un ten un comando que mostra se a dependencia funciona ou se falta. O erro é reiniciar BGP cada vez que falla o ping en lugar de probar as dependencias en orde. Se salta directamente á configuración da VRF, pode pasar unha hora nun problema que comezou cun seguinte salto sen resolver dous equipos máis aló.

Traballa a lista de abaixo cara arriba. Un punto de control que pasa queda aprobado, e o primeiro fallo é o que paga a pena depurar.

Punto de control un: os PE alcanzan uns aos outros

Cada PE necesita unha ruta cara ao loopback do outro PE, e esa ruta debe resolverse a través de algo real. Un interior gateway protocol é a vía habitual, pero unha ruta estática tamén serve sempre que a busca recursiva acabe nunha adjacency viva. En equipos de estilo IOS, show ip route 10.0.0.2 seguido de show ip cef 10.0.0.2 indica se o prefixo existe e se hai unha adjacency resolta detrás. Unha ruta na táboa sen adjacency detrás non é alcanzabilidade.

Comprobe ambos os sentidos. Costes IGP asimétricos, unha passive interface no lado equivocado ou unha distribute list que filtra o loopback rompen cada un só un sentido, e un sentido abonda para matar a sesión. Se os loopbacks responden ao ping pero a sesión BGP queda en Active, mire a update source antes de tocar nada máis.

Punto de control dous: existe un camiño de etiquetas

Unha ruta IP cara ao loopback remoto non demostra que o transporte vaia poñer unha etiqueta. Nun deseño LDP, confirme que o loopback remoto ten unha binding local e unha remota, e que a etiqueta de saída aparece na táboa de forwarding. show mpls ldp bindings 10.0.0.2 32 mostra os pares de etiquetas, e show mpls forwarding-table 10.0.0.2 mostra o que a line card poñerá realmente. Cando o segundo comando non mostra ningunha etiqueta ou recae en IP, o transporte non leva o tráfico VPN como supón o deseño.

A distinción vén de como MPLS separa o estado de forwarding dos prefixos de destino, o modelo que se describe na RFC 3031. Se o seu laboratorio usa RSVP-TE ou etiquetas adxacentes a BGP en lugar de LDP, comprobe o estado propio dese mecanismo; supoñer que LDP distribúe cada etiqueta da capa inferior é unha forma habitual de perseguir un fallo pantasma. Un camiño de etiquetas roto adoita aparecer máis tarde como unha ruta VPN presente pero inutilizable.

Punto de control tres: a ruta VPN chegou intacta

Mire a ruta VPNv4 ou VPNv6 do prefixo de cliente exacto, non o resumo de sesión. show bgp vpnv4 unicast all 10.10.1.0/24 debería mostrar o route distinguisher, o next hop axustado ao loopback do PE remoto e unha etiqueta. Se falta o prefixo, a política de exportación no PE de orixe ou a política de importación no PE receptor é o primeiro sospeitoso, e as route targets son o culpable habitual.

Lea a comprobación de route target por separado da recepción BGP. Unha ruta pode chegar co next hop correcto e non aterrar na VRF porque o import target non coincide. No PE receptor, show ip route vrf CUSTOMER 10.10.1.0 é a proba que importa; a táboa BGP só demostra que a ruta cruzou o plano de control.

Punto de control catro: a interface está na VRF

Unha definición de VRF cun route distinguisher e route targets non move ningunha interface dentro. A interface do lado CE necesita a asignación de VRF, e show ip vrf interfaces ou show ip interface brief debería listala baixo a instancia correcta. Este é o punto de control onde unha configuración copiada falla máis a miúdo, porque o bloque VRF parece completo mentres a interface segue na táboa global.

Despois confirme que o PE aprendeu o prefixo de cliente local nesa VRF, e que o CE ten unha ruta de volta polo enlace. Unha default estática no CE apuntando ao PE abonda para un laboratorio, sempre que a VRF do PE teña unha ruta cara á LAN do CE. Se falta calquera das dúas metades, o ping falla antes de que se poña ningunha etiqueta.

Punto de control cinco: a resposta atopa o camiño de casa

Rastree o paquete de ida e logo o de volta, porque usan táboas distintas. No PE de entrada, a orixe do cliente debe resolverse dentro da VRF cara ao prefixo remoto coa etiqueta remota. No PE de saída, o destino debe resolverse dentro da mesma VRF cara á interface do lado CE. Un ping lanzado desde o propio PE non é proba: pode saír pola táboa global ou por outro enderezo de orixe, e por iso ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 é a proba que hai que executar.

Os cortalumes dos hosts, o reverse-path filtering e as listas de acceso do CE seguen aplicándose. Se o camiño de ida funciona e a resposta morre, o problema é unha ruta ou un filtro no lado de volta, non o transporte MPLS.

Manteña unha liña por punto de control coa primeira dependencia que fallou. Esa liña converte a queixa de que o cliente non pode facer ping nunha pregunta concreta sobre alcanzabilidade, estado de etiquetas, importación de rutas, pertenza de interface ou camiño de volta, e evita que a seguinte sesión de depuración repita os mesmos cinco comandos na mesma orde.