Průzkum a ověření možností směrování multicast provozu na platformě MikroTik.

Transkript

1 Průzkum a ověření možností směrování multicast provozu na platformě MikroTik. K. Bambušková, A. Janošek Abstrakt: V této práci je popsán základní princip multicastů, následuje popis možností použití multicastů na platformě MikroTik. Dále práce obsahuje návrh fyzického zapojení, na kterém jsme otestovali a prakticky ověřili funkčnost multicastů. Jsou zde také popsány problémy, se kterými jsme se setkali. Na závěr uvádíme zhodnocení použitelnosti MikroTiků pro multicastové aplikace. Klíčová slova: MikroTik, multicast, PIM, IGMP, Sparse Mode, RP, distribuční strom. 1 Úvod Multicast Základní vlastnosti Multicast na spojové vrstvě Multicast na síťové vrstvě IGMP Směrování multicastů Distribuční stromy Režimy vysílání dat Hustý režim Řídký režim PIM Randezvous Point Parametr Hello-holdtime MikroTik Podpora multicastů na platformě MikroTik Konfigurace na platformě MikroTik Praktické zapojení Topologie Konfigurace Testovací provoz Zapnutí vysílače S Zapnutí přijímače C Zapnutí posluchačů C2 a C Rozpojení linky Rozpojení linky na druhé straně hubu Zhodnocení použitelnosti Závěr Zdroje...14 květen /18

2 1 Úvod Multicast je technologie pro skupinové vysílání, která byla vyvinuta pro aplikace, kde převážně komunikuje jeden vysílací zdroj s velkým počtem příjemců stejných dat, tedy je vhodné tuto technologii použít pro multimediální aplikace, kde je jeden zdroj dat a zároveň potřeba tyto data v reálném čase posílat mnoha příjemcům. Další použítí ve více konvenčních aplikacích, které vyhovují této technologii, může být například posílání oběžníku všem zaměstnancům organizace nebo oprava milionté první chyby v jednom velmi rozšířeném operačním systému. Pro multicast se velmi hodí multimediální aplikace, které jsou tolerantní na chyby v přenosu dat, protože pro přenos dat v síti se nejčastěji používá protokol UDP. Typicky se multicast vyskytuje v oblastech: distribuce vysílání obrazu a hlasu distribuce přesného času videokonference vyhledávání služeb distribuované simulace 2 Multicast 2.1 Základní vlastnosti Hlavní úlohou této technologie je snížení zátěže vysílajícího uzlu a přenosové soustavy při přenosech typu jeden zdroj - mnoho příjemců. Zdroj tedy vysílá data určená neznámému, potenciálně velmi velkému počtu příjemců (skupině) pouze jednou a veškerá režie spojená s distribucí příjemcům je ponechána na směrovačích (routerech). Na nich také je, aby zajistily efektivní přenos dat od zdroje k příjemcům, tedy aby vysílaná data poslaly po každém spoji nejvýše jedenkrát a to pouze tehdy, je-li daným směrem skutečně nějaký příjemce. Při směrování paketů typu unicast je cesta paketu dana cílovou adresou. U paketů typu multicast však toto není možné, neboť cílová adresa neurčuje jen jednoho příjemce, ale obecně skupinu příjemců. Proto se nedá použít klasická smerovací tabulka pro doručení ke všem příjemcům. Využívá se multicastových routovacích protokolů, které vědí, na kterou množinu rozhraní mají replikovat daný multicastový paket. Množina rozhraní je dána rozmístěním posluchačů (za kterým rozhraním se nachází) vzhledem ke směrovači. K identifikaci skupin příjemců se používá speciální třída adres IP (třída D), zahrnující adresy z množiny až Rozdíl mezi unicastovým a multicastovým přenosem viz Obrázek 1 květen /18

