VPN дээгүүр PIM-SM: BSR, RP-ийн зураглал, RPF замыг шалгах

Туннель ажиллаж байна, unicast ping-ууд түүгээр дамжина, гэвч хүлээн авагч хар дэлгэц харуулсаар байна. PIM-SM-ийн байршуулалтад энэ шинж тэмдэг бараг үргэлж дөрвөн удирдлагын замын нэг эвдэрсэн, өгөгдлийн зам хэзээ ч асуудал байгаагүй гэсэн утгатай. Доорх жагсаалтыг дарааллаар нь хийж, бүтэлгүйтсэн эхний алхам дээр зогсоно уу, учир нь дараагийн алхам бүр өмнөхөөсөө хамаардаг. Би эдгээр таван шалгалтыг ноорог файлд хадгалж, multicast гомдол ирэхэд терминалд буулгадаг бөгөөд энэ нь оношилгоог таамаглал болгохоос сэргийлдэг.

Туннель биш, хүлээн авагчаас эхэл

Бүлгийг хэзээ ч хүсээгүй хүлээн авагч ямар ч чиглүүлэгч дээр төлөв үүсгэхгүй тул өөр зүйлийг шалгахаас өмнө хүлээн авагчийн талын сегментэд нэгдэл байгаа эсэхийг баталгаажуулна уу. Cisco маягийн платформуудад сүүлчийн үсрэлтийн чиглүүлэгч дээр show ip igmp groups нэгдсэн бүлгүүдийг тэдгээрийг сонссон интерфэйсийн хажууд хэвлэдэг. Тухайн гаралтад бүлэг байхгүй бол туннель нь анхаарлыг сарниулагч юм: хүсэлт нэвтрэх коммутатор дээр, хост-ын сокет дээр эсвэл querierгүй VLAN дотор үхсэн.

Миний харсан ихэнх алга болсон нэгдлийг хоёр энгийн шалтгаан тайлбарладаг: хост ба чиглүүлэгчийн хоорондох IGMP хувилбарын зөрүү, мөн чиглүүлэлт хийдэггүй коммутатор дээр буусан querier-ийн сонголт. Гурав дахь нь илүү нарийн: бүлэгт нэгдсэн боловч буруу VLAN-д байна, учир нь хост дээр хоёр сүлжээний карт байгаа бөгөөд програмыг буруу картад холбосон. IPv6 хүлээн авагчдад MLD-тэй ижил асуудал байдаг бөгөөд тэнд show ipv6 mld groups мөн адил асуултад хариулдаг. Эдгээрийн аль нь ч туннельд хүрэх замаар засрахгүй бөгөөд яг ийм учраас дараалал чухал.

Нэгдэл харагдах үед PIM нь хүлээн авагчийн талын интерфэйс болон уулзах цэг рүү чиглэсэн интерфэйс хоёр дээр идэвхтэй эсэхийг баталгаажуулна уу. IGMP гишүүнчлэлтэй боловч дээд интерфэйс дээрээ PIMгүй чиглүүлэгч бүлгийг локал хүснэгтэд хадгалж, хаана ч юу ч илгээхгүй.

BSR-ийн багц нөгөө талд хүрдэг үү?

Bootstrap Router мессежүүд нэг PIM домайн дотор үсрэлтээс үсрэлт рүү шилждэг бөгөөд туннелиар дамжин эвдэрдэг чиглэл нь яг энэ юм. Нэр дэвшигч RP-ууд өөрийн зарлалыг сонгогдсон BSR руу unicast-аар илгээдэг тул RP-ээс BSR хүртэлх хэсэг ажиллаж буй туннельд ихэвчлэн өөрчлөгдөхгүй үлддэг. Нөгөө чиглэлд Bootstrap мессежийн урсгал нь завсрын интерфэйс бүрд PIM идэвхтэй байх, мөн хилийн дээр мессежийг зогсоох зүйл байхгүй байхаас хамаарна. RFC 5059 нь энэ хуваарилалт болон түүнийг богиносгохыг зөвшөөрсөн захиргааны хүрээний хил хязгаарыг тодорхойлдог.

ip pim bsr-border мэдэгдэл, 103 протоколыг шүүх ACL, эсвэл multicast зөөх чадваргүй бодлогод суурилсан IPsec туннель — тус бүр урсгалыг тасалж, unicast хөндөгдөхгүй үлдэнэ. Яг энэ хослол нь доголдлыг RP-ийн асуудал мэт харагдуулах бөгөөд бодит байдал дээр энэ нь хүртээмжийн асуудал бөгөөд тиймээс би RP-ийн тохиргооны өмнө BSR-ийн төлвийг уншдаг.

