EVPN all-active-ൽ Linux ആക്ടീവ്-ബാക്കപ്പ് ബോണ്ട്: എന്താണ് പൊട്ടുന്നത്

സെർവറിൽ ആക്ടീവ്-ബാക്കപ്പ് ബോണ്ട് വയ്ക്കുക, ഫാബ്രിക്കിൽ all-active ഈതർനെറ്റ് സെഗ്മെന്റ് വയ്ക്കുക, മടങ്ങിവരുന്ന ട്രാഫിക്കിന്റെ പകുതി ഒരു പിശക് കൗണ്ടറും അനങ്ങാതെ അപ്രത്യക്ഷമാകാം. രണ്ട് കോൺഫിഗറേഷനുകളിൽ ഒന്നും സ്വയം തെറ്റല്ല. പ്രശ്നം അവയ്ക്കിടയിലുള്ള കൈമാറ്റത്തിലാണ്, ഒരു വശം ഒരു പോർട്ട് തിരഞ്ഞെടുക്കുമ്പോൾ മറുവശം ബന്ധിപ്പിച്ച ഓരോ ലീഫിനും എത്തിക്കാനാകുമെന്ന് കരുതുന്നു. ഓരോ ദിശയിലും ഒരു ഫ്രെയിം പിന്തുടരുക, പൊരുത്തക്കേട് വ്യക്തമാകും.

ആക്ടീവ്-ബാക്കപ്പ് വരുന്ന ഫ്രെയിമിനോട് എന്ത് ചെയ്യുന്നു

ബോണ്ടിംഗ് മോഡ് 1 അയയ്ക്കുന്ന പാതയിൽ കൃത്യമായി ഒരു സ്ലേവ് നിലനിർത്തുന്നു, നിലവിലുള്ളത് പരാജയപ്പെടുമ്പോൾ മാത്രം അത് മാറ്റുന്നു. ആ ഭാഗം നന്നായി അറിയപ്പെടുന്നതാണ്. ഇവിടെ പ്രധാനം സ്വീകരണ വശമാണ്: കേർണൽ സ്റ്റാക്കിന് ഫ്രെയിം നൽകുന്നത് അത് സജീവ സ്ലേവിൽ എത്തുമ്പോൾ മാത്രമാണ്, മറ്റേതെങ്കിലും സ്ലേവിൽ പ്രത്യക്ഷപ്പെടുന്ന ഫ്രെയിമുകൾ ഉപേക്ഷിക്കുന്നു. ഈ all_slaves_active ക്രമീകരണം ആ നിയമം അയവുവരുത്താൻ വേണ്ടിയാണ്, സ്വതവേ ഇത് ഓഫാണ്. ip -d link show bond0 മോഡിനൊപ്പം നിലവിലെ മൂല്യം പ്രിന്റ് ചെയ്യുന്നു.

/proc/net/bonding/bond0 സജീവ സ്ലേവിനെ പേരെടുത്ത് പറയുകയും ഓരോ സ്ലേവിന്റെയും ലിങ്ക് നില അറിയിക്കുകയും ചെയ്യുന്നു. ഏത് പോർട്ടാണ് ഇപ്പോൾ ട്രാഫിക് വഹിക്കുന്നതെന്നതിന് ആ ഫയൽ മാത്രമാണ് സത്യസന്ധമായ ഉറവിടം.

ഈ മോഡിലുള്ള ഹോസ്റ്റിന് ഒരു സമയത്ത് ഒരു ഉപയോഗയോഗ്യമായ സ്വീകരണ പാത മാത്രമുണ്ട്, അത് ഫാബ്രിക്കിനെക്കുറിച്ചുള്ള അറിവില്ലാതെ പ്രാദേശികമായി തിരഞ്ഞെടുക്കുന്നു. ആ ഹോസ്റ്റിനുള്ള ഫ്രെയിം മറ്റേ കേബിളിൽ എത്തിയാൽ, സ്വിച്ച് പോർട്ട് അതിനെ സ്വീകരിച്ചതായി കണക്കാക്കും, ഹോസ്റ്റിന്റെ സ്റ്റാക്ക് അത് ഒരിക്കലും കാണില്ല, ഹോസ്റ്റിന്റെ സ്വന്തം ഡ്രോപ്പ് കൗണ്ടർ ഒഴികെയുള്ള എല്ലാ കൗണ്ടറുകളും പൂർണ്ണമായും ആരോഗ്യകരമായി തോന്നും.