3 Obrázek 1: Zobrazení rozdílu mezi unicastovým a multicastovým přenosem 2.2 Multicast na spojové vrstvě Protokoly na 2. vrstvě modelu ISO/OSI obsahují ve svých specifikacích podporu skupinového vysílání v podobě speciálních MAC adres. Konkrétně v případě IP multicastu cílová adresa rámce začíná 25bitovým prefixem: oktet 0 oktet 1 oktet 2 oktet 3 oktet 4 oktet xxxxxxx xxxxxxxx xxxxxxxx tedy 01:00:5E a jeden bit. Pro mapování IP adresy do takovéto MAC adresy se používá zbylých 23 bitů. Každa multicastová IP adresa začíná bitovým prefixem Na rozlišení nám tedy zbývá 28 bitů. Mapování do MAC adresy nelze udělat beze ztráty a provede se tak, ze se prvních pět bitů z 28 uřízne a konec IP adresy se uloží do zbytku MAC adresy. Tedy například IP odpovídá MAC adresa 01:00:5E:01:01:01. Tato MAC adresa ovšem náleží i kupříkladu IP adrese nebo a pod. Do jedné MAC adresy se tedy mapuje 2 5 = 32 IP adres. Běžné síťové karty pracovních stanic mají schopnost podle svého okamžitého nastavení filtrovat pakety skupinového vysílání a nejbližším vrstvám programového vybavení již předávat jen relevantní část paketů skupinového vysílání, které se v lokální síti pohybují. To jsou 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á. Pro experimentování se skupinovým vysíláním v rámci lokální sítě stačí běžné technické vybavení a příslušný aplikační program. květen /18

4 2.3 Multicast na síťové vrstvě Primárním úkolem protokolů na 3. vrstvě modelu ISO/OSI 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. První protokol pro podporu multicastů byl protokol IGMP - Internet Group Management Protocol. S jeho pomocí směrovač periodicky zjišťuje zájem stanic v připojených sítích o jednotlivé proudy skupinového vysílání. 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 něž mají zájem. 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í IGMP Protokol IGMP, definovaný v RFC 1112 a RFC 2236 pro verzi 2, dynamicky registruje jednotlivé posluchače multicastového vysílání. Posluchač identifikuje členství ve skupině odesláním zpráv protokolu IGMP a data zasílá vždy všem členům skupiny. Směrovače používající protokol IGMP pravidelně naslouchají zprávám tohoto protokolu a systematicky odesílají dotazy s cílem zjistit, které skupiny jsou v síti LAN aktivní. Směrovače spolu komunikují pomocí multicastových směrovacích protokolů, které jsou popsáný níže Směrování multicastů Směrovače musí, kromě trvalého mapování svého bezprostředního okolí, zajistit tok paketů skupinového vysílání i do vzdálených oblastí sítě, a to pokud možno optimálním způsobem. K tomu slouží tzv. směrovací protokoly. Pomocí nich 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. Je zřejmé, že na rozdíl od klasického směrování přímého vysílání půjde o proces velmi dynamický. Cesta od daného zdroje k danému cíli je totiž stálá, pokud nedojde k nějaké vnější události měnící topologii sítě, např. poruše linky. Naproti tomu zájemci o příjem daného skupinového vysílání mohou vznikat a zanikat trvale a tento proces průběžných změn musí směrovací protokoly vhodně reflektovat. Směrovací protokoly skupinového vysílání jsou dosud předmětem dalšího výzkumu a vývoje. V současné době se nejvíce používá protokol PIM - Protocol Independent Multicast Distribuční stromy Používají se na distribuci multicastů tak, aby multicastové pakety příšly ke všem zájemcům, ale nechodily tam, kde o ně zájem není. Proto v případě, že se objeví nový zájemce o daný typ vysílání a sdělí to nejbližšímu směrovači, musí daný směrovač požádat nadřazený multicastový směrovač o to, aby na něj byl směrován požadovaný typ multicastové skupiny. Dále bude přidána další větev do distribučního stromu. Obdobná operace nastane, když zájemce přestane mít zájem o dané vysílání, směrovač musí tento strom prořezat. Pokud ani na jednom z jeho rozhraní není požadován tento typ multicastu, reportuje svému nadřazenému multicastovému smerovači v distribučním stromu to, že celou multicastovou skupinu k němu nemá posílat. květen /18

