Multicast a smÂ¦Å¤rov+Ã-n+Å- provozu

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ásle-duje 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 ÚvodMulticast 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í vlastnostiHlavní úlohou této technologie je snížení zátěže vysílajícího uzlu a přenosové sou-

stavy 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 pone-chá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 je-denkrá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), zahrnu-jí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

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 nasta-vení filtrovat pakety skupinového vysílání a nejbližším vrstvám programového vyba-vení 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é tech-nické vybavení a příslušný aplikační program.

květen 2008 3/18

Obrázek 1: Zobrazení rozdílu mezi unicastovým a multicastovým přenosem

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ři-pojeny.

První protokol pro podporu multicastů byl protokol IGMP - Internet Group Manage-ment 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 nedo-chá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 IGMPProtokol IGMP, definovaný v RFC 1112 a RFC 2236 pro verzi 2, dynamicky regis-

truje 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 pro-tokolu a systematicky odesílají dotazy s cílem zjistit, které skupiny jsou v síti LAN ak-tivní. 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 opti-má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í stromyPouží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ža-dová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í datPro distribuci multicastu se používají dva režimy:

● hustý režim – Dense Mode● řídký režim – Sparse Mode

2.4.1 Hustý režimV tomto režimu se předpokládá, že všichni budou chtít všechny multicastové skupi-

ny 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. Multi-castový 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 impli-citně směrován do všech segmentů.

2.4.2 Řídký režimJe 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í pod-porovat směrování multicastů.

Tuto funkci využijeme, pokud máme malou hustotu a velké rozprostření poslucha-čů.

2.5 PIMPIM – 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 PointRandezvous 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-holdtimeTento 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 MikroTikMikroTik 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ě MikroTikMulticasty 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 pomo-cí 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ě MikroTikJak už bylo napsáno, PIM není „opravdový“ směrovací protokol. Tedy je třeba zajis-

tit 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.1nastavení RP na 10.0.1.1

● určení rozhraní pro multicastypříklad konfigurace:[admin@mk] > routing pim interface add interface=allzapnutí 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 TopologieTopologie 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

květen 2008 8/18

Obrázek 2: Zvolená testovací topologie

4.2 KonfiguraceNastavení 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

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

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í provozPro 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 SPo zapnutí vysílání do multicastové skupiny 224.0.1.100 přicházely pakety na nej-

bližší 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 C2Výsledkem bylo to, že se posluchač úspěšně zaregistroval do multicastové skupiny

viz Obrázek 4.

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 Source Destination Protocol Info 139 26.405319 10.0.2.10 224.0.1.100 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 Source Destination Protocol Info 140 26.420641 192 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: 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=12ISO/IEC 13818-1 PID=0x42 CC=12ISO/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 mul-ticastovou skupinu 3x).

No. Time Source Destination Protocol Info 161 27.219182 10.0.2.10 224.0.1.100 IGMP V2 Membership Report / Join group 224.0.1.100


MK2 stále posílá multicastovou skupinu.No. Time Source Destination Protocol Info 162 27.248600 192 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: 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

Obrázek 4: Zaregistrovaná multicastová skupina 224.0.1.100

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

...


...

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

No. Time Source Destination Protocol Info 193 28.219178 10.0.2.10 224.0.1.100 IGMP V2 Membership Report / Join group 224.0.1.100



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]


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=11ISO/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 me-dia playeru):

Stanice C2 opouští multicastovou skupinu 224.0.1.100.No. Time Source Destination Protocol Info 196 28.283456 10.0.2.10 224.0.0.2 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 Source Destination Protocol Info 197 28.284745 10.0.2.1 224.0.1.100 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)

MK2 stále posílá multicastovou skupinu.No. Time Source Destination Protocol Info

květen 2008 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]

...


...

MK2 se doptává, zdali ještě někdo nemá zájem o multicastové vysílání 224.0.1.100.No. Time Source Destination Protocol Info 224 29.283724 10.0.2.1 224.0.1.100 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)


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=9ISO/IEC 13818-1 PID=0x44 CC=10ISO/IEC 13818-1 PID=0x44 CC=11ISO/IEC 13818-1 PID=0x44 CC=12[Malformed Packet: MPEG Audio]

...


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

castová přeposílací tabulka (MFC - Multicast Forwarding Cache) všech směrovačů (MK1, MK2 a MK3) viz Obrázek 5.

květen 2008 13/18

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

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í linkyTopologii 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 pozo-rovat 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.

květen 2008 14/18

Obrázek 6: Obohacená topologie s rozpojenou linkou.

květen 2008 15/18

4.3.5 Rozpojení linky na druhé straně hubuPo 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 nepo-sílá, přestože MK2 zasílá zprávu join pro vyžádanou multicastovou skupinu.

květen 2008 16/18

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

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. Restar-tová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 experi-mentá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žitelnostiPo 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ři-pojení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ěrPo 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

Obrázek 8: Topologie s linkou rozpojenou na druhé straně hubu.

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

Documents

Multicast a smÂ¦Å¤rov+Ã-n+Å- provozu