Resumo

  • A RFC 10039 define domínio pelo encaminhamento do tráfego do tenant. Um ASN, uma instância IGP, um data center ou uma divisão empresarial podem coincidir com essa fronteira, mas não a determinam.
  • O DOMAIN-ID deixa de ser simples documentação quando entra no D-PATH: a coincidência com um ID local sinaliza loop, e o comprimento do atributo participa da escolha do melhor caminho.

Uma equipe configurou os dois gateways redundantes na mesma janela. No primeiro, o domínio correspondia a toda a interconexão. No segundo, cada IP-VRF de tenant ganhou um identificador próprio. Os comandos foram aceitos, as sessões BGP permaneceram estabelecidas e nenhum alarme de sintaxe apareceu. Ainda assim, uma rota que voltasse pelo par seria comparada com duas definições incompatíveis.

O problema começou antes da configuração. Faltava um acordo sobre o objeto que o ID nomeava.

A RFC 10039 especifica a interconexão entre domínios EVPN e IPVPN para encaminhamento entre sub-redes de tenants. Um PE de interworking recebe uma rota de um domínio, importa-a em uma IP-VRF e a origina novamente com a família e os atributos adequados ao domínio vizinho. Quando há mais de um gateway, uma rota convertida de IPVPN para EVPN pode ser devolvida por outro gateway ao domínio IPVPN, formando um loop de controle.

O novo atributo Domain Path registra por onde a rota passou. Sua utilidade, porém, depende de todos lerem a mesma legenda.

O teste é de encaminhamento, não de organograma

Dois PEs pertencem ao mesmo domínio quando atendem ao mesmo tenant e os pacotes entre eles não exigem uma consulta IP no espaço do tenant em um roteador de trânsito. A necessidade dessa consulta marca uma fronteira conectada por um gateway.

A consequência é expressa na própria RFC: a fronteira não se limita a um Sistema Autônomo nem a uma instância IGP. Um domínio pode atravessar ASes; um AS pode conter vários domínios. O nome do site, o fabricante do fabric ou a responsabilidade de uma equipe são descrições úteis, mas não substituem o teste do caminho de dados.

O formato do DOMAIN-ID pode sugerir uma autoridade que ele não possui. São seis octetos: quatro para Global Administrator e dois para Local Administrator. A parte global pode usar um ASN público ou privado, um endereço IPv4 ou outro valor. Essa escolha facilita a unicidade e a investigação. Não transforma o ID em prova de que o domínio é aquele AS, nem em autenticação do titular de um endereço.

As obrigações de consistência são rigorosas. Cada domínio deve ter um ID único; todos os gateways ligados ao mesmo domínio devem usar o mesmo valor; um gateway entre dois domínios usa dois valores distintos. O escopo pode ser toda a interconexão ou uma IP-VRF específica. Em cenários de route leaking entre VRFs, o contexto do ID local é parte do resultado, e não uma opção de apresentação.

Um nome passa a decidir

D-PATH é um atributo BGP opcional e transitivo, registrado pela IANA sob o código 36. Cada entrada junta o DOMAIN-ID a um ISF_SAFI_TYPE, indicando EVPN, IPVPN ou outra situação prevista. O tipo SAFI ajuda a verificar a sequência de interworking, mas não altera o teste de loop.

Se uma rota recebida contém no D-PATH qualquer DOMAIN-ID configurado localmente para a IP-VRF, o gateway a reconhece como passagem de volta pelo domínio, independentemente do tipo SAFI associado. A regra impede que uma mudança de família esconda o retorno. Também faz uma colisão parecer um loop real.

Dois domínios diferentes com o mesmo ID podem bloquear uma rota legítima. Dois gateways do mesmo domínio com IDs diferentes podem não bloquear uma rota que voltou. Um vínculo na VRF errada pode comparar a rota com um mapa que só existe no documento de mudança.

O atributo ainda participa da seleção. Para candidatos EVPN e não EVPN do mesmo prefixo, o procedimento compara LOCAL_PREF e depois remove os caminhos que não tenham o D-PATH mais curto. A ausência do atributo conta como comprimento zero. Essa quantidade não mede latência, distância física, congestão, preço ou confiabilidade. Ela conta fronteiras declaradas, mas pode determinar o próximo salto vencedor.

