Konfigurace a sledování provozu protokolů PIM pro směrování multicastů Cisco směrovači

Transkript

1 Konfigurace a sledování provozu protokolů PIM pro směrování multicastů Cisco směrovači Bc. Bronislav Feču Bc. Filip Řezáč Abstrakt: Tento dokument pojednává obecně o multicastu a konkrétně se poté zaměřuje na protokol PIM. Je zde vysvětlen princip fungování multicastu a jeho směrování mezi směrovači pomocí protokolu PIM. V praktické části je navržena topologie a metologie pro sledování multicastového provozu. Naměřené hodnoty jsou poté analyzovány a vyhodnoceny, jestli odpovídají teoretickým předpokladům. Klíčová slova: Multicast, PIM, IGMP, Dense Mode, Sparse Mode, Prune linky, Graft linky, Assert linky, SPT, zpráva Join 1 Úvod Multicasting Základní vlastnosti skupinového vysílání Multicastové skupiny Multicast v lokálních sítích Směrování multicastového provozu v rozsáhlých sítích Hustý režim (Dense Mode) Řídký režim (Sparse Mode) Distribuční stromy Zdrojový strom Sdílený strom Protocol Independent Multicast (PIM) PIM Dense Mode PIM Sparse Mode Měření a sledování PIM v síti Návrh měření PIM provozu Topologie Metologie Měření PIM provozu v Dense modu Prune linky Graft linky Assert linky Měření PIM provozu v Sparse modu Zpráva Join SPT (Shortest Path Tree) Měření a analýza reálných hodnot Prune linky Graft linky Assert linek Zpráva Join /19

2 3.4.5 SPT Závěr Literatura /19

3 1 Úvod Technologie skupinového vysílání (multicast) slouží především aplikacím, které využívají komunikace jednoho zdroje s velkým počtem příjemců stejných dat. Tato metoda pracuje na principu přeposílání IP datagramů z jednoho zdroje skupině více koncových stanic. Místo odesílání jednotlivých datagramů ke každému cíli zvlášť je odeslán pouze jediný datagram. Tento přenos je mimořádně vhodný pro různé multimediální aplikace, např. přenos obrazu a zvuku v reálném čase několika příjemcům. Aplikace tohoto typu se v síti Internet zatím většinou řeší hrubou silou. Například běžná internetová rádia: pro každého klienta, který se připojí, se vytváří pomocí protokolu TCP samostatné datové spojení. To ovšem znamená, že server musí stejná data, v tomto případě zakódovaný zvuk, posílat v tolika kopiích, kolik je aktuálně připojených klientů. U velmi populárních zdrojů to může znamenat enormní zátěž jak pro vlastní server, tak i pro jeho připojení do internetu. 2 Multicasting 2.1 Základní vlastnosti skupinového vysílání Cílem technologie skupinového vysílání je odlehčení zátěže vysílacího prvku a jeho připojení do sítě při odesílání dat mnoha příjemcům. Při vysílání neznámému a mnohdy velkému počtu příjemců (skupině), se data odešlou pouze jednou a veškerá zátěž spojená s distribucí dat příjemcům je ponechána na směrovačích zapojených do této sítě, viz. obrázek 1. Směrovače mají za úkol zajistit efektivní přenos dat ke všem příjemcům. Tok paketů je v případě skupinového vysílání určován příjemci dat. Obrázek 1: Rozdíl mezi unicastovou a multicastovou distribucí dat 2.2 Multicastové skupiny Každá skupina příjemců dat má svou vlastní adresu. Pro adresy multicastových skupin jsou vyčleněny IP adresy třídy D tedy rozsah až Rozsah adres od do by neměl být používán aplikačními programy. Datagramy adresované do těchto skupin, nebudou multicastovým směrovačem předány dál. Vlastní vysílání probíhá tak, že zdroj dat odesílá pakety s cílovou adresou skupiny a další šíření paketů probíhá stejně jako šíření běžných paketů přímého vysílání. Rozdíl je v tom, že v případě skupinového vysílání, může směrovač provést replikaci paketu a jeho vyslání do více směrů. 2.3 Multicast v lokálních sítích Šíření multicastu v lokální síti (bez směrovačů) obvykle nevyžaduje žádná speciální opatření. Ve standardu Ethernetu je multicast definován a je pro něj vyhrazen blok MAC adres. Stačí tedy, aby se multicastové IP adresy vhodným způsobem zobrazily na MAC adresy. Běžné síťové karty pracovních stanic (včetně PC) pak mají schopnost podle svého okamžitého nastavení (na základě požadavku programu) filtrovat pakety skupinového vysílání a nejbližším vrstvám programového vybavení již předávat jen relevantní část paketu skupinového vysílání, které se v lokální síti pohybují, tedy pouze skupiny, jež jsou předmětem momentálního zájmu dané stanice. Nedochází tedy k zatěžování stanic lokální sítě, jichž se dané skupinové vysílání netýká. 3/19

