പേരുള്ളതും അക്കമിട്ടതുമായ DMVPN ഹബ്: FQDN എന്താണ് മാറ്റുന്നത്

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

രണ്ട് വിലാസങ്ങൾ, രണ്ട് ജോലികൾ

പ്രഖ്യാപിത ഉദാഹരണത്തിൽ, hub.example.net സ്പോക്കിനോട് ഗതാഗത ട്രാഫിക് എവിടെ അയക്കണമെന്ന് പറയുന്നു, 10.90.0.1 ടണലിനുള്ളിലെ NHS തിരിച്ചറിയുന്നു. കണ്ടെത്തൽ ആദ്യത്തേതിൽ പ്രവർത്തിക്കുന്നു; രജിസ്ട്രേഷനും റൂട്ടിംഗും രണ്ടാമത്തേതിൽ പ്രവർത്തിക്കുന്നു. പേരിന്റെ മാറ്റം അന്ത്യബിന്ദുവിലേക്കുള്ള വഴിയെ ബാധിക്കുന്നു, എന്നാൽ പ്രോട്ടോക്കോൾ വിലാസത്തിന്റെ മാറ്റം overlay ബന്ധത്തെത്തന്നെ ബാധിക്കുന്നു.

റോളുകൾ വേർതിരിച്ചു നിർത്തുന്നതാണ് പേരുള്ള രൂപത്തെ ഡീബഗ് ചെയ്യാവുന്നതാക്കുന്നത്. ഒരു സ്പോക്കിന് രജിസ്റ്റർ ചെയ്യാനാകാതെ വരുമ്പോൾ, നിങ്ങൾക്ക് രണ്ട് വ്യത്യസ്ത ചോദ്യങ്ങൾ ചോദിക്കാം: ഞാൻ പ്രതീക്ഷിച്ച വിലാസത്തിലേക്കാണോ പേര് പരിഹരിക്കപ്പെട്ടത്, ആ വിലാസം കോൺഫിഗറേഷൻ അവകാശപ്പെടുന്ന പ്രോട്ടോക്കോൾ വിലാസവുമായി പൊരുത്തപ്പെട്ടോ? ഒരു ഉത്തരവും മറ്റേതിനെ സൂചിപ്പിക്കുന്നില്ല.

രണ്ട് കോൺഫിഗറേഷൻ രൂപങ്ങൾ താരതമ്യം ചെയ്യുക

ഒരു രൂപം പേരിനൊപ്പം NHS പ്രോട്ടോക്കോൾ വിലാസം വ്യക്തമായി കോൺഫിഗർ ചെയ്യുന്നു. മറ്റൊന്ന് രജിസ്ട്രേഷൻ മറുപടിയിൽ നിന്ന് ആ പ്രോട്ടോക്കോൾ വിലാസം പഠിക്കാൻ സ്പോക്കിനെ അനുവദിക്കുന്നു. രണ്ടും രേഖപ്പെടുത്തിയിട്ടുണ്ട്, വിജയിക്കുമ്പോൾ രണ്ടും ഒരേ തരത്തിലുള്ള NHS ബന്ധത്തിൽ അവസാനിക്കുന്നു.

വ്യക്തമായ രൂപത്തിന് ഓർമ്മിക്കാൻ യോഗ്യമായ ഒരു പരിമിതിയുണ്ട്: കോൺഫിഗർ ചെയ്ത പ്രോട്ടോക്കോൾ വിലാസത്തിലേക്ക് മാപ്പ് ചെയ്യാത്ത പരിഹരിച്ച ഗതാഗത വിലാസം രജിസ്ട്രേഷനെ തടയുന്നു. ഇത് DNS പരാജയമല്ല, എന്നിരുന്നാലും DNS മാറ്റത്തിന് തൊട്ടുപിന്നാലെ ലക്ഷണം പ്രത്യക്ഷപ്പെടുന്നു. പേര് ശരിയായി പരിഹരിക്കപ്പെട്ടു, ഫലം മറ്റൊരു കാരണത്താൽ നിരസിക്കപ്പെട്ടു. പരിഹരിച്ച വിലാസവും കോൺഫിഗർ ചെയ്ത പ്രോട്ടോക്കോൾ വിലാസവും അടുത്തടുത്ത് വായിക്കുക.

പഠന രൂപം ഒരു കൈകൊണ്ടുള്ള ഘട്ടവും ഒരു ഡ്രിഫ്റ്റ് ഉറവിടവും നീക്കം ചെയ്യുന്നു, പകരം മാപ്പിംഗ് സ്ഥാപിക്കാൻ മറുപടിയെ ആശ്രയിക്കുന്നു. ഹബ് വിലാസം സ്ഥിരമാണെങ്കിൽ, പൊരുത്തക്കേട് ഉച്ചത്തിൽ പരാജയപ്പെടണമെന്ന് നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ വ്യക്തമായ രൂപം തിരഞ്ഞെടുക്കുക. ഹബ് പ്രോട്ടോക്കോൾ വിലാസം മാറാമെങ്കിൽ, സ്പോക്ക് അത് പിന്തുടരണമെന്ന് നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ പഠന രൂപം തിരഞ്ഞെടുക്കുക. ഏതായാലും, ഡിസൈൻ ഏത് രൂപമാണ് ഉപയോഗിക്കുന്നതെന്ന് രേഖപ്പെടുത്തുക.

DNS കാഷിനെ സ്ഥിര ഹബുമായി താരതമ്യം ചെയ്യുക

