PIM-SM kupitia VPN: angalia BSR, ramani ya RP na njia za RPF

Tuneli inafanya kazi, ping za unicast zinapita ndani yake, na kipokezi bado kinaonyesha skrini nyeusi. Katika usambazaji wa PIM-SM dalili hiyo karibu kila mara inamaanisha kuwa mojawapo ya njia nne za udhibiti imevunjika, na njia ya data haikuwa tatizo kamwe. Pitia orodha iliyo hapa chini kwa mpangilio na usimame kwenye hatua ya kwanza inayoshindikana, kwa sababu kila hatua inayofuata inategemea ile iliyotangulia. Ninahifadhi ukaguzi huu watano kwenye faili ya rasimu na kuibandika kwenye terminali wakati malalamiko ya multicast yanapofika, jambo ambalo huzuia uchunguzi usigeuke kuwa ubashiri.

Anza na kipokezi, sio tuneli

Kipokezi ambacho hakikuwahi kuomba kikundi hakiunda hali yoyote kwenye kipanga njia chochote, kwa hivyo kabla ya kuchunguza kitu kingine chochote thibitisha kuwa uunganishaji upo kwenye sehemu inayoelekea kipokezi. Kwenye majukwaa ya mtindo wa Cisco, show ip igmp groups kwenye kipanga njia cha hatua ya mwisho huchapisha vikundi vilivyounganishwa kando ya kiolesura kilichovisikia. Wakati kikundi hakipo kwenye matokeo hayo, tuneli ni kizuizi cha umakini: ombi lilikufa kwenye swichi ya ufikiaji, kwenye soketi ya mwenyeji au kwenye VLAN isiyo na querier.

Sababu mbili za kawaida zinaelezea uunganishaji mwingi uliokosekana niliouona: kutofautiana kwa toleo la IGMP kati ya mwenyeji na kipanga njia, na uchaguzi wa querier ulioangukia swichi isiyofanya uelekezaji. Ya tatu ni nyeti zaidi: kikundi kimeunganishwa lakini kwenye VLAN isiyofaa, kwa sababu mwenyeji ana kadi mbili za mtandao na programu ilijifunga kwenye ile isiyofaa. Vipokezi vya IPv6 vina tatizo lilelile na MLD, ambapo show ipv6 mld groups hujibu swali hilohilo. Hakuna mojawapo ya haya linalotatuliwa kwa kugusa tuneli, na ndiyo sababu mpangilio ni muhimu.

Mara tu uunganishaji unapoonekana, thibitisha kwamba PIM imewezeshwa kwenye kiolesura kinachoelekea kipokezi na kwenye kiolesura kinachoelekea mahali pa kukutana. Kipanga njia kilicho na uanachama wa IGMP lakini hakina PIM kwenye kiolesura chake cha juu kitahifadhi kikundi kwenye jedwali la ndani na hakitotuma chochote popote.

Je, seti ya BSR inafika upande wa pili?

Ujumbe wa Bootstrap Router husogea hatua kwa hatua ndani ya kikoa kimoja cha PIM, na huo ndio mwelekeo unaovunjika kupitia tuneli. RP wagombea hutuma matangazo yao kwa BSR iliyochaguliwa kwa unicast, kwa hivyo sehemu ya RP-hadi-BSR kwa kawaida huendelea bila kubadilika kwenye tuneli inayofanya kazi. Mafuriko ya ujumbe wa Bootstrap upande mwingine hutegemea kila kiolesura cha kati kuwa na PIM imewezeshwa, na kwamba hakuna kinachozuia ujumbe kwenye mpaka. RFC 5059 inafafanua usambazaji huo na mipaka ya wigo wa kiutawala inayoruhusiwa kuufupisha.

Tamko la ip pim bsr-border, ACL inayochuja itifaki 103, au tuneli ya IPsec inayotegemea sera isiyoweza kubeba multicast, kila moja itakata mafuriko wakati unicast inabaki salama. Mchanganyiko huo ndio unaofanya hitilafu ionekane kama tatizo la RP wakati kwa kweli ni tatizo la ufikivu, na ndiyo sababu nasoma hali ya BSR kabla ya usanidi wa RP.

Kwenye kipanga njia cha upande wa mbali, show ip pim bsr-router hutaja BSR iliyochaguliwa na seti ya RP iliyojifunza; ikiwa matokeo ni tupu, upande wa mbali umekaa kwenye kikoa chake na hakuna usanidi wa RP utakaopatanisha hizo mbili. Linganisha safu za vikundi na anwani za RP kwenye show ip pim rp mapping pande zote za tuneli. Ramani inayopatikana ndani tu huzalisha mti wa pamoja unaoishia mahali pasipofaa, na kipokezi husubiri milele.

