PIM протокол хэрхэн ажилладаг

PIM протокол нь чиглүүлэгчдийн хооронд сүлжээнд олон дамжуулалтыг дамжуулах протоколуудын багц юм. Хөршүүдийн харилцааг динамик чиглүүлэлтийн протоколуудтай адил аргаар байгуулдаг. PIMv2 нь 30 (Бүх PIM-чиглүүлэгч) хаяг руу 224.0.0.13 секунд тутамд Сайн байна уу мессежийг илгээдэг. Уг мессеж нь Hold Timers-ийг агуулдаг - ихэвчлэн 3.5*Hello Timer-тай тэнцүү буюу анхдагчаар 105 секунд.

PIM нь нягт ба сийрэг горим гэсэн хоёр үндсэн горимыг ашигладаг. Нягт горимоос эхэлцгээе.
Эх сурвалжид суурилсан тархалтын мод.
Өтгөн горимын горимыг янз бүрийн multicast бүлгүүдийн олон тооны үйлчлүүлэгчид ашиглахыг зөвлөж байна. Чиглүүлэгч multicast урсгалыг хүлээн авах үед хамгийн түрүүнд хийх зүйл бол RPF дүрмийг шалгах явдал юм. RPF - энэ дүрмийг unicast чиглүүлэлтийн хүснэгтээр олон дамжуулалтын эх сурвалжийг шалгахад ашигладаг. Траффик нь unicast чиглүүлэлтийн хүснэгтийн хувилбарын дагуу энэ хостыг нуусан интерфейс дээр ирэх шаардлагатай. Энэ механизм нь олон дамжуулалт дамжуулах үед үүссэн гогцооны асуудлыг шийддэг.

R3 нь олон дамжуулалтын эх сурвалжийг (Source IP) multicast мессежээс таньж, R1 ба R2-ын хоёр урсгалыг өөрийн unicast хүснэгт ашиглан шалгана. Хүснэгтэнд заасан интерфэйсээс (R1-ээс R3) дамжуулж буй урсгал цаашид дамжих ба R2-ээс гарах урсгал тасрах болно, учир нь олон дамжуулалтын эх үүсвэрт очихын тулд S0/1-ээр пакет илгээх шаардлагатай.
Асуулт нь, хэрэв танд ижил хэмжигдэхүүнтэй хоёр тэнцүү маршрут байвал яах вэ? Энэ тохиолдолд чиглүүлэгч эдгээр маршрутуудаас дараагийн хопыг сонгох болно. Хэн өндөр IP хаягтай бол тэр ялна. Хэрэв та энэ зан үйлийг өөрчлөх шаардлагатай бол ECMP ашиглаж болно. Илүү дэлгэрэнгүй мэдээллийг энд.
RPF дүрмийг шалгасны дараа чиглүүлэгч нь пакет хүлээн авсанаас бусад бүх PIM хөрш рүү multicast пакет илгээдэг. Бусад PIM чиглүүлэгчид энэ үйл явцыг давтана. Олон дамжуулалтын багцын эх сурвалжаас эцсийн хүлээн авагч хүртэлх зам нь эх сурвалжид суурилсан түгээлтийн мод, хамгийн богино замын мод (SPT), эх мод гэж нэрлэгддэг модыг үүсгэдэг. Гурван өөр нэр, аль нэгийг нь сонгоно уу.
Зарим чиглүүлэгчид олон дамжуулагч дамжуулалтаас татгалзаагүй бөгөөд үүнийг илгээх хүн байхгүй, харин дээд талын чиглүүлэгч нь түүн рүү илгээдэг асуудлыг хэрхэн шийдвэрлэх вэ. Үүний тулд Prune механизмыг зохион бүтээсэн.
Prune мессеж.
Жишээлбэл, R2 нь RPF дүрмийн дагуу R3 үүнийг хассан ч R3 руу multicast илгээсээр байх болно. Яагаад сувгийг ачаалах вэ? R3 нь PIM Prune Message илгээдэг бөгөөд R2 нь энэ мессежийг хүлээн авмагц S0/1 интерфэйсийг энэ урсгалын гарах интерфэйсийн жагсаалтаас, энэ урсгалыг илгээх интерфэйсүүдийн жагсаалтаас хасах болно.

