EIGRP അയൽക്കാരനോ DMVPN ട്രാൻസിറ്റോ? ആദ്യം റോൾ പരിശോധിക്കുക

അയൽബന്ധം ഇല്ല, നടുവിലെ റൗട്ടർ വ്യക്തമായ സംശയിതനായി തോന്നുന്നു. അത് നിരപരാധിയായിരിക്കാം. പുറം ടണൽ പാക്കറ്റുകൾ കൈമാറുന്നതും overlay റൗട്ടിംഗ് പ്രോട്ടോക്കോളിൽ പങ്കെടുക്കുന്നതും രണ്ട് വ്യത്യസ്ത ജോലികളാണ്, ഉപകരണത്തിന് രണ്ടാമത്തേത് ചെയ്യാതെ ആദ്യത്തേത് ചെയ്യാം. താഴെയുള്ള അഞ്ച് പരിശോധനകൾ ക്രമത്തിൽ ചെയ്ത് ആദ്യം പരാജയപ്പെടുന്നതിൽ നിർത്തുക.

ഘട്ടം 1: രണ്ട് റോളുകൾ വരയ്ക്കുക

ഉദ്ദേശിച്ച EIGRP അയൽബന്ധം രണ്ട് റൗട്ടറുകൾക്കിടയിലുള്ള യുക്തിപരമായ ബന്ധമായി വരയ്ക്കുക, തുടർന്ന് അതിന്റെ ടണൽ പാക്കറ്റുകൾ വഹിക്കുന്ന underlay റൗട്ടറുകൾ വരയ്ക്കുക. ഒരേ ഉപകരണം രണ്ട് പട്ടികകളിലും വേണമെന്നില്ല, പട്ടികകൾ കൂട്ടിക്കലർത്തുന്നതാണ് ആരോഗ്യകരമായ ട്രാൻസിറ്റ് റൗട്ടർ അയൽബന്ധം തകർത്തുവെന്ന് ആരോപിക്കപ്പെടാൻ ഏറ്റവും സാധാരണ കാരണം.

ട്രാൻസിറ്റ് റൗട്ടർ തന്റെ സാധാരണ IP റൗട്ടിംഗും നയവും ഉപയോഗിച്ച് പുറം പാക്കറ്റുകൾ കൈമാറുന്നു. സംരക്ഷിത ടണലിനുള്ളിൽ കൊണ്ടുപോകുന്ന പ്രോട്ടോക്കോൾ പ്രവർത്തിപ്പിക്കേണ്ടതില്ല, ആ പാക്കറ്റുകൾ മുന്നോട്ട് കൈമാറാൻ EIGRP പ്രോസസ്സും വേണ്ട.

ഘട്ടം 2: നടുവിലെ ഉപകരണം എന്ത് അവസാനിപ്പിക്കുന്നു എന്ന് പരിശോധിക്കുക

നടുവിലെ റൗട്ടർ ടണൽ അവസാനിപ്പിച്ച് spoke-കളുമായി EIGRP അയൽബന്ധങ്ങൾ രൂപപ്പെടുത്തേണ്ടതാണെങ്കിൽ ഉത്തരം പൂർണ്ണമായി മാറുന്നു. ആ ഉപകരണത്തിന് പിന്തുണയുള്ള overlay റൗട്ടിംഗ് സ്വഭാവം ആവശ്യമാണ്, അതിനെ ട്രാൻസിറ്റ് എന്ന് വിളിക്കുന്നത് അയൽക്കാരൻ എന്ന ആവശ്യകത ഒഴിവാക്കുന്നില്ല. റൗട്ടിംഗ് കോൺഫിഗറേഷന് മുൻപ് ടണൽ കോൺഫിഗറേഷൻ വായിക്കുക. ആ ഉത്തരമാണ് തുടർന്നുള്ള ഓരോ പരിശോധനയും നിർണ്ണയിക്കുന്നത്.

അതിനാൽ ആദ്യത്തെ യഥാർത്ഥ ചോദ്യം ഏത് പ്രോട്ടോക്കോൾ ക്രമീകരിക്കണം എന്നല്ല. ബോക്സ് hub ആണോ, spoke ആണോ, വെറും underlay ഹോപ്പ് ആണോ, അതല്ലെങ്കിൽ അറ്റങ്ങൾക്കിടയിൽ ഫ്രെയിമുകൾ കൊണ്ടുപോകുന്ന Layer 2 സേവനമാണോ എന്നതാണ്.

ഘട്ടം 3: അയൽക്കാരന്റെ നിയന്ത്രണ തലം പരിശോധിക്കുക

അയൽക്കാരനാകേണ്ട ഓരോ ഉപകരണത്തിലും നാല് കാര്യങ്ങൾ സ്ഥിരീകരിക്കുക: EIGRP ഇൻസ്റ്റൻസും സ്വയംഭരണ സിസ്റ്റം നമ്പറും, പ്രാമാണീകരണ പാരാമീറ്ററുകൾ, പ്രോസസ്സിൽ പങ്കെടുക്കുന്ന ഇന്റർഫേസ്, ആ ഇന്റർഫേസ് ഉൾക്കൊള്ളുന്ന നെറ്റ്വർക്ക് പ്രസ്താവന. ഇവയിലേതെങ്കിലും പൊരുത്തപ്പെടാത്തപക്ഷം ഇന്റർഫേസ് മുകളിൽ നിൽക്കുകയും ping തുടരുകയും ചെയ്യുമ്പോൾ അയൽബന്ധം താഴെയായിരിക്കും.