4 2.4 Směrování multicastového provozu v rozsáhlých sítích Mnohem složitější je směrování multicastu v rozsáhlých sítích, respektive v celém Internetu. Do hry vstupují směrovače. Jejich primárním úkolem je unicastové směrování, šíření a správa směrovací informace. Jedním z jejich úkolů je získat informace o tom, které skupiny mají být vysílány do sítí, jež jsou ke směrovači bezprostředně připojeny. Jde především o to, aby se všechna data vysílaná v rámci konkrétní multicastové skupiny dostala všem přihlášeným příjemcům a pokud možno nikomu jinému. Tuto úlohu řeší multicastové směrovací protokoly. Reprezentantem IP multicastu v rozsáhlých sítích a internetu je Internet Group Membership Protocol (IGMP), který byl, pro použití v IPv6 přejmenován na Multicast Listener Discovery (MLD). Hlavní úlohou IGMP i MLD je informovat směrovače v síti o přítomnosti koncového počítače, který má zájem o příjem určité multicastové skupiny. Směrovač vyšle do připojené sítě dotaz (paket se speciální skupinovou adresou ) a jednotlivé stanice odpovídají (s náhodně zvoleným zpožděním, aby nedocházelo k zahlcení sítě při současné odpovědi všech najednou) informací o adresách skupinového vysílání, o než mají zájem. Odpovědi jsou rovněž vysílány na adresu a odposlouchávány ostatními stanicemi. Tím se zamezí duplicitnímu vysílání požadavku na stejnou skupinu. Programové vybavení koncové stanice tedy musí navíc podporovat protokol IGMP. Směrovače tak pomocí protokolu IGMP sledují zájem o příjem konkrétních skupin ve svém bezprostředním okolí. Od multicastových odesílatelů se naproti tomu žádná explicitní registrace nežádá: ti se totiž prozradí přímo svými daty, jakmile je začnou vysílat. Protokol IGMP existuje ve třech verzích. K optimálnímu přenosu paketů skupinového vysílání i do vzdálených částí sítě slouží směrovací protokoly. S jejich pomocí směrovače hledají minimální strom spojů pokrývající cestu od zdroje skupinového vysílání k momentálním zájemcům o příjem. Na rozdíl od klasického unicastového směrování vysílání, jde o proces velmi dynamický. Zájemci o příjem daného skupinového vysílání mohou libovolně vznikat a zanikat a tento proces průběžných změn musejí směrovací protokoly brát vhodně do úvahy. V současné době se nejvíce používají protokoly DVMRP (Distance Vector Multicast Routing Protocol) a dvě varianty protokolu PIM (Protocol Independent Multicast). Směrovací protokoly dělíme podle jejich přístupu ke směrování do dvou skupin: Hustý režim (Dense Mode) Protokoly této skupiny používají zdrojové stromy k doručování Source Specific Multicast (SSM) a pracují na tzv. push principu. Tento princip předpokládá, že každý subnet má příjemce (S, G) multicastového provozu a tento provoz je tedy primárně přenášen všude. Aby se zabránilo plýtvání pásma, listy stromu, které nemají žádné příjemce pro předmětnou skupinu, pošlou směrem ke kořenu tzv. Prune zprávu. Směr, ze kterého taková zpráva přišla, je pak ve stromě ořezán, až zůstanou pouze větve, které mají některé aktivní posluchače. Prune zpráva platí pouze po omezenou dobu, takže po chvíli je ji nutné opět obnovit, jinak začne nadřazený směrovač opět posílat data do předtím ořezaných větví. Naopak ve chvíli, kdy se objeví nějaký nový posluchač dané skupiny, pošle směrovač svému nadřazenému zprávu Graft a data začnou téct okamžitě. Mezi Dense Mode protokoly patří například DVMRP a PIM-DM Řídký režim (Sparse Mode) Mezi Sparse Mode protokoly patří například PIM-SM (Protocol Independent Multicast) nebo CBT (Core Based Trees). Tyto protokoly využívají sdílené stromy pro distribuci multicastových dat a využívají tzv. Pull Model. Tento model předpokládá, že data se nesmějí posílat do sítě, pokud si je někdo explicitně nevyžádá. Pokud se tedy některý stroj chce připojit do multicastové skupiny, jeho příslušný směrovač pošle zprávu Join směrem ke kořenu stromu. Takto je sestavena další větev stromu a data můžou proudit. Platnost zprávy Join je časově omezena, takže je nutné ji obnovovat. Pokud už v dané větvi není žádný příjemce skupiny, směrovač pošle zprávu Graft, která větev uřízne. Důvodem pro zavedení Sparse Mode protokolů byla především snaha šetřit výpočetní výkon směrovačů. V případě, že je více přispěvovatelů do skupiny, musí Dense Mode protokoly počítat strom pro každý zvlášť. To u Sparse Mode protokolů odpadá, ale na oplátku může být jejich směrování méně efektivní, a je tedy nutné velmi pečlivě volit RP (Rendezvous Point). CBT se nikdy velikého rozšíření nedočkal, naopak PIM-SM má několik implementací a je běžně v multicastových sítích používán. 4/19

