O laboratório MPLS L3VPN não faz ping? Verifique estes cinco saltos

Dois routers de cliente, um par de caixas provider edge e um ping que morre sem mensagem de erro. Num laboratório MPLS L3VPN pequeno, a falha fica quase sempre num dos cinco pontos de controlo, e cada um tem um comando que mostra se a dependência funciona ou se falta. O erro é reiniciar o BGP sempre que o ping falha em vez de testar as dependências por ordem. Se saltar diretamente para a configuração da VRF, pode gastar uma hora num problema que começou com um próximo salto não resolvido dois equipamentos adiante.

Trabalhe a lista de baixo para cima. Um ponto de controlo que passa fica aprovado, e a primeira falha é a que vale a pena depurar.

Ponto de controlo um: os PE alcançam-se uns aos outros

Cada PE precisa de uma rota para o loopback do outro PE, e essa rota tem de resolver através de algo real. Um interior gateway protocol é a via habitual, mas uma rota estática também serve desde que a pesquisa recursiva acabe numa adjacency viva. Em equipamentos 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 há uma adjacency resolvida por trás. Uma rota na tabela sem adjacency por trás não é alcançabilidade.

Verifique ambos os sentidos. Custo IGP assimétrico, uma passive interface no lado errado ou uma distribute list que filtra o loopback quebram cada um apenas um sentido, e um sentido basta para matar a sessão. Se os loopbacks respondem ao ping mas a sessão BGP fica em Active, olhe para a update source antes de mexer em mais nada.

Ponto de controlo dois: existe um caminho de etiquetas

Uma rota IP para o loopback remoto não prova que o transporte vá colocar uma etiqueta. Num desenho LDP, confirme que o loopback remoto tem uma binding local e uma remota, e que a etiqueta de saída aparece na tabela 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 vai realmente colocar. Quando o segundo comando não mostra nenhuma etiqueta ou recai em IP, o transporte não leva o tráfego VPN como o desenho pressupõe.

A distinção vem de como o MPLS separa o estado de forwarding dos prefixos de destino, o modelo descrito na RFC 3031. Se o seu laboratório usa RSVP-TE ou etiquetas adjacentes ao BGP em vez de LDP, verifique o estado próprio desse mecanismo; assumir que o LDP distribui todas as etiquetas da camada inferior é uma forma comum de perseguir um bug fantasma. Um caminho de etiquetas quebrado costuma aparecer mais tarde como uma rota VPN presente mas inutilizável.

Ponto de controlo três: a rota VPN chegou intacta

Veja a rota VPNv4 ou VPNv6 do prefixo de cliente exato, não o resumo da sessão. show bgp vpnv4 unicast all 10.10.1.0/24 deve mostrar o route distinguisher, o next hop definido para o loopback do PE remoto e uma etiqueta. Se o prefixo faltar, a política de exportação no PE de origem ou a política de importação no PE recetor é o primeiro suspeito, e as route targets são o culpado habitual.

Leia a verificação de route target separadamente da receção BGP. Uma rota pode chegar com o next hop certo e ainda assim não aterrar na VRF porque o import target não corresponde. No PE recetor, show ip route vrf CUSTOMER 10.10.1.0 é o teste que importa; a tabela BGP apenas prova que a rota atravessou o plano de controlo.

Ponto de controlo quatro: a interface está na VRF

Uma definição de VRF com um route distinguisher e route targets não move nenhuma interface para dentro dela. A interface do lado CE precisa da atribuição de VRF, e show ip vrf interfaces ou show ip interface brief deve listá-la sob a instância correta. Este é o ponto de controlo onde uma configuração copiada falha mais vezes, porque o bloco VRF parece completo enquanto a interface continua na tabela global.

Depois confirme que o PE aprendeu o prefixo de cliente local nessa VRF, e que o CE tem uma rota de volta pelo enlace. Uma default estática no CE a apontar para o PE chega para um laboratório, desde que a VRF do PE tenha uma rota para a LAN do CE. Se faltar qualquer das duas metades, o ping falha antes de qualquer etiqueta ser colocada.

Ponto de controlo cinco: a resposta encontra o caminho de casa

Siga o pacote de ida e depois o de volta, porque usam tabelas diferentes. No PE de entrada, a origem do cliente deve resolver dentro da VRF para o prefixo remoto com a etiqueta remota. No PE de saída, o destino deve resolver dentro da mesma VRF para a interface do lado CE. Um ping lançado a partir do próprio PE não é prova: pode sair pela tabela global ou por outro endereço de origem, e é por isso que ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 é o teste a executar.

As firewalls dos anfitriões, o reverse-path filtering e as listas de acesso do CE continuam a aplicar-se. Se o caminho de ida funciona e a resposta morre, o problema está numa rota ou num filtro do lado de volta, não no transporte MPLS.

Mantenha uma linha por ponto de controlo a nomear a primeira dependência que falhou. Essa linha transforma a queixa de que o cliente não consegue fazer ping numa pergunta concreta sobre alcançabilidade, estado das etiquetas, importação de rotas, pertença da interface ou caminho de volta, e impede que a sessão de depuração seguinte repita os mesmos cinco comandos na mesma ordem.