PIM protokola darbības principi

PIM protokols ir protokolu kopums multikasta pārsūtīšanai tīklā starp maršrutētājiem. Kaimiņattiecības tiek veidotas līdzīgi kā dinamiskiem maršrutēšanas protokoliem. PIMv2 katras 30 sekundes sūta Hello ziņojumus uz rezervēto multikasta adresi 224.0.0.13 (All-PIM-Routers). Ziņojums satur Hold Timers - parasti vienāds ar 3.5*Hello Timer, tas ir, 105 sekundes pēc noklusējuma.

PIM izmanto divus galvenos darbības režīmus — Dense un Sparse mode. Sāksim ar Dense mode.
Avota balstītas sadales koki.
Dense-mode režīms ir piemērots lietošanai, ja ir liels klientu skaits dažādās multikasta grupās. Kad maršrutētājs saņem multikasta trafiku, vispirms tas pārbauda to pret RPF noteikumu. RPF — šis noteikums tiek izmantots, lai pārbaudītu multikasta avotu pret unicast maršrutizācijas tabulu. Trafikam ir jāierodas tajā interfeisā, kurā slēpjas šis host saskaņā ar unicast maršrutizācijas tabulu. Šis mehānisms novērš aplamu apļainu sūtīšanu multikastā.

R3 no multikasta ziņojuma uzzina multikasta avotu (Source IP) un pārbauda divus plūsmus no R1 un R2 pēc savas unicast maršrutizācijas tabulas. Plūsma no tā interfeisa, uz kuru norāda tabula (R1 uz R3), tiks nodota tālāk, bet plūsma no R2 tiks noraidīta, jo, lai sasniegtu multikasta avotu, jānosūta paketes pa S0/1.
Jautājums: kas notiek, ja jums ir divi ekvivalentu maršrutu ar vienādu metrikas? Šajā gadījumā maršrutētājs izvēlēsies pēc next-hop attiecībā uz šiem maršrutiem. Kam ir augstāks IP adrese, tas uzvar. Ja nepieciešams mainīt šo uzvedību, var izmantot ECMP. Lasīt vairāk. šeit.
P pēc RPF noteikuma pārbaudes maršrutētājs nosūta multikasta paketi visiem saviem PIM kaimiņiem, izņemot to, no kura tika saņemta šī pakete. Pārējie PIM maršrutētāji atkārto šo procesu. Ceļš, pa kuru multikasta pakete virzījās no avota līdz galīgajiem saņēmējiem, veido koku, kas saucas — avota balstīta sadales koks, īsākā ceļa koks (SPT), avota koks. Trīs dažādi nosaukumi, izvēlieties jebkuru.
Kā risināt jautājumu, kad daži maršrutētāji nesaņem kādu multikasta plūsmu un nevienam to nosūtīt nav, bet augstāks maršrutētājs to sūta? Tam ir izstrādāts Prune mehānisms.
Prune ziņojums.
Piemēram, R2 turpinās sūtīt R3 multicast, lai gan R3 saskaņā ar RPF noteikumu to noraida. Kāpēc slodzes kanāls? R3 nosūta PIM Prune ziņojumu, un R2, saņemot šo ziņojumu, izdzēsīs S0/1 interfeisu no iznākuma interfeisu saraksta attiecīgajam plūsmam, interfeisu sarakstu, no kuriem jānosūta šis saturs.

Šeit ir formālāka PIM Prune ziņojuma definīcija:
PIM Prune ziņojums tiek nosūtīts no viena maršrutētāja uz otro maršrutētāju, lai liktu otrajam maršrutētājam izņemt saiti, uz kuras tiek saņemts Prune, no konkrētā (S,G) SPT.

Pēc Prune ziņojuma saņemšanas R2 iestata Prune taimeri uz 3 minūtēm. Pēc trim minūtēm tas sāks atkal sūtīt satiksmi, līdz saņems nākamo Prune ziņojumu. Tas ir PIMv1.
Savukārt PIMv2 ir pievienots State Refresh taimeris (noklusēti 60 sekundes). Tiklīdz tiek nosūtīts Prune ziņojums no R3, šis taimeris tiek aktivizēts uz R3. Kad šis taimeris beidzas, R3 nosūtīs State Refresh ziņojumu, kas resete 3 minūšu Prune taimeri uz R2 attiecībā uz grupu.
Prunēšanas ziņojuma sūtīšanas iemesli:

