VPN വഴിയുള്ള PIM-SM: BSR, RP മാപ്പിംഗ്, RPF പാതകൾ പരിശോധിക്കുക

ടണൽ പ്രവർത്തിക്കുന്നു, യൂണികാസ്റ്റ് പിംഗുകൾ അതിലൂടെ കടക്കുന്നു, എന്നിട്ടും സ്വീകർത്താവ് കറുത്ത സ്ക്രീൻ കാണിക്കുന്നു. PIM-SM വിന്യാസത്തിൽ ഈ ലക്ഷണം മിക്കവാറും എപ്പോഴും നാല് നിയന്ത്രണ പാതകളിൽ ഒന്ന് തകർന്നു എന്നും ഡാറ്റാ പാത ഒരിക്കലും പ്രശ്നമായിരുന്നില്ല എന്നും അർത്ഥമാക്കുന്നു. താഴെയുള്ള പട്ടിക ക്രമത്തിൽ പരിശോധിച്ച് പരാജയപ്പെടുന്ന ആദ്യ ഘട്ടത്തിൽ നിർത്തുക, കാരണം അടുത്ത ഓരോ ഘട്ടവും അതിന് മുമ്പുള്ളതിനെ ആശ്രയിച്ചിരിക്കുന്നു. ഈ അഞ്ച് പരിശോധനകൾ ഞാൻ ഒരു കരട് ഫയലിൽ സൂക്ഷിച്ച് മൾട്ടികാസ്റ്റ് പരാതി വരുമ്പോൾ ടെർമിനലിൽ ഒട്ടിക്കുന്നു, ഇത് രോഗനിർണയം ഊഹത്തിലേക്ക് മാറുന്നത് തടയുന്നു.

ടണലിൽ നിന്നല്ല, സ്വീകർത്താവിൽ നിന്ന് തുടങ്ങുക

ഗ്രൂപ്പ് ഒരിക്കലും ആവശ്യപ്പെടാത്ത സ്വീകർത്താവ് ഒരു റൗട്ടറിലും അവസ്ഥ സൃഷ്ടിക്കുന്നില്ല, അതിനാൽ മറ്റെന്തെങ്കിലും പരിശോധിക്കുന്നതിന് മുമ്പ് സ്വീകർത്താവിന്റെ വശത്തുള്ള സെഗ്മെന്റിൽ ജോയിൻ ഉണ്ടെന്ന് ഉറപ്പാക്കുക. 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-ലേക്ക് യൂണികാസ്റ്റിലൂടെ അയക്കുന്നു, അതിനാൽ RP-മുതൽ-BSR വരെയുള്ള ഭാഗം പ്രവർത്തിക്കുന്ന ടണലിൽ സാധാരണയായി മാറ്റമില്ലാതെ നിലനിൽക്കുന്നു. മറുദിശയിലുള്ള Bootstrap സന്ദേശങ്ങളുടെ ഒഴുക്ക് ഓരോ ഇടനില ഇന്റർഫേസിലും PIM സജീവമായിരിക്കുന്നതിനെയും അതിർത്തിയിൽ സന്ദേശങ്ങൾ തടയാൻ ഒന്നുമില്ല എന്നതിനെയും ആശ്രയിച്ചിരിക്കുന്നു. RFC 5059 ആ വിതരണവും അത് ചുരുക്കാൻ അനുവാദമുള്ള ഭരണപരമായ പരിധിയുടെ അതിർത്തികളും നിർവചിക്കുന്നു.

