Resumo

  • O exemplo de um Internet-Draft de 27 de outubro põe quatro rotas com o prefixo P1 diante do PE1. Ele escolhe a de RD22 para VPN11. O relatório BMP entregue ao monitor identifica RD11, a instância que recebeu a rota, mas deixa RD22 para trás.
  • A revisão 02 propõe levar a identidade da VRF remota também em uma importação EVPN Type-5. Enviar esse dado e aproveitá-lo no coletor continuam sendo escolhas. Quem opera a rede precisa decidir se uma rota sem origem identificável satisfaz sua própria regra de supervisão.

Quatro candidatos e um recibo pela metade

No cenário construído pelos autores do draft, PE1 recebe quatro rotas para P1. PE2 oferece três delas, vindas das instâncias RD21, RD22 e RD23. PE3 oferece RD31. Todas têm o route target que permite a VPN11 considerar a importação. PE1 escolhe RD22. O servidor BMP recebe então a rota selecionada na tabela local de VPN11: prefixo P1, próximo salto e RD11. O relatório não leva o nome da instância que venceu a disputa.

Nada nesse exemplo afirma uma falha real. O problema é a diferença entre duas perguntas que uma tela costuma misturar. “Onde P1 está?” recebe uma resposta: VPN11. “De qual instância veio a rota escolhida?” fica aberta. O próximo salto de PE2 não distingue RD21, RD22 e RD23. A escolha específica ocorreu no roteador, mas a sua origem não atravessou o caminho até o monitor.

O Datatracker do IETF classifica o documento como Internet-Draft individual. Não há decisão de adoção pelo grupo nem levantamento de instalações. O valor do texto está em expor uma autoridade prática: quem pode dizer que controla a passagem entre VRFs quando o registro usado como prova conhece apenas o lado de chegada?

O que a Loc-RIB conta — e o que ela deixa de contar

O RFC 9069 permite que o BMP comunique a Loc-RIB, conjunto de rotas selecionadas pelo processo BGP local. É uma vista eficiente para o coletor; ele não precisa repetir toda a seleção sobre as entradas recebidas. Para uma rota VPN, porém, o peer address no cabeçalho fica zerado e o peer distinguisher identifica a instância local cuja tabela está sendo descrita. No exemplo, esse identificador é RD11. Ele marca o destino da importação, não a fonte RD22.

PE1 viu os quatro candidatos e escolheu um. A lacuna aparece no artefato exportado ao servidor BMP. É nela que uma auditoria de política de importação tropeça. Uma regra pode permitir determinada combinação de route targets. Isso não dispensa a equipe de saber qual instância remota forneceu a rota que acabou na tabela receptora. Sem a origem, a troca de RD22 por RD21 pode ocorrer sob o mesmo prefixo, na mesma VPN, com uma aparência de estabilidade no painel.

Os autores propõem um Remote VRF Information TLV com família de endereços, identificador BGP remoto e route distinguisher remoto. RD11 passa a nomear a instância que recebeu P1 e RD22, a instância que forneceu a rota escolhida. Há também campos opcionais para a etiqueta MPLS e o SID SRv6 carregados pela rota remota. Esses valores detalham o tratamento da rota; não transformam a origem em um detalhe dispensável.

Um bom registro não precisa fingir que responde a tudo. Ele precisa responder com precisão à pergunta para a qual foi guardado. A Loc-RIB comum mostra uma seleção local. Acrescentar a identidade remota permitiria investigar a travessia entre instâncias. Chamar a primeira capacidade de equivalente à segunda deixa a equipe com um arquivo impecável da chegada e quase nada sobre a escolha de entrada.

A extensão de EVPN amplia a pergunta

A versão 01 já propunha o campo para VPN. A revisão 02 inclui EVPN Type-5 e o vazamento de rotas entre EVIs via IRB. Nela, P1 parte de EVI21 em PE2 e entra em EVI11 em PE1. Um relatório tradicional apresenta P1 em EVI11 com PE2 como próximo salto, mas não identifica EVI21. O campo proposto pode anexar AFI 25, SAFI 70, o identificador BGP remoto e RD21.

O draft menciona outro trabalho sobre estatísticas BMP de EVPN. Um contador por EVI pode mostrar quantas rotas foram importadas entre instâncias. Esse número aponta volume; não responde qual EVI originou determinada P1. Para investigar uma mudança específica, o operador precisa tanto da pista estatística quanto da identidade por rota.

Há um limite adicional. A Loc-RIB registra uma seleção no plano de controle BGP. A presença de P1 ali não estabelece instalação na tabela de encaminhamento, entrega de pacotes ou alteração de um serviço. A proposta melhora a atribuição da rota selecionada. O efeito sobre o tráfego exige outra observação.

A informação pode sumir no emissor ou no coletor

O texto diz que um emissor BMP com suporte à extensão pode incluir o TLV. Um coletor pode ignorá-lo e continuar interoperando com RFC 9069. Os tipos de informação estão pendentes de designação na seção da IANA. A mera existência do draft não faz um equipamento enviar RD22, nem obriga o banco de dados de monitoramento a guardá-lo.

A seção de segurança pede sessões apenas com dispositivos de monitoramento autorizados e confiáveis. É a fronteira de acesso ao fluxo. Reter a instância remota, expor sua ausência e fazê-la pesar em uma decisão local são responsabilidades adicionais da organização. Um indicador verde de sessão BMP pode coexistir com uma trilha de origem vazia.

Sources