Sessão BGP ativa, caminho do cliente quebrado: MPLS sobre DMVPN

O peering está ativo há semanas, a contagem de prefixos parece correta e, mesmo assim, o tráfego de um cliente continua pegando o caminho longo ou nunca chega. Duas coisas diferentes estão sendo julgadas pelo mesmo indicador. Uma sessão BGP informa que dois peers conseguem trocar mensagens por uma conexão TCP; ela não diz nada sobre o overlay conseguir transportar um pacote rotulado para aquele cliente específico.

Essa lacuna é mais fácil de ver num projeto MPLS sobre DMVPN, onde o caminho pelo hub e o caminho direto pelo spoke podem se comportar de modo diferente por razões que nada têm a ver com o peering.

O que a sessão realmente prova

O BGP roda sobre TCP, então cada peer precisa de uma rota até o endereço da outra ponta antes que qualquer outra coisa aconteça. Escolha um loopback como essa ponta e você terá criado um requisito de alcançabilidade, não uma garantia de encaminhamento. A sessão pode então permanecer ativa por uma interface que o tráfego do cliente nunca usaria.

Anote quatro fatos nas duas pontas antes de concluir: o endereço de origem da sessão, o endereço de destino, o contexto de roteamento em que ela está e qual interface o kernel ou o roteador escolheria para esse par. Esses fatos descrevem o plano de controle. Os pacotes do cliente acrescentam sobre eles um VRF, uma pilha de rótulos e um mapeamento de overlay.

Quatro mecanismos, não um

A documentação da Cisco sobre MPLS sobre DMVPN separa as peças com clareza. O MP-BGP distribui os rótulos de overlay do cliente entre os equipamentos da borda do provedor. O MPLS usa esses rótulos para selecionar o contexto de encaminhamento de um pacote. O NHRP mapeia um endereço de overlay para a ponta de transporte de que um túnel dinâmico precisa. O IPsec protege o caminho entre os peers onde se aplica.

Qualquer um dos quatro pode estar certo enquanto outro está errado, e é a combinação que carrega o tráfego. Uma troca de rotas pode terminar enquanto falta o vínculo de rótulo para um VRF, enquanto o mapeamento NHRP aponta para um endereço de transporte obsoleto ou enquanto o túnel existe mas nenhuma política permite o pacote interno. Nenhuma dessas condições derruba a sessão.

Compare o caminho pelo hub com o atalho, uma variável por vez

Fixe o host de origem, o host de destino e o VRF, e depois siga o mesmo fluxo duas vezes. No caminho pelo hub, anote o próximo salto, o rótulo de serviço que identifica o contexto do cliente remoto e o mapeamento de overlay para transporte em uso. No caminho direto pretendido, anote as mesmas três coisas. A diferença entre as duas listas é a falha, ou a ausência dela.

Mantenha o fluxo constante durante a comparação. Mudar o host de origem, o VRF ou o destino entre observações produz duas histórias sem relação, e é a forma mais comum de este exercício dar errado.

Mantenha os testes de loopback no próprio compartimento

Um ping originado no loopback de um roteador é um teste útil e exercita um caso diferente de um fluxo a partir de um host. O endereço de origem pertence ao roteador, o contexto de roteamento pode ser global em vez de um VRF, e o caminho de resposta pode diferir do que um prefixo de cliente tomaria. Portanto, o loopback que responde e a aplicação que funciona pelo atalho são resultados separados, e só o segundo descreve o cliente.

Teste os dois e depois rotule-os separadamente nas suas notas. Quando discordam, você aprendeu algo concreto sobre onde o projeto diverge, e isso é mais do que uma única marca verde jamais dirá.

Afirmações sobre versões e sobre defeitos precisam da própria evidência

Relatos de campo às vezes recomendam mudar uma máscara de host ou um endereço de origem do BGP, e esses relatos só valem a leitura junto ao defeito sobre o qual foram escritos e às versões afetadas. Uma solução alternativa de uma versão não é a afirmação de que a arquitetura não suporta nenhum prefixo /32.

Use documentação que corresponda à sua fase de DMVPN, plataforma e versão, e lembre-se de que um capítulo pode cobrir várias disposições, incluindo FlexVPN. Um exemplo de uma disposição não se transfere em silêncio para outra. Escolha as pontas da sessão para o projeto do plano de controle de que você realmente precisa e depois verifique separadamente o caminho de encaminhamento do cliente, porque reescrever cada máscara de loopback não substitui descobrir qual tarefa falhou.