5 2.5 Distribuční stromy Distribuční strom tvoří acyklický podgraf grafu topologie sítě a spojuje všechny sítě, na nichž jsou přijímače dané multicastové skupiny. Jak se do skupiny přihlašují nové přijímače a odhlašují existující, musí se do stromu připojovat nové větve a odstraňovat prořezávat staré Zdrojový strom Tomuto stromu se také někdy říká strom nejkratších cest (Shortest Path Tree SPT) a je to strom, jehož kořenem je zdroj multicastových dat, a listy tohoto stromu jsou příjemci tohoto vysílání. Příklad takového stromu vidíte na následujícím obrázku 2. Obrázek 2: Source Tree zdrojový strom Pro označení stromu se obvykle používá notace (S, G), což se anglicky čte jako S Comma G, kde S je adresa zdroje a G je adresa multicastové skupiny. Náš příklad na obrázku bychom označili jako ( , ). Je tedy zřejmé, ze pro různé zdroje posílající data do stejné multicastové skupiny existují různé zdrojové stromy. Někdy se také tento způsob práce s multicastem označuje Source Specific Multicast (SSM). Existuje-li samostatný strom pro každý zdroj vysílání do každé multicastové skupiny je to optimální, ale málo škálovatelné řešení Sdílený strom Oproti zdrojovým stromům mají sdílené stromy kořen vždy na jednom místě, nezávisle na tom, kdo data posílá. Tomuto kořenu se obvykle říká Rendesvous Point (RP), a proto se také tyto stromy někdy nazývají RP stromy. Příklad takového stromu máme na následujícím obrázku 3. 5/19

6 Obrázek 3: Shared Tree Sdílený strom Jako označení pro tyto stromy se používá notace (*, G), anglicky Star Comma G. Hvězdička označuje, že strom není závislý na zdroji multicastu. Náš příklad by se dal označit jako (*, ). Jak je vidět, směrovač F tvoří kořen stromu. Aby situace nebyla tak jednoduchá, tyto stromy jsou dvojího druhu: jednosměrné a obousměrné. Distribuce multicastu v obousměrném stromu probíhá tak, že zdroj data vysílá směrem ke kořenu a zároveň po směru stromu k listům. U jednosměrného se data pošlou unicastem ke kořenu a ten se o jejich distribuci již postará. Tento způsob chápání multicastu má také označení ASM (Any Source Multicast). 2.6 Protocol Independent Multicast (PIM) PIM je v dnešní době nejpoužívanější protokol pro směrování multicastu. Je nezávislý na specifickém unicastovém směrovacím protokolu, ale používá jeho směrovací tabulku. Multicasty směruje na základě RPF check (Reverse Path Forwarding). Ve skutečnosti není PIM směrovacím protokolem (neposílá a nepřijímá aktualizace o směrování routing updates). Existuje ve dvou módech, kdy pro některé skupiny může pracovat v dense módu a pro některé ve sparse módu PIM Dense Mode PIM-DM (Protocol Independent Multicast Dense Mode). Nesestavuje si sám unicastovou směrovací tabulku, ale místo toho využívá tabulku směrovače. Independent v názvu označuje, že PIM umí spolupracovat např. i se statickým routingem apod. Flooduje provoz do všech větví. Větev muže požádat o prořezání, pokud neobsahuje příjemce multicast skupiny (refresh každé 3 minuty). Podmínky pro efektivní funkci: přijímače a vysílače blízko sebe málo vysílačů a mnoho příjemců intenzivní multicastový tok konstantní proud multicastových dat PIM Sparse Mode Protokol PIM-SM proto odesílatelům a příjemcům vytváří obecně známé místo pro setkání rendezvous point (RP). Páteřní směrovač se pro tuto roli konfiguruje buď ručně, anebo častěji pomocí automatického mechanismu zvaného PIM-SM bootstrap. Protokol je vhodný pro malý počet příjemců ve skupině a pro nepravidelné datové toky. Odesílatelé zasílají multicast pakety na RP. Příjemci se registrují u RP. Směrovače na cestě mohou optimalizovat trasu datového toku od zdroje k příjemci. Odesílatelé totiž nevědí, kde se nacházejí příjemci a naopak. Rendezvous point (RP) pro jednotlivé multicast skupiny musí být 6/19

