PIM Stub Routing Pavel Pustowka PUS0017 Abstrakt: Tento dokument ukazuje možné řešení problematiky PIM Stub Routingu. Součástí je návrh topologie různých typů zapojení, jejich řešení a otestování. Kontrola funkcionality byla provedena v laboratorních podmínkách na směrovačích a přepínačích značky CISCO. Klíčová slova: PIM, Stub, Routing, Multicast, Cisco 1 Úvod... 2 2 Multicast... 2 2.1 Multicastové adresy... 2 2.2 IGMP - Internet Group Management Protocol... 3 2.3 Multicastové distribuční režimy... 3 2.4 Multicast Stub sítě... 3 2.5 Multicast Stub směrování... 3 3 PIM - Protocol Independed Multicast... 4 3.1 RPF - Reverse Path Forwarding... 4 3.2 Rendezvous Point (RP)... 4 3.3 PIM režimy... 5 3.4 PIM v IPv6... 7 4 Praktická část... 8 4.1 Testovací topologie... 8 4.2 PIM - SM s RP konfigurace na R1 a R2... 9 4.3 PIM DM konfigurace na R1 a R2... 9 4.4 PIM BDM konfigurace na R1 a R2... 9 4.5 PIM SSM konfigurace na R1 a R2... 9 4.6 Kontrola spojení... 10 5 Závěr... 13 6 Citovaná literatura... 13 7 Přílohy... 14 7.1 Základní konfigurace směrovačů... 14 19. dubna 2014 1/14
1 Úvod S příchodem gigabitových sítí a rostoucím provozem na sítí a služeb je nutné data efektivně směrovat od zdroje k cíli. Pro tyto účely se nám nabízí tři způsoby směrování podle toho, komu jsou určena. Prvním způsobem je UNICAST, jehož principem je směrovat data od jednoho zdroje k jednomu cíli. Další možnosti je BROADCAST, který funguje na principu jeden zdroj všechny cíle v dané sítí. Na řadu přichází jako třetí typ MULTICAST, který posílá data od zdroje ke skupině, která má zájem přijímat data. Typickým použitím jsou rozhlasová vysílání videa a hlasu, videokonference a vyhledávání určitých služeb. 2 Multicast Základní vlastností této technologie je efektivní odlehčení zátěže tak, že zdroj posílá datový provoz jedné cílové adrese (skupině) a uživatelé, kteří mají zájem přijímat toto vysílání, se připojí na adresu, na kterou zdroj vysílá. Výsledkem je vysílání jen na jednu adresu oproti UNICASTu, který vysílá na všechny cíle (adresy), které chtějí tyto data přijímat. Je třeba zdůraznit, že tok dat od zdroje k cíli je zahajován příjemcem. Výsledkem je značné odlehčení sítě, zejména snížení režií směrovačů. Rozdíly mezi technologiemi zachycuje Obrázek 1. K rozesílání provozu od zdroje se používá adresní rozsah 224.0.0.0 239.255.255.255 (třída D). Obrázek 1: Rozdíl mezi UNICASTem a MULTICASTem 2.1 Multicastové adresy Jak už bylo řečeno výše, multicast se dělí do několika skupin. Každá z těchto skupin má rezervovaný určitý rozsah IP adres. Název Rozsah Popis Lokálně linkové adresy 224.0.0.0 224.0.0.255 Reservováno pro síťové protokoly na lokální sítí Globální adresy 224.0.1.0 238.255.255.255 Pro posílání multicastových napříč internetem Source specific Multicast 232.0.0.0 232.255.255.255 Reservováno pro SSM rámcový model GLOP adresy 233.0.0.0 233.255.255.255 Rezervováno pro statické adresy pro organizace, které mají přiřazeno doménové číslo autonomního systému. Limited scope adresy 239.0.0.0 239.255.255.255 Pro privátní multicastové domény 19. dubna 2014 2/14
2.2 IGMP - Internet Group Management Protocol používá se mezi klientem a aktivním prvkem (směrovače, přepínače) IGMP slouží k registraci jednotlivých hostů do multicast skupin multicast router odesílá membership query message (host query message), aby objevil, jaké multicast skupiny mají členy na připojené síti, to se odesílá všem pomocí IP 224.0.0.1 s TTL = 1 hosté odpovídají pomocí IGMP report message, která značí, že chtějí přijímat multicast pakety pro danou skupinu designated router (designated querier) se používá u multiaccess, pro podsíť je jediný, kdo posílá host query message, pro IGMP verze 1 se volí pomocí multicast směrovacího protokolu, pro verzi 2 a 3 je to multicast router s nejvyšší IP adresou, Point-to-point linky nezobrazují informace o DR IGMP verze 3 umožňuje filtrování zdrojů, tedy aby si host řekl směrovači, které zdroje chce přijímat IGMP odhlašovací (leave) zprávy jsou IP datagramy s cílovou adresou 224.0.0.2, TTL 1 [1] 2.3 Multicastové distribuční režimy Distribuční režimy se dělí podle toho, jakým způsobem chce cíl data přijímat. Při vysílání zašle stanice multicastový paket, pro zdrojovou adresu paketu se nastaví IP adresa stanice a pro cílovou adresu se nastaví skupinová adresa. [2] 2.3.1 Anysource multicast V tomto režimu může příjemce využít libovolnou verzi IGMP protokolu pro připojení do multicastové skupiny. V routovací tabulce je skupina označována jako G. Síť pak doručí všem uživatelům ze skupiny G data z libovolného zdroje, jehož cílová adresa je G. Je náchylný na DoS útoky. [2] ASM vyžaduje alokaci skupinových adres v sítí. Každá skupina může být využitá právě jednou aplikací. Když se použijí stejné ASM pro dvě aplikace, příjemci v této skupině budou přijímat data z obou aplikací. Tento způsob může způsobit v krajních situacích problémy s příjmem správných dat. [2] 2.3.2 Source specific Mutlicast SSM je základní technologie multicastových sítí a nejlépe podporuje audio a video vysílání. Pro zapsání příjemce do skupiny je nutné využit protokol IGMPv3. Identifikace skupiny se zapisuje jako (S, G), kde S je zdroj a G skupina. [2] SSM nevyžaduje adresní skupinovou alokaci v síti, kromě zdroje v každé skupině. Různé aplikace běžící ve skupině musí mít odlišné SSM skupiny, nebo mohou využít dočasných SSM skupin, aniž by došlo k chybám v sítí. [2] 2.4 Multicast Stub sítě Jsou takové segmenty v sítí, jejichž uživatelé jsou přímo připojení v libovolné multicastové skupině, a to i přes to, že jsou připojení za uživateli, kteří v muticastové skupině nejsou. [3] 2.5 Multicast Stub směrování Multicastové směrování můžeme využít na dvou částech sítě, upstream a downstream: Upstream mezi stub a DR - stub router má plnou PIM funkcionalitu, distribuční router pracuje v pasivním režimu Downstream mezi stub routerem a uživatelem downstream rozhraní je připojeno na L2 sítě, nebo L3 rozhraní, pracuje v pasivním režimu [3] 2.5.1 Směrování mezi Stub a Distribučním směrovačem (DR) Vhodnou konfiguraci v této sítí je PIM dense režim, kde dochází k periodickému hlcení a občasnému prořezávání segmentů. Implementování PIM sparse režimu a PIM zamezí potřebě uchovávat RP záznamy ve stub směrovači a periodickému obnovování stavu sítě. [3] 2.5.2 Směrování mezi Stub a uživateli Implementováním se redukuje proces pro celkové řízení provozu pro PIM, pokud se zvyšuje počet stub sítí a také pro ochranu před DoS útoky, cílené na DR. [3] 19. dubna 2014 3/14
3 PIM - Protocol Independed Multicast Protokol je nezávislý na ostatních směrovacích unicastových protokolech, jako je OSPF, RIP, EIGRP, BGP a statických cestách. PIM využívá unicastovou směrovací techniku k forwardování multicastu za pomocí RPF funkce. 3.1 RPF - Reverse Path Forwarding Reverse Path Forwarding je metoda šíření multicast paketů od zdroje vysílání dolů po distribučním stromu. K určení rozhraní, kterými se má příchozí multicast paket dále šířit, slouží běžná (unicast) směrovací tabulka. Aby bylo zajištěno šíření každého multicast paketu od kořeni k listům distribučního stromu, nezpůsobení zacyklení multicast paketů ve smyčce a pokud možno vyloučení vícenásobného vysílání téhož multicast paketu na segment, postupuje směrovač při přijetí multicast paketu podle následujícího pravidla (tzv. RPF Check) [4] 3.1.1 RPF Check Pokud paket přišel z rozhraní, které se podle směrovací tabulky používá pro směrování paketů ke zdrojové adrese multicastového paketu, paket se rozešle na downstream rozhraní. V opačném případě se paket zahodí. [4] 3.2 Rendezvous Point (RP) Setkávací místo pro zdroje a příjemce multicastového provozu (obecně známé místo pro obě strany), jedná se společný o kořen pro sdílené stromy, zdroje multicastu posílají provoz na tento bod a ten je přeposílá přes sdílené stromy všem členům skupin, díky RP se lépe využijí síťové zdroje, ale nezaručuje optimální cestu. [1] 19. dubna 2014 4/14
3.3 PIM režimy 3.3.1 Sparse Mode - PIM-SM Vychází z představy, že klienti, kteří chtějí přijímat multicast, se v síti nachází velmi řídce. Takže Sparse mode posílá provoz pouze směrovačům, kteří si o něj požádají. Používá jednosměrné sdílené stromy s kořenem v RP a může vytvářet stromy nejkratších cest pro zdroje, vyžaduje na síti Rendezvous Point (RP). Zdroje posílají multicast přímo připojeným směrovačům (DR), DR (směrovač s nejvyšší IP) je zabalí a jako unicast pošle na RP, ten je posílá členům multicast skupiny. RP oznamuje zdroje a vytváří cestu od zdroje ke členům skupiny, teprve potom posílá multicast datagramy. Rozšířený směrovací protokol pro multicast. Použijeme, pokud ostatní směrovače jsou různé. Je dobře škálovatelný. Směrovač se musí přihlásit do skupiny, aby přijímal provoz. [1] Příjemce 2 R3 IGMPv2 S = Zdroj R1 RP Příjemce 1 R2 IGMPv2 Obrázek 1: Zapojení v režimu PIM-SM 3.3.2 Dense Mode - PIM-DM Dense mode vychází z představy, že téměř všichni chtějí provoz přijmout, takže jej odesílá do všech směrů (na všechny směrovače mimo toho, od kterého přišel). Pokud některý sousední směrovač provoz nechce, tak to musí oznámit. Vytváří strom nejkratších cest, používá flood and prune metodu (nejprve zaplaví doménu multicastem a pak ořezává větve, kde nejsou příjemci). Rozhraní se přidávají do multicast směrovací tabulky na směrovači. Špatně škálovatelný, je ideální pro LAN, kde jsou členové hustě umístěni v síti. [1] Příjemce 2 R3 IGMPv2 S = Zdroj R1 RP Příjemce 1 R2 IGMPv2 Obrázek 2: Příklad zapojení PIM-DM 19. dubna 2014 5/14
3.3.3 Sparse-Dense Mode - PIM-SDM Pokud máme Rendezvous Point (RP), tak funguje jako PIM-SM, pokud ne, tak funguje jako PIM-DM. [1] 3.3.4 Bidirectional Mode - PIM-BIDIR Vytváří obousměrné sdílené stromy, ale nikdy ne strom nejkratších cest, takže může mít delší end-end vzdálenost, ale dobře škáluje. [1] Příjemce 2 R1 RP R3 IGMPv2 S = Zdroj R2 IGMPv2 Příjemce 1 Obrázek 3: Příklad zapojení PIM-BDM S = Zdroj 3.3.5 Source Specific Multicast - PIM-SSM Vytváří stromy, které mají kořen pouze v jednom zdroji. Adresa vysílače je známá a příjemci se registrují přímo ke zdroji vysílání. [1] Příjemce 2 R3 IGMPv3 S = Zdroj R1 Příjemce 1 R2 IGMPv3 Obrázek 4: Příklad zapojení PIM-SSM 19. dubna 2014 6/14
3.4 PIM v IPv6 Rozdíl oproti 32 bitové verzi IP je v tom, že se nepoužívá hustý režim (dense mode). Nepoužívá se také kombinovaný režim sparse-dense. Ve verzi IPv6 se používají pouze možnosti PIM SSM, Bidirectional a Sparse režim. Pokud multicastová skupina obdrží SSM rozsah, PIM použije SSM režim, což je v podstatě sparse režim bez RP a bez značení zpráv a stavů typu (*, G). IOS ignoruje jakékoliv nastavení RP pro skupiny v SSM rozsahu. Pokud skupina není v SSM, ale router zná adresu RP pro skupinu, skupina je označena nastavením RP. Tento RP se může učit dynamicky přes BSR, statickou konfiguraci nebo AutoRP. BSR a statická konfigurace je dostupná jak pro IPv4 tak IPv6, AutoRP jenom pro IPv4. Pokud IOS nezná RP pro skupinu, použije výchozí režim pro skupinu. V IPv4 je to hustý režim. V IPv6 je to řídký režim. PIM sparse režim bez RP je velmi podobný PIM-SSM, rozdíl je ve značení skupiny (*, G), ale RPF je nefunkční. Jakmile se dozví směrovač o RP pro skupinu, RPF začne fungovat správně. 19. dubna 2014 7/14
4 Praktická část 4.1 Testovací topologie Pro ověření čtyř variant PIM popsaných výše jsem zvolil následující topologii. Jako směrovací protokol jsem použil OSPF. Pro otestování multicastového provozu jsem použil program iperf a wireshark. Topologii jsem testoval na směrovačích CISCO řady 2800 s IOS verzí 15.1. Základní konfigurace směrovačů včetně OSPFje popsána v přílohách. Obrázek 5: Testovací topologie 4.1.1 Zdroj - generování multicastového provozu # iperf -c 232.0.0.1 -u -T 32 -t 10 -i 1 Obrázek 6: Ukázka generování multicastu (vysílání) 4.1.2 Cíl - naslouchání multicastového provozu # iperf -s -u -B 232.0.0.1 -i 1 Obrázek 7: Ukázka naslouchání multicastu (přijímání) 19. dubna 2014 8/14
4.2 PIM - SM s RP konfigurace na R1 a R2 (config) # interface FastEthernet0/0 (config-if) # ip pim sparse-mode (config) # interface Serial0/1/0 (config-if) # ip pim sparse-mode (config) # ip pim rp-address 10.1.1.1 4.3 PIM DM konfigurace na R1 a R2 (config) # interface FastEthernet0/0 (config-if) # ip pim dense-mode (config) # interface Serial0/1/0 (config-if) # ip pim dense-mode 4.4 PIM BDM konfigurace na R1 a R2 (config)# interface FastEthernet0/0 (config-if) # ip pim sparse-mode (config) # interface Serial0/1/0 (config-if) # ip pim sparse-mode (config) # ip pim bidir-enable (config) # ip pim rp-address 10.1.1.1 bidir 4.5 PIM SSM konfigurace na R1 a R2 (config) # interface FastEthernet0/0 (config-if) # ip pim sparse-mode (config) # interface Serial0/1/0 (config-if) # ip pim sparse-mode (config) # ip pim ssm default 4.5.1 Směrovač R2 (config) # interface FastEthernet0/0 (config) # ip igmp join-group 232.0.0.1 source 10.1.1.2 19. dubna 2014 9/14
4.6 Kontrola spojení Pro ověření komunikace spojení jsem využil síťový analyzátor wireshark, který jsem spustil na straně klienta a očekával datový tok UDP na transportní vrstvě. Současně začal IGMP protokol posílat reporty. Ověřit spojení pomohl také program iperf. Takto jsem ověřil všechny čtyři varianty PIM. Obrázek 8: Wireshark příjem multicastového toku na UDP Obrázek 9: Wireshark IGMP protokol reporting u příjemce 4.7 Analýza PIM protokolu Příkazem debug ip pim jsem zapnul vypisování informací o PIM protokolu do konzole. 4.7.1 PIM SM Na Chyba! Nenalezen zdroj odkazů. můžeme vidět registraci RP ve směrovači R1. Hned po tomto kroku bylo spuštěno multicastové vysílání. V momentě, kdy chtěl klient přijímat data, R2 poslal žádost o propuštění dat směrem ke klientovi, Obrázek 11. Obrázek 10: R1 - registrace RP Obrázek 11: R2 - zaslání požadavku k příjmu směrem k R1 Směrovač R1 tuto informaci zachytil a propustil data směrem k příjemci přes R2. Dalším krokem bylo odpojení klienta ze skupiny, což se projevilo zasláním PRUNE zprávy na R1, Obrázek 12. Na Obrázek 13 vidíme příjem PRUNE zprávy, která způsobila odstřižení vysílání dat k R2. Obrázek 12: Odpojení klienta ze skupiny, R2 zasílá PRUNE zprávu 19. dubna 2014 10/14
Obrázek 13: Příjem PRUNE zprávy na R1 4.7.2 PIM DM Při této konfiguraci R1 nejprve propustil data směrem ke klientovi přes R2, R2 však nepožadoval data a tak zaslal PRUNE zprávu. Na Obrázek 14 můžeme přesně vidět, co dělá R2, jestliže přijme multicastová data, aniž by předtím o ně požádal. Obrázek 14: R2 - zaslání PRUNE zprávy k R1 Obrázek 15: R1 - příjem PRUNE zprávy z R2 V okamžiku zapsání klienta do skupiny se na R2 generuje zpráva GRAFT 1, která se zasílá na R1. Tato zpráva umožnila propuštění multicastového toku ke klientovi skrze R2. Obrázek 16: R2 - zaslání GRAFT zprávy a následné potvrzení Dále následovalo odpojení klienta ze skupiny, což se projevilo zasláním PRUNE zprávy na R1, Obrázek 17. Router R1 tuto zprávu přijal a větev zaříznul. Obrázek 17: R2 zaslání PRUNE zprávy směrovači R1 4.7.3 PIM BIDIR Tento režim jsem otestoval tak, že na obou koncích trasy byl jak zdroj vysílání, tak příjemce. Na Obrázek 18 vidíme sestavování nové multicastové skupiny zasláním JOIN zprávy pro zdroj 224.0.2.1 na R1. Následně R1 přijmul zprávu JOIN a otevřel spojení pro druhou multicastovou skupinu. Obrázek 18: R2 - zaslání Join zprávy směrem k R1 1 Graft je re-join zpráva, zasílá se v případě, pokud byla větev předtím zaříznutá. 19. dubna 2014 11/14
Obrázek 19: R1 - přepnutí rozhraní 0/1/0 do stavu Forward Dále mě zajímalo co děje, pokud příjemci na obou koncích ukončí příjem skupinového vysílání. Klient v první skupině (224.0.2.1) ukončuje spojení a tudíž je zaslána zpráva směrovačem R2 na R1, Obrázek 20. U druhé skupiny (224.0.2.2) nevidíme PIM zprávu a to z toho důvodu, že je klient připojený hned za R1, který je současně RP. Odhlášení ze skupiny provede IGMP protokol. Na obrázcích toto nevidíme, protože nebyl zapnutý IGMP debugging. PIM zprávu typu PRUNE bychom viděli, pokud by byly zapojeny tři směrovače v sérii a prostřední by byl RP. Jediné co vidíme pro druhou skupinu je následné zaříznutí spojení od R1, Obrázek 21. Na Obrázek 22 je výpis ze směrovací tabulky pro multicast. Můžeme tam vidět obě registrované skupiny. Obrázek 20: R2 zaslání PRUNE zprávy na R1 pro první skupinu Obrázek 21: R1 odpověď na ukončení příjmu ve druhé skupině Obrázek 22: Výpis z multicastové směrovací tabulky 4.7.4 PIM SSM Po konfiguraci multicastového zapojení jsem vymazal záznamy ze směrovací tabulky pro multicast a zapnul výpisy IGMP protokolu do konzole. Na Obrázek 23 vidíme sestavení skupiny a následné zaslání na R1. Obrázek 23: R2 zaslání JOIN zprávy na R1 Obrázek 24: R2 přidání skupiny do směrovací tabulky pro multicast Jelikož SSM běží v řídkém režimu, tak směrovače, které chtějí přijímat zašlou požadavek, Obrázek 25. Na Obrázek 26 vidíme odhlášení klienta ze skupiny pomocí IGMP zprávy. Obrázek 25: R2 zaslání JOIN zprávy pro umožnění vysílání 19. dubna 2014 12/14
Obrázek 26: R2 odhlášení klienta ze skupiny 5 Závěr Ve všech režimech PIM se podařilo přijímat generovaný multicastový provoz ze zdroje včetně obousměrného režimu. Tímto jsem otestoval a ověřil metody skupinového vysílání. Ověřil jsem si také, jak to chodí v se skupinovým vysíláním v praxi. Ze získaných informací během vytváření tohoto projektu jsem usoudil, že se hustý režim už dnes tak často nebude používat. Je to z toho důvodu, že není podporován v IPv6 a už není tak efektivní jako PIM SSM. Řídký režim v konfiguraci SSM nebo čistý SPARSE jsou zřejmě nejpoužívanější varianty skupinového vysílání v internetu. Hustý režim se spíše hodí do malých sítí nebo LAN. V těchto sítích se také hodí obousměrný režim, pokud máme hodně zdrojů vysílání, strom se pak vytváří efektivněji. Zvolená topologie s dvěma směrovači byla dostačující, PIM protokol se mezi nimi distribuoval a z vypisovaných zpráv na jednotlivých směrovačích jsem pochopil jeho funkcionalitu. Pro obousměrný režim by bylo lepší využít tři směrovače, ale i tak se dvěma komunikace pracovala správně. 6 Citovaná literatura 1. BOUŠKA, P. TCP/IP - skupinové vysílání IP Multicast a Cisco. In: http://www.samuraj-cz.com/ [online]. Dostupné také z: http://www.samuraj-cz.com/clanek/tcpip-skupinove-vysilani-ip-multicast-a-cisco/ 2. CISCO. IP Multicast Technology Overview. Cisco [online]. verze 10. Prosince 2009. Dostupné také z: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_pim/configuration/15-s/imc-pim-15-sbook/imc_tech_oview.pdf 3. CISCO. Implementing Multicast Stub Routing. Cisco [online]. verze 1. Ledna 2012. Dostupné také z: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_pim/configuration/15-s/imc-pim-15-sbook/imc_stub_routing.pdf 4. GRYGÁREK, P. IP Multicast. In: Směrované a přepínané sítě [online]. Dostupné také z: http:// www.cs.vsb.cz/grygarek/sps/lect/multicast/multicast.html 19. dubna 2014 13/14
7 Přílohy 7.1 Základní konfigurace směrovačů Nastavení směrovacího protokolu OSPF a adresace rozhraní včetně výchozího nastavení pro všechny směrovače 7.1.1 Společně pro směrovač R1 a R2 (config) # ip multicast-routing (config) # router ospf 1 (config-router) # network 10.1.1.0 0.0.0.3 area 0 (config-router) # network 172.16.32.0 0.0.0.3 area 0 (config-router) # network 192.168.1.0 0.0.0.255 area 0 7.1.2 Směrovač R1 (config) # hostname R1 (config) # interface FastEthernet0/0 (config-if) # ip address 10.1.1.1 255.255.255.252 (config-if) # ip ospf 1 area 0 (config-if) # no shutdown (config) # interface Serial0/1/0 (config-if) # ip address 172.16.32.1 255.255.255.252 (config-if) # ip ospf 1 area 0 (config-if) # clock rate 128000 (config-if) # no shutdown 7.1.3 Směrovač R2 (config) # hostname R2 (config) # interface FastEthernet0/0 (config-if) # ip address 192.168.1.1 255.255.255.0 (config-if) # ip ospf 1 area 0 (config-if) # no shutdown (config) # interface Serial0/1/0 (config-if) # ip address 172.16.32.2 255.255.255.252 (config-if) # ip ospf 1 area 0 (config-if) # clock rate 128000 (config-if) # no shutdown 7.1.4 Příkazy pro ladění # show ip pim int # show ip pim neighbor # show ip igmp groups # show ip mroute 19. dubna 2014 14/14