Porque uma MAC QFX aparece no EVPN mas não na tabela de encaminhamento

Encontrar uma MAC na base de dados EVPN prova que foi anunciada ou recebida como rota, e nada mais. A tabela de encaminhamento é outra estrutura, programada mais tarde, pelo que a mesma MAC pode aparecer numa e faltar na outra enquanto todos os protocolos se comportam corretamente. Tratar estas duas saídas como cópias uma da outra manda os engenheiros atrás de uma falha de BGP quando a lacuna real é uma política de importação ou um salto seguinte por resolver. A pergunta que vale a pena fazer não é se o fabric conhece a MAC, mas em que etapa deixou de a passar adiante.

Duas tabelas que respondem a perguntas diferentes

No Junos EVPN a base de dados lista os endereços MAC por instância juntamente com a forma como cada um chegou: aprendido de uma porta de acesso, recebido numa rota Type 2 ou marcado como parte de um grupo de multihoming. A referência da Juniper show evpn database abrange os filtros por MAC e por instância que tornam a vista legível. É um resumo do plano de controlo indexado por instância e MAC, não a tabela com que o hardware comuta as tramas.

A tabela de comutação é esse estado de encaminhamento. Ambas as saídas listam MAC ao lado do contexto de VLAN ou VNI, que é exatamente por isso que são comparadas linha a linha, e exatamente por isso que a comparação engana. Uma entrada na base de dados diz que a rota existe e foi aceite na instância; não diz nada sobre se a plataforma a instalou para encaminhamento.

Uma rota Type 2 transporta a MAC, um IP opcional, uma etiqueta ou VNI, um distinto de rota e um salto seguinte que nomeia o VTEP remoto. Quatro coisas podem quebrar entre o cabo e essa rota: o anfitrião nunca é aprendido, a rota nunca é anunciada, é rejeitada na importação ou o seu salto seguinte não resolve. Cada falha deixa um conjunto diferente de tabelas preenchidas, e é por isso que a sequência pode ser diagnosticada.

A aprendizagem local continua a acontecer primeiro

A suposição comum é que o EVPN assume a aprendizagem de MAC, pelo que uma base de dados vazia deve significar um problema de overlay. A aprendizagem local continua a correr do lado do acesso, exatamente como antes de existir VXLAN: o switch aprende a MAC de origem de uma trama permitida no VLAN e no serviço corretos, e só depois origina uma Type 2 para ela. Um anfitrião que não enviou nenhuma trama relevante não tem nada a anunciar. Um anfitrião cujas tramas são descartadas por pertença ao VLAN, um filtro ou um membro em baixo de um agregado parece idêntico do ponto de vista do overlay.

Comece no ponto de ligação e avance com comandos só de leitura. O objetivo é provar que uma trama do anfitrião atravessou o serviço pretendido, porque nada a jusante compensa uma trama que nunca chegou.

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

Os membros LACP selecionados importam mais do que o bundle estar ativo, já que um agregado pode estar ativo num membro enquanto o tráfego do anfitrião é disperso para uma ligação em baixo ou bloqueada. Os contadores de interface separam um anfitrião silencioso de um que descarta, porque um anfitrião que nunca transmite e um anfitrião cujas tramas são descartadas por classificação deixam a mesma tabela vazia.

Onde se perde uma MAC remota

Uma MAC remota falha na direção oposta, e em silêncio. A rota Type 2 chega, mas só entra numa instância quando o seu alvo de rota e o VNI correspondem à configuração local, e só se torna utilizável quando o salto seguinte resolve num VTEP alcançável. Um desalinhamento do alvo de rota deixa uma rota válida na tabela BGP que nenhuma instância pede.

Leia as três vistas por ordem: presença da rota, entrada na base de dados, entrada de encaminhamento. Os comandos abaixo consultam a mesma MAC em cada etapa, e o endereço de exemplo mantém as saídas comparáveis.

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

Essas saídas respondem a três perguntas separadas. Uma rota em bgp.evpn.0 sem entrada na base de dados aponta para política de importação, alvo de rota ou configuração de instância. Uma entrada na base de dados sem entrada de encaminhamento aponta para a programação da plataforma, que pertence a um caminho de escalonamento diferente. Uma rota ativa cujo salto seguinte não resolve é um problema de transporte ou de etiqueta, e nenhuma quantidade de depuração de MAC o repara.

Um reinício que o corrigiu prova muito pouco

Quando um reinício faz o sintoma desaparecer, a conclusão tentadora é que a configuração deve estar sólida. Um reinício reprograma cada tabela de raiz, pelo que também esconde o caso em que uma entrada obsoleta ocultava um erro de política; a falha tende a voltar na alteração seguinte, no flapping de uma ligação ou na retirada de uma rota.

Antes de qualquer janela de manutenção, capture o que o reinício vai apagar. Estes três comandos bastam para comparar antes e depois, e não alteram nada no equipamento.

show evpn database instance blue
show route table bgp.evpn.0
show version

Arquive essas saídas com a data e a versão do software ao lado. Um relatório posterior de que o mesmo reinício já tinha funcionado é uma pista e não uma prova, e a diferença só se torna visível quando alguém guardou a saída anterior.

Quatro observações que resolvem a maioria dos casos

Quatro observações cobrem quase todos os casos: o ponto de ligação e o seu serviço, a MAC como valor de exemplo, o estado da rota e da base de dados, e a versão em uso. Escolha uma MAC obviamente de exemplo para que ninguém a confunda com um endereço de produção: um primeiro octeto 02 marca um endereço unicast administrado localmente, os restantes octetos estão livres, e 02:00:00:00:00:5c é portanto um marcador seguro.

Depois deixe que as respostas apontem para a etapa que falhou. Nenhuma aprendizagem no ponto de ligação significa o lado do acesso; uma rota sem entrada na base de dados significa importação; uma entrada na base de dados sem estado de encaminhamento significa programação. Seja o que for, entregue as saídas recolhidas juntamente com o anfitrião, a interface, o serviço e a versão, para que o próximo engenheiro possa reproduzir o caminho em vez de repetir a consulta.