AFI i SAFI: przeczytaj parę przed nazwą usługi

Można patrzeć, jak sesja się podnosi, jak pojawia się trasa, i wciąż czytać niewłaściwą usługę. Para liczb na początku każdego ogłoszenia, identyfikator rodziny adresów i identyfikator kolejnej rodziny adresów, decyduje, który parser czyta ładunek i która tabela trzyma wynik. Pomyl parę, a polityka importu, dopasowanie celu trasy i wyszukiwanie następnego skoku działają przeciw strukturze, której nikt nie ogłosił. Poniższa wędrówka zaczyna się przy tej parze i kończy na wyniku przekazywania.

Do której tabeli należy trasa, decydują dwie liczby

Para pojawia się dwa razy: wewnątrz zdolności wieloprotokołowej, gdzie mówca ogłasza rodzinę, i przed każdym NLRI, które ta rodzina niesie. Czyni to ją właściwością trasy, a nie ustawieniem na skrzynce źródłowej. Producenci drukują ją jako nazwę typu Address family VPNv4 Unicast, a sformułowanie przesuwa się między wydaniami, podczas gdy liczby zostają na miejscu.

Cztery kodowania obejmują prawie każdy przypadek korporacyjny: 1 z 128 dla VPN-IPv4 z etykietą MPLS, 2 z 128 dla odpowiednika IPv6, 25 z 65 dla VPLS sygnalizowanego przez BGP i 25 z 70 dla EVPN. Pierwszy błąd to założenie, że każda usługa Layer 2 stoi za 25 z 65, co ukrywa EVPN. Drugi to traktowanie dwóch rodzin IP jako jednej rodziny z dłuższym adresem, choć negocjuje się je osobno i można je przyjąć na różnych peerach. Trzeci pojawia się, gdy szablon kopiuje się z wydania, które zna tylko jedną z nich. Sprawdzenie w rejestrze rozstrzyga wszystkie trzy szybciej niż domysł zbudowany na nazwie usługi.

Traktuj cztery wiersze jako przykłady z rejestru IANA, a nie jako sam rejestr. Gdy liczba nie pasuje do niczego znanego, sprawdź ją, zanim zbudujesz wokół niej politykę.

AFI 25 niesie dwa niepowiązane formaty NLRI

Obie rodziny Layer 2 siedzą pod AFI 25 i podobieństwo na tym się kończy. NLRI VPLS w RFC 4761 section 3.2.2 niesie długość, rozróżniacz trasy, VE ID, przesunięcie bloku VE, rozmiar bloku VE i bazę etykiet, które razem nazywają punkt końcowy pseudowire i jego etykietę. EVPN zachowuje AFI 25 i przechodzi do SAFI 70, gdzie ładunkiem jest typ trasy: automatyczne wykrywanie Ethernetu, ogłoszenie MAC/IP, multicast inkluzywny, segment Ethernetu, prefiks IP. Dlatego to samo przesunięcie bajtów znaczy co innego w obu rodzinach. Parser napisany dla jednej czyta drugą bez skargi i produkuje nonsens. Para jest jedynym ostrzeżeniem, że interpretacja jest błędna.

Pole, które w jednej rodzinie oznacza przesunięcie bloku VE, nie ma odpowiednika w drugiej, a trasa ogłoszenia MAC/IP istnieje tylko w EVPN. Cytowanie atrybutu tak, jakby dotyczył obu, to sposób, w jaki przegląd zrzutu idzie źle.

Gdy ktoś wręczy ci zrzut lub tabelę producenta, zapytaj, do której rodziny należy atrybut. Potem potwierdź, że implementacja odbiorcy obsługuje tę rodzinę, a nie nazwę usługi z karty katalogowej. Dwie platformy mogą obie twierdzić, że wspierają VPLS, a implementować różne rodziny sygnalizacji. Para je rozdziela; etykieta produktu nie.

Własna rodzina adresów sesji to osobne pytanie

VPN-IPv6 jest rutynowo ogłaszany przez sesję, której połączenie TCP biegnie po IPv4, i to jest obsługiwany projekt, nie usterka. Czytanie tylko podsumowania sesji nic więc nie mówi o tym, którymi rodzinami VPN wymieniają się peery.

Rodzina NLRI, rodzina transportu i rodzina przekazywania to trzy niezależne decyzje. Router może mówić IPv4 ze swoim peerem, przyjąć osiągalność VPN-IPv6 i zainstalować trasę, której następnym skokiem jest adres IPv6 osiągalny ścieżką, której nie zamierzałeś. Każda warstwa wymaga własnego potwierdzenia. Witryny, które zgłaszają nieosiągalne cele IPv6, gdy ogłoszenia wyglądają poprawnie, zwykle utraciły rozwiązywanie następnego skoku, a nie negocjację rodzin.

Przetestuj rodzinę adresów sesji osobno, potem rodziny, które niesie, potem to, co rdzeń może przekazać. Trzymanie tych trzech osobno zapobiega częstej błędnej diagnozie, w której poprawne ogłoszenie czyta się jako dowód, że IPv6 działa od końca do końca. Dowodzi ona tylko, że jeden peer powiedział drugiemu o prefiksie.

Wynegocjowane, odebrane, zaimportowane, zainstalowane

Dla jednej oczekiwanej trasy cztery stany muszą zachodzić w kolejności, a każdy jest obserwowalny. Rodzina musi być wynegocjowana z tym peerem, trasa musi dotrzeć, cel trasy musi ją zaimportować do zamierzonego kontekstu, a następny skok musi się rozwiązać, aby trasa się zainstalowała. Pominięcie pierwszego stanu czyni pozostałe trzy bez odpowiedzi, bo niewynegocjowana rodzina nie produkuje tras do zbadania. Na platformach w stylu Cisco podsumowania rodzin i zdolności dla każdego peera to osobne polecenia.

show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family

Negocjacja pojawia się w wymianie zdolności drukowanej dla każdego peera, a ustanowiona sesja bez wylistowanej rodziny nie niesie nic z tego, o co prosiłeś. Import rozstrzygają cele tras przenoszone jako społeczności rozszerzone, więc poprawna para z błędnie wpisanym celem zostawia tabelę pustą. Instalacja zależy potem od rozwiązania następnego skoku w kontekście odbiorcy, co może zawieść, gdy każde ogłoszenie wygląda perfekcyjnie.

Potwierdź płaszczyznę danych na końcu, bo trasa w tabeli jest twierdzeniem, nie dostawą. Te same cztery stany dotyczą każdej rodziny; zmieniają się tylko polecenia i nazwy tabel.

Czego para rodzin nigdy nie dowodzi

Poprawne odczytanie pary mówi, jak interpretować informację routingu, która następuje, i to jest całe twierdzenie. Nie mówi nic o osiągalności, o polityce ani o zdrowiu płaszczyzny danych. Mieszanie obu daje pewne siebie zdania o sieci, której nikt nie zweryfikował. Niezgodność celu trasy i zepsuty następny skok wyglądają identycznie patrząc tylko na parę. Para jest instrukcją czytania, nigdy wyrokiem.

Gdy eskalujesz, umieść parę, cel trasy i rozwiązany następny skok w tej samej notatce. Następny inżynier ma wtedy trzy niezależne rzeczy do przetestowania zamiast nazwy usługi do ponownej interpretacji. Gdy brak negocjacji, widzą to od razu, zły cel zostawia import widocznie nieobecny, a nierozwiązany następny skok zostawia trasę obecną, ale bezużyteczną.