Un amfitrió EVPN silenciós no es resol mai: seguiu l'ARP fins a la vinculació

El punt final està connectat, el seu port està actiu i l'amfitrió de monitoratge encara no hi pot arribar. Algú executa un ping des del costat oposat i comença a funcionar, cosa que fa que el problema sembli intermitent i que la fabric sembli innocent. Aquest patró és la signatura d'un amfitrió silenciós: transmet poques vegades, així que el comportament de descobriment i refresc de la fabric importa més que l'estat de la seva connexió. Comenceu amb una IP, una MAC i un bridge domain objectiu i seguiu el proper intercanvi de resolució.

Seguiu el proper intercanvi ARP o ND

Per a IPv4, observeu l'intercanvi ARP de l'amfitrió sol·licitant; per a IPv6, seguiu el Neighbor Solicitation i l'Advertisement. Confirmeu que la sol·licitud entra al segment local objectiu i al VNI objectiu, perquè cap proxy no pot respondre una sol·licitud que mai arriba al bridge domain correcte.

Després mireu què sap la fabric sobre l'objectiu. Una ruta només MAC pot identificar una destinació de Layer 2 mentre el proxy encara no té cap vinculació IP-to-MAC per a ella. Són registres separats, i comprovar-ne un no diu res de l'altre.

Si existeix una vinculació vàlida, el proxy pot respondre segons la seva política, però la MAC d'aquesta vinculació encara necessita un camí de reenviament actiu. Si la vinculació no hi és, la sol·licitud ha d'arribar a la connexió del punt final a través del camí de flooding o de rèplica abans que res no pugui aprendre de la resposta.

Dos registres que han de coincidir

La ruta MAC respon on viu l'adreça Ethernet. La taula del proxy respon quina IP es mapifica a quina MAC. Un amfitrió que no ha parlat recentment pot tenir una ruta MAC perfectament bona i cap entrada de proxy utilitzable, i aquest és exactament l'estat que produeix un fracàs de resolució en una connexió sana.

A la connexió remota, comproveu si el punt final realment rep l'intercanvi i hi respon. La seva resposta refresca l'aprenentatge local i l'anunci EVPN corresponent, i per això el ping manual sembla arreglar les coses: heu generat el trànsit que la fabric esperava. Això també explica per què la solució no dura: un cop l'entrada refrescada caduca, el punt final torna a quedar-se en silenci. Un ping programat tracta el símptoma i amaga la mancança de disseny.

Després de la resposta, seguiu la ruta seleccionada i l'estat de reenviament instal·lat de tornada cap al sol·licitant. Que la resolució tingui èxit i que el reenviament en tingui són dos esdeveniments separats, i un tiquet que els confon us envia a la capa equivocada.

Què assumeix realment l'estàndard

RFC 9161 descriu l'aprenentatge dinàmic del proxy i el flooding per defecte de les sol·licituds ARP i ND desconegudes. La supressió completa d'aquest flooding es limita a desplegaments les suposicions d'aprenentatge o d'aprovisionament dels quals la fan segura, que és una condició més estreta del que insinuen la majoria de guies de configuració.

Una fabric que espera punts finals descoberts recentment necessita un camí funcional per a aquestes sol·licituds. Si algú ha desactivat el flooding de sol·licituds desconegudes per reduir el trànsit BUM, els amfitrions silenciosos són la població que ho paga, i el símptoma arriba setmanes després com una queixa de connectivitat intermitent.

Llegiu el paràmetre de supressió com una declaració sobre què promet saber la fabric. Si res no aprovisiona les vinculacions, la promesa no és certa per als emissors poc freqüents. Compareu la supressió configurada amb el sistema d'aprovisionament que se suposa que l'alimenta. Quan aquests dos no coincideixen, la fabric es comporta exactament com està configurada i l'expectativa és el que cal corregir.

Refresc, envelliment i l'alternativa estàtica

L'estàndard descriu sondes de refresc admeses abans que les entrades dinàmiques caduquin. Les respostes refresquen l'estat rellevant del bridge i del proxy; l'absència de respostes pot portar legítimament a l'eliminació i a la retirada de la ruta. Això no és un error que calgui suprimir allargant cada temporitzador.

Allargar indefinidament els temporitzadors d'envelliment canvia un fracàs visible per un d'obsolet: la fabric continua anunciant una ubicació que l'amfitrió ha deixat. Utilitzeu els controls documentats de la implementació i trieu una vida útil que coincideixi amb la freqüència amb què es pot esperar raonablement que parli el punt final.

Per als punts finals coneguts i gestionats, una vinculació estàtica o aprovisionada pel controlador és un segon model legítim. Necessita un propietari que gestioni la substitució i el moviment, perquè un registre aprovisionat no s'actualitza sol quan l'amfitrió es mou a un altre port.

Què cal registrar abans del proper tiquet

Manteniu la font de la vinculació, l'hora de l'últim refresc, la ubicació actual i qualsevol esdeveniment de retirada al costat de la ruta MAC. Aquest registre respon la pregunta que el tiquet realment fa: l'aplicació espera el descobriment, depèn d'un estat obsolet o no aconsegueix reenviar després d'una resolució correcta?

Després decidiu quin dels tres esteu disposats a operar. Descobriment amb flooding, refresc amb una vida útil realista o aprovisionament amb un propietari són tots defensables. Una fabric configurada per a un i de la qual s'espera que es comporti com un altre és on desapareixen els amfitrions silenciosos.