Logo, exibir D-PATH no CLI comprova a presença de uma afirmação, não sua exatidão. O efeito precisa ser seguido da Adj-RIB-In até a FIB e o pacote.

Preservar contexto também amplia exposição

O atributo é desativado por padrão e só pode acompanhar rotas IPVPN ou EVPN. Ao reoriginar uma rota, o gateway adota uma de duas políticas.

No Propagation Mode é o padrão. Os atributos BGP são reinicializados na fronteira, como se o prefixo fosse local, e o D-PATH não segue adiante. Isso reduz o estado herdado por outro domínio, mas pode deixar gateways redundantes expostos a loops. Políticas e comunidades de origem ajudam em alguns cenários sem oferecer a mesma cobertura em todos.

Uniform Propagation Mode conserva um conjunto estreito de atributos: AS_PATH, D-PATH quando aplicável e alguns atributos internos em sessões iBGP. Qualquer outro deve depender de autorização explícita de importação ou exportação. O modo preserva uma história útil para decisão e diagnóstico, mas permite que informações sintaticamente válidas e semanticamente inadequadas influenciem domínios remotos.

A escolha não é uma disputa abstrata entre segurança e visibilidade. Em cada fronteira, o operador precisa declarar quais evidências serão mantidas, quais riscos serão isolados, qual lista de atributos é válida e quem aprova uma exceção. “Habilitar D-PATH” não descreve essa política.

Validade sintática não resolve divergência semântica

Uma estrutura malformada recebe tratamento definido. Segmentos impossíveis, comprimento insuficiente ou D-PATH em AFI/SAFI não permitido acionam treat-as-withdraw, conforme a RFC 7606. Um valor SAFI desconhecido pode ser aceito. Quando aparecem várias cópias do atributo no mesmo UPDATE, preserva-se a primeira e descartam-se as demais.

Essas proteções contêm bytes defeituosos. Não detectam um ID bem formado e atribuído ao domínio errado. A RFC 10039 adverte que DOMAIN-ID incorreto ou suporte inconsistente pode causar falso positivo de loop, descarte de tráfego e roteamento subótimo ou divergente. Como o atributo é transitivo, um agente malicioso também pode tentar propagar uma história de domínio falsa.

O limite com o cliente requer teste específico. D-PATH deve permanecer no “jardim murado” das VPNs. Um PE conforme o remove antes de anunciar o prefixo a um CE como unicast SAFI 1. Equipamentos atualizados também devem considerar política local para rotas com D-PATH vindas de peers classificados como não atualizados. A RFC não diz como provar essa classificação; a versão e o comportamento precisam ser inventariados.

O artefato correto é um acordo de fronteira

Para cada tenant e interconexão, o acordo deve começar com a prova de encaminhamento que define os domínios. Em seguida registra o responsável pela alocação, o escopo de unicidade, a busca por colisões, todos os gateways envolvidos e o vínculo exato em interfaces e IP-VRFs. Se a notação usar um ASN ou endereço, o documento separa conveniência de significado.

O recibo de implantação acrescenta versão de software, suporte testado, modo de propagação em cada limite, lista de atributos, regra para rotas locais, janela de observação, limiar de abortar e caminho independente de rollback. O comportamento esperado para um prefixo deve estar descrito salto a salto antes da alteração.

Os testes precisam desafiar a decisão: uma rota legítima percorre a sequência prevista; outra recebe um ID local e ativa a proteção; um SAFI desconhecido não impede a comparação; um atributo malformado é retirado de forma contida; um peer antigo revela como realmente trata o dado. Na saída CE, uma captura demonstra que D-PATH não aparece em SAFI 1.

O mesmo prefixo canário deve ligar RIB de entrada, conjunto de candidatos, melhor caminho, FIB e entrega de pacote. Uma sessão Established não prova suporte funcional. Uma configuração salva não prova identidade coerente. Um contador sem escopo não prova ausência de loop. O recibo só fecha quando a declaração comum produz o resultado esperado no código em execução.

RFC 4271 fornece o processo básico do BGP; RFC 4364, o contexto IPVPN; RFC 7432, RFC 9135 e RFC 9136, o contexto EVPN. Esses textos não atestam implementação de fornecedor, implantação de operador nem resultado de produção.

Fontes