Paano gumagana ang PIM protocol

Ang PIM protocol ay isang hanay ng mga protocol para sa pagpapadala ng multicast sa isang network sa pagitan ng mga router. Ang mga relasyon sa kapitbahayan ay binuo sa parehong paraan tulad ng sa kaso ng mga dynamic na routing protocol. Ang PIMv2 ay nagpapadala ng mga Hello message bawat 30 segundo sa nakareserbang multicast address na 224.0.0.13 (All-PIM-Routers). Ang mensahe ay naglalaman ng Mga Hold Timer - karaniwang katumbas ng 3.5*Hello Timer, ibig sabihin, 105 segundo bilang default.

Gumagamit ang PIM ng dalawang pangunahing operating mode - Dense at Sparse mode. Magsimula tayo sa Dense mode.
Mga Puno ng Pamamahagi na Nakabatay sa Pinagmulan.
Ang mode na dense-mode ay ipinapayong gamitin sa kaso ng isang malaking bilang ng mga kliyente ng iba't ibang mga multicast na grupo. Kapag nakatanggap ang isang router ng multicast na trapiko, ang unang bagay na ginagawa nito ay suriin ito para sa panuntunan ng RPF. RPF - ang panuntunang ito ay ginagamit upang suriin ang pinagmulan ng isang multicast na may unicast routing table. Kinakailangang dumating ang trapiko sa interface kung saan nakatago ang host na ito ayon sa bersyon ng unicast routing table. Ang mekanismong ito ay nalulutas ang problema ng isang loop na nagaganap sa panahon ng multicast transmission.

Makikilala ng R3 ang multicast source (Source IP) mula sa multicast message at suriin ang dalawang daloy mula sa R1 at R2 gamit ang unicast table nito. Ang stream mula sa interface na itinuro ng talahanayan (R1 hanggang R3) ay ipapadala pa, at ang stream mula sa R2 ay ihuhulog, dahil upang makarating sa multicast source, kailangan mong magpadala ng mga packet sa pamamagitan ng S0/1.
Ang tanong, ano ang mangyayari kung mayroon kang dalawang katumbas na ruta na may parehong sukatan? Sa kasong ito, pipiliin ng router ang next-hop mula sa mga rutang ito. Kung sino ang may mas mataas na IP address ay panalo. Kung kailangan mong baguhin ang gawi na ito, maaari mong gamitin ang ECMP. Higit pang mga detalye dito.
Pagkatapos suriin ang panuntunan ng RPF, ang router ay nagpapadala ng isang multicast packet sa lahat ng mga kapitbahay nito sa PIM, maliban sa isa kung saan natanggap ang packet. Ulitin ng ibang PIM router ang prosesong ito. Ang path na kinuha ng isang multicast packet mula sa pinagmulan hanggang sa mga huling tatanggap ay bumubuo ng isang puno na tinatawag na source-based distribution tree, shortest-path tree (SPT), source tree. Tatlong magkakaibang pangalan, pumili ng alinman.
Paano malutas ang problema na ang ilang mga router ay hindi sumuko sa ilang multicast stream at walang sinumang magpapadala nito, ngunit ang upstream router ay nagpapadala nito sa kanya. Ang mekanismo ng Prune ay naimbento para dito.
Prune na Mensahe.
Halimbawa, ang R2 ay patuloy na magpapadala ng isang multicast sa R3, bagaman ang R3, ayon sa panuntunan ng RPF, ay ibinabagsak ito. Bakit i-load ang channel? Nagpapadala ang R3 ng PIM Prune Message at ang R2, kapag natanggap ang mensaheng ito, ay aalisin ang interface S0/1 mula sa papalabas na listahan ng interface para sa daloy na ito, ang listahan ng mga interface kung saan dapat ipadala ang trapikong ito.

Ang sumusunod ay isang mas pormal na kahulugan ng isang mensahe ng PIM Prune:
Ang mensahe ng PIM Prune ay ipinadala ng isang router sa isang pangalawang router upang maging sanhi ng pangalawang router na alisin ang link kung saan ang Prune ay natanggap mula sa isang partikular na (S,G) SPT.