Patanisha ramani ya RP pande zote za tuneli

RP tuli, BSR na anycast-RP ni njia tatu za kujibu swali moja, na kuzichanganya kupitia tuneli ni njia ya kuaminika ya kujenga kikoa kisichoungana kamwe. Ikiwa upande wa mbele unatumia BSR na tawi linatumia ip pim rp-address tuli inayoelekeza anwani nyingine, tawi linajenga mti wake wa pamoja kuelekea RP isiyojua kipokezi kipo. Ramani inapaswa kukubaliana kwenye safu ya kikundi na pia kwenye anwani, kwa kuwa safu maalum zaidi hushinda ile pana.

Anycast-RP ipo kwa ajili ya tovuti mbili kushiriki anwani moja ya RP, na inafaa kuitaja hapa kwa sababu inabadilisha maana ya «RP hiyo hiyo». RP mbili zinazotangaza anwani moja ni thabiti kwa muundo; RP mbili zinazotangaza anwani tofauti kwa safu hiyo hiyo haziko hivyo, hata kila tovuti ionekane yenye afya kivyake.

Kwa multicast maalum kwa chanzo ndani ya 232.0.0.0/8, RP haihitajiki kamwe kuulizwa, kwa hivyo ramani tupu ya RP si hitilafu kiatomati. Amua ni muundo gani wa huduma ambao programu inatumia kabla ya kufukuza RP ambayo haikuhitajika kamwe.

Soma utafutaji wa RPF kuelekea chanzo

PIM hujenga mti kwa kugeuza njia ya unicast, kwa hivyo ukaguzi muhimu ni njia ya kurudi kwenye chanzo, au kurudi kwenye RP kwa mti wa pamoja. Uunganishaji unaofika kwenye kiolesura ambacho kipanga njia hakikioni kuwa cha juu hutupwa, na sababu huandikwa kama kushindikana kwa RPF na sio kushindikana kwa tuneli. Kwenye kipanga njia cha tawi kilicho na njia chaguo-msingi juu ya tuneli na njia maalum zaidi juu ya WAN, kiolesura cha RPF kinaweza kuwa WAN kwa urahisi ingawa chanzo kinafikiwa kwa njia ya tuneli tu. Hii ndiyo sababu moja ya kawaida zaidi ya uunganishaji kutupwa kwa kimya.

show ip rpf 192.0.2.10 huchapisha kiolesura kilichochaguliwa, hatua inayofuata na njia iliyozalisha uamuzi, na kwa kawaida hiyo inatosha kuona kutokupatana. Njia tuli ya multicast kama ip mroute 192.0.2.0 255.255.255.0 tunnel0 hupitiliza utafutaji wa unicast kwa kiambishi hicho, na ni marekebisho halali wakati topolojia ya multicast inatofautiana kweli na topolojia ya unicast. Ichukulie kama usanidi unaopaswa kuandikwa, sio kama kiraka kilichowekwa wakati wa tukio kisha kusahaulika.

Thibitisha uunganishaji kwa amri, sio kwa ping

Ping inathibitisha kuwa unicast inafanya kazi, jambo ambalo ulikuwa unalijua. Uthibitisho wa mwanzo hadi mwisho ni mfululizo unaoonyesha uunganishaji, ramani, jirani na mti kwa mpangilio huo, na kila amri hujibu swali tofauti.

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

Kipengee cha (S,G) kilichojaa na kiolesura halisi cha kuingia na orodha ya kutoka isiyo tupu kinamaanisha ngazi ya udhibiti imemaliza kazi yake. Kipengee ambacho kiolesura chake cha kuingia kinasomwa kama Null, au kihesabu kilichowekwa lebo RPF failed kinachoendelea kupanda, kinaelekeza nyuma kwenye sehemu iliyotangulia na sio kwenye tuneli.

Ikiwa amri zote tano zinaonekana sahihi na kipokezi bado hakioni chochote, mtuhumiwa aliyebaki ni sera ya tuneli yenyewe: ACL ya usimbaji fiche au kanuni ya firewall inayoruhusu itifaki ya uelekezaji wa unicast lakini sio PIM, IGMP au trafiki ya kikundi yenyewe. Kwenye tuneli ya IPsec inayotegemea sera, multicast haibebwi kabisa, kwa hivyo jibu ni muundo wa GRE au VTI na sio kingine cha kipekee cha chujio. Andika ni ukaguzi upi kati ya watano ulioshindikana kabla ya kubadilisha chochote, kisha badilisha tabaka hilo pekee.