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

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................................................................................................2 2 Multicast.........................................................................................2 2.1 Základní vlastnosti...................................................................2 2.2 Multicast na spojové vrstvě......................................................3 2.3 Multicast na síťové vrstvě........................................................3 2.3.1 IGMP..................................................................................3 2.3.2 Směrování multicastů........................................................3 2.3.3 Distribuční stromy.............................................................4 2.4 Režimy vysílání dat...................................................................4 2.4.1 Hustý režim.......................................................................4 2.4.2 Řídký režim........................................................................4 2.5 PIM...........................................................................................4 2.5.1 Randezvous Point..............................................................4 2.5.2 Parametr Hello-holdtime...................................................5 3 MikroTik..........................................................................................5 3.1 Podpora multicastů na platformě MikroTik.............................5 3.2 Konfigurace na platformě MikroTik.........................................5 4 Praktické zapojení...........................................................................5 4.1 Topologie..................................................................................5 4.2 Konfigurace..............................................................................7 4.3 Testovací provoz.......................................................................8 4.3.1 Zapnutí vysílače S..............................................................8 4.3.2 Zapnutí přijímače C2.........................................................8 4.3.3 Zapnutí posluchačů C2 a C3............................................11 4.3.4 Rozpojení linky................................................................11 4.3.5 Rozpojení linky na druhé straně hubu.............................13 5 Zhodnocení použitelnosti..............................................................13 6 Závěr.............................................................................................14 7 Zdroje............................................................................................14 květen 2008

1/18

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 224.0.0.0 až 239.255.255.255. Rozdíl mezi unicastovým a multicastovým přenosem viz Obrázek 1

květen 2008

2/18

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 5 +--------+--------+--------+--------+--------+--------+ |00000001|00000000|01011110|0xxxxxxx|xxxxxxxx|xxxxxxxx| +--------+--------+--------+--------+--------+--------+ 76543210 76543210 76543210 76543210 76543210 76543210 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 1110. 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 224.1.1.1 odpovídá MAC adresa 01:00:5E:01:01:01. Tato MAC adresa ovšem náleží i kupříkladu IP adrese 224.129.1.1 nebo 225.1.1.1 a pod. Do jedné MAC adresy se tedy mapuje 25 = 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 2008

3/18

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 224.0.0.1) 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í.

2.3.1 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.

2.3.2 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.

2.3.3 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 2008

4/18

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

2.4.1 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ů.

2.4.2 Ří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.

2.5.1 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.

2.5.2 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ů 802.11a a 802.11b/g (Wi-Fi).

květen 2008