Алслаг талын чиглүүлэгч дээр show ip pim bsr-router сонгогдсон BSR болон сурсан RP-ийн багцыг нэрлэнэ; гаралт хоосон бол алслаг тал өөрийн домайнд сууж байгаа бөгөөд ямар ч RP тохиргоо хоёрыг эвлэрүүлэхгүй. Туннелийн хоёр талд show ip pim rp mapping гаралт дахь бүлгийн хүрээ болон RP хаягийг харьцуулна уу. Зөвхөн локал байдлаар оршин байгаа зураглал буруу газарт төгсдөг хуваалцсан мод үүсгэдэг бөгөөд хүлээн авагч үүрд хүлээдэг.

RP-ийн зураглалыг туннелийн хоёр талд тааруул

Статик RP, BSR болон anycast-RP нь нэг асуултад өгөх гурван хариулт бөгөөд тэдгээрийг туннелиар холих нь хэзээ ч нэгдэхгүй домайн барих найдвартай арга юм. Хэрэв толгой хэсэг BSR ашиглаж, салбар нь өөр хаяг руу заасан статик ip pim rp-address ашиглавал салбар нь хүлээн авагч байгааг мэдэхгүй RP руу өөрийн хуваалцсан модоо барьдаг. Зураглал нь бүлгийн хүрээ болон хаяг аль алинд нь таарах ёстой, учир нь илүү тодорхой хүрээ өргөнөөс дийлдэг.

Anycast-RP нь хоёр сайт нэг RP хаягийг хуваалцахын тулд яг байдаг бөгөөд энд нэрлэх нь зүйтэй, учир нь энэ нь «ижил RP» гэдгийн утгыг өөрчилдөг. Нэг хаягийг зарладаг хоёр RP нь зохион байгуулалтаараа нийцтэй; нэг хүрээнд өөр өөр хаяг зарладаг хоёр RP нь тийм биш, сайт бүр дангаараа хичнээн эрүүл харагдавч.

232.0.0.0/8 доторх эх үүсвэрт тусгай multicast-ийн хувьд RP-ээс хэзээ ч асуудаггүй, тиймээс хоосон RP зураглал автоматаар алдаа биш. Хэзээ ч хэрэггүй байсан RP-ийн араас хөөхөөс өмнө програм ямар үйлчилгээний загвар ашигладаг талаар шийдээрэй.

Эх үүсвэр рүү чиглэсэн RPF хайлтыг унших

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

show ip rpf 192.0.2.10 сонгосон интерфэйс, дараагийн үсрэлт болон шийдвэр гаргасан замыг хэвлэдэг бөгөөд ихэвчлэн зөрүүг харахад хангалттай. ip mroute 192.0.2.0 255.255.255.0 tunnel0 мэтийн статик multicast зам нь тухайн префиксийн unicast хайлтыг давж гардаг бөгөөд multicast топологи unicast топологоос үнэхээр ялгаатай үед энэ нь хууль ёсны засвар юм. Үүнийг баримтжуулах ёстой тохиргоо гэж үзээрэй, ослын үеэр тавьж дараа нь мартагдсан нөхөөс гэж бүү үзээрэй.

Нэгдлийг пингээр биш, командаар баталгаажуул

Пинг нь unicast ажиллаж байгааг нотолдог, үүнийг та аль хэдийн мэдэж байсан. Эцсээс эцэс хүртэлх баталгаажуулалт нь нэгдэл, зураглал, хөрш болон модыг яг энэ дарааллаар харуулсан дараалал бөгөөд команд бүр өөр асуултад хариулдаг.

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

Бодит орж ирж буй интерфэйс болон хоосон бус гарч буй жагсаалттай бөглөгдсөн (S,G) бичлэг нь удирдлагын хавтгай ажлаа дуусгасан гэсэн үг. Орж ирж буй интерфэйс нь Null гэж уншигдах бичлэг, эсвэл байнга өсөж буй RPF failed шошготой тоолуур нь туннель рүү биш, өмнөх хэсэг рүү заана.

Таван команд бүгд зөв харагдаж байтал хүлээн авагч юу ч харахгүй бол үлдсэн сэжигтэн нь туннелийн өөрийн бодлого юм: unicast чиглүүлэлтийн протоколыг зөвшөөрдөг боловч PIM, IGMP эсвэл бүлгийн трафикийг өөрийг нь зөвшөөрдөггүй крипто ACL эсвэл галт ханын дүрэм. Бодлогод суурилсан IPsec туннельд multicast огт зөөгддөггүй тул хариу нь өөр нэг шүүлтүүрийн үл хамаарах зүйл биш, GRE эсвэл VTI загвар юм. Ямар нэг зүйлийг өөрчлөхөөс өмнө таван шалгалтын алинаас нь бүтэлгүйтсэнийг бичээд, дараа нь зөвхөн тэр давхаргыг өөрчил.