Pagkatapos matanggap ang mensahe ng Prune, itinatakda ng R2 ang timer ng Prune sa 3 minuto. Pagkalipas ng tatlong minuto, magsisimula itong magpadala muli ng trapiko hanggang sa makatanggap ito ng isa pang mensahe ng Prune. Ito ay nasa PIMv1.
At sa PIMv2 isang State Refresh timer ang naidagdag (60 segundo bilang default). Sa sandaling maipadala ang isang mensahe ng Prune mula sa R3, magsisimula ang timer na ito sa R3. Sa pag-expire ng timer na ito, magpapadala ang R3 ng mensahe ng State Refresh, na magre-reset ng 3 minutong Prune Timer sa R2 para sa grupong ito.
Mga dahilan para sa pagpapadala ng mensahe ng Prune:

• Kapag nabigo ang isang multicast packet sa pagsusuri ng RPF.
• Kapag walang lokal na konektadong kliyente na humiling ng multicast group (IGMP Join) at walang PIM neighbors kung saan maaaring ipadala ang multicast traffic (Non-prune Interface).

Graft Message.
Isipin natin na ayaw ni R3 ng traffic mula sa R2, nagpadala ng Prune at nakatanggap ng multicast mula sa R1. Ngunit biglang nahulog ang channel sa pagitan ng R1-R3 at ang R3 ay naiwang walang multicast. Maaari kang maghintay ng 3 minuto hanggang sa mag-expire ang Prune Timer sa R2. Ang 3 minuto ay isang mahabang paghihintay, upang hindi maghintay, kailangan mong magpadala ng mensahe na agad na magdadala sa interface na ito na S0/1 hanggang R2 mula sa pruned state. Magiging isang Graft message ang mensaheng ito. Pagkatapos matanggap ang mensahe ng Graft, tutugon ang R2 gamit ang isang Graft-ACK.
Prune Override.

Tingnan natin ang diagram na ito. Ang R1 ay nagbo-broadcast ng multicast sa isang segment na may dalawang router. Ang R3 ay tumatanggap at nagbo-broadcast ng trapiko, ang R2 ay tumatanggap, ngunit walang sinumang mag-broadcast ng trapiko. Nagpapadala ito ng mensahe ng Prune sa R1 sa segment na ito. Dapat alisin ng R1 ang Fa0/0 sa listahan at ihinto ang pagsasahimpapawid sa segment na ito, ngunit ano ang mangyayari sa R3? At si R3 ay nasa parehong segment, natanggap din ang mensaheng ito mula sa Prune at naunawaan ang trahedya ng sitwasyon. Bago huminto ang R1 sa pagsasahimpapawid, nagtatakda ito ng timer na 3 segundo at hihinto sa pagsasahimpapawid pagkatapos ng 3 segundo. 3 segundo - ito ay eksakto kung gaano katagal ang R3 upang hindi mawala ang kanyang multicast. Samakatuwid, nagpapadala si R3 ng mensahe ng Pim Join para sa grupong ito sa lalong madaling panahon, at hindi na iniisip ni R1 na ihinto ang pagsasahimpapawid. Tungkol sa Sumali sa mga mensahe sa ibaba.
Igiit ang Mensahe.

Isipin natin ang sitwasyong ito: dalawang router ang nag-broadcast sa isang network nang sabay-sabay. Nakatanggap sila ng parehong stream mula sa pinagmulan, at pareho itong nai-broadcast sa parehong network sa likod ng interface e0. Samakatuwid, kailangan nilang tukuyin kung sino ang magiging nag-iisang broadcaster para sa network na ito. Ang mga mensahe ng paggiit ay ginagamit para dito. Kapag nakita ng R2 at R3 ang pagdoble ng trapiko ng multicast, iyon ay, dumating ang isang multicast sa R2 at R3, na sila mismo ang nag-broadcast, naiintindihan ng mga router na may mali dito. Sa kasong ito, ang mga router ay nagpapadala ng mga mensahe ng Assert, na kinabibilangan ng Administrative Distance at ang sukatan ng ruta kung saan naabot ang multicast source - 10.1.1.10. Ang nagwagi ay tinutukoy bilang mga sumusunod:

