Cichy host EVPN nigdy się nie rozwiązuje: podążaj za ARP do powiązania

Punkt końcowy jest podłączony, jego port jest aktywny, a host monitorujący nadal nie może go osiągnąć. Ktoś uruchamia ping z drugiej strony i zaczyna działać, co sprawia, że problem wygląda na okresowy, a fabric na niewinną. Ten wzorzec jest sygnaturą cichego hosta: rzadko nadaje, więc zachowanie fabric przy wykrywaniu i odświeżaniu ma większe znaczenie niż stan jego połączenia. Zacznij od jednego docelowego IP, MAC i bridge domain i prześledź kolejną wymianę rozwiązywania.

Prześledź kolejną wymianę ARP lub ND

Dla IPv4 obserwuj wymianę ARP hosta żądającego; dla IPv6 śledź Neighbor Solicitation i Advertisement. Potwierdź, że żądanie trafia do docelowego segmentu lokalnego i docelowego VNI, ponieważ żądanie, które nigdy nie dociera do właściwego bridge domain, nie może zostać obsłużone przez żadne proxy.

Następnie sprawdź, co fabric wie o celu. Trasa tylko z MAC może zidentyfikować miejsce docelowe Layer 2, podczas gdy proxy nadal nie ma dla niego powiązania IP-to-MAC. To osobne rekordy, a sprawdzenie jednego nic nie mówi o drugim.

Jeśli istnieje ważne powiązanie, proxy może odpowiedzieć zgodnie ze swoją polityką, ale MAC w tym powiązaniu nadal wymaga aktywnej ścieżki przekazywania. Jeśli powiązania nie ma, żądanie musi dotrzeć do połączenia punktu końcowego ścieżką flooding lub replikacji, zanim cokolwiek nauczy się z odpowiedzi.

Dwa rekordy, które muszą się zgadzać

Trasa MAC odpowiada, gdzie mieszka adres Ethernet. Tabela proxy odpowiada, który IP mapuje się na który MAC. Host, który ostatnio nie mówił, może mieć całkowicie dobrą trasę MAC i brak użytecznego wpisu proxy, i to jest dokładnie ten stan, który powoduje błąd rozwiązywania na zdrowym połączeniu.

Na zdalnym połączeniu sprawdź, czy punkt końcowy faktycznie odbiera wymianę i odpowiada na nią. Jego odpowiedź odświeża lokalne uczenie i odpowiednie ogłoszenie EVPN, dlatego ręczny ping wydaje się naprawiać rzeczy: wygenerowałeś ruch, na który fabric czekała. To wyjaśnia też, dlaczego poprawka nie trwa: gdy odświeżony wpis się zestarzeje, punkt końcowy znowu milknie. Zaplanowany ping leczy objaw i ukrywa lukę w projekcie.

Po odpowiedzi prześledź wybraną trasę i zainstalowany stan przekazywania z powrotem w stronę żądającego. To, że rozwiązywanie się udaje, i to, że przekazywanie się udaje, to dwa osobne zdarzenia, a zgłoszenie, które je miesza, wysyła cię do niewłaściwej warstwy.

Co standard faktycznie zakłada

RFC 9161 opisuje dynamiczne uczenie proxy i domyślne flooding nieznanych żądań ARP i ND. Pełne wytłumienie tego floodingu jest ograniczone do wdrożeń, których założenia dotyczące uczenia lub provisioningu czynią je bezpiecznym, co jest węższym warunkiem, niż sugeruje większość przewodników konfiguracji.

Fabric, która oczekuje nowo wykrytych punktów końcowych, potrzebuje działającej ścieżki dla tych żądań. Jeśli ktoś wyłączył flooding nieznanych żądań, aby zmniejszyć ruch BUM, ciche hosty są populacją, która za to płaci, a objaw pojawia się tygodnie później jako skarga na okresową osiągalność.

Czytaj ustawienie wytłumienia jako stwierdzenie, co fabric obiecuje wiedzieć. Jeśli nic nie dostarcza powiązań, obietnica nie jest prawdziwa dla rzadkich nadawców. Porównaj skonfigurowane wytłumienie z systemem provisioningu, który ma je zasilać. Gdy te dwa się nie zgadzają, fabric zachowuje się dokładnie tak, jak skonfigurowano, i to oczekiwanie wymaga naprawy.

Odświeżanie, starzenie i alternatywa statyczna

Standard opisuje obsługiwane sondy odświeżania, zanim wpisy dynamiczne się zestarzeją. Odpowiedzi odświeżają odpowiedni stan bridge i proxy; brak odpowiedzi może zgodnie z prawem prowadzić do usunięcia i wycofania trasy. To nie jest błąd, który należy wytłumić, rozciągając każdy timer.

Nieograniczone wydłużanie timerów starzenia zamienia widoczną awarię na nieaktualną: fabric nadal ogłasza lokalizację, którą host opuścił. Użyj udokumentowanych mechanizmów implementacji i wybierz czas życia odpowiadający temu, jak często punkt końcowy może rozsądnie mówić.

Dla znanych, zarządzanych punktów końcowych statyczne lub dostarczone przez kontroler powiązanie jest uzasadnionym drugim modelem. Wymaga właściciela, który zajmuje się wymianą i przenoszeniem, ponieważ dostarczony rekord nie aktualizuje się sam, gdy host przenosi się na inny port.

Co zapisać przed następnym zgłoszeniem

Trzymaj źródło powiązania, czas ostatniego odświeżenia, bieżącą lokalizację i każde zdarzenie wycofania obok trasy MAC. Ten rekord odpowiada na pytanie, które zgłoszenie naprawdę zadaje: czy aplikacja czeka na wykrycie, polega na nieaktualnym stanie, czy nie potrafi przekazywać po udanym rozwiązaniu?

Potem zdecyduj, który z trzech jesteś gotów obsługiwać. Wykrywanie z floodingiem, odświeżanie z realistycznym czasem życia lub provisioning z właścicielem — wszystkie są do obrony. Fabric skonfigurowana pod jedno, a oczekiwana jako zachowująca się jak drugie, to miejsce, w którym ciche hosty znikają.