Proč se MAC adresa QFX zobrazuje v EVPN, ale ne ve forwardovací tabulce

Nalezení MAC v databázi EVPN dokazuje, že byla inzerována nebo přijata jako trasa, a nic víc. Forwardovací tabulka je jiná struktura, programovaná později, takže stejná MAC se může objevit v jedné a chybět ve druhé, i když se každý protokol chová správně. Považovat tyto dva výstupy za kopie jeden druhého posílá inženýry po poruše BGP, zatímco skutečnou mezerou je importní politika nebo nevyřešený next hop. Otázka, kterou stojí za to si položit, není, zda fabric MAC zná, ale ve které fázi ji přestal předávat.

Dvě tabulky, které odpovídají na různé otázky

V Junos EVPN databáze vypisuje MAC adresy po instancích spolu s tím, jak každá přišla: naučená z access portu, přijatá v trase Type 2 nebo označená jako součást multihomingové skupiny. Referenční příručka Juniperu show evpn database pokrývá filtry po MAC a po instanci, které činí pohled čitelným. Je to shrnutí řídicí roviny klíčované instancí a MAC, ne tabulka, kterou hardware přepíná rámce.

Přepínací tabulka je onen forwardovací stav. Oba výstupy uvádějí MAC vedle kontextu VLAN nebo VNI, což je přesně důvod, proč se porovnávají řádek po řádku, a přesně důvod, proč porovnání klame. Záznam v databázi říká, že trasa existuje a byla přijata do instance; neříká nic o tom, zda ji platforma nainstalovala pro forwarding.

Trasa Type 2 nese MAC, volitelnou IP, label nebo VNI, rozlišovač trasy a next hop pojmenovávající vzdálený VTEP. Mezi kabelem a touto trasou se mohou rozbít čtyři věci: hostitel se nikdy nenaučí, trasa se nikdy neinzeruje, je odmítnuta při importu nebo se její next hop nevyřeší. Každá porucha zanechá jinou sadu naplněných tabulek, a proto lze sekvenci vůbec diagnostikovat.

Lokální učení stále probíhá první

Běžný předpoklad je, že EVPN přebírá učení MAC, takže prázdná databáze musí znamenat problém s overlayem. Lokální učení stále běží na access straně, přesně jako před existencí VXLAN: switch se naučí zdrojovou MAC povoleného rámce ve správném VLAN a službě a teprve potom pro ni vytvoří Type 2. Hostitel, který neposlal žádný relevantní rámec, nemá co inzerovat. Hostitel, jehož rámce jsou zahozeny členstvím ve VLAN, filtrem nebo neaktivním členem agregátu, vypadá z pohledu overlaye stejně.

Začněte na připojení a postupujte dopředu příkazy pouze pro čtení. Cílem je dokázat, že rámec od hostitele prošel zamýšlenou službou, protože nic níže nekompenzuje rámec, který nikdy nedorazil.

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

Vybraní členové LACP jsou důležitější než to, že je bundle aktivní, protože agregát může být aktivní na jednom členu, zatímco provoz hostitele se hashuje na linku, která je neaktivní nebo blokovaná. Čítače rozhraní oddělují tichého hostitele od hostitele, který zahazuje, protože hostitel, který nikdy nevysílá, a hostitel, jehož rámce jsou zahozeny klasifikací, zanechávají stejnou prázdnou tabulku.

Kde se vzdálená MAC ztrácí

Vzdálená MAC selhává v opačném směru, a tiše. Trasa Type 2 dorazí, ale do instance vstoupí jen tehdy, když její route target a VNI odpovídají lokální konfiguraci, a použitelná je jen tehdy, když se next hop vyřeší na dostupný VTEP. Neshoda route targetu zanechá v tabulce BGP platnou trasu, kterou žádná instance nepožaduje.

Přečtěte si tři pohledy v pořadí: existence trasy, záznam v databázi, záznam forwardingu. Příkazy níže dotazují stejnou MAC v každé fázi a ukázková adresa udržuje výstupy srovnatelné.

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

Tyto výstupy odpovídají na tři oddělené otázky. Trasa v bgp.evpn.0 bez záznamu v databázi ukazuje na importní politiku, route target nebo konfiguraci instance. Záznam v databázi bez forwardovacího záznamu ukazuje na programování platformy, což patří jiné eskalační cestě. Aktivní trasa, jejíž next hop se nevyřeší, je problém transportu nebo labelu a žádné ladění MAC ji neopraví.

Restart, který to opravil, dokazuje velmi málo

Když restart symptom odstraní, lákavý závěr je, že konfigurace musí být v pořádku. Restart přeprogramuje každou tabulku od nuly, takže skrývá i případ, kdy zastaralý záznam zastiňoval chybu politiky; porucha se obvykle vrací při další změně, bliknutí linky nebo odvolání trasy.

Před jakýmkoli servisním oknem zaznamenejte, co restart smaže. Tyto tři příkazy stačí k porovnání před a po a na zařízení nic nemění.

show evpn database instance blue
show route table bgp.evpn.0
show version

Uložte tyto výstupy spolu s datem a verzí softwaru vedle nich. Pozdější zpráva, že stejný restart už dříve pomohl, je stopa, ne důkaz, a rozdíl je vidět jen tehdy, když si někdo ponechal dřívější výstup.

Čtyři pozorování, která vyřeší většinu případů

Čtyři pozorování pokrývají téměř každý případ: připojení a jeho služba, MAC jako ukázková hodnota, stav trasy a databáze a používaná verze. Vyberte MAC, která je zjevně ukázková, aby si ji nikdo nespletl s produkční adresou: první oktet 02 označuje lokálně spravovanou unicast adresu, zbývající oktety jsou volné, a 02:00:00:00:00:5c je proto bezpečný zástupný údaj.

Pak nechte odpovědi ukázat na fázi, která selhala. Žádné učení na připojení znamená access stranu; trasa bez záznamu v databázi znamená import; záznam v databázi bez forwardovacího stavu znamená programování. Ať to vyjde jakkoli, předejte shromážděné výstupy spolu s hostitelem, rozhraním, službou a verzí, aby další inženýr mohl cestu reprodukovat, místo aby dotaz opakoval.