PIM-SM sa Buong VPN: Suriin ang BSR, Pagmamapa ng RP at mga Landas ng RPF

Buhay ang tunnel, dumadaan ang mga unicast ping, at itim pa rin ang screen ng tumatanggap. Sa isang deployment ng PIM-SM, halos palaging ibig sabihin ng sintomas na ito ay isa sa apat na landas ng kontrol ang sira, at ang landas ng datos ay hindi kailanman naging problema. Sundin ang listahan sa ibaba sa pagkakasunod-sunod at huminto sa unang hakbang na bigong, dahil bawat susunod na hakbang ay nakasalalay sa nauna. Itinatago ko ang limang pagsusuring ito sa isang draft na file at ipinapadikit sa terminal kapag may dumarating na reklamo tungkol sa multicast, na pumipigil sa diagnosis na maging haka-haka.

Magsimula sa tumatanggap, hindi sa tunnel

Ang tumatanggap na hindi kailanman humiling ng grupo ay hindi gumagawa ng anumang estado sa alinmang router, kaya tiyakin muna na mayroong pagsali sa segment na nakaharap sa tumatanggap bago suriin ang anupaman. Sa mga platform na tulad ng Cisco, ang show ip igmp groups sa router ng huling hop ay naglilimbag ng mga sinamahang grupo sa tabi ng interface na nakarinig sa mga ito. Kapag wala ang grupo sa output na iyon, ang tunnel ay isang abala: namatay ang kahilingan sa switch ng access, sa socket ng host o sa isang VLAN na walang querier.

Dalawang karaniwang dahilan ang nagpapaliwanag sa karamihan ng nawawalang pagsali na nakita ko: hindi pagkakatugma ng bersyon ng IGMP sa pagitan ng host at router, at isang halalan ng querier na napunta sa switch na hindi nagra-routing. Ang pangatlo ay mas banayad: nakasali na ang grupo ngunit sa maling VLAN, dahil may dalawang network card ang host at nakakabit ang aplikasyon sa mali. May katumbas na problema ang mga tumatanggap na IPv6 sa MLD, kung saan sinasagot ng show ipv6 mld groups ang parehong tanong. Wala sa mga ito ang naaayos sa pamamagitan ng paghawak sa tunnel, at iyon mismo ang dahilan kung bakit mahalaga ang pagkakasunod-sunod.

Kapag nakita na ang pagsali, tiyakin na naka-enable ang PIM sa interface na nakaharap sa tumatanggap at sa interface na patungo sa tagpuan. Ang router na may pagiging kasapi sa IGMP ngunit walang PIM sa upstream na interface nito ay magtatago ng grupo sa lokal na talahanayan at wala itong ipapadala kahit saan.

Nakarating ba ang set ng BSR sa kabilang panig?

Gumagalaw ang mga mensahe ng Bootstrap Router nang hop sa hop sa loob ng isang domain ng PIM, at iyon ang direksyong nasisira sa tunnel. Ipinapadala ng mga kandidatong RP ang kanilang mga anunsyo sa nahalal na BSR sa pamamagitan ng unicast, kaya karaniwang nananatiling buo ang bahagi ng RP-hanggang-BSR sa gumaganang tunnel. Ang pagbaha ng mga mensahe ng Bootstrap sa kabilang direksyon ay nakasalalay sa pagkakaroon ng PIM sa bawat intermediate na interface, at sa walang pumipigil sa mga mensahe sa isang hangganan. Tinutukoy ng RFC 5059 ang pamamahaging iyon at ang mga hangganan ng saklaw na administratibo na pinapayagang paikliin ito.

Isang pahayag na ip pim bsr-border, isang ACL na nagsasala sa protocol 103, o isang tunnel ng IPsec na batay sa patakaran na hindi makapagdala ng multicast, bawat isa ay puputol sa pagbaha habang buo ang unicast. Ang kombinasyong iyon ang nagpapamukha sa pagkabigo na problema sa RP gayong sa totoo ay problema ito sa maabot, kaya binabasa ko ang estado ng BSR bago ang configuration ng RP.

Sa router sa malayong panig, tinutukoy ng show ip pim bsr-router ang nahalal na BSR at ang natutuhang set ng RP; kung walang laman ang output, nasa sariling domain ito at walang configuration ng RP ang makakapagkasundo sa dalawa. Ihambing ang mga saklaw ng grupo at mga address ng RP sa show ip pim rp mapping sa magkabilang panig ng tunnel. Ang pagmamapang lokal lamang ay gumagawa ng pinagsasaluhang puno na nagtatapos sa maling lugar, at naghihintay magpakailanman ang tumatanggap.

