Host EVPN silencioso nunca é resolvido: siga o ARP até a vinculação

O endpoint está conectado, sua porta está ativa, e o host de monitoramento ainda não consegue alcançá-lo. Alguém executa um ping do lado oposto e começa a funcionar, o que faz o problema parecer intermitente e a fabric parecer inocente. Esse padrão é a assinatura de um host silencioso: ele raramente transmite, então o comportamento de descoberta e atualização da fabric importa mais que o estado da sua conexão. Comece com um IP, um MAC e um bridge domain pretendidos e siga a próxima troca de resolução.

Siga a próxima troca de ARP ou ND

Para IPv4, observe a troca ARP do host solicitante; para IPv6, siga o Neighbor Solicitation e o Advertisement. Confirme que a solicitação entra no segmento local pretendido e no VNI pretendido, porque nenhum proxy pode responder a uma solicitação que nunca chega ao bridge domain correto.

Depois veja o que a fabric sabe sobre o destino. Uma rota apenas MAC pode identificar um destino de Layer 2 enquanto o proxy ainda não tem nenhuma vinculação IP-to-MAC para ele. São registros separados, e verificar um não diz nada sobre o outro.

Se existir uma vinculação válida, o proxy pode responder conforme sua política, mas o MAC nessa vinculação ainda precisa de um caminho de encaminhamento ativo. Se a vinculação estiver ausente, a solicitação precisa chegar à conexão do endpoint pelo caminho de flooding ou de replicação antes que algo possa aprender com a resposta.

Dois registros que precisam concordar

A rota MAC responde onde vive o endereço Ethernet. A tabela do proxy responde qual IP mapeia para qual MAC. Um host que não falou recentemente pode ter uma rota MAC perfeitamente boa e nenhuma entrada de proxy utilizável, e esse é exatamente o estado que produz uma falha de resolução numa conexão saudável.

Na conexão remota, verifique se o endpoint realmente recebe e responde à troca. A resposta dele atualiza o aprendizado local e o anúncio EVPN correspondente, e é por isso que o ping manual parece resolver as coisas: você gerou o tráfego que a fabric esperava. Isso também explica por que a correção não dura: assim que a entrada atualizada envelhece, o endpoint volta a ficar silencioso. Um ping agendado trata o sintoma e esconde a lacuna de projeto.

Depois da resposta, siga a rota selecionada e o estado de encaminhamento instalado de volta em direção ao solicitante. O sucesso da resolução e o sucesso do encaminhamento são dois eventos separados, e um ticket que os confunde envia você para a camada errada.

O que o padrão realmente assume

RFC 9161 descreve o aprendizado dinâmico do proxy e o flooding padrão de solicitações ARP e ND desconhecidas. A supressão completa desse flooding é limitada a implantações cujas premissas de aprendizado ou provisionamento a tornam segura, o que é uma condição mais estreita do que a maioria dos guias de configuração sugere.

Uma fabric que espera endpoints recém-descobertos precisa de um caminho funcional para essas solicitações. Se alguém desativou o flooding de solicitações desconhecidas para reduzir o tráfego BUM, os hosts silenciosos são a população que paga por isso, e o sintoma chega semanas depois como uma reclamação de alcançabilidade intermitente.

Leia a configuração de supressão como uma declaração sobre o que a fabric promete saber. Se nada provisiona as vinculações, a promessa não é verdadeira para remetentes pouco frequentes. Compare a supressão configurada com o sistema de provisionamento que deveria alimentá-la. Quando os dois discordam, a fabric está se comportando exatamente como configurada, e a expectativa é o que precisa ser corrigido.

Atualização, envelhecimento e a alternativa estática

O padrão descreve sondas de atualização suportadas antes que as entradas dinâmicas envelheçam. As respostas atualizam o estado relevante do bridge e do proxy; a ausência de respostas pode legitimamente levar à remoção e à retirada da rota. Isso não é um bug a ser suprimido esticando cada temporizador.

Estender indefinidamente os temporizadores de envelhecimento troca uma falha visível por uma desatualizada: a fabric continua anunciando um local que o host deixou. Use os controles documentados da implementação e escolha um tempo de vida que corresponda à frequência com que se pode razoavelmente esperar que o endpoint fale.

Para endpoints conhecidos e gerenciados, uma vinculação estática ou fornecida pelo controlador é um segundo modelo legítimo. Ela precisa de um proprietário que cuide da substituição e do movimento, porque um registro fornecido não se atualiza sozinho quando o host se move para outra porta.

O que registrar antes do próximo ticket

Mantenha a origem da vinculação, o horário da última atualização, a localização atual e qualquer evento de retirada ao lado da rota MAC. Esse registro responde à pergunta que o ticket realmente faz: a aplicação está esperando a descoberta, contando com um estado desatualizado ou falhando em encaminhar após uma resolução bem-sucedida?

Depois decida qual dos três você está disposto a operar. Descoberta com flooding, atualização com um tempo de vida realista ou provisionamento com um proprietário são todos defensáveis. Uma fabric configurada para um e da qual se espera que se comporte como outro é onde os hosts silenciosos desaparecem.