5 2.4 Režimy vysílání dat Pro distribuci multicastu se používají dva režimy: hustý režim Dense Mode řídký režim Sparse Mode Hustý režim V tomto režimu se předpokládá, že všichni budou chtít všechny multicastové skupiny poslouchat, a tak je tam vše standardně doručováno. Teprve když nebudou chtít, aby k nim něco přicházelo, explicitně o tom dají vědět pomocí IGMP protokolu. Multicastový směrovač se snaží v pravidelných intervalech znovu posílat nechtěný provoz a tedy posluchač ho musí pravidelně odmítat Tuto funkci využijeme, pokud máme velkou hustotu posluchačů. Provoz je implicitně směrován do všech segmentů Řídký režim Je opakem hustého režimu. Pokud chceme dostávat žádaný multicastový provoz, musíme o něj explicitně požádat. Jak už bylo výše uvedeno, žádost se posílá pomocí IGMP protokolu. Tuto žádost posílá posluchač nejbližšímu směrovači, který musí podporovat směrování multicastů. Tuto funkci využijeme, pokud máme malou hustotu a velké rozprostření posluchačů. 2.5 PIM PIM Protocol Independent Multicast - je multicastový směrovací protokol, který je nezávislý na specifickém unicastovém směrovacím protokolu použitým v síti. PIM ovšem není skutečný směrovací protokol, protože spoléhá na dobrou funkci použitého skutečného směrovacího protokolu (např: OSPF, RIP, atd.). PIM je obecně navržen pro oba režimy distribuce dat a to jak hustého, tak řídkého. Tento protokol je otevřený standard a proto je rozšířený na hlavní síťové platformy jako Cisco, Linux a v neposlední řadě námi testované platformy MikroTik Randezvous Point Randezvous Point dále jen RP, se používá jako registrační bod pro usnadnění správněho směrování paketů. Je nakonfiguorován staticky nebo dynamicky. Statická konfigurace spočívá v ručním nastavení IP adresy RP na všech směrovačích v oblasti, kde chceme směrovat multicasty. Dynamickou konfigurací jsme se nezabývali Parametr Hello-holdtime Tento parametr slouží k určení kdy vyprší vazba se sousedem, pokud nepřichází tzv. hello pakety (zprávy), které PIM periodicky posílá mezi sousedy. 3 MikroTik MikroTik je směrovací operační systém založený na bázi Linux OS, vhodný zejména pro bezdrátové spoje a jako bezpečný HW firewall, popřípadě směrovač se snadnou GUI konfigurací. Komunikace s tímto OS se provádí zejména přes GUI Winbox, ssh, telnet, sériovou konzoli. Dnes je tento OS zejména uplatňován u kvalitních bezdrátových spojů a a b/g (Wi-Fi). květen /18

6 3.1 Podpora multicastů na platformě MikroTik Multicasty se na platformě MikroTik objevily od verze 3.0 a na starších verzích se ani neplánují implementovat. MikroTik používá pro komunikaci mezi multicast směrovači protokol PIM-SM (PIM- Sparse Mode) přebraný z implementace projektu XORP extensible Open Router Platform. RP - Randezvous Point jde nakonfigurovat jak staticky, tak dynamicky pomocí tzv. Bootstrap protokolu. Pro komunikaci mezi příjemci multicastového provozu a multicastovým směrovačem se používá standardně protokol IGMP verze 2. MikroTik také podporuje IGMP verze 1 a verze Konfigurace na platformě MikroTik Jak už bylo napsáno, PIM není opravdový směrovací protokol. Tedy je třeba zajistit směrování pomocí klasického protokolu (RIP, OSPF) nebo statických cest. Konfigurace se skládá ze dvou kroků a to: nastavení RP příklad konfigurace: [admin@mk] > routing pim rp add address= nastavení RP na určení rozhraní pro multicasty příklad konfigurace: [admin@mk] > routing pim interface add interface=all zapnutí multicastů na všech dostupných rozhraních Po této základní konfiguraci je stav rozhraní směrovače viz Obrázek 3. Ukázka je ze směrovače MK2, který je součástí naší testovací topologie, viz Obrázek 2. Směrovače MK1, MK2 a MK3 mají tři rozhraní a na všech běží PIM i IGMP. Můžeme vidět počty PIM sousedů a kdo je designated router. 4 Praktické zapojení 4.1 Topologie Topologie byla zvolena s ohledem na možnost redundantní cesty pro multicastový provoz. Použili jsme tři směrovače a zapojili jsme je do trojúhelníku viz Obrázek 2. květen /18

7 květen /18

8 Obrázek 2: Zvolená testovací topologie květen /18