ip pim bsr-border പ്രസ്താവന, പ്രോട്ടോക്കോൾ 103 ഫിൽട്ടർ ചെയ്യുന്ന ACL, അല്ലെങ്കിൽ മൾട്ടികാസ്റ്റ് കൊണ്ടുപോകാൻ കഴിയാത്ത നയാധിഷ്ഠിത IPsec ടണൽ, ഇവ ഓരോന്നും ഒഴുക്ക് മുറിച്ച് യൂണികാസ്റ്റ് കേടുകൂടാതെ നിർത്തും. യഥാർത്ഥത്തിൽ എത്തിച്ചേരാനുള്ള കഴിവിന്റെ പ്രശ്നമായിരിക്കെ തകരാർ 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-യിലേക്ക് ശാഖ അതിന്റെ പങ്കിട്ട മരം കെട്ടിപ്പടുക്കുന്നു. മാപ്പിംഗ് ഗ്രൂപ്പ് ശ്രേണിയിലും വിലാസത്തിലും ഒരുപോലെ ഒത്തുപോകണം, കൂടുതൽ നിർദ്ദിഷ്ട ശ്രേണി വിശാലമായതിനെ തോൽപ്പിക്കുന്നു.

രണ്ട് സൈറ്റുകൾക്ക് ഒരു RP വിലാസം പങ്കിടാൻ കഴിയണം എന്നതിനാണ് anycast-RP ഉള്ളത്, ഇവിടെ അത് പരാമർശിക്കേണ്ടതാണ് കാരണം «അതേ RP» എന്നതിന്റെ അർത്ഥം അത് മാറ്റുന്നു. ഒരു വിലാസം പ്രഖ്യാപിക്കുന്ന രണ്ട് RP രൂപകൽപ്പനപ്രകാരം സ്ഥിരതയുള്ളവരാണ്; ഒരേ ശ്രേണിക്ക് വ്യത്യസ്ത വിലാസങ്ങൾ പ്രഖ്യാപിക്കുന്ന രണ്ട് RP അങ്ങനെയല്ല, ഓരോ സൈറ്റും സ്വന്തം നിലയ്ക്ക് എത്ര ആരോഗ്യകരമായി തോന്നിയാലും.

232.0.0.0/8-നുള്ളിൽ ഉറവിട-നിർദ്ദിഷ്ട മൾട്ടികാസ്റ്റിന് RP-യോട് ഒരിക്കലും ചോദിക്കുന്നില്ല, അതിനാൽ ശൂന്യമായ RP മാപ്പിംഗ് സ്വയമേവ ഒരു തകരാറല്ല. ഒരിക്കലും ആവശ്യമില്ലാത്ത RP-യുടെ പിന്നാലെ പോകുന്നതിന് മുമ്പ് ആപ്ലിക്കേഷൻ ഏത് സേവന മാതൃക ഉപയോഗിക്കുന്നു എന്ന് തീരുമാനിക്കുക.

ഉറവിടത്തിലേക്കുള്ള RPF അന്വേഷണം വായിക്കുക

PIM യൂണികാസ്റ്റ് പാത തലകീഴായി മാറ്റിയാണ് മരം നിർമ്മിക്കുന്നത്, അതിനാൽ പ്രധാന പരിശോധന ഉറവിടത്തിലേക്ക് തിരികെയുള്ള റൂട്ട്, അല്ലെങ്കിൽ പങ്കിട്ട മരത്തിന് RP-യിലേക്ക് തിരികെയുള്ളതുമാണ്. റൗട്ടർ മുകളിലത്തേതായി കണക്കാക്കാത്ത ഇന്റർഫേസിലേക്ക് എത്തുന്ന ജോയിൻ ഉപേക്ഷിക്കപ്പെടുന്നു, കാരണം ടണൽ തകരാറായി അല്ല, RPF തകരാറായി രേഖപ്പെടുത്തുന്നു. ടണലിലൂടെയുള്ള സ്ഥിര റൂട്ടും WAN വഴി കൂടുതൽ നിർദ്ദിഷ്ട റൂട്ടും ഉള്ള ശാഖാ റൗട്ടറിൽ, ഉറവിടം ടണലിലൂടെ മാത്രം എത്താവുന്നതാണെങ്കിലും RPF ഇന്റർഫേസ് എളുപ്പത്തിൽ WAN ആകാം. ജോയിൻ നിശബ്ദമായി ഉപേക്ഷിക്കപ്പെടുന്നതിന്റെ ഏറ്റവും സാധാരണ കാരണം ഇതാണ്.

