Un host EVPN silencioso nunca se resuelve: siga el ARP hasta la vinculación

El extremo está conectado, su puerto está activo y el host de monitorización sigue sin poder alcanzarlo. Alguien ejecuta un ping desde el lado opuesto y empieza a funcionar, lo que hace que el problema parezca intermitente y que la fabric parezca inocente. Ese patrón es la firma de un host silencioso: transmite pocas veces, así que el comportamiento de descubrimiento y refresco de la fabric importa más que el estado de su conexión. Empiece con una IP, una MAC y un bridge domain previstos y siga el siguiente intercambio de resolución.

Siga el siguiente intercambio ARP o ND

Para IPv4, observe el intercambio ARP del host solicitante; para IPv6, siga el Neighbor Solicitation y el Advertisement. Confirme que la solicitud entra en el segmento local previsto y en el VNI previsto, porque ningún proxy puede responder a una solicitud que nunca llega al bridge domain correcto.

Después mire qué sabe la fabric sobre el destino. Una ruta solo de MAC puede identificar un destino de Layer 2 mientras el proxy todavía no tiene ninguna vinculación IP-to-MAC para él. Son registros separados, y comprobar uno no dice nada del otro.

Si existe una vinculación válida, el proxy puede responder según su política, pero la MAC de esa vinculación todavía necesita una ruta de reenvío activa. Si la vinculación falta, la solicitud debe llegar a la conexión del extremo por la ruta de flooding o de réplica antes de que algo pueda aprender de la respuesta.

Dos registros que deben coincidir

La ruta MAC responde dónde vive la dirección Ethernet. La tabla del proxy responde qué IP se asigna a qué MAC. Un host que no ha hablado recientemente puede tener una ruta MAC perfectamente buena y ninguna entrada de proxy utilizable, y ese es exactamente el estado que produce un fallo de resolución en una conexión sana.

En la conexión remota, compruebe si el extremo recibe realmente el intercambio y responde a él. Su respuesta refresca el aprendizaje local y el anuncio EVPN correspondiente, y por eso el ping manual parece arreglar las cosas: usted generó el tráfico que la fabric esperaba. Eso también explica por qué la corrección no dura: en cuanto la entrada refrescada caduca, el extremo vuelve a quedarse en silencio. Un ping programado trata el síntoma y oculta la carencia de diseño.

Tras la respuesta, siga la ruta seleccionada y el estado de reenvío instalado de vuelta hacia el solicitante. Que la resolución tenga éxito y que el reenvío lo tenga son dos sucesos separados, y un tique que los confunde le envía a la capa equivocada.

Qué asume realmente el estándar

RFC 9161 describe el aprendizaje dinámico del proxy y el flooding predeterminado de las solicitudes ARP y ND desconocidas. La supresión completa de ese flooding se limita a despliegues cuyas suposiciones de aprendizaje o aprovisionamiento la hacen segura, que es una condición más estrecha de lo que insinúan la mayoría de las guías de configuración.

Una fabric que espera extremos recién descubiertos necesita una ruta funcional para esas solicitudes. Si alguien desactivó el flooding de solicitudes desconocidas para reducir el tráfico BUM, los hosts silenciosos son la población que lo paga, y el síntoma llega semanas después como una queja de conectividad intermitente.

Lea el ajuste de supresión como una declaración sobre lo que la fabric promete saber. Si nada aprovisiona las vinculaciones, la promesa no es cierta para los emisores poco frecuentes. Compare la supresión configurada con el sistema de aprovisionamiento que se supone que la alimenta. Cuando esos dos no coinciden, la fabric se comporta exactamente como está configurada y la expectativa es lo que hay que corregir.

Refresco, envejecimiento y la alternativa estática

El estándar describe sondas de refresco admitidas antes de que caduquen las entradas dinámicas. Las respuestas refrescan el estado relevante del bridge y del proxy; la ausencia de respuestas puede llevar legítimamente a la eliminación y a la retirada de la ruta. Eso no es un error que deba suprimirse estirando cada temporizador.

Ampliar indefinidamente los temporizadores de envejecimiento cambia un fallo visible por uno obsoleto: la fabric sigue anunciando una ubicación que el host ha abandonado. Utilice los controles documentados de la implementación y elija una vida útil que coincida con la frecuencia con la que cabe esperar razonablemente que hable el extremo.

Para extremos conocidos y gestionados, una vinculación estática o aprovisionada por el controlador es un segundo modelo legítimo. Necesita un propietario que gestione la sustitución y el movimiento, porque un registro aprovisionado no se actualiza solo cuando el host se traslada a otro puerto.

Qué registrar antes del siguiente tique

Mantenga la fuente de la vinculación, la hora del último refresco, la ubicación actual y cualquier evento de retirada junto a la ruta MAC. Ese registro responde a la pregunta que el tique realmente plantea: ¿la aplicación espera el descubrimiento, depende de un estado obsoleto o no consigue reenviar tras una resolución correcta?

Después decida cuál de los tres está dispuesto a operar. Descubrimiento con flooding, refresco con una vida útil realista o aprovisionamiento con un propietario son todos defendibles. Una fabric configurada para uno y de la que se espera que se comporte como otro es donde desaparecen los hosts silenciosos.