9 Obrázek 3: Rozhraní pro informace o PIMu kdo je designated router, zda běží IGMP a PIM na daném rozhraní a počet PIM sousedů. 4.2 Konfigurace Nastavení na jednotlivých směrovačích je následující: MK1 /interface bridge add disabled=no name="bridge1" /routing ospf area add area-id= authentication=none disabled=no name="backbone" type=default /ip address add address= /24 broadcast= disabled=no interface=ether1 network= add address= /24 broadcast= disabled=no interface=ether2 network= add address= /24 broadcast= disabled=no interface=ether3 network= add address= /32 broadcast= disabled=no interface=bridge1 network= /system identity set name="mk1" /routing ospf set router-id= /routing ospf network add area=backbone disabled=no network= /24 add area=backbone disabled=no network= /24 květen /18

10 add area=backbone disabled=no network= /24 add area=backbone disabled=no network= /32 /routing pim interface add disabled=no interface=all /routing pim rp add address= disabled=no group= /4 hash-mask-length=30 priority=192 MK2 /interface bridge add disabled=no name="bridge1" /routing ospf area add area-id= authentication=none disabled=no name="backbone" type=default /ip address add address= /24 broadcast= disabled=no interface=ether1 network= add address= /24 broadcast= disabled=no interface=ether2 network= add address= /24 broadcast= disabled=no interface=ether3 network= add address= /32 broadcast= disabled=no interface=bridge1 network= /system identity set name="mk2" /routing ospf set router-id= /routing ospf network add area=backbone disabled=no network= /24 add area=backbone disabled=no network= /24 add area=backbone disabled=no network= /24 add area=backbone disabled=no network= /32 /routing pim interface add disabled=no interface=all /routing pim rp add address= disabled=no group= /4 hash-mask-length=30 priority=192 MK3 /interface bridge add disabled=no name="bridge1" /routing ospf area add area-id= authentication=none disabled=no name="backbone" type=default /ip address add address= /24 broadcast= disabled=no interface=ether3 network= add address= /24 broadcast= disabled=no interface=ether1 network= add address= /24 broadcast= disabled=no interface=ether2 network= add address= /32 broadcast= disabled=no interface=bridge1 network= /system identity set name="mk3" /routing ospf set router-id= /routing ospf network add area=backbone disabled=no network= /24 add area=backbone disabled=no network= /24 add area=backbone disabled=no network= /24 add area=backbone disabled=no network= /32 /routing pim interface add disabled=no interface=all /routing pim rp add address= disabled=no group= /4 hash-mask-length=30 priority= Testovací provoz Pro simulaci multicastového provozu jsme použili VLC media player, jak ve funkci sender-vysílač, tak ve funkci client-posluchač multicastového provozu. Vysílač posílal hudební stream na multicastovou adresu a posluchači se registrovali do této multicastové skupiny Zapnutí vysílače S Po zapnutí vysílání do multicastové skupiny přicházely pakety na nejbližší směrovač (MK1), který byl zároveň RP. Protože ještě žádný posluchač neměl zájem o tuto skupinu, multicastová skupina se dále neposílala. V případě, že by byl RP na jiném směrovači, posílala by se multicastová skupina na něj. květen /18