show ip rpf 192.0.2.10 തിരഞ്ഞെടുത്ത ഇന്റർഫേസും അടുത്ത ഹോപ്പും തീരുമാനമുണ്ടാക്കിയ റൂട്ടും അച്ചടിക്കുന്നു, സാധാരണയായി പൊരുത്തക്കേട് കാണാൻ അത് മതിയാകും. ip mroute 192.0.2.0 255.255.255.0 tunnel0 പോലുള്ള സ്റ്റാറ്റിക് മൾട്ടികാസ്റ്റ് റൂട്ട് ആ പ്രിഫിക്സിനുള്ള യൂണികാസ്റ്റ് അന്വേഷണത്തെ മറികടക്കുന്നു, മൾട്ടികാസ്റ്റ് ടോപ്പോളജി യൂണികാസ്റ്റ് ടോപ്പോളജിയിൽ നിന്ന് യഥാർത്ഥത്തിൽ വ്യത്യാസപ്പെടുമ്പോൾ അത് ന്യായമായ തിരുത്താണ്. രേഖപ്പെടുത്തേണ്ട കോൺഫിഗറേഷനായി അതിനെ കാണുക, സംഭവവേളയിൽ പ്രയോഗിച്ച് പിന്നീട് മറന്നുപോകുന്ന പാച്ചായി അല്ല.

പിംഗ് കൊണ്ടല്ല, കമാൻഡുകൾ കൊണ്ട് ജോയിൻ ഉറപ്പാക്കുക

പിംഗ് യൂണികാസ്റ്റ് പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുന്നു, അത് നിങ്ങൾക്ക് ഇതിനകം അറിയാമായിരുന്നു. അറ്റം മുതൽ അറ്റം വരെയുള്ള സ്ഥിരീകരണം ജോയിൻ, മാപ്പിംഗ്, അയൽക്കാരൻ, മരം എന്നിവ ആ ക്രമത്തിൽ കാണിക്കുന്ന ഒരു ശ്രേണിയാണ്, ഓരോ കമാൻഡും വ്യത്യസ്ത ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു.

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 ലേബലുള്ള കൗണ്ടർ, ടണലിലേക്കല്ല, മുമ്പത്തെ വിഭാഗത്തിലേക്കാണ് ചൂണ്ടുന്നത്.

അഞ്ച് കമാൻഡുകളും ശരിയായി തോന്നുന്നുവെങ്കിലും സ്വീകർത്താവ് ഇപ്പോഴും ഒന്നും കാണുന്നില്ലെങ്കിൽ, ബാക്കിയുള്ള സംശയം ടണലിന്റെ സ്വന്തം നയമാണ്: യൂണികാസ്റ്റ് റൗട്ടിംഗ് പ്രോട്ടോക്കോളിന് അനുമതി നൽകുന്നുവെങ്കിലും PIM, IGMP അല്ലെങ്കിൽ ഗ്രൂപ്പ് ട്രാഫിക്കിന് അനുമതി നൽകാത്ത ക്രിപ്റ്റോ ACL അല്ലെങ്കിൽ ഫയർവാൾ നിയമം. നയാധിഷ്ഠിത IPsec ടണലിൽ മൾട്ടികാസ്റ്റ് ഒട്ടും കൊണ്ടുപോകുന്നില്ല, അതിനാൽ ഉത്തരം മറ്റൊരു ഫിൽട്ടർ അപവാദമല്ല, GRE അല്ലെങ്കിൽ VTI രൂപകൽപ്പനയാണ്. എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് അഞ്ച് പരിശോധനകളിൽ ഏത് പരാജയപ്പെട്ടു എന്ന് എഴുതുക, എന്നിട്ട് ആ പാളി മാത്രം മാറ്റുക.