Protokół PIM to zestaw protokołów do transmisji multiemisji w sieci pomiędzy routerami. Relacje sąsiedzkie budowane są w taki sam sposób, jak w przypadku protokołów routingu dynamicznego. PIMv2 wysyła wiadomości Hello co 30 sekund na zarezerwowany adres multiemisji 224.0.0.13 (wszystkie routery PIM). Wiadomość zawiera liczniki wstrzymania - zwykle równe 3.5*Hello Timer, czyli domyślnie 105 sekund.
PIM wykorzystuje dwa główne tryby pracy – tryb gęsty i rzadki. Zacznijmy od trybu gęstego.
Drzewa dystrybucji oparte na źródłach.
Tryb gęsty zaleca się stosować w przypadku dużej liczby klientów należących do różnych grup multiemisji. Kiedy router odbiera ruch multiemisji, pierwszą rzeczą, którą robi, jest sprawdzenie go pod kątem reguły RPF. RPF - ta reguła służy do sprawdzania źródła multiemisji za pomocą tablicy routingu unicast. Konieczne jest, aby ruch docierał do interfejsu, za którym ten host jest ukryty, zgodnie z wersją tabeli routingu emisji pojedynczej. Mechanizm ten rozwiązuje problem pętli występujących podczas transmisji multicast.
R3 rozpozna źródło multiemisji (źródłowy adres IP) z komunikatu multiemisji i sprawdzi dwa przepływy z R1 i R2, korzystając ze swojej tabeli emisji pojedynczej. Strumień z interfejsu wskazanego w tabeli (R1 do R3) zostanie przesłany dalej, a strumień z R2 zostanie odrzucony, gdyż aby dostać się do źródła multiemisji, należy wysłać pakiety przez S0/1.
Pytanie brzmi: co się stanie, jeśli masz dwie równoważne trasy z tą samą metryką? W takim przypadku router wybierze następny przeskok spośród tych tras. Wygrywa ten, kto ma wyższy adres IP. Jeśli chcesz zmienić to zachowanie, możesz użyć ECMP. Więcej szczegółów .
Po sprawdzeniu reguły RPF router wysyła pakiet multiemisji do wszystkich swoich sąsiadów PIM z wyjątkiem tego, od którego pakiet został odebrany. Inne routery PIM powtarzają ten proces. Ścieżka, którą pakiet multiemisji przeszedł od źródła do odbiorców końcowych, tworzy drzewo zwane drzewem dystrybucji opartej na źródle, drzewem najkrótszej ścieżki (SPT) lub drzewem źródłowym. Trzy różne imiona, wybierz dowolne.
Jak rozwiązać problem, że niektóre routery nie rezygnują z jakiegoś strumienia multicast i nie ma do kogo go wysłać, a router nadrzędny go do niego wysyła. W tym celu wymyślono mechanizm Prune.
Przytnij wiadomość.
Na przykład R2 będzie kontynuował wysyłanie multiemisji do R3, chociaż R3, zgodnie z regułą RPF, porzuci ją. Po co ładować kanał? R3 wysyła komunikat PIM Prune, a R2 po odebraniu tego komunikatu usunie interfejs S0/1 z listy interfejsów wychodzących dla tego przepływu, czyli listy interfejsów, z których ten ruch powinien być wysyłany.
Poniżej znajduje się bardziej formalna definicja wiadomości PIM Prune:
Komunikat PIM Prune jest wysyłany przez jeden router do drugiego routera, co powoduje, że drugi router usuwa łącze, na którym odbierany jest komunikat Prune z określonego (S,G) SPT.
Po otrzymaniu wiadomości Prune, R2 ustawia licznik czasu Prune na 3 minuty. Po trzech minutach ponownie zacznie wysyłać ruch do czasu otrzymania kolejnej wiadomości Prune. To jest w PIMv1.
W PIMv2 dodano licznik czasu odświeżania stanu (domyślnie 60 sekund). Gdy tylko wiadomość Prune zostanie wysłana z R3, licznik czasu jest uruchamiany na R3. Po upływie tego czasu R3 wyśle wiadomość State Refresh, która zresetuje 3-minutowy licznik czasu Prune na R2 dla tej grupy.
Powody wysłania wiadomości Prune:
- Gdy pakiet multiemisji nie przejdzie kontroli RPF.
- Gdy nie ma podłączonych lokalnie klientów, którzy zażądali grupy multiemisji (Dołączenie IGMP) i nie ma sąsiadów PIM, do których można wysłać ruch multiemisji (interfejs Non-prune).
Wiadomość o przeszczepie.
Wyobraźmy sobie, że R3 nie chciał ruchu od R2, wysłał Prune i odebrał multiemisję od R1. Ale nagle kanał pomiędzy R1-R3 spadł i R3 pozostał bez multiemisji. Możesz poczekać 3 minuty, aż upłynie licznik czasu Prune na R2. 3 minuty to długo czekać, więc aby nie czekać, musisz wysłać wiadomość, która natychmiast przeniesie ten interfejs S0/1 do R2 ze stanu oczyszczonego. Ta wiadomość będzie wiadomością o przeszczepie. Po otrzymaniu wiadomości Graft, R2 odpowie potwierdzeniem przeszczepu.
Zastąpienie przycinania.
Spójrzmy na ten diagram. R1 rozgłasza multicast do segmentu z dwoma routerami. R3 odbiera i rozgłasza ruch, R2 odbiera, ale nie ma nikogo, do kogo mógłby rozgłaszać ruch. Wysyła wiadomość Prune do R1 w tym segmencie. R1 powinien usunąć Fa0/0 z listy i zatrzymać nadawanie w tym segmencie, ale co stanie się z R3? A R3 jest w tym samym segmencie, również otrzymał tę wiadomość od Prune i zrozumiał tragedię sytuacji. Zanim R1 przestanie nadawać, ustawia licznik czasu na 3 sekundy i zakończy nadawanie po 3 sekundach. 3 sekundy - dokładnie tyle czasu ma R3, aby nie stracić swojego multicastu. Dlatego R3 wysyła wiadomość Pim Join dla tej grupy tak szybko, jak to możliwe, a R1 nie myśli już o zaprzestaniu nadawania. Informacje o dołączaniu do wiadomości poniżej.
Potwierdź wiadomość.
Wyobraźmy sobie taką sytuację: dwa routery transmitują jednocześnie do jednej sieci. Otrzymują ten sam strumień ze źródła i oba transmitują go do tej samej sieci za interfejsem e0. Dlatego muszą ustalić, kto będzie jedynym nadawcą tej sieci. Do tego służą komunikaty potwierdzenia. Kiedy R2 i R3 wykryją duplikację ruchu multiemisji, to znaczy R2 i R3 odbierają multiemisję, którą same rozgłaszają, routery rozumieją, że coś tu jest nie tak. W tym przypadku routery wysyłają komunikaty Assert, które zawierają odległość administracyjną i metrykę trasy, z jaką osiągnięto źródło multiemisji - 10.1.1.10. Zwycięzca jest ustalany w następujący sposób:
- Ten z niższym AD.
- Jeśli AD są równe, to kto ma niższą metrykę.
- Jeśli jest tu równość, to ten, który ma wyższy adres IP w sieci, do której transmituje tę multiemisję.
Zwycięzca tego głosowania zostaje Wyznaczonym Routerem. Pim Hello służy również do wybierania DR. Na początku artykułu wyświetlił się komunikat PIM Hello, widać tam pole DR. Wygrywa ten, który ma najwyższy adres IP na tym łączu.
Przydatny znak:
Stół MROUTE.
Po wstępnym przyjrzeniu się działaniu protokołu PIM musimy zrozumieć, jak pracować z tabelą routingu multiemisji. Tabela mroute przechowuje informacje o tym, które strumienie zostały zażądane od klientów i które strumienie płyną z serwerów multiemisji.
Na przykład, gdy na jakimś interfejsie zostanie odebrany raport członkostwa IGMP lub złącze PIM, do tablicy routingu dodawany jest rekord typu ( *, G ):
Wpis ten oznacza, że otrzymano żądanie ruchu o adresie 238.38.38.38. Flaga DC oznacza, że multiemisja będzie działać w trybie Dense, a C oznacza, że odbiorca jest bezpośrednio podłączony do routera, czyli router otrzymał raport członkostwa IGMP i przyłączenie PIM.
Jeżeli jest zapis typu (S,G) oznacza to, że mamy strumień multiemisji:
W polu S - 192.168.1.11 zarejestrowaliśmy adres IP źródła multicast, to on będzie sprawdzany przez regułę RPF. Jeśli wystąpią problemy, pierwszą rzeczą, którą musisz zrobić, to sprawdzić w tabeli emisji pojedynczej trasę do źródła. W polu Interfejs przychodzący wskazuje interfejs, do którego odbierana jest transmisja multiemisji. W tabeli routingu emisji pojedynczej trasa do źródła musi odnosić się do określonego tutaj interfejsu. Interfejs wychodzący określa, dokąd zostanie przekierowana transmisja multiemisji. Jeśli jest pusty, oznacza to, że router nie otrzymał żadnych żądań dotyczących tego ruchu. Więcej informacji na temat wszystkich flag można znaleźć .
Tryb rzadki PIM.
Strategia trybu rzadkiego jest przeciwieństwem trybu gęstego. Gdy tryb rzadki odbiera ruch multiemisji, będzie wysyłał ruch tylko przez te interfejsy, z których wystąpiły żądania tego przepływu, na przykład komunikaty Pim Join lub IGMP Report żądające tego ruchu.
Podobne elementy dla SM i DM:
- Relacje sąsiedzkie budowane są analogicznie jak w PIM DM.
- Reguła RPF działa.
- Wybór DR jest podobny.
- Mechanizm komunikatów Prune Overrides i Assert jest podobny.
Aby kontrolować, kto, gdzie i jaki rodzaj ruchu multiemisji jest potrzebny w sieci, potrzebne jest wspólne centrum informacyjne. Naszym centrum będzie Rendezvous Point (RP). Każdy, kto chce jakiś ruch multicastowy lub ktoś zaczął odbierać ruch multicastowy ze źródła, wysyła go do RP.
Kiedy RP odbierze ruch multiemisji, wyśle go do routerów, które wcześniej zażądały tego ruchu.
Wyobraźmy sobie topologię, w której RP to R3. Gdy tylko R1 odbierze ruch z S1, hermetyzuje ten pakiet multiemisji w wiadomości rejestru PIM emisji pojedynczej i wysyła go do RP. Skąd on wie, kim jest RP? W tym przypadku jest on skonfigurowany statycznie, a o dynamicznej konfiguracji RP porozmawiamy później.
ip pim adres rp 3.3.3.3
RP sprawdzi – czy była informacja od kogoś, kto chciałby otrzymywać ten ruch? Załóżmy, że tak nie było. Następnie RP wyśle R1 wiadomość PIM Register-Stop, co oznacza, że nikt nie potrzebuje tej multiemisji, rejestracja jest odmowa. R1 nie wyśle multiemisji. Jednak host źródłowy multiemisji wyśle go, tak że R1 po odebraniu zatrzymania rejestru uruchomi licznik czasu tłumienia rejestru równy 60 sekundom. 5 sekund przed upływem tego czasu, R1 wyśle pusty komunikat rejestru z bitem rejestru zerowego (to znaczy bez kapsułkowanego pakietu multiemisji) w kierunku RP. RP z kolei zachowa się tak:
- Jeśli nie było odbiorców, odpowie komunikatem Register-Stop.
- Jeśli pojawią się odbiorcy, nie będzie on w żaden sposób na to reagował. R1, nie otrzymawszy odmowy rejestracji w ciągu 5 sekund, będzie zadowolony i wyśle wiadomość Register z enkapsulowaną transmisją multicast do RP.
Wydaje się, że już zrozumieliśmy, jak multicast dociera do RP, teraz spróbujmy odpowiedzieć na pytanie, w jaki sposób RP dostarcza ruch do odbiorców. W tym miejscu konieczne jest wprowadzenie nowej koncepcji - drzewa ścieżek korzeniowych (RPT). RPT to drzewo zakorzenione w RP, rosnące w kierunku odbiorców, rozgałęziające się na każdym routerze PIM-SM. RP tworzy go poprzez odbieranie wiadomości PIM Join i dodaje nową gałąź do drzewa. I tak robi każdy router downstream. Ogólna zasada wygląda następująco:
- Kiedy router PIM-SM odbierze wiadomość PIM Join na dowolnym interfejsie innym niż ten, za którym ukryty jest RP, dodaje nową gałąź do drzewa.
- Oddział jest również dodawany, gdy router PIM-SM odbierze raport członkostwa IGMP od bezpośrednio podłączonego hosta.
Wyobraźmy sobie, że mamy klienta multiemisji na routerze R5 dla grupy 228.8.8.8. Gdy tylko R5 odbierze raport członkostwa IGMP od hosta, R5 wysyła połączenie PIM w kierunku RP i sam dodaje interfejs do drzewa, który patrzy na hosta. Następnie R4 odbiera PIM Join od R5, dodaje interfejs Gi0/1 do drzewa i wysyła PIM Join w kierunku RP. Na koniec RP (R3) otrzymuje połączenie PIM i dodaje Gi0/0 do drzewa. W ten sposób odbiorca multiemisji zostaje zarejestrowany. Budujemy drzewo z korzeniem R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Następnie do R1 zostanie wysłane połączenie PIM, a R1 rozpocznie wysyłanie ruchu multiemisji. Należy pamiętać, że jeśli host zażądał ruchu przed rozpoczęciem transmisji multiemisji, wówczas RP nie wyśle PIM Join i w ogóle nie wyśle niczego do R1.
Jeśli nagle podczas wysyłania multiemisji host przestanie chcieć ją odbierać, gdy tylko RP odbierze PIM Prune na interfejsie Gi0/0, natychmiast wyśle PIM Register-Stop bezpośrednio do R1, a następnie PIM Prune wiadomość poprzez interfejs Gi0/1. Rejestr PIM-stop wysyłany jest metodą unicast na adres, z którego przyszedł Rejestr PIM.
Jak powiedzieliśmy wcześniej, gdy tylko router wyśle połączenie PIM do innego, na przykład R5 do R4, wówczas do R4 dodawany jest rekord:
Uruchamia się licznik czasu, który musi stale resetować komunikaty PIM Join licznika czasu, w przeciwnym razie R5 zostanie wykluczony z listy wychodzącej. R4 będzie wysyłać co 5 wiadomości PIM Join.
Przełączenie drzewa najkrótszej ścieżki.
Dodamy interfejs pomiędzy R1 i R5 i zobaczymy, jak przepływa ruch w tej topologii.
Załóżmy, że ruch był wysyłany i odbierany według starego schematu R1-R2-R3-R4-R5, a tutaj połączyliśmy i skonfigurowaliśmy interfejs pomiędzy R1 i R5.
Przede wszystkim musimy odbudować tablicę routingu unicast na R5 i teraz sieć 192.168.1.0/24 jest osiągalna poprzez interfejs R5 Gi0/2. Teraz R5, odbierając multiemisję na interfejsie Gi0/1, rozumie, że reguła RPF nie jest spełniona i bardziej logiczne byłoby odbieranie multiemisji na interfejsie Gi0/2. Powinien odłączyć się od RPT i zbudować krótsze drzewo o nazwie Drzewo Najkrótszej Ścieżki (SPT). Aby to zrobić, wysyła PIM Join do R0 przez Gi2/1, a R1 rozpoczyna wysyłanie multiemisji przez Gi0/2. Teraz R5 musi zrezygnować z subskrypcji RPT, aby nie otrzymać dwóch kopii. W tym celu wysyła do Prune wiadomość wskazującą źródłowy adres IP i wstawiającą specjalny bit - bit RPT. Oznacza to, że nie musisz wysyłać mi ruchu, mam tutaj lepsze drzewo. RP wysyła również komunikaty PIM Prune do R1, ale nie wysyła komunikatu Register-Stop. Kolejna funkcja: R5 będzie teraz w sposób ciągły wysyłał PIM Prune do RP, podczas gdy R1 będzie nadal wysyłał PIM Register do RP co minutę. Dopóki nie będzie nowych osób chcących tego ruchu, RP odmówi. R5 powiadamia RP, że w dalszym ciągu odbiera transmisję multiemisji przez SPT.
Dynamiczne wyszukiwanie RP.
Auto-RP.
Technologia ta jest własnością firmy Cisco i nie jest szczególnie popularna, ale wciąż żyje. Działanie Auto-RP składa się z dwóch głównych etapów:
1) RP wysyła wiadomości RP-Announce na zarezerwowany adres - 224.0.1.39, deklarując się jako RP dla wszystkich lub dla określonych grup. Ta wiadomość jest wysyłana co minutę.
2) Wymagany jest agent mapujący RP, który będzie wysyłał komunikaty RP-Discovery wskazujące, dla których grup którego RP należy słuchać. To na podstawie tej wiadomości zwykłe routery PIM same określą RP. Agentem mapującym może być sam router RP lub oddzielny router PIM. RP-Discovery jest wysyłane na adres 224.0.1.40 z licznikiem czasu wynoszącym jedną minutę.
Przyjrzyjmy się procesowi bardziej szczegółowo:
Skonfigurujmy R3 jako RP:
ip pim send-rp-announce pętla zwrotna 0 zakres 10
R2 jako agent mapujący:
ip pim send-rp-discovery pętla zwrotna 0 zakres 10
A na wszystkich innych będziemy oczekiwać RP poprzez Auto-RP:
ip pim autorp słuchacz
Gdy skonfigurujemy R3, zacznie on wysyłać ogłoszenie RP:
A R2, po skonfigurowaniu agenta mapującego, zacznie czekać na wiadomość RP-Announce. Dopiero gdy znajdzie co najmniej jeden RP, zacznie wysyłać RP-Discovery:
W ten sposób, gdy tylko zwykłe routery (PIM RP Listener) otrzymają tę wiadomość, będą wiedziały, gdzie szukać RP.
Jednym z głównych problemów z Auto-RP jest to, że aby otrzymywać wiadomości RP-Announce i RP-Discovery, musisz wysłać PIM Join na adresy 224.0.1.39-40, a aby wysłać, musisz wiedzieć, gdzie mieści się RP. Klasyczny problem kurczaka i jajka. Aby rozwiązać ten problem, wynaleziono tryb PIM Sparse-Dense-Mode. Jeśli router nie zna RP, działa w trybie gęstym, jeśli zna, to w trybie rzadkim. Gdy na interfejsach zwykłych routerów skonfigurowany jest tryb PIM Sparse i polecenie ip pim autorp Listener, router będzie działał w trybie Dense tylko w przypadku multiemisji bezpośrednio z protokołu Auto-RP (224.0.1.39-40).
Router BootStrap (BSR).
Ta funkcja działa podobnie do Auto-RP. Każdy RP wysyła wiadomość do agenta mapującego, który zbiera informacje o mapowaniu, a następnie przekazuje je wszystkim pozostałym routerom. Opiszmy proces podobnie do Auto-RP:
1) Po skonfigurowaniu R3 jako kandydata na RP za pomocą polecenia:
ip pim rp-kandydat pętli zwrotnej 0
Wtedy R3 nic nie zrobi, aby rozpocząć wysyłanie specjalnych wiadomości, musi najpierw znaleźć agenta mapującego. Tym samym przechodzimy do drugiego kroku.
2) Skonfiguruj R2 jako agenta mapującego:
ip pim bsr-kandydat pętli zwrotnej 0
R2 zaczyna wysyłać wiadomości Bootstrap PIM, w których wskazuje siebie jako agenta mapującego:
Wiadomość ta jest wysyłana na adres 224.0.013, którego protokół PIM używa również do innych swoich wiadomości. Wysyła je we wszystkich kierunkach i dlatego nie ma problemu z kurą i jajkiem, jak w Auto-RP.
3) Gdy tylko RP odbierze wiadomość od routera BSR, natychmiast wyśle wiadomość unicast na adres routera BSR:
Następnie BSR, po otrzymaniu informacji o RP, wyśle je multiemisji na adres 224.0.0.13, którego słuchają wszystkie routery PIM. Dlatego analogia polecenia ip pim autorp słuchacz dla zwykłych routerów spoza BSR.
Anycast RP z protokołem Multicast Source Discovery Protocol (MSDP).
Auto-RP i BSR pozwalają nam rozłożyć obciążenie na RP w następujący sposób: Każda grupa multiemisji ma tylko jeden aktywny RP. Nie będzie możliwe rozłożenie obciążenia dla jednej grupy multicast na kilka RP. MSDP robi to poprzez przydzielenie routerom RP tego samego adresu IP z maską 255.255.255.255. MSDP uczy się informacji jedną z metod: statycznej, Auto-RP lub BSR.
Na zdjęciu mamy konfigurację Auto-RP z MSDP. Oba punkty RP są skonfigurowane z adresem IP 172.16.1.1/32 w interfejsie Loopback 1 i są używane dla wszystkich grup. Dzięki RP-Announce oba routery ogłaszają się, odwołując się do tego adresu. Agent mapujący Auto-RP po otrzymaniu informacji wysyła RP-Discovery o RP z adresem 172.16.1.1/32. Mówimy routerom o sieci 172.16.1.1/32 za pomocą protokołu IGP i odpowiednio. W ten sposób routery PIM żądają lub rejestrują przepływy od RP określonego jako następny przeskok na trasie do sieci 172.16.1.1/32. Sam protokół MSDP jest przeznaczony dla samych RP w celu wymiany komunikatów na temat informacji multiemisji.
Rozważ tę topologię:
Switch6 rozgłasza ruch pod adres 238.38.38.38 i na razie wie o tym tylko RP-R1. Switch7 i Switch8 zażądały tej grupy. Routery R5 i R4 wyślą PIM Join odpowiednio do R1 i R3. Dlaczego? Trasa do 13.13.13.13 dla R5 będzie odnosić się do R1 przy użyciu metryki IGP, podobnie jak w przypadku R4.
RP-R1 wie o strumieniu i zacznie go nadawać do R5, ale R4 nic o tym nie wie, ponieważ R1 po prostu go nie wyśle. Dlatego MSDP jest konieczne. Konfigurujemy to na R1 i R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 na R1
ip msdp peer 1.1.1.1 connect-source Loopback3 na R3
Będą nawiązywać sesję między sobą, a po otrzymaniu jakiegokolwiek przepływu zgłoszą to swojemu sąsiadowi RP.
Gdy tylko RP-R1 odbierze strumień z Switch6, natychmiast wyśle wiadomość unicast MSDP Source-Active, która będzie zawierać takie informacje jak (S, G) - informacje o źródle i miejscu docelowym multiemisji. Teraz, gdy RP-R3 wie, że źródło takie jak Switch6, po otrzymaniu żądania od R4 dla tego przepływu, wyśle PIM Join do Switch6, kierując się tablicą routingu. W rezultacie R1 po odebraniu takiego połączenia PIM zacznie wysyłać ruch w kierunku RP-R3.
MSDP działa przez TCP, RP wysyłają sobie nawzajem komunikaty podtrzymujące, aby sprawdzić żywotność. Timer wynosi 60 sekund.
Funkcja podziału równorzędnych użytkowników MSDP na różne domeny pozostaje niejasna, ponieważ wiadomości Keepalive i SA nie wskazują członkostwa w żadnej domenie. Również w tej topologii testowaliśmy konfigurację wskazującą różne domeny - nie było różnicy w wydajności.
Jeśli ktoś może wyjaśnić, chętnie przeczytam w komentarzach.
Źródło: www.habr.com