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. Teoretická část... 2 1.1. Multicast... 2 1.1.1. Adresování... 2 1.1.2. IGMP... 2 1.1.3. IGMP snooping... 3 1.1.4. PIM... 3 1.1.5. Mrouter (multicast router) port... 3 1.2. Popis problému... 3 1.3. Řešení problému... 4 1.3.1. Povolení PIM protokolu na směrovači pracujícím na třetí vrstvě... 4 1.3.2. Povolení IGMP querier na přepínači... 4 1.3.3. Statické nastavení mrouter portu na přepínači... 4 1.3.4. Nastavení statických multicastových mac záznamů na všech přepínačích... 4 1.3.5. Vypnutí IGMP snoopingu na všech přepínačích... 4 2. Praktické ověření... 4 2.1. Topologie... 4 2.2. Konfigurace... 5 2.2.1. Ověření prvního řešení... 5 2.2.2. Ověření druhého řešení... 5 2.2.3. Ověření třetího řešení... 5 2.2.4. Ověření čtvrtého řešení... 6 2.2.5. Ověření pátého řešení... 6 3. Závěr... 6 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.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 [1]. 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í 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 Tabulka 1: typy IGMP zpráv Květen 2015 2/7
1.1.3. 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.4. 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.5. 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ů. 1.2. Popis problému Obrázek 1: Problémová topologie 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í. Květen 2015 3/7
1.3. Řešení problému 1.3.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. 1.3.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. 1.3.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čů. 1.3.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. 1.3.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. 2. Praktické ověření 2.1. Topologie Obrázek 2: testovací topologie Květen 2015 4/7
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č. 2.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. Obrázek 3: nastavení VLAN 2.2.1. Ověření prvního řešení 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. 2.2.2. Ověření druhého řešení Obrázek 4: výpis z Wiresharku SW1(config)#ip igmp snooping querier Obrázek 5: konfigurace portu 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í. 2.2.3. Ověření třetího řešení SW2(config)#ip igmp snooping vlan 1 mrouter interface fastethernet 0/1 Obrázek 6: zobrazení portu Květen 2015 5/7
Datagramy opět procházely sítí bez problému přesně tak, jak mají. 2.2.4. Ověření čtvrtého řešení Obrázek 7: staticky nastavená mac adresa Nastavení statických mac adres do tabulek je nejméně vhodné a nejvíce pracné řešení, funkčností je na tom ale stejně. 2.2.5. Ověření pátého řešení SW1(config)#no ip igmp snooping SW2(config)#no ip igmp snooping 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. 3. Závěr Cílem projektu bylo prozkoumat a prakticky ověřit možná řešení šíření multicastového provohu v L2 sítích založených na přepínačích CISCO. Nejjednodušším řešení, které jsme vyzkoušeli, bylo nastavení topologie takovým způsobem, že šířila multicastový provoz jako broadcast. Příjemci tedy dostávali očekávaná data, která ale byla zbytečně šířena i do zbytku sítě a docházelo tím k plýtvání přenosové kapacity. Proto jsme ve druhém testu přidali do sítě směrovač, který zajistil správné šíření IGMP zpráv a následně i multicastového provozu. Ne vždy je však k dispozici prvek pracující na třetí vrstvě a proto jsme testovali i další řešení. Třetí řešení spočívalo v nastavení IGMP querier funkce na jednom ze směrovačů, který převzal roli prvku pracujícího na třetí vrstvě a dokázal jeho roli v naší topologii nahradit. Poslední dvě řešení spočívaly v nastavení statických portů a mac adres na směčovačích. U všech řešení jsme ověřili, že jsou funkční. Avšak každé se svou povahou hodí do jiných typů sítě a je nutno vybrat nejvhodnější podle aktuální situace s ohledem na budoucí možné změny v topologii. Květen 2015 6/7
Zdroje [1] multicastové zprávy dostupné z: http://www.iana.org/assignments/igmp-type-numbers/igmp-type-numbers.xhtml#igmp-type-numbers-codes-1 Květen 2015 7/7