ആരെങ്കിലും കോൺഫിഗറേഷൻ എഡിറ്റ് ചെയ്യുമ്പോൾ സ്ഥിര ഹബ് വിലാസം മാറുന്നു. DNS മാറുമ്പോൾ പേരുള്ള ഹബ് മാറുന്നു, DNS മറുപടികൾ അവയുടെ ജീവിതകാലം മുഴുവൻ കാഷ് ചെയ്യപ്പെടുന്നു. കാഷ് ചെയ്ത വിവരങ്ങൾ കാലഹരണപ്പെടുന്നതുവരെ ഉപയോഗയോഗ്യമായി തുടരുന്നു എന്നും, പിന്നീടുള്ള ഒരു ചോദ്യത്തിന് പുതിയ വിലാസം ലഭിക്കാമെന്നും രേഖകൾ പറയുന്നു.

ആ വ്യത്യാസം സമയ വ്യത്യാസമാണ്, തൽക്ഷണ കുടിയേറ്റമല്ല. ദീർഘമായ കാഷ് ജീവിതകാലം പുനർനാമകരണം ചെയ്ത അന്ത്യബിന്ദുവിന്റെ സ്വീകരണം വൈകിപ്പിക്കുന്നു, DNS റെക്കോർഡ് മാത്രം നിരീക്ഷിച്ചാൽ കാലതാമസം കാണാനാകില്ല. എല്ലാ ടണലുകളും ഒരുമിച്ച് നീങ്ങുന്നു എന്ന് കരുതുന്നതിനുപകരം കാഷ് ജീവിതകാലത്തിന്റെയും ഇൻസ്റ്റാൾ ചെയ്ത റിലീസിന്റെ രജിസ്ട്രേഷൻ സ്വഭാവത്തിന്റെയും ചുറ്റും പുനർനാമകരണം ആസൂത്രണം ചെയ്യുക.

സ്ഥിര രൂപത്തിന് സ്വാഭാവികമായും സ്വന്തം കാലതാമസമുണ്ട്: ഓരോ സ്പോക്കും എഡിറ്റ് ചെയ്യുന്നതുവരെ ഒന്നും മാറുന്നില്ല. താരതമ്യം ഏകോപിപ്പിച്ച കോൺഫിഗറേഷൻ തള്ളലും കാഷ് ചെയ്ത കണ്ടെത്തൽ പുതുക്കലും തമ്മിലാണ്, പതുക്കയും തൽക്ഷണവും തമ്മിലല്ല.

എന്ത് അതേപടി തുടരുന്നു എന്ന് താരതമ്യം ചെയ്യുക

പിയർ പ്രാമാണീകരണം നീങ്ങുന്നില്ല. ഗതാഗത അന്ത്യബിന്ദു കണ്ടെത്തുന്ന ഹോസ്റ്റ്നാം കോൺഫിഗർ ചെയ്ത IKE ഐഡന്റിറ്റിയെയോ പിയറിനെ സാധൂകരിക്കുന്ന പ്രാമാണീകരണ നയത്തെയോ മാറ്റിസ്ഥാപിക്കുന്നില്ല. ഐഡന്റിറ്റി തെറ്റാണെങ്കിൽ, വിജയകരമായ DNS പരിഹാരം നിങ്ങളെ നിരസിക്കപ്പെട്ട ടണലിലേക്ക് വേഗത്തിൽ എത്തിക്കുക മാത്രം ചെയ്യുന്നു.

സംരക്ഷിത ട്രാഫിക്കും മാറ്റമില്ല. പ്രതികരിക്കുന്ന NHS ഉപഭോക്തൃ റൂട്ട് നിലവിലുണ്ടെന്നോ ആപ്ലിക്കേഷൻ ഫ്ലോ അനുവദനീയമാണെന്നോ തെളിയിക്കുന്നില്ല. രജിസ്ട്രേഷൻ, റൂട്ടിംഗ്, നയം എന്നിവ മൂന്ന് പരിശോധനകളാണ്, പേര് അവയെ പോഷിപ്പിക്കുന്ന ആദ്യ ഘട്ടത്തെ മാത്രം ബാധിക്കുന്നു.

നിങ്ങൾക്ക് പരിശോധിക്കാവുന്ന താരതമ്യം

Cisco സെഷനും NHS ബന്ധത്തിനും വേർതിരിച്ച നിരീക്ഷണങ്ങൾ രേഖപ്പെടുത്തുന്നു. പിയറിന്റെയും സെഷന്റെയും അവസ്ഥ വായിക്കാൻ show dmvpn ഉപയോഗിക്കുക, NHS രജിസ്ട്രേഷൻ കാഴ്ച വായിക്കാൻ show ip nhrp nhs ഉപയോഗിക്കുക. പരിഹരിച്ച ഗതാഗത വിലാസം, overlay പിയർ, രജിസ്ട്രേഷൻ അവസ്ഥ എന്ന ക്രമത്തിൽ താരതമ്യം ചെയ്യുക.

IOS XE FQDN-DMVPN അധ്യായം ഈ താരതമ്യത്തിന് പിന്നിലെ കണ്ടെത്തൽ, കാഷിംഗ്, പരിമിതി സ്വഭാവം രേഖപ്പെടുത്തുന്നു. പുനർനാമകരണം ചെയ്ത ഹബിനെ അക്കമിട്ട ഹബിന്റെ നേരിട്ടുള്ള പകരക്കാരനായി കാണുന്നതിന് മുമ്പ് അത് നിങ്ങളുടെ ഇൻസ്റ്റാൾ ചെയ്ത റിലീസിനെതിരെ വായിക്കുക.