AWS VGW സബ്നെറ്റ് റൂട്ടിന് ഒരു VPN ടണൽ തിരഞ്ഞെടുക്കാൻ കഴിയാത്തത് എന്തുകൊണ്ട്

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

രണ്ട് പാളികൾ കളിയിലുണ്ട്: ഏത് ഗേറ്റ്വേ എന്ന് പറയുന്ന VPC റൂട്ടും ഗേറ്റ്വേയുടെ സ്വന്തം ടണൽ തിരഞ്ഞെടുപ്പും. ഇവ രണ്ടും കൂട്ടിക്കുഴച്ചാൽ റൂട്ട് പട്ടികയിൽ ശരിയായി തോന്നുന്നതും ഒരു പാക്കറ്റും നീക്കാത്തതുമായ എഡിറ്റുകൾ ഉണ്ടാകും.

ഒന്നുപോലെ തോന്നുന്ന രണ്ട് പാളികൾ

സബ്നെറ്റ് റൂട്ട് ഒരു ചോദ്യത്തിന് മാത്രം ഉത്തരം നൽകുന്നു: ഈ ലക്ഷ്യസ്ഥാനത്തിന് ഏത് അറ്റാച്ച്മെന്റ്? അതിന്റെ ലക്ഷ്യം വിർച്വൽ പ്രൈവറ്റ് ഗേറ്റ്വേയാണ്, അതിന്റെ മെട്രിക് അതേ പട്ടികയിലെ മറ്റ് റൂട്ടുകളുമായി മാത്രം മത്സരിക്കുന്നു. ആ എൻട്രിയിൽ ടണൽ ഒന്നിനെ ടണൽ രണ്ടിൽ നിന്നോ കണക്ഷൻ A യെ കണക്ഷൻ B യിൽ നിന്നോ വേർതിരിക്കുന്ന ഒന്നുമില്ല. കൂടുതൽ നിർദ്ദിഷ്ടമായ ഒരു പ്രിഫിക്സ് മറ്റൊരു ലക്ഷ്യസ്ഥാന പൊരുത്തമാണ്, കൂടുതൽ സൂക്ഷ്മമായ പാത തിരഞ്ഞെടുപ്പല്ല.

ഗേറ്റ്വേ അടുത്ത ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: ആ പ്രിഫിക്സിനായി അത് സൂക്ഷിക്കുന്ന ടണലുകളിൽ ഇപ്പോൾ ഏതാണ് ട്രാഫിക് വഹിക്കുന്നത്. ആ തീരുമാനം ടണൽ ആരോഗ്യത്തിൽ നിന്നും കസ്റ്റമർ ഗേറ്റ്വേയിൽ നിന്ന് ലഭിക്കുന്ന BGP ഗുണങ്ങളിൽ നിന്നും വരുന്നു, അത് സബ്നെറ്റ് റൂട്ട് പട്ടികയിൽ ഒരിക്കലും പ്രത്യക്ഷപ്പെടുന്നില്ല.

VGW യഥാർത്ഥത്തിൽ എന്താണ് താരതമ്യം ചെയ്യുന്നത്

ആരോഗ്യം ആദ്യം വരുന്നു. താഴെയുള്ള ഒരു ടണലോ ഉയർന്നിട്ടില്ലാത്ത ഒരു BGP സെഷനോ ഏതെങ്കിലും ഗുണം പരിശോധിക്കുന്നതിന് മുമ്പുതന്നെ തോൽക്കുന്നു. അതുകൊണ്ടാണ് ഇതിനകം പരാജയപ്പെടുന്ന ഒരു കണക്ഷനിൽ പാത മുന്നിൽ ചേർക്കുന്നത് ഒന്നും മാറ്റാത്തത്.

ഒരേ പ്രിഫിക്സിനുള്ള യോഗ്യമായ പാതകളിൽ AWS ചെറിയ AS_PATH നെ മുൻഗണന നൽകുന്നു. രണ്ട് പാതകൾക്ക് നീളം തുല്യമെങ്കിൽ അത് MED താരതമ്യം ചെയ്യുന്നു, പാതയിലെ ആദ്യ AS സംബന്ധിച്ച രേഖപ്പെടുത്തിയ വ്യവസ്ഥയ്ക്ക് വിധേയമായി. നാട്ടുവിശേഷ പതിപ്പല്ല, പ്രസിദ്ധീകരിച്ച ക്രമം വായിക്കുക, കാരണം നാട്ടുവിശേഷം സാധാരണയായി ആരോഗ്യ ഘട്ടവും സ്റ്റാറ്റിക് റൂട്ട് ഒഴിവും ഒഴിവാക്കുന്നു. ഒരു അനന്തരഫലം: ബാക്കപ്പ് കണക്ഷനിൽ മൂന്ന് മുന്നിൽ ചേർക്കലുകൾ പ്രൈമറിയെ കർശനമായി ചെറുതാക്കുന്നു, മുൻഗണന പ്രകടിപ്പിക്കാനുള്ള സാധാരണ വഴി അതാണ്.

മുന്നിൽ ചേർക്കൽ, എപ്പോഴാണ് അത് ഒന്നും ചെയ്യാത്തത്

