PIM Dense mode State Refresh

PIM Dense mode State Refresh Radim Holek, HOL0123 Abstrakt: Tato práce se zabývá prozkoumáním volby PIM Dense mode State refresh jako proaktivním opatřením proti periodickému floodingu. Klíčová slova: PIM, PIM DM, State refresh, Multicast 1 Úvod... 2 2 PIM DM Signalizace... 3 3 Konfigurace... 4 4 Analýza fungování State refresh... 5 4.1 Analýza State refresh zpráv... 5 4.1.1 Analýza na segmentu připojeném k původci zpráv... 5 4.1.2 Analýza na vzdáleném segmentu... 6 5 Srovnání provozu... 7 5.1 Provoz na podsíti 2... 7 5.2 Provoz na podsíti 3... 8 6 Ověření chování... 9 7 Závěr... 10 8 Reference... 11 9 Přílohy... 12 Duben 2014 1/12

1 Úvod Protocol Independent Multicast (PIM) je multicastový směrovací protokol nezávislý na použitém směrovacím protokolu pro unicast. Jedna z jeho implementací je Dense mode (PIM DM), který přepokládá, že každý segment sítě bude mít nějaké přijímače pro každou skupinu multicastového provozu. Posílání provozu do těch segmentů, které nemají žádné přijímače, způsobuje nadbytečné zatížení sítě a je tedy nechtěné. Proto je nutné signalizovat, že se žádný přijímač na daném segmentu nenachází a prořezat směrovací strom. Tato signalizace může ovšem vést k periodické záplavě sítě, protože se nemůžeme spoléhat na dobré chování přijímačů a musíme provádět znovuvytvoření prořezání stromu periodicky. Možností, jak zabránit tomuto chování, může být volba State refresh. Cílem této práce je prozkoumat tuto volbu, analyzovat její signalizaci, porovnat chování sítě s a bez této volby, ověřit zda se chová podle teoretických předpokladů a zjistit, kdy je vhodné ji použít. V práci se nejprve krátce představím způsob prořezávání směrovacího stromu u protokolu PIM, poté se budu podrobněji věnovat analýze State refresh volby a jejich zpráv a nakonec provedu srovnání provozu na stejné síti bez a s volbou State refresh. Duben 2014 2/12

2 PIM DM Signalizace Jako každý multicastový protokol, musí i PIM DM vytvořit směrovací strom a k tomu je potřeba signalizace mezi směrovači. PIM DM ve verzi 2 využívá k signalizaci vlastní protokol s číslem IP 103 a zprávy posílá na adrese 224.0.0.13. Mezi nejdůležitější zprávy tohoto protokolu patří: Hello, Assert, Prune, Graft a State Refresh. Hello - Jak už název napovídá, tato zpráva se používá k informování sousedních směrovačů o existenci. Assert - Při směrování multicastového provozu nechceme, aby na jeden segment sítě vysílalo více směrovačů. K tomu slouží tyto zprávy. Vysílačem se stane směrovač s menší metrikou ke zdroji a v případě shody směrovač s vyšší IP adresou na rozhraní, které směřuje do segmentu. Tyto zprávy je třeba opakovat, protože se topologie může změnit. Běžně se opakují co 3 minuty. Prune (prořezat) - Protože některé segmenty sítě (nejspíše listy směrovacího stromu) nemusí mít přijímače, je zbytečné posílat pakety do tohoto segmentu a je potřeba provést prořezání směrovacího stromu. Tyto zprávy využívá směrovač k tomu, aby dal svému rodiči (v směrovacím stromu) vědět, že nemá žádné přijímače (o čem se dozví díky IGMP - Internet Group Management Protocol). Běžně se opakují každé 3 minuty. Graft (roubovat) - Tyto zprávy se posílají, když se přihlásí přijímač na části stromu, která již byla prořezána. Prosílají se proto, aby přijímač nemusel čekat na vypršení časového limitu pro platnost Prune zpráv. State refresh - Z výše uvedeného je jasné, že se v (zejména velkých) sítích, bude každé 3 minuty opakovat záplava zpráv PIM protokolu. Toto chování může být nežádoucí. State refresh slouží k jejich nahrazení. Podrobnější analýza State refresh zpráv je provedena v kapitole 4.1. Duben 2014 3/12

