Mae'r protocol PIM yn set o brotocolau ar gyfer trawsyrru aml-ddarllediad mewn rhwydwaith rhwng llwybryddion. Mae perthnasoedd cymdogaeth yn cael eu hadeiladu yn yr un ffordd ag yn achos protocolau llwybro deinamig. Mae PIMv2 yn anfon negeseuon Helo bob 30 eiliad i'r cyfeiriad aml-ddarllediad neilltuedig 224.0.0.13 (All-PIM-Routers). Mae'r neges yn cynnwys Amseryddion Dal - fel arfer yn hafal i 3.5 * Helo Timer, hynny yw, 105 eiliad yn ddiofyn.
Mae PIM yn defnyddio dau brif ddull gweithredu - modd trwchus a gwasgaredig. Gadewch i ni ddechrau gyda modd trwchus.
Coed Dosbarthu Seiliedig ar Ffynonellau.
Fe'ch cynghorir i ddefnyddio modd dwys-ddelw yn achos nifer fawr o gleientiaid o wahanol grwpiau aml-gastio. Pan fydd llwybrydd yn derbyn traffig aml-gast, y peth cyntaf y mae'n ei wneud yw ei wirio am y rheol RPF. RPF - defnyddir y rheol hon i wirio ffynhonnell multicast gyda thabl llwybro unicast. Mae'n angenrheidiol bod y traffig yn cyrraedd y rhyngwyneb y tu ôl i'r gwesteiwr hwn wedi'i guddio yn ôl y fersiwn o'r tabl llwybro unicast. Mae'r mecanwaith hwn yn datrys problem dolen sy'n digwydd yn ystod trosglwyddiad aml-gast.
R3 из мультикаст сообщения узнает источник мультикаста ( Source IP ) и проверит два потока от R1 и R2 по своей юникастовой таблице. Поток с того интерфейса, на который указывает таблица ( R1 к R3 ), будет передан дальше, а поток от R2 будет дропнут, так как, чтоб добраться до источника мультикаста, надо отправлять пакеты по S0/1.
Y cwestiwn yw, beth sy'n digwydd os oes gennych ddau lwybr cyfatebol gyda'r un metrig? Yn yr achos hwn, bydd y llwybrydd yn dewis yr hop nesaf o'r llwybrau hyn. Pwy bynnag sydd â'r cyfeiriad IP uwch sy'n ennill. Os oes angen i chi newid yr ymddygiad hwn, gallwch ddefnyddio ECMP. Mwy o fanylion .
Ar ôl gwirio'r rheol RPF, mae'r llwybrydd yn anfon pecyn aml-gast at ei holl gymdogion PIM, ac eithrio'r un y derbyniwyd y pecyn ganddo. Mae llwybryddion PIM eraill yn ailadrodd y broses hon. Mae'r llwybr y mae pecyn aml-gastio wedi'i gymryd o'r ffynhonnell i'r derbynwyr terfynol yn ffurfio coeden o'r enw coeden ddosbarthu seiliedig ar ffynhonnell, coeden llwybr byrraf (SPT), coeden ffynhonnell. Tri enw gwahanol, dewiswch unrhyw un.
Sut i ddatrys y broblem na roddodd rhai llwybryddion y gorau iddi ar ryw ffrwd aml-ddarlledu ac nid oes unrhyw un i'w hanfon ato, ond mae'r llwybrydd i fyny'r afon yn ei anfon ato. Dyfeisiwyd y mecanwaith Tocio ar gyfer hyn.
Prune Message.
Например, R2 будет продолжать слать R3 мультикаст, хотя R3 по правилу RPF дропает его. Зачем нагружать канал? R3 шлет PIM Prune Message и R2, при получении данного сообщения, удалит интерфейс S0/1 из списка ( outgoing interface list ) для данного потока, список интерфейсов, с которых надо посылать данный трафик.
Mae'r canlynol yn ddiffiniad mwy ffurfiol o neges Tocio PIM:
The PIM Prune message is sent by one router to a second router to cause the second router to remove the link on which the Prune is received from a particular (S,G) SPT.
После получения Prune сообщения, R2 выставляет Prune таймер в 3 минуты. Через три минуты он начнет отправлять трафик опять, пока не получит очередное Prune сообщение. Это в PIMv1.
Ac yn PIMv2 mae amserydd Diweddaru'r Wladwriaeth wedi'i ychwanegu (60 eiliad yn ddiofyn). Cyn gynted ag y bydd neges Tocio wedi'i hanfon o R3, mae'r amserydd hwn yn cychwyn ar R3. Ar ôl i'r amserydd hwn ddod i ben, bydd R3 yn anfon neges State Refresh, a fydd yn ailosod yr Amserydd Tocio 3 munud ar R2 ar gyfer y grŵp hwn.
Rhesymau dros anfon neges Tocio:
- Pan fydd pecyn aml-ddarllediad yn methu'r gwiriad RPF.
- Pan nad oes unrhyw gleientiaid â chysylltiad lleol sydd wedi gofyn am grŵp aml-gast (IGMP Join) ac nad oes unrhyw gymdogion PIM y gellir anfon traffig aml-gast atynt (Rhyngwyneb Di-docio).
Neges Graft.
Представим, что R3 не захотел трафик от R2, отправил Prune и получал мультикаст от R1. Но вдруг, упал канал между R1-R3 и R3 остался без мультикаста. Можно ждать 3 минуты, пока на R2 не истечет Prune Timer. 3 минуты ждать долго, чтоб не ждать, необходимо послать сообщение, которое моментально выведет данный интерфейс S0/1 на R2 из pruned состояния. Таким сообщением будет Graft сообщение. После получения Graft сообщения, R2 отправит в ответ Graft-ACK.
Tocio Diystyru.
Edrychwn ar y diagram hwn. Mae R1 yn darlledu aml-ddarllediad i segment gyda dau lwybrydd. Mae R3 yn derbyn ac yn darlledu traffig, mae R2 yn derbyn, ond nid oes ganddo unrhyw un i ddarlledu traffig iddo. Mae'n anfon neges Tocio i R1 yn y segment hwn. Dylai R1 dynnu Fa0 / 0 o'r rhestr a rhoi'r gorau i ddarlledu yn y segment hwn, ond beth fydd yn digwydd i R3? Ac mae R3 yn yr un segment, hefyd wedi derbyn y neges hon gan Prune ac yn deall trasiedi'r sefyllfa. Cyn i R1 roi'r gorau i ddarlledu, mae'n gosod amserydd o 3 eiliad a bydd yn rhoi'r gorau i ddarlledu ar ôl 3 eiliad. 3 eiliad - dyma'n union faint o amser sydd gan R3 er mwyn peidio â cholli ei multicast. Felly, mae R3 yn anfon neges Pim Join ar gyfer y grŵp hwn cyn gynted â phosibl, ac nid yw R1 bellach yn meddwl am roi'r gorau i ddarlledu. Ynglŷn â Negeseuon ymuno isod.
Datgan Neges.
Gadewch i ni ddychmygu'r sefyllfa hon: darlledodd dau lwybrydd i un rhwydwaith ar unwaith. Maent yn derbyn yr un ffrwd o'r ffynhonnell, ac mae'r ddau yn ei darlledu i'r un rhwydwaith y tu ôl i ryngwyneb e0. Felly, mae angen iddynt benderfynu pwy fydd yr unig ddarlledwr ar gyfer y rhwydwaith hwn. Defnyddir negeseuon Assert ar gyfer hyn. Pan fydd R2 a R3 yn canfod dyblygu traffig aml-ddarllediad, hynny yw, mae R2 a R3 yn derbyn aml-ddarllediad y maen nhw eu hunain yn ei ddarlledu, mae'r llwybryddion yn deall bod rhywbeth o'i le yma. Yn yr achos hwn, mae llwybryddion yn anfon negeseuon Assert, sy'n cynnwys Pellter Gweinyddol a'r metrig llwybr y cyrhaeddir y ffynhonnell aml-gast ag ef - 10.1.1.10. Pennir yr enillydd fel a ganlyn:
- Yr un ag AD is.
- Os yw AD yn hafal, yna pwy sydd â'r metrig isaf.
- Os oes cydraddoldeb yma, yna'r un sydd â'r IP uwch yn y rhwydwaith y maent yn darlledu'r aml-ddarllediad hwn iddo.
Победивший в этом голосовании, маршрутизатор становится Designated Router-ом. Для выбора DR также используются Pim Hello. В начале статьи было показано PIM Hello сообщение, там можно заметить DR поле. Побеждает тот, у кого выше IP адреса на этом линке.
Arwydd defnyddiol:
Tabl MROUTE.
Ar ôl edrych yn gychwynnol ar sut mae'r protocol PIM yn gweithio, mae angen inni ddeall sut i weithio gyda thabl llwybro aml-gast. Mae tabl mroute yn storio gwybodaeth am ba ffrydiau y gofynnwyd amdanynt gan gleientiaid a pha ffrydiau sy'n llifo o weinyddion aml-ddarlledu.
Er enghraifft, pan dderbynnir Adroddiad Aelodaeth IGMP neu PIM Join ar ryw ryngwyneb, mae cofnod o'r math ( *, G ) yn cael ei ychwanegu at y tabl llwybro:
Данная запись означает, что был получен запрос на трафик с адресом 238.38.38.38. Флаг DC означает, что мультикаст будет работать в режиме Dense mode и С означает, что получатель непосредственно подключен к маршрутизатору, то есть маршрутизатор получил IGMP Membership Report, а PIM Join.
Os oes cofnod o'r math (S,G) mae'n golygu bod gennym ni ffrwd aml-ddarlledu:
В поле S — 192.168.1.11, у нас прописан IP адрес источника мультикаста, именно он будет проверяться правилом RPF. При проблемах, первым делом необходимо проверить юникастовую таблицу на маршрут к источнику. В поле Incoming Interface указывает интерфейс, на который поступает мультикаст. В юникастовой таблице маршрутизации, маршрут до источника должен ссылаться на интерфейс, указанный здесь. В Outgoing Interface указывается куда будет мультикаст перенаправлен. Если он пуст, значит к маршрутизатору не поступало запросов на данный трафик. Более подробную информацию о всех флагах можно найти .
PIM Modd gwasgarog.
Mae strategaeth y modd gwasgaredig i'r gwrthwyneb i'r modd Trwchus. Pan fydd modd gwasgaredig yn derbyn traffig aml-ddarllediad, ni fydd ond yn anfon traffig trwy'r rhyngwynebau hynny lle roedd ceisiadau am y llif hwn, er enghraifft negeseuon Pim Join neu IGMP Report yn gofyn am y traffig hwn.
Elfennau tebyg ar gyfer SM a DM:
- Mae perthnasoedd cymdogaeth yn cael eu hadeiladu yn yr un ffordd ag yn PIM DM.
- Mae rheol yr RPF yn gweithio.
- Mae'r dewis DR yn debyg.
- Mae mecanwaith y negeseuon Tocio Diystyru a Mynnu yn debyg.
Er mwyn rheoli pwy, ble a pha fath o draffig aml-ddarllediad sydd ei angen ar y rhwydwaith, mae angen canolfan wybodaeth gyffredin. Ein canolfan fydd Rendezvous Point (RP). Dylai unrhyw un sydd eisiau rhyw fath o draffig aml-gastio neu rywun ddechrau derbyn traffig aml-gastio o'r ffynhonnell, yna mae'n ei anfon at RP.
Когда RP получит мультикаст трафик, то отправит его тем маршрутизаторам, которые запросили до этого этот трафик.
Gadewch i ni ddychmygu topoleg lle mae RP yn R3. Cyn gynted ag y bydd R1 yn derbyn traffig o S1, mae'n crynhoi'r pecyn aml-gastio hwn i mewn i neges Cofrestr PIM unicast a'i anfon at RP. Sut mae'n gwybod pwy yw'r RP? Yn yr achos hwn, mae wedi'i ffurfweddu'n statig, a byddwn yn siarad am gyfluniad RP deinamig yn ddiweddarach.
ip pim rp-address 3.3.3.3
Bydd RP yn edrych - a oedd yna wybodaeth gan rywun a hoffai dderbyn y traffig hwn? Gadewch i ni dybio nad oedd. Yna bydd RP yn anfon neges Cofrestru-Stop PIM i R1, sy'n golygu nad oes angen y multicast hwn ar unrhyw un, gwrthodir cofrestriad. Ni fydd R1 yn anfon multicast. Ond bydd y gwesteiwr ffynhonnell multicast yn ei anfon, fel y bydd R1, ar ôl derbyn Register-Stop, yn cychwyn amserydd Cofrestru-Atal sy'n hafal i 60 eiliad. 5 eiliad cyn i'r amserydd hwn ddod i ben, bydd R1 yn anfon neges Gofrestr wag gyda did Null-Register (hynny yw, heb becyn aml-gastio wedi'i amgáu) tuag at RP. Bydd RP, yn ei dro, yn gweithredu fel hyn:
- Os nad oedd unrhyw dderbynwyr, yna bydd yn ymateb gyda neges Cofrestru-Stop.
- Os bydd derbynwyr yn ymddangos, ni fydd yn ymateb iddo mewn unrhyw ffordd. Bydd R1, ar ôl peidio â derbyn gwrthodiad i gofrestru o fewn 5 eiliad, yn hapus ac yn anfon neges Cofrestr gyda multicast wedi'i amgáu i RP.
Как мультикаст доходит до RP вроде бы разобрались, теперь попытаемся ответить на вопрос как RP доводит трафик до получателей. Здесь необходимо ввести новое понятие — root-path tree (RPT). RPT — это дерево с корнем в RP, растущее в сторону получателей, разветвляющиеся на каждом PIM-SM маршрутизаторе. RP создает его, получая PIM Join сообщения и добавляет в дерево новую ветвь. И так, делает каждый нижестоящий маршрутизатор. Общее правило выглядит так:
- Когда PIM-SM маршрутизатор получает PIM Join сообщение на каком-либо интерфейсе, за исключением интерфейса за котором скрывается RP, он добавляет в дерево новую ветвь.
- Также ветвь добавляется, когда PIM-SM маршрутизатор получает IGMP Membership Report с непосредственно подключенного хоста.
Gadewch i ni ddychmygu bod gennym gleient multicast ar y llwybrydd R5 ar gyfer grŵp 228.8.8.8. Cyn gynted ag y bydd R5 yn derbyn Adroddiad Aelodaeth IGMP gan y gwesteiwr, mae R5 yn anfon PIM Ymunwch i gyfeiriad y RP, ac mae ei hun yn ychwanegu rhyngwyneb i'r goeden sy'n edrych ar y gwesteiwr. Nesaf, mae R4 yn derbyn PIM Join o R5, yn ychwanegu rhyngwyneb Gi0 / 1 i'r goeden ac yn anfon PIM Join i gyfeiriad RP. Yn olaf, mae RP ( R3 ) yn derbyn PIM Join ac yn ychwanegu Gi0/0 at y goeden. Felly, mae'r derbynnydd multicast wedi'i gofrestru. Rydym yn adeiladu coeden gyda'r gwraidd R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
После этого, будет отправлен PIM Join к R1 и R1 начнет слать мультикаст трафик. Важно заметить, что если хост запросил трафик до того, как началось вещание мультикаста, то RP не будет отправлять PIM Join и вообще не будет ничего отправлять в строну R1.
Os yn sydyn tra bod multicast yn cael ei anfon, mae'r gwesteiwr yn peidio â bod eisiau ei dderbyn, cyn gynted ag y bydd RP yn derbyn PIM Prune ar ryngwyneb Gi0/0, bydd yn anfon Cofrestr-Stop PIM yn syth i R1, ac yna Tocio PIM neges trwy'r rhyngwyneb Gi0/1. Anfonir PIM Register-stop trwy unicast i'r cyfeiriad y daeth y Gofrestr PIM ohono.
Fel y dywedasom yn gynharach, cyn gynted ag y bydd llwybrydd yn anfon PIM Join i un arall, er enghraifft R5 i R4, yna ychwanegir cofnod at R4:
И запускается таймер, что сбросить данный таймер R5 должен постоянно PIM Join сообщения постоянно, а то R4 исключит из outgoing list. R5 будет отправлять каждые 60 PIM Join сообщения.
Byrraf - Trosglwyddiad Coed Llwybr.
Byddwn yn ychwanegu rhyngwyneb rhwng R1 a R5 ac yn gweld sut mae traffig yn llifo gyda'r topoleg hon.
Gadewch i ni dybio bod traffig wedi'i anfon a'i dderbyn yn ôl yr hen gynllun R1-R2-R3-R4-R5, ac yma fe wnaethom gysylltu a ffurfweddu'r rhyngwyneb rhwng R1 a R5.
Yn gyntaf oll, mae'n rhaid i ni ailadeiladu'r tabl llwybro unicast ar R5 a nawr mae'r rhwydwaith 192.168.1.0 / 24 yn cael ei gyrraedd trwy ryngwyneb R5 Gi0 / 2. Nawr mae R5, sy'n derbyn multicast ar ryngwyneb Gi0/1, yn deall nad yw'r rheol RPF yn fodlon ac y byddai'n fwy rhesymegol derbyn aml-ddarllediad ar Gi0/2. Dylai ddatgysylltu oddi wrth RPT ac adeiladu coeden fyrrach o'r enw Shortest-Path Tree (SPT). I wneud hyn, mae'n anfon PIM Join i R0 trwy Gi2/1 ac mae R1 yn dechrau anfon multicast hefyd trwy Gi0/2. Nawr mae angen i R5 ddad-danysgrifio o RPT er mwyn peidio â derbyn dau gopi. I wneud hyn, mae'n anfon neges Tocio yn nodi'r cyfeiriad IP ffynhonnell ac yn mewnosod darn arbennig - RPT-bit. Mae hyn yn golygu nad oes angen i chi anfon traffig ataf, mae gen i goeden well yma. Mae RP hefyd yn anfon negeseuon PIM Prune i R1, ond nid yw'n anfon neges Cofrestru-Stop. Nodwedd arall: Bydd R5 nawr yn anfon PIM Prune i RP yn barhaus, gan fod R1 yn parhau i anfon Cofrestr PIM i RP bob munud. Hyd nes nad oes unrhyw bobl newydd eisiau'r traffig hwn, bydd RP yn ei wrthod. Mae R5 yn hysbysu RP ei fod yn parhau i dderbyn aml-ddarllediad trwy SPT.
Динамический поиск RP.
Auto-RP.
Данная технология является проприетарной от Cisco и не пользуется особой популярной, но все еще жива. Работа Auto-RP состоит из двух основных этапов:
1) Mae RP yn anfon negeseuon RP-Cyhoeddi i'r cyfeiriad neilltuedig - 224.0.1.39, gan ddatgan ei hun yn RP naill ai i bawb neu ar gyfer grwpiau penodol. Anfonir y neges hon bob munud.
2) Необходим RP mapping agent, который будет слать RP-Discovery сообщения с указанием для каких групп какой RP необходимо слушать. Именно из этого сообщения, обычные PIM маршрутизаторы будут определять для себя RP. Mapping Agent может быть как сам RP маршрутизатор, так и какой-либо отдельный PIM маршрутизатор. RP-Discovery отправляется на адрес 224.0.1.40 c таймером в одну минуту.
Посмотрим на процесс поподробнее:
Gadewch i ni ffurfweddu R3 fel RP:
ip pim anfon-rp-cyhoeddi loopback 0 cwmpas 10
R2 fel asiant mapio:
ip pim anfon-rp-darganfod loopback 0 cwmpas 10
Ac ar bob un arall byddwn yn disgwyl RP trwy Auto-RP:
ip pim gwrandäwr autorp
Ar ôl i ni ffurfweddu R3, bydd yn dechrau anfon RP-Announce:
A bydd R2, ar ôl sefydlu'r asiant mapio, yn dechrau aros am y neges RP-Announce. Dim ond pan fydd yn dod o hyd i o leiaf un RP y bydd yn dechrau anfon RP-Discovery:
Fel hyn, cyn gynted ag y bydd llwybryddion rheolaidd (PIM RP Listener) yn derbyn y neges hon, byddant yn gwybod ble i chwilio am yr RP.
Un o'r prif broblemau gyda Auto-RP yw, er mwyn derbyn negeseuon RP-Announce a RP-Discovery, mae angen i chi anfon PIM Join i gyfeiriadau 224.0.1.39-40, ac er mwyn anfon, mae angen i chi wybod ble mae'r Mae RP wedi'i leoli. Problem cyw iâr ac wy clasurol. I ddatrys y broblem hon, dyfeisiwyd y PIM Sparse-Dense-Mode. Os nad yw'r llwybrydd yn gwybod RP, yna mae'n gweithredu yn y modd Trwchus; os ydyw, yna yn y modd Tenau. Pan fydd PIM Sparse-mod a'r gorchymyn gwrandäwr ip pim autorp yn cael eu ffurfweddu ar ryngwynebau llwybryddion rheolaidd, bydd y llwybrydd yn gweithredu mewn modd Trwchus yn unig ar gyfer aml-ddarlledu yn uniongyrchol o'r protocol Auto-RP (224.0.1.39-40).
Llwybrydd BootStrap (BSR).
Mae'r swyddogaeth hon yn gweithio'n debyg i Auto-RP. Mae pob RP yn anfon neges at yr asiant mapio, sy'n casglu gwybodaeth fapio ac yna'n dweud wrth bob llwybrydd arall. Gadewch i ni ddisgrifio'r broses yn yr un modd ag Auto-RP:
1) Как только мы настроим R3 в качестве кандидата быть RP, командой:
ip pim rp-ymgeisydd loopback 0
Yna ni fydd R3 yn gwneud unrhyw beth; er mwyn dechrau anfon negeseuon arbennig, yn gyntaf mae angen iddo ddod o hyd i asiant mapio. Felly, symudwn ymlaen at yr ail gam.
2) Настраиваем R2 как mapping agent:
ip pim bsr-ymgeisydd loopback 0
Mae R2 yn dechrau anfon negeseuon PIM Bootstrap, lle mae'n nodi ei hun fel asiant mapio:
Anfonir y neges hon i'r cyfeiriad 224.0.013, y mae'r protocol PIM hefyd yn ei ddefnyddio ar gyfer ei negeseuon eraill. Mae'n eu hanfon i bob cyfeiriad ac felly nid oes problem cyw iâr ac wy fel yr oedd yn Auto-RP.
3) Cyn gynted ag y bydd yr RP yn derbyn neges gan y llwybrydd BSR, bydd yn anfon neges unicast ar unwaith i gyfeiriad llwybrydd BSR:
После чего, BSR получив информацию о RP, разошлет их мультикастом на адрес 224.0.0.13, который слушают все PIM маршрутизаторы. Поэтому, аналога команды ip pim gwrandäwr autorp для обычных маршрутизаторов нет в BSR.
Anycast RP gyda Multicast Source Discovery Protocol (MSDP).
Auto-RP и BSR нам позволяют распредилить нагрузку на RP следующим образом: У каждой мультикаст группы есть только один активный RP. Не получится сделать распределение нагрузки для одной мультикаст группы несколько RP. MSDP делает это при помощи выдачи RP маршрутизаторам одинакового ip адреса с маской 255.255.255.255. MSDP узнает информацию при помощи одного из методов: статики, Auto-RP или BSR.
Yn y llun mae gennym gyfluniad Auto-RP gyda MSDP. Mae'r ddau RP wedi'u ffurfweddu gyda chyfeiriad IP 172.16.1.1/32 ar ryngwyneb Loopback 1 ac fe'i defnyddir ar gyfer pob grŵp. Gyda RP-Announce, mae'r ddau lwybrydd yn cyhoeddi eu hunain trwy gyfeirio at y cyfeiriad hwn. Mae'r asiant mapio Auto-RP, ar ôl derbyn y wybodaeth, yn anfon RP-Discovery am yr RP gyda'r cyfeiriad 172.16.1.1/32. Rydyn ni'n dweud wrth lwybryddion am y rhwydwaith 172.16.1.1/32 gan ddefnyddio IGP ac, yn unol â hynny. Felly, mae llwybryddion PIM yn gofyn neu'n cofrestru llif o'r RP a nodir fel y hop nesaf ar y llwybr i'r rhwydwaith 172.16.1.1/32. Mae'r protocol MSDP ei hun wedi'i gynllunio i'r RPs eu hunain gyfnewid negeseuon am wybodaeth aml-ddarllediad.
Ystyriwch y topoleg hon:
Switch6 вещает трафик на адрес 238.38.38.38 и о нем пока знает только RP-R1. Вот Switch7 и Switch8 запросили данную группу. Маршрутизаторы R5 и R4 отправят PIM Join на R1 и R3, соответственно. Почему? Маршрут до 13.13.13.13 у R5 будет ссылаться на R1 по метрике IGP, как и у R4.
Mae RP-R1 yn gwybod am y ffrwd a bydd yn dechrau ei ddarlledu tuag at R5, ond nid yw R4 yn gwybod dim amdano, gan na fydd R1 yn ei anfon yn syml. Felly mae MSDP yn angenrheidiol. Rydym yn ei ffurfweddu ar R1 a R5:
ip msdp cyfoedion 3.3.3.3 connect-source Loopback1 ar R1
ip msdp cyfoedion 1.1.1.1 connect-source Loopback3 ar R3
Byddant yn codi sesiwn rhwng ei gilydd ac wrth dderbyn unrhyw lif byddant yn ei adrodd i'w cymydog RP.
Cyn gynted ag y bydd RP-R1 yn derbyn ffrwd o Switch6, bydd yn anfon neges Unicast MSDP Source-Active ar unwaith, a fydd yn cynnwys gwybodaeth fel (S, G) - gwybodaeth am ffynhonnell a chyrchfan y multicast. Nawr bod RP-R3 yn gwybod bod ffynhonnell fel Switch6, wrth dderbyn cais gan R4 am y llif hwn, bydd yn anfon PIM Join tuag at Switch6, dan arweiniad y tabl llwybro. O ganlyniad, bydd R1 ar ôl derbyn PIM Join o'r fath yn dechrau anfon traffig tuag at RP-R3.
MSDP работает по TCP, RP посылают друг другу keepalive сообщения для проверки жизнеспособности. Таймер равен 60 cекундам.
Остается непонятной функция разделения MSDP пиров в различные домены, так как в сообщениях Keepalive и SA не указывается принадлежность какому-либо домену. Также в данной топологии тестировалась конфигурация с указанием различных доменов — разницы в работе не было.
Os gall unrhyw un egluro, byddwn yn hapus i'w ddarllen yn y sylwadau.
Ffynhonnell: hab.com