• Kad multicast pakete nav izturējusi RPF pārbaudi.
• Ja nav lokāli pieslēgtu klientu, kuri pieprasīja multicast grupu (IGMP Join), un nav PIM kaimiņu, kuriem var sūtīt multicast satiksmi (Non-prune Interface).

Graft ziņojums.
Iedomāsimies, ka R3 nevēlējās saņemt satiksmi no R2, nosūtīja Prune un saņēma multicast no R1. Bet pēkšņi sabruka saite starp R1 un R3, un R3 palika bez multicast. Var gaidīt 3 minūtes, kamēr uz R2 beigsies Prune taimeris. 3 minūtes gaidīšana ir ilga, tāpēc, lai nesagaidītu, ir nepieciešams nosūtīt ziņojumu, kas tūlīt izņems S0/1 interfeisu uz R2 no pruned stāvokļa. Šāds ziņojums būs Graft ziņojums. Pēc Graft ziņojuma saņemšanas R2 atbildēs ar Graft-ACK.
Prune Override.

Apskatīsim šo shēmu. R1 izsūta multicast datu plūsmu segmentā ar diviem maršrutētājiem. R3 saņem un izplata trafiku, bet R2 saņem, taču tam nav, kam izplatīt trafiku. Tas nosūta Prune ziņojumu R1 šajāsegmentā. R1 ir jāiznīcina Fa0/0 no saraksta un jāpārtrauc izplatīšana šajā segmentā, bet kas notiks ar R3? R3 atrodas tajā pašā segmentā, arī saņēma šo Prune ziņojumu un saprata visas situācijas nopietnību. Pirms R1 pārtrauc izplatīšanu, tas iestata taimeri 3 sekundes un pārtrauks izplatīšanu pēc 3 sekundēm. 3 sekundes — tieši tik ilgi R3 nevajadzētu zaudēt savu multicast datu plūsmu. Tādēļ R3, cik drīz vien iespējams, nosūta Pim Join ziņojumu šajā grupā, un R1 vairs nedomā pārtraukt izplatīšanu. Par Join ziņojumiem zemāk.
Assert ziņojums.

Iedomāsimies šādu situāciju: vienā tīklā izplata divi maršrutētāji. Viņi saņem vienu un to pašu plūsmu no avota un abi to izplata vienā tīklā aiz interfeisa e0. Tādēļ viņiem jānosaka, kurš būs vienīgais izplatītājs šim tīklam. Tam tiek izmantoti Assert ziņojumi. Kad R2 un R3 atklāj, ka notiek multicast datu plūsmu dublēšana, proti, R2 un R3 saņem multicast datu plūsmu, kuru paši izplata, maršrutētāji saprot, ka kaut kas nav kārtībā. Šajā gadījumā maršrutētāji nosūta Assert ziņojumus, kuros iekļauta Administratīvā attāluma un maršrutu metrikas informācija, kā sasniegt multicast avotu — 10.1.1.10. Uzvarētājs tiek noteikts tā:

1. Tam, kam ir zemākais AD.
2. Ja AD ir vienādi, tad tam kam ir zemāka metrika.
3. Ja šajā gadījumā arī ir vienādība, tad tam, kam ir augstāks IP adresē tīklā, kurā tie izplata šo multicast datu plūsmu.

Uzvarētājs šajā balsojumā kļūst par Designated Router. DR izvēlēšanai tiek izmantoti arī Pim Hello. Raksta sākumā tika parādīts PIM Hello ziņojums, tur var novērot DR lauku. Uzvar tas, kam ir augstākā IP adrese šajā savienojumā.
Noderīga tabula:

MROUTE Tabula.
Pēc sākotnējās PIM protokola darbības apskates mums ir jāizskata, kā strādāt ar multicast maršrutēšanas tabulu. Mroute tabulā glabājas informācija par to, kuri plūsmas ir pieprasītas no klientiem un kuras plūsmas plūst no multicast serveriem.
Piemēram, saņemot IGMP Membership Report vai PIM Join uz kāda interfeisa, maršrutēšanas tabulā tiek pievienota ieraksts ar tipu ( *, G ):