Pagtatugmain ang pagmamapa ng RP sa magkabilang panig ng tunnel

Ang static na RP, BSR at anycast-RP ay tatlong paraan ng pagsagot sa parehong tanong, at ang paghahalo sa kanila sa tunnel ay isang maaasahang paraan ng pagbuo ng domain na hindi kailanman nagkokonberhe. Kung gumagamit ang head end ng BSR at ang sangay ng static na ip pim rp-address na tumuturo sa ibang address, itinatayo ng sangay ang pinagsasaluhang puno nito patungo sa isang RP na walang kaalaman na may tumatanggap. Dapat magtugma ang pagmamapa sa saklaw ng grupo at sa address, dahil ang mas tiyak na saklaw ay nananalo sa mas malawak.

Umiiral ang anycast-RP upang makapagsaluha ng isang address ng RP ang dalawang site, at sulit itong banggitin dito dahil binabago nito ang kahulugan ng «kaparehong RP». Ang dalawang RP na nag-aanunsyo ng isang address ay magkatugma ayon sa disenyo; ang dalawang RP na nag-aanunsyo ng magkaibang address para sa parehong saklaw ay hindi, gaano man kalusog ang bawat site kapag nag-iisa.

Para sa multicast na tukoy sa pinagmulan sa loob ng 232.0.0.0/8, hindi kailanman tinatanong ang RP, kaya ang walang lamang pagmamapa ng RP ay hindi awtomatikong depekto. Magpasya kung aling modelo ng serbisyo ang ginagamit ng aplikasyon bago habulin ang isang RP na hindi kailanman kailangan.

Basahin ang paghahanap ng RPF patungo sa pinagmulan

Binubuo ng PIM ang puno sa pamamagitan ng pagbaligtad ng landas ng unicast, kaya ang mahalagang tsek ay ang rutang pabalik sa pinagmulan, o pabalik sa RP para sa pinagsasaluhang puno. Ang pagsaling dumadating sa interface na hindi itinuturing na upstream ng router ay itinatapon, at ang dahilan ay itinatala bilang pagkabigo ng RPF at hindi pagkabigo ng tunnel. Sa router ng sangay na may default na ruta sa tunnel at mas tiyak na ruta sa WAN, ang interface ng RPF ay madaling maging WAN kahit na maabot lamang ang pinagmulan sa pamamagitan ng tunnel. Iyon ang nag-iisang pinakakaraniwang dahilan kung bakit tahimik na itinatapon ang isang pagsali.

show ip rpf 192.0.2.10 ay naglilimbag ng piniling interface, susunod na hop at ang rutang gumawa ng desisyon, na karaniwang sapat upang makita ang hindi pagkakatugma. Ang static na rutang multicast tulad ng ip mroute 192.0.2.0 255.255.255.0 tunnel0 ay lumalampas sa paghahanap ng unicast para sa prefix na iyon, at ito ay lehitimong pagwawasto kapag talagang naiiba ang topolohiya ng multicast sa topolohiya ng unicast. Ituring ito bilang configuration na dapat idokumento, hindi bilang tapal na inilapat habang may insidente at pagkatapos ay nakalimutan.

Tiyakin ang pagsali sa pamamagitan ng mga utos, hindi ng ping

Pinatutunayan ng ping na gumagana ang unicast, na alam mo na. Ang pagpapatibay mula dulo hanggang dulo ay isang pagkakasunod-sunod na nagpapakita ng pagsali, pagmamapa, kapitbahay at puno sa ganoong ayos, at bawat utos ay sumasagot sa ibang tanong.

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

Ang punong entry na (S,G) na may tunay na papasok na interface at hindi walang laman na listahan ng palabas ay nangangahulugan na natapos na ng control plane ang trabaho nito. Ang entry na ang papasok na interface ay nababasa bilang Null, o isang counter na may label na RPF failed na patuloy na tumataas, ay tumuturo pabalik sa nakaraang seksyon at hindi sa tunnel.

Kung mukhang tama ang lahat ng limang utos at wala pa ring nakikita ang tumatanggap, ang natitirang pinaghihinalaan ay ang patakaran mismo ng tunnel: isang crypto ACL o panuntunan ng firewall na pinapayagan ang protocol ng routing na unicast ngunit hindi ang PIM, IGMP o ang trapiko ng grupo mismo. Sa tunnel ng IPsec na batay sa patakaran, hindi talaga dinadala ang multicast, kaya ang sagot ay disenyo ng GRE o VTI at hindi isa pang eksepsiyon sa filter. Isulat kung alin sa limang pagsusuri ang nabigo bago baguhin ang anuman, at pagkatapos ay baguhin lamang ang layer na iyon.