3 Konfigurace PIM ke svému provozu využívá směrovací tabulku pro unicast, proto je potřeba nejprve nakonfigurovat směrovací protokol pro unicast (např. OSPF) nebo statické směrování. Následující konfigurace je platná pro směrovače Cisco, pro jiné platformy se může lišit. Nejdříve je potřeba povolit směrování multicastu a povolit State refresh (standardně je to povoleno): (config)#ip multicast-routing (config)#no ip pim state-refresh disable Dále na všech rozhraních, na které potřebujeme směrovat multicastový provoz (PIM DM), nastavit dense mode: (config-if)#ip pim dense-mode Původce State refresh zpráv nastavíme pouze na rozhraních směřujících do segmentu, kde jsou zdroje provozu. Nastavením na jiných rozhraních nic nezískáme: (config-if)#ip pim state-refresh origination-interval [interval posílání zpráv] Tímto je konfigurace dokončena. Pro ověření může využít tyto výpisy: #show ip mroute #show ip pim interface #show ip pim neighbor #show ip pim interface [<interface>] detail Ladění můžeme zahájit příkazem: #debug ip pim Pro simulaci přijímače multicastového provozu směrovačem zadáme na zvoleném rozhraní příkaz: (config-if)#ip igmp join-group [ip multicastové skupiny] Zdroj můžeme simulovat třeba pomocí příkazu ping: #ping [ip multicastové skupiny] repeat 9999 Duben 2014 4/12

4 Analýza fungování State refresh Při povolení State refresh se nejprve provede vytvoření a prořezání směrovacího stromu podle klasického algoritmu PIM DM. Poté začnou směrovače, které jsou označeny jako zdroje State refresh zpráv (tedy ty, které jsou přímo připojeny ke zdrojům musticastového provozu), periodicky generovat a posílat State refresh zprávy na adresu 224.0.0.13. Tuto zprávu zachytí všechny sousední směrovače, a pokud mají povoleno přeposílaní těchto zpráv (viz. Konfigurace), pak zprávu zpracují a přepošlou (vytvoří a pošlou novou) dále. Takto se zpráva rozšíří od kořene do celé topologie. 4.1 Analýza State refresh zpráv Každý směrovač, který zachytí zprávu, ji analyzuje a pošle svou vlastní, proto se zprávy na různých segmentech liší. Dále analyzované segmenty sítě odpovídají segmentům 2 a 3 z ukázkové topologie definované v kapitole 5. Na obrázku 1 můžeme vidět strukturu State refresh zprávy, která je detailněji popsána dále. Obrázek 1 - Struktura State refresh zprávy 4.1.1 Analýza na segmentu připojeném k původci zpráv Na obrázku 2 (segment 2 z ukázkové topologie) vidíme, že PIM zprávy se posílají v IP paketech. Zdrojem je směrovač, který se nachází mezi zdrojovým a sledovaným segmentem, přičemž jeho rozhraní směřující do sledovaného segmentu má adresu 10.0.2.2. Dále vidíme, že se zprávy posílají na adresu 224.0.0.13. TTL je vždy 1. V samotné PIM zprávě, jejíž strukturu můžeme vidět na obrázku 1, vidíme verzi PIM a typ zprávy (verze 2 a zpráva 9) a kontrolní součet. Dále vidíme multicastovou skupinu, které se tato zpráva týká, zdroj multicastového provozu a původce State refresh zprávy, kterým je rozhraní směřující do zdrojového segmentu (adresy 10.0.1.2 a 10.0.2.2 jsou adresy různých rozhraní stejného směrovače). Hodnota RP Tree bude pro PIM DM vždy 0. Dále můžeme vidět hodnoty Metric Preference, Metric a Masklen, což jsou hodnoty unicastového směrovacího protokolu. V tomto případě jsou hodnoty nulové, protože zdroj je přímo připojený ke směrovači. Dále je vidět TTL, který je snížen vždy při přeposlání o 1. Prune indicator má hodnotu 1, pokud rozhraní, na které se tato zpráva odesílá, má nastavenou hodnotu Prune. V opačném případě má hodnotu 0. Prune now je nastaven původcem zprávy a směrovače je používají pro kontrolu toku Prune zpráv. Je nastaven pro každou třetí State refresh zprávu. Assert override je nastaven, pokud směrovač již nějakou dobu neslyšel o vítězi Assertu. Oba příznaky jsou zde z důvodu kompatibility s předchozí verzí State refresh a příjemce by je měl ignorovat. Na konec je uveden interval pro rozesílání State refresh zpráv. Duben 2014 5/12