Дараах нь PIM Prune мессежийн илүү албан ёсны тодорхойлолт юм.
PIM Prune мессежийг нэг чиглүүлэгчээр хоёр дахь чиглүүлэгч рүү илгээж, хоёр дахь чиглүүлэгч нь тодорхой (S,G) SPT-ээс Prune хүлээн авсан холбоосыг арилгахад хүргэдэг.

Prune мессежийг хүлээн авсны дараа R2 нь Prune таймерыг 3 минут болгож тохируулна. Гурван минутын дараа энэ нь өөр Prune мессеж хүлээн авах хүртэл урсгалыг дахин илгээж эхэлнэ. Энэ нь PIMv1 дээр байна.
Мөн PIMv2-д State Refresh таймер нэмэгдсэн (анхдагчаар 60 секунд). R3-аас Prune мессеж илгээгдсэн даруйд энэ таймер R3 дээр эхэлнэ. Энэ таймерын хугацаа дууссаны дараа R3 нь State Refresh мессеж илгээх бөгөөд энэ нь R3 дээрх 2 минутын Prune Timer-ыг энэ бүлгийн хувьд дахин тохируулах болно.
Prune мессеж илгээх шалтгаанууд:

• Multicast пакет амжилтгүй болвол RPF шалгана.
• Multicast групп (IGMP Join) хүссэн орон нутагт холбогдсон үйлчлүүлэгч байхгүй ба олон дамжуулалт илгээх боломжтой PIM хөрш байхгүй үед (Prune бус интерфэйс).

Graft мессеж.
R3 R2-ээс урсгалыг хүсээгүй, Prune-г илгээж, R1-ээс multicast хүлээн авсан гэж төсөөлөөд үз дээ. Гэтэл гэнэт R1-R3 хоорондох суваг унаж, R3 олон дамжуулалтгүй үлдэв. R3 дээрх Prune Timer-ын хугацаа дуусах хүртэл та 2 минут хүлээх боломжтой. 3 минут бол удаан хүлээх тул хүлээхгүйн тулд та S0/1 интерфэйсийг R2 руу тайрах төлөвөөс шууд гаргах мессеж илгээх хэрэгтэй. Энэ зурвас Graft мессеж байх болно. Graft мессежийг хүлээн авсны дараа R2 Graft-ACK-ээр хариу өгөх болно.
Prune Override.

Энэ диаграммыг харцгаая. R1 нь хоёр чиглүүлэгчтэй сегмент рүү multicast цацдаг. R3 нь траффик хүлээн авч, цацдаг, R2 нь хүлээн авдаг, гэхдээ траффик дамжуулах хүн байхгүй. Энэ сегмент дэх R1 рүү Prune мессеж илгээдэг. R1 жагсаалтаас Fa0/0-ыг хасч, энэ сегмент дэх цацалтыг зогсоох ёстой, гэхдээ R3-д юу тохиолдох вэ? Мөн R3 нь ижил сегментэд байгаа бөгөөд энэ мессежийг Prune-ээс хүлээн авч, нөхцөл байдлын эмгэнэлт байдлыг ойлгосон. R1 цацахаа зогсоохоос өмнө 3 секундын таймер тохируулдаг бөгөөд 3 секундын дараа цацалтаа зогсооно. 3 секунд - энэ нь R3-д олон дамжуулалтаа алдахгүйн тулд яг хичнээн цаг хугацаа зарцуулдаг. Тиймээс R3 энэ бүлэгт Pim Join мессежийг аль болох хурдан илгээдэг бөгөөд R1 нэвтрүүлгээ зогсоох талаар бодохоо больсон. Доорх нэгдэх мессежийн талаар.
Зурвасыг баталгаажуулах.