11 4.3.2 Zapnutí přijímače C2 Výsledkem bylo to, že se posluchač úspěšně zaregistroval do multicastové skupiny viz Obrázek 4. Obrázek 4: Zaregistrovaná multicastová skupina Následně mu začal od vysílače přicházet hudební stream. Viz následující výpis z programu Wireshark, který poslouchal na sítově kartě stanice C2: Stanice C2 žádá o poslech multicastové skupiny IGMP V2 Membership Report / Join group Frame 139 (46 bytes on wire, 46 bytes captured) Ethernet II, Src: Intel_69:01:c8 (00:16:76:69:01:c8), Dst: IPv4mcast_00:01:64 (01:00:5e:00:01:64) Internet Protocol, Src: ( ), Dst: ( ) Internet Group Management Protocol IGMP Version: 2 Type: Membership Report (0x16) Max Response Time: 0,0 sec (0x00) Header checksum: 0x089b [correct] Multicast Address: ( ) MK2 začíná posílat multicastovou skupinu kb/s 44,1 khz MPEG-1 Audio Layer 3[Malformed Packet] Frame 140 (1358 bytes on wire, 1358 bytes captured) Ethernet II, Src: Routerbo_28:5c:36 (00:0c:42:28:5c:36), Dst: IPv4mcast_00:01:64 (01:00:5e:00:01:64) Internet Protocol, Src: ( ), Dst: ( ) User Datagram Protocol, Src Port: bvtsonar (1149), Dst Port: search-agent (1234) ISO/IEC PID=0x0 CC=12 ISO/IEC PID=0x42 CC=12 ISO/IEC PID=0x44 CC=0 [Malformed Packet: MPEG Audio] mnoho paketu stejneho streamu... Stanice C2 podruhé žádá o poslech multicastové skupiny (program standardně žádá o multicastovou skupinu 3x) IGMP V2 Membership Report / Join group Frame 161 (46 bytes on wire, 46 bytes captured) Ethernet II, Src: Intel_69:01:c8 (00:16:76:69:01:c8), Dst: IPv4mcast_00:01:64 (01:00:5e:00:01:64) Internet Protocol, Src: ( ), Dst: ( ) Internet Group Management Protocol IGMP Version: 2 Type: Membership Report (0x16) Max Response Time: 0,0 sec (0x00) Header checksum: 0x089b [correct] Multicast Address: ( ) MK2 stále posílá multicastovou skupinu kb/s 44,1 khz MPEG-1 Audio Layer 3[Malformed Packet] Frame 162 (1358 bytes on wire, 1358 bytes captured) Ethernet II, Src: Routerbo_28:5c:36 (00:0c:42:28:5c:36), Dst: IPv4mcast_00:01:64 (01:00:5e:00:01:64) Internet Protocol, Src: ( ), Dst: ( ) User Datagram Protocol, Src Port: bvtsonar (1149), Dst Port: search-agent (1234) ISO/IEC PID=0x44 CC=13 květen /18

12 ISO/IEC PID=0x44 CC=14 ISO/IEC PID=0x44 CC=15 ISO/IEC PID=0x0 CC=0 ISO/IEC PID=0x42 CC=0 ISO/IEC PID=0x44 CC=0 [Malformed Packet: MPEG Audio] mnoho paketu stejneho streamu... Stanice C2 potřetí žádá o poslech multicastové skupiny (program standardně žádá o multicastovou skupinu 3x) IGMP V2 Membership Report / Join group Frame 193 (46 bytes on wire, 46 bytes captured) Ethernet II, Src: Intel_69:01:c8 (00:16:76:69:01:c8), Dst: IPv4mcast_00:01:64 (01:00:5e:00:01:64) Internet Protocol, Src: ( ), Dst: ( ) Internet Group Management Protocol IGMP Version: 2 Type: Membership Report (0x16) Max Response Time: 0,0 sec (0x00) Header checksum: 0x089b [correct] Multicast Address: ( ) MK2 stále posílá multicastovou skupinu kb/s 44,1 khz MPEG-1 Audio Layer 3[Malformed Packet] Frame 194 (1358 bytes on wire, 1358 bytes captured) Ethernet II, Src: Routerbo_28:5c:36 (00:0c:42:28:5c:36), Dst: IPv4mcast_00:01:64 (01:00:5e:00:01:64) Internet Protocol, Src: ( ), Dst: ( ) User Datagram Protocol, Src Port: bvtsonar (1149), Dst Port: search-agent (1234) ISO/IEC PID=0x44 CC=4 [Malformed Packet: MPEG Audio] MK2 stále posílá multicastovou skupinu kb/s 44,1 khz MPEG-1 Audio Layer 3[Malformed Packet] Frame 195 (1358 bytes on wire, 1358 bytes captured) Ethernet II, Src: Routerbo_28:5c:36 (00:0c:42:28:5c:36), Dst: IPv4mcast_00:01:64 (01:00:5e:00:01:64) Internet Protocol, Src: ( ), Dst: ( ) User Datagram Protocol, Src Port: bvtsonar (1149), Dst Port: search-agent (1234) ISO/IEC PID=0x44 CC=11 ISO/IEC PID=0x44 CC=12 [Malformed Packet: MPEG Audio] Nyní jsme ukončili poslech multicastového streamu (zastaveno přehrávání VLC media playeru): Stanice C2 opouští multicastovou skupinu IGMP V2 Leave Group Frame 196 (46 bytes on wire, 46 bytes captured) Ethernet II, Src: Intel_69:01:c8 (00:16:76:69:01:c8), Dst: IPv4mcast_00:00:02 (01:00:5e:00:00:02) Internet Protocol, Src: ( ), Dst: ( ) Internet Group Management Protocol IGMP Version: 2 Type: Leave Group (0x17) Max Response Time: 0,0 sec (0x00) Header checksum: 0x079b [correct] Multicast Address: ( ) MK2 se doptává, zdali ještě někdo nemá zájem o multicastové vysílání IGMP V2 Membership Query / Join group Frame 197 (60 bytes on wire, 60 bytes captured) Ethernet II, Src: Routerbo_28:5c:36 (00:0c:42:28:5c:36), Dst: IPv4mcast_00:01:64 (01:00:5e:00:01:64) Internet Protocol, Src: ( ), Dst: ( ) Internet Group Management Protocol IGMP Version: 2 Type: Membership Query (0x11) Max Response Time: 1,0 sec (0x0a) Header checksum: 0x0d91 [correct] Multicast Address: ( ) MK2 stále posílá multicastovou skupinu. květen /18