all-active മൾട്ടിഹോമിംഗ് വിദൂര അടുത്ത ഹോപ്പിനോട് എന്ത് ചെയ്യുന്നു

EVPN മൾട്ടിഹോമിംഗ് ESI കൊണ്ട് തിരിച്ചറിയുന്ന ഒരു ഈതർനെറ്റ് സെഗ്മെന്റ് പങ്കിടുന്ന ലീഫുകളുടെ ഒരു കൂട്ടത്തെ വിവരിക്കുകയും ആ സെഗ്മെന്റ് ബാക്കിയുള്ള ഫാബ്രിക്കിന് പ്രഖ്യാപിക്കുകയും ചെയ്യുന്നു. all-active മോഡലിൽ, വിദൂര പിയറുകൾ സെഗ്മെന്റിന്റെ വിലാസങ്ങൾക്ക് ഒന്നിലധികം അടുത്ത ഹോപ്പുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. സെർവറിലേക്കുള്ള യൂണികാസ്റ്റ് അപ്പോൾ ഏത് ലീഫിലും എത്താം, ഫാബ്രിക് ഓരോ ഫ്ലോയ്ക്കും സ്വതന്ത്രമായി തിരഞ്ഞെടുക്കാം. ഇതാണ് ഡിസൈനിന്റെ മുഴുവൻ ഉദ്ദേശ്യം, സെർവറിന്റെ ബോണ്ട് പാലിക്കേണ്ട അനുമാനവും ഇതുതന്നെ.

വെള്ളപ്പൊക്ക ട്രാഫിക് മറ്റൊരു നിയമം പിന്തുടരുന്നു. ലീഫുകൾ ഓരോ സെഗ്മെന്റിനും നിയുക്ത ഫോർവേഡർ തിരഞ്ഞെടുക്കുന്നു, അതിനാൽ ബ്രോഡ്കാസ്റ്റും അജ്ഞാത യൂണികാസ്റ്റും മൾട്ടികാസ്റ്റും സാധാരണയായി അവയിലൊന്നിലൂടെ പ്രവേശിക്കുന്നു. അതിനാൽ യൂണികാസ്റ്റും വെള്ളപ്പൊക്കവും രണ്ട് വേറിട്ട തീരുമാനങ്ങൾ എടുക്കുന്നു, അവയിൽ ഒന്ന് മാത്രം ഹോസ്റ്റിന്റെ ബോണ്ട് നിലയിൽ കാണുന്നു.

രണ്ട് തിരഞ്ഞെടുപ്പുകൾ വിയോജിക്കുന്നിടം

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

രണ്ട് പിന്തുണയുള്ള മാർഗങ്ങളുണ്ട്, അവ പരസ്പരം മാറ്റാനാവില്ല. ഫാബ്രിക് ഒരു യുക്തിപരമായ ബന്ധനമായി കാണാവുന്ന ബോണ്ട് ഹോസ്റ്റിന് നൽകുക, അതായത് പ്രായോഗികമായി ലീഫുകളുമായി ചർച്ച ചെയ്ത LACP ബോണ്ട്, രണ്ട് ലിങ്കുകളും ശരിക്കും ഒരുമിച്ച് സജീവമായിരിക്കും. അല്ലെങ്കിൽ ഫാബ്രിക്കിൽ നിന്ന് single-active വിതരണവും സ്വീകരിക്കുക, സെഗ്മെന്റ് ബോണ്ടിന് സമാനമായ ഒരു-പോർട്ട്-ഒരു-സമയം മോഡൽ പിന്തുടരാൻ. പ്രവർത്തിക്കാത്തത് ഒരു പോർട്ടിൽ മാത്രം കേൾക്കുന്ന ബോണ്ടിന് മുന്നിൽ all-active സെഗ്മെന്റ് ഇടുന്നതാണ്, നിഷ്ക്രിയ സ്ലേവുകളിൽ സ്വീകരണം ബോധപൂർവം ഓണാക്കി തുടർന്നുള്ള ഇരട്ടി വിതരണം സ്വീകരിക്കുന്നില്ലെങ്കിൽ.

