Тихият хост в EVPN никога не се разрешава: следвайте ARP до връзката

Крайната точка е свързана, портът ѝ е активен, а мониторинг хостът все още не може да я достигне. Някой пуска ping от отсрещната страна и то започва да работи, което прави проблема да изглежда периодичен, а fabric — невинен. Този модел е подписът на тихия хост: той рядко предава, затова поведението на fabric при откриване и обновяване е по-важно от състоянието на връзката му. Започнете с един предвиден IP, MAC и bridge domain и проследете следващия обмен на разрешаване.

Проследете следващия обмен по ARP или ND

За IPv4 наблюдавайте ARP обмена на заявяващия хост; за IPv6 следвайте Neighbor Solicitation и Advertisement. Потвърдете, че заявката влиза в предвидения локален сегмент и предвидения VNI, защото заявка, която никога не достига правилния bridge domain, не може да бъде отговорена от никое прокси.

След това вижте какво знае fabric за целта. Маршрут само по MAC може да идентифицира дестинация от Layer 2, докато проксито все още няма връзка IP-to-MAC за нея. Това са отделни записи и проверката на единия не ви казва нищо за другия.

Ако има валидна връзка, проксито може да отговори според политиката си, но MAC адресът в тази връзка все още се нуждае от активен път за препращане. Ако връзката липсва, заявката трябва да достигне връзката на крайната точка през пътя на flooding или репликация, преди нещо да може да научи от отговора.

Два записа, които трябва да съвпадат

MAC маршрутът отговаря къде живее Ethernet адресът. Прокси таблицата отговаря кой IP към кой MAC се съпоставя. Хост, който не е говорил наскоро, може да има напълно добър MAC маршрут и никакъв използваем прокси запис — и това е точно състоянието, което поражда неуспех при разрешаване върху здрава връзка.

При отдалечената връзка проверете дали крайната точка наистина получава и отговаря на обмена. Нейният отговор обновява локалното обучение и съответната EVPN реклама, поради което ръчният ping изглежда, че оправя нещата: вие генерирахте трафика, който fabric чакаше. Това също обяснява защо поправката не трае: щом обновеният запис остарее, крайната точка отново замлъква. Планираният ping лекува симптома и скрива пропуск в дизайна.

След отговора проследете избрания маршрут и инсталираното състояние за препращане обратно към заявяващия. Успешното разрешаване и успешното препращане са две отделни събития и тикет, който ги смесва, ви праща на грешния слой.

Какво всъщност предполага стандартът

RFC 9161 описва динамично прокси обучение и стандартното flooding на неизвестни ARP и ND заявки. Пълното потискане на това flooding е ограничено до внедрявания, чиито допускания за обучение или осигуряване го правят безопасно, което е по-тясно условие, отколкото повечето конфигурационни ръководства предполагат.

Fabric, която очаква новооткрити крайни точки, се нуждае от работещ път за тези заявки. Ако някой е изключил flooding на неизвестни заявки, за да намали BUM трафика, тихите хостове са популацията, която плаща за това, и симптомът идва седмици по-късно като оплакване за периодична достижимост.

Четете настройката за потискане като изявление за това какво fabric обещава да знае. Ако нищо не осигурява връзките, обещанието не е вярно за редките податели. Сравнете конфигурираното потискане с осигуряващата система, която трябва да го храни. Когато двете не съвпадат, fabric се държи точно както е конфигурирана и очакването е това, което трябва да се поправи.

Обновяване, остаряване и статичната алтернатива

Стандартът описва поддържани проби за обновяване, преди динамичните записи да остареят. Отговорите обновяват съответното bridge и прокси състояние; липсващите отговори могат законно да доведат до премахване и оттегляне на маршрут. Това не е бъг, който да се потиска чрез разтягане на всеки таймер.

Безкрайното удължаване на таймерите за остаряване разменя видим отказ срещу остарял: fabric продължава да рекламира място, което хостът е напуснал. Използвайте документираните контроли на реализацията и изберете живот, който съответства на това колко често крайната точка може разумно да се очаква да говори.

За известни, управлявани крайни точки статична или осигурена от контролер връзка е законен втори модел. Тя се нуждае от собственик, който се занимава със замяна и преместване, защото осигурен запис не се обновява сам, когато хостът се премести на друг порт.

Какво да запишете преди следващия тикет

Пазете източника на връзката, времето на последно обновяване, текущото местоположение и всяко събитие на оттегляне до MAC маршрута. Този запис отговаря на въпроса, който тикетът всъщност задава: приложението чака откриване, разчита на остаряло състояние или не успява да препрати след успешно разрешаване?

След това решете кой от трите сте готови да експлоатирате. Откриване с flooding, обновяване с реалистичен живот или осигуряване със собственик — всички са защитими. Fabric, конфигурирана за едно и от която се очаква да се държи като друго, е мястото, където тихите хостове изчезват.