AFI e SAFI: leia o par antes do nome do serviço

Pode ver uma sessão subir, ver uma rota aparecer e ainda assim ler o serviço errado. O par de números no início de cada anúncio, o identificador de família de endereços e o identificador da família de endereços seguinte, decide qual analisador lê a carga e qual tabela guarda o resultado. Erre o par e a política de importação, a correspondência do alvo da rota e a busca do próximo salto correm todas contra uma estrutura que ninguém anunciou. O percurso abaixo começa nesse par e termina no resultado do encaminhamento.

Dois números decidem a que tabela pertence a rota

O par aparece duas vezes: dentro da capacidade multiprotocolo, onde um falante anuncia uma família, e diante de cada NLRI que essa família transporta. Isso torna-o uma propriedade da rota e não um ajuste da caixa de origem. Os fabricantes imprimem-no como um nome do tipo Address family VPNv4 Unicast, e a redação muda entre versões enquanto os números ficam no lugar.

Quatro codificações cobrem quase todos os casos empresariais: 1 com 128 para VPN-IPv4 etiquetada com MPLS, 2 com 128 para o equivalente IPv6, 25 com 65 para VPLS sinalizado por BGP e 25 com 70 para EVPN. O primeiro erro é supor que todo serviço Layer 2 fica atrás de 25 com 65, o que esconde EVPN. O segundo é tratar as duas famílias IP como uma só família com um endereço mais longo, quando são negociadas em separado e podem ser aceites em pares diferentes. Um terceiro surge quando se copia um modelo de uma versão que só conhece uma delas. Uma consulta ao registo resolve os três mais depressa do que uma suposição baseada no nome do serviço.

Trate as quatro linhas como exemplos do registo IANA, não como o registo em si. Quando um número não corresponder a nada que reconheça, consulte-o antes de construir uma política em torno dele.

AFI 25 transporta dois formatos NLRI sem relação

As duas famílias Layer 2 ficam sob AFI 25, e a semelhança termina aí. O NLRI de VPLS em RFC 4761 section 3.2.2 transporta um comprimento, um distinguidor de rota, um VE ID, um deslocamento de bloco VE, um tamanho de bloco VE e uma base de etiquetas, que juntos nomeiam um extremo de pseudowire e a sua etiqueta. EVPN mantém AFI 25 e passa a SAFI 70, onde a carga é um tipo de rota: descoberta automática de Ethernet, anúncio MAC/IP, multicast inclusivo, segmento Ethernet, prefixo IP. Por isso o mesmo deslocamento de byte significa coisas diferentes nas duas famílias. Um analisador escrito para uma lê a outra sem queixa e produz disparate. O par é o único aviso de que a interpretação está errada.

Um campo que numa família significa deslocamento de bloco VE não tem contrapartida na outra, e a rota de anúncio MAC/IP só existe em EVPN. Citar um atributo como se se aplicasse às duas é como uma revisão de captura corre mal.

Quando alguém lhe entregar uma captura ou uma tabela de fornecedor, pergunte a que família pertence o atributo. Depois confirme que a implementação recetora suporta essa família, não o nome do serviço na folha de dados. Duas plataformas podem ambas reclamar suporte de VPLS enquanto implementam famílias de sinalização diferentes. O par separa-as; a etiqueta do produto não.

A família de endereços da própria sessão é uma questão à parte

VPN-IPv6 é anunciado rotineiramente por uma sessão cuja ligação TCP corre sobre IPv4, e isso é desenho suportado, não avaria. Ler apenas o resumo da sessão nada diz, por isso, sobre que famílias VPN os pares trocam.

Família NLRI, família de transporte e família de encaminhamento são três decisões independentes. Um router pode falar IPv4 com o seu par, aceitar alcance de VPN-IPv6 e instalar uma rota cujo próximo salto é um endereço IPv6 alcançável por um caminho que não pretendia. Cada camada precisa da sua própria confirmação. Sítios que relatam destinos IPv6 inalcançáveis enquanto os anúncios parecem corretos perderam normalmente a resolução do próximo salto, não a negociação de famílias.

Teste a família de endereços da sessão isoladamente, depois as famílias que transporta, depois o que o núcleo consegue encaminhar. Manter as três separadas evita o diagnóstico errado comum em que um anúncio correto é lido como prova de que IPv6 funciona de ponta a ponta. Prova apenas que um par disse a outro algo sobre um prefixo.

Negociado, recebido, importado, instalado

Para uma rota esperada, quatro estados têm de se verificar por ordem, e cada um é observável. A família tem de estar negociada com esse par, a rota tem de chegar, um alvo de rota tem de a importar para o contexto pretendido e o próximo salto tem de resolver para que a rota se instale. Saltar o primeiro estado torna os outros três sem resposta, porque uma família não negociada não produz rotas para inspecionar. Em plataformas ao estilo Cisco os resumos de família e as capacidades por par são comandos separados.

show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family

A negociação aparece na troca de capacidades impressa por par, e uma sessão estabelecida sem qualquer família listada não transporta nada do que pediu. A importação é decidida por alvos de rota transportados como comunidades estendidas, pelo que um par correto com um alvo mal escrito deixa a tabela vazia. A instalação depende depois de o próximo salto resolver no contexto recetor, o que pode falhar enquanto cada anúncio parece perfeito.

Confirme o plano de dados por último, porque uma rota na tabela é uma afirmação, não uma entrega. Os mesmos quatro estados aplicam-se a cada família; só mudam os comandos e os nomes das tabelas.

O que um par de famílias nunca prova

Ler o par corretamente diz-lhe como interpretar a informação de encaminhamento que se segue, e essa é toda a afirmação. Não diz nada sobre alcance, nada sobre política e nada sobre a saúde do plano de dados. Confundir as duas coisas produz afirmações seguras sobre uma rede que ninguém verificou. Um desalinhamento de alvo de rota e um próximo salto quebrado parecem idênticos só de olhar para o par. O par é uma instrução de leitura, nunca um veredicto.

Quando escalar, ponha o par, o alvo de rota e o próximo salto resolvido na mesma nota. O engenheiro seguinte tem então três coisas independentes para testar em vez de um nome de serviço para reinterpretar. Se faltar a negociação vêem-no logo, um alvo errado deixa a importação visivelmente ausente e um próximo salto não resolvido deixa a rota presente mas inutilizável.