ബാക്കപ്പ് കേബിൾ ആരോഗ്യകരമായി തുടരുന്നതെന്തുകൊണ്ട്

ട്രാഫിക് വഹിക്കാത്ത കേബിളും ലിങ്ക് അപ്പ് എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു, ബോണ്ടിലെ സ്റ്റാൻഡ്ബൈ സ്ലേവ് തയ്യാറായി തോന്നാൻ വേണ്ടി രൂപകൽപ്പന ചെയ്തതാണ്. ഓപ്പറേറ്റർമാർ അതിനെ റിഡണ്ടൻസിയായി വായിക്കുകയും ചോദ്യങ്ങൾ നിർത്തുകയും ചെയ്യുന്നു.

പകരം മടങ്ങിവരുന്ന ഫ്രെയിം ഏത് ഭൗതിക പോർട്ട് ഉപയോഗിച്ചുവെന്ന് ചോദിക്കുക. ഹോസ്റ്റിൽ, ബോണ്ടിന് പകരം സ്ലേവ് തോറും സ്വീകരിച്ച പാക്കറ്റുകൾ എണ്ണുക, കാരണം ബോണ്ട് കൗണ്ടർ അസമത്വം മറയ്ക്കുന്നു. ലീഫിൽ, നോക്കുക സെർവറിന്റെ MAC-നുള്ള ബ്രിഡ്ജ് ഫോർവേഡിംഗ് എൻട്രികൾ ഒപ്പം EVPN റൂട്ട് വഹിക്കുന്ന അടുത്ത-ഹോപ്പ് കൂട്ടവും. എൻട്രി ഹോസ്റ്റ് ലിങ്ക് സ്റ്റാൻഡ്ബൈ ആയ ലീഫിലേക്ക് ചൂണ്ടുന്നുവെങ്കിൽ, ഡിസൈൻ ഹോസ്റ്റ് അവഗണിക്കുന്ന പോർട്ടിലേക്ക് വിതരണം ചെയ്യുന്നു. ഇത് ഹാർഡ്വെയർ തകരാറല്ല, കോൺഫിഗറേഷൻ പൊരുത്തക്കേടാണ്, എത്ര ലിങ്ക്-നില നിരീക്ഷണം നടത്തിയാലും അത് പുറത്തുവരില്ല.

രണ്ട് ദിശകളിലും വിതരണം പരിശോധിക്കുക, ലിങ്ക് നിലയല്ല

ഓരോ പരാജയത്തിനും ഒരു വരിയും ഓരോ ദിശയ്ക്കും ഒരു നിരയും ഉള്ള ഒരു മാട്രിക്സ് നിർമ്മിക്കുക, തുടർന്ന് ഇന്റർഫേസ് നിലയ്ക്ക് പകരം വിതരണം ചെയ്ത ട്രാഫിക് നിറയ്ക്കുക. ആദ്യ വരി സാധാരണ പ്രവർത്തനമാണ്, പൊരുത്തക്കേട് കൃത്യം അവിടെയാണ് ഒളിക്കുന്നത്, കാരണം ലക്ഷണം ആപ്ലിക്കേഷൻ പ്രശ്നം പോലെ തോന്നുന്നു.

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

നിങ്ങൾ ഉദ്ദേശിച്ച പാതയിലൂടെ ദ്വിദിശ വിതരണം മാട്രിക്സ് കാണിക്കുമ്പോൾ മാത്രം ഡിസൈൻ സ്വീകരിക്കുക. ലിങ്ക് അപ്പുള്ള രണ്ട് കേബിളുകൾ ആ ഫലമല്ല.