Tichý hostitel EVPN se nikdy nerozřeší: sledujte ARP až k vazbě

Koncový bod je připojen, jeho port je aktivní a monitorovací hostitel se k němu stále nedostane. Někdo spustí ping z opačné strany a ono to začne fungovat, což problém dělá zdánlivě přerušovaným a fabric vypadá nevinně. Tento vzorec je podpisem tichého hostitele: vysílá jen zřídka, takže chování fabric při zjišťování a obnově je důležitější než stav jeho připojení. Začněte jednou zamýšlenou IP, MAC a bridge domain a sledujte další výměnu rozlišení.

Sledujte další výměnu ARP nebo ND

U IPv4 sledujte výměnu ARP tázajícího se hostitele; u IPv6 sledujte Neighbor Solicitation a Advertisement. Potvrďte, že požadavek vstupuje do zamýšleného lokálního segmentu a zamýšleného VNI, protože požadavek, který nikdy nedosáhne správné bridge domain, nemůže odpovědět žádná proxy.

Pak se podívejte, co fabric o cíli ví. Trasa jen podle MAC může identifikovat cíl v Layer 2, zatímco proxy pro něj stále nemá vazbu IP-to-MAC. Jsou to oddělené záznamy a kontrola jednoho nic neříká o druhém.

Pokud platná vazba existuje, proxy může odpovědět podle své politiky, ale MAC v této vazbě stále potřebuje aktivní cestu předávání. Pokud vazba chybí, musí požadavek dorazit k připojení koncového bodu přes cestu flooding nebo replikace, než se z odpovědi může cokoli naučit.

Dva záznamy, které musí souhlasit

MAC trasa odpovídá na to, kde žije Ethernetová adresa. Proxy tabulka odpovídá na to, která IP se mapuje na kterou MAC. Hostitel, který nedávno nemluvil, může mít naprosto dobrou MAC trasu a žádnou použitelnou položku proxy, a to je přesně stav, který vytváří selhání rozlišení na zdravém připojení.

Na vzdáleném připojení zkontrolujte, zda koncový bod výměnu skutečně přijímá a odpovídá na ni. Jeho odpověď obnovuje lokální učení a odpovídající inzerci EVPN, a proto se zdá, že ruční ping věci opravuje: vygenerovali jste provoz, na který fabric čekala. To také vysvětluje, proč oprava nevydrží: jakmile obnovená položka vyprší, koncový bod znovu ztichne. Naplánovaný ping léčí symptom a skrývá mezeru v návrhu.

Po odpovědi sledujte vybranou trasu a instalovaný stav předávání zpět k tazateli. Úspěch rozlišení a úspěch předávání jsou dvě oddělené události a tiket, který je slučuje, vás pošle na špatnou vrstvu.

Co standard vlastně předpokládá

RFC 9161 popisuje dynamické učení proxy a výchozí flooding neznámých požadavků ARP a ND. Úplné potlačení tohoto flooding je omezeno na nasazení, jejichž předpoklady učení nebo provisioningingu ho činí bezpečným, což je užší podmínka, než naznačuje většina konfiguračních příruček.

Fabric, která očekává nově objevené koncové body, potřebuje funkční cestu pro tyto požadavky. Pokud někdo vypnul flooding neznámých požadavků, aby snížil provoz BUM, platí za to právě tichý hostitelé, a symptom dorazí o týdny později jako stížnost na přerušovanou dosažitelnost.

Čtěte nastavení potlačení jako tvrzení o tom, co fabric slibuje vědět. Pokud vazby nic nezajišťuje, slib neplatí pro občasné odesílatele. Porovnejte nakonfigurované potlačení s provisioningovým systémem, který ho má napájet. Když se ty dva neshodují, fabric se chová přesně tak, jak je nakonfigurovaná, a opravit je potřeba očekávání.

Obnova, stárnutí a statická alternativa

Standard popisuje podporované sondy obnovy před tím, než dynamické položky vyprší. Odpovědi obnovují příslušný stav bridge a proxy; chybějící odpovědi mohou legitimně vést k odstranění a odvolání trasy. To není chyba, která se má potlačit natažením každého časovače.

Neurčité prodlužování časovačů stárnutí mění viditelné selhání za zastaralé: fabric dál inzeruje umístění, které hostitel opustil. Použijte dokumentované ovládací prvky implementace a zvolte životnost, která odpovídá tomu, jak často lze rozumně očekávat, že koncový bod promluví.

Pro známé, spravované koncové body je statická nebo kontrolerem zajištěná vazba legitimní druhý model. Potřebuje vlastníka, který řeší výměnu a přesun, protože zajištěný záznam se sám neaktualizuje, když se hostitel přesune na jiný port.

Co zaznamenat před dalším ticketem

Uchovávejte zdroj vazby, čas poslední obnovy, aktuální umístění a jakoukoli událost odvolání vedle MAC trasy. Tento záznam odpovídá na otázku, kterou ticket skutečně klade: čeká aplikace na zjištění, spoléhá na zastaralý stav, nebo po úspěšném rozlišení neumí předávat?

Pak rozhodněte, který ze tří jste ochotni provozovat. Zjišťování s floodingem, obnova s realistickou životností nebo provisioning s vlastníkem jsou všechny obhajitelné. Fabric nakonfigurovaná pro jedno a očekávaná, že se bude chovat jako jiné, je místo, kde tichý hostitelé mizí.