Protokol PIM je soubor protokolů pro přenos multicastu v síti mezi směrovači. Vztahy sousedství se vytvářejí podobně jako v případě dynamických směrovacích protokolů. PIMv2 posílá každých 30 sekund zprávy Hello na rezervovanou multicastovou adresu 224.0.0.13 (All-PIM-Routers). Zpráva obsahuje Hold Timers — obvykle roven 3.5 * Hello Timer, tedy 105 sekund ve výchozím nastavení.
PIM používá dva hlavní režimy práce — Dense a Sparse mode. Začněme s režimem Dense.
Stromy distribuce na základě zdroje.
Režim Dense mode je vhodné použít v případě velkého počtu klientů různých multicastových skupin. Když směrovač obdrží multicastový provoz, nejprve kontroluje jeho pravidlo RPF. RPF — toto pravidlo se používá ke kontrole zdroje multicastu s tabulkou směrování unicast. Je nutné, aby provoz přicházel na ten interface, za kterým se skrývá daný host podle tabulky směrování unicast. Tento mechanismus řeší problém vzniku smyčky při přenosu multicastu.
R3 z multicastové zprávy zjistí zdroj multicastu (Source IP) a zkontroluje dva proudy od R1 a R2 podle své tabulky unicast. Proud z toho interface, na který ukazuje tabulka (R1 k R3), bude předán dále, zatímco proud od R2 bude zamítnut, protože pro dosažení zdroje multicastu je nutné posílat pakety přes S0/1.
Co se stane, pokud máte dva ekvivalentní směry s identickou metrikou? V tomto případě směrovač vybere podle next-hop těchto směrů. Který má vyšší IP adresu, ten vyhrál. Pokud je potřeba změnit toto chování, lze použít ECMP. Více informací zde. .
Po kontrole pravidla RPF směrovač posílá multicastový paket všem svým PIM sousedům, kromě toho, od kterého byl tento paket přijat. Ostatní PIM směrovače opakují tento proces. Cesta, kterou multicastový paket prošel od zdroje k konečným příjemcům, tvoří strom, který se nazývá — source-based distribution tree, shortest-path tree (SPT), source tree. Tři různé názvy, vyberte si jakýkoliv.
Jak vyřešit problém s tím, že některé směrovače nezpracovaly nějaký multicastový proud a nikdo ho neposílá, a přesto jejich nadřízený směrovač ho posílá. Pro to byl vymyšlen mechanismus Prune.
Prune Message.
Například R2 bude nadále posílat R3 multicast, ačkoliv R3 podle pravidla RPF jej zavrhuje. Proč zatěžovat kanál? R3 posílá PIM Prune zprávu a R2, po obdržení této zprávy, odstraní rozhraní S0/1 ze seznamu (outgoing interface list) pro tento tok, seznam rozhraní, ze kterých je třeba tento provoz posílat.
Následuje formálnější definice zprávy PIM Prune:
Zpráva PIM Prune je odesílána jedním routerem druhému routeru, aby druhý router odstranil spojení, na kterém je Prune přijato, z konkrétního (S,G) SPT.
Po obdržení zprávy Prune nastaví R2 Prune časovač na 3 minuty. Po třech minutách začne opět posílat provoz, dokud neobdrží další zprávu Prune. To platí pro PIMv1.
A v PIMv2 byl přidán časovač State Refresh (ve výchozím nastavení 60 sekund). Jakmile byla odeslána zpráva Prune z R3, spustí se tento časovač na R3. Po uplynutí tohoto časovače R3 odešle zprávu State Refresh, která resetuje 3-minutový Prune timer na R2 pro tuto skupinu.
Důvody pro odeslání zprávy Prune:
- Když multicastový paket neprošel kontrolou RPF.
- Když nejsou místně připojeni klienti, kteří by požádali o multicastovou skupinu (IGMP Join), a nejsou PIM sousedé, kterým by bylo možné posílat multicastový provoz (Non-prune Interface).
Graft Message.
Představme si, že R3 nechtěl provoz od R2, odeslal Prune a přijímal multicast od R1. Ale najednou, došlo k výpadku kanálu mezi R1-R3 a R3 zůstal bez multicastu. Můžeme čekat 3 minuty, než na R2 vyprší Prune Timer. Čekání 3 minuty je dlouhé, abychom nečekali, je třeba poslat zprávu, která okamžitě vyvede toto rozhraní S0/1 na R2 ze stavu pruned. Takovou zprávou bude Graft zpráva. Po obdržení zprávy Graft odešle R2 v odpovědi Graft-ACK.
Prune Override.
Podívejme se na tuto schéma. R1 vysílá multicast do segmentu se dvěma routery. R3 přijímá a vysílá provoz, R2 přijímá, ale nemá koho obsluhovat. Posílá zprávu Prune k R1 do tohoto segmentu. R1 by měl odstranit Fa0/0 ze seznamu a přestat vysílat do tohoto segmentu, ale co se stane s R3? R3 je ve stejném segmentu a také obdržel zprávu Prune a pochopil tragédii situace. Před tím, než R1 přestane vysílat, nastaví časovač na 3 sekundy a přestane vysílat za 3 sekundy. 3 sekundy — právě tolik času má R3, aby neztratil svůj multicast. Proto R3 co nejdříve posílá zprávu Pim Join pro tuto skupinu a R1 už nepřemýšlí o tom, že by přestal vysílat. O zprávách Join níže.
Assert zpráva.
Představme si situaci: do jedné sítě vysílají dva routery. Dostávají stejný tok od zdroje a oba ho vysílají do jedné sítě za rozhraním e0. Musí tedy zjistit, kdo bude jediným vysílatelem pro tuto síť. K tomu slouží zprávy Assert. Když R2 a R3 detekují duplikaci multicastového provozu, tedy na R2 a R3 přichází multicast, který sami vysílají, routery chápou, že něco není v pořádku. V tomto případě routery posílají zprávy Assert, které obsahují Administrative Distance a metriky trasy, pomocí které se dosahuje zdroje multicastu — 10.1.1.10. Vítěz je určen takto:
- Ten, kdo má nižší AD.
- Pokud jsou AD stejné, pak ten, kdo má nižší metriku.
- Pokud je i zde rovnost, tak ten, kdo má vyšší IP v síti, do které vysílají tento multicast.
Vítěz této volby se stává Designated Routerem. Pro výběr DR se také používají Pim Hello. Na začátku článku bylo ukázáno zprávu PIM Hello, kde je vidět pole DR. Vítězí ten, kdo má vyšší IP adresy na tomto odkazu.
Užitečná tabulka:
MROUTE Tabulka.
Po počátečním přezkoumání fungování protokolu PIM je třeba se zaměřit na to, jak pracovat s multicastovou směrovací tabulkou. V tabulce mroute je uložená informace o tom, které toky byly požadovány ze strany klientů a které toky proudí z multicastových serverů.
Například, při obdržení IGMP Membership Report nebo PIM Join na nějakém rozhraní se do směrovací tabulky přidává záznam typu (*, G):
Tento záznam znamená, že byla přijata žádost o provoz z adresy 238.38.38.38. Příznak DC znamená, že multicast bude fungovat v režimu Dense mode a C znamená, že příjemce je přímo připojen k routeru, což znamená, že router obdržel IGMP Membership Report a PIM Join.
Pokud existuje záznam typu (S,G), znamená to, že máme multicast stream:
V poli S — 192.168.1.11, máme uvedenou IP adresu zdroje multicastu, právě ta bude zkontrolována pravidlem RPF. V případě problémů je nutné nejprve zkontrolovat unicastovou tabulku na trasu k zdroji. V poli Incoming Interface se uvádí rozhraní, na které přichází multicast. V unicastové tabulce směrování by měla trasa k zdroji odkazovat na rozhraní uvedené zde. V Outgoing Interface se uvádí, kam bude multicast přesměrován. Pokud je prázdné, znamená to, že k routeru nebyly přijaty žádosti o tento provoz. Podrobnější informace o všech příznacích lze najít .
PIM Sparse-mode.
Strategie Sparse-mode je opakem Dense-mode. Když Sparse-mode přijme multicastový provoz, bude odesílat provoz pouze přes ta rozhraní, kde byly žádosti o tento stream, například Pim Join nebo zprávy IGMP Report s žádostí o tento provoz.
Podobné prvky mezi SM a DM:
- Vztahy sousedství se budují stejně jako v PIM DM.
- Pravidlo RPF funguje.
- Volba DR je podobná.
- Mechanismus Prune Overrides a zprávy Assert jsou analogické.
Pro kontrolu toho, komu, kde a jaký multicastový provoz je v síti potřeba, je nezbytný společný informační středisko. Tento středisko bude naším Rendezvous Point (RP). Všichni, kdo chtějí nějaký multicastový provoz nebo někdo začal přijímat multicastový provoz od zdroje, jej posílá na RP.
Když RP obdrží multicastový provoz, odešle jej těm routerům, které o tento provoz předtím žádaly.
Představme si takovou topologii, kde RP je R3. Jakmile R1 obdrží provoz od S1, inkapsuluje tento multicastový paket do unicastového PIM Register zprávy a odešle jej na RP. Odkud ví, kdo je RP? V tomto případě je nastaven staticky, o dynamickém nastavení RP si povíme později.
ip pim rp-address 3.3.3.3
RP zkontroluje, zda byla informace od někoho, kdo měl zájem o příjem této komunikace. Předpokládejme, že nebyla. Pak RP odešle R1 zprávu PIM Register-Stop, což znamená, že nikdo o tento multicast nemá zájem, registrace byla zamítnuta. R1 nepošle multicast. Ale hostitel multicastu jej bude stále posílat, takže po obdržení Register-Stop R1 spustí časovač Register-Suppression timer nastavený na 60 sekund. 5 sekund před vypršením tohoto časovače zašle R1 prázdnou Register zprávu s Null-Register bitem (tj. bez zabaleného multicast paketu) směrem k RP. RP na to bude reagovat takto:
- Pokud příjemci jak nebyli, tak nejsou, odpoví na to zprávou Register-Stop.
- Pokud se příjemci objevili, na toto nijak nezareaguje. R1, pokud během 5 sekund neobdrží zamítnutí své registrace, se potěší a odešle zprávu Register se zabaleným multicastem k RP.
Jak jsme si vyjasnili, jak multicast dochází k RP, nyní se pokusíme odpovědět na otázku, jak RP přivádí přenos k příjemcům. Zde je třeba zavést nový pojem — root-path tree (RPT). RPT je strom s kořenem v RP, který roste směrem k příjemcům a větví se na každém PIM-SM routeru. RP jej vytváří, když přijímá PIM Join zprávy, a přidává do stromu novou větev. A tak pokračuje každý nižší router. Obecné pravidlo zní:
- Když PIM-SM router obdrží PIM Join zprávu na jakémkoli rozhraní, kromě rozhraní, za kterým se skrývá RP, přidá do stromu novou větev.
- Větev je také přidána, když PIM-SM router obdrží IGMP Membership Report od přímo připojeného hostitele.
Představme si, že máme klienta multicastu na routeru R5 na skupině 228.8.8.8. Jakmile R5 obdrží IGMP Membership Report od hostitele, R5 odešle PIM Join směrem k RP a sama přidá do stromu rozhraní směřující k hostiteli. Dále R4 obdrží PIM Join od R5, přidá do stromu rozhraní Gi0/1 a odešle PIM Join směrem k RP. Nakonec RP (R3) obdrží PIM Join a přidá Gi0/0 do stromu. Takto se zaregistruje příjemce multicastu. Vytvoříme strom s kořenem R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Po této fázi bude odeslán PIM Join k R1 a R1 začne posílat multicastový provoz. Je důležité si povšimnout, že pokud host požádal o provoz, než začalo vysílání multicastu, RP nebude odesílat PIM Join a vlastně nebude nic posílat k R1.
Pokud se náhodou během odesílání multicastu host rozhodne, že ho už nechce přijímat, jakmile RP obdrží PIM Prune na rozhraní Gi0/0, okamžitě odešle PIM Register-Stop přímo na R1 a poté PIM Prune zprávu přes rozhraní Gi0/1. PIM Register-Stop je odesílán unicastem na tu adresu, ze které přišel PIM Register.
Jak jsme zmínili dříve, jakmile router odešle PIM Join jinému, například R5 na R4, na R4 se přidá záznam:
A spustí se časovač, který resetuje tento časovač, R5 musí nepřetržitě posílat PIM Join zprávy, jinak R4 vyloučí z outgoing list. R5 bude posílat každých 60 PIM Join zprávy.
Přepnutí Shortest-Path Tree.
Přidáme rozhraní mezi R1 a R5 a podíváme se, jak bude proudit provoz při takové topologii.
Předpokládejme, že provoz byl odesílán a přijímán podle starého schématu R1-R2-R3-R4-R5 a teď jsme připojili a nastavili rozhraní mezi R1 a R5.
Nejprve se nám obnoví unicastová tabulka směrování na R5 a nyní je síť 192.168.1.0/24 dosažena přes rozhraní R5 Gi0/2. Nyní, když R5 přijímá multicast na rozhraní Gi0/1, si uvědomuje, že pravidlo RPF není splněno a multicast by měl být logičtější přijímat na Gi0/2. Měl by se odpojit od RPT a postavit kratší strom, který se nazývá Shortest-Path Tree (SPT). K tomu posílá přes Gi0/2 PIM Join na R1 a R1 začne posílat multicast také přes Gi0/2. Nyní se musí R5 odhlásit z RPT, aby nedostával dvě kopie. K tomu posílá zprávu Prune, uvádějící IP adresu zdroje a vkládá speciální bit — RPT-bit. To znamená, že mi nemusíte posílat provoz, mám tady strom lepší. RP také posílá směrem k R1 zprávy PIM Prune, ale neposílá zprávu Register-Stop. Ještě jedna zvláštnost: R5 nyní bude neustále posílat PIM Prune na RP, protože R1 pokračuje v odesílání PIM Register na RP každou minutu. RP zatím nebude mít nové zájemce o tento provoz, a tak mu bude odpovídat odmítnutím. R5 informuje RP, že stále přijímá multicast přes SPT.
Dynamické hledání RP.
Auto-RP.
Tato technologie je proprietární od Cisco a není zvlášť populární, ale stále existuje. Práce Auto-RP se skládá ze dvou základních fází:
1) RP posílá zprávy RP-Announce na vyhrazenou adresu — 224.0.1.39, oznamující se jako RP buď pro všechny, nebo pro určité skupiny. Tato zpráva se posílá každou minutu.
2) Je třeba RP mapping agent, který bude posílat zprávy RP-Discovery s informací, pro jaké skupiny je který RP třeba poslouchat. Právě z této zprávy standardní PIM směrovače zjistí, který RP mají poslouchat. Mapping agent může být buď samotný RP směrovač, nebo jiný nezávislý PIM směrovač. RP-Discovery je odesíláno na adresu 224.0.1.40 s časovačem jedné minuty.
Podívejme se na proces podrobněji:
Nastavíme R3 jako RP:
ip pim send-rp-announce loopback 0 scope 10
R2 jako mapping agent:
ip pim send-rp-discovery loopback 0 scope 10
A na všech ostatních budeme čekat na RP přes Auto-RP:
ip pim autorp listener
Jakmile nastavíme R3, začne posílat RP-Announce:
A R2 po nastavení jako mapping agent začne čekat na zprávy RP-Announce. Pouze když najde alespoň jeden RP, začne posílat RP-Discovery:
Tak tímto způsobem, jakmile standardní směrovače (PIM RP Listener) obdrží tuto zprávu, budou vědět, kde hledat RP.
Jedním z hlavních problémů Auto-RP je, že pro příjem zpráv RP-Announce a RP-Discovery je třeba poslat PIM Join na adresy 224.0.1.39-40, a aby bylo možné poslat, je nutné vědět, kde se RP nachází. Klasický problém slepice a vejce. Pro řešení tohoto problému byl vymyšlen režim PIM Sparse-Dense-Mode. Pokud směrovač nezná RP, pracuje v režimu Dense-mode, pokud ví, pak v režimu Sparse-mode. Když jsou na rozhraních standardních směrovačů nastaveny PIM Sparse-mode a příkaz ip pim autorp listener, směrovač bude pracovat v režimu Dense-mode pouze pro multicast Auto-RP protokolu (224.0.1.39-40).
BootStrap Router (BSR).
Tato funkce funguje podobně jako Auto-RP. Každý RP posílá zprávu mapping agentovi, který shromažďuje mappingové informace a poté je sděluje všem ostatním směrovačům. Popišme proces obdobně jako u Auto-RP:
1) Jakmile nastavíme R3 jako kandidáta na RP, příkazem:
ip pim rp-candidate loopback 0
Pak R3 nic nedělá, aby začal posílat speciální zprávy, musí nejprve najít mapping agenta. Přecházíme proto k druhému kroku.
2) Nastavujeme R2 jako mapping agent:
ip pim bsr-candidate loopback 0
R2 začíná vysílat PIM Bootstrap zprávy, ve kterých se označuje jako mapping agent:
Tato zpráva je posílána na adresu 224.0.0.13, kterou protokol PIM používá i pro další své zprávy. Odesílá je do všech směrů, a proto nevzniká problém s kuřetem a vejcem, jak to bylo u Auto-RP.
3) Jakmile RP obdrží zprávu od BSR routeru, okamžitě odešle unicast zprávu na adresu BSR routeru:
Po obdržení informace o RP, BSR je rozešle multicast na adresu 224.0.0.13, kterou poslouchají všechny PIM routery. Proto neexistuje ekvivalent příkazu ip pim autorp listener pro běžné routery v BSR.
Anycast RP s protokolem Multicast Source Discovery (MSDP).
Auto-RP a BSR nám umožňují rozložit zátěž na RP následujícím způsobem: Každá multicast skupina má jen jedno aktivní RP. Není možné rozložit zátěž pro jednu multicast skupinu mezi více RP. MSDP to dělá poskytováním RP routerům stejné ip adresy s maskou 255.255.255.255. MSDP získává informace pomocí jednoho z metod: statiky, Auto-RP nebo BSR.
Na obrázku máme konfiguraci Auto-RP s MSDP. Oba RP jsou nastaveny s ip adresou 172.16.1.1/32 na rozhraní Loopback 1 a používají se pro všechny skupiny. Při RP-Announce oba routery informují o sobě, odkazujíc na tuto adresu. Auto-RP mapping agent, po obdržení informací, vysílá RP-Discovery o RP s adresou 172.16.1.1/32. O síti 172.16.1.1/32 informujeme routery pomocí IGP a tímto způsobem. PIM routery requestují nebo registrují toky od RP, který je uveden jako next-hop v cestě k síti 172.16.1.1/32. Samotný protokol MSDP slouží pro RP, aby si vyměňovaly informace o multicastu.
Podívejme se na takovou topologii:
Switch6 vysílá provoz na adresu 238.38.38.38 a prozatím o něm ví pouze RP-R1. Tady Switch7 a Switch8 požádali o tuto skupinu. Routery R5 a R4 odešlou PIM Join na R1 a R3, respektive. Proč? Cesta k 13.13.13.13 u R5 bude odkazovat na R1 podle metriky IGP, stejně jako u R4.
RP-R1 ví o toku a začne ho vysílat směrem k R5, ale R4 o něm nic neví, protože R1 ho za normálních podmínek nebude posílat. Proto je nezbytný MSDP. Nastavujeme ho na R1 a R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 na R1
ip msdp peer 1.1.1.1 connect-source Loopback3 na R3
Naváží mezi sebou relaci a po obdržení jakéhokoli toku budou informovat svého souseda RP.
RP-R1, jakmile přijme tok od Switch6, okamžitě odešle unicast zprávu MSDP Source-Active, která bude obsahovat informace typu (S, G) — informace o zdroji a cíli multicastu. Nyní, když RP-R3 ví, že existuje takový zdroj jako Switch6, při obdržení žádosti od R4 o tento tok, odešle směrem k Switch6 PIM Join podle směrovací tabulky. Tím pádem R1, který obdrží tento PIM Join, začne směrovat provoz směrem k RP-R3.
MSDP funguje přes TCP, RP si vzájemně posílají keepalive zprávy pro kontrolu životaschopnosti. Časovač je nastaven na 60 sekund.
Funkce rozdělení MSDP peerů do různých domén zůstává nejasná, protože v keepalive a SA zprávách není uvedena příslušnost k jakékoli doméně. V této topologii byla také testována konfigurace s uvedením různých domén — nebyl zaznamenán žádný rozdíl v provozu.
Pokud někdo může objasnit, rád si přečtu v komentářích.
Zdroj: habr.com