7 nakonfigurován ve všech směrovačích. Existují také (zatím nestandardizované) protokoly, které šíří informaci o aktivních RP pomocí multicastingu. Řešení, které nabízí PIM-SM je poměrně komplikované. Praktické zkušenosti ukazují, že spolehlivé provozování multicastu ve velkém je zatím chimérou. To je jeden z důvodů, proč se s nabídkou multicastu jako služby u internetových poskytovatelů téměř nesetkáme. Daleko větší šance se proto přisuzují zjednodušené variantě zvané zdrojově specifický multicast (SSM, Source-Specific Multicast). V tomto případě má každá multicastová relace jediného odesílatele a libovolný počet příjemců. Výhoda spočívá v tom, že IP adresa odesílatele je a priori známá, takže směrovače nepotřebují RP a mohou zprávy PIM Join posílat přímým směrem k odesílateli. 3 Měření a sledování PIM v síti 3.1 Návrh měření PIM provozu Pro odměření a sledování PIM protokolu v síti je nutné zvolit správnou topologii a metologii tak, aby pokud možno simulovala co nejvíce situací, a aby bylo zřejmé, jak v těchto situacích PIM, ať už v Dense či Sparse modu, prochází sítí. Veškeré návrhy topologií a metologií byly kresleny v programu Packet Tracer 4.11 od firmy Cisco Topologie Zvolili jsme si několik Cisco směrovačů pro směrování multicastů (závisí na zvolené topologii) a pro vysílání, přijímání a sledování PIM protokolu několik osobních počítačů. Adresování bylo vybráno z rozsahu privátních adres a počítalo se i s rozšířením topologie o další prvky. Využili jsme adresování s maskou podsítě proměnné délky (VLSM), aby nedocházelo k zbytečnému plýtvání adresami, i když se jedná jen o laboratorní zapojení. Jako routovací protokol jsme využili OSPF. Na obrázku 4 je vidět hlavní topologie, kterou jsme využili pro téměř všechna měření PIM provozu, na obrázku 5 je potom zobrazena topologie pro tzv. Assert linek. Obrázek 4: Topologie zapojení pro testování PIM provozu 7/19

8 Obrázek 5: Topologie pro testování Assertu linek Metologie Jelikož už máme navrženou topologii, je čas uvést, jak budeme sledovat provoz PIM protokolu, čím budeme multicast vysílat a čím přijímat a jak se ho budeme snažit řídit pomocí metriky linek. Počítače uvedené v topologii jsme si rozdělily na tzv. Testery, Listenery a Sender. Na všech těchto PC bude nainstalován program Wireshark (Ethereal) pro sledování provozu v síti, dále potom na Listenerech (posluchačích) bude nainstalován program VLC a bude spuštěn v módu receiver (posluchač). Na počítači Sender (vysílač) bude taktéž program VLC, ten bude sloužit jako sender (vysílač) mutlicastu do sítě. Abychom v naší topologii mohli ovlivňovat kudy budou procházet PIM pakety sítí, je manuálně nastavena metrika na dvou linkách, tak jak je nakresleno na obrázku 6 a 7. Našim cílem bude pomocí programu Wireshark (Ethereal) sledovat a zdokumentovat provoz v této síti. Obrázek 6: Metologie pro měření PIM provozu v síti 8/19

9 Obrázek 7: Metologie pro zapojení Assertu linek 3.2 Měření PIM provozu v Dense modu Jak pracuje PIM protokol v Dense modu bylo již uvedeno výše v teoretické části, proto zde už tato metoda nebude znovu popsána Prune linky Pro naše testování jsme zvolili zapojení, kde při probíhajícím mutlicastovém provozu odpojíme ze sítě počítač s označením Listener 2, který byl do té doby členem multicastové skupiny a přijímal proto multicastové pakety - obrázek 8. Obrázek 8: Průběh PIM paketů po odpojení Listeneru 2 Chceme zjistit, jak bude v reálném zapojení probíhat odřezání (prune) linek po odpojení zmiňovaného PC. Pro odřezání se používá zpráva PRUNE, tuto bychom rádi zachytili a analyzovali na Testerech 1 a 2. O tom, kam se pošle zpráva PRUNE první a o tom, které rozhraní směrovače (interface) bude odříznuto jako první rozhoduje metrika linek, kterou jsme si manuálně nastavili na hodnoty zvolené v obrázku. Při tomto nastavení se první odřeže horní rozhraní na směrovač R2 označené červeným kroužkem.následuje odřezání rozhraní na směrovači R4 označené též červeným kroužkem. Proč nemůžeme odřezat spodní větev až u směovače R2 jak jsme to provedli u horní větve? Protože na směrovači R4 je stále připojený ještě Listener 1, který přijímá multicastový provoz. Jak bude vypadat provoz v síti po odřezání větví můžeme vidět na obrázku 9. 9/19