Энэ нөхцөл байдлыг төсөөлөөд үз дээ: хоёр чиглүүлэгч нэг сүлжээнд нэгэн зэрэг цацдаг. Тэд эх сурвалжаас ижил урсгалыг хүлээн авдаг бөгөөд хоёулаа e0 интерфэйсийн ард ижил сүлжээнд цацдаг. Тиймээс тэд энэ сүлжээний цорын ганц нэвтрүүлэгч нь хэн болохыг тодорхойлох хэрэгтэй. Үүний тулд баталгаажуулах мессежийг ашигладаг. R2 ба R3 нь олон дамжуулалтын траффикийн давхардлыг илрүүлэхэд, өөрөөр хэлбэл R2 ба R3 дээр олон дамжуулалт ирж, өөрсдөө цацдаг бол чиглүүлэгчид энд ямар нэг зүйл буруу байгааг ойлгодог. Энэ тохиолдолд чиглүүлэгчид Захиргааны зай болон олон дамжуулалтын эх үүсвэрт хүрэх маршрутын хэмжигдэхүүнийг багтаасан Assert мессежийг илгээдэг - 10.1.1.10. Ялагчийг дараах байдлаар тодруулна.

1. AD багатай.
2. Хэрэв AD тэнцүү бол хэн нь доод хэмжигдэхүүнтэй байна.
3. Хэрэв энд тэгш байдал байгаа бол энэ олон дамжуулалтыг дамжуулж буй сүлжээнд өндөр IP-тэй хүн байна.

Энэ саналын ялагч нь Зориулалтын чиглүүлэгч болно. Pim Hello нь мөн DR сонгоход хэрэглэгддэг. Өгүүллийн эхэнд PIM Hello мессежийг харуулсан бөгөөд та тэнд DR талбарыг харж болно. Энэ холбоос дээрх хамгийн өндөр IP хаягтай нь ялна.
Ашигтай тэмдэг:

MROUTE Хүснэгт.
PIM протокол хэрхэн ажилладаг талаар анх харсны дараа бид олон дамжуулалтын чиглүүлэлтийн хүснэгттэй хэрхэн ажиллахыг ойлгох хэрэгтэй. Mroute хүснэгт нь үйлчлүүлэгчдээс ямар урсгалыг хүссэн, олон дамжуулалт серверээс ямар урсгал урсаж байгаа талаарх мэдээллийг хадгалдаг.
Жишээлбэл, зарим интерфэйс дээр IGMP гишүүнчлэлийн тайлан эсвэл PIM нэгдлийг хүлээн авах үед ( *, G ) төрлийн бичлэгийг чиглүүлэлтийн хүснэгтэд нэмнэ:

Энэ оруулга нь замын хөдөлгөөний хүсэлтийг 238.38.38.38 хаягаар хүлээн авсан гэсэн үг юм. DC туг нь multicast нь Desen горимд ажиллах ба C нь хүлээн авагч нь чиглүүлэгчтэй шууд холбогдсон, өөрөөр хэлбэл чиглүүлэгч нь IGMP гишүүнчлэлийн тайлан болон PIM Join-ийг хүлээн авсан гэсэн үг юм.
Хэрэв (S,G) төрлийн бичлэг байгаа бол бид олон дамжуулалттай байна гэсэн үг:

