PIM-SM multicast i HSRP / VRRP

10

Muszę skonfigurować komputer, aby nasłuchiwał źródła danych multiemisji (PIM-SM). Źródła multiemisji i (anycast) punkt Rendezvous znajdują się za „adresem HSRP / VRRP” po drugiej stronie łącza WAN. (Instrukcje faktycznie mówią „HSRP / VRRP”)

Zgodnie z otrzymaną dokumentacją skonfigurowałem router ze statyczną trasą do adresu HSRP / VRRP, a druga strona dodała trasę do mojej sieci. Ruch Unicast działa dobrze, ale nie otrzymuję żadnego ruchu multiemisji. Wireshark pokazuje, że mój router nie wysyła żadnych połączeń PIM.

Co może być nie tak?

Gerben
źródło

Odpowiedzi:

7

Wiadomości PIM nie są pozyskiwane z HSRP VIP, więc sprawdzenie RPF kończy się niepowodzeniem, ponieważ HSRP VIP jest twoim sąsiadem RPF. Są na to jednak dwa sposoby.

  1. Skonfiguruj protokół routingu dynamicznego między routerem a routerami innych stron, aby HSRP nie był potrzebny.

  2. Skonfiguruj statyczne mroutes po drugiej stronie rzeczywistych adresów IP interfejsu, takich jak:

    ip mroute 0.0.0.0 0.0.0.0 1.1.1.1

Eric
źródło
2

Problem polega na tym, że routery zdalne ogłaszają się komunikatami PIM Hello ze swoich własnych adresów IP, a mój router rejestruje te adresy jako sąsiadów PIM.

Brama w tabeli routingu zawiera jednak wirtualny adres HSRP. Gdy router chce dołączyć do grupy multiemisji, szuka trasy do punktu Rendezvous, który ma wirtualny adres HSRP jako następny przeskok. Ponieważ ten adres HSRP następnego skoku nie jest jednym ze znanych sąsiadów PIM, PIM-SM RFC określa, że ​​nie należy wysyłać Join.

Zmiana trasy statycznej na faktyczny adres IP jednego z routerów HSRP sprawia, że ​​multiemisja działa, ale oczywiście czyni HSRP bezużytecznym.

Nie testowałem VRRP, ponieważ druga strona nie chciała zmieniać sieci. VRRP prawdopodobnie nie miałby tego problemu, ponieważ nie używa adresu IP routera wirtualnego, ale używa rzeczywistego adresu IP routera głównego.

Gerben
źródło
Nieaktualny obecnie RFC 2362 w rzeczywistości stwierdza „Wiadomości dołączania / czyszczenia są wysyłane tylko wtedy, gdy sąsiad RPF jest sąsiadem PIM”. Nie mogę znaleźć dokładnie tego samego w bieżącym RFC 4601, ale napisano: „Ogólnie komunikat dołączenia / czyszczenia PIM powinien zostać zaakceptowany do przetworzenia tylko, jeśli pochodzi od znanego sąsiada PIM”.
Gerben
1
... lepiej byłoby edytować dodatkowe informacje w swoim pierwotnym pytaniu, jeśli nauczyłeś się więcej od napisania Q. Lub jeśli ma to być odpowiedź na twoje własne pytanie (co jest całkowicie do przyjęcia), to potrzebuje dużo pracy, która ma sens.
Craig Constantine
Zobaczysz to samo zachowanie z VRRP, ponieważ większość nowoczesnych implementacji korzysta z VIP.
netdad
2

Być może przy użyciu statycznego mroute, który wskazuje na „prawdziwy” adres IP interfejsu, a następnie normalną trasę statyczną wskazującą na HSRP. przynajmniej dostaniesz HSRP dla emisji pojedynczej. LUB wskaż trasę mroute lub statyczną do interfejsu zamiast adresu IP.

Fredpbaker
źródło
W tym przypadku konfiguracja została zbudowana wyłącznie w celu wyświetlania informacji przychodzących za pośrednictwem multiemisji, ale w przeciwnym razie może to być poprawa.
Gerben
2

Zakładając, że jesteś w środowisku Cisco ... czy włączyłeś ip pim sparse-mode wszystkie interfejsy między tym urządzeniem a RP?

Nie zapomnij też mieć ip pim autorp listenergo, aby automatycznie znalazł RP.

Ponadto - jeśli masz nadmiarowe połączenia między tobą a RP ... Routing PIM (lub gałęzie) nie podąża tą samą ścieżką, co zwykła tabela routingu. Sprawdzą RPF (przekazywanie wstecznej ścieżki), aby upewnić się, że źródło strumienia multiemisji nadchodzi z właściwego kierunku. Ale możliwe jest, aby rezerwowym łączem HSRP był DR (wyznaczony router) po stronie PIM domu. Możesz zmienić to zachowanie, ustawiając priorytet DR. ip pim dr-priority xim wyższa wartość X, tym wyższa wartość.

Możesz również sprawdzić, czy router widzi połączenia multiemisji, wydając show ip mroutego, powinien również wyświetlić RP.

show ip pim neigh powie Ci również, czy zobaczy sąsiad nadrzędnej multiemisji

Uważam, że VRRP stosuje tę samą koncepcję, jednak nie jestem w 100% pewien, ponieważ rzadko korzystam z domyślnych bram wielu dostawców.

knotseh
źródło
„Oni” byli na Cisco, „my” na Juniper.
Gerben