10 Obrázek 9: Průběh multicast streamu po odřezání větví Graft linky V předchozím případě jsme ze sítě odpojili počítač Listener 2. V tomto měření ho opět připojíme a budeme požadovat obnovení multicastového provozu na toto PC. Bude proto nutné obnovit odřezané linky. Opět závisí na nastavené metrice, kterou cestou bude proudit mutlicastový provoz a tudíž která linka bude obnovena. Jak vypadá naše zapojení před obnovením linky můžeme vidět na obrázku 10. Obrázek 10: Průběh multicast streamu před zapojením dalšího posluchače Jakmile připojíme do sítě Listener 2 a ten požádá o multicastový přenos v dané skupině, okamžitě tento počítač posílá směrovači R5 IGMP zprávu a směrovač podle metriky rozesílá PIM zprávu GRAFT. V našem případě se bude zpráva GRAFT šířit spodní větví na směrovač R4. Ten odešle potvrzovací zprávu GRAFT 10/19

11 ACK zpět na směrovač R5 a odřazaná linka je opět obnovena a začíná mutlicast stream. Pruběh PIM paketů při připojení Listenera 2 můžeme vidět na obrázku 11. Obrázek 11: Průběh PIM paketů při zapojení posluchače Assert linky V tomto měření budeme chtít ukázat a pozorovat jak dochází k tzv. Assertu (prosazení) linek. Pokud budeme mít v topologii zprovozněno šíření PIM protokolu pomocí Dense modu, může se stát, že pokud budou dva směrovače vysílat společně multicast jedním směrem k příjemci - obr. 12, bude nutné vybrat jednoho z nich, který dostane přednost a bude zvolen, aby pouze on přenášel multicast. Obrázek 12: Zobrazení Assert bitvy linek Výběr probíhá pomocí tzv. bitvy linek. V této bitvě se určuje, který směrovač bude přenášet multicast a který ne. Porovnává se metrika linek a vyhrává linka s menší metrikou. Pokud je metrika linek stejná, vítězem je směrovač s vyšší IP adresou. V našem případě bude vítězem spodní linka a multicastový provoz se tak bude přenášet přes směrovač R4. Směrovač R3 posílá zprávu PRUNE a větev je odpojena na směrovači R2, jak značí zelený kroužek obrázek /19

12 Obrázek 13: Přenos multicast streamu po Assertu linek 3.3 Měření PIM provozu v Sparse modu Stejně jako u PIM Dense modu, nebude zde již rozebírat princip funkce PIM ve Sparse modu. Tato problematika je vysvětlena výše Zpráva Join Pro testování a analýzu PIM protokolu v módu Sparse jsme si zvolili zapojení, kde budeme simulovat připojení jednoho posluchače (Listener 2 ), který bude žádat o příjem mutlicast streamu. Na obrázku 14 můžeme vidět již připojený Listener 1, který přijímá mutlicast a zvolený Rendezvous Point (RP), přes který tento stream probíhá a ke kterému se také hlásí nový posluchači, kteří mají zájem o mutlicastový přenos. Obrázek 14: PIM ve Sparse modu, přenos pře Rendezvous Point Jakmile na směrovač R5 připojíme Listener 2, ten vysílá IGMP zprávu na tento směrovač a ten dále šíří PIM zprávu Join a žádá tak o připojení do multicastové skupiny. V našem případě bude zpráva putovat spodní větví na směrovač R4, kde právě od tohoto směrovače obdrží informace od RP. Směrovač R4 začne posílat mutlicast i na směrovač R5 a ten poté na Listener 2. Pokud by však byly metriky linek přehozené, 12/19