S талбарт - 192.168.1.11 бид олон дамжуулалтын эх үүсвэрийн IP хаягийг бүртгэсэн бөгөөд үүнийг RPF дүрмээр шалгах болно. Хэрэв асуудал гарвал хамгийн түрүүнд хийх ёстой зүйл бол эх сурвалж руу хүрэх маршрутыг unicast хүснэгтээс шалгах явдал юм. Incoming Interface талбарт multicast хүлээн авах интерфейсийг заана. Unicast чиглүүлэлтийн хүснэгтэд эх сурвалж руу хүрэх зам нь энд заасан интерфейстэй холбоотой байх ёстой. Гарах интерфэйс нь олон дамжуулалтыг хаашаа дахин чиглүүлэхийг зааж өгдөг. Хэрэв энэ нь хоосон бол чиглүүлэгч энэ траффикийн хүсэлтийг хүлээж аваагүй болно. Бүх тугны талаарх дэлгэрэнгүй мэдээллийг авах боломжтой энд.
PIM сийрэг горим.
Sparse горимын стратеги нь өтгөн горимын эсрэг юм. Sparse-mode нь олон дамжуулалтын урсгалыг хүлээн авах үед энэ урсгалыг хүссэн интерфэйсүүдээр дамжуулан зөвхөн урсгалыг илгээх болно, жишээ нь Pim Join эсвэл IGMP Report мессежүүд нь энэ урсгалыг хүссэн.
SM болон DM-ийн ижил төстэй элементүүд:

• Хөршийн харилцаа нь МХХ-ны ДМ-тэй ижил аргаар бий болдог.
• RPF дүрэм ажилладаг.
• DR сонголт нь ижил төстэй байна.
• Prune Overrides болон Assert мессежийн механизм нь ижил төстэй.

Сүлжээнд хэн, хаана, ямар олон дамжуулалт хэрэгтэй байгааг хянахын тулд нэгдсэн мэдээллийн төв хэрэгтэй. Манай төв нь Rendezvous Point (RP) байх болно. Ямар нэгэн төрлийн multicast урсгалыг хүссэн эсвэл хэн нэгэн эх сурвалжаас multicast урсгалыг хүлээн авч эхэлсэн бол тэр үүнийг RP руу илгээдэг.
RP нь олон дамжуулалтын траффик хүлээн авахдаа энэ урсгалыг өмнө нь хүссэн чиглүүлэгч рүү илгээх болно.

RP нь R3 байх топологийг төсөөлье. R1 нь S1-ээс траффик хүлээн авмагц энэ олон дамжуулалтын пакетыг unicast PIM Бүртгэлийн мессеж болгон багтааж, RP руу илгээдэг. Тэр РП гэж хэн болохыг яаж мэдэх вэ? Энэ тохиолдолд энэ нь статик байдлаар тохируулагдсан бөгөөд бид дараа нь динамик RP тохиргооны талаар ярих болно.

ip pim rp-хаяг 3.3.3.3

RP харах болно - энэ урсгалыг хүлээн авахыг хүссэн хүнээс мэдээлэл байсан уу? Тийм биш байсан гэж бодъё. Дараа нь RP R1-д PIM Register-Stop мессеж илгээх бөгөөд энэ нь хэнд ч энэ multicast хэрэггүй, бүртгэлээс татгалзсан гэсэн үг юм. R1 нь олон дамжуулалт илгээхгүй. Гэхдээ олон дамжуулалтын эх сурвалжийн хост үүнийг илгээх бөгөөд ингэснээр R1 нь Бүртгүүлэх-Стопыг хүлээн авсны дараа 60 секундтэй тэнцэх Бүртгэлийг дарах таймерыг эхлүүлэх болно. Энэ таймер дуусахаас 5 секундын өмнө R1 нь Null-Register биттэй (өөрөөр хэлбэл капсуллагдсан multicast пакетгүй) хоосон Бүртгэлийн мессежийг RP руу илгээнэ. RP нь эргээд дараах байдлаар ажиллах болно.

• Хэрэв хүлээн авагч байхгүй байсан бол энэ нь Бүртгүүлэх-Стоп мессежээр хариулах болно.
• Хэрэв хүлээн авагчид гарч ирвэл тэр ямар ч байдлаар хариу өгөхгүй. 1 секундын дотор бүртгүүлэхээс татгалзсан хариу аваагүй R5 баярлаж, Бүртгэлийн мессежийг RP руу илгээнэ.

