PIM-SM przez VPN: sprawdź BSR, mapowanie RP i ścieżki RPF

Tunel działa, pingi unicast go przechodzą, a odbiornik nadal pokazuje czarny ekran. We wdrożeniu PIM-SM ten objaw prawie zawsze oznacza, że jedna z czterech ścieżek kontrolnych jest zepsuta, a ścieżka danych nigdy nie była problemem. Przejdź przez poniższą listę po kolei i zatrzymaj się na pierwszym kroku, który zawodzi, bo każdy kolejny krok zależy od poprzedniego. Trzymam te pięć sprawdzeń w pliku roboczym i wklejam je do terminala, gdy przychodzi zgłoszenie o multicast, co nie pozwala diagnozie zamienić się w zgadywanie.

Zacznij od odbiornika, nie od tunelu

Odbiornik, który nigdy nie poprosił o grupę, nie tworzy żadnego stanu na żadnym routerze, więc zanim sprawdzisz cokolwiek innego, potwierdź, że przyłączenie istnieje w segmencie od strony odbiornika. Na platformach w stylu Cisco show ip igmp groups na routerze ostatniego skoku wypisuje przyłączone grupy obok interfejsu, który je usłyszał. Gdy grupy nie ma w tym wyniku, tunel jest rozproszeniem uwagi: żądanie zginęło na przełączniku dostępowym, w gnieździe hosta albo w VLAN bez queriera.

Dwie zwykłe przyczyny wyjaśniają większość brakujących przyłączeń, które widziałem: niezgodność wersji IGMP między hostem a routerem oraz wybór queriera, który trafił na przełącznik nieroutujący. Trzecia jest subtelniejsza: grupa jest przyłączona, ale w złym VLAN, bo host ma dwie karty sieciowe, a aplikacja związała się z niewłaściwą. Odbiorniki IPv6 mają ten sam problem z MLD, gdzie show ipv6 mld groups odpowiada na to samo pytanie. Żadnego z nich nie naprawia się dotknięciem tunelu, i właśnie dlatego kolejność ma znaczenie.

Gdy przyłączenie jest widoczne, potwierdź, że PIM jest włączony zarówno na interfejsie od strony odbiornika, jak i na interfejsie prowadzącym do punktu spotkania. Router z członkostwem IGMP, ale bez PIM na interfejsie nadrzędnym, będzie trzymał grupę w lokalnej tabeli i nie wyśle niczego nigdzie.

Czy zbiór BSR dociera na drugą stronę?

Komunikaty Bootstrap Router przemieszczają się skok po skoku w obrębie jednej domeny PIM, i to ten kierunek psuje się przez tunel. Kandydaci RP wysyłają swoje ogłoszenia do wybranego BSR przez unicast, więc odcinek RP-BSR zwykle przeżywa działający tunel bez zmian. Zalew komunikatów Bootstrap w drugą stronę zależy od tego, czy każdy pośredni interfejs ma włączony PIM i czy nic nie zatrzymuje komunikatów na granicy. RFC 5059 definiuje to rozprowadzanie oraz granice zasięgu administracyjnego, którym wolno je skrócić.

Instrukcja ip pim bsr-border, ACL filtrujący protokół 103 albo tunel IPsec oparty na politykach, który nie potrafi przenosić multicastu, każdy z nich przetnie zalew, pozostawiając unicast nietknięty. Właśnie ta kombinacja sprawia, że awaria wygląda jak problem z RP, choć w rzeczywistości jest problemem osiągalności, i dlatego czytam stan BSR przed konfiguracją RP.

Na routerze po drugiej stronie show ip pim bsr-router podaje wybrany BSR i wyuczony zbiór RP; jeśli wynik jest pusty, druga strona siedzi we własnej domenie i żadna konfiguracja RP nie pogodzi obu. Porównaj zakresy grup i adresy RP w show ip pim rp mapping po obu stronach tunelu. Mapowanie istniejące tylko lokalnie tworzy współdzielone drzewo, które kończy się w złym miejscu, a odbiornik czeka wiecznie.