മുന്നിൽ ചേർക്കൽ കസ്റ്റമർ ഗേറ്റ്വേയുടെ പുറത്തേക്കുള്ള പ്രഖ്യാപനങ്ങളിൽ സംഭവിക്കുന്നു, AWS നുള്ളിൽ അല്ല. AWS ഒഴിവാക്കണമെന്ന് ആഗ്രഹിക്കുന്ന പ്രിഫിക്സിലേക്ക് നിങ്ങളുടെ ASN രണ്ടോ മൂന്നോ തവണ ചേർക്കുന്നു, അപ്പോൾ AWS ആ കണക്ഷന് നീളമേറിയ പാത കാണുന്നു. പ്രൈമറി കണക്ഷൻ മുന്നിൽ ചേർക്കാത്ത പ്രഖ്യാപനം നിലനിർത്തുന്നു. രണ്ട് കണക്ഷനുകളും ഒരേ ASN ൽ നിന്ന് ഒരേ എണ്ണം മുന്നിൽ ചേർക്കലുകളോടെ പ്രഖ്യാപിക്കുന്നുവെങ്കിൽ നിങ്ങൾ ഒരു മുൻഗണനയും പ്രകടിപ്പിച്ചിട്ടില്ല.

മാറ്റത്തിന് ശേഷം AWS വശത്ത് ലഭിച്ച പാത പരിശോധിക്കുക. കസ്റ്റമർ ഉപകരണം ഒരിക്കലും വിട്ടിട്ടില്ലാത്ത ഒരു മുന്നിൽ ചേർക്കൽ AWS അവഗണിച്ചതിനോട് കൃത്യമായി സമാനമായി കാണപ്പെടുന്നു.

സ്റ്റാറ്റിക് റൂട്ടുകൾ മുഴുവൻ വാദവും അവഗണിക്കുന്നു

കണക്ഷൻ സ്റ്റാറ്റിക് റൂട്ടിംഗ് ഉപയോഗിക്കുന്നുവെങ്കിൽ നീട്ടാൻ AS_PATH ഇല്ല. ഒരേ പ്രിഫിക്സിന് BGP വഴി പഠിച്ച റൂട്ടുകൾക്ക് മേൽ സ്റ്റാറ്റിക് VPN റൂട്ടുകൾക്ക് മുൻഗണനയുണ്ടെന്ന് AWS രേഖപ്പെടുത്തുന്നു, അതിനാൽ മിശ്രിത രൂപകൽപ്പന പൂർണ്ണമായും ചലനാത്മകമായതുപോലെ പെരുമാറുന്നില്ല. ആദ്യം റൂട്ടിംഗ് തരം തീരുമാനിക്കുക, തുടർന്ന് അതിനായി നിലനിൽക്കുന്ന മുൻഗണനാ സംവിധാനം തിരഞ്ഞെടുക്കുക.

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

ട്രാൻസിറ്റ് ഗേറ്റ്വേ വ്യത്യസ്ത ഉത്തരമാകുന്നത് എന്തുകൊണ്ട്

ട്രാൻസിറ്റ് ഗേറ്റ്വേ VPN അറ്റാച്ച്മെന്റുകളിലെല്ലാം തുല്യ ചെലവിലുള്ള ബഹുപഥം പിന്തുണയ്ക്കുന്നു, അതിനാൽ രണ്ട് കണക്ഷനുകൾ ഒന്ന് സ്റ്റാൻഡ്ബൈയിൽ നിൽക്കുന്നതിന് പകരം ട്രാഫിക് പങ്കിടാം. ആ രൂപകൽപ്പനയ്ക്ക് വ്യത്യസ്തമായ പരാജയ പ്രതലമുണ്ട്: പ്രവാഹങ്ങൾ ടണലുകളിലേക്ക് പരക്കുന്നു, ഒരു ടണൽ വീഴുമ്പോൾ ലോഡിന്റെ ഒരു ഭാഗം മാത്രം നീങ്ങുന്നു. VGW കുറിപ്പടി ട്രാൻസിറ്റ് ഗേറ്റ്വേയിലേക്കോ തിരിച്ചോ പകർത്തുന്നത് രണ്ട് പ്ലാറ്റ്ഫോമുകളും നിറവേറ്റാത്ത പ്രതീക്ഷകൾ സൃഷ്ടിക്കുന്നു.

സംവിധാനത്തിന് മുമ്പ് മാതൃക തിരഞ്ഞെടുക്കുക: ഉറപ്പിച്ച മുൻഗണനയോടെ സജീവവും സ്റ്റാൻഡ്ബൈയും, അല്ലെങ്കിൽ ECMP യോടെ സജീവവും സജീവവും.

സജ്ജീകരിച്ച ശേഷം എന്താണ് പരിശോധിക്കേണ്ടത്

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

തുടർന്ന് അനുവദിച്ച ഫെയിൽഓവർ പരീക്ഷ ഓടിക്കുക, അതിജീവിച്ച പാത സേവനം വഹിക്കുന്നത് കാണുക. കോൺഫിഗറേഷൻ വ്യത്യാസത്തിൽ മാത്രം നിലനിൽക്കുന്ന മുൻഗണന ഇപ്പോഴും മുൻഗണനയല്ല.