Šis ieraksts nozīmē, ka ir saņemts pieprasījums par datplūsmu no adreses 238.38.38.38. DC karogs nozīmē, ka multicast darbosies blīvā režīmā, un C nozīmē, ka saņēmējs ir tieši pieslēgts maršrutētājam, t.i., maršrutētājs saņēma IGMP Membership Report, un PIM Join.
Ja ir ieraksts tipa (S,G), tas nozīmē, ka mums ir multicast plūsma:

S laukā — 192.168.1.11, mums ir norādīta multicast avota IP adrese, tieši tā tiks pārbaudīta RPF noteikumā. Problēmu gadījumā vispirms jāpārbauda unikālo tabula saistībā ar avota maršrutu. Ienākošā saskarne norāda interfeisu, caur kuru nāk multicast. Unikālo maršrutu tabulā maršruts uz avotu jānorāda uz interfeisu, kas norādīts šeit. Izvērsto interfeisu norāda, uz kurieni tiks novirzīts multicast. Ja tas ir tukšs, tas nozīmē, ka maršrutētājam nebija pieprasījumu par šo datplūsmu. Sīkāku informāciju par visiem karogiem var atrast. šeit.
PIM Sparse-mode.
Sparse-mode stratēģija ir pretēja blīvajam režīmam. Kad Sparse-mode saņem multicast datplūsmu, tas sūtīs datplūsmu tikai caur tiem interfeisiem, kur ir bijuši pieprasījumi par šo plūsmu, piemēram, PIM Join vai IGMP Report ziņojumi ar pieprasījumu par šo datplūsmu.
Līdzīgi elementi SM un DM:

• Ka neighbors attiecības veidojas tāpat kā PIM DM.
• Darbojas RPF noteikums.
• DR izvēle ir līdzīga.
• Prune Overrides mehānisms un assert ziņojumi ir līdzīgi.

Lai kontrolētu, kam, kur un kāda multicast datplūsma ir nepieciešama tīklā, ir nepieciešams kopīgs informācijas centrs. Šāds centrs būs Rendezvous Point (RP). Visi, kas vēlas kādu multicast datplūsmu vai kas sāk saņemt multicast datplūsmu no avota, to nosūta uz RP.
Kad RP saņems multicast datplūsmu, tas to nosūtīs tiem maršrutētājiem, kuri iepriekš bija pieprasījuši šo datplūsmu.

Iedomāsimies šādu topoloģiju, kur RP ir R3. Tiklīdz R1 saņems datplūsmu no S1, tas iesaiņos šo multicast paketi unikālo PIM Register ziņojumā un nosūtīs to uz RP. No kurienes viņš zina, kurš ir RP? Šajā gadījumā tas ir konfigurēts statiski, bet par dinamikas RP konfigurāciju runāsim vēlāk.

ip pim rp-address 3.3.3.3

RP pārbaudīs, vai ir bijusi informācija no kāda, kas vēlētos saņemt šo trafiku? Pieņemsim, ka nav bijis. Tad RP nosūtīs R1 ziņojumu PIM Register-Stop, kas nozīmē — neviens negrib šo multicast, reģistrācija noraidīta. R1 nesūtīs multicast. Bet host-izcelsmes multicast būs jānosūta, tāpēc R1 pēc Register-Stop saņemšanas uzsāks Register-Suppression timer, kas ir 60 sekundes. 5 sekundes pirms šī taimeris izbeigšanās, R1 nosūtīs tukšu Register ziņojumu ar Null-Register bit (t.i., bez iepakota multicast paketa) uz RP. RP savukārt rīkosies tā:

• Ja saņēmēju nebija, tad tas atbildēs ar Register-Stop ziņojumu.
• Ja saņēmēji ir parādījušies, tad tas uz to nekādi neatbildēs. R1, nesaņemot atteikumu par savu reģistrāciju 5 sekunžu laikā, priecāsies un nosūtīs Register ziņojumu ar iepakotu multicast uz RP.

