Wprowadzenie
Mówiliśmy już o IP Multicast. W tym miesiącu zamierzam zacząć omawiać tryb PIM Sparse Mode. Poprzednie artykuły, które mogą być interesujące:
- Protokoły IP Multicast
- PIM Dense Mode
Sparse Versus Dense Mode
Przypomnijmy, że PIM Dense Mode jest używany (w zasadzie), gdy multicast jest pożądany w większości lokalizacji. Tak więc początkowe pakiety multicast są zalewane wszędzie, z przycinaniem odcinając ruch do miejsc, które nie potrzebują paszy multicast. Do niedawna, PIM Dense Mode cierpiał z powodu okresowego ponownego zalewania co 3 minuty, ale w 12.1(5)T, funkcja PIM Dense Mode State Refresh złagodziła ten problem. Z tą funkcją, PIM Dense Mode jest prawdopodobnie odpowiedni dla prostej implementacji multicast. Szczególnie tam, gdzie dodatkowa kontrola PIM Sparse Mode nie jest potrzebna i gdzie sporadyczne „przypadkowe” zalewanie nie będzie bardzo szkodliwe.
PIM Sparse Mode używa jawnego podejścia do żądania, gdzie router musi poprosić o paszę multicast z wiadomością PIM Join. PIM Sparse Mode jest wskazany, gdy potrzebujesz bardziej precyzyjnej kontroli, zwłaszcza gdy masz duże ilości ruchu IP multicast w porównaniu do przepustowości. PIM Sparse Mode skaluje się raczej dobrze, ponieważ pakiety idą tylko tam, gdzie są potrzebne, i ponieważ tworzy stan w routerach tylko w razie potrzeby. Z tego powodu, został on zapisany jako Internet Experimental Protocol.
Ceną, jaką płacimy za tę dodatkową kontrolę jest łagodna dodatkowa złożoność. PIM Sparse Mode używa specjalnego routera zwanego Rendezvous Point (RP), aby połączyć źródło przepływu lub drzewo multicastowe z routerem obok odbiornika. RP jest zwykle używany tylko tymczasowo, jak zobaczymy poniżej.
Mogą być różne RP dla różnych grup multicastowych, co jest jednym ze sposobów rozłożenia obciążenia. Zazwyczaj na jedną grupę multicastową przypada jeden RP. Redundancja RP jest zaawansowanym tematem i wymaga nieco głębszej wiedzy. Jednym ze sposobów jest protokół MSDP (możliwy późniejszy artykuł w tej serii).
Przypomnijmy, że wiadomość PIM Join jest wysyłana w kierunku źródła (lub dla PIM-SM, ewentualnie w kierunku RP), w oparciu o routing unicastowy. Wiadomość Join mówi w efekcie „potrzebujemy kopii multicastów tutaj”. Łączy ona nadawcę komunikatu Join oraz routery pośredniczące z każdym istniejącym drzewem multicastowym, aż do celu komunikatu Join, jeśli jest to konieczne. Wiadomość Prune mówi w efekcie „nie potrzebujemy już tego tutaj”. Router otrzymujący wiadomość Prune sprawdza, czy ma inne interfejsy wymagające przepływu multicastu i jeśli nie, wysyła swoją własną wiadomość Prune. Jedną z zaawansowanych technik jest zorganizowanie oddzielnej i być może innej kopii informacji routingu unicast tylko dla celów multicast. Pozwala to na „sterowanie” wiadomościami Join. MultiProtocol BGP, MBGP, dla multicast, jest jednym ze sposobów, aby to zrobić (możliwy późniejszy artykuł w serii).
Podstawowy punkt Rendezvous (RP)
Widzieliśmy do tej pory, że PIM-SM używa punktu Rendezvous (RP), aby połączyć źródło i odbiorniki. Może być tylko jeden RP na grupę multicastową, a najprostsza implementacja używa jednego RP dla wszystkich grup multicastowych.
Przedyskutujmy podstawy tego, jak RP jest używany. Załóżmy, że źródło zaczyna wysyłać zanim pojawią się odbiorcy. Jeśli sprawy mają się odwrotnie, niektóre szczegóły nieco się zmieniają, ale nie jest to duża różnica.
Więc: źródło multicastu rozpoczyna wysyłanie. Jak już zauważyliśmy, nie ma żadnego protokołu ani niczego do rejestrowania źródeł w IP multicast. Źródło wysyła i to do sąsiedniego routera(ów) należy zrobienie tego co należy. W PIM-SM, sąsiedni router wie o RP. (Skąd wie, to temat na osobny artykuł.) Sąsiedni router przekazuje dane multicastowe do RP poprzez enkapsulację ich w wiadomości lub wiadomościach unicast Register. Normalny routing dostarcza rejestr do RP. RP de-enkapsuluje multicast i przesyła kopie w dół dowolnego drzewa współdzielonego (jest jedno wstępnie zbudowane, jeśli istnieją odbiorniki połączone przed rozpoczęciem wysyłania przez źródło). Jeśli są odbiorcy (interfejsy wychodzące w stanie Shared Tree), RP wysyła PIM Join z powrotem w kierunku źródła. Łączy to źródło z RP za pomocą drzewa źródłowego, SPT (S, G) Shortest Path Tree. Gdy RP odbiera multicasty wzdłuż tego SPT, wysyła Register-Stop, aby powiedzieć routerowi przy źródle, aby przestał wysyłać pakiety Register. Powodem takiego zachowania jest to, że żadne pakiety multicast nie są tracone, jeśli są już obecne odbiorniki.
Przy okazji, jeśli nie ma obecnych odbiorników, wysyłany jest komunikat Register-Stop. Następnie, gdy odbiornik pojawi się w przyszłości (IGMP do sąsiedniego routera, PIM Join z sąsiedniego routera z powrotem do RP), wtedy RP wysyła PIM Join do źródła w tym czasie.
Następujący rysunek zakłada, że istnieje źródło i aktywne odbiorniki (nie pokazane). Przedstawiony odbiornik wysyła raport IGMP do routera D. Router D wysyła następnie PIM Join w kierunku RP. Ponieważ istnieją inne odbiorniki, RP jest już dołączony do Drzewa Źródłowego (pokazanego na niebiesko) i otrzymuje przepływ multicastowy. Przekazuje on pakiety przepływu drzewa źródłowego dalej przez drzewo współdzielone, pokazane na zielono.
Więc, teraz mamy pakiety idące od źródła do RP wzdłuż drzewa źródłowego (Shortest Path Tree, SPT), oraz od RP do odbiorcy wzdłuż drzewa współdzielonego. Kiedy zagregowana przepływność pakietów (*, G) (ze wszystkich źródeł) przekroczy próg wyrażony w Kbps, wyzwala to router znajdujący się najbliżej odbiorcy, aby spróbował dołączyć do Drzewa Źródłowego. Wysyła on sygnał Join w kierunku źródła przepływu multicast. Zauważ, że poprzednie Join wysłane było w kierunku RP. Join w kierunku źródła idzie router po routerze w kierunku źródła aż napotka router, który jest już w Drzewie Źródłowym. To dodaje router w pobliżu odbiorcy do drzewa źródłowego. Gdy pakiet jest faktycznie odbierany wzdłuż tego drzewa, wysyłane jest polecenie Prune w kierunku RP. W efekcie, „dzięki, ale teraz dostaję mój multicast hurtowo, a nie detalicznie”, ponieważ ten proces wycina RP w środku.
Następujący rysunek pokazuje, jak to działa. Górne lewe czerwone strzałki pokazują dołączenie w kierunku źródła. To uruchamia górny niebieski przepływ, pakiety są przekazywane wzdłuż Drzewa Źródłowego. Dolne prawe czerwone strzałki to Prunes, ponieważ przepływ Shared Tree nie jest już potrzebny (pokazane jako zielona przerywana linia). Zauważ, że pakiety Drzewa Źródłowego docierają do Odbiorcy bardziej bezpośrednią ścieżką, generalnie z mniejszym opóźnieniem.
Przy okazji, kontrolujemy próg. Jest on konfigurowalny. Domyślnie jest to zero Kbps: odbieramy jeden pakiet i przełączamy się na Source Tree. Jeśli mamy wiele źródeł dla danej grupy multicastowej (np. telekonferencja, VoIP), to dla każdego z nich istnieje wpis (S, G) Source Tree. Jeżeli ustawimy próg jako nigdy nie aktywowany, wtedy wszystkie pakiety przechodzą przez RP (coś w rodzaju mostka połączeń konferencyjnych), używając tylko (*, G) Shared Tree. Próg jest również używany przy przełączaniu zwrotnym jak i przełączaniu. Drzewa źródłowe o niskiej szybkości (S, G) są przełączane z powrotem na drzewo współdzielone. Natężenie ruchu jest sprawdzane co minutę.
Jeżeli odbiorca chce się przyłączyć, a jego sąsiedni router jest na SPT (Source Tree), to wpis interfejsu wychodzącego Shared Tree jest kopiowany do wpisu Source Tree, co chroni przed koniecznością wysyłania ruchu do RP, a następnie „z powrotem” do routera na SPT.
Przy okazji, możesz się zastanawiać, jaki jest sens posiadania tutaj RP? Ze względu na mechanizm progowy, RP daje nam sposób na wykorzystanie Shared Tree, i kontrolować wybuchowe tworzenie informacji o stanie w routerach, jeśli wielu odbiorców dołącza w tym samym czasie.
Shared Versus Source Trees
PIM Sparse Mode (PIM-SM) może używać zarówno Shared Trees (przechodząc przez RP) i Source Trees (dla efektywnego bezpośredniego dostarczania wzdłuż „najkrótszej” ścieżki od źródła do odbiorcy). Zazwyczaj, może używać obu. Jeśli efektywne dostarczanie jest mniej ważne dla użytkownika, a zmniejszenie ilości informacji o stanie przechowywanych przez routery jest ważniejsze, wtedy PIM może być skonfigurowany tak, aby używać tylko Shared Tree.
Gdy router PIM-SM otrzymuje pakiet multicastowy, sprawdza Source Tree dla tego konkretnego adresu źródłowego i adresu grupy multicastowej (docelowego). Jeśli nie ma żadnego wpisu, sprawdza następnie, czy istnieje wpis Shared Tree (*, G) dla grupy multicastowej. Jeśli wpisy są obecne dla obu drzew, interfejs przychodzący mówi routerowi, które drzewo ma być użyte. Jeśli oba drzewa mają ten sam interfejs wejściowy, to bit RPF dla wpisu (S, G) zapobiega duplikowaniu pakietów: wskazuje to, że interfejs RPF leży wzdłuż Shared Tree.
Dla przepływu multicastowego z przynajmniej jednym aktywnym odbiorcą, ścieżka pomiędzy źródłem a RP będzie częścią drzewa źródłowego. (Zauważ, że „ścieżka między” jest tu trochę niejasna, staram się nie podawać zbyt wielu szczegółów.)
Wejścia drzewa współdzielonego połączą RP z niektórymi odbiorcami. Interfejs RPF dla (*, G) Shared Tree jest interfejsem w kierunku RP, a nie źródła grupy multicastowej. Dlatego istnieje możliwość, że drzewo źródłowe (S, G) i współdzielone (*, G) mają różne interfejsy RPF.
Wpisy drzewa współdzielonego (*, G) pokazują interfejsy, gdzie otrzymano dołączenie do RP lub interfejsy z bezpośrednio podłączonymi członkami grupy (skonfigurowane lub otrzymane przez IGMP). Wpisy Source Tree (S, G) pokazują, gdzie otrzymano Join lub Prune lub Register.
Konfiguracja PIM Sparse Mode
Podstawową częścią tego, czego potrzebujesz jest:
ip multicast-routing
interface ethernet 0
ip address 10.1.1.1.1 255.255.255.0
ip pim sparse-mode
interface ethernet 1
ip address 10.1.2.1 255.255.255.0
ip pim sparse-mode
Trzeba również wskazać każdemu routerowi RP, albo dla wszystkich grup, albo dla wybranych grup (używając list dostępu do określenia, który RP dla których grup). Można to zrobić statycznie za pomocą:
ip pim rp-address 1.2.3.4
Przyjrzymy się innym opcjom zarządzania RP w następnym artykule.
W podsumowaniu
W następnym miesiącu przyjrzymy się różnym sposobom pracy z Rendezvous Points. Możemy również poruszyć kilka innych, bardziej zaawansowanych tematów związanych z multicastem IP.
.