Бид multicast хэрхэн RP хүрдгийг олж мэдсэн бололтой, одоо RP нь хүлээн авагчдад траффик хэрхэн хүргэдэг вэ гэсэн асуултад хариулахыг хичээцгээе. Энд шинэ ойлголтыг нэвтрүүлэх шаардлагатай байна - root-path tree (RPT). RPT нь PIM-SM чиглүүлэгч бүр дээр салбарлаж, хүлээн авагч руу чиглэсэн RP-д үндэслэсэн мод юм. RP нь PIM Join мессежийг хүлээн авах замаар үүнийг үүсгэж, модонд шинэ салбар нэмнэ. Тиймээс, доод чиглүүлэгч бүр үүнийг хийдэг. Ерөнхий дүрэм дараах байдалтай байна.

• PIM-SM чиглүүлэгч нь RP нуугдсан интерфэйсээс өөр ямар ч интерфэйс дээр PIM Join мессежийг хүлээн авах үед энэ нь модонд шинэ салбар нэмнэ.
• PIM-SM чиглүүлэгч нь шууд холбогдсон хостоос IGMP гишүүнчлэлийн тайланг хүлээн авах үед салбар нэмэгдэнэ.

Бид R5 чиглүүлэгч дээр 228.8.8.8 бүлэгт зориулсан олон дамжуулагч үйлчлүүлэгчтэй байна гэж төсөөлөөд үз дээ. R5 нь хостоос IGMP гишүүнчлэлийн тайланг хүлээн авмагц R5 нь RP-ийн чиглэлд PIM Join илгээдэг бөгөөд өөрөө хост руу хардаг мод руу интерфейс нэмдэг. Дараа нь R4 R5-аас PIM Join-г хүлээн авч, мод руу Gi0/1 интерфэйсийг нэмж, RP-ийн чиглэлд PIM Join илгээдэг. Эцэст нь RP ( R3 ) нь PIM Join-ийг хүлээн авч, мод руу Gi0/0 нэмнэ. Тиймээс multicast хүлээн авагч бүртгэгдсэн байна. Бид R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0 үндэстэй модыг барьж байна.
Үүний дараа PIM Join R1 рүү илгээгдэх ба R1 нь олон дамжуулалтын урсгалыг илгээж эхэлнэ. Хэрэв олон дамжуулалт эхлэхээс өмнө хост урсгалыг хүссэн бол RP нь PIM Join илгээхгүй бөгөөд R1 рүү юу ч илгээхгүй гэдгийг анхаарах нь чухал.
Хэрэв multicast илгээгдэж байх үед гэнэт хост хүлээн авахаа больсон бол RP нь Gi0/0 интерфэйс дээр PIM Prune хүлээн авмагц тэр даруй R1 рүү PIM Бүртгэлийг зогсоож, дараа нь PIM Prune илгээнэ. Gi0/1 интерфейсээр дамжуулан мессеж илгээх. МХХ бүртгэлийн бүртгэлийг ирсэн хаяг руу Unicast-аар илгээдэг.
Өмнө дурьдсанчлан, чиглүүлэгч өөр рүү, жишээлбэл R5-аас R4 рүү PIM холболтыг илгээмэгц R4-д бичлэг нэмэгдэнэ.

Мөн R5 нь энэ таймерыг PIM-д байнга нэгтгэх ёстой гэсэн таймерыг эхлүүлсэн, эс тэгвээс R4 нь гарах жагсаалтаас хасагдах болно. R5 нь 60 PIM Join мессеж бүрийг илгээх болно.
Хамгийн богино зам мод шилжих.
Бид R1 болон R5 хооронд интерфэйс нэмж, энэ топологийн тусламжтайгаар урсгал хэрхэн урсаж байгааг харах болно.