Kā multicast nonāk līdz RP, šķiet, mēs sapratām, tagad mēģināsim atbildēt uz jautājumu, kā RP nogādā trafiku līdz saņēmējiem. Šeit ir nepieciešams ieviest jaunu jēdzienu — root-path tree (RPT). RPT — tas ir koks ar sakni RP, kas aug virzienā uz saņēmējiem, sazarojoties katrā PIM-SM maršrutētājā. RP to izveido, saņemot PIM Join ziņojumus un pievienojot nozares koks. Un tā dara katrs apakšējais maršrutētājs. Kopējais noteikums izskatās šādi:

• Kad PIM-SM maršrutētājs saņem PIM Join ziņojumu kādā saskarnē, izņemot to saskarni, aiz kuras slēpjas RP, tas pievieno jaunus zaru kokam.
• Arī zars tiek pievienots, kad PIM-SM maršrutētājs saņem IGMP Membership Report no tieši pieslēgta hosta.

Iedomāsimies, ka mums ir multicast klients maršrutētājā R5 grupai 228.8.8.8. Tiklīdz R5 saņems IGMP Membership Report no hosta, R5 nosūtīs PIM Join virzienā uz RP un pats pievienos zaru koks saskarnei, kas skatās uz hostu. Pēc tam R4 saņem PIM Join no R5, pievieno zaru koks saskarnei Gi0/1 un nosūtīs PIM Join virzienā uz RP. Visbeidzot, RP (R3) saņem PIM Join un pievieno Gi0/0 koks. Tādējādi izveidojas saņēmēja multicast reģistrācija. Mums tiek veidots koks ar sakni R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Pēc tam tiks nosūtīts PIM Join uz R1, un R1 sāks sūtīt multicast trafiku. Svarīgi atzīmēt, ka, ja hosts ir pieprasījis trafiku pirms multicast pārraides uzsākšanas, RP nesūtīs PIM Join un vispār nesūtīs neko uz R1.
Ja gadījumā, kamēr notiek multicast nosūtīšana, hosts pārtrauks vēlēties to saņemt, tiklīdz RP saņems PIM Prune interfeisā Gi0/0, tas tūlīt nosūtīs PIM Register-Stop tieši uz R1 un pēc tam PIM Prune ziņojumu caur interfeisu Gi0/1. PIM Register-stop tiek nosūtīts unikastā uz adresi, no kuras tika saņemts PIM Register.
Kā jau iepriekš norādījām, tiklīdz maršrutētājs nosūta PIM Join citam, piemēram, R5 uz R4, tad R4 tiek pievienota ieraksts:

Un tiek uzsākts taimeris, ka R5 šim taimerim pastāvīgi jāsūta PIM Join ziņojumi, citādi R4 izslēgs no outgoing list. R5 sūtīs PIM Join ziņojumus ik pēc 60 sekundēm.
Shortest-Path Tree pārslēgšana.
Mēs pievienosim interfeisu starp R1 un R5, skatīsim, kā plūdīs trafiks šādā topoloģijā.

