Protokolli PIM është një grup protokollesh për transmetimin e multicast-it në rrjet midis routerave. Marrëdhëniet e fqinjësisë krijohen në mënyrë të ngjashme si në rastin e protokolleve dinamike të routing-ut. PIMv2 dërgon mesazhe Hello çdo 30 sekonda në adresën e multicast-it të rezervuar 224.0.0.13 (All-PIM-Routers). Mesazhi përmban Timers të mbajtjes — zakonisht është 3.5*Hello Timer, që do të thotë 105 sekonda si parazgjedhje.
PIM përdor dy moda kryesore pune — Dense dhe Sparse mode. Le të fillojmë me Dense mode.
Përgjigjet e Distribucionit të Bazuar në Burim.
Modaliteti i Dense-mode është i arsyeshëm për t'u përdorur në rastin e një numri të madh klientësh nga grupe të ndryshme multicast. Kur router-i merr trafik multicast, ai e kontrollon fillimisht atë në rregullin RPF. RPF — ky rregull përdoret për të verifikuar burimin e multicast-it me tabelën e routing-ut unicast. Duhet që trafiku të vijë në atë ndërfaqe, për të cilën ky host është i fshehur sipas tabelës së routing-ut unicast. Ky mekanizëm zgjidh problemin e krijimit të cikleve gjatë transmetimit të multicast-it.
R3 nga mesazhi multicast mëson burimin e multicast-it (Source IP) dhe verifikon dy rrugë nga R1 dhe R2 sipas tabelës së tij unicast. Rruga nga ai ndërfaqe, në të cilën tregon tabela (R1 për në R3), do të kalojë më tej, ndërsa rruga nga R2 do të bllokohet, sepse për të arritur te burimi i multicast-it, duhet të dërgohen paketa përmes S0/1.
Pyetja është, çfarë do të ndodhë nëse keni dy rrugë ekuivalente me metrikë të njëjtë? Në këtë rast, router-i do të zgjedhë sipas next-hop për këto rrugë. Ai me adresën më të lartë IP do të fitojë. Nëse është e nevojshme të ndryshohet kjo sjellje, mund të përdoret ECMP. Lexoni më shumë. .
Pas verifikimit të rregullit RPF, router-i dërgon paketën multicast të gjithë fqinjëve të tij PIM, përveç atij nga i cili është pranuar kjo paketë. Routerat e tjerë PIM përsërisin këtë proces. Rruga që ka ndjekur paketa multicast nga burimi deri te pranuesit përfundimtar, formon një pemë, e cila quhet — source-based distribution tree, shortest-path tree (SPT), source tree. Tri emra të ndryshëm, zgjidhni cilin të doni.
Si të zgjidhni çështjen kur disa routera nuk duan një rrjedhë të caktuar multicast dhe nuk ka askënd për ta dërguar atë, ndërsa një router më i lartë po e dërgon. Për këtë është krijuar mekanizmi Prune.
Mesazhi Prune.
Për shembull, R2 do të vazhdojë të dërgojë multicast në R3, megjithëse R3 sipas rregullit RPF e bllokon atë. Pse të ngarkoni kanalin? R3 dërgon mesazhin PIM Prune dhe R2, pas marrjes së këtij mesazhi, do të heqë ndërfaqen S0/1 nga lista (outgoing interface list) për këtë rrjedhë, lista e ndërfaqeve nga të cilat duhet të dërgohet ky trafik.
Më poshtë është një definicion më formal i një mesazhi PIM Prune:
Mesazhi PIM Prune dërgohet nga një router te një router tjetër për ta bërë router-in e dytë të heqë lidhjen në të cilën është pranuar Prune nga një (S,G) SPT të caktuar.
Pas marrjes së mesazhit Prune, R2 vendos timer-in Prune në 3 minuta. Pas tre minutash ai do të fillojë të dërgojë trafik sërish, deri sa të marrë një mesazh tjetër Prune. Kjo është në PIMv1.
Ndërsa në PIMv2 është shtuar timer-i State Refresh (me parazgjedhje 60 sekonda). Sa herë që është dërguar mesazhi Prune nga R3, ky timer aktivizohet në R3. Pas skadimit të këtij timer-i, R3 do të dërgojë mesazhin State Refresh, i cili do të reshtojë timer-in Prune 3-minutësh në R2 për këtë grup.
Arsyet për dërgimin e mesazhit Prune:
- Kur paketa multicast nuk kalon verifikimin e RPF.
- Kur nuk ka klientë të lidhur lokal, të cilët kanë kërkuar grupin multicast (IGMP Join) dhe nuk ka fqinjë PIM, te të cilët mund të dërgohet trafiku multicast (Non-prune Interface).
Mesazhi Graft.
Imagjinoni që R3 nuk dëshiroi trafik nga R2, dërgoi Prune dhe merrte multicast nga R1. Por papritmas, kanali midis R1 dhe R3 ra dhe R3 mbeti pa multicast. Mund të prisni 3 minuta, derisa timer-i Prune te R2 të skadojë. 3 minuta është shumë gjatë, për të mos pritur, është e nevojshme të dërgohet një mesazh, i cili do ta nxjerrë këtë ndërfaqe S0/1 në R2 nga gjendja pruned. Ky mesazh do të jetë mesazhi Graft. Pas marrjes së mesazhit Graft, R2 do të dërgojë përgjigjen Graft-ACK.
Prune Override.
Le të shikojmë këtë skemë. R1 transmeton multicast në segmentin me dy routera. R3 merr dhe transmeton trafik, R2 merr, por nuk ka askënd për të transmetuar trafik. Ai dërgon një mesazh Prune te R1 në këtë segment. R1 duhet të heqë Fa0/0 nga lista dhe të ndalojë transmetimin në këtë segment, por çfarë do të ndodhë me R3? R3 ndodhet në të njëjtin segment, gjithashtu e mori këtë mesazh Prune dhe e kupton tragjedinë e situatës. Para se R1 të ndalojë transmetimin, ai vendos një timer për 3 sekonda dhe do të ndalojë transmetimin pas 3 sekondash. 3 sekonda — pikërisht aq kohë ka R3 për të mos humbur multicast-in e tij. Prandaj R3, sa më shpejt të jetë e mundur, dërgon mesazhin Pim Join për këtë grup dhe R1 nuk mendon më të ndalojë transmetimin. Më poshtë janë mesazhet Join.
Mesazhi Assert.
Le të supozojmë një situatë: në një rrjet transmetojnë njëkohësisht dy routera. Të dy marrin të njëjtin rrjedh nga burimi dhe e transmetojnë në një rrjet përmes ndërfaqes e0. Prandaj, ata duhet të përcaktojnë se kush do të jetë transmetuesi i vetëm për këtë rrjet. Për këtë përdoren mesazhe Assert. Kur R2 dhe R3 zbulojnë kopjimin e trafikut multicast, që do të thotë se në R2 dhe R3 arrin një multicast, i cili ata vetë e transmetojnë, routerat kuptojnë se ka diçka që nuk shkon. Në këtë rast, routerat dërgojnë mesazhe Assert, në të cilat përfshihen Distanca Administrative dhe metrika e rrugës përmes së cilës arrin te burimi i multicast - 10.1.1.10. Fituesi përcaktohet kështu:
- Ai që ka AD më të ulët.
- Nëse AD janë të barabarta, atëherë ai që ka metrikën më të ulët.
- Nëse këtu ka një barazi, atëherë ai që ka IP më të lartë në rrjetin në të cilin ata transmetojnë këtë multicast.
Fituesi në këtë votim, routeri bëhet Router i Caktuar. Për të zgjedhur DR gjithashtu përdoren mesazhet Pim Hello. Në fillim të artikullit u tregua një mesazh PIM Hello, ku mund të shihet fusha DR. Pjesa fituese është ai që ka IP më të lartë në këtë lidhje.
Tabelë e dobishme:
Tabela MROUTE.
Pas shqyrtimit fillestar të funksionit të protokollit PIM, ne duhet të kuptojmë sesi të punojmë me tabelën e rrugëzimit multicast. Në tabelën mroute ruhen informacionet se cilat rrjedha janë kërkuar nga klientët dhe cilat rrjedha priten nga serverat multicast.
Për shembull, kur pranoni një IGMP Membership Report ose PIM Join në ndonjë ndërfaqe, në tabelën e rrugëzimit shtohet një regjistrim i tipit (*, G):
Ky regjistrim nënkupton se është marrë një kërkesë për trafik nga adresa 238.38.38.38. Flaga DC nënkupton se multicast do të funksionojë në modin Dense dhe C tregon se marrësi është lidhur drejtpërdrejt me routerin, domethënë routeri ka marrë IGMP Membership Report dhe PIM Join.
Nëse ka një regjistrim të tipit (S,G) nënkupton se kemi një rrjedhë multicast:
Në fushën S — 192.168.1.11, kemi shkruar adresën IP të burimit të multicast, dhe kjo do të kontrollohet nga rregulli RPF. Në rast probleme, fillimisht duhet të kontrolloni tabelën unicast për rrugën drejt burimit. Në fushën e Ndërfaqes së Pranimit tregohet ndërfaqja, në të cilën arrin multicast. Në tabelën e rrugëzimit unicast, rruga drejt burimit duhet të referohet në ndërfaqen e përcaktuar këtu. Në fushën Ndërfaqja e Dërgimit tregohet ku do të redirektohet multicast. Nëse ajo është bosh, atëherë routeri nuk ka marrë kërkesa për këtë trafik. Informacione më të detajuara rreth të gjitha flamujve mund të gjenden .
PIM Sparse-mode.
Strategjia Sparse-mode është e kundërta e Dense-mode. Kur Sparse-mode merr trafik multicast, ai do ta dërgojë trafikun vetëm përmes atyre ndërfaqeve ku janë bërë kërkesa për këtë rrjedhë, për shembull mesazhe Pim Join ose IGMP Report që kërkojnë për këtë trafik.
Elementet e ngjashme në SM dhe DM:
- Raportet e fqinjësisë ndërtohen ashtu si në PIM DM.
- Rregulli RPF funksionon.
- Zgjedhja e DR është e ngjashme.
- Mekanizmi Prune Overrides dhe mesazhet Assert janë të ngjashme.
Për të kontrolluar se kush, ku dhe çfarë trafik multicast nevojitet në rrjet, është e nevojshme një qendër informacioni e përbashkët. Ky qendër do të jetë Pikë Takimi (RP). Të gjithë ata që duan ndonjë trafik multicast ose ata që kanë filluar të marrin trafik multicast nga burimi, e dërgojnë atë në RP.
Kur RP të marrë trafik multicast, ai do t'ia dërgojë atyre routerave që kanë kërkuar më parë këtë trafik.
Le të supozojmë një topologji, ku RP është R3. Sap o R1 të marrë trafik nga S1, ai inkapsulon këtë paketë multicast në një mesazh unicast PIM Register dhe e dërgon atë në RP. Si e di ai kush është RP? Në këtë rast, ai është konfiguruar statikisht, ndërsa me konfigurimin dinamik të RP do të flasim më vonë.
ip pim rp-address 3.3.3.3
RP do të shikojë — a ka pasur ndonjë informacion nga dikush që dëshiron të marrë këtë trafik? Le të supozojmë se nuk ka pasur. Atëherë RP do t'i dërgojë R1 një mesazh PIM Register-Stop, që do të thotë — askush nuk e dëshiron këtë multicast, regjistrimi refuzohet. R1 nuk do të dërgojë multicast. Por host burim multicast do ta dërgojë, kështu që R1 pas marrjes së Register-Stop do të aktivizojë atë që quhet Register-Suppression timer, që është 60 sekonda. 5 sekonda para përfundimit të këtij timeri, R1 do të dërgojë një mesazh të zbrazët Register me Null-Register bit (dmth pa paketë multicast të inkapsuluar) drejt RP. RP nga ana e saj do të veprojë kështu:
- Nëse nuk kishte marrës dhe nuk ka ndonjë, ai do të përgjigjet me një mesazh Register-Stop.
- Nëse ka pasur marrës, atëherë ai nuk do t'i përgjigjet ashtu. R1, duke mos marrë një refuzim për regjistrimin e tij brenda 5 sekondash, do të gëzohet dhe do të dërgojë një mesazh Register me paketën multicast të inkapsuluar në RP.
Tani si e kuptuam si arrin multicast tek RP, tani do të përpiqemi të përgjigjemi në pyetjen se si RP e dorëzon trafikën tek marrësit. Këtu duhet të prezantojmë një koncept të ri — pemën e rrugës rrënjësore (RPT). RPT është një pemë me rrënjë tek RP, e cila shkon drejt marrësve, duke u ndarë në çdo router PIM-SM. RP e krijon atë, duke marrë mesazhe PIM Join dhe shton një degë të re në pemë. Kështu, bën çdo router i poshtëm. Rregulli i përgjithshëm duket kështu:
- Kur një router PIM-SM merr një mesazh PIM Join në ndonjë ndërfaqe, përveç ndërfaqes ku ndodhet RP, ai shton një degë të re në pemë.
- Po ashtu, një degë shtohet kur një router PIM-SM merr një Raport Anëtarësie IGMP nga një host që është direkt i lidhur.
Supozoni se kemi një klient multicast në routerin R5 në grupin 228.8.8.8. Sa herë që R5 merr Raport Anëtarësie IGMP nga hosti, R5 dërgon PIM Join drejt RP, dhe vetë shton në pemë ndërfaqen që shikon nga hosti. Më tej, R4 merr PIM Join nga R5, shton në pemë ndërfaqen Gi0/1 dhe dërgon PIM Join drejt RP. Përfundimisht, RP (R3) merr PIM Join dhe shton Gi0/0 në pemë. Kështu, ndodh regjistrimi i marrësit multicast. Ne krijojmë një pemë me rrënjë R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Pas kësaj, do të dërgohet PIM Join te R1 dhe R1 do të fillojë të dërgojë trafik multicast. Është e rëndësishme të theksohet se nëse hosti ka kërkuar trafik para se të fillonte transmetimi i multicast, atëherë RP nuk do të dërgojë PIM Join dhe asgjë nuk do të dërgojë drejt R1.
Nëse ndodhi që gjatë transmetimit të multicast, hosti të ndalojë së dëshiruar, sapo RP të marrë PIM Prune në ndërfaqen Gi0/0, ai menjëherë do të dërgojë PIM Register-Stop direkt te R1, pastaj edhe mesazhin PIM Prune përmes ndërfaqes Gi0/1. PIM Register-stop dërgohet me unicast në adresën nga e cila ka ardhur PIM Register.
Siç e thamë më parë, sa herë që një router dërgon PIM Join tek një tjetër, për shembull R5 tek R4, atëherë në R4 shtohet një regjistrim:
Dhe aktivizohet një timer, që për të anuluar këtë timer, R5 duhet të dërgojë vazhdimisht mesazhe PIM Join, përndryshe R4 do ta përjashtojë nga lista dalëse. R5 do të dërgojë çdo 60 mesazhe PIM Join.
Ndërrimi i Pemës së Rrugës më të Shkurtër.
Do të shtojmë një ndërfaqe midis R1 dhe R5, të shohim si do të kalojë trafiku në këtë topologji.
Supozoni se trafiku është dërguar dhe marrë sipas skemës së vjetër R1-R2-R3-R4-R5 dhe këtu ne kemi lidhur dhe konfiguruar një ndërfaqe midis R1 dhe R5.
Së pari, tabela e rrugëtimit unicast në R5 do të përmirësohet dhe tani rrjeti 192.168.1.0/24 arrihet përmes ndërfaqes R5 Gi0/2. Tani R5, duke marrë multicast në ndërfaqen Gi0/1, kupton se rregulli RPF nuk përmbushet dhe do të ishte më logjike të merrte multicast në Gi0/2. Ai duhet të çprishë lidhjen me RPT dhe të krijojë një pemë më të shkurtër, e cila quhet Pema e Rrugës më të Shkurtër (SPT). Për këtë, ai dërgon një PIM Join në R1 përmes Gi0/2 dhe R1 fillon të dërgojë multicast gjithashtu përmes Gi0/2. Tani R5 duhet të çregjistrohet nga RPT, për të mos marrë dy kopje. Për këtë, ai dërgon një mesazh Prune duke treguar adresën IP të burimit dhe duke futur një bit të veçantë — RPT-bit. Kjo do të thotë se nuk është e nevojshme të më dërgoni trafik, unë kam këtu një pemë më të mirë. RP gjithashtu dërgon mesazhe PIM Prune në drejtim të R1, por nuk dërgon mesazhin Register-Stop. Një veçori tjetër: R5 tani do të dërgojë vazhdimisht PIM Prune te RP, për shkak se R1 vazhdon të dërgojë PIM Register te RP çdo minutë. RP do t'i përgjigjet me refuzim derisa të ketë kërkesa të reja për këtë trafik. R5 e njofton RP se vazhdon të marrë multicast përmes SPT.
Kërkimi Dinamik i RP.
Auto-RP.
Kjo teknologji është pronësi e Cisco dhe nuk është shumë e njohur, por ende është aktive. Funksionimi i Auto-RP përbëhet nga dy faza kryesore:
1) RP dërgon mesazhe RP-Announce në adresën e rezervuar — 224.0.1.39, duke shpallur veten RP ose për të gjitha grupet ose për grupe të caktuara. Ky mesazh dërgohet çdo minutë.
2) Nevojitet një agjent për hartimin e RP, që do të dërgojë mesazhe RP-Discovery duke treguar për cilat grupe cili RP duhet të dëgjojë. Sipas këtij mesazhi, routerat PIM do të përcaktojnë RP për vetveten. Agjenti i Hartimit mund të jetë si vetë routeri RP, ashtu edhe ndonjë router i veçantë PIM. RP-Discovery dërgohet në adresën 224.0.1.40 me një timer prej një minute.
Të shohim procesin më në detaje:
Të konfigurojmë R3 si RP:
ip pim send-rp-announce loopback 0 scope 10
R2 si agjent hartimi:
ip pim send-rp-discovery loopback 0 scope 10
Dhe në të gjithë të tjerët do të presim RP përmes Auto-RP:
ip pim autorp listener
Sa herë që ne konfigurojmë R3, ai do të fillojë të dërgojë RP-Announce:
Dhe R2, pas konfigurimit si agjent hartimi, do të fillojë të presë mesazhet RP-Announce. Vetëm kur të gjejë të paktën një RP, ai do të fillojë të dërgojë RP-Discovery:
Таким образом, как только обычные маршрутизаторы ( PIM RP Listener ) получат данное сообщения, они будут знать где искать RP.
Одна из основных проблем Auto-RP заключается в том, что чтобы получать сообщения RP-Announce и RP-Discovery необходимо отправлять PIM Join на адреса 224.0.1.39-40, а для того, чтобы отправить, надо знать где находится RP. Классическая проблема курицы и яйца. Для решение это проблемы, был придуман режим PIM Sparse-Dense-Mode. Если маршрутизатор не знает RP, то он работает в режиме Dense-mode, если знает, то в режиме Sparse-mode. Когда на интерфейсах обычных маршрутизаторов настроен PIM Sparse-mode и команда ip pim autorp listener, то маршрутизатор будет работать в режиме Dense-mode только для мультикаста непосредственно Auto-RP протокола ( 224.0.1.39-40 ).
BootStrap Router (BSR).
Данный функция работает похоже на Auto-RP. Каждый RP шлет сообщение mapping agent-у, который собирает маппинг информацию и далее рассказывает всем остальным маршрутизаторам. Опишем процесс аналогично Auto-RP:
1) Как только мы настроим R3 в качестве кандидата быть RP, командой:
ip pim rp-candidate loopback 0
То R3 ничего делать не будет, для того, чтобы начать слать специальные сообщение, ему, для начала, надо найти mapping agent-а. Таким образом, переходим ко второму шагу.
2) Настраиваем R2 как mapping agent:
ip pim bsr-candidate loopback 0
R2 начинает рассылать PIM Bootstrap сообщения, где указывает себя в качестве mapping agent-а:
Отправляется данное сообщение на адрес 224.0.013, которое PIM протокол использует и для других своих сообщений. Он отправляет их во все стороны и поэтому нет проблемы курицы и яйца, как было в Auto-RP.
3) Как только RP получит сообщение от BSR маршрутизатора, он сразу отправит юникастовое сообщение на адрес BSR маршрутизатора:
После чего, BSR получив информацию о RP, разошлет их мультикастом на адрес 224.0.0.13, который слушают все PIM маршрутизаторы. Поэтому, аналога команды ip pim autorp listener для обычных маршрутизаторов нет в BSR.
Anycast RP with Multicast Source Discovery Protocol (MSDP).
Auto-RP и BSR нам позволяют распредилить нагрузку на RP следующим образом: У каждой мультикаст группы есть только один активный RP. Не получится сделать распределение нагрузки для одной мультикаст группы несколько RP. MSDP делает это при помощи выдачи RP маршрутизаторам одинакового ip адреса с маской 255.255.255.255. MSDP узнает информацию при помощи одного из методов: статики, Auto-RP или BSR.
На картинке у нас Auto-RP конфигурация с MSDP. Оба RP настроены с ip адресом 172.16.1.1/32 на Loopback 1 интерфейсе и используется для всех групп. При RP-Announce оба маршрутизатора рассказывают о себе, ссылаясь на этот адрес. Auto-RP mapping agent, получив информацию, рассылает RP-Discovery об RP c адресом 172.16.1.1/32. Про сеть 172.16.1.1/32, маршрутизаторам мы рассказываем при помощи IGP и, соответственно. Таким образом, PIM маршрутизаторы запрашивают или регистрируют потоки с того RP, к который указан как next-hop у маршрута к сети 172.16.1.1/32. Cам протокол MSDP же призван для самих RP, чтоб обмениваться сообщениями о информации про мультикаст.
Рассмотрим такую топологию:
Switch6 вещает трафик на адрес 238.38.38.38 и о нем пока знает только RP-R1. Вот Switch7 и Switch8 запросили данную группу. Маршрутизаторы R5 и R4 отправят PIM Join на R1 и R3, соответственно. Почему? Маршрут до 13.13.13.13 у R5 будет ссылаться на R1 по метрике IGP, как и у R4.
RP-R1 знает о потоке и начнет вещать его в сторону R5, а вот R4 ничего о нем не знает, так как R1 просто так его отправлять не будет. Поэтому необходим MSDP. Настраиваем его на R1 и R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 на R1
ip msdp peer 1.1.1.1 connect-source Loopback3 на R3
Они поднимут сессию между друг другом и при получении какого-либо потока будут сообщать о нем своему RP соседу.
RP-R1 как только получит поток от Switch6, сразу отправит юникастом MSDP Source-Active сообщение, где будет содержаться информация типа ( S, G) — информация о источнике и назначении мультикаста. Теперь, когда RP-R3 будет знать, что такой источник как Switch6, он при получении запроса от R4 на данный поток, будет слать в сторону Switch6 PIM Join, руководстваясь таблицей маршрутизации. Следовательно, R1 получив такой PIM Join, начнет слать трафик в сторону RP-R3.
MSDP работает по TCP, RP посылают друг другу keepalive сообщения для проверки жизнеспособности. Таймер равен 60 cекундам.
Остается непонятной функция разделения MSDP пиров в различные домены, так как в сообщениях Keepalive и SA не указывается принадлежность какому-либо домену. Также в данной топологии тестировалась конфигурация с указанием различных доменов — разницы в работе не было.
Если кто-то может внести ясность, с радостью почитаю в комментариях.
Burimi: habr.com
