L3VPN കൈമാറ്റം: സ്വകാര്യ റൂട്ടുകൾ, ഡിഫോൾട്ട്, അതോ മുഴുവൻ പട്ടികയോ?

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

കൈമാറ്റം ക്രമത്തിൽ പരിശോധിക്കുന്നതാണ് ഇത് ശരിയായി ചെയ്യാനുള്ള ഏറ്റവും വിലകുറഞ്ഞ വഴി. ഒന്നിനോടും പൊരുത്തപ്പെടാത്ത ട്രാഫിക്കിന് എന്ത് സംഭവിക്കുന്നു എന്നതിൽ നിന്ന് തുടങ്ങി, സ്വകാര്യ പ്രിഫിക്സുകളും അവയുടെ പരാജയ സ്വഭാവവും എഴുതി, അതിനുശേഷം മാത്രം എത്ര വലിയ ഫീഡ് വഹിക്കാൻ തയ്യാറാണ് എന്ന് സംസാരിക്കുക.

ആരും ആസൂത്രണം ചെയ്യാത്ത ട്രാഫിക്കിൽ നിന്ന് തുടങ്ങുക

പ്രിഫിക്സ് പട്ടിക വരുന്നതിന് മുൻപ് ഒരു ചോദ്യം ചോദിക്കുക: പാക്കറ്റ് ഏതെങ്കിലും സ്വകാര്യ റൂട്ടുമായി പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ അത് എവിടെ പോകണം? സ്വന്തം ഇന്റർനെറ്റ് സർക്യൂട്ടുള്ള ശാഖ സാധാരണയായി പ്രാദേശിക ഡിഫോൾട്ട് സൂക്ഷിക്കുന്നു, അതിനാൽ സാധാരണ വെബ് ട്രാഫിക് പ്രാദേശിക ഫയർവാൾ വഴി പുറത്തുപോകുന്നു, ദാതാവിനെ ഒരിക്കലും തൊടുന്നില്ല. ആ ഡിസൈനിൽ VPN വിദൂര സ്വകാര്യ സൈറ്റുകൾ മാത്രം വഹിക്കുന്നു, കൂടുതൽ നിർദ്ദിഷ്ടമായ പ്രിഫിക്സുകളാണ് തിരഞ്ഞെടുപ്പ് നടത്തുന്നത്.

കേന്ദ്ര എക്സിറ്റ് ഉപയോഗിക്കാൻ ഉദ്ദേശിക്കുന്ന ശാഖ വിപരീത സാഹചര്യമാണ്. അവിടെ ഡിഫോൾട്ട് സേവനത്തിനുള്ളിലേക്ക് ചൂണ്ടുന്നു, ഫോർവേഡിംഗും റിട്ടേൺ റൂട്ടിംഗും ഏതെങ്കിലും വിവർത്തനവും ദാതാവോ കേന്ദ്ര സൈറ്റോ കൈവശം വയ്ക്കുന്നു. ആ ഉടമയില്ലാതെ "VPN-ലേക്ക് ഡിഫോൾട്ട്" എന്ന് പറഞ്ഞാൽ പേരുകൾ പരിഹരിക്കുന്ന, പക്ഷേ ഒന്നും എത്തിച്ചേരാത്ത ശാഖ ഉണ്ടാകും.

രണ്ട് ഡിസൈനുകളും റൂട്ടിംഗ് പരാജയം എങ്ങനെ കാണപ്പെടുന്നു എന്നതിൽ വ്യത്യസ്തമാണ്, അതുകൊണ്ടാണ് ഊഹിക്കുന്നത് ചെലവേറിയത്. പ്രാദേശിക ഡിഫോൾട്ടിലൂടെ, നഷ്ടപ്പെട്ട സ്വകാര്യ റൂട്ട് ആ ട്രാഫിക്കിനെ ഇന്റർനെറ്റിലേക്ക് അയയ്ക്കുന്നു, അവിടെ ഫയർവാൾ അത് ഉപേക്ഷിക്കുന്നു, അല്ലെങ്കിൽ അതിലും മോശമായി, നിങ്ങൾ ഉദ്ദേശിക്കാത്ത എന്തോ മറുപടി നൽകുന്നു. കേന്ദ്ര ഡിഫോൾട്ടിലൂടെ, അതേ നഷ്ടം ഇന്റർനെറ്റ് ആക്സസ് പൂർണ്ണമായി നീക്കം ചെയ്യുന്നു, ടിക്കറ്റ് "മുഴുവൻ ശാഖയും തകർന്നു" എന്ന രൂപത്തിൽ എത്തുന്നു. ഓരോ പരാജയവും സ്വതേ തെറ്റല്ല, പക്ഷേ നിങ്ങൾ വിറ്റ സേവനവുമായി പൊരുത്തപ്പെടുന്നത് ഒന്ന് മാത്രം, BGP കോൺഫിഗറേഷൻ മാത്രം ഏതാണ് നിർമ്മിച്ചതെന്ന് പറയില്ല.

സ്വകാര്യ പ്രിഫിക്സുകൾ അവയുടെ പരാജയ സാഹചര്യത്തോടൊപ്പം എഴുതുക

ശാഖ എത്തിച്ചേരേണ്ട പ്രിഫിക്സുകൾ പട്ടികപ്പെടുത്തി അവയിൽ ഏതാണ് സംഗ്രഹിച്ചതെന്ന് രേഖപ്പെടുത്തുക. ഒരു ബിറ്റ് അധികം വീതിയുള്ള അഗ്രിഗേറ്റ് അജ്ഞാത ലക്ഷ്യസ്ഥാനങ്ങളെ VPN-ലേക്ക് വലിച്ചിടുന്നു, ദൂരെയുള്ള വശം അവ യഥാർത്ഥത്തിൽ കൈവശം വച്ച് ഫോർവേഡ് ചെയ്യുന്നെങ്കിൽ മാത്രമേ അത് ശരിയാകൂ.

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

ലഭ്യതയും അനുവദനീയമായ ബാക്കപ്പും കൈമാറ്റ രേഖയിൽ രണ്ട് വേറിട്ട ആവശ്യകതകളായി നിലനിർത്തുക. അവ കൂട്ടിച്ചേർക്കുന്ന ടീമുകൾ യോജിച്ച നയം നടപ്പാക്കിയോ എന്ന് പരിശോധിക്കുന്നതിന് പകരം ശാഖ പരാജയപ്പെടേണ്ടതായിരുന്നോ എന്ന് വാദിക്കും.

CE യഥാർത്ഥത്തിൽ എന്ത് ഇൻസ്റ്റാൾ ചെയ്തു എന്ന് പരിശോധിക്കുക

കോൺഫിഗറേഷൻ ഉദ്ദേശ്യവും ഫോർവേഡിംഗ് അവസ്ഥയും മതിയായ പലപ്പോഴും വ്യത്യാസപ്പെടുന്നതിനാൽ പരിശോധന കൈമാറ്റത്തിലാണ് വേണ്ടത്, സംഭവ അവലോകനത്തിലല്ല. IOS-XE കസ്റ്റമർ എഡ്ജിൽ താഴെയുള്ള മൂന്ന് കമാൻഡുകൾ മൂന്ന് വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു: എന്ത് വാഗ്ദാനം ചെയ്തു, എന്ത് സ്വീകരിച്ചു, എന്താണ് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്നത്.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

മൂന്നും കൈമാറ്റ ദിവസം തന്നെ പ്രവർത്തിപ്പിക്കുക, ഒരു മാസത്തിന് ശേഷമല്ല, എന്ത് യോജിച്ചു എന്ന് ആർക്കെങ്കിലും ഇപ്പോഴും ഓർമ്മയുള്ളപ്പോൾ. ആദ്യ ഔട്ട്പുട്ട് soft-reconfiguration inbound അല്ലെങ്കിൽ സംഭരിച്ച route refresh-നെ ആശ്രയിച്ചിരിക്കുന്നു; രണ്ടുമില്ലാതെ CE എന്ത് നിരസിച്ചു എന്ന് കാണിക്കാനാവില്ല. രണ്ടാമത്തേത് നയത്തിന് ശേഷമുള്ള സ്വീകരിച്ചതും മികച്ചതുമായ റൂട്ടുകൾ കാണിക്കുന്നു. മൂന്നാമത്തേത് ഡിഫോൾട്ട് യഥാർത്ഥത്തിൽ എവിടെ പോകുന്നു എന്ന് പറയുന്നു, അതാണ് മുഴുവൻ കൈമാറ്റത്തിലെയും ഏറ്റവും ഉപയോഗപ്രദമായ വരി.

സൈറ്റ് ഇരട്ട കണക്ഷനുള്ളതാണെങ്കിൽ രണ്ടാമത്തെ CE-യിലും അതേ പരിശോധനകൾ നടത്തുക. രണ്ട് എഡ്ജുകൾക്കിടയിലുള്ള അസമമായ സ്വീകരണം "ഒരു സെർവറിൽ നിന്ന് പ്രവർത്തിക്കുന്നു, മറ്റൊന്നിൽ നിന്ന് ഇല്ല" എന്നതിന്റെ സാധാരണ കാരണമാണ്, സമമിതിയായി തോന്നുന്ന കോൺഫിഗറേഷൻ diff-ൽ അത് കാണാനാവില്ല.

വലിയ ഫീഡ് അനുമാനിക്കാതെ അതിന് യോഗ്യത നിർണ്ണയിക്കുക

ചിലപ്പോൾ ഉപഭോക്താവിന് VRF-നുള്ളിൽ ഇന്റർനെറ്റ് റൂട്ട് വിവരങ്ങൾ യഥാർത്ഥത്തിൽ ആവശ്യമാണ്, പോളിസി റൂട്ടിംഗിനോ പ്രിഫിക്സ് അനുസരിച്ച് നയിക്കുന്ന കേന്ദ്ര എക്സിറ്റിനോ വേണ്ടി. അത് പ്രഖ്യാപിക്കേണ്ടതും പരിധി നിർണ്ണയിക്കേണ്ടതും വിലയിടേണ്ടതുമായ ആവശ്യകതയാണ്, മറഞ്ഞ ഡിഫോൾട്ടല്ല. അതിനൊപ്പം RIB-ക്കും FIB-ക്കുമുള്ള മെമ്മറി, അപ്ഡേറ്റുകൾക്കുള്ള CPU, ഫിൽട്ടർ പരിപാലനം, ഉണ്ടാകുന്ന പട്ടികയുടെ ഉടമ എന്നിവ വരുന്നു.

ശേഷി സംബന്ധിച്ച വാദങ്ങൾ രണ്ട് ദിശകളിലും തെറ്റാകുന്നു. പൂർണ്ണ പട്ടിക VRF-നുള്ളിൽ വിലക്കപ്പെട്ടിട്ടില്ല, അത് സൗജന്യവുമല്ല. അതുപോലെ, പഴയ റൂട്ട് എണ്ണത്തിൽ നിന്ന് ഇന്നത്തെ ചെലവ് അനുമാനിക്കാനാവില്ല, ചെറിയ ലേബൽ വിഭജനം റൂട്ടുകൾ സൂക്ഷിക്കുന്നതിന്റെ ചെലവ് ഒഴിവാക്കുന്നുമില്ല.

BGP/MPLS IP VPN സ്പെസിഫിക്കേഷൻ VPN സേവനത്തിനൊപ്പം ഒട്ടനവധി ഇന്റർനെറ്റ് ആക്സസ് ക്രമീകരണങ്ങൾ ചർച്ച ചെയ്യുന്നു, ഓരോ ഉപഭോക്താവിനും പൂർണ്ണ പട്ടികയോ ഡിഫോൾട്ടോ നിർബന്ധമാണെന്ന് പ്രഖ്യാപിക്കുന്നില്ല, "സാധാരണ പ്രയോഗം" എന്ന അവകാശവാദം വരുമ്പോൾ ചൂണ്ടിക്കാണിക്കാൻ യോഗ്യമായ ഭാഗം അതാണ്: RFC 4364.

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