Obrázek 2 State refresh zpráva na připojeném segmentu 4.1.2 Analýza na vzdáleném segmentu Na obrázku 3 vidíme zprávu na jiném segmentu (segment 3 z ukázkové topologie). Vidíme, že zdrojová adresa IP paketu je nyní 10.0.3.3, což je adresa směrovače, který provedl přeposlání PIM zprávy. Další změnou je nastavení hodnoty Metric preference na 110 (OSPF) a hodnoty Mectric na 2. TTL se snížilo o 1. Hodnoty Prune indicator, Prune now a Asseret override byly nastaveny znovu, ale jsou shodou okolností stejné. Obrázek 3 - State refresh zpráva na vzdáleném segmentu Duben 2014 6/12

5 Srovnání provozu Pro analýzu zpráv a ověření funkčnosti byla zapojena topologie zobrazena na obrázku 4 na směrovačích Cisco (viz. Příloha - tabulka 1). Směrovače RZ1 a RZ2 simulují zdroj multicastového provozu pro skupiny 229.0.1.1 a 229.0.1.2. Směrovač RP je přijímač pro skupinu 229.0.1.1. Na celé topologii je nastaven směrovací protokol OSPF. Na vyznačené části topologie byl podle konfigurace popsané v kapitole 3 nastaven PIM DM. Nejprve bez využití State refresh a přijímače, poté se State refresh a pak i s přijímačem. Provoz byl zachycen programem Wireshark postupně na segmentech 2 a 3. Celý záznam je možné nalézt v příloze. Při analýze je dobré filtrovat pouze protokol PIM. Obrázek 4 - Topologie pro ověření funkčnosti 5.1 Provoz na podsíti 2 Na obrázku 5 je vypsán provoz zachycený na segmentu 2 před zapnutím State refresh. Vidíme, že se provádí prořezání stromu. A provádí se každé 3 minuty Obrázek 5 - Provoz na segmentu 2 bez State refresh Na obrázku 6 je zachycen provoz po zprovoznění State refresh. Vidíme, že se posílají dvě zprávy. Každá pro jeden směrovač s povoleným vytvářením State refresh zpráv (State refresh originator). Tyto zprávy jsou detailněji popsány v kapitole 4. Velikost State refresh paketů je pouze o několik bytů větší než velikost Assert a Prune paketů a jejich podstatně méně. Na druhou stranu se posílají častěji. V tomto případě je přínos State refresh téměř nulový. Duben 2014 7/12

Obrázek 6 - Provoz na segmentu 2 s State refresh 5.2 Provoz na podsíti 3 Na obrázku 7 můžeme vidět provoz na segmentu 3 před zavedením State refresh. Posílá se pouze jedna Prune zpráva a žádná Assert zpráva a v případě, že by RP bylo připojené ke zdroji, tak by se neposílala žádná zpráva (protože strom by nebylo třeba prořezávat). Oproti tomu obě State refresh zprávy na obrázku 8 by se posílaly vždy. Obrázek 7- Provoz na segmentu 3 bez State refresh Obrázek 8 - Provoz na segmentu 3 s State refresh Tady State refresh dokonce situaci zhoršil. Duben 2014 8/12