RFC 7868 EIGRP-യെ മൾട്ടികാസ്റ്റ് നിയന്ത്രണ കൈമാറ്റമുള്ള IP പ്രോട്ടോക്കോളായി വിവരിക്കുന്നു, അതിനാൽ അയൽബന്ധം ഇടനില റൗട്ടറിന് പാക്കറ്റുകൾ ലക്ഷ്യത്തിലേക്ക് റൗട്ട് ചെയ്ത് പകരം വയ്ക്കാവുന്ന ഒന്നല്ല. ഒന്നുകിൽ നിയന്ത്രണ കൈമാറ്റം പിയറിലെത്തുന്നു, അല്ലെങ്കിൽ അയൽബന്ധം രൂപപ്പെടുന്നില്ല.

ഘട്ടം 4: ഗതാഗതം നിയന്ത്രണ കൈമാറ്റം എത്തിക്കുന്നുണ്ടെന്ന് പരിശോധിക്കുക

അടുത്തതായി, overlay ഉദ്ദേശിച്ച അറ്റങ്ങൾക്കിടയിൽ നിയന്ത്രണ ട്രാഫിക് യഥാർത്ഥത്തിൽ വഹിക്കുന്നുണ്ടെന്ന് പരിശോധിക്കുക. പിയറിന്റെ NHRP മാപ്പിംഗും അതിലേക്കെത്തുന്ന പുറം റൂട്ടും പരിശോധിച്ച്, ടണൽ ഇന്റർഫേസ് മുകളിലാണെന്നും ട്രാഫിക് കടത്തിവിടുന്നുവെന്നും സ്ഥിരീകരിക്കുക. വിജയകരമായ underlay ping പുറം പാതയുണ്ടെന്ന് തെളിയിക്കുന്നു; overlay നിയന്ത്രണ കൈമാറ്റം എത്തിയെന്ന് തെളിയിക്കുന്നില്ല.

സുതാര്യമായ Layer 2 സേവനം, പോയിന്റ്-ടു-പോയിന്റ് ടണൽ, മൾട്ടിപോയിന്റ് DMVPN ക്ലൗഡ് എന്നിവ മൾട്ടികാസ്റ്റ് വ്യത്യസ്ത രീതികളിൽ എത്തിക്കുന്നു. മൂന്നും ഒരുപോലെ പ്രവർത്തിക്കുമെന്ന് കരുതുന്നതിന് പകരം യഥാർത്ഥത്തിൽ വിന്യസിച്ചതിന് പിന്തുണയുള്ള ഇന്റർഫേസ്, NHRP, മൾട്ടികാസ്റ്റ് മാതൃക പിന്തുടരുക.

ഘട്ടം 5: പങ്കെടുക്കാൻ കഴിയില്ലെങ്കിൽ അതിർത്തി പുനർരൂപകൽപ്പന ചെയ്യുക

ആവശ്യമായ overlay ഉപകരണത്തിന് പ്രോട്ടോക്കോൾ പ്രവർത്തിപ്പിക്കാൻ കഴിയില്ലെങ്കിൽ ഡിസൈൻ വ്യക്തമായി മാറ്റുക. ആ അതിർത്തിയിൽ പിന്തുണയുള്ള പ്രോട്ടോക്കോളോ കൈമാറ്റ മാതൃകയോ ഉപയോഗിക്കുക, അല്ലെങ്കിൽ അയൽക്കാർ യഥാർത്ഥത്തിൽ പരസ്പരം സംസാരിക്കുന്ന അറ്റങ്ങളാകാൻ അനുയോജ്യമായ എൻഡ്-ടു-എൻഡ് ടണൽ ഒരുക്കുക. സ്ഥിര റൂട്ട് പങ്കെടുക്കാത്തവനെ ഓരോ നിയന്ത്രണ പാക്കറ്റിനും റിലേയാക്കി മാറ്റുമെന്ന് കരുതരുത്.

ഡയഗ്രാമിൽ ഓരോ ഉപകരണത്തിന്റെയും റോൾ രേഖപ്പെടുത്തി അത് കോൺഫിഗറേഷനൊപ്പം സൂക്ഷിക്കുക. RFC 7868 പ്രോട്ടോക്കോൾ കൈമാറ്റം നിർവചിക്കുന്നു, ആ നിർവചനമാണ് ട്രാൻസിറ്റ് ഫോർവേഡിംഗ് കൊണ്ട് അയൽബന്ധം അനുകരിക്കാൻ കഴിയാത്തതിന്റെ അടിസ്ഥാനം.

അഞ്ച് പരിശോധനകൾക്ക് ശേഷവും അയൽബന്ധം പരാജയപ്പെടുന്നുവെങ്കിൽ, ബാക്കിയുള്ള സംശയിതർ ടണൽ ഇന്റർഫേസിലെ മൾട്ടികാസ്റ്റ് കൈകാര്യം ചെയ്യലും 88 പ്രോട്ടോക്കോൾ ഫിൽട്ടർ ചെയ്യുന്ന നയവും പോലുള്ള പ്ലാറ്റ്ഫോം സവിശേഷതകളാണ്. ഇവ കൃത്യവും പരിശോധിക്കാവുന്നതുമായ കാരണങ്ങളാണ്, നടുവിലെ റൗട്ടറിനെ കുറ്റപ്പെടുത്തുന്ന മറ്റൊരു റൗണ്ടിനേക്കാൾ അവ വിലപ്പെട്ടതാണ്.