1. Yung may lower AD.
2. Kung pantay ang AD, sino ang may mas mababang sukatan.
3. Kung mayroong pagkakapantay-pantay dito, kung gayon ang may mas mataas na IP sa network kung saan sila nag-broadcast ng multicast na ito.

Ang nagwagi sa boto na ito ay naging Designated Router. Ginagamit din ang Pim Hello para pumili ng mga DR. Sa simula ng artikulo, ipinakita ang mensahe ng PIM Hello, makikita mo ang field ng DR doon. Panalo ang may pinakamataas na IP address sa link na ito.
Kapaki-pakinabang na palatandaan:

MROUTE Talahanayan.
Pagkatapos ng unang pagtingin sa kung paano gumagana ang PIM protocol, kailangan nating maunawaan kung paano magtrabaho sa isang multicast routing table. Ang mroute table ay nag-iimbak ng impormasyon tungkol sa kung aling mga stream ang hiniling mula sa mga kliyente at kung aling mga stream ang dumadaloy mula sa mga multicast server.
Halimbawa, kapag ang isang IGMP Membership Report o PIM Join ay natanggap sa ilang interface, isang talaan ng uri ( *, G ) ay idinagdag sa routing table:

Ang entry na ito ay nangangahulugan na ang isang kahilingan sa trapiko ay natanggap na may address na 238.38.38.38. Ang DC flag ay nangangahulugan na ang multicast ay gagana sa Dense mode at ang C ay nangangahulugan na ang tatanggap ay direktang konektado sa router, iyon ay, ang router ay nakatanggap ng IGMP Membership Report at PIM Join.
Kung mayroong talaan ng uri (S,G) nangangahulugan ito na mayroon tayong multicast stream:

Sa larangan ng S - 192.168.1.11, nairehistro namin ang IP address ng pinagmulan ng multicast, ito ang susuriin ng panuntunan ng RPF. Kung may mga problema, ang unang bagay na kailangan mong gawin ay suriin ang unicast table para sa ruta patungo sa pinagmulan. Sa field na Papasok na Interface, ipinapahiwatig ang interface kung saan natatanggap ang multicast. Sa isang unicast routing table, ang ruta patungo sa pinagmulan ay dapat sumangguni sa interface na tinukoy dito. Tinutukoy ng Outgoing Interface kung saan ire-redirect ang multicast. Kung ito ay walang laman, kung gayon ang router ay hindi nakatanggap ng anumang mga kahilingan para sa trapikong ito. Higit pang impormasyon tungkol sa lahat ng mga flag ay matatagpuan dito.
PIM Sparse-mode.
Ang diskarte ng Sparse-mode ay ang kabaligtaran ng Dense-mode. Kapag nakatanggap ang Sparse-mode ng multicast na trapiko, magpapadala lamang ito ng trapiko sa pamamagitan ng mga interface kung saan may mga kahilingan para sa daloy na ito, halimbawa Pim Join o IGMP Report na mga mensahe na humihiling ng trapikong ito.
Mga katulad na elemento para sa SM at DM:

• Ang mga relasyon sa kapitbahayan ay binuo sa parehong paraan tulad ng sa PIM DM.
• Gumagana ang panuntunan ng RPF.
• Ang pagpili ng DR ay magkatulad.
• Ang mekanismo ng Prune Overrides at Assert na mga mensahe ay magkatulad.

Upang makontrol kung sino, saan at anong uri ng multicast na trapiko ang kailangan sa network, kailangan ang isang karaniwang sentro ng impormasyon. Ang magiging sentro natin ay Rendezvous Point (RP). Sinumang nais ng ilang uri ng multicast na trapiko o isang taong nagsimulang makatanggap ng multicast na trapiko mula sa pinagmulan, pagkatapos ay ipinapadala niya ito sa RP.
Kapag nakatanggap ang RP ng multicast na trapiko, ipapadala ito sa mga router na iyon na dati nang humiling ng trapikong ito.