13 zpráva Join by putovala horní větví přes směrovač R3 až do RP a ten by poté povolil mutlicastový stream obrázek 15. Obrázek 15: Průběh PIM paketů při připojení Listener SPT (Shortest Path Tree) Pojem SPT se již v textu objevil. Jedná se nejkratší cestu stromu, v našem případě to znamená, že pokud je od příjemce ke zdroji multicastu kratší cesta než k zvolenému RP, komunikace a samotný mutlicast přenos prochází právě touto kratší cestou. Na obrázku 16 můžeme vidět novou linku spojující směrovač R1 se směrovačem R4. Tím pádem vzniká kratší cesta přímo ke zdroji multicastu, než kdyby se pakety měly šířit přes zvolený RP. V našem případě do sítě připojíme pouze Listener 2 a ten vysílá zprávu Join právě přes kratší nově vytvořenou linku. Pokud bychom však obrátili metriky na vybraných linkách, zpráva Join by procházela přes směrovač R3 do RP. Obrázek 16: Ukázka SPT a průběh PIM paketů kratší cestou Jakmile dorazí zpráva Join na směrovač R1, ten posílá IGMP paket na zdroj multicastového vysílání a začne probíhat mutlicast stream nejkratší cestou obrázek /19

14 Obrázek 17: Ukázka SPT a průběh mutlicast stream paketů přes nejkratší cestu 3.4 Měření a analýza reálných hodnot V této kapitole jsou zobrazeny reálné výsledky a hodnoty, které jsme naměřili. Multicastovou adresu jsme použili na portě Prune linky Teoretický úvod k tomuto testu je uveden v kapitole Celkové schema zapojení topologie i se znázorněnými rozhraními je na obrázku 4 v kapitole Na směrovači R2 jsme zadali příkaz: show ip mroute pro zobrazení multicastové směrovací tabulky: (*, ), 00:31:53/stopped, RP , flags: D Incoming interface: Null, RPF nbr Outgoing interface list: Serial0/2/1, Forward/Dense, 00:30:41/00:00:00 Serial0/1/1, Forward/Dense, 00:31:53/00:00:00 ( , ), 00:14:51/00:02:54, flags: T Incoming interface: Serial0/1/1, RPF nbr Outgoing interface list: Serial0/2/1, Forward/Dense, 00:09:09/00:00:00 Vidíme, že rozhraní Serial 0/2/0 na směrovači R2 není v tabulce, jelikož je toto rozhraní odřezáno. Mutlicast probíhá pouze po rozhraní Serial 0/1/1 a Serial 0/2/1. Na směrovači R4 jsme zadali příkaz: debug ip pim a pozorovali jsme jaké PIM pakety bude směrovač přijímat či vysílat. *May 9 09:49:45.515: PIM(0): Received v2 Join/Prune on FastEthernet0/1 from , to us *May 9 09:49:45.515: PIM(0): Prune-list: ( /32, ) *May 9 09:49:45.515: PIM(0): Prune FastEthernet0/1/ from ( /32, ) Směrovač R4 přijal PIM zprávu PRUNE pro rozhraní FastEthernet0/1 a lze vidět odřezání větve právě na tomto rozhraní. Měření odpovídá našim předpokladům. 14/19

