Niektóre trasy L2VPN znikają po dodaniu reflektorów tras

Sesje pozostają aktywne, IGP jest stabilny, a mimo to kilka tras L2VPN nigdy nie pojawia się na dwóch z czterech krawędzi dostawcy. Ten wzorzec należy do problemu odbić, a nie transportu, ponieważ zerwana sesja zawodzi całkowicie, podczas gdy ponownie użyta granica odbić zawodzi selektywnie. Fizyczny pierścień nie ma z tym nic wspólnego; logiczny graf dystrybucji to miejsce, w którym te trasy się zatrzymały. Znalezienie tego punktu nie wymaga przebudowy płaszczyzny sterowania.

Utrata jest selektywna, co zawęża poszukiwania

Cztery krawędzie dostawcy w fizycznym pierścieniu potrzebują sześciu sesji logicznych do pełnej siatki, ponieważ każdy router łączy się w parę z pozostałymi trzema. Te sesje jadą po trasowanym transporcie, więc okablowanie nic nie mówi o tym, ile jest sąsiedztw ani które z nich odbijają. Gdy dwie krawędzie tracą określony zbiór prefiksów, a wszystko inne się zbiega, kabel nie jest podejrzanym.

Selektywna utrata wskazuje na zapobieganie pętlom, politykę lub kierunek relacji, gdzie niektóre trasy przekraczają granicę, a inne są po drodze odrzucane. Całkowita utrata wskazuje na sesję lub rodzinę adresów. Rozstrzygnięcie, którą z tych dwóch widzisz, to pierwszy użyteczny krok i wymaga jednego polecenia.

Co naprawdę zmienia odbicie

Odbicie tras łagodzi regułę, że mówca iBGP nie może ponownie ogłaszać trasy nauczonej od innego mówcy iBGP. RFC 4456 wyraża wyjątek poprzez relację między mówcą a źródłem trasy, a kierunek tej relacji ma większe znaczenie, niż sugeruje większość streszczeń. Trasę nauczoną od klienta można odbić do innych klientów i do nie-klientów, natomiast trasę nauczoną od nie-klienta można odbić tylko do klientów. Przeczytaj tę asymetrię dwa razy, bo wyjaśnia, jak dodanie relacji klienta może ukryć błąd projektowy: otwiera ścieżkę, której topologia nigdy nie zamierzała.

Atrybut CLUSTER_LIST zapisuje historię odbić, a reflektor, który znajdzie własny identyfikator klastra na tej liście, musi zignorować ogłoszenie. To zapobieganie pętlom i zarazem mechanizm, który usuwa trasy, gdy identyfikatory zostaną przypadkowo użyte ponownie. ORIGINATOR_ID odgrywa pokrewną rolę, nazywając router, który jako pierwszy ogłosił trasę.

Ponownie użyte identyfikatory klastrów to sposób, w jaki trasy znikają

Mała sieć zaprasza do skrótu: nadaj każdemu routerowi identyfikator klastra równy jego loopbackowi, później dodaj jeszcze jeden reflektor i użyj ponownie istniejącego loopbacka, bo jest pod ręką. Jeśli ten identyfikator pojawi się teraz na dwóch niezależnych etapach odbić, drugi etap zobaczy własny identyfikator w CLUSTER_LIST i odrzuci trasę. Nic nie zapisuje błędu, bo odrzucenie jest prawidłową odpowiedzią na pętlę.

Zbędne reflektory obsługujące jeden klaster to uzasadniony wyjątek: dzielą identyfikator celowo, aby każdy z nich mógł obsługiwać tych samych klientów. Identyfikator musi odpowiadać projektowi odbić, a nie rozróżniać nazwy obudów.

Narysuj zamierzony graf, zanim dotkniesz jakiejkolwiek konfiguracji: kto tworzy prefiks, która relacja klienta pozwala na pierwsze odbicie, który reflektor niesie je do następnego etapu i gdzie siedzi ostatni klient. Każdy skok w tym grafie to miejsce, w którym ponownie użyty identyfikator, brakująca relacja klienta lub filtr polityki mogą zatrzymać trasę. Gdy graf jest narysowany, brakująca trasa ma lokalizację zamiast zagadki.

Oprzyj się pokusie uczynienia każdego sąsiada klientem

Szybka naprawa brakującej trasy to uczynienie każdego sąsiada klientem każdego reflektora. Propagacja wraca, a projekt przestaje ci cokolwiek mówić: mnoży trasy, które niesie każdy mówca, jednocześnie ukrywając, która relacja miała wykonać tę pracę.

Mała sieć zwykle potrzebuje jednego z dwóch kształtów. Pełna siatka iBGP to sześć sesji dla czterech routerów całkowicie bez odbić, a wyznaczona para reflektorów obsługująca pozostałe krawędzie to drugi kształt. Oba są łatwiejsze do przemyślenia niż częściowa siatka, w której każdy router odbija trochę. Wybierz kształt według skali i zachowania przy awarii, a nie według schematu okablowania.

Sprawdź rodzinę adresów, zanim obwinisz odbicia

Sesja TCP na porcie 179 dowodzi, że oba mówcy mogą rozmawiać, i nic nie mówi o tym, czy rodzina adresów VPN wymieniła choć jedną trasę. Ustal stan sesji, potem rodzinę, potem pojedynczy prefiks.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

Te trzy wyjścia oddzielają problem sąsiedztwa od problemu wymiany i od problemu brakującego prefiksu. Jeśli rodzina nie pokazuje żadnych prefiksów, sprawdź stan aktywacji i politykę eksportu sąsiada, zanim spojrzysz na odbicia. Jeśli prefiksy pojawiają się na jednej krawędzi, ale nie na drugiej, porównaj listę klastrów i originator po stronie odbierającej, a następnie przejdź graf z poprzedniej sekcji.

Trzymaj osiągalność następnego skoku i stan przekazywania poza tą kontrolą. Odbita trasa z nieosiągalnym następnym skokiem jest obecna i bezużyteczna, co wygląda jak awaria odbić, dopóki nie spojrzysz na kolumnę następnego skoku. Rozwiąż następny skok, potwierdź wpis przekazywania i dopiero wtedy zdecyduj, czy graf dystrybucji potrzebuje jeszcze jednego reflektora.