ASA VTI-യിൽ OSPF അല്ലെങ്കിൽ EIGRP: നിങ്ങളുടെ റിലീസ് ഏതിനെ പിന്തുണയ്ക്കുന്നു
OSPFv2-യും EIGRP-യും ASA VTI-യിലൂടെ 9.19(1) മുതൽ മാത്രം, multicast പ്രവർത്തനക്ഷമമാക്കിയാൽ മാത്രം കടന്നുപോകുന്നു. നിങ്ങൾ പ്രവർത്തിപ്പിക്കുന്ന റിലീസിൽ രണ്ടും താരതമ്യം ചെയ്ത്, ശേഷം അയൽക്കാരെ പരിശോധിക്കുക.
OSPF-യും EIGRP-യും തമ്മിലുള്ള ചർച്ചകളിൽ മിക്കതും ടണലിന് ഇതിനകം പ്രോട്ടോക്കോൾ വഹിക്കാനാകും എന്ന് അനുമാനിക്കുന്നു; ASA-യിൽ ആദ്യം പരിശോധിക്കേണ്ട ഭാഗം ആ അനുമാനം തന്നെയാണ്. ഇമേജ്, VTI തരം, multicast പാത എന്നിവ സ്ഥിരീകരിച്ചതിനു ശേഷം മാത്രമേ താരതമ്യം രസകരമാകൂ. ഈ ക്രമം തെറ്റിയാൽ, ഒരിക്കലും അയൽബന്ധം ഉണ്ടാകാത്ത ടണലിൽ ടൈമറുകൾ ക്രമീകരിച്ച് ഒരു പിടി സമയം കളയും. ഈ ഓരോ ഡിസൈനും ഞാൻ റിലീസ് കുറിപ്പുകളിലും പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷനിലും തുടങ്ങുന്നു, പ്രോട്ടോക്കോൾ മുൻഗണനയിലല്ല.
പ്രോട്ടോക്കോളിന് മുമ്പ് റിലീസാണ് തീരുമാനിക്കുന്നത്
ASA 9.24-നുള്ള Cisco-യുടെ VTI ഗൈഡ് ഉപയോഗപ്രദമായ ഡോക്യുമെന്റേഷൻ അടിത്തറയാണ്: സ്റ്റാറ്റിക്, ഡൈനാമിക് VTI വിവരിക്കുകയും സ്റ്റാറ്റിക് റൂട്ടിംഗ്, BGP, OSPF, EIGRP എന്നിവ പട്ടികപ്പെടുത്തുകയും ചെയ്യുന്നു. അതിന്റെ ഫീച്ചർ ചരിത്രം VTI-യിലെ OSPFv2, EIGRP പിന്തുണ 9.19(1)-ൽ ആണ്. അതിനേക്കാൾ പഴയത് മറ്റൊരു സംഭാഷണമാണ്.
അതിനാൽ ആദ്യ രണ്ട് ചോദ്യങ്ങൾ വിരസവും നിർണായകവുമാണ്:
| Check | What decides it |
|---|---|
| Image and release | Whether the feature history lists OSPFv2 or EIGRP on VTI for the version you run |
| VTI type | Static or dynamic, and which routing context the platform permits |
| Multicast on the tunnel | Whether it is enabled, and whether the group limits are respected |
ASA-യ്ക്ക് VTI ഉപയോഗിക്കാനാവില്ല, അല്ലെങ്കിൽ IGP വഹിക്കാനാവില്ല എന്ന പ്രസ്താവന ചില പഴയ ഇമേജുകൾക്ക് ശരിയായിരുന്നു, ഇന്നത്തെ പിന്തുണാ മാട്രിക്സ് അല്ല. അതുപോലെ, 9.24 ഗൈഡ് ഓരോ ഉപകരണവും അപ്ഗ്രേഡ് ചെയ്യാനുള്ള നിർദ്ദേശമല്ല. ആ റിലീസ് എന്തിനെ പിന്തുണയ്ക്കുന്നു എന്ന് അത് പറയുന്നു; നിങ്ങളുടെ വിന്യസിച്ച റിലീസ് സ്വയം ഉത്തരം നൽകണം.
unicast കടന്നുപോകുന്നത് IGP രൂപപ്പെടും എന്ന് അർത്ഥമാക്കുന്നില്ല
അതേ ഗൈഡ് പറയുന്നത്, unicast സ്വതേ കടന്നുപോകുന്നു എന്നും VTI-യിൽ OSPFv2 അല്ലെങ്കിൽ EIGRP-യ്ക്ക് multicast പ്രവർത്തനക്ഷമമാക്കണം എന്നും, multicast ഗ്രൂപ്പുകളിൽ രേഖപ്പെടുത്തിയ പരിധികളോടെ. ആ ഒരു വാക്യം ഈ ഡിസൈനിൽ ഞാൻ കണ്ട മിക്ക പരാജയപ്പെട്ട അയൽബന്ധങ്ങളും വിശദീകരിക്കുന്നു. ടണലിലൂടെ പ്രവർത്തിക്കുന്ന ping, അല്ലെങ്കിൽ പച്ച IPsec നില, unicast പാത മാത്രം തെളിയിക്കുന്നു. പ്രോട്ടോക്കോൾ കണ്ടെത്തലിന് multicast പാത വേണം, രണ്ടും വെവ്വേറെ കോൺഫിഗർ ചെയ്യുന്നു.
hello അല്ലെങ്കിൽ hold ടൈമറുകൾ തൊടുന്നതിന് മുമ്പ് ടണൽ ഇന്റർഫേസ് കോൺഫിഗറേഷനിൽ ആ multicast ക്രമീകരണം പരിശോധിക്കുക. ക്രമീകരണം ഇല്ലെങ്കിൽ, അയൽബന്ധം മന്ദഗതിയല്ല, അസാധ്യമാണ്.
ഒരേ ടണലിൽ OSPF-യും EIGRP-യും ഒപ്പം
ടണലിൽ തന്നെ രണ്ട് പ്രോട്ടോക്കോളുകളും മറ്റെവിടെയുമുള്ളതുപോലെ കാണപ്പെടുന്നു. OSPF-ന് പൊരുത്തപ്പെടുന്ന നെറ്റ്വർക്ക് തരം, ഏരിയ, പ്രാമാണീകരണം, അയൽ പാരാമീറ്ററുകൾ ആവശ്യമാണ്; EIGRP-ന് അതിന്റെ AS നമ്പറും അതിനൊപ്പമുള്ള ഇന്റർഫേസ് തല ക്രമീകരണങ്ങളും ആവശ്യമാണ്.
മറ്റൊരു ടണൽ മോഡലിൽ നിന്ന് അയൽ പ്രസ്താവനകൾ പകർത്തുന്നതാണ് കെണി. VTI ഇല്ലാത്ത ഡിസൈനിലെ സ്റ്റാറ്റിക് അയൽക്കാരെക്കുറിച്ചുള്ള ഉപദേശം multicast ഒഴിവാക്കാനായിരുന്നു, അത് പ്രോട്ടോക്കോൾ സ്വാഭാവികമായി വഹിക്കേണ്ട VTI-യിലേക്ക് പകരുന്നില്ല. പിന്തുണയുള്ള ഇന്റർഫേസ് പെരുമാറ്റം കോൺഫിഗർ ചെയ്ത്, പിന്നീട് പ്രോട്ടോക്കോൾ സ്വന്തം അയൽബന്ധം രൂപപ്പെടുത്തട്ടെ.
തുടർന്ന് നിങ്ങളുടെ ടോപ്പോളജിക്ക് യഥാർത്ഥത്തിൽ വ്യത്യാസമുള്ള അച്ചുതണ്ടുകളിൽ താരതമ്യം ചെയ്യുക: മറുവശവുമായുള്ള പരസ്പരപ്രവർത്തനക്ഷമത, പരിശോധിക്കാനാകുന്ന കൺവർജൻസ് പെരുമാറ്റം, നിങ്ങളുടെ ടീമിലെ പ്രവർത്തന അറിവ്. ഒരു പ്രോട്ടോക്കോൾ വേഗമേറിയതോ ഭാരം കുറഞ്ഞതോ എന്ന ചരിത്രകഥ നിങ്ങളുടെ നെറ്റ്വർക്കിന്റെ അളവല്ല.
അയൽക്കാർ ഇൻസ്റ്റാൾ ചെയ്ത റൂട്ടുകൾക്ക് തുല്യമല്ല
അയൽബന്ധം ഉയർന്നാൽ, ഉത്ഭവിക്കുന്നതിനെ സ്വീകരിക്കുന്നതിൽ നിന്ന് വേർതിരിക്കുക. ഓരോ വശവും ഏത് ബ്രാഞ്ച് പ്രിഫിക്സുകൾ പ്രഖ്യാപിക്കുന്നു, ഏത് സ്വീകരിക്കുന്നു, ഏത് തിരഞ്ഞെടുക്കുന്നു, ഏത് യഥാർത്ഥത്തിൽ റൂട്ടിംഗ് പട്ടികയിൽ എത്തുന്നു എന്ന് നോക്കുക. ഇംപോർട്ട്, എക്സ്പോർട്ട്, പുനർവിതരണം എന്നിവയുടെ പരിധി ഉപകരണത്തിന് അറിയാവുന്നതെല്ലാം ഒരുപോലെ പ്രഖ്യാപിക്കുന്നതല്ല, ബോധപൂർവമായിരിക്കണം.
show ospf neighbor ഒപ്പം show eigrp neighbors സെഷൻ ജീവിച്ചിരിക്കുന്നു എന്ന് നിങ്ങളോട് പറയുന്നു. show route ബ്രാഞ്ച് പ്രിഫിക്സ് എത്തിയോ എന്ന് നിങ്ങളോട് പറയുന്നു, ഇവ വ്യത്യസ്ത ചോദ്യങ്ങളാണ്.
അപ്ലിക്കേഷൻ പാത വീണ്ടും മൂന്നാമത്തെ ചോദ്യമാണ്. അയൽബന്ധം എത്തിച്ചേരാനുള്ള കഴിവ് വിതരണം ചെയ്യുന്നു; അത് ഫയർവാളിലൂടെ അനുമതി നൽകുന്നില്ല, ട്രാഫിക് സെലക്ടറുകളും ഫിൽട്ടറിംഗ് നിയമങ്ങളും യോജിക്കുന്നു എന്ന് തെളിയിക്കുന്നുമില്ല. റൂട്ട് എന്നാൽ നയം എന്ന് അനുമാനിക്കുന്നതിനുപകരം അനുവദിച്ച ഫ്ലോയും അതിന്റെ മറുപടി പാതയും അംഗീകൃത പരിശോധനയിലൂടെ സ്ഥിരീകരിക്കുക.
പൂർത്തിയായ താരതമ്യം എന്ത് രേഖപ്പെടുത്തണം
ടണൽ ഇന്റർഫേസ്, അതിനെ പിന്തുണയ്ക്കുന്ന റിലീസ്, നിങ്ങൾ പരിശോധിച്ച നിയന്ത്രണ കൈമാറ്റം, നിങ്ങൾ പരിധി നിശ്ചയിച്ച റൂട്ട് നയം എന്നിവ എഴുതുക. multicast ക്രമീകരണം കൂട്ടിച്ചേർക്കുക; ബാക്കിയുള്ളവ പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് നിശ്ശബ്ദമായി തീരുമാനിക്കുന്നത് ആ വിശദാംശമാണ്. ആ രേഖ വിന്യസിച്ച റിലീസിന് അടുത്ത് സൂക്ഷിക്കുക, അപ്പോൾ പിന്നീടുള്ള ഫീച്ചർ മാറ്റം ഇതിനകം കാലഹരണപ്പെട്ട അനുമാനത്തിൽ നിന്ന് വീണ്ടും തുടങ്ങാതെ പരിശോധിക്കാം.
ആ നാലിൽ ഏതെങ്കിലും ഇല്ലെങ്കിൽ, നിങ്ങൾക്ക് ഡിസൈനല്ല, മുൻഗണനയാണ്. ആദ്യം കാണാത്ത വസ്തുത ശരിയാക്കുക; പ്രോട്ടോക്കോൾ തിരഞ്ഞെടുക്കൽ എളുപ്പമുള്ള ഭാഗമാണ്.