Protokół PIM to zestaw protokołów do przesyłania multicastu w sieci pomiędzy routerami. Relacje sąsiedztwa budowane są analogicznie jak w przypadku dynamicznych protokołów routingu. PIMv2 wysyła co 30 sekund wiadomości Hello na zarezerwowany adres multicast 224.0.0.13 (All-PIM-Routers). Wiadomość zawiera Hold Timers – zazwyczaj równy 3,5 * Hello Timer, czyli 105 sekund domyślnie.
PIM korzysta z dwóch podstawowych trybów pracy – Dense i Sparse mode. Zacznijmy od Dense mode.
Source-Based Distribution Trees.
Tryb Dense mode warto stosować w przypadku dużej liczby klientów różnych grup multicastowych. Gdy router odbiera ruch multicastowy, przede wszystkim sprawdza go pod kątem reguły RPF. RPF – ta reguła jest używana do weryfikacji źródła multicastu z unicastową tabelą routingu. Ruch musi przychodzić na ten interfejs, za którym kryje się dany host według wersji unicastowej tabeli routingu. Mechanizm ten rozwiązuje problem pojawiania się pętli podczas przesyłania multicastu.
Router R3 z wiadomości multicastowej dowiaduje się o źródle multicastu (Source IP) i sprawdzi dwa strumienie od R1 i R2 w swojej tabeli unicastowej. Strumień z tego interfejsu, na który wskazuje tabela (R1 do R3), zostanie przekazany dalej, a strumień od R2 zostanie odrzucony, ponieważ aby dotrzeć do źródła multicastu, należy wysyłać pakiety przez S0/1.
Pytanie, co się stanie, jeśli macie dwa równoważne trasy z taką samą metryką? W takim przypadku router wybierze na podstawie next-hop tych tras. Kto ma wyższy adres IP, ten wygrywa. Jeśli trzeba zmienić to zachowanie, można zastosować ECMP. Więcej informacji .
Po weryfikacji reguły RPF, router wysyła pakiet multicastowy do wszystkich swoich sąsiadów PIM, z wyjątkiem tego, od którego otrzymał dany pakiet. Pozostałe routery PIM powtarzają ten proces. Droga, którą przebył pakiet multicastowy od źródła do ostatecznych odbiorców, tworzy drzewo nazywane – source-based distribution tree, shortest-path tree (SPT), source tree. Trzy różne nazwy, wybierz dowolną z nich.
Jak rozwiązać problem, że niektóre routery nie mogły odbierać pewnego strumienia multicastowego i nie mają do kogo go wysłać, podczas gdy wysyła go wyższy router? Dla tego stworzono mechanizm Prune.
Prune Message.
Na przykład, R2 będzie kontynuował wysyłanie R3 multicast, mimo że R3 odrzuca go zgodnie z zasadą RPF. Po co obciążać kanał? R3 wysyła wiadomość PIM Prune, a R2 po otrzymaniu tej wiadomości usunie interfejs S0/1 z listy (outgoing interface list) dla tego strumienia, czyli listy interfejsów, z których należy wysyłać ten ruch.
Poniżej znajduje się bardziej formalna definicja wiadomości PIM Prune:
Wiadomość PIM Prune jest wysyłana przez jeden router do drugiego routera, aby spowodować, że drugi router usunie łącze, na którym odebrano Prune, z określonego (S,G) SPT.
Po otrzymaniu wiadomości Prune, R2 ustawia timer Prune na 3 minuty. Po trzech minutach zacznie ponownie wysyłać ruch, dopóki nie otrzyma kolejnej wiadomości Prune. To jest w PIMv1.
A w PIMv2 dodano timer State Refresh (domyślnie 60 sekund). Gdy tylko wysłano wiadomość Prune z R3, uruchamiany jest ten timer na R3. Po upływie tego timera R3 wyśle wiadomość State Refresh, która zresetuje 3-minutowy timer Prune na R2 dla tej grupy.
Powody wysyłania wiadomości Prune:
- Kiedy pakiet multicast nie przeszedł walidacji RPF.
- Kiedy nie ma lokalnie podłączonych klientów, którzy zażądali grupy multicastowej (IGMP Join) i nie ma sąsiadów PIM, do których można wysyłać ruch multicastowy (Non-prune Interface).
Wiadomość Graft.
Załóżmy, że R3 nie chciał ruchu z R2, wysłał Prune i otrzymywał multicast od R1. Ale nagle, kanał między R1 a R3 się zepsuł i R3 pozostał bez multicastu. Można czekać 3 minuty, aż Prune Timer na R2 wygasł. Czekanie 3 minut jest zbyt długie, aby nie czekać, musisz wysłać wiadomość, która natychmiast wyprowadzi dany interfejs S0/1 na R2 z stanu pruned. Taką wiadomością będzie wiadomość Graft. Po otrzymaniu wiadomości Graft, R2 wyśle odpowiedź Graft-ACK.
Prune Override.
Przyjrzyjmy się temu schematowi. R1 nadaje multicast do segmentu z dwoma routerami. R3 odbiera i nadaje ruch, R2 odbiera, ale nie ma nikogo, komu mógłby nadać ruch. Wysyła wiadomość Prune do R1 w tym segmencie. R1 powinien usunąć Fa0/0 z listy i przestać nadawać w tym segmencie, ale co stanie się z R3? A R3 jest w tym samym segmencie, również otrzymał tę wiadomość Prune i zrozumiał całą tragedię sytuacji. Zanim R1 przestanie nadawać, ustawia timer na 3 sekundy i przestaje nadawać po 3 sekundach. 3 sekundy — tyle czasu ma R3, aby nie stracić swojego multicastu. Dlatego R3 jak najszybciej wysyła wiadomość Pim Join dla tej grupy, a R1 już nie myśli o zaprzestaniu nadawania. O wiadomościach Join poniżej.
Wiadomość Assert.
Wyobraźmy sobie taką sytuację: do jednej sieci nadają od razu dwa routery. Odbierają ten sam strumień z źródła, a obydwa nadają go do jednej sieci za interfejsem e0. Dlatego muszą ustalić, kto będzie jednym jedynym nadawcą dla tej sieci. Do tego służą wiadomości Assert. Kiedy R2 i R3 wykrywają duplikację ruchu multicast, to znaczy, że na R2 i R3 przychodzi multicast, który sami nadają, routery rozumieją, że coś jest nie tak. W takiej sytuacji routery wysyłają wiadomości Assert, które zawierają Administrative Distance oraz metrykę trasy, za pomocą której osiągany jest źródło multicastu — 10.1.1.10. Zwycięzca jest określany w ten sposób:
- Ten, kto ma niższe AD.
- Jeżeli AD są równe, to ten, kto ma niższą metrykę.
- Jeżeli i tutaj jest równość, to ten, kto ma wyższy adres IP w sieci, do której nadają ten multicast.
Zwycięzca tego głosowania, router staje się Designated Routerem. Do wyboru DR również używa się PIM Hello. Na początku artykułu pokazano wiadomość PIM Hello, można zauważyć pole DR. Zwycięża ten, kto ma wyższe adresy IP na tym łączu.
Przydatna tabelka:
Tabela MROUTE.
Po wstępnym zapoznaniu się z działaniem protokołu PIM, musimy zrozumieć, jak działa tabela routingu multicast. W tabeli mroute przechowywane są informacje o tym, jakie strumienie zostały zażądane przez klientów i jakie strumienie spływają z serwerów multicastowych.
Na przykład, po otrzymaniu raportu IGMP Membership Report lub PIM Join na jakimś interfejsie, do tabeli routingu dodawany jest wpis typu (*, G):
Ten wpis oznacza, że otrzymano zapytanie o ruch z adresu 238.38.38.38. Flaga DC oznacza, że multicast będzie działać w trybie Dense mode, a S oznacza, że odbiorca jest bezpośrednio podłączony do routera, to znaczy, że router otrzymał raport członkostwa IGMP, a PIM Join.
Jeśli istnieje wpis typu (S,G), oznacza to, że mamy strumień multicast:
W polu S — 192.168.1.11, mamy zapisany adres IP źródła multicastu, to on będzie sprawdzany regułą RPF. W przypadku problemów, najpierw należy sprawdzić tabelę unicastową pod kątem trasy do źródła. W polu Incoming Interface wskazuje interfejs, na który przychodzi multicast. W tabeli trasowania unicastowego, trasa do źródła powinna odnosić się do interfejsu wskazanego tutaj. W Outgoing Interface wskazuje, gdzie multicast zostanie przekierowany. Jeśli jest pusty, oznacza to, że do routera nie wpływały żadne zapytania o ten ruch. Bardziej szczegółowe informacje o wszystkich flagach można znaleźć. .
PIM Sparse-mode.
Strategia Sparse-mode jest odwrotnością Dense-mode. Gdy Sparse-mode otrzymuje ruch multicastowy, będzie wysyłać ruch tylko przez te interfejsy, gdzie były zapytania o ten strumień, na przykład wiadomości Pim Join lub raporty IGMP z zapytaniem o ten ruch.
Podobne elementy w SM i DM:
- Relacje sąsiedztwa są budowane tak samo, jak w PIM DM.
- Reguła RPF działa.
- Wybór DR jest analogiczny.
- Mechanizm Prune Overrides i komunikaty Assert są podobne.
Aby kontrolować, кому, gdzie i jaki ruch multicastowy jest potrzebny w sieci, potrzebne jest wspólne centrum informacyjne. Takim centrum będzie Rendezvous Point (RP). Wszyscy, którzy chcą otrzymać jakiś ruch multicastowy lub którzy zaczęli otrzymywać ruch multicastowy ze źródła, wysyłają go do RP.
Gdy RP otrzyma ruch multicastowy, wyśle go tym routerom, które wcześniej prosiły o ten ruch.
Załóżmy taką topologię, gdzie RP to R3. Gdy tylko R1 otrzyma ruch od S1, encapsuluje ten pakiet multicastowy w wiadomości PIM Register typu unicast i wysyła go do RP. Skąd wie, kto to RP? W tym przypadku jest skonfigurowany statycznie, a o dynamicznej konfiguracji RP porozmawiamy później.
ip pim rp-address 3.3.3.3
RP sprawdzi, czy była jakaś informacja od kogoś, kto chciałby otrzymywać ten ruch? Załóżmy, że nie było. Wtedy RP wyśle do R1 wiadomość PIM Register-Stop, co oznacza, że nikt nie potrzebuje tego multicastu, rejestracja została odrzucona. R1 nie będzie wysyłać multicastu. Jednak źródło hosta multicastu będzie go wysyłać, więc R1 po otrzymaniu Register-Stop uruchomi timer Register-Suppression, równy 60 sekundom. Na 5 sekund przed upływem tego timera, R1 wyśle pustą wiadomość Register z bitem Null-Register (tj. bez kapsułkowanej paczki multicastowej) w kierunku RP. RP z kolei zadziała w następujący sposób:
- Jeśli odbiorców nie było i nadal nie ma, to odpowie wiadomością Register-Stop.
- Jeśli odbiorcy się pojawią, to w ogóle na nią nie odpowie. R1, nie otrzymawszy odmowy dla swojej rejestracji w ciągu 5 sekund, ucieszy się i wyśle wiadomość Register z kapsułkowanym multicastem do RP.
Już ustaliliśmy, jak multicast dociera do RP, teraz spróbujmy odpowiedzieć na pytanie, jak RP dostarcza ruch do odbiorców. Tutaj trzeba wprowadzić nowe pojęcie — drzewo ścieżki źródłowej (RPT). RPT to drzewo z korzeniem w RP, rozrastające się w kierunku odbiorców, rozgałęziające się na każdym routerze PIM-SM. RP tworzy je, otrzymując wiadomości PIM Join i dodaje nową gałąź do drzewa. I tak robi każdy niżej stojący router. Ogólna zasada wygląda następująco:
- Gdy router PIM-SM otrzymuje wiadomość PIM Join na jakimkolwiek interfejsie, z wyjątkiem interfejsu, za którym kryje się RP, dodaje nową gałąź do drzewa.
- Gałąź jest również dodawana, gdy router PIM-SM otrzymuje raport o członkostwie IGMP od bezpośrednio podłączonego hosta.
Załóżmy, że mamy klienta multicastowego na routerze R5 dla grupy 228.8.8.8. Gdy tylko R5 otrzyma raport o członkostwie IGMP od hosta, R5 wysyła PIM Join w kierunku RP, a sam dodaje do drzewa interfejs patrzący na hosta. Następnie R4 otrzymuje PIM Join od R5, dodaje do drzewa interfejs Gi0/1 i wysyła PIM Join w kierunku RP. W końcu RP (R3) otrzymuje PIM Join i dodaje Gi0/0 do drzewa. W ten sposób następuje rejestracja odbiorcy multicastu. Budujemy drzewo z korzeniem R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Po tym, zostanie wysłany PIM Join do R1, a R1 zacznie przesyłać ruch multicastowy. Ważne jest, aby zauważyć, że jeśli host zażądał ruchu przed rozpoczęciem transmisji multicastu, to RP nie wyśle PIM Join i w ogóle nie wyśle nic w kierunku R1.
Jeśli w międzyczasie, podczas przesyłania multicastu, host przestanie chcieć go otrzymywać, gdy tylko RP otrzyma PIM Prune na interfejsie Gi0/0, natychmiast wyśle PIM Register-Stop bezpośrednio do R1, a następnie wiadomość PIM Prune przez interfejs Gi0/1. PIM Register-stop jest wysyłany jako unicast na ten adres, z którego otrzymano PIM Register.
Jak już wcześniej wspomnieliśmy, gdy router wysyła PIM Join do innego, na przykład R5 do R4, to na R4 zostaje dodany wpis:
I uruchamia się timer, w którym R5 musi stale wysyłać PIM Join, w przeciwnym razie R4 wykluczy go z listy outgoing. R5 będzie wysyłać PIM Join co 60 sekund.
Switchover Shortest-Path Tree.
Dodamy interfejs między R1 a R5, aby zobaczyć, jak będzie płynąć ruch przy tej topologii.
Załóżmy, że ruch był przesyłany i odbierany według starego schematu R1-R2-R3-R4-R5, a następnie podłączyliśmy i skonfigurowaliśmy interfejs między R1 a R5.
Po pierwsze, tabela trasowania unicast na R5 zostanie przebudowana i teraz sieć 192.168.1.0/24 jest osiągana przez interfejs R5 Gi0/2. Teraz, gdy R5 odbiera multicast na interfejsie Gi0/1, zdaje sobie sprawę, że zasada RPF nie jest spełniona i lepiej będzie otrzymać multicast na Gi0/2. Musi odłączyć się od RPT i zbudować krótsze drzewo, które nazywa się Shortest-Path Tree (SPT). W tym celu wysyła PIM Join przez Gi0/2 do R1, a R1 zaczyna również przesyłać multicast przez Gi0/2. Teraz R5 musi wypisać się z RPT, aby nie otrzymywać dwóch kopii. Dlatego wysyła wiadomość Prune, wskazując adres IP źródła i wstawiając specjalny bit — RPT-bit. Oznacza to, że nie musisz mi wysyłać ruchu, mam tu lepsze drzewo. RP również wysyła wiadomości PIM Prune w kierunku R1, ale nie wysyła wiadomości Register-Stop. Kolejną cechą jest to, że R5 będzie teraz stale wysyłać PIM Prune do RP, ponieważ R1 nadal wysyła PIM Register do RP co minutę. RP, dopóki nie będzie nowych zainteresowanych tym ruchem, będzie mu odmawiać. R5 informuje RP, że nadal otrzymuje multicast przez SPT.
Dynamiczne wyszukiwanie RP.
Auto-RP.
Ta technologia jest własnościowa firmy Cisco i nie cieszy się zbyt dużą popularnością, ale wciąż funkcjonuje. 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, ogłaszając się jako RP dla wszystkich grup lub dla określonych grup. Wiadomość ta jest wysyłana co minutę.
2) Potrzebny jest agent mapowania RP, który będzie wysyłał wiadomości RP-Discovery z informacją, dla których grup który RP należy nasłuchiwać. To właśnie z tej wiadomości zwykłe routery PIM będą określać swój RP. Agent mapowania może być zarówno samym routerem RP, jak i oddzielnym routerem PIM. RP-Discovery jest wysyłane na adres 224.0.1.40 z timerem na jedną minutę.
Przyjrzyjmy się procesowi bliżej:
Skonfigurujemy R3 jako RP:
ip pim send-rp-announce loopback 0 scope 10
R2 jako agent mapowania:
ip pim send-rp-discovery loopback 0 scope 10
A na pozostałych routerach będziemy oczekiwać RP przez Auto-RP:
ip pim autorp listener
Gdy tylko skonfigurujemy R3, zacznie on wysyłać RP-Announce:
A R2 po skonfigurowaniu jako agent mapowania zacznie czekać na wiadomości RP-Announce. Tylko gdy znajdzie przynajmniej jeden RP, rozpocznie wysyłanie RP-Discovery:
W ten sposób, gdy zwykłe routery (PIM RP Listener) otrzymają te wiadomości, będą wiedziały, gdzie szukać RP.
Jednym z głównych problemów Auto-RP jest to, że aby otrzymywać wiadomości RP-Announce i RP-Discovery, należy wysłać PIM Join na adresy 224.0.1.39-40, a aby to zrobić, trzeba wiedzieć, gdzie znajduje się RP. Klasyczny problem kurczaka i jaja. Aby rozwiązać ten problem, wymyślono tryb PIM Sparse-Dense-Mode. Jeśli router nie zna RP, działa w trybie Dense-mode, jeśli zna, przechodzi w tryb Sparse-mode. Gdy na interfejsach zwykłych routerów skonfigurowany jest PIM Sparse-mode oraz polecenie ip pim autorp listener, router będzie działał w trybie Dense-mode tylko dla multicastu bezpośrednio protokołu Auto-RP (224.0.1.39-40).
Router BootStrap (BSR).
Funkcja ta działa podobnie do Auto-RP. Każdy RP wysyła wiadomość do agenta mapowania, który zbiera informacje o mapowaniu i następnie przekazuje je wszystkim innym routerom. Opiszmy proces analogicznie do Auto-RP:
1) Gdy tylko skonfigurujemy R3 jako kandydata na RP, używając polecenia:
ip pim rp-candidate loopback 0
Wówczas R3 nie będzie nic robić, aby zacząć wysyłać specjalne wiadomości, musi najpierw znaleźć agenta mapowania. W ten sposób przechodzimy do drugiego kroku.
2) Konfigurujemy R2 jako agenta mapowania:
ip pim bsr-candidate loopback 0
R2 zaczyna rozsyłać wiadomości PIM Bootstrap, w których wskazuje siebie jako agenta mapowania:
Wiadomość ta jest wysyłana na adres 224.0.0.13, który protokół PIM wykorzystuje także do innych wiadomości. Wysyła je we wszystkie strony, dlatego nie ma problemu z kurą i jajkiem, jak to miało miejsce w Auto-RP.
3) Gdy tylko RP otrzyma wiadomość od routera BSR, natychmiast wyśle wiadomość unicast na adres routera BSR:
Po tym, BSR, otrzymując informacje o RP, rozsyła je multicast do adresu 224.0.0.13, który nasłuchują wszystkie routery PIM. Dlatego też nie ma odpowiednika komendy ip pim autorp listener dla zwykłych routerów w BSR.
Anycast RP z protokołem Multicast Source Discovery Protocol (MSDP).
Auto-RP i BSR umożliwiają nam rozłożyć obciążenie na RP w następujący sposób: każda grupa multicast ma tylko jednego aktywnego RP. Nie można rozłożyć obciążenia dla jednej grupy multicast na kilku RP. MSDP realizuje to, przydzielając routerom RP ten sam adres IP z maską 255.255.255.255. MSDP uzyskuje informacje jednym z metod: statycznie, Auto-RP lub BSR.
Na obrazku mamy konfigurację Auto-RP z MSDP. Oba RP są skonfigurowane z adresem IP 172.16.1.1/32 na interfejsie Loopback 1 i używane są dla wszystkich grup. Podczas RP-Announce obie routery informują o sobie, odwołując się do tego adresu. Agent mapowania Auto-RP, otrzymując informacje, rozsyła RP-Discovery o RP z adresem 172.16.1.1/32. O sieci 172.16.1.1/32, informujemy routery za pomocą IGP i, odpowiednio. W ten sposób routery PIM żądają lub rejestrują strumienie od RP, który został wskazany jako next-hop w trasie do sieci 172.16.1.1/32. Sam protokół MSDP ma na celu umożliwienie RP wymiany informacji o multicast.
Rozważmy taką topologię:
Switch6 emituje ruch na adres 238.38.38.38 i jak na razie zna go tylko RP-R1. Switch7 i Switch8 zapytały o tę grupę. Routery R5 i R4 wyślą PIM Join na R1 i R3, odpowiednio. Dlaczego? Trasa do 13.13.13.13 w R5 będzie wskazywała na R1 z metryką IGP, tak samo jak w R4.
RP-R1 zna strumień i zacznie go nadawać w kierunku R5, a R4 nic o nim nie wie, ponieważ R1 nie wyśle go po prostu. Dlatego potrzebny jest MSDP. Konfigurujemy go 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
Zainicjują sesję między sobą i po otrzymaniu jakiegokolwiek strumienia będą informować o nim swojego sąsiedniego RP.
Gdy RP-R1 otrzyma strumień od Switch6, natychmiast wyśle komunikat MSDP Source-Active przez unicast, zawierający informacje typu (S, G) — informacje o źródle i docelowym multicastcie. Teraz, gdy RP-R3 będzie wiedział, że takim źródłem jest Switch6, w przypadku otrzymania zapytania od R4 o ten strumień, wyśle w stronę Switch6 PIM Join, kierując się tabelą routingu. W związku z tym, R1 otrzymując taki PIM Join, zacznie wysyłać ruch w kierunku RP-R3.
MSDP działa na TCP, RP wymieniają między sobą komunikaty keepalive w celu weryfikacji aktywności. Timer wynosi 60 sekund.
Funkcja podziału peerów MSDP na różne domeny pozostaje niejasna, ponieważ w komunikatach Keepalive i SA nie wskazuje się przynależności do jakiejkolwiek domeny. W tej topologii testowano również konfigurację z określeniem różnych domen — nie zauważono różnicy w działaniu.
Jeśli ktoś może wprowadzić jasność, z przyjemnością przeczytam w komentarzach.
Źródło: habr.com
