Tichý hostiteľ EVPN sa nikdy nevyrieši: sledujte ARP až po väzbu

Koncový bod je pripojený, jeho port je aktívny a monitorovací hostiteľ sa k nemu stále nedostane. Niekto spustí ping z opačnej strany a ono to začne fungovať, čo robí problém zdanlivo prerušovaným a fabric vyzerá nevinne. Tento vzor je podpisom tichého hostiteľa: vysiela len zriedka, takže správanie fabric pri zisťovaní a obnove je dôležitejšie ako stav jeho pripojenia. Začnite jednou zamýšľanou IP, MAC a bridge domain a sledujte ďalšiu výmenu rozlíšenia.

Sledujte ďalšiu výmenu ARP alebo ND

Pri IPv4 sledujte výmenu ARP opytujúceho sa hostiteľa; pri IPv6 sledujte Neighbor Solicitation a Advertisement. Potvrďte, že požiadavka vstupuje do zamýšľaného lokálneho segmentu a zamýšľaného VNI, pretože požiadavku, ktorá nikdy nedosiahne správnu bridge domain, nemôže odpovedať žiadny proxy.

Potom sa pozrite, čo fabric o cieli vie. Trasa len podľa MAC môže identifikovať cieľ v Layer 2, zatiaľ čo proxy naň stále nemá väzbu IP-to-MAC. Sú to oddelené záznamy a kontrola jedného nič nehovorí o druhom.

Ak existuje platná väzba, proxy môže odpovedať podľa svojej politiky, ale MAC v tejto väzbe stále potrebuje aktívnu cestu preposielania. Ak väzba chýba, požiadavka musí doraziť k pripojeniu koncového bodu cez cestu flooding alebo replikácie, kým sa z odpovede môže niečo naučiť.

Dva záznamy, ktoré musia súhlasiť

MAC trasa odpovedá, kde žije ethernetová adresa. Proxy tabuľka odpovedá, ktorá IP sa mapuje na ktorú MAC. Hostiteľ, ktorý nedávno nehovoril, môže mať úplne dobrú MAC trasu a žiadnu použiteľnú položku proxy, a to je presne stav, ktorý vytvára zlyhanie rozlíšenia na zdravom pripojení.

Na vzdialenom pripojení skontrolujte, či koncový bod výmenu skutočne prijíma a odpovedá na ňu. Jeho odpoveď obnovuje lokálne učenie a príslušnú inzerciu EVPN, a preto sa zdá, že ručný ping veci opravuje: vygenerovali ste prevádzku, na ktorú fabric čakala. To tiež vysvetľuje, prečo oprava nevydrží: keď obnovená položka zostarne, koncový bod opäť utíchne. Naplánovaný ping lieči príznak a skrýva medzeru v návrhu.

Po odpovedi sledujte vybranú trasu a nainštalovaný stav preposielania späť k opytujúcemu. Úspech rozlíšenia a úspech preposielania sú dve oddelené udalosti a tiket, ktorý ich zlieva, vás pošle na nesprávnu vrstvu.

Čo štandard vlastne predpokladá

RFC 9161 opisuje dynamické učenie proxy a predvolené flooding neznámych požiadaviek ARP a ND. Úplné potlačenie tohto floodingu je obmedzené na nasadenia, ktorých predpoklady učenia alebo provisioningu ho robia bezpečným, čo je užšia podmienka, než naznačuje väčšina konfiguračných príručiek.

Fabric, ktorá očakáva novoobjavené koncové body, potrebuje funkčnú cestu pre tieto požiadavky. Ak niekto vypol flooding neznámych požiadaviek, aby znížil prevádzku BUM, tichí hostitelia sú populácia, ktorá za to platí, a príznak príde o týždne neskôr ako sťažnosť na prerušovanú dostupnosť.

Čítajte nastavenie potlačenia ako tvrdenie o tom, čo fabric sľubuje vedieť. Ak nič neposkytuje väzby, sľub neplatí pre zriedkavých odosielateľov. Porovnajte nakonfigurované potlačenie s provisioningovým systémom, ktorý ho má napájať. Keď sa tieto dva nezhodujú, fabric sa správa presne tak, ako je nakonfigurovaná, a opraviť treba očakávanie.

Obnova, starnutie a statická alternatíva

Štandard opisuje podporované sondy obnovy pred tým, než dynamické položky zostarnú. Odpovede obnovujú príslušný stav bridge a proxy; chýbajúce odpovede môžu legitímne viesť k odstráneniu a odvolaniu trasy. To nie je chyba, ktorá sa má potlačiť naťahovaním každého časovača.

Neurčité predlžovanie časovačov starnutia mení viditeľné zlyhanie za zastarané: fabric ďalej inzeruje umiestnenie, ktoré hostiteľ opustil. Použite dokumentované ovládacie prvky implementácie a vyberte životnosť, ktorá zodpovedá tomu, ako často možno rozumne očakávať, že koncový bod prehovorí.

Pre známe, spravované koncové body je statická alebo kontrolérom poskytnutá väzba legitímny druhý model. Potrebuje vlastníka, ktorý rieši výmenu a presun, pretože poskytnutý záznam sa sám neaktualizuje, keď sa hostiteľ presunie na iný port.

Čo zaznamenať pred ďalším tiketom

Uchovávajte zdroj väzby, čas poslednej obnovy, aktuálne umiestnenie a akúkoľvek udalosť odvolania vedľa MAC trasy. Tento záznam odpovedá na otázku, ktorú tiket skutočne kladie: čaká aplikácia na zistenie, spolieha sa na zastaraný stav, alebo po úspešnom rozlíšení nedokáže preposielať?

Potom rozhodnite, ktorý z troch ste ochotní prevádzkovať. Zisťovanie s floodingom, obnova s realistickou životnosťou alebo provisioning s vlastníkom sú všetky obhájiteľné. Fabric nakonfigurovaná pre jedno a očakávaná, že sa bude správať ako iné, je miesto, kde tichí hostitelia miznú.