Un host EVPN silencioso nunca se resolve: siga o ARP ata a vinculación

O extremo está conectado, o seu porto está activo e o host de monitorización segue sen poder alcanzalo. Alguén executa un ping desde o lado oposto e comeza a funcionar, o que fai que o problema pareza intermitente e que a fabric pareza inocente. Ese patrón é a sinatura dun host silencioso: transmite poucas veces, así que o comportamento de descubrimento e refresco da fabric importa máis que o estado da súa conexión. Empece cunha IP, unha MAC e un bridge domain previstos e siga o seguinte intercambio de resolución.

Siga o seguinte intercambio ARP ou ND

Para IPv4, observe o intercambio ARP do host solicitante; para IPv6, siga o Neighbor Solicitation e o Advertisement. Confirme que a solicitude entra no segmento local previsto e no VNI previsto, porque ningún proxy pode responder a unha solicitude que nunca chega ao bridge domain correcto.

Despois mire que sabe a fabric sobre o destino. Unha ruta só de MAC pode identificar un destino de Layer 2 mentres o proxy aínda non ten ningunha vinculación IP-to-MAC para el. Son rexistros separados, e comprobar un non di nada do outro.

Se existe unha vinculación válida, o proxy pode responder segundo a súa política, pero a MAC desa vinculación aínda necesita unha ruta de reenvío activa. Se a vinculación falta, a solicitude debe chegar á conexión do extremo pola ruta de flooding ou de réplica antes de que algo poida aprender da resposta.

Dous rexistros que deben coincidir

A ruta MAC responde onde vive o enderezo Ethernet. A táboa do proxy responde que IP se asigna a que MAC. Un host que non falou recentemente pode ter unha ruta MAC perfectamente boa e ningunha entrada de proxy utilizábel, e ese é exactamente o estado que produce un fallo de resolución nunha conexión sa.

Na conexión remota, comprobe se o extremo recibe realmente o intercambio e responde a el. A súa resposta refresca a aprendizaxe local e o anuncio EVPN correspondente, e por iso o ping manual parece arranxar as cousas: vostede xerou o tráfico que a fabric agardaba. Iso tamén explica por que a corrección non dura: en canto a entrada refrescada caduca, o extremo volve quedar en silencio. Un ping programado trata o síntoma e oculta a carencia de deseño.

Tras a resposta, siga a ruta seleccionada e o estado de reenvío instalado de volta cara ao solicitante. Que a resolución teña éxito e que o reenvío o teña son dous acontecementos separados, e un tícket que os confunde envíalle á capa equivocada.

Que asume realmente o estándar

RFC 9161 describe a aprendizaxe dinámica do proxy e o flooding predeterminado das solicitudes ARP e ND descoñecidas. A supresión completa dese flooding limítase a despregamentos cuxas suposicións de aprendizaxe ou aprovisionamento a fan segura, que é unha condición máis estreita do que insinúan a maioría das guías de configuración.

Unha fabric que espera extremos recentemente descubertos necesita unha ruta funcional para esas solicitudes. Se alguén desactivou o flooding de solicitudes descoñecidas para reducir o tráfico BUM, os hosts silenciosos son a poboación que o paga, e o síntoma chega semanas despois como unha queixa de conectividade intermitente.

Lea o axuste de supresión como unha declaración sobre o que a fabric promete saber. Se nada aprovisiona as vinculacións, a promesa non é certa para os emisores pouco frecuentes. Compare a supresión configurada co sistema de aprovisionamento que se supón que a alimenta. Cando eses dous non coinciden, a fabric compórtase exactamente como está configurada e a expectativa é o que hai que corrixir.

Refresco, envellecemento e a alternativa estática

O estándar describe sondas de refresco admitidas antes de que caduquen as entradas dinámicas. As respostas refrescan o estado relevante do bridge e do proxy; a ausencia de respostas pode levar lexitimamente á eliminación e á retirada da ruta. Iso non é un erro que deba suprimirse estirando cada temporizador.

Ampliar indefinidamente os temporizadores de envellecemento cambia un fallo visible por un obsoleto: a fabric segue anunciando unha localización que o host abandonou. Utilice os controis documentados da implementación e escolla unha vida útil que coincida coa frecuencia coa que cabe esperar razoablemente que fale o extremo.

Para extremos coñecidos e xestionados, unha vinculación estática ou aprovisionada polo controlador é un segundo modelo lexítimo. Necesita un propietario que xestione a substitución e o movemento, porque un rexistro aprovisionado non se actualiza só cando o host se traslada a outro porto.

Que rexistrar antes do seguinte tícket

Manteña a fonte da vinculación, a hora do último refresco, a localización actual e calquera acontecemento de retirada xunto á ruta MAC. Ese rexistro responde a pregunta que o tícket realmente formula: a aplicación espera o descubrimento, depende dun estado obsoleto ou non consegue reenviar tras unha resolución correcta?

Despois decida cal dos tres está disposto a operar. Descubrimento con flooding, refresco cunha vida útil realista ou aprovisionamento cun propietario son todos defendibles. Unha fabric configurada para un e da que se espera que se comporte como outro é onde desaparecen os hosts silenciosos.