Úvod
Tento článek je pokračováním seriálu o IP Multicast. Podíváme se na to, jak funguje základní vícesměrové vysílání IP. Poté se podíváme na to, jak funguje PIM Dense Mode (PIM-DM), jak jej nakonfigurovat a jak řešit problémy. To by nás mělo zahřát před tím, než se v pozdějším článku pustíme do poněkud složitějšího a škálovatelnějšího režimu PIM Sparse Mode.
Úvodní článek o vícesměrovém vysílání obsahuje na svém konci odkazy na klíčové pracovní skupiny IETF. Naleznete jej na adrese The Protocols of IP Multicast.
Understanding IP Multicast Forwarding
Účelem směrovacího protokolu vícesměrového vysílání je umožnit směrovačům spolupracovat na efektivním doručování kopií paketů vícesměrového vysílání zainteresovaným příjemcům. Při tom směrovací protokol vícesměrového vysílání pravděpodobně také poskytuje mechanismus, který umožňuje sousedům zjistit a sledovat sousední směrovače, které rovněž používají směrovací protokol vícesměrového vysílání.
Jak jsme viděli v minulém článku, počítače, které mají zájem o příjem proudu paketů vícesměrového vysílání, používají protokol IGMP k oznámení sousedního směrovače (směrovačů). Směrovače pak pomocí protokolu vícesměrového vysílání zařídí, aby jim byla zaslána kopie proudu paketů vícesměrového vysílání, aby je mohly předat do sítě LAN obsahující příjemce. Nezmínili jsme se o tom, co se děje na zdrojovém konci proudu paketů. V protokolu IP multicast neexistuje žádný protokol, kterým by zdroj komunikoval nebo se registroval či oznamoval směrovačům. Zdroj prostě začne odesílat pakety vícesměrového vysílání IP a je na sousedních směrovačích, aby postupovaly správně. (Jaká „správná věc“ to bude, závisí na směrovacím protokolu vícesměrového vysílání).
Následující obrázek ukazuje červeně zdroj, který odesílá paket vícesměrového vysílání, a navazující směrovače, které tento paket duplikují a zaplavují jím ostatní směrovače a nakonec všechny segmenty sítě LAN. Jak brzy uvidíme, jedná se o počáteční (a periodické) chování směrovacího protokolu PIM (Protocol Independent Multicast) společnosti Cisco pro vícesměrové vysílání, pokud pracuje v hustém režimu.
Všimněte si na výše uvedeném obrázku, že modré šipky organizovaně předávají kopie paketů vícesměrového vysílání. Do některých směrovačů nebo segmentů sítě LAN mohou přicházet dvě kopie každého paketu. Směrovače však nepředávají pakety „pozpátku“. To je dobrá věc: zamyslete se nad tím, co by se mohlo stát, kdyby směrovač E přeposlal kopii paketu, kterou obdržel od C, směrovači B. Přeposlal by pak B paket směrovači A, který by ho mohl přeposlat směrovači C a tak dále, do smyčky předávání? Jednalo by se o jakýsi ekvivalent toho, co se děje na vrstvě 3, když je v topologii smyčky vypnut Spanning Tree: dobrý způsob, jak promrhat velkou šířku pásma a kapacitu směrovače.
Aby se zabránilo smyčkám předávání vícesměrového vysílání, vícesměrové vysílání IP vždy provádí kontrolu RPF, o které si povíme za chvíli.
Kromě kontroly RPF mohou k zabránění neefektivity fungovat také směrovací protokoly vícesměrového vysílání, jako je PIM. Například směrovač E na obrázku nemusí přijímat dvě kopie každého paketu vícesměrového vysílání (jednu od B, jednu od C).
Směrovací protokol vícesměrového vysílání určuje, která rozhraní mají odesílat kopie (nebo neposílat kopie). Jak naznačuje výše uvedený obrázek, k předávání vícesměrového vysílání dochází podél logických stromů, větvících se cest v síti. Všechny informace o předávání vícesměrového vysílání jsou uloženy ve stavové tabulce vícesměrového vysílání, kterou někteří nazývají směrovací tabulka vícesměrového vysílání. Tyto informace lze zobrazit pomocí velmi užitečného příkazu show ip mroute. Podívejme se krátce na ukázkový výstup příkazu show ip mroute (se spuštěným hustým režimem PIM):
Router# show ip mroute 233.1.1.1IP Multicast Routing TableFlags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit setTimers: Uptime/ExpiresInterface state: Interface, Next-Hop, State/Mode(*, 233.1.1.1), uptime 0:57:31, expires 0:02:59, RP is 0.0.0.0, flags: DC Incoming interface: Null, RPF neighbor 0.0.0.0 Outgoing interface list: Ethernet0, Forward/Dense, 0:57:31/0:02:52 FastEthernet1, Forward/Dense, 0:56:55/0:01:28 FastEthernet2, Forward/Dense, 0:56:45/0:01:22(172.16.16.1/32, 233.1.1.1), uptime 20:20:00, expires 0:02:55, flags: C Incoming interface: FastEthernet1, RPF neighbor 10.20.30.1 Outgoing interface list: Ethernet0, Forward/Dense, 20:20:00/0:02:52
Pro pochopení si všimněte, že adresy začínající 224-239 jsou adresy nebo skupiny vícesměrového vysílání IP. (Skupina označuje skupinu příjemců pro danou cílovou adresu vícesměrového vysílání).
Záznam začínající (*, 233.1.1.1) je záznam sdíleného stromu vícesměrového vysílání, někdy označovaný jako (*, G). (G je zde právě 223.1.1.1). PIM-DM je nepoužívá pro předávání paketů, ale pod takovými záznamy uvádí rozhraní s rolí v multicastu (známý přijímač IGMP nebo soused PIM) jako odchozí rozhraní.
Záznam začínající (172.16.16.1, 233.1.1.1) se označuje jako záznam (S, G). S je zdroj, G je skupina. Pokud chcete, představte si to jako zdroj a cíl v hlavičce IP (protože tam se skutečně objevují v paketech). Tato položka je stromem vícesměrového vysílání specifickým pro zdroj pro konkrétní skupinu vícesměrového vysílání. Pro každý zdroj a skupinu bude zpravidla existovat jeden takový záznam. Všimněte si, že další skok směrování jednosměrového vysílání se zobrazuje jako soused RPF a příchozí rozhraní je rozhraní RPF, tedy rozhraní používané směrováním jednosměrového vysílání směrem ke zdroji 172.16.16.1. Seznam odchozích rozhraní ukazuje, že každý paket od 172.16.16.1 s cílem 233.1.1.1 přijatý na FastEthernet1 bude zkopírován ven Ethernet0.
Pro účely řešení problémů můžete nakreslit strom předávání vícesměrového vysílání pro konkrétní (S, G). Za tímto účelem spusťte na každém směrovači příkaz show ip mroute. Vezměte si kopii mapy sítě a nakreslete šipku směrem ven pro každé rozhraní v seznamu odchozích rozhraní („OIL“ nebo „OILIST“). Nakonec získáte diagram, který se bude trochu podobat výše uvedenému obrázku.
Příznaky stavu, které můžete vidět ve výstupu příkazu PIM-DM show ip mroute:
- D = Dense Mode (hustý režim). Zobrazuje se pouze u položek (*, G). Skupina pracuje v hustém režimu.
- C = Přímo připojený hostitel (IGMP!)
- L = Místní (směrovač je nakonfigurován jako člen skupiny vícesměrového vysílání).
- P = Prořezaný (všechna rozhraní OILIST nastavena na prořezávání). Směrovač zpravidla posílá Prune svému RPF sousedovi, když k tomu dojde.
- T = Forwarding via Shortest Path Tree (SPT), označuje alespoň jeden přijatý / předaný paket.
- J = Join SPT. Vždy zapnuto v položce (*,G) v PIM-DM, neznamená mnoho.
Co je to kontrola RPF a proč?
Předávání multicastu IP vždy provádí kontrolu RPF. RPF je zkratka pro Reverse Path Forwarding (zpětné předávání cest). Cílem kontroly RPF je pokusit se jednoduchým způsobem zabránit smyčce předávání paketů multicast. U každého proudu vícesměrového vysílání směrovač vícesměrového vysílání zkontroluje zdrojovou adresu, tedy jaké zařízení vícesměrové vysílání odeslalo. Poté vyhledá odesílatele ve směrovací tabulce vícesměrového vysílání a určí rozhraní, které by použil k odeslání paketů vícesměrového vysílání ke zdroji. Toto rozhraní je rozhraní RPF, tedy rozhraní, na kterém směrovač „očekává“ příjem multicastu. Představte si ho jako „oficiálně schválené“ rozhraní pro příjem multicastů z daného zdroje. Směrovač ukládá rozhraní RPF jako součást informací o stavu vícesměrového vysílání pro daný zdroj a daný cíl (skupinu) vícesměrového vysílání.
Pokud směrovač přijme paket vícesměrového vysílání, sleduje, přes které rozhraní paket přišel. Pokud je paket prvním paketem od nového zdroje, určí se rozhraní RPF a uloží se do tabulky mroute, jak bylo právě popsáno. V opačném případě směrovač vyhledá zdroj a skupinu vícesměrového vysílání v tabulce mroute. Pokud byl paket přijat na rozhraní RPF, je paket zkopírován a předán na každé odchozí rozhraní uvedené v tabulce mroute. Pokud byl paket přijat na rozhraní mimo RPF, je zahozen. Kdyby byl směrovač osobou, jednalo by se o ekvivalent otázky: „Proč mi to ten člověk posílá? Musí být zmatený, budu ignorovat to, co mi právě poslal.“
Směrovač také neposílá kopii paketu zpět přes rozhraní, přes které přišel (rozhraní RPF). Jinými slovy, i kdyby sousední směrovač na rozhraní RPF nějakým způsobem požádal o zaslání kopií vícesměrového toku, směrovač nepřidá rozhraní RPF do seznamu odchozích rozhraní, která přijímají kopie vícesměrového toku. To chrání před jakoukoli chybou protokolu, která by dva sousedy dostala do těsné smyčky předávání vícesměrového vysílání.
Směrovač E také pravděpodobně ignoruje jeden ze dvou proudů paketů podle toho, zda je k rozhraní RPF připojen B nebo C. I u tras se stejnými náklady je obvykle jako rozhraní RPF vybráno právě jedno rozhraní. Pokud tedy máte dvě linky spojující dva směrovače, pro vícesměrové vysílání z jedné zdrojové podsítě bude obvykle použito pouze jedno z nich.
Však viz příkaz ip multicast multipath (novinka ve verzi Cisco IOS 12.0(8) T, 12.0(5) S). Při správném použití tohoto příkazu může dojít k rozložení zátěže pro různé zdroje pro určitou skupinu vícesměrového vysílání. Vzhledem k tomu, že se jedná o rozdělení zátěže na zdroje, a nikoli na proudy, jedná se ve skutečnosti spíše o rozdělení zátěže. Nakonec to nemusí být příliš vyvážené.
Vyvážení zátěže pro jeden proud paketů (jeden zdroj a skupina) přes dvě linky mezi dvěma směrovači lze také provést pomocí tunelů GRE mezi rozhraními loopback, i když bych se možná obával výkonnostních důsledků tohoto postupu u toku s velkou šířkou pásma.
Mimochodem, toto nám také říká, jak směrovat IP multicast přes linky podle našeho výběru. Řízením kontroly RPF řídíme, kam bude multicastový provoz směřovat. Pokud se směrovač nenaučí trasy zpět ke zdroji multicastu na nějakém rozhraní, pak toto rozhraní nebude rozhraním RPF. Pomocí vektorových protokolů vzdálenosti a „route starvation“ (neinzerování trasy sousedovi) tedy můžeme multicast řídit nebo usměrňovat.
Později uvidíme, že všechny štěpy nebo připojení PIM jsou posílány přes rozhraní RPF zpět ke zdroji (nebo RP, v režimu PIM Sparse Mode). Tím, že řídíme, kde tato činnost probíhá, řídíme, po kterých linkách je multicast předáván. Statické záznamy mroute (statické trasy zpět ke zdroji pro účely kontroly RPF multicastu) jsou dalším způsobem směrování provozu multicastu. Pokud / až budeme hovořit o protokolu MBGP pro vícesměrové vysílání (Multiprotocol BGP for Multicast), uvidíme, že protokol MBGP nám také poskytuje způsob, jak směrovat nebo řídit spoje používané provozem vícesměrového vysílání. Všimněte si také, že pokud rozhraní RPF nemá povolený IP multicast, pak ve skutečnosti směrovač očekává pakety tam, kde je nedostane. Rozhraní RPF by mělo být vždy takové, kde je povolen IP multicast.
PIM Dense Mode – Overview
Protocol Independent Multicast má dva režimy, Dense Mode a Sparse Mode. V tomto článku je prostor věnovat se pouze prvnímu z nich. K PIM-SM se dostaneme v příštím článku.
PIM Dense Mode (PIM-DM) používá poměrně jednoduchý přístup ke zpracování směrování vícesměrového vysílání IP. Základním předpokladem PIM-DM je, že proud paketů multicast má příjemce na většině míst. Příkladem může být firemní prezentace generálního ředitele nebo prezidenta společnosti. Naproti tomu režim PIM Sparse Mode (PIM-SM) předpokládá relativně méně příjemců. Příkladem může být úvodní instruktážní video pro nové zaměstnance.
Tento rozdíl se projevuje v počátečním chování a mechanismech obou protokolů. PIM-SM odesílá multicasty pouze tehdy, když je o to požádán. Zatímco PIM-DM začíná zahlcením multicastovým provozem a poté jej zastaví na každém spoji, kde není potřeba, pomocí zprávy Prune. Zprávu Prune si představuji tak, že jeden směrovač říká druhému: „Tady ten multicast právě teď nepotřebujeme.“
Ve starších verzích systému Cisco IOS PIM-DM zaplavoval veškerý multicastový provoz každé 3 minuty. To je v pořádku pro nízký objem vícesměrového vysílání, ale ne pro datové toky vícesměrového vysílání s větší šířkou pásma. Novější verze systému Cisco IOS podporují od verze 12.1(5)T novou funkci nazvanou PIM Dense Mode State Refresh. Tato funkce používá zprávy o obnovení stavu PIM k obnovení stavu Prune na odchozích rozhraních. Další výhodou je rychlejší rozpoznání změn topologie. Ve výchozím nastavení jsou zprávy o obnovení stavu PIM odesílány každých 60 sekund.
Podívejte se na směrovače E a F na obrázku výše. Když se dva směrovače PIM-DM připojí k síti LAN, uvidí pakety vícesměrového vysílání jeden od druhého. Jeden z nich by měl pakety do sítě LAN předávat a druhý ne. Oba posílají zprávy Assert. Vyhrává nejlepší směrovací metrika, přičemž rozhoduje vyšší IP adresa. Pokud používají různé směrovací protokoly, rozhoduje o tom, který směrovač má být předávačem (předává pakety multicastu do sítě LAN), vážené schéma směrovací metriky, trochu podobné administrativní vzdálenosti. Forwarder může být umlčen pomocí Prune z následného směrovače bez přijímačů, pokud v segmentu LAN nejsou také žádní přijímači. Navazující směrovače mohou být nuceny upravit svého souseda RPF tak, aby odrážel vítěze procesu Assert.
Zopakujme si to úplně podrobně: Když je multicastový provoz přijat na rozhraní bez RPF, je odeslána zpráva Prune, pokud je rozhraní point-to-point. Tyto zprávy Prune mají omezenou rychlost, aby jejich objem (potenciálně jedna na každý přijatý multicast) nezpůsobil další problémy.
Pokud je rozhraní non-RPF LAN, je odeslána zpráva Assert. Směrovače, které nejsou směrovači, pak na svém rozhraní RPF odešlou zprávu Prune, pokud proud vícesměrového vysílání nepotřebují. Je odesláno pouze jedno takové Prune, a to v okamžiku přechodu na to, že v seznamu odchozích rozhraní (OILIST) nejsou žádná rozhraní. Příjemce Prune pro LAN odloží svou akci o 3 sekundy, takže pokud jiný směrovač LAN stále potřebuje multicastový tok, může odeslat zprávu PIM Join, aby Prune vyvrátil (zrušil). („Hej, tenhle směrovač to nepotřebuje, ale já ještě ano!“)
Předpokládejme, že směrovač provedl Pruned a o nějaký čas později si přijímač vyžádá multicastový tok zprávou IGMP. Směrovač poté odešle zprávu Graft. V podstatě říká: „Hej, teď potřebuji ten multicastový tok sem.“
Následující obrázek to ilustruje, pravda, v poněkud komprimované podobě.
Vysvětlení obrázku:
(1), možná si směrovač E vybere B jako svého souseda RPF na základě unicastového směrování zpět ke zdroji. Pak E přijme paket multicastu na rozhraní bod-bod od C. Pošle C paket Prune s omezenou rychlostí.
(2), směrovače E a F v LAN si vymění pakety Assert, když E nebo F vidí multicast předaný druhým z nich. Předpokládejme, že E vyhrává na základě metriky nebo adresy směrování unicast. Pak F ví, že nemá předávat multicasty v síti LAN. Všimněte si, že se to netýká G a H, protože Ethernet je jejich rozhraní RPF.
(3) Předpokládejme, že směrovač G nemá žádné přijímače za sebou. Může tedy poslat zprávu LAN Prune forwarderu pro LAN, směrovači E.
(4), pokud má směrovač H místní nebo navazující přijímače, kontruje zprávou LAN Join.
(5), předpokládejme, že směrovač D nemá navazující nebo místní přijímače a poslal zprávu Prune směrovači B. Předpokládejme, že někdy později mu jeden z počítačů napravo od něj pošle zprávu IGMP pro stejnou skupinu multicast. Směrovač D pak může poslat B zprávu PIM Graft a požádat B, aby mu znovu posílal určenou skupinu vícesměrového vysílání.
Protokol PIM a typy paketů
PIM je úplný směrovací protokol s různými druhy zpráv. Nehodlám o různých zprávách drolit a rozepisovat se o nich. Myslím si však, že stojí za to se na něj krátce podívat, protože nám něco málo o protokolu říká.
PIM používá zprávy Hello k objevování sousedů a vytváření adjacencí. Zpráva Hello je každých 30 sekund odesílána na místní multicastovou adresu All-PIM-Routers, 224.0.0.13 (PIMv1 používá AllRouters, 224.0.0.2). Každá síť LAN má určený směrovač (PIM Designated Router, DR), který se používá v režimu PIM Sparse Mode. Je to také IGMPv1 Querier: nejvyšší IP adresa v LAN. Příkaz show ip pim neighbor zobrazuje sousedy a informace o přiléhavosti a časovači.
Vysvětlení přidáno 12.11.2004: IGMP querier a Designated Router jsou dvě role, o které se jedná. Viz zde.
V IGMP verze 1 „DR je zodpovědný za následující úlohy:
- Vysílání zpráv PIM register a PIM join a prune směrem k RP, aby ho informoval o členství ve skupině hostitelů.
- Vysílání zpráv IGMP host-query.“
V IGMP verze 2 jsou odděleny. Kverulant IGMP je volen podle nejnižšího IP v síti LAN. PIM vybírá DR podle nejvyšší IP v síti LAN, aby předával multicasty do sítě LAN. (Tím se odlehčí práce).
PIM má také zprávu Join/Prune, která se používá, jak je popsáno výše. Existují také zprávy Graft a Graft ACK, což nám říká, že Graft probíhá spolehlivě (na rozdíl od reálného světa?).
A existuje zpráva PIM Assert.
PIM-SM má další 3 typy zpráv:
Konfigurace PIM Dense Mode
Konfigurace PIM-DM je ve srovnání se všemi výše uvedenými zprávami vyloženě jednoduchá.
Globálně povolte směrování vícesměrového vysílání příkazem:
ip multicast-routing
Poté na každém rozhraní, které se má účastnit vícesměrového vysílání, povolte IP multicast a PIM příkazem interface:
interface …
ip pim dense-mode
Ve skutečnosti je lepší nastavit režim sparse-dense:
interface …
ip pim sparse-dense-mode
Důvodem je, že to umožňuje jednoduše migrovat některé nebo všechny skupiny vícesměrového vysílání do řídkého režimu tím, že směrovač informuje o bodu setkání. A můžete to udělat i bez překonfigurování mnoha směrovačů nebo rozhraní směrovačů.
Můžete nakonfigurovat stub sítě pro jednoduché vícesměrové vysílání IP. Jde o to, abyste pro jednoduchost nespustili PIM na stub části sítě, jako jsou malé vzdálené lokality. To je zvláště dobrý nápad u směrovačů, které nejsou pod vaší kontrolou: nechcete, aby sdílely směrování vícesměrového vysílání s vašimi směrovači. Eliminuje to také zaplavování takových směrovačů protokolem PIM-DM (u starších verzí systému Cisco IOS).
Chcete-li nakonfigurovat stub multicast, nakonfigurujte
ip igmp helper-address a.b.c.d
na všech rozhraních LAN stub směrovače s potenciálními příjemci multicastu. Adresa a.b.c.d je adresa centrálního směrovače mluvícího PIM. Na centrálním směrovači nakonfigurujete filtr, který odladí všechny zprávy PIM, které by mohl posílat sousední směrovač se stubem, pomocí:
ip pim neighbor-filter access-list
Podívejte se také na příručku příkazů na adrese URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm .
Existuje několik příkazů show, které pomáhají řešit problémy s vícesměrovým vysíláním IP. Ty, které mám nejraději:
- show ip mroute
- show ip pim interface
- show ip pim neighbor
- show ip rpf
Protože je místa málo, odkážu vás pro příklady na Příručku příkazů.
Jedna poznámka k řešení problémů: pokud máte v síti vícesměrové vysílání s velkou šířkou pásma, ujistěte se, že v novějších verzích systému Cisco IOS používáte funkci Prune State Refresh, pokud používáte režim sparse-dense. Obávám se, že směrovače „zapomenou“, že mají RP, a vrátí se do hustého režimu s periodickým zaplavováním. Může se jednat o vzácný náhodný výskyt, ale může vám to opravdu zkazit ráno! Možná budete chtít zvážit také techniky robustnosti RP, což je téma pro náš pozdější článek o PIM-SM nebo Rendezvous Point.
Závěr
Doporučená kniha pro mnoho témat multicastu: Vývoj sítí IP Multicast:
Další mimořádně dobrý odkaz na Cisco multicast naleznete zde.
Další článek: Škálování pomocí PIM Sparse Mode.