6 Ověření chování Ze zachyceného provozu, uvedeného na obrázcích 6, 8 a 9 je vidět, že se State refresh chová podle teoretických předpokladů. Po jeho povolení se přestane směrovací strom periodicky prořezávat a sítí se začnou šířit State refresh zprávy. V síti se ovšem občas vyskytne Join/Prune zpráva, která opravuje špatnou informaci ve State refresh. Může být způsobena změnou topologie sítě nebo připojením přijímače, jak je vidět na obrázku 9. Obrázek 9- Join/Prune zpráva při zapnutém State refresh V síti občas objeví Join/Prune zpráva, i když ke změně nedošlo. Důvodem je, že State refresh neobsahují správné informace a posílají Prune indicator nastavený na 1 i na rozhraních, kde není nastaven Prune. Nepodařilo se mi, ale vysledovat, proč se tak děje, jedná se o náhodné chování. Toto chování nebylo očekávané z teoretických předpokladů. Duben 2014 9/12

7 Závěr PIM DM State refresh je funkční opatření proti periodickému zaplavení. A to hlavně v sítích s vysokým počtem segmentů bez přijímačů nebo v sítích s mnoha směrovači na jednom segmentu. Na rozdíl od čisté implementace PIM DM, která co tři minuty prořezává směrovací strom znovu a zatěžuje tím síť, implementace s využitím State refresh posílá periodicky pouze jeden (popř. několik) paket, který se dostane do celé sítě. Nicméně u malých sítí, jako je například ukázková topologie, nepřináší State refresh významné zlepšení a může přinést i zhoršení. I bez něj se posílá pouze několik poměrně malých (několik desítek bytů) zpráv navíc, což při periodě opakování tři minut není v dnešních sítích problém. Ale s rostoucí velikostí sítě roste i počet zpráv, které prořezávají strom. Ovšem počet State refresh se nezmění (bude vždy roven maximálně počtu směrovačů na zdrojovém segmentu). Z tohoto důvodu je zřejmé, že pro ověření účinnosti State refresh by bylo vhodnější použít větší síť, což ale není v laboratorních podmínkách příliš možné. Je nutné si ale uvědomit, že State refresh kromě přenosových medií šetří částečně i prostředky směrovače, protože místo generování a analýzy několika zpráv, musí směrovač analyzovat, generovat a přeposlat jedinou zprávu. Nicméně pokud k tomu není zvláštní důvod, pak bych doporučoval nepoužívat Dense mode vůbec, protože je pro naprostou většinu sítí nevhodný. Pokud se ale najde důvod použít jej, pak bych doporučil zavést i State refresh. Je podporován většinou multicastových směrovačů a jeho konfigurace je velmi rychlá. Duben 2014 10/12

8 Reference 1) RFC 3973 - Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). 2005 [cit. 2014-04-23]. Dostupné na: http://tools.ietf.org/html/rfc3973#section-4.7.10 Duben 2014 11/12

9 Přílohy Směrovač Typ Verze software R1 Cisco 2801 ADVIPSERVICESK9-M 15.1(3)T4 R2 Cisco 2801 ADVIPSERVICESK9-M 15.1(3)T4 R3 Cisco 2811 ADVIPSERVICESK9-M 15.1(3)T R4 Cisco 2801 ADVIPSERVICESK9-M 15.1(3)T4 RZ1 Cisco 2801 ADVIPSERVICESK9-M 15.1(3)T4 RZ2 Cisco 2811 ADVIPSERVICESK9-M 15.1(3)T RP Cisco 1812 ADVIPSERVICESK9-M 12.4(24)T Tabulka 1 Použitý hardware Duben 2014 12/12