Dlaczego MAC QFX widać w EVPN, ale nie w tabeli przekazywania

Znalezienie MAC w bazie EVPN dowodzi, że został ogłoszony lub odebrany jako trasa, i nic więcej. Tabela przekazywania to inna struktura, programowana później, więc ten sam MAC może występować w jednej i brakować w drugiej, choć każdy protokół działa poprawnie. Traktowanie tych dwóch wyników jako kopii siebie nawzajem wysyła inżynierów na poszukiwanie usterki BGP, podczas gdy rzeczywistą luką jest polityka importu lub nierozwiązany następny skok. Pytanie, które warto zadać, nie brzmi, czy fabric zna MAC, ale na którym etapie przestał go przekazywać.

Dwie tabele odpowiadające na różne pytania

W Junos EVPN baza wymienia adresy MAC dla każdej instancji wraz ze sposobem, w jaki każdy dotarł: nauczony z portu dostępowego, odebrany w trasie Type 2 lub oznaczony jako część grupy multihoming. Dokumentacja Juniper show evpn database obejmuje filtry według MAC i instancji, które czynią widok czytelnym. To podsumowanie płaszczyzny sterowania z kluczem instancji i MAC, a nie tabela, którą sprzęt przełącza ramki.

Tabela przełączania to właśnie ten stan przekazywania. Oba wyniki wymieniają MAC obok kontekstu VLAN lub VNI, i właśnie dlatego porównuje się je linia po linii, i właśnie dlatego porównanie wprowadza w błąd. Wpis w bazie mówi, że trasa istnieje i została przyjęta do instancji; nie mówi nic o tym, czy platforma zainstalowała ją do przekazywania.

Trasa Type 2 niesie MAC, opcjonalny IP, etykietę lub VNI, wyróżnik trasy i następny skok wskazujący zdalny VTEP. Między kablem a tą trasą mogą zepsuć się cztery rzeczy: host nigdy nie zostaje nauczony, trasa nigdy nie jest ogłaszana, jest odrzucana przy imporcie albo jej następny skok nie rozwiązuje się. Każda awaria pozostawia inny zestaw wypełnionych tabel, i dlatego tę sekwencję można w ogóle zdiagnozować.

Lokalne uczenie nadal odbywa się najpierw

Powszechne założenie jest takie, że EVPN przejmuje uczenie MAC, więc pusta baza musi oznaczać problem z overlay. Lokalne uczenie nadal działa po stronie dostępu, dokładnie tak jak przed istnieniem VXLAN: przełącznik uczy się źródłowego MAC dozwolonej ramki w prawidłowym VLAN i usłudze, a dopiero potem tworzy dla niej Type 2. Host, który nie wysłał żadnej istotnej ramki, nie ma nic do ogłoszenia. Host, którego ramki są odrzucane przez członkostwo w VLAN, filtr lub nieaktywnego członka agregatu, wygląda identycznie z perspektywy overlay.

Zacznij od przyłącza i idź naprzód poleceniami tylko do odczytu. Celem jest dowód, że ramka od hosta przeszła w zamierzonej usłudze, ponieważ nic poniżej nie kompensuje ramki, która nigdy nie dotarła.

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

Wybrani członkowie LACP są ważniejsi niż to, że wiązka jest aktywna, ponieważ agregat może być aktywny na jednym członku, podczas gdy ruch hosta jest haszowany na łącze, które jest nieaktywne lub zablokowane. Liczniki interfejsu odróżniają cichego hosta od gubiącego, ponieważ host, który nigdy nie nadaje, i host, którego ramki są odrzucane przez klasyfikację, zostawiają tę samą pustą tabelę.

Gdzie ginie zdalny MAC

Zdalny MAC zawodzi w przeciwnym kierunku, i to cicho. Trasa Type 2 dociera, ale wchodzi do instancji tylko wtedy, gdy jej cel trasy i VNI pasują do konfiguracji lokalnej, i staje się użyteczna dopiero wtedy, gdy następny skok rozwiązuje się do osiągalnego VTEP. Niezgodność celu trasy pozostawia prawidłową trasę w tabeli BGP, o którą żadna instancja nigdy nie prosi.

Przeczytaj trzy widoki po kolei: obecność trasy, wpis w bazie, wpis przekazywania. Poniższe polecenia pytają o ten sam MAC na każdym etapie, a adres przykładowy utrzymuje wyniki porównywalnymi.

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

Te wyniki odpowiadają na trzy osobne pytania. Trasa w bgp.evpn.0 bez wpisu w bazie wskazuje na politykę importu, cel trasy lub konfigurację instancji. Wpis w bazie bez wpisu przekazywania wskazuje na programowanie platformy, które należy do innej ścieżki eskalacji. Aktywna trasa, której następny skok się nie rozwiązuje, jest problemem transportu lub etykiety, i żadna ilość debugowania MAC tego nie naprawi.

Restart, który to naprawił, dowodzi bardzo niewiele

Gdy restart sprawia, że objaw znika, kuszący wniosek jest taki, że konfiguracja musi być zdrowa. Restart programuje każdą tabelę od nowa, więc ukrywa też przypadek, w którym nieaktualny wpis zasłaniał błąd polityki; usterka zwykle wraca przy następnej zmianie, flappingu łącza lub wycofaniu trasy.

Przed jakimkolwiek oknem serwisowym zapisz, co restart usunie. Te trzy polecenia wystarczą do porównania przed i po, i nie zmieniają niczego na urządzeniu.

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

Zarchiwizuj te wyniki wraz z datą i wersją oprogramowania. Późniejszy raport, że ten sam restart już wcześniej pomógł, jest wskazówką, a nie dowodem, i różnica staje się widoczna tylko wtedy, gdy ktoś zachował wcześniejszy wynik.

Cztery obserwacje, które rozstrzygają większość przypadków

Cztery obserwacje obejmują prawie każdy przypadek: przyłącze i jego usługa, MAC jako wartość przykładowa, stan trasy i bazy oraz używana wersja. Wybierz MAC, który jest oczywiście przykładem, aby nikt nie pomylił go z adresem produkcyjnym: pierwszy oktet 02 oznacza lokalnie administrowany adres unicast, pozostałe oktety są wolne, a zatem 02:00:00:00:00:5c jest bezpiecznym symbolem zastępczym.

Potem pozwól odpowiedziom wskazać etap, który zawiódł. Brak uczenia na przyłączu oznacza stronę dostępu; trasa bez wpisu w bazie oznacza import; wpis w bazie bez stanu przekazywania oznacza programowanie. Cokolwiek to jest, przekaż zebrane wyniki wraz z hostem, interfejsem, usługą i wersją, aby następny inżynier mógł odtworzyć ścieżkę zamiast powtarzać zapytanie.