Isipin natin ang isang topology kung saan ang RP ay R3. Sa sandaling makatanggap ang R1 ng trapiko mula sa S1, isinasama nito ang multicast packet na ito sa isang unicast na PIM Register na mensahe at ipinapadala ito sa RP. Paano niya malalaman kung sino ang RP? Sa kasong ito, naka-configure ito nang statically, at pag-uusapan natin ang tungkol sa dynamic na configuration ng RP mamaya.

ip pim rp-address 3.3.3.3

Titingnan ng RP - mayroon bang impormasyon mula sa isang taong gustong makatanggap ng trapikong ito? Ipagpalagay natin na hindi. Pagkatapos ang RP ay magpapadala kay R1 ng isang PIM Register-Stop na mensahe, na nangangahulugan na walang nangangailangan ng multicast na ito, ang pagpaparehistro ay tinanggihan. Ang R1 ay hindi magpapadala ng multicast. Ngunit ipapadala ito ng multicast source host, upang ang R1, pagkatapos matanggap ang Register-Stop, ay magsisimula ng Register-Suppression timer na katumbas ng 60 segundo. 5 segundo bago mag-expire ang timer na ito, magpapadala ang R1 ng walang laman na Register message na may Null-Register bit (iyon ay, walang encapsulated multicast packet) patungo sa RP. Ang RP, sa turn, ay kikilos tulad nito:

• Kung walang tatanggap, tutugon ito ng isang Register-Stop na mensahe.
• Kung lumitaw ang mga tatanggap, hindi siya tutugon dito sa anumang paraan. Si R1, na hindi nakatanggap ng pagtanggi na magparehistro sa loob ng 5 segundo, ay magiging masaya at magpapadala ng mensahe sa Register na may naka-encapsulated na multicast sa RP.

Tila naisip natin kung paano naaabot ng multicast ang RP, ngayon subukan nating sagutin ang tanong kung paano naghahatid ng trapiko ang RP sa mga tatanggap. Narito ito ay kinakailangan upang ipakilala ang isang bagong konsepto - root-path tree (RPT). Ang RPT ay isang punong nakaugat sa RP, lumalaki patungo sa mga tatanggap, na sumasanga sa bawat router ng PIM-SM. Ginagawa ito ng RP sa pamamagitan ng pagtanggap ng mga mensahe ng PIM Join at pagdaragdag ng bagong sangay sa puno. At kaya, ginagawa ng bawat downstream router. Ang pangkalahatang tuntunin ay ganito ang hitsura:

• Kapag nakatanggap ang isang PIM-SM router ng mensahe ng PIM Join sa anumang interface maliban sa interface kung saan nakatago ang RP, nagdaragdag ito ng bagong sangay sa puno.
• Nagdaragdag din ng branch kapag nakatanggap ang PIM-SM router ng IGMP Membership Report mula sa direktang konektadong host.

Isipin natin na mayroon tayong multicast client sa R5 router para sa grupong 228.8.8.8. Sa sandaling matanggap ni R5 ang IGMP Membership Report mula sa host, magpapadala si R5 ng PIM Join sa direksyon ng RP, at mismong nagdadagdag ng interface sa tree na tumitingin sa host. Susunod, natatanggap ng R4 ang PIM Join mula sa R5, nagdaragdag ng interface na Gi0/1 sa puno at nagpapadala ng PIM Join sa direksyon ng RP. Sa wakas, natatanggap ng RP ( R3 ) ang PIM Join at nagdagdag ng Gi0/0 sa puno. Kaya, ang tatanggap ng multicast ay nakarehistro. Nagtatayo kami ng puno na may ugat na R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Pagkatapos nito, ang isang PIM Join ay ipapadala sa R1 at ang R1 ay magsisimulang magpadala ng multicast na trapiko. Mahalagang tandaan na kung ang host ay humiling ng trapiko bago magsimula ang multicast broadcast, ang RP ay hindi magpapadala ng PIM Join at hindi magpapadala ng kahit ano sa R1.
Kung biglang habang ipinapadala ang isang multicast, ang host ay huminto sa pagnanais na matanggap ito, sa sandaling matanggap ng RP ang isang PIM Prune sa Gi0/0 interface, agad itong magpapadala ng isang PIM Register-Stop nang direkta sa R1, at pagkatapos ay isang PIM Prune mensahe sa pamamagitan ng interface ng Gi0/1. Ang PIM Register-stop ay ipinapadala sa pamamagitan ng unicast sa address kung saan nanggaling ang PIM Register.
Gaya ng sinabi namin kanina, sa sandaling magpadala ang isang router ng isang PIM Join sa isa pa, halimbawa R5 hanggang R4, pagkatapos ay may idinagdag na record sa R4:

At ang isang timer ay nagsimula na ang R5 ay dapat na patuloy na i-reset ang timer na ito PIM Join messages patuloy, kung hindi, R4 ay hindi isasama sa papalabas na listahan. Ipapadala ng R5 ang bawat 60 PIM Join messages.
Shortest-Path Tree Switchover.
Magdaragdag kami ng interface sa pagitan ng R1 at R5 at tingnan kung paano dumadaloy ang trapiko sa topology na ito.

Ipagpalagay natin na ang trapiko ay ipinadala at natanggap ayon sa lumang scheme R1-R2-R3-R4-R5, at dito namin ikinonekta at isinaayos ang interface sa pagitan ng R1 at R5.
Una sa lahat, kailangan nating buuin muli ang unicast routing table sa R5 at ngayon ang network na 192.168.1.0/24 ay naabot sa pamamagitan ng R5 Gi0/2 interface. Ngayon ang R5, na tumatanggap ng multicast sa interface na Gi0/1, ay nauunawaan na ang panuntunan ng RPF ay hindi nasiyahan at magiging mas lohikal na makatanggap ng multicast sa Gi0/2. Dapat itong idiskonekta mula sa RPT at bumuo ng isang mas maikling puno na tinatawag na Shortest-Path Tree (SPT). Upang gawin ito, ipinapadala niya ang PIM Join sa R0 sa pamamagitan ng Gi2/1 at ang R1 ay nagsimulang magpadala din ng multicast sa pamamagitan ng Gi0/2. Ngayon ang R5 ay kailangang mag-unsubscribe mula sa RPT upang hindi makatanggap ng dalawang kopya. Upang gawin ito, nagpapadala siya ng Prune ng isang mensahe na nagpapahiwatig ng pinagmulan ng IP address at pagpasok ng isang espesyal na bit - RPT-bit. Nangangahulugan ito na hindi mo na kailangang magpadala sa akin ng trapiko, mayroon akong isang mas mahusay na puno dito. Nagpapadala rin ang RP ng mga mensahe ng PIM Prune sa R1, ngunit hindi nagpapadala ng mensaheng Register-Stop. Isa pang tampok: Ang R5 ay patuloy na magpapadala ng PIM Prune sa RP, dahil ang R1 ay patuloy na nagpapadala ng PIM Register sa RP bawat minuto. Hangga't walang mga bagong tao na gusto ang trapikong ito, tatanggihan ito ng RP. Inaabisuhan ng R5 ang RP na patuloy itong tumatanggap ng multicast sa pamamagitan ng SPT.
Dynamic na paghahanap sa RP.
Auto-RP.
Ang teknolohiyang ito ay pagmamay-ari mula sa Cisco at hindi partikular na sikat, ngunit buhay pa rin. Ang pagpapatakbo ng Auto-RP ay binubuo ng dalawang pangunahing yugto:
1) Nagpapadala ang RP ng RP-I-anunsyo ang mga mensahe sa nakareserbang address - 224.0.1.39, na nagdedeklara ng sarili nitong RP para sa lahat o para sa mga partikular na grupo. Ang mensaheng ito ay ipinapadala bawat minuto.
2) Kinakailangan ang isang ahente ng pagmamapa ng RP, na magpapadala ng mga mensahe ng RP-Discovery na nagsasaad kung aling mga grupo ang dapat pakinggan ng RP. Mula sa mensaheng ito na ang mga regular na router ng PIM ay tutukuyin ang RP para sa kanilang sarili. Ang Mapping Agent ay maaaring ang RP router mismo o isang hiwalay na PIM router. Ang RP-Discovery ay ipinadala sa address 224.0.1.40 na may timer na isang minuto.
Tingnan natin ang proseso nang mas detalyado:
I-configure natin ang R3 bilang RP:

ip pim send-rp-announce loopback 0 saklaw 10

R2 bilang ahente ng pagmamapa:

ip pim send-rp-discovery loopback 0 saklaw 10

At sa lahat ng iba pa ay aasahan namin ang RP sa pamamagitan ng Auto-RP:

ip pim autorp listener

Kapag na-configure namin ang R3, magsisimula itong magpadala ng RP-Announce:

At si R2, pagkatapos mag-set up ng mapping agent, ay magsisimulang maghintay para sa mensahe ng RP-Announce. Kapag nakakita lang ito ng kahit isang RP, magsisimula itong magpadala ng RP-Discovery:

Sa ganitong paraan, sa sandaling matanggap ng mga regular na router (PIM RP Listener) ang mensaheng ito, malalaman nila kung saan hahanapin ang RP.
Ang isa sa mga pangunahing problema sa Auto-RP ay upang makatanggap ng mga mensahe ng RP-Announce at RP-Discovery, kailangan mong magpadala ng PIM Join sa mga address na 224.0.1.39-40, at upang maipadala, kailangan mong malaman kung saan ang Matatagpuan ang RP. Klasikong problema sa manok at itlog. Upang malutas ang problemang ito, naimbento ang PIM Sparse-Dense-Mode. Kung ang router ay hindi alam ang RP, pagkatapos ito ay nagpapatakbo sa Dense-mode kung alam nito, pagkatapos ay sa Sparse-mode; Kapag ang PIM Sparse-mode at ang ip pim autorp listener command ay na-configure sa mga interface ng mga regular na router, ang router ay gagana sa Dense-mode para lang sa multicasting nang direkta mula sa Auto-RP protocol (224.0.1.39-40).
BootStrap Router (BSR).
Gumagana ang function na ito katulad ng Auto-RP. Ang bawat RP ay nagpapadala ng mensahe sa ahente ng pagmamapa, na nangongolekta ng impormasyon sa pagmamapa at pagkatapos ay nagsasabi sa lahat ng iba pang mga router. Ilarawan natin ang proseso nang katulad ng Auto-RP:
1) Kapag na-configure namin ang R3 bilang isang kandidato upang maging RP, na may utos:

ip pim rp-kandidato loopback 0

Pagkatapos R3 ay hindi gagawa ng anuman; upang simulan ang pagpapadala ng mga espesyal na mensahe, kailangan muna niyang maghanap ng ahente ng pagmamapa. Kaya, lumipat kami sa pangalawang hakbang.
2) I-configure ang R2 bilang ahente ng pagmamapa:

ip pim bsr-candidate loopback 0

Nagsisimula ang R2 na magpadala ng mga mensahe ng PIM Bootstrap, kung saan ipinapahiwatig nito ang sarili nito bilang ahente ng pagmamapa:

Ang mensaheng ito ay ipinadala sa address na 224.0.013, na ginagamit din ng PIM protocol para sa iba pang mga mensahe nito. Ito ay nagpapadala sa kanila sa lahat ng direksyon at samakatuwid ay walang problema sa manok at itlog tulad ng nangyari sa Auto-RP.
3) Sa sandaling makatanggap ang RP ng mensahe mula sa BSR router, agad itong magpapadala ng unicast na mensahe sa address ng BSR router:

Pagkatapos nito, ang BSR, na nakatanggap ng impormasyon tungkol sa mga RP, ay ipapadala ang mga ito sa pamamagitan ng multicast sa address na 224.0.0.13, na pinakikinggan ng lahat ng mga router ng PIM. Samakatuwid, isang analogue ng utos ip pim autorp listener para sa mga regular na router na wala sa BSR.
Anycast RP na may Multicast Source Discovery Protocol (MSDP).
Ang Auto-RP at BSR ay nagpapahintulot sa amin na ipamahagi ang load sa RP gaya ng sumusunod: Ang bawat multicast group ay may isang aktibong RP lamang. Hindi posibleng ipamahagi ang load para sa isang multicast group sa ilang RP. Ginagawa ito ng MSDP sa pamamagitan ng pagbibigay sa mga RP router ng parehong IP address na may mask na 255.255.255.255. Natututo ang MSDP ng impormasyon gamit ang isa sa mga pamamaraan: static, Auto-RP o BSR.

Sa larawan mayroon kaming Auto-RP configuration na may MSDP. Ang parehong mga RP ay na-configure na may IP address 172.16.1.1/32 sa Loopback 1 interface at ginagamit para sa lahat ng mga grupo. Sa RP-Announce, inanunsyo ng parehong router ang kanilang sarili sa pamamagitan ng pagtukoy sa address na ito. Ang Auto-RP mapping agent, pagkatanggap ng impormasyon, ay nagpapadala ng RP-Discovery tungkol sa RP na may address na 172.16.1.1/32. Sinasabi namin sa mga router ang tungkol sa network 172.16.1.1/32 gamit ang IGP at, nang naaayon. Kaya, humihiling o magrehistro ang mga PIM router ng mga daloy mula sa RP na tinukoy bilang susunod na pag-hop sa ruta patungo sa network 172.16.1.1/32. Ang MSDP protocol mismo ay idinisenyo para sa mga RP mismo na makipagpalitan ng mga mensahe tungkol sa multicast na impormasyon.
Isaalang-alang ang topology na ito:

Ang Switch6 ay nagbo-broadcast ng trapiko sa address na 238.38.38.38 at hanggang ngayon ang RP-R1 lang ang nakakaalam nito. Hiniling ng Switch7 at Switch8 ang grupong ito. Ang mga router na R5 at R4 ay magpapadala ng PIM Join sa R1 at R3, ayon sa pagkakabanggit. Bakit? Ang ruta sa 13.13.13.13 para sa R5 ay tumutukoy sa R1 gamit ang IGP metric, tulad ng para sa R4.
Alam ng RP-R1 ang tungkol sa stream at sisimulan itong i-broadcast patungo sa R5, ngunit walang alam ang R4 tungkol dito, dahil hindi basta basta ipapadala ito ni R1. Kaya kailangan ang MSDP. Kino-configure namin ito sa R1 at R5:

ip msdp peer 3.3.3.3 connect-source Loopback1 sa R1

ip msdp peer 1.1.1.1 connect-source Loopback3 sa R3

Magtataas sila ng session sa pagitan ng isa't isa at kapag nakatanggap ng anumang daloy ay irereport nila ito sa kanilang kapitbahay sa RP.
Sa sandaling makatanggap ang RP-R1 ng stream mula sa Switch6, agad itong magpapadala ng unicast na MSDP Source-Active na mensahe, na maglalaman ng impormasyon tulad ng (S, G) - impormasyon tungkol sa pinagmulan at patutunguhan ng multicast. Ngayong alam na ng RP-R3 na ang source gaya ng Switch6, kapag nakatanggap ng kahilingan mula sa R4 para sa daloy na ito, magpapadala ito ng PIM Join patungo sa Switch6, na ginagabayan ng routing table. Dahil dito, ang R1 na nakatanggap ng naturang PIM Join ay magsisimulang magpadala ng trapiko patungo sa RP-R3.
Ang MSDP ay tumatakbo sa TCP, ang mga RP ay nagpapadala sa isa't isa ng mga keepalive na mensahe upang suriin ang kasiglahan. Ang timer ay 60 segundo.
Ang function ng paghahati ng mga peer ng MSDP sa iba't ibang domain ay nananatiling hindi maliwanag, dahil ang mga mensahe ng Keepalive at SA ay hindi nagpapahiwatig ng pagiging miyembro sa anumang domain. Gayundin, sa topology na ito, sinubukan namin ang isang pagsasaayos na nagpapahiwatig ng iba't ibang mga domain - walang pagkakaiba sa pagganap.
Kung may makapaglilinaw, ikalulugod kong basahin ito sa mga komento.

Pinagmulan: www.habr.com