15 3.4.2 Graft linky Teoretický úvod k tomuto testu je uveden v kapitole Celkové schema zapojení topologie i se znázorněnými rozhraními je na obrázku 4 v kapitole Na směrovači R5 jsme zadali příkaz: debug ip igmp a pozorovali jsme jaké IGMP pakety bude směrovač přijímat od Listenera2 který jsme k tomuto směrovači připojili. *May 9 08:50:32.627: IGMP(0): Updating EXCLUDE group timer for *May 9 08:50:32.627: IGMP(0): MRT Add/Update FastEthernet0/0 for (*, ) by 0 *May 9 08:50:34.627: IGMP(0): Received v2 Report on FastEthernet0/0 from for *May 9 08:50:34.627: IGMP(0): Received Group record for group , mode 2 from for 0 sources *May 9 08:50:34.627: IGMP(0): Updating EXCLUDE group timer for *May 9 08:50:34.627: IGMP(0): MRT Add/Update FastEthernet0/0 for (*, Pomocí příkazu debug ip pim na R5 jsme pozorovali vytvoření PIM zprávy GRAFT pro znovu připojení větve do mutlicastové skupiny. *May 9 08:51:10.967: PIM(0): Building Graft message for , FastEthernet 0/0: no entries *May 9 08:51:10.967: PIM(0): Building Graft message for , Serial0/0/1: /32 *May 9 08:51:10.967: PIM(0): Send v2 Graft to (Serial0/0/1) *May 9 08:51:10.987: PIM(0): Received v2 Graft-Ack on Serial0/0/1 from *May 9 08:51:10.987: Group : /32 Tuto zprávu obdrží směrovač R4 a obnovuje větev pro mutlicastový provoz *May 9 10:00:16.199: PIM(0): Join-list: ( /32, ) *May 9 10:00:16.199: PIM(0): Add FastEthernet0/1/ to ( , ), Forward state, by PIM Graft *May 9 10:00:16.199: PIM(0): Send v2 Graft-Ack on FastEthernet0/1 to Měření odpovídá našim předpokladům. 15/19

16 3.4.3 Assert linky Teoretický úvod k tomuto testu je uveden v kapitole Celkové schema zapojení topologie i se znázorněnými rozhraními je na obrázku 5 v kapitole Po připojení Listeneru 2 probíhá mezi směrovačem R3 a R4 assert bitva o to kdo bude vysílat na R5 a dále potom na Listenera 2. Bohužel se nám nepodařilo zachytit samotné ASSERT zprávy, i když jsme se o to několikrát pokoušeli, ale můžeme vidět, kdo bitvu vyhrál a tedy jakou cestou multicast prochází. Na směrovači R2 jsme zadali příkaz: show ip mroute pro zobrazení multicastové směrovací tabulky: (*, ), 00:12:13/stopped, RP , flags: D Incoming interface: Null, RPF nbr Outgoing interface list: Serial0/2/1, Forward/Dense, Serial0/1/1, Forward/Dense, 00:12:13/00:00:00 ( , ), 00:12:13/00:02:54, flags: T Incoming interface: Serial0/1/1, RPF nbr Outgoing interface list: Serial0/2/1, Forward/Dense, 00:01:22/00:00:00 Vidíme, že mutlicast se směruje pouze do spodní větve do rozhraní Serial 0/2/1, proto víme že bitvu vyhrál R4 přes který bude nyní probíhat veškerý multicastový provoz pro R5. Ověříme si na obou směrovačích jejich multicastové směrovací tabulky pomocí příkazu show ip mroute. Pro R4: (*, ), 00:21:15/stopped, RP , flags: D Incoming interface: Null, RPF nbr Outgoing interface list: FastEthernet0/0, Forward/Dense, 00:19:58/00:00:00 Serial0/1/0, Forward/Dense, 00:21:15/00:00:00 ( , ), 00:18:15/00:02:59, flags: T Incoming interface: Serial0/1/0, RPF nbr Outgoing interface list: FastEthernet0/0, Forward/Dense, 00:05:30/00:00:00 16/19

17 Pro R3: (*, ), 00:20:04/stopped, RP , flags: D Incoming interface: Null, RPF nbr Outgoing interface list: FastEthernet0/0, Forward/Dense, 00:20:04/00:00:00 ( , ), 00:02:03/00:00:56, flags: PT Incoming interface: FastEthernet0/0, RPF nbr Outgoing interface list: Null Vidíme, že zatímco na R4 je pro multicaast nastaveno odchozí rozhraní FastEthernet0/0, na R3 je seznam odchozích rozhraní prázdný, tudíž R3 žádný multicast nevysílá. Měření odpovídá našim předpokladům Zpráva Join Teoretický úvod k tomuto testu je uveden v kapitole Celkové schema zapojení topologie i se znázorněnými rozhraními je na obrázku 4 v kapitole Směrovače jsou nastaveny ve sparse modu. Na směrovači R2 máme nastavený RP a ten posílá mutlicast na směrovač R4 a do Listener 1. Nyní připojíme Listener 2 na směrovač R5 a ten vyšle zprávu JOIN na směrovač R4. Na směrovači R5 zadáme příkaz: debug ip igmp abychom sledovali IGMP pakety kde Listener 2 žádá IGMP zprávamio připojení do skupiny. *May 9 09:16:56.151: IGMP(0): Switching to EXCLUDE mode for on FastEthernet0/0 *May 9 09:16:56.151: IGMP(0): Updating EXCLUDE group timer for *May 9 09:16:56.151: IGMP(0): MRT Add/Update FastEthernet0/0 for (*, ) by 0 *May 9 09:16:57.167: IGMP(0): Received v2 Report on FastEthernet0/0 from for *May 9 09:16:57.167: IGMP(0): Received Group record for group , mode 2 from for 0 sources *May 9 09:16:57.167: IGMP(0): Updating EXCLUDE group timer for *May 9 09:16:57.167: IGMP(0): MRT Add/Update FastEthernet0/0 for (*, by 0 *May 9 09:16:58.135: IGMP(0): Received v2 Report on FastEthernet0/0 from for *May 9 09:16:58.135: IGMP(0): Received Group record for group , mode 2 from for 0 sources *May 9 09:16:58.135: IGMP(0): Updating EXCLUDE group timer for /19

18 *May 9 09:16:58.135: IGMP(0): MRT Add/Update FastEthernet0/0 for (*, ) by 0 Směrovač R5 vytváří PIM zprávu JOIN a posílá ji na směrovač R4: *May 9 09:19:19.091: PIM(0): Insert ( , ) join in nbr 's queue *May 9 09:19:19.091: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for *May 9 09:19:19.091: PIM(0): Insert (*, ) join in nbr 's queue *May 9 09:19:19.091: PIM(0): Building Join/Prune packet for nbr *May 9 09:19:19.091: PIM(0): Adding v2 ( /32, ), WC-bit, RP T-bit, S-bit Join *May 9 09:19:19.091: PIM(0): Adding v2 ( /32, ), S-bit Join *May 9 09:19:19.091: PIM(0): Send v2 join/prune to (Serial0/0/1) Směrovač R4 ověřuje RP a pouští multicast i na směrovač R5. *May 9 10:22:12.435: PIM(0): Received RP-Reachable on Serial0/1/0 from *May 9 10:22:12.435: PIM(0): Received RP-Reachable on Serial0/1/0 from *May 9 10:22:12.435: for group *May 9 10:22:13.659: PIM(0): Received RP-Reachable on Serial0/1/0 from *May 9 10:22:13.659: PIM(0): Received RP-Reachable on Serial0/1/0 from *May 9 10:22:13.659: for group *May 9 10:22:13.659: PIM(0): Forward RP-reachability for 2 *May 9 10:22:13.659: PIM(0): Forward RP-reachability for 2 Měření odpovídá našim předpokladům SPT V tomto měření máme dokázat, že pokud je cesta přímo ke zdroji multicastu kratší než k RP, multicastový provoz prochází právě touto kratší cestou mimo RP. Bohužel se nám nepodařilo ověřit tuto skutečnost. Po připojení Listenera 2 na směrovač R5 tento směrovač stále vysílal PIM pakety přes RP a né přímo k směrovači R1 jak bylo zamýšleno. Tuto skutečnost přikládáme chybě v nastavení metrik linek, kde i po zapojení kratší cesty, ta byla stále metricky více vzdálená než RP. Měření neodpovídá našim předpokladům. 18/19

19 4 Závěr Projekt jsme rozdělil na dvě části. V první části jsme teoreticky popsali problematiku multicastu. Druhá část byla zaměřena na praktické ověření funkce multicastového přenosu a jeho směrování v testovací lokální síti. Teoretická část byla zaměřena především na nastínění základních vlastností a problematiky multicastového přenosu. V další části jsme se zabývali v jakých režimech se multicast provozuje a jakým způsobem se distribuuje k příjemcům. S tím souvisí tzv. prořezávání distribučních stromů od neaktivních příjemců vysílání. Velký důraz byl kladen na protokol PIM, jehož popsání a analýza byla cílem projektu. Jak bylo vysvětleno tento protokol se používá pro směrování multicastového provozu mezi směrovači sítě. V praktické části jsme si zvolili vhodnou topologii zapojení sítě a také metologii samotného měření. Jako zdroj i přijímač multicastového vysílání jsme zvolili program VLC. V zapojení byl jeden počítač jako zdroj vysílání a několik dalších sloužilo jako přijímače. Další počítače jsme použili jako testovací, na nichž jsme odchytávali provoz v síti. Samotné měření jsme rozdělili do dvou částí. V jedné jsme testovali Dense Mode a v druhé Sparse Mode protokolu PIM. Všechna měření která jsme provedli v Dense Modu, dopadla podle předpokladů. Následovalo testování Sparse Modu. Měření, kdy jsme odchytávali zprávu Join probíhalo také podle předchozího návrhu a předpokladu. Výsledky testování SPT metody dopadly však jinak než jsme předpokládali. Jednotlivé analýyzy a výsledky jsou uvedeny u každého typu měření. Je zde také vysvětlena pravděpodobná příčina, proč výsledek posledního měření nesouhlasil s předpoklady. Měřením jsme si prakticky ověřili možnosti jednotlivých modů přenosu a metod jake protokol PIM nabízí a se kterými pracuje. I přes problémy které nastaly byla naše práce úspěšná a může být přínosem a rošířením v nastudování problematiky multicastů a jejich směrování v síti. Multicastový přenos se používá převážně ve velkých sítích kde je potřeba distribuovat z jednoho zdroje pro více posluchačů, aniž bychom přetěžovaly síť a daný zdroj dat. 5 Literatura Sledování provozu protokolu PIM pro směrování multicastu; Michal Sehnal /19