Хуучин R1-R2-R3-R4-R5 схемийн дагуу урсгалыг илгээж, хүлээн авсан гэж үзье, энд бид R1 ба R5 хоорондын интерфейсийг холбож, тохируулсан.
Юуны өмнө бид R5 дээр Unicast чиглүүлэлтийн хүснэгтийг дахин бүтээх ёстой бөгөөд одоо 192.168.1.0/24 сүлжээнд R5 Gi0/2 интерфейсээр холбогдож байна. Одоо Gi5/0 интерфэйс дээр multicast хүлээн авч байгаа R1 нь RPF дүрэм хангагдаагүй гэдгийг ойлгож байгаа бөгөөд Gi0/2 дээр multicast хүлээн авах нь илүү логик байх болно. Энэ нь RPT-ээс салж, хамгийн богино зам мод (SPT) хэмээх богино модыг барих ёстой. Үүний тулд тэрээр Gi0/2-оор дамжуулан PIM Join-ийг R1 рүү илгээж, R1 нь Gi0/2-ээр дамжуулан олон дамжуулалтыг илгээж эхэлдэг. Одоо R5 хоёр хуулбарыг хүлээн авахгүйн тулд RPT-ээс бүртгэлээ цуцлах шаардлагатай байна. Үүнийг хийхийн тулд тэрээр Prune руу эх сурвалжийн IP хаягийг зааж, тусгай бит - RPT-бит оруулах мессежийг илгээдэг. Энэ нь та надад замын хөдөлгөөн илгээх шаардлагагүй, надад илүү сайн мод байна гэсэн үг юм. RP нь мөн PIM Prune мессежийг R1 рүү илгээдэг боловч Бүртгүүлэх-Stop мессеж илгээдэггүй. Өөр нэг онцлог: R5 PIM бүртгэлийг минут тутамд RP руу илгээсээр байгаа тул R1 одоо PIM Prune-г RP руу тасралтгүй илгээх болно. Энэ урсгалыг хүсч буй шинэ хүмүүс байхгүй болтол РП татгалзах болно. R5 нь RP-д SPT-ээр дамжуулан олон дамжуулалтыг хүлээн авсаар байгаагаа мэдэгддэг.
Динамик RP хайлт.
Автомат RP.
Энэ технологи нь Cisco-ийн өмч бөгөөд тийм ч алдартай биш боловч амьд хэвээр байна. Auto-RP ажиллагаа нь хоёр үндсэн үе шатаас бүрдэнэ.
1) RP нь RP-Announce мессежийг нөөцлөгдсөн хаяг - 224.0.1.39 руу илгээж, өөрийгөө хүн бүрт эсвэл тодорхой бүлэгт зориулж RP гэж зарладаг. Энэ мессежийг минут тутамд илгээдэг.
2) RP зураглалын агент шаардлагатай бөгөөд энэ нь аль бүлгүүдэд ямар RP сонсох ёстойг харуулсан RP-Discovery мессежийг илгээх болно. Энэ мессежээс ердийн PIM чиглүүлэгчид RP-г өөрсдөө тодорхойлох болно. Mapping Agent нь RP чиглүүлэгч өөрөө эсвэл тусдаа PIM чиглүүлэгч байж болно. RP-Discovery-г 224.0.1.40 хаяг руу нэг минутын таймертай илгээдэг.
Үйл явцыг илүү нарийвчлан авч үзье:
R3-ийг RP болгон тохируулцгаая:

ip pim send-rp-дэгдэлтийг зарлах 0 хамрах хүрээ 10

R2 зураглалын агент болгон:

ip pim send-rp-discovery loopback 0 хамрах хүрээ 10

Бусад бүх зүйлд бид Auto-RP-ээр дамжуулан RP-г хүлээх болно:

ip pim autorp сонсогч

Бид R3-ийг тохируулсны дараа RP-Announce-ийг илгээж эхэлнэ:

R2 нь зураглалын агентийг тохируулсны дараа RP-Announce мессежийг хүлээж эхэлнэ. Зөвхөн дор хаяж нэг RP олсон үед л RP-Discovery илгээж эхэлнэ:

