Algumas rotas L2VPN desaparecem depois de adicionar refletores de rota

As sessões permanecem ativas, o IGP está estável e, ainda assim, um punhado de rotas L2VPN nunca aparece em duas das quatro bordas do provedor. Esse padrão pertence a um problema de reflexão e não de transporte, porque uma sessão quebrada falha por completo, enquanto uma fronteira de reflexão reutilizada falha de forma seletiva. O anel físico não tem nada a ver; o grafo lógico de distribuição é onde essas rotas pararam. Encontrar esse ponto não exige reconstruir o plano de controle.

A perda é seletiva, o que estreita a busca

Quatro bordas de provedor em um anel físico precisam de seis sessões lógicas para uma malha completa, já que cada roteador se emparelha com os outros três. Essas sessões trafegam sobre o transporte roteado, então a cabeação não diz nada sobre quantas adjacências existem ou qual delas reflete. Quando duas bordas perdem um conjunto específico de prefixos enquanto todo o resto converge, o cabo não é o suspeito.

A perda seletiva aponta para prevenção de laços, política ou direção da relação, em que algumas rotas cruzam uma fronteira e outras são descartadas no caminho. A perda total aponta para a sessão ou para a família de endereços. Decidir qual das duas você está vendo é o primeiro passo útil, e custa um único comando.

O que a reflexão realmente muda

A reflexão de rotas flexibiliza a regra de que um falante iBGP não pode reanunciar uma rota aprendida de outro falante iBGP. RFC 4456 expressa a exceção por meio da relação entre o falante e a origem da rota, e a direção dessa relação importa mais do que sugerem a maioria dos resumos. Uma rota aprendida de um cliente pode ser refletida a outros clientes e a não clientes, enquanto uma rota aprendida de um não cliente só pode ser refletida a clientes. Leia a assimetria duas vezes, porque ela explica como adicionar uma relação de cliente pode esconder um erro de projeto: abre um caminho que a topologia nunca pretendeu.

O atributo CLUSTER_LIST registra o histórico de reflexão, e um refletor que encontra o próprio ID de cluster nessa lista deve ignorar o anúncio. Isso é prevenção de laços, e também é o mecanismo que apaga rotas quando identificadores são reutilizados por acidente. O ORIGINATOR_ID desempenha um papel relacionado ao nomear o roteador que anunciou a rota primeiro.

IDs de cluster reutilizados são como as rotas desaparecem

Uma rede pequena convida a um atalho: dê a cada roteador um ID de cluster igual ao seu loopback, adicione outro refletor depois e reutilize um loopback existente porque está à mão. Se esse identificador agora aparece em dois estágios de reflexão independentes, o segundo estágio vê o próprio ID em CLUSTER_LIST e descarta a rota. Nada registra um erro, porque descartar é a resposta correta a um laço.

Refletores redundantes que servem um único cluster são a exceção legítima: compartilham um ID de propósito para que qualquer um deles possa servir os mesmos clientes. O identificador precisa corresponder ao projeto de reflexão e não distinguir nomes de chassis.

Desenhe o grafo pretendido antes de tocar em qualquer configuração: quem origina o prefixo, qual relação de cliente permite a primeira reflexão, qual refletor a leva ao próximo estágio e onde fica o último cliente. Cada salto desse grafo é um lugar onde um identificador reutilizado, uma relação de cliente ausente ou um filtro de política pode deter a rota. Com o grafo desenhado, uma rota ausente tem uma localização em vez de um mistério.

Resista à tentação de tornar cliente cada vizinho

O reparo rápido para uma rota ausente é tornar cada vizinho cliente de cada refletor. A propagação volta, e o projeto deixa de lhe dizer qualquer coisa: multiplica as rotas que cada falante carrega enquanto esconde qual relação deveria fazer o trabalho.

Uma rede pequena geralmente precisa de uma de duas formas. Uma malha iBGP completa são seis sessões para quatro roteadores sem reflexão alguma, e um par designado de refletores que serve as bordas restantes é a outra. Ambas são mais fáceis de raciocinar do que uma malha parcial em que cada roteador reflete um pouco. Escolha a forma por escala e comportamento em caso de falha, não pelo diagrama de cabeação.

Verifique a família de endereços antes de culpar a reflexão

Uma sessão TCP na porta 179 prova que os dois falantes conseguem falar, e nada sobre se a família de endereços VPN trocou uma única rota. Estabeleça o estado da sessão, depois a família, depois o prefixo individual.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

Essas três saídas separam um problema de adjacência de um problema de troca e de um problema de prefixo ausente. Se a família não mostra nenhum prefixo, inspecione o estado de ativação e a política de exportação do vizinho antes de olhar para a reflexão. Se os prefixos aparecem em uma borda mas não em outra, compare a lista de clusters e o originador no lado receptor e depois percorra o grafo da seção anterior.

Mantenha a acessibilidade do próximo salto e o estado de encaminhamento fora dessa verificação. Uma rota refletida com um próximo salto inacessível está presente e é inutilizável, o que parece uma falha de reflexão até você olhar a coluna do próximo salto. Resolva o próximo salto, confirme a entrada de encaminhamento e só então decida se o grafo de distribuição precisa de outro refletor.