സൈറ്റിനുള്ളിൽ ഒരേ iESI, സൈറ്റുകൾക്കിടയിൽ അനന്യം: Junos ജോടിയാക്കൽ

രണ്ട് ഗേറ്റ്വേ ജോഡികൾ രണ്ട് ഡാറ്റാ സെന്ററുകൾക്ക് സേവനം നൽകുന്നു, ഡിസൈനിന് എത്ര interconnect ESI മൂല്യങ്ങൾ വേണമെന്ന് ആരെങ്കിലും തീരുമാനിക്കണം. ഉത്തരം ഓരോ ഗേറ്റ്വേ ഗ്രൂപ്പിനും ഒന്നാണ്, ഓരോ fabric-നും ഒന്നല്ല, ഓരോ ഗേറ്റ്വേക്കും ഒന്നല്ല. ഇത് തെറ്റായി ചെയ്താൽ കോൺഫിഗർ ചെയ്തതായി തോന്നുന്നതും തെറ്റായ forwarder തിരഞ്ഞെടുക്കുന്നതുമായ fabric ഉണ്ടാകുന്നു, അല്ലെങ്കിൽ വേർതിരിഞ്ഞിരിക്കേണ്ടിയിരുന്ന രണ്ട് സൈറ്റുകൾ ലയിക്കുന്നു. നിയമവും അതിന്റെ ഒഴിവുകളും ഗേറ്റ്വേ പട്ടികയുടെ അരികിൽ എഴുതിവയ്ക്കാൻ യോഗ്യമാണ്.

രണ്ട് പരിധികൾ, രണ്ട് നിയമങ്ങൾ

സൈറ്റിനുള്ളിൽ, അധിക interconnect ഗേറ്റ്വേകൾ ഒരു multihomed അന്തിമ ബിന്ദുവായി പ്രവർത്തിക്കുന്നു, അതിനാൽ അവ ഒരു interconnect ESI പങ്കിടുന്നു. അവയുടെ peer-കൾ രണ്ട് സ്വതന്ത്ര അംഗങ്ങൾക്ക് പകരം ഒരു യുക്തിപരമായ അംഗത്തെ കാണണം. പങ്കിട്ട മൂല്യത്തിന്റെ മുഴുവൻ അർത്ഥവും അതാണ്.

സൈറ്റുകൾക്കിടയിൽ, ഓരോ ഗേറ്റ്വേ ഗ്രൂപ്പിനും സ്വന്തം മൂല്യം ലഭിക്കുന്നു. ഒരേ ഐഡന്റിഫയർ പങ്കിടുന്ന രണ്ട് ഡാറ്റാ സെന്ററുകൾ നിയന്ത്രണ തലത്തിൽ ഒരു multihomed ഗ്രൂപ്പായി മാറുന്നു, ഇത് സാധാരണയായി WAN വഴിയുള്ള ജോടിയാക്കൽ ഡിസൈൻ ഉദ്ദേശിക്കുന്നതല്ല. ഒരു ഗ്രൂപ്പിലെ രണ്ട് സൈറ്റുകൾ പരസ്പരം പരാജയ മോഡുകളും പാരമ്പര്യമായി നേടുന്നു.

സൈറ്റിനുള്ളിൽ: ഗ്രൂപ്പിന് ഒരു ഐഡന്റിറ്റി

ജോഡിക്ക് രണ്ട് peer-കളിലും ഒരേ മൂല്യം, അതേ സേവന സന്ദർഭത്തിൽ നൽകുക, ചാറ്റ് ത്രെഡിലല്ല, നെറ്റ്വർക്കിന്റെ ഐഡന്റിഫയർ ഇൻവെന്ററിയിൽ രേഖപ്പെടുത്തുക. രണ്ട് അംഗങ്ങൾ തമ്മിലുള്ള പൊരുത്തക്കേടാണ് ഒരു അംഗമുള്ള ഗ്രൂപ്പും വ്യക്തമായ അലാറവുമില്ലാത്ത അവസ്ഥ ഉണ്ടാക്കുന്ന പരാജയ മോഡ്. പ്രവർത്തിക്കുന്ന സെഷൻ വിശ്വസിക്കുന്നതിന് മുമ്പ് രണ്ട് അംഗങ്ങളെയും താരതമ്യം ചെയ്യുക.

പിന്തുണയ്ക്കുന്ന മാതൃക all-active ആണ്. അതേ റഫറൻസ് ഈ ജോടിയാക്കൽ ഐഡന്റിറ്റിക്ക് single-active പ്രവർത്തനം, സ്വയമേവ ലഭ്യമാക്കുന്ന LACP ഐഡന്റിഫയറുകൾ, source-bmac ഓപ്ഷനുകൾ എന്നിവ ഒഴിവാക്കുന്നു, അതിനാൽ അവയിലൊന്ന് അനുമാനിച്ച ഡിസൈൻ ഐഡന്റിഫയർ തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പുതന്നെ പുനഃപരിശോധിക്കണം. ഈ നിയന്ത്രണം ഡിസൈൻ ഇൻപുട്ടാണ്, അടിക്കുറിപ്പല്ല.

സൈറ്റുകൾക്കിടയിൽ: വ്യത്യസ്ത മൂല്യങ്ങൾ, അല്ലെങ്കിൽ ബോധപൂർവമായ ലയനം

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