Zgraj mapowanie RP po obu stronach tunelu

Statyczny RP, BSR i anycast-RP to trzy sposoby odpowiedzi na to samo pytanie, a mieszanie ich przez tunel to pewny sposób zbudowania domeny, która nigdy się nie zbiega. Jeśli strona główna używa BSR, a oddział statycznego ip pim rp-address wskazującego inny adres, oddział buduje swoje współdzielone drzewo w stronę RP, który nie wie o istnieniu odbiornika. Mapowanie musi się zgadzać zarówno co do zakresu grup, jak i adresu, ponieważ bardziej szczegółowy zakres wygrywa z szerszym.

Anycast-RP istnieje właśnie po to, by dwa ośrodki mogły dzielić jeden adres RP, i warto go tu wymienić, bo zmienia znaczenie „tego samego RP”. Dwa RP ogłaszające jeden adres są spójne z założenia; dwa RP ogłaszające różne adresy dla tego samego zakresu nie są, niezależnie od tego, jak zdrowy wygląda każdy ośrodek z osobna.

Dla multicastu specyficznego dla źródła w zakresie 232.0.0.0/8 RP nie jest nigdy pytany, więc puste mapowanie RP nie jest automatycznie awarią. Zdecyduj, którego modelu usługi używa aplikacja, zanim zaczniesz gonić RP, który nigdy nie był potrzebny.

Przeczytaj wyszukiwanie RPF w stronę źródła

PIM buduje drzewo, odwracając ścieżkę unicast, więc istotnym sprawdzeniem jest trasa powrotna do źródła lub powrotna do RP w przypadku drzewa współdzielonego. Przyłączenie, które przychodzi na interfejs, którego router nie uznaje za nadrzędny, jest odrzucane, a przyczyna jest zapisywana jako awaria RPF, a nie jako awaria tunelu. Na routerze oddziału z trasą domyślną przez tunel i bardziej szczegółową trasą przez WAN interfejs RPF może łatwo być interfejsem WAN, choć źródło jest osiągalne tylko przez tunel. To jedyna najczęstsza przyczyna cichego odrzucania przyłączenia.

show ip rpf 192.0.2.10 wypisuje wybrany interfejs, następny skok i trasę, która wytworzyła decyzję, i to zwykle wystarcza, by zobaczyć niezgodność. Trasa multicastu statycznego, taka jak ip mroute 192.0.2.0 255.255.255.0 tunnel0, omija wyszukiwanie unicast dla tego prefiksu, i jest to uzasadniona poprawka, gdy topologia multicastu naprawdę różni się od topologii unicast. Traktuj ją jako konfigurację do udokumentowania, a nie jako łatkę założoną w trakcie incydentu i potem zapomnianą.

Potwierdź przyłączenie poleceniami, nie pingiem

Ping dowodzi, że unicast działa, co już wiesz. Potwierdzenie od końca do końca to sekwencja, która pokazuje przyłączenie, mapowanie, sąsiada i drzewo w tej kolejności, a każde polecenie odpowiada na inne pytanie.

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

Wypełniony wpis (S,G) z rzeczywistym interfejsem wejściowym i niepustą listą wyjściową oznacza, że płaszczyzna sterowania skończyła swoją pracę. Wpis, którego interfejs wejściowy jest odczytywany jako Null, albo licznik oznaczony RPF failed, który wciąż rośnie, wskazuje z powrotem na poprzednią sekcję, a nie na tunel.

Jeśli wszystkie pięć poleceń wygląda poprawnie, a odbiornik nadal nic nie widzi, pozostałym podejrzanym jest polityka samego tunelu: krypto ACL lub reguła zapory, która pozwala na protokół routingu unicast, ale nie na PIM, IGMP ani sam ruch grupy. W tunelu IPsec opartym na politykach multicast nie jest w ogóle przenoszony, więc odpowiedzią jest projekt GRE lub VTI, a nie kolejny wyjątek w filtrze. Zapisz, które z pięciu sprawdzeń zawiodło, zanim cokolwiek zmienisz, a potem zmień tylko tę warstwę.