Pieņemot, ka trafiks tika sūtīts un saņemts pēc vecās shēmas R1-R2-R3-R4-R5, un tagad mēs pieslēdzam un konfigurējam interfeisu starp R1 un R5.
Pirmkārt, mums pārbūvēsies unikasta maršrutēšanas tabula R5, un tagad tīkls 192.168.1.0/24 tiek sasniegts caur interfeisu R5 Gi0/2. Tagad R5 saņemot multicast interfeisā Gi0/1, saprot, ka RPF noteikums netiek apmierināts un būtu loģiskāk saņemt multicast caur Gi0/2. Viņam jāatvienojas no RPT un jāuzbūvē īsāks koks, ko sauc par Shortest-Path Tree (SPT). Tādēļ viņš caur Gi0/2 nosūta PIM Join uz R1, un R1 sāk sūtīt multicast arī caur Gi0/2. Tagad R5 ir jāatvienojas no RPT, lai nesaņemtu divas kopijas. Tādēļ viņš nosūta Prune ziņojumu, norādot avota IP adresi un ievietojot īpašu bitu — RPT-bit. Tas nozīmē, ka man nevajag sūtīt trafiku, man te ir labāks koks. RP arī sūta PIM Prune ziņojumus uz R1, bet nesūta Register-Stop ziņojumu. Vēl viena īpatnība: R5 tagad pastāvīgi sūta PIM Prune uz RP, jo R1 turpina sūtīt PIM Register uz RP katru minūti. RP, līdz nebūs jaunu vēlētāju šī trafika, atbildēs ar atteikumu. R5 informē RP, ka turpina saņemt multicast caur SPT.
Dinamisks RP meklējums.
Auto-RP.
Šī tehnoloģija ir Cisco patentēta un nav īpaši populāra, taču tā joprojām pastāv. Auto-RP darbība sastāv no divām galvenajām stadijām:
1) RP sūta RP-Announce ziņojumus uz rezervēto adresi — 224.0.1.39, paziņojot par sevi kā RP vai nu visām, vai dažām grupām. Šis ziņojums tiek sūtīts katru minūti.
2) Nepieciešams RP mapping agent, kurš sūtīs RP-Discovery ziņojumus ar norādījumu, kurām grupām kurš RP ir jāuzklausa. Tieši no šī ziņojuma parastie PIM maršrutētāji noteiks savu RP. Mapping Agent var būt gan pats RP maršrutētājs, gan kāds atsevišķs PIM maršrutētājs. RP-Discovery tiek sūtīts uz adresi 224.0.1.40 ar taimeri vienā minūtē.
Paskatīsimies procesu sīkāk:
Iestatīsim R3 kā RP:

ip pim send-rp-announce loopback 0 scope 10

R2 kā mapping agent:

ip pim send-rp-discovery loopback 0 scope 10

Un visos pārējos gaidīsim RP caur Auto-RP:

ip pim autorp listener

Tiklīdz mēs iestatīsim R3, tas sāks sūtīt RP-Announce:

Un R2, pēc mapping agent iestatīšanas, sāks gaidīt RP-Announce ziņojumus. Tikai tad, kad tas atradīs vismaz vienu RP, tas sāks sūtīt RP-Discovery:

Tādējādi, tiklīdz parastie maršrutētāji (PIM RP Listener) saņems šo ziņojumu, tie zinās, kur meklēt RP.
Viens no galvenajiem Auto-RP trūkumiem ir tas, ka, lai saņemtu RP-Announce un RP-Discovery ziņojumus, nepieciešams sūtīt PIM Join uz adresēm 224.0.1.39-40, bet lai to sūtītu, jāzina, kur atrodas RP. Klasiskais vistas un olu jautājums. Šai problēmai tika izstrādāts PIM Sparse-Dense-Mode. Ja maršrutētājs nezina RP, tas darbojas Dense-mode režīmā, ja zina, tad Sparse-mode. Kad parasto maršrutētāju saskarnēs ir iestatīts PIM Sparse-mode un komanda ip pim autorp listener, maršrutētājs darbosies Dense-mode tikai multividei tieši Auto-RP protokola ietvaros (224.0.1.39-40).
BootStrap Router (BSR).
Šī funkcija darbojas līdzīgi kā Auto-RP. Katrs RP sūta ziņojumu mapping agent, kurš apkopo mapešanas informāciju un tālāk to ziņo visiem pārējiem maršrutētājiem. Aprakstīsim procesu līdzīgi Auto-RP:
1) Tiklīdz mēs iestatām R3 par kandidātu būt RP, izmantojot komandu:

ip pim rp-candidate loopback 0

Tad R3 neko nedarīs, lai sāktu sūtīt īpašus ziņojumus, tam vispirms jāatrod mapping agent. Tādējādi pārejam uz otro posmu.
2) Iestatām R2 kā mapping agent:

ip pim bsr-candidate loopback 0

R2 sāk izsūtīt PIM Bootstrap ziņojumus, norādot sevi kā mapping agent:

