L2 multicast v doméně s přepínači CISCO Vojtěch Kotík (KOT0084) Abstrakt: Tento dokument se zabývá šířením L2 multicastu v doméně složené z přepínačů Cisco. Obsahuje stručný popis technologie a jejích vlastností. Popisuje známé problémy a zkoumá možnosti jejich řešení. Obsahuje také výsledky laboratorních testů popsaných řešeních na technologiích společnosti Cisco. Klíčová slova: multicast, L2, IGMP, PIM, cisco 1.1.Multicast... 2 1.1.2.IGMP... 2 Květen 2015 1/7
1. Teoretická část Multicast umožňuje doručení datagramů od zdroje provozu více příjemcům současně bez nutnosti vysílat oddělené proudy jednotlivým příjemcům, což umožňuje snížit vytížení přenosové kapacity. Při provozu sítí založených pouze na prvcích druhé vrstvy však dochází k problémům se správným šířením multicastového provozu. Tento projekt popisuje tyto problémy a zkoumá jejich možná řešení. 1 Multicast Základem multicastu je odesílání pouze jedné kopie datagramů, která je duplikována pouze v místech, kde se dělí cesty k jednotlivým příjemcům. Proto je potřeba mít k dispozici efektivní způsob, jak mohou příjemci projevit zájem o datagramy, aby nedocházelo ke zbytečnému zahlcování sítě. 1.1.1. Adresování Pro multicastové skupiny jsou používány IP adresy třídy D. - Rezervované (224.0.0.0 224.0.0.255) pro nejmenší subnety, hodnota TTL je pevně nastavena na hodnotu 1, proto nemůžou projít žádným routerem - Administrativní (239.0.0.0 239.255.255.255) pro soukromé použití v rámci jedné sítě - Veřejné (224.0.1.0 224.0.1.255 a 224.0.2.0 238.255.255.255) pro šíření celým internetem 1.1.2. IGMP Protokol vytvořený pro dynamické spravování skupin příjemců multicastových proudů. Používá se pro přihlašování a odhlašování ze skupin v lokální síti. Bez něj se multicastové datagramy šíří sítí jako broadcast, což zbytečně zahlcuje přenosovou kapacitu. Existuje ve třech verzích. - IGMPv1 obsahuje pouze zprávy membership query a membership reply. Neumožňuje stanicím odhlášení z příjmových skupin. Místo toho je v pravidelném intervalu kontrolováno, zda má na daném síťovém segmentu ještě někdo zájem přijímat. - IGMPv2 membership query mohou být nově odesílány i na specifické skupiny. V této verzi byl také sjednocen způsob, kterým probíhá výběr řídícího prvku (tzv. querier) stává se jím router s nejnižší ip adresou. Přibyla také leave zpráva umožňující odhlášení příjmu. - IGMPv3 vylepšuje vlastnosti předchozích verzí 1.1.2.1. Typy IGMP zpráv 0x00 Reserved 0x01-0x08 Reserved (Obsolete) 0x09-0x10 Unassigned 0x11 IGMP Membership Query 0x12 IGMPv1 Membership Report 0x13 DVMRP 0x14 PIM version 1 0x15 Cisco Trace Messages 0x16 IGMPv2 Membership Report 0x17 IGMPv2 Leave Group 0x1e Multicast Traceroute Response 0x1f Multicast Traceroute 0x22 IGMPv3 Membership Report 0x30 Multicast Router Advertisement 0x31 Multicast Router Solicitation 0x32 Multicast Router Termination 0xf0-0xff Reserved for experimentation Květen 2015 2/7
1.1.2.2. IGMP snooping Mechanismus k zajištění odesílání datagramů pouze na porty, na kterých leží příjemci. Přepínač naslouchá zprávám směrovače a koncových příjemců, na jejich základě si buduje tabulku portů, které multicastový provoz chtějí přijímat. 1.1.2. PIM Rodina multicastových protokolů. Neobsahují vlastní mechanismy pro průzkum síťové topologie a využívají tyto informace z ostatních směrovacích protokolů. Existují ve dvou hlavních variantách. Sparse mode vytváří jednosměrné stromy od rendezvous point (kořen všech stromů). Také může vytvářet pro jednotlivé zdroje kratší cesty. Vhodný pro větší sítě. Dense mode vytváří stromy nejkratších cest pomocí zaplavování celé sítě multicastovým provozem a následným odřezáváním větví, které nemají zájem o příjem. 1.1.3. Mrouter (multicast router) port Někdy také označován jako uplink port. Slouží k příjmu hello a join datagramů PIM protokolu pro správně směrování multicastových datagramů. 2. Popis problému V doméně složené pouze z přepínačů CISCO dochází k problémům s šířením IGMP zpráv. V topologii na obrázku (doplnit odkaz) zdroj vysílá multicastový provoz na přepínač SW1. Příjemce je připojen do přepínače SW4. Ten však neposílá igmp zprávy dále přes přepínače SW2 nebo SW3, což vede k tomu, že není možné navázat spojení. 2.1. Řešení problému 2.1.1. Povolení PIM protokolu na směrovači pracujícím na třetí vrstvě Toto řešení je použitelné v případě, že máme k dispozici směrovač, kterým můžeme topologii rozšířit. Všechny Cisco přepínače jsou schopny se dynamicky učit přítomnost mrouter portu. Květen 2015 3/7
2.1.2. Povolení IGMP querier na přepínači Používá se v případě, kdy nemáme k dispozici směrovač. Na směrovači povolíme funkci IGMP querier, která periodicky do sítě zasílá IGMP požadavky. Díky tomu směrovač považuje sám sebe za mrouter port. Ostatní přepínače v síti definují jako mrouter porty rozhraní, ze kterého jim přicházejí IGMP zprávy. 2.1.3. Statické nastavení mrouter portu na přepínači Multicastový provoz nefunguje i v rámci jedné vlan v případě absence mrouter portů. Pokud nelze uskutečnit ani jedno ze dvou předcházejících řešení, je možné nastavit na všech přepínačích staticky jako mrouter příslušné porty, vedoucí do jiných směrovačů. 2.1.4. Nastavení statických multicastových mac záznamů na všech přepínačích Spočívá ve statickém nastavení mac adres zdroje a příjemců do adresní tabulky přepínače. Nejméně vhodné řešení pro sítě, u kterých je více multicastového provozu. 2.1.5. Vypnutí IGMP snoopingu na všech přepínačích Multicastový provoz je šířen jako broadcast. Máme sice garantováno doručení příjemci, ale dochází ke zbytečnému zahlcování síťových segmentů, kde nejsou příjemci. 3. Praktické ověření 3.1. Topologie Použity byly směrovače Cisco Catalyst 2960 a směrovač Cisco řady 2800. Operační systém byl IOS verze 15.0(2)SE4. Pro testování odesílání a příjmu multicastového provozu byl použit VLC přehrávač. 3.2. Konfigurace Všechny prvky a rozhraní byla nastavena do jedné VLAN (123) a mezi přepínači byly nastaveny trunk propoje. Také jsme ověřili, že je na všech přepínačích zapnutý IGMP snooping. Květen 2015 4/7
3.3.1. Ověření prvního řešení Bohužel screeny s ověřením tohoto řešení má můj neschopný kolega. Naše řešení spočívalo v zapojení směrovače do přepínače. Následně jsme povolili protokol PIM v dense módu. Po spuštění streamu ve VLC přehrávači bylo ve Wiresharku vidět, že pakety se síří sítí jen tam, kde je o ně požádáno příjemcem. 3.3.2. Ověření druhého řešení SW1(config)#ip igmp snooping querier Nastavili jsme přepínač SW1 jako IGMP querier. Na SW2 bylo vidět, že jej viděl jako mrouter port. Šíření v síti fungovalo stejně jako u předchozího řešení. 3.3.3. Ověření třetího řešení SW2(config)#ip igmp snooping vlan 1 mrouter interface fastethernet 0/1 Datagramy opět procházely sítí bez problému přesně tak, jak mají. 3.3.4. Ověření čtvrtého řešení Nastavení statických mac adres do tabulek je nejméně vhodné a nejvíce pracné řešení, funkčností je na tom ale stejně. 3.3.5. Ověření pátého řešení SW1(config)#no ip igmp snooping SW2(config)#no ip igmp snooping Květen 2015 5/7
Bez IGMP snoopingu sice bylo pakety stále možno přijímat na všech bodech sítě, avšak i v době, kdy nebyly žádným příjemcem požadovány. 4. Závěr Ověřili jsme možné problémy se sířením multicastu v L2 sítích a jejich řešení. Tyto řešení přesně splnila očekávání a umožňují efektivně problém vyřešit. Květen 2015 6/7
Zdroje http://www.iana.org/assignments/igmp-type-numbers/igmp-type-numbers.xhtml#igmp-type-numberscodes-1 (multicastové zprávy) Květen 2015 7/7