ഉദ്ദേശിച്ച വ്യത്യാസം പ്ലാനിൽ എഴുതുക, അതുവഴി പിന്നീട് പ്രവർത്തിക്കുന്ന സൈറ്റ് ടെംപ്ലേറ്റ് പകർത്തുന്ന എൻജിനീയർ അതിന്റെ ഐഡന്റിഫയറും കൂടെ കൊണ്ടുവരാതിരിക്കും.

peer പ്രസ്താവന ഐഡന്റിറ്റിയുടെ ഭാഗമാണ്

ഗ്രൂപ്പിലെ ഓരോ ഗേറ്റ്വേയും അതിന്റെ പ്രാദേശിക peer-കളെ loopback വിലാസം അനുസരിച്ച് ലിസ്റ്റ് ചെയ്യുന്നു, ആ ബന്ധം വ്യക്തിഗത MAC-VRF-നുള്ളിൽ അല്ല, ആഗോള EVPN തലത്തിലാണ് ജീവിക്കുന്നത്. അത് തെറ്റായ ശ്രേണീകരണത്തിൽ വയ്ക്കുന്നത് commit ആകുന്നുവെങ്കിലും ഗ്രൂപ്പ് ഒരിക്കലും രൂപപ്പെടുത്താത്ത കോൺഫിഗറേഷൻ സൃഷ്ടിക്കാനുള്ള സാധാരണ വഴിയാണ്. റഫറൻസ് ശ്രേണീകരണം ഒരിക്കൽ വായിക്കുക, പിന്നീട് അതിൽ ഉറച്ചു നിൽക്കുക.

പ്രസ്താവനയുടെ പേരും നീങ്ങി. Juniper 24.2R1-ൽ interconnect peer-gateways പ്രസ്താവന പുനർനാമകരണം ചെയ്തു, 24.4R1-ൽ ഡാറ്റാ സെന്റർ interconnect-നുള്ള interconnect-നിർദ്ദിഷ്ട രൂപം പുനഃസ്ഥാപിച്ചു. അതിനാൽ ഇടക്കാല റിലീസിൽ നിന്ന് എടുത്ത സ്നിപ്പെറ്റ് വിന്യസിച്ച പതിപ്പ് സ്വീകരിക്കാത്ത പേര് ഉപയോഗിച്ചേക്കാം, അല്ലെങ്കിൽ തിരിച്ചും. സ്നിപ്പെറ്റ് ഏത് റിലീസിൽ നിന്നാണോ വന്നത് അത് സ്നിപ്പെറ്റിന്റെ അരികിൽ രേഖപ്പെടുത്തുക.

iESI പങ്കിടുന്നത് എന്ത് ചെയ്യുന്നില്ല

ഇത് നിങ്ങൾക്കായി route target, VNI അല്ലെങ്കിൽ പ്രാദേശിക EVPN ഇൻസ്റ്റൻസ് നിർവചിക്കുന്നില്ല. അവ ഇരുവശത്തും പൊരുത്തപ്പെടേണ്ട വേറിട്ട കോൺഫിഗറേഷനായി തുടരുന്നു, ഒപ്പം പൊരുത്തപ്പെടുന്ന ഐഡന്റിഫയർ, route target പൊരുത്തപ്പെടാത്തപ്പോൾ, രൂപപ്പെടുകയും ഒന്നും വഹിക്കാതിരിക്കുകയും ചെയ്യുന്ന ഗ്രൂപ്പ് ഉണ്ടാക്കുന്നു. ആ ക്രമീകരണങ്ങളുടെ ഇരുവശവും ഒരേ പാസിൽ താരതമ്യം ചെയ്യുക.

ഇത് peer എത്തിച്ചേരാനുള്ള കഴിവോ designated forwarder തിരഞ്ഞെടുപ്പോ തെളിയിക്കുന്നുമില്ല. സാധാരണ സാഹചര്യത്തിൽ unicast ഉം ആവശ്യമായ broadcast, multicast പെരുമാറ്റവും പരിശോധിക്കുക, തുടർന്ന് ഒരു ഗേറ്റ്വേ നീക്കി ആവർത്തിക്കുക, ശേഷിക്കുന്ന അംഗം ഗ്രൂപ്പ് ഒറ്റയ്ക്ക് വഹിക്കാൻ.

ആ രണ്ടാം പ്രവർത്തനമാണ് ഗ്രൂപ്പ് യഥാർത്ഥമാണെന്ന് തെളിയിക്കുന്നത്.

നിരീക്ഷിച്ച അംഗത്വവും സേവന സന്ദർഭവും പരീക്ഷണ ഫലങ്ങളോടൊപ്പം സൂക്ഷിക്കുക. പിന്നീടുള്ള ഐഡന്റിഫയർ മാറ്റം അപ്പോൾ സ്ട്രിംഗിന്റെ സൗന്ദര്യ മാറ്റമായല്ല, യഥാർത്ഥത്തിൽ അതായ multihoming മാറ്റമായി പരിശോധിക്കാം. ഐഡന്റിഫയർ ഡ്രോയിംഗ് പറയുന്നത് ചെയ്യുന്നു എന്നതിന് ഫലങ്ങൾ മാത്രമാണ് തെളിവ്.