Šis ziņojums tiek nosūtīts uz adresi 224.0.0.13, kuru PIM protokols izmanto arī citās savās ziņojumu nosūtīšanas reizēs. Tas nosūta tos visās pusēs, tāpēc nav vistas un ola problēmas, kā tas bija Auto-RP.
3) Tiklīdz RP saņems ziņojumu no BSR maršrutētāja, tas tūlīt nosūtīs unikālo ziņojumu uz BSR maršrutētāja adresi:

Pēc tam, kad BSR saņems informāciju par RP, tas izplatīs to multicasting uz adresi 224.0.0.13, kuru klausās visi PIM maršrutētāji. Tādējādi nav analoga komandas ip pim autorp listener par parastajiem maršrutētājiem BSR.
Anycast RP ar Multicast Source Discovery Protocol (MSDP).
Auto-RP un BSR ļauj sadalīt slodzi uz RP šādi: katrai multicasting grupai ir tikai viens aktīvs RP. Nav iespējams veidot slodzes sadalījumu vienai multicasting grupai ar vairākiem RP. MSDP to paveic, izsniedzot RP maršrutētājiem vienādu IP adresi ar masku 255.255.255.255. MSDP iegūst informāciju ar vienu no metodēm: statiku, Auto-RP vai BSR.

Attēlā redzam Auto-RP konfigurāciju ar MSDP. Abi RP ir konfigurēti ar IP adresi 172.16.1.1/32 uz Loopback 1 interfeisa un tiek izmantoti visām grupām. Pie RP-Announce abi maršrutētāji stāsta par sevi, atsaucoties uz šo adresi. Auto-RP mapping agent, saņemot informāciju, izsūta RP-Discovery par RP ar adresi 172.16.1.1/32. Par tīklu 172.16.1.1/32 maršrutētājiem mēs stāstām, izmantojot IGP un attiecīgi. Tādējādi PIM maršrutētāji pieprasa vai reģistrē plūsmas no tā RP, kuru ir norādījusi kā next-hop maršrutam uz tīklu 172.16.1.1/32. Pats MSDP protokols ir paredzēts RP, lai apmainītos ar ziņojumiem par informāciju par multicasting.
Apskatīsim šādu topoloģiju:

Switch6 izsūta satiksmi uz adresi 238.38.38.38, un par to pagaidām zina tikai RP-R1. Šeit Switch7 un Switch8 ir pieprasījuši šo grupu. Maršrutētāji R5 un R4 nosūtīs PIM Join uz R1 un R3, attiecīgi. Kāpēc? Maršruts uz 13.13.13.13 R5 norādīs uz R1 ar IGP metrikas palīdzību, tāpat kā R4.
RP-R1 zina par plūsmu un sāks to izsūtīt uz R5, bet R4 par to neko nezina, jo R1 vienkārši to nesūtīs. Tāpēc nepieciešams MSDP. Konfigurējam to uz R1 un R5:

ip msdp peer 3.3.3.3 connect-source Loopback1 uz R1

ip msdp peer 1.1.1.1 connect-source Loopback3 uz R3

Viņi izveidos sesiju starp sevi un, saņemot kādu plūsmu, informēs par to savu RP kaimiņu.
Kad RP-R1 saņems straumi no Switch6, tas nekavējoties nosūtīs MSDP Source-Active ziņojumu, kurā būs informācija par avotu un mērķi (S, G) — informācija par multicast avotu un galamērķi. Tagad, kad RP-R3 zinās, ka tāds avots kā Switch6 eksistē, saņemot pieprasījumu no R4 par šo straumi, tas nosūtīs PIM Join uz Switch6, balstoties uz maršrutēšanas tabulu. Tādējādi, saņemot šo PIM Join, R1 sāks sūtīt satiksmi uz RP-R3.
MSDP darbojas, izmantojot TCP, RP savā starpā sūta keepalive ziņojumus, lai pārbaudītu dzīvotspēju. Taimeris ir 60 sekundes.
Nav skaidra MSDP pušu sadalīšanas funkcija dažādos domēnos, jo Keepalive un SA ziņojumos nav norādīta piederība kādam domēnam. Arī šajā topoloģijā tika testēta konfigurācija ar dažādu domēnu norādījumiem — darba rezultāti neizmainījās.
Ja kāds var sniegt skaidrojumu, labprāt izlasīšu komentāros.

Avots: habr.com