Ингэснээр ердийн чиглүүлэгчид (PIM RP сонсогч) энэ мессежийг хүлээн авмагц тэд RP-г хаанаас хайхаа мэдэх болно.
Auto-RP-ийн гол бэрхшээлүүдийн нэг нь RP-Announce болон RP-Discovery мессежийг хүлээн авахын тулд 224.0.1.39-40 хаягаар PIM Join илгээх шаардлагатай бөгөөд илгээхийн тулд та хаана RP байрладаг. Сонгодог тахиа, өндөгний асуудал. Энэ асуудлыг шийдэхийн тулд PIM Sparse-Dense-Mode-ийг зохион бүтээсэн. Хэрэв чиглүүлэгч нь RP-г мэдэхгүй бол нягт горимд, хэрэв мэддэг бол Sparse горимд ажилладаг. PIM Sparse-mode болон ip pim autorp listener командыг энгийн чиглүүлэгчдийн интерфейс дээр тохируулах үед чиглүүлэгч нь зөвхөн Auto-RP протоколоос шууд олон дамжуулалт хийх зорилгоор нягт горимд ажиллах болно (224.0.1.39-40).
BootStrap чиглүүлэгч (BSR).
Энэ функц нь Auto-RP-тэй төстэй ажилладаг. RP бүр зураглалын агент руу мессеж илгээдэг бөгөөд энэ нь газрын зургийн мэдээллийг цуглуулж, дараа нь бусад бүх чиглүүлэгчид мэдэгддэг. Процессыг Auto-RP-тэй төстэй байдлаар тайлбарлая:
1) Бид R3-ийг RP байх нэр дэвшигчээр тохируулсны дараа дараах тушаалаар:

ip pim rp-нэр дэвшигчийн давталт 0

Дараа нь R3 юу ч хийхгүй, тусгай мессеж илгээж эхлэхийн тулд эхлээд зураглалын агент олох хэрэгтэй. Тиймээс бид хоёр дахь алхам руу шилжиж байна.
2) R2-г зураглалын агент болгон тохируулах:

ip pim bsr-нэр дэвшигчийн давталт 0

R2 нь PIM Bootstrap мессежийг илгээж эхэлдэг бөгөөд энэ нь өөрийгөө зураглалын агент гэж харуулж байна:

Энэ мессежийг 224.0.013 хаяг руу илгээдэг бөгөөд үүнийг PIM протокол бусад мессежүүдэд ашигладаг. Энэ нь тэднийг бүх чиглэлд илгээдэг тул Auto-RP-д байсан шиг тахиа, өндөгний асуудал байхгүй.
3) RP нь BSR чиглүүлэгчээс мессеж хүлээн авмагц BSR чиглүүлэгчийн хаяг руу нэн даруй Unicast мессеж илгээнэ.

Үүний дараа BSR нь RP-ийн талаарх мэдээллийг хүлээн авсны дараа тэдгээрийг бүх PIM чиглүүлэгчид сонсдог 224.0.0.13 хаяг руу олон дамжуулалтаар илгээх болно. Тиймээс тушаалын аналог ip pim autorp сонсогч BSR-д байдаггүй ердийн чиглүүлэгчид зориулсан.
Multicast Source Discovery Protocol (MSDP) бүхий Anycast RP.
Auto-RP болон BSR нь RP дээрх ачааллыг дараах байдлаар хуваарилах боломжийг олгодог: Multicast бүлэг бүр зөвхөн нэг идэвхтэй RP-тэй. Нэг multicast бүлгийн ачааллыг хэд хэдэн RP дээр хуваарилах боломжгүй болно. MSDP үүнийг RP чиглүүлэгчид 255.255.255.255 масктай ижил IP хаягийг гаргаж өгдөг. MSDP нь статик, Auto-RP эсвэл BSR гэсэн аргуудын аль нэгийг ашиглан мэдээллийг сурдаг.