5/18

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 (PIMSparse 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 3.

3.2 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=10.0.1.1 nastavení RP na 10.0.1.1 ● 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 2008

6/18

květen 2008

7/18

Obrázek 2: Zvolená testovací topologie

květen 2008

8/18

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=0.0.0.0 authentication=none disabled=no name="backbone" type=default /ip address add address=10.0.1.1/24 broadcast=10.0.1.255 disabled=no interface=ether1 network=10.0.1.0 add address=10.0.12.1/24 broadcast=10.0.12.255 disabled=no interface=ether2 network=10.0.12.0 add address=10.0.13.1/24 broadcast=10.0.13.255 disabled=no interface=ether3 network=10.0.13.0 add address=10.0.0.1/32 broadcast=10.0.0.1 disabled=no interface=bridge1 network=10.0.0.1 /system identity set name="MK1" /routing ospf set router-id=10.0.0.1 /routing ospf network add area=backbone disabled=no network=10.0.1.0/24 add area=backbone disabled=no network=10.0.12.0/24

květen 2008

9/18

add area=backbone disabled=no network=10.0.13.0/24 add area=backbone disabled=no network=10.0.0.1/32 /routing pim interface add disabled=no interface=all /routing pim rp add address=10.0.1.1 disabled=no group=224.0.0.0/4 hash-mask-length=30 priority=192

●

MK2

/interface bridge add disabled=no name="bridge1" /routing ospf area add area-id=0.0.0.0 authentication=none disabled=no name="backbone" type=default /ip address add address=10.0.12.2/24 broadcast=10.0.12.255 disabled=no interface=ether1 network=10.0.12.0 add address=10.0.2.1/24 broadcast=10.0.2.255 disabled=no interface=ether2 network=10.0.2.0 add address=10.0.23.2/24 broadcast=10.0.23.255 disabled=no interface=ether3 network=10.0.23.0 add address=10.0.0.2/32 broadcast=10.0.0.2 disabled=no interface=bridge1 network=10.0.0.2 /system identity set name="MK2" /routing ospf set router-id=10.0.0.2 /routing ospf network add area=backbone disabled=no network=10.0.2.0/24 add area=backbone disabled=no network=10.0.12.0/24 add area=backbone disabled=no network=10.0.23.0/24 add area=backbone disabled=no network=10.0.0.2/32 /routing pim interface add disabled=no interface=all /routing pim rp add address=10.0.1.1 disabled=no group=224.0.0.0/4 hash-mask-length=30 priority=192

●

MK3

/interface bridge add disabled=no name="bridge1" /routing ospf area add area-id=0.0.0.0 authentication=none disabled=no name="backbone" type=default /ip address add address=10.0.3.1/24 broadcast=10.0.3.255 disabled=no interface=ether3 network=10.0.3.0 add address=10.0.13.3/24 broadcast=10.0.13.255 disabled=no interface=ether1 network=10.0.13.0 add address=10.0.23.3/24 broadcast=10.0.23.255 disabled=no interface=ether2 network=10.0.23.0 add address=10.0.0.3/32 broadcast=10.0.0.3 disabled=no interface=bridge1 network=10.0.0.3 /system identity set name="MK3" /routing ospf set router-id=10.0.0.3 /routing ospf network add area=backbone disabled=no network=10.0.3.0/24 add area=backbone disabled=no network=10.0.13.0/24 add area=backbone disabled=no network=10.0.23.0/24 add area=backbone disabled=no network=10.0.0.3/32 /routing pim interface add disabled=no interface=all /routing pim rp add address=10.0.1.1 disabled=no group=224.0.0.0/4 hash-mask-length=30 priority=192

4.3 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 224.0.1.100 a posluchači se registrovali do této multicastové skupiny.

4.3.1 Zapnutí vysílače S Po zapnutí vysílání do multicastové skupiny 224.0.1.100 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 2008

10/18

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 224.0.1.100 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 224.0.1.100. No.

Time 139 26.405319

Source 10.0.2.10

Destination 224.0.1.100

Protocol Info IGMP V2 Membership Report / Join group 224.0.1.100

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: 10.0.2.10 (10.0.2.10), Dst: 224.0.1.100 (224.0.1.100) Internet Group Management Protocol IGMP Version: 2 Type: Membership Report (0x16) Max Response Time: 0,0 sec (0x00) Header checksum: 0x089b [correct] Multicast Address: 224.0.1.100 (224.0.1.100)

MK2 začíná posílat multicastovou skupinu. No.

Time 140 26.420641

Source 192 kb/s

Destination 44,1 kHz

Protocol Info 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: 10.0.1.10 (10.0.1.10), Dst: 224.0.1.100 (224.0.1.100) User Datagram Protocol, Src Port: bvtsonar (1149), Dst Port: search-agent (1234) ISO/IEC 13818-1 PID=0x0 CC=12 ISO/IEC 13818-1 PID=0x42 CC=12 ISO/IEC 13818-1 PID=0x44 CC=0 [Malformed Packet: MPEG Audio] ... ..... mnoho paketu stejneho streamu ...

Stanice C2 podruhé žádá o poslech multicastové skupiny 224.0.1.100 (program standardně žádá o multicastovou skupinu 3x). No.

Time 161 27.219182

Source 10.0.2.10




MK2 stále posílá multicastovou skupinu. No.

Time 162 27.248600

Source 192 kb/s



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: 10.0.1.10 (10.0.1.10), Dst: 224.0.1.100 (224.0.1.100) User Datagram Protocol, Src Port: bvtsonar (1149), Dst Port: search-agent (1234) ISO/IEC 13818-1 PID=0x44 CC=13

květen 2008

11/18

ISO/IEC 13818-1 PID=0x44 CC=14 ISO/IEC 13818-1 PID=0x44 CC=15 ISO/IEC 13818-1 PID=0x0 CC=0 ISO/IEC 13818-1 PID=0x42 CC=0 ISO/IEC 13818-1 PID=0x44 CC=0 [Malformed Packet: MPEG Audio] ... ..... mnoho paketu stejneho streamu ...

Stanice C2 potřetí žádá o poslech multicastové skupiny 224.0.1.100 (program standardně žádá o multicastovou skupinu 3x). No.

Time 193 28.219178

Source 10.0.2.10





Time 194 28.232935

Source 192 kb/s



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: 10.0.1.10 (10.0.1.10), Dst: 224.0.1.100 (224.0.1.100) User Datagram Protocol, Src Port: bvtsonar (1149), Dst Port: search-agent (1234) ISO/IEC 13818-1 PID=0x44 CC=4 [Malformed Packet: MPEG Audio]


Time 195 28.279761

Source 192 kb/s



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: 10.0.1.10 (10.0.1.10), Dst: 224.0.1.100 (224.0.1.100) User Datagram Protocol, Src Port: bvtsonar (1149), Dst Port: search-agent (1234) ISO/IEC 13818-1 PID=0x44 CC=11 ISO/IEC 13818-1 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 224.0.1.100. No.

Time 196 28.283456

Source 10.0.2.10


Protocol Info IGMP V2 Leave Group 224.0.1.100

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: 10.0.2.10 (10.0.2.10), Dst: 224.0.0.2 (224.0.0.2) Internet Group Management Protocol IGMP Version: 2 Type: Leave Group (0x17) Max Response Time: 0,0 sec (0x00) Header checksum: 0x079b [correct] Multicast Address: 224.0.1.100 (224.0.1.100)

MK2 se doptává, zdali ještě někdo nemá zájem o multicastové vysílání 224.0.1.100. No.

Time 197 28.284745

Source 10.0.2.1


Protocol Info IGMP V2 Membership Query / Join group 224.0.1.100

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: 10.0.2.1 (10.0.2.1), Dst: 224.0.1.100 (224.0.1.100) Internet Group Management Protocol IGMP Version: 2 Type: Membership Query (0x11) Max Response Time: 1,0 sec (0x0a) Header checksum: 0x0d91 [correct] Multicast Address: 224.0.1.100 (224.0.1.100)


Time

květen 2008

Source

Destination

Protocol Info

12/18

198 28.326743

192 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: 10.0.1.10 (10.0.1.10), Dst: 224.0.1.100 (224.0.1.100) User Datagram Protocol, Src Port: bvtsonar (1149), Dst Port: search-agent (1234) ISO/IEC 13818-1 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í 224.0.1.100. No.

Time 224 29.283724

Source 10.0.2.1


Protocol Info IGMP V2 Membership Query / Join group 224.0.1.100

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: 10.0.2.1 (10.0.2.1), Dst: 224.0.1.100 (224.0.1.100) Internet Group Management Protocol IGMP Version: 2 Type: Membership Query (0x11) Max Response Time: 1,0 sec (0x0a) Header checksum: 0x0d91 [correct] Multicast Address: 224.0.1.100 (224.0.1.100)


Time 225 29.311071

Source 192 kb/s



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: 10.0.1.10 (10.0.1.10), Dst: 224.0.1.100 (224.0.1.100) User Datagram Protocol, Src Port: bvtsonar (1149), Dst Port: search-agent (1234) ISO/IEC 13818-1 PID=0x44 CC=9 ISO/IEC 13818-1 PID=0x44 CC=10 ISO/IEC 13818-1 PID=0x44 CC=11 ISO/IEC 13818-1 PID=0x44 CC=12 [Malformed Packet: MPEG Audio] ... ..... mnoho paketu stejneho streamu ...

MK2 přestal posílat multicastovou skupinu 224.0.1.100, protože se mu nedostalo žádné jiné žádosti o tuto multicastovou skupinu, ani odpověď na dotaz.

4.3.3 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 2008

13/18

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.

4.3.4 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 2008

14/18

květen 2008

15/18

Obrázek 7: MFC - Multicast Forwarding Cache na všech MikroTicích (MK1, MK2 a MK3) po odpojení linky

4.3.5 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 2008

16/18

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 2008

17/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. 2008-05-30]. Dostupné na: http://cs.wikipedia.org/wiki/Multicast. 2. Multicast: skupinové vysílání [online], [cit. 2008-05-30]. Dostupné na: http://www.ics.muni.cz/zpravodaj/articles/134.html. 3. Multicast Routing in RouterOS 3.x [online], [cit. 2008-05-30]. Dostupné na: http://wiki.mikrotik.com.

květen 2008

18/18

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

Recommend Documents