13 kb/s 44,1 khz MPEG-1 Audio Layer 3[Malformed Packet] Frame 198 (1358 bytes on wire, 1358 bytes captured) Ethernet II, Src: Routerbo_28:5c:36 (00:0c:42:28:5c:36), Dst: IPv4mcast_00:01:64 (01:00:5e:00:01:64) Internet Protocol, Src: ( ), Dst: ( ) User Datagram Protocol, Src Port: bvtsonar (1149), Dst Port: search-agent (1234) ISO/IEC PID=0x44 CC=0 [Malformed Packet: MPEG Audio] mnoho paketu stejneho streamu... MK2 se doptává, zdali ještě někdo nemá zájem o multicastové vysílání IGMP V2 Membership Query / Join group Frame 224 (60 bytes on wire, 60 bytes captured) Ethernet II, Src: Routerbo_28:5c:36 (00:0c:42:28:5c:36), Dst: IPv4mcast_00:01:64 (01:00:5e:00:01:64) Internet Protocol, Src: ( ), Dst: ( ) Internet Group Management Protocol IGMP Version: 2 Type: Membership Query (0x11) Max Response Time: 1,0 sec (0x0a) Header checksum: 0x0d91 [correct] Multicast Address: ( ) MK2 stále posílá multicastovou skupinu kb/s 44,1 khz MPEG-1 Audio Layer 3[Malformed Packet] Frame 225 (1358 bytes on wire, 1358 bytes captured) Ethernet II, Src: Routerbo_28:5c:36 (00:0c:42:28:5c:36), Dst: IPv4mcast_00:01:64 (01:00:5e:00:01:64) Internet Protocol, Src: ( ), Dst: ( ) User Datagram Protocol, Src Port: bvtsonar (1149), Dst Port: search-agent (1234) ISO/IEC PID=0x44 CC=9 ISO/IEC PID=0x44 CC=10 ISO/IEC PID=0x44 CC=11 ISO/IEC PID=0x44 CC=12 [Malformed Packet: MPEG Audio] mnoho paketu stejneho streamu... MK2 přestal posílat multicastovou skupinu , protože se mu nedostalo žádné jiné žádosti o tuto multicastovou skupinu, ani odpověď na dotaz Zapnutí posluchačů C2 a C3 Po registraci stanic C2 a C3 se na MikroTicích vybudoval distribuční strom. Multicastová přeposílací tabulka (MFC - Multicast Forwarding Cache) všech směrovačů (MK1, MK2 a MK3) viz Obrázek 5. Obrázek 5: MFC - Multicast Forwarding Cache na všech MikroTicích (MK1, MK2 a MK3) květen /18

14 Multicastový provoz se choval dle očekávání: z RP se posílal na jednotlivé sousedy a odtud se přeposílal na posluchače Rozpojení linky Topologii jsme obohatili o další síťové prvky, viz Obrázek 6. Připojili jsme HUB, abychom mohli sledovat provoz mezi směrovači MK1 a MK2, a také abychom mohli vyzkoušet rozpojit jen jednu stranu spoje mezi MK1 a MK2. Testovali rozpojení a následné chování po znovuzapojení naší sítě. Spoj mezi MK1 a MK2 jsme nechali rozpojen po různou dobu. Při testování jsme zjistili rozdílné chování při dlouhodobém (cca 10 minut) a krátkodobém (cca 10 sekund) odpojení linky. Při rozpojení došlo ke změně v distribučním stromu, který si směrovače vytvořily, aby zajistily posluchačům dostupnost multicastové skupiny. MFC vypadala následovně viz Obrázek 7. Všimněme si, že na MK1 je stále odchozí rozhraní ether2. Je to dáno tím, že linka tohoto rozhraní je stále aktivní (připojená k hubu). Tento stav lze pozorovat maximalně 1 minutu a 45 sekund. Čas je dán parametrem hello-holdtime, který lze konfigurovat. Pokud se vrátí linka zpět, provoz se znovu přesměruje přes linku mezi MK1 a MK2, jelikož má tato linka lepsí cenu je to dáno směrovacím protokolem OSPF. Obrázek 6: Obohacená topologie s rozpojenou linkou. květen /18

15 květen /18

16 Obrázek 7: MFC - Multicast Forwarding Cache na všech MikroTicích (MK1, MK2 a MK3) po odpojení linky Rozpojení linky na druhé straně hubu Po znovuzapojení všech rozhraní jsme provedli další test s rozpojováním topologie viz Obrázek 8. Poté, co po rozpojení označené linky znovu zkonverguje OSPF, je MFC tabulka směrovačů MK1, MK2 a MK3 velice podobná jako Obrázek 7 s tím rozdílem, že už MK1 nemá odchozí rozhraní ether2. Pokud znovu zapojíme linku před vypršením hello-holdtime intervalu, dostaneme se do nekorektního stavu, kdy RP (MK1) přes PIM vidí sousedy, ale RP multicasty neposílá, přestože MK2 zasílá zprávu join pro vyžádanou multicastovou skupinu. květen /18

17 Obrázek 8: Topologie s linkou rozpojenou na druhé straně hubu. Jedna z možností, jak zamezit nebo se dostat z tohoto nekorektního stavu, je počkat s rozpojeným rozhraním alespoň po dobu hello-holdtime intervalu (standardně 105 s), nebo restartovat všechny MikroTiky v celé naší sítí. Restartováním jen jednoho, ať už MK1 nebo MK2 si moc nepomůžeme, stále setrváváme v nekorektním stavu. Restartováním MK1 a MK2 zároveň, způsobíme rozpad linek s MK3 směrovačem, jehož linky se dostanou do stejného nekorektního stavu jako linka mezi MK1 a MK2. Tento nekorektní stav se pohledem na konfiguraci přes GUI projevuje rychlou změnou DR na znovuspojené lince (řádově v sekundách). Po nastavení hello-holdtime intervalu na 75 s na všech směrovačích jsme experimentálně ověřili, že změna tohoto parametru souvisí se vznikem nekorektního stavu. Poté stačí vyčkat se znovuzapojením linky cca 80 s a multicastový provoz se opět obnoví. Před změnou tohoto parametru 80 s nestačilo. 5 Zhodnocení použitelnosti Po standardním nakonfigurování směrovačů vše funguje tak, jak má a multicasty se směrují podle očekávání. Problém ovšem nastane při výpadku některé z linek mezi multicastovými směrovači. Tento problém se dá nejrychleji vyřešit tak, že necháme restartovat všechny multicastové směrovače. Druhým řešením je vyčkat se znovupřipojením linky minimálně po dobu hello-holdtime intervalu. Vzhledem k těmto problémům se nasazení multicastů na platformě MikroTik do reálného prostředí jeví jako nevhodné. 6 Závěr Po několika hodinách strávených konfigurací multicastů na platformě MikroTik, kdy se zdálo, že vůbec netušíme, proč to jednou funguje a po druhé zase nefunguje, jsme začali poznávat taje a zákoutí implementace multicastu na této platformě. květen /18

18 Po této zkušenosti můžeme říct, že umíme predikovat nefunkčnost multicastů a domníváme se, že problém je na straně implementace protokolu PIM na platformě MikroTik. I když zařízení hlásí, že posílá data pro další směrovač, fyzicky data vůbec neopouští rozhraní směrovače. 7 Zdroje 1. Multicast [online], [cit ]. Dostupné na: 2. Multicast: skupinové vysílání [online], [cit ]. Dostupné na: 3. Multicast Routing in RouterOS 3.x [online], [cit ]. Dostupné na: květen /18