BGP പ്രിഫിക്സ് പഠിച്ചു, പക്ഷേ ട്രാഫിക് ഇപ്പോഴും ടണൽ ഒഴിവാക്കുന്നു
BGP പട്ടികയിലെ പ്രിഫിക്സ് നിയന്ത്രണ-തലത്തിലെ വാർത്തയാണ്, ഫോർവേഡിംഗ് തീരുമാനമല്ല. ടണലിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുൻപ് സ്വീകരണം, തിരഞ്ഞെടുപ്പ്, ഇൻസ്റ്റാളേഷൻ, പൊരുത്തം എന്നിവ പരിശോധിക്കുക.
ശാഖയുടെ ഗേറ്റ്വേ തന്റെ BGP പട്ടികയിൽ ക്ലൗഡ് പ്രിഫിക്സ് കാണിക്കുന്നു, ദാതാവുമായുള്ള സെഷൻ സ്ഥാപിതമാണ്, എന്നിട്ടും ആ പ്രിഫിക്സിലേക്കുള്ള ഉപയോക്താവിന്റെ അഭ്യർത്ഥന തെറ്റായ ഇന്റർഫേസിലൂടെ പുറത്തുപോകുന്നു. മോണിറ്ററിംഗ് സൂചിപ്പിക്കുന്ന രീതിയിൽ ഒന്നും തകർന്നിട്ടില്ല, കാരണം “BGP അത് പഠിച്ചു” എന്നത് നിയന്ത്രണ-തലത്തെക്കുറിച്ചുള്ള പ്രസ്താവനയാണ്. ആ പട്ടികയ്ക്കും പാക്കറ്റിനും ഇടയിൽ നാല് വേറിട്ട പരിവർത്തനങ്ങളുണ്ട്, ഒഴുക്ക് അവയിൽ കൃത്യമായി ഒന്നിൽ നിൽക്കുന്നു. ഗേറ്റുകൾ ക്രമത്തിൽ കടന്ന് ആദ്യം പരാജയപ്പെടുന്നതിൽ നിർത്തുക.
ആദ്യ ഗേറ്റ്: അയൽക്കാരൻ യഥാർത്ഥത്തിൽ അയച്ചത്
പ്രിഫിക്സിൽ നിന്ന് സംഗ്രഹിച്ച രൂപത്തിലല്ല, ലഭിച്ചതുപോലെ തന്നെ തുടങ്ങുക. BGP പട്ടികയിൽ കൃത്യമായ നെറ്റ്വർക്കും മാസ്കും കണ്ടെത്തി അടുത്ത ഹോപ്പ്, AS പാത, ഇംപോർട്ട് നയം പൊരുത്തപ്പെടാവുന്ന ഏതെങ്കിലും കമ്മ്യൂണിറ്റി എന്നിവ രേഖപ്പെടുത്തുക. ഡാഷ്ബോർഡിലെ സംഗ്രഹ റൂട്ട്, ആ നിർദ്ദിഷ്ട പ്രിഫിക്സ് ഒരിക്കലും സ്വീകരിച്ചിട്ടില്ല എന്ന വസ്തുത മറയ്ക്കാം.
ഇംപോർട്ട് നയമാണ് പിശകില്ലാതെ ഒരു റൂട്ട് അപ്രത്യക്ഷമാകുന്ന സാധാരണ സ്ഥലം. പ്രിഫിക്സ് ലിസ്റ്റ്, കമ്മ്യൂണിറ്റി ഫിൽട്ടർ അല്ലെങ്കിൽ ഇൻബൗണ്ട് റൂട്ട് മാപ്പ് എന്നിവ സെഷൻ മുകളിലും ആരോഗ്യകരവുമായിരിക്കുമ്പോൾ തന്നെ അപ്ഡേറ്റ് ഉപേക്ഷിച്ചേക്കാം, അതുകൊണ്ടാണ് പച്ച അയൽവിളക്ക് ഇത്ര കുറച്ച് തെളിയിക്കുന്നത്. ഒരു ലോഗ് വരിയുടെ അഭാവം ഒരു തീരുമാനത്തിന്റെ അഭാവമല്ല. സാധാരണയായി അത് അർത്ഥമാക്കുന്നത് തീരുമാനം നിശ്ശബ്ദമായി, കോൺഫിഗർ ചെയ്തതുപോലെ തന്നെ എടുത്തു എന്നാണ്.
show ip bgp 10.60.20.0/24 show ip bgp neighbors 203.0.113.5 advertised-routes show ip route 10.60.20.0 show ip cef 10.60.20.0
ഔട്ട്പുട്ട് ആ ക്രമത്തിൽ വായിക്കുക. ആദ്യ രണ്ട് കമാൻഡുകൾ വിവരം എത്തിയോയെന്നും പീയർ എന്താണ് അയച്ചതെന്ന് അവകാശപ്പെടുന്നതെന്നും പറയുന്നു; അവസാന രണ്ടെണ്ണം എന്തെങ്കിലും റൂട്ടിംഗ്, ഫോർവേഡിംഗ് പട്ടികകളിൽ എത്തിയോയെന്ന് പറയുന്നു. ആദ്യ കമാൻഡിൽ ഉള്ളതും മൂന്നാമത്തേതിൽ ഇല്ലാത്തതുമായ പ്രിഫിക്സ് തിരഞ്ഞെടുപ്പിന്റെയോ ഇൻസ്റ്റാളേഷന്റെയോ പ്രശ്നമാണ്, കണക്റ്റിവിറ്റിയുടെയല്ല.
രണ്ടാം ഗേറ്റ്: തിരഞ്ഞെടുപ്പ്, പിന്നെ ഇൻസ്റ്റാളേഷൻ
BGP മികച്ച പാത തിരഞ്ഞെടുക്കുന്നു, തിരഞ്ഞെടുത്ത പാത സ്വയമേവ ഇൻസ്റ്റാൾ ചെയ്യപ്പെടുന്നില്ല. അടുത്ത ഹോപ്പ് പരിഹരിക്കപ്പെടണം, കൂടാതെ മറ്റൊരു റൂട്ട് ഉറവിടത്തിന് മികച്ച അഡ്മിനിസ്ട്രേറ്റീവ് ദൂരത്തോടെ ആ പ്രിഫിക്സ് ഇതിനകം ഉണ്ടായിരിക്കാം. മൈഗ്രേഷനിൽ നിന്ന് അവശേഷിച്ച സ്റ്റാറ്റിക് റൂട്ട് സാധുവായ BGP പാതയെ എളുപ്പത്തിൽ തോൽപ്പിച്ച് ട്രാഫിക് വേറെയെങ്കിലേക്ക് അയയ്ക്കും.
RFC 4271 മൂന്ന് ആശയങ്ങൾ വേറിട്ട് നിർത്തുന്നു: പീയർ എന്ത് അയച്ചു, ഈ സ്പീക്കർ ഏതാണ് മികച്ചതായി തിരഞ്ഞെടുത്തു, ഇനി എന്ത് പ്രഖ്യാപിക്കും. ഇവ സങ്കൽപ്പികമായ റോളുകളാണ്, വിൽപ്പനക്കാരൻ വെളിപ്പെടുത്തേണ്ട മൂന്ന് ഭൗതിക ഡാറ്റാബേസുകളല്ല, പക്ഷേ ആ വേർതിരിവാണ് “അത് BGP-യിലുണ്ട്” എന്നതിനെ അപൂർണ്ണ ഉത്തരമാക്കുന്നത്.
ഏത് റൂട്ടിംഗ് സന്ദർഭമാണ് നിങ്ങൾ വായിക്കുന്നതെന്നും പരിശോധിക്കുക. ഉപയോക്താവിന്റെ ഇന്റർഫേസ് ഉൾപ്പെടാത്ത VRF-ൽ ഇൻസ്റ്റാൾ ചെയ്ത റൂട്ട് ആ ഉപയോക്താവിന്റെ പാക്കറ്റുകൾക്ക് അദൃശ്യമാണ്, പട്ടിക സദാ ശരിയായി തോന്നുന്നു.
മൂന്നാം ഗേറ്റ്: ഈ ഒഴുക്കിന് ബാധകമായ തിരയൽ
ഇപ്പോൾ റൂട്ടിനെക്കുറിച്ച് ചോദിക്കുന്നത് നിർത്തി പാക്കറ്റിനെക്കുറിച്ച് ചോദിക്കാൻ തുടങ്ങുക. ഉപയോക്താവിന്റെ ഉറവിട വിലാസം, ലക്ഷ്യം, പ്രോട്ടോക്കോൾ, പോർട്ട്, ഇൻഗ്രസ് ഇന്റർഫേസ് എന്നിവ രേഖപ്പെടുത്തുക, കാരണം അവയിൽ ഓരോന്നും വ്യത്യസ്ത നയം തിരഞ്ഞെടുക്കാം. പിന്നെ പൊതുവായ റൂട്ടിംഗ് പട്ടികയ്ക്ക് പകരം ആ സംയോജനത്തിന് ബാധകമായ തിരയൽ നോക്കുക.
ip route get 10.60.20.25 from 10.60.10.40 ip rule show sudo tcpdump -ni tun0 'host 10.60.20.25'
കൂടുതൽ നിർദ്ദിഷ്ട പ്രിഫിക്സാണ് ഇവിടെ ഏറ്റവും സാധാരണ ആശ്ചര്യം, നയ റൂട്ട് രണ്ടാമത്തേത്. രണ്ടും നിങ്ങൾ നോക്കിയിരുന്ന സമാഹാരത്തെ മറികടക്കുന്നു, ഒന്നും BGP പട്ടികയുടെ സംഗ്രഹത്തിൽ കാണുന്നില്ല.
ഗേറ്റ്വേയിൽ നിന്ന് തന്നെ അയച്ച പിംഗ് ഉപയോക്താവിന്റെ സെഷനെക്കുറിച്ചുള്ള തെളിവല്ല. വ്യത്യസ്ത ഉറവിട വിലാസം, വ്യത്യസ്ത നയ പാത, പലപ്പോഴും വ്യത്യസ്ത ഫലം. അപ്ലിക്കേഷൻ ഉപയോഗിക്കുന്ന അതേ ഉറവിടത്തോടെ പരീക്ഷിക്കുക, അല്ലെങ്കിൽ പരീക്ഷണം മറ്റൊരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു എന്ന് അംഗീകരിക്കുക.
നാലാം ഗേറ്റ്: പാതയുടെ അകലെയുള്ള പകുതി
പ്രാദേശിക തിരയൽ ടണൽ തിരഞ്ഞെടുക്കുന്നുവെങ്കിൽ, പാക്കറ്റ് ഇപ്പോഴും സംരക്ഷണ നയം സ്വീകരിക്കണം, ഫോർവേഡിംഗ് നിയമം അനുവദിക്കണം, മറുവശത്ത് എന്തെങ്കിലും ഉത്തരം നൽകണം. വിലാസ ജോഡി ഉൾപ്പെടുത്താത്ത ക്രിപ്റ്റോ ACL ടണൽ സ്വയം മുകളിലാണെന്ന് റിപ്പോർട്ട് ചെയ്യുമ്പോൾ ട്രാഫിക് ഉപേക്ഷിക്കും, ഇത് റൂട്ടിംഗ് പരാജയത്തിൽ നിന്ന് വേർതിരിക്കാൻ കഴിയാത്ത സമയപരിധി സൃഷ്ടിക്കുന്നു.
മടക്കപ്പാത പുറപ്പെടുന്ന പാതയോളം പ്രധാനമാണ്. ക്ലൗഡ് വശം ശാഖയുടെ ഉറവിടത്തിലേക്ക് എങ്ങനെ എത്തുമെന്ന് അറിയണം, ഒരു റൂട്ടിലൂടെയോ നിങ്ങൾ ബോധപൂർവം കോൺഫിഗർ ചെയ്ത വിവർത്തനത്തിലൂടെയോ. അസമമായ മടക്കപ്പാതകൾ ഒരു ദിശയിൽ മാത്രം പരീക്ഷിച്ച രൂപകൽപ്പനകളിൽ സാധാരണമാണ്.
പുതിയ അംഗീകൃത കണക്ഷനെ മൂന്ന് നിരീക്ഷണങ്ങളുമായി ബന്ധിപ്പിക്കുക: പൊരുത്തപ്പെട്ട പ്രാദേശിക നയം, ചലിച്ച ടണൽ കൗണ്ടറുകൾ, കാണാവുന്നിടത്ത് അകലെയുള്ള വശത്തെ സ്വീകരണം. കൗണ്ടറുകൾ ചലിക്കുന്നില്ലെങ്കിൽ, റൂട്ട് പട്ടിക എന്ത് പറഞ്ഞാലും പാക്കറ്റ് ഒരിക്കലും ടണലിൽ പ്രവേശിച്ചിട്ടില്ല. അവ ചലിക്കുകയും ഒന്നും എത്താതിരിക്കുകയും ചെയ്താൽ, അകലെയുള്ള വശം അത് ഉപേക്ഷിക്കുകയോ തെറ്റായി റൂട്ട് ചെയ്യുകയോ ചെയ്യുന്നു. ആ രണ്ട് ഫലങ്ങൾ തികച്ചും വ്യത്യസ്ത ടീമുകളിലേക്ക് നയിക്കുന്നു.
പരാജയപ്പെട്ട പരിവർത്തനത്തിന് പേര് നൽകുക
ഫലം അഞ്ച് അവസ്ഥകളിൽ ഒന്നായി എഴുതുക: ലഭിച്ചിട്ടില്ല, നയം സ്വീകരിച്ചിട്ടില്ല, തിരഞ്ഞെടുത്തിട്ടില്ല, ഇൻസ്റ്റാൾ ചെയ്തിട്ടില്ല, അല്ലെങ്കിൽ ഈ ഒഴുക്കിന് പൊരുത്തപ്പെട്ടിട്ടില്ല. പ്രാദേശിക പാത ശരിയും അകലെയുള്ള അറ്റത്തിന് ഉത്തരം നൽകാനാകാത്തതുമായ സാഹചര്യത്തിന് ആറാമത്തേത് ചേർക്കുക. ആ വാക്യമാണ് ഡെലിവറബിൾ, സ്ഥാപിത അയൽക്കാരന്റെ സ്ക്രീൻഷോട്ടിനേക്കാൾ ഇത് വളരെ ഉപയോഗപ്രദമാണ്.
സ്വീകരണ പദ്ധതിയിൽ നെഗറ്റീവ് പരീക്ഷണവും സൂക്ഷിക്കുക: ടണലിലൂടെ കടന്നുപോകരുതാത്ത ലക്ഷ്യം, മാറ്റത്തിന് ശേഷം പരിശോധിച്ചത്. സുഖകരമായ പാത മാത്രം തെളിയിക്കുന്ന ചെക്ക്ലിസ്റ്റ് അടുത്ത അറ്റകുറ്റപ്പണി വിൻഡോയിൽ ആരെങ്കിലും ചേർക്കുന്ന വിശാല നയ നിയമം പിടിക്കുകയില്ല.