Resumo

  • O D-PATH, atributo BGP opcional e transitivo de código 36, carrega sequências de DOMAIN-ID nas interconexões EVPN/IPVPN para as quais o RFC 10039 foi configurado.
  • A sequência permite reconhecer o retorno de uma rota ao próprio domínio e, depois de Local Preference, preferir o D-PATH mais curto; ela não autentica os domínios nem observa pacotes.
  • A operação precisa manter quatro trilhas de evidência: identidade configurada, atributos na fronteira, realização em RIB/FIB e entrega bidirecional no ambiente do cliente.

Um novo dado no BGP não encerra o incidente

Uma rota chega ao domínio de destino com uma sequência D-PATH plausível. Nenhum identificador se repete, a política a aceita e o processo de seleção escolhe o anúncio. A equipe vê uma história limpa no controle enquanto o cliente vê perda no serviço.

As duas observações podem ser verdadeiras ao mesmo tempo. O D-PATH descreve o que a atualização BGP declara ter atravessado. Ele não é uma sonda do plano de dados. Seu ganho é tornar o domínio uma unidade explícita de detecção de loop; seu limite é não falar pelas etapas posteriores.

A identidade que o protocolo não descobre

Cada segmento D-PATH relaciona um tipo de família de serviço a uma lista de DOMAIN-IDs. Ao exportar uma rota para outro domínio, o gateway acrescenta a identidade do domínio que representa. Se o receptor encontra sua própria identidade na lista, pode reconhecer um loop de domínio.

O padrão exige que todos os gateways do mesmo domínio compartilhem um DOMAIN-ID e que domínios diferentes usem valores diferentes. Porém, o identificador é opaco e administrado. O protocolo não descobre a associação organizacional dos equipamentos nem arbitra a unicidade entre fronteiras independentes.

Uma migração com metade dos gateways usando a identidade antiga e metade usando a nova pode fazer um único domínio parecer dois. Uma colisão entre domínios distintos pode produzir um falso loop. Em ambos os casos, o D-PATH representa fielmente valores incorretos. A autoridade sobre essa verdade permanece no inventário e na configuração revisada.

A propagação depende do contrato da fronteira

Ser optional transitive permite que o atributo atravesse um falante BGP que não o compreende. Isso favorece a continuidade, mas não cria integridade criptográfica. Uma política pode removê-lo, um software pode codificá-lo incorretamente e um limite operacional pode adotar um modelo que não o propaga.

No modelo No Propagate, o D-PATH não segue para o outro domínio. No Uniform Model, a sequência pode ser preservada e ampliada ao longo do caminho. A ausência do atributo só é uma anomalia quando a fronteira deveria preservá-lo. Sua presença, por outro lado, não prova que route targets, rótulos, VNIs e demais informações de serviço também chegaram intactos.

O RFC 10039 manda tratar um D-PATH malformado como retirada. O treat-as-withdraw impede que conteúdo inválido participe do roteamento, mas pode transformar uma incompatibilidade de versão em desaparecimento de muitas rotas. Uma implantação deve medir as retiradas e capturar as atualizações reais, não apenas conferir a opção de recurso na interface.

Menos domínios não significa melhor serviço

Depois de Local Preference, o processo de melhor caminho pode comparar a quantidade de DOMAIN-IDs e preferir a menor. Um anúncio sem D-PATH conta como comprimento zero nessa etapa. A ordem é importante: a política local continua tendo precedência, e uma rota mais longa pode vencer se tiver Local Preference superior.

O número também não mede distância física, latência, capacidade ou risco. Mesmo a rota escolhida pode não chegar à FIB. Se chegar, ainda pode apontar para next-hop sem resolução, rótulo incorreto, VNI errado ou túnel indisponível. Uma ACL específica do cliente pode derrubar os pacotes após toda a cadeia de controle parecer coerente.

Por isso, “caminho escolhido” e “entrega realizada” precisam permanecer como resultados distintos em relatórios e painéis.

O método de verificação em quatro estações

Na primeira estação, a equipe extrai DOMAIN-IDs de todos os gateways, compara equipamentos do mesmo domínio e procura colisões entre domínios. A evidência deve incluir a versão de configuração efetivamente carregada.

Na segunda, compara atualizações de entrada e saída em cada fronteira. A sequência D-PATH, o tipo de família de serviço e os atributos necessários ao VPN são observados juntos. A captura dos dois lados localiza a fronteira que alterou a informação.

Na terceira, acompanha a rota recebida até a escolha na RIB e a programação na FIB. Next-hop, rótulo, VNI e estado do túnel são validados no equipamento que encaminhará o tráfego.

Na quarta, executa uma prova de ida e volta a partir do VRF ou contexto de isolamento do cliente. Um teste originado na rede de gestão não substitui essa etapa. Só a última estação consegue afirmar que o serviço foi entregue.