Зураг дээр бид MSDP-тэй Auto-RP тохиргоотой байна. Хоёр RP нь Loopback 172.16.1.1 интерфэйс дээр 32/1 IP хаягаар тохируулагдсан бөгөөд бүх бүлгүүдэд ашиглагддаг. RP-Announce-ийн тусламжтайгаар чиглүүлэгч хоёулаа энэ хаяг руу хандаж өөрсдийгөө зарладаг. Auto-RP зураглалын агент нь мэдээллийг хүлээн авсны дараа RP-ийн тухай RP-Discovery-г 172.16.1.1/32 хаягаар илгээдэг. Бид чиглүүлэгчдэд IGP ашиглан 172.16.1.1/32 сүлжээний талаар хэлдэг бөгөөд үүний дагуу. Тиймээс PIM чиглүүлэгчид 172.16.1.1/32 сүлжээнд хүрэх зам дээрх дараагийн үе гэж заасан RP-ээс урсгалыг хүсэх буюу бүртгэдэг. MSDP протокол нь өөрөө олон дамжуулалтын мэдээллийн талаар мессеж солилцох зорилгоор RP-д зориулагдсан болно.
Энэ топологийг авч үзье:

Switch6 нь 238.38.38.38 хаяг руу урсгалыг дамжуулдаг бөгөөд одоогоор энэ талаар зөвхөн RP-R1 л мэддэг. Switch7 болон Switch8 энэ бүлгийг хүссэн. R5 ба R4 чиглүүлэгчид PIM Join-ийг R1 ба R3 руу илгээнэ. Яагаад? R13.13.13.13-д зориулсан 5 хүртэлх зам нь R1-ийн нэгэн адил IGP хэмжигдэхүүнийг ашиглан R4-ийг заана.
RP-R1 нь дамжуулалтын талаар мэддэг бөгөөд R5 руу цацаж эхлэх боловч R4 үүнийг зүгээр л илгээхгүй тул R1 энэ талаар юу ч мэдэхгүй. Тиймээс MSDP зайлшгүй шаардлагатай. Бид үүнийг R1 ба R5 дээр тохируулна:

ip msdp peer 3.3.3.3 R1 дээрх Loopback1 холболтын эх үүсвэр

ip msdp peer 1.1.1.1 R3 дээрх Loopback3 холболтын эх үүсвэр

Тэд өөр хоорондоо сесс босгох бөгөөд ямар нэгэн урсгалыг хүлээн авахдаа RP хөршдөө мэдээлэх болно.
RP-R1 нь Switch6-аас дамжуулалтыг хүлээн авмагц нэн даруй unicast MSDP Source-Active мессежийг илгээх бөгөөд үүнд (S, G) гэх мэт мэдээллийг агуулсан байх болно - олон дамжуулалтын эх сурвалж, очих газрын тухай. Одоо RP-R3 нь Switch6 гэх мэт эх сурвалж R4-ээс энэ урсгалын хүсэлтийг хүлээн авахдаа чиглүүлэлтийн хүснэгтээр удирдуулан Switch6 руу PIM Join илгээх болно гэдгийг мэдэж байгаа. Иймээс R1 ийм PIM Join хүлээн авснаар RP-R3 руу урсгалыг илгээж эхэлнэ.
MSDP нь TCP дээр ажилладаг, RP нь амьд байдлыг шалгахын тулд бие биедээ амьд мессеж илгээдэг. Цаг хэмжигч нь 60 секунд байна.
Keepalive болон SA мессежүүд нь ямар ч домэйны гишүүнчлэлийг заагаагүй тул MSDP нөхдийг өөр өөр домэйнд хуваах функц тодорхойгүй хэвээр байна. Түүнчлэн, энэ топологид бид өөр өөр домэйныг харуулсан тохиргоог туршиж үзсэн - гүйцэтгэлийн хувьд ямар ч ялгаа байхгүй.
Хэрэв хэн нэгэн тодруулж чадах юм бол би үүнийг сэтгэгдэл дээр уншихдаа баяртай байх болно.

Эх сурвалж: www.habr.com