Por que um único tenant EVPN pode mostrar vários route distinguishers
Dois RD no mesmo tenant não são um conflito. Percorra da saída da CLI até o MAC-VRF ou o IP-VRF que originou a rota e depois verifique a importação de RT e o VNI.
Você filtra a tabela EVPN para um único tenant, e as rotas carregam dois route distinguishers diferentes. O primeiro instinto é um conflito de configuração, e esse instinto costuma estar errado. O nome do tenant é um rótulo de negócio, não um objeto único do plano de controle, então o contexto de bridge e o contexto de roteamento dentro dele podem anunciar legitimamente sob identificadores separados. Percorra uma rota de cada vez da saída até o objeto de serviço local que a originou, e o segundo RD deixa de parecer um erro.
Comece pela saída que o confundiu
Escolha uma rota em vez da tabela inteira. Anote o tipo de rota, o RD, os route targets exportados e o próximo salto. Esses quatro campos bastam para identificar qual objeto local a anunciou e qual política remota deveria importá-la.
Em um dispositivo no estilo NX-OS, a visão detalhada é obtida com show bgp l2vpn evpn route-type 2 detail ou show bgp l2vpn evpn route-type 5 detail. No Junos, as mesmas informações estão em show route table bgp.evpn.0 detail. Sintaxe diferente, os mesmos campos.
Não comece tornando iguais todos os números exibidos. Igualar os RD é a mudança que quebra a política de importação em um fabric que funciona.
Dê a cada identificador o seu trabalho
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
Um MAC-VRF mantém informações de encaminhamento MAC para um serviço de bridge. Um IP-VRF fornece um contexto de roteamento IP para um serviço roteado. Um tenant pode incluir ambos, por isso um único tenant pode produzir mais de um RD sem nenhum erro de configuração.
O RFC 7432 atribui o RD do MAC-VRF anunciante ao seu EVPN NLRI e exige RDs distintos entre MAC-VRFs no mesmo PE. Os procedimentos de route-target são separados: permitem um ou mais atributos RT e dependem da política de importação para a associação. A igualdade de RD não é o que cria associação compartilhada, e tratá-la assim é a raiz desta confusão.
Percorra uma rota do anúncio à importação
Siga a rota em uma direção. Confirme o tipo de rota, o serviço que a originou, o RD, os RTs exportados e depois a política de importação no PE que a recebe. Cada passo responde a uma pergunta diferente, e uma falha em qualquer passo parece o mesmo prefixo ausente do outro lado.
Depois que a rota existe, inspecione o contexto de encaminhamento instalado e o mapeamento de VNI. Um VNI igual nas duas pontas demonstra que o plano de dados concorda; não demonstra que o plano de controle importou a rota pela política pretendida.
Se a rota aparece no PE remoto mas não há tráfego, o problema passou do EVPN. Verifique a ligação VNI-VLAN ou VNI-VRF e o caminho de underlay antes de editar route targets novamente. Comece pelo mapeamento, depois o underlay e só então o plano de controle. Reverter uma mudança de route-target para perseguir uma falha do plano de dados é uma forma confiável de quebrar uma importação que funciona.
Os prefixos de camada 3 continuam sendo rotas EVPN
Um prefixo IP na tabela EVPN não é BGP IPv4-unicast comum. A rota EVPN IP Prefix é um tipo de rota próprio, e os anúncios de MAC/IP e de prefixo IP viajam na família de endereços EVPN, que o RFC 7432 identifica como AFI 25 e SAFI 70.
Essa distinção importa quando você compara uma rota da tabela EVPN com uma da tabela unicast. Elas podem descrever o mesmo destino e ainda assim serem produzidas, filtradas e importadas por políticas diferentes. Ler uma como prova sobre a outra é o que faz um fabric correto parecer quebrado durante uma migração.
Verifique a derivação do fornecedor antes de comparar números
O RFC 9136 estende o EVPN com rotas IP Prefix e especifica se o RD aplicável vem do contexto MAC-VRF ou IP-VRF. Por isso um rótulo de serviço L2 e um rótulo de serviço roteado na mesma saída devem ser lidos em relação aos objetos a que pertencem, não reduzidos a um RD por tenant.
A derivação automática de RD e RT depende do fornecedor. Leia a referência do fornecedor implantado para a fórmula em uso; um valor gerado automaticamente visto em um único switch não é uma codificação universal, e comparar os números de dois fornecedores raramente prova algo.
Termine com um rastro escrito para a rota com que você começou: tipo, objeto de origem, RD, RT exportado, política de importação, VNI instalado. Seis campos explicam o anúncio a quem ler o chamado em seguida, e nenhum deles exige que os números do tenant coincidam.