ബ്രിഡ്ജ് ചെയ്ത സൈറ്റുകൾക്ക് ഇപ്പോഴും പ്രാദേശിക ഇന്റർനെറ്റ് എക്സിറ്റ് തീരുമാനം ആവശ്യമാണ്
പങ്കിട്ട Ethernet സെഗ്മെന്റ് ഏത് റൗട്ടർ ക്ലയന്റ് ഉപയോഗിക്കണം എന്ന് തീരുമാനിക്കുന്നില്ല. ബ്രിഡ്ജിനെ DHCP റൗട്ടർ ഓപ്ഷനിൽ നിന്ന് വേർതിരിക്കുക, ഓരോ സൈറ്റിന്റെയും എക്സിറ്റ് ബോധപൂർവമാക്കുക.
VLAN വിപുലീകരണം വൃത്തിയായി വിജയിച്ചു: രണ്ട് സൈറ്റുകളിലെയും ഹോസ്റ്റുകൾ പരസ്പരം കാണുന്നു, ഫയൽ പങ്കിടൽ പ്രവർത്തിക്കുന്നു, പ്രിന്ററുകൾ പ്രതികരിക്കുന്നു. പിന്നീട് ചെറിയ സൈറ്റിലുള്ള ഒരാൾ ഓരോ ഡൗൺലോഡും മറ്റേ സൈറ്റിന്റെ ഇന്റർനെറ്റ് ലൈൻ ഉപയോഗിക്കുന്നു എന്ന് ശ്രദ്ധിക്കുന്നു, ടിക്കറ്റ് ബാൻഡ്വിഡ്ത്ത് പരാതിയായി വരുന്നു. ബ്രിഡ്ജ് ആവശ്യപ്പെട്ടത് കൃത്യമായി ചെയ്തു. അത് രണ്ട് കെട്ടിടങ്ങൾക്കിടയിൽ ഫ്രെയിമുകൾ വഹിച്ചു, ആ ഫ്രെയിമുകൾ ഇന്റർനെറ്റിനായി ഏത് റൗട്ടർ ഉപയോഗിക്കണം എന്നതിൽ അതിന് ഒരിക്കലും അഭിപ്രായമുണ്ടായിരുന്നില്ല.
ബ്രിഡ്ജ് ഫ്രെയിമുകൾ വഹിക്കുന്നു, തീരുമാനങ്ങളല്ല
ലെയർ 2 വിപുലീകരണം രണ്ട് സ്ഥലങ്ങളെ ഒരു ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്ൻ പോലെ കാണിക്കുന്നു, അതിനാൽ ARP അഭ്യർത്ഥനകൾ, DHCP ബ്രോഡ്കാസ്റ്റുകൾ, അതേ സബ്നെറ്റിലെ ട്രാഫിക് എല്ലാം ടണൽ കടക്കുന്നു. അത് നൽകുന്ന മുഴുവൻ സേവനം അതാണ്. ബ്രിഡ്ജിൽ ഒന്നും ലക്ഷ്യ വിലാസം പരിശോധിക്കുന്നില്ല, അതിനെ സൈറ്റിന്റെ അപ്ലിങ്കുമായി താരതമ്യപ്പെടുത്തുന്നില്ല, ട്രാഫിക്കിനെ അടുത്ത എക്സിറ്റിലേക്ക് തിരിച്ചുവിടുന്നുമില്ല. ഓരോ ക്ലയന്റും ഇപ്പോഴും കോൺഫിഗർ ചെയ്ത വിലാസവും മാസ്കും ഉപയോഗിച്ച് സ്വന്തം പ്രാദേശിക അല്ലെങ്കിൽ ദൂര തീരുമാനം എടുക്കുന്നു.
ആ പങ്കിട്ട സബ്നെറ്റിൽ രണ്ട് റൗട്ടറുകൾ വയ്ക്കുക, രണ്ടും സാധ്യമായ ഗേറ്റ്വേകളാകുന്നു, അവയിലൊന്ന് ഉപയോഗിക്കുന്ന ക്ലയന്റിന് അടുത്താണോ ഇല്ലയോ എന്നത് പ്രശ്നമല്ല.
ക്ലയന്റ് തന്റെ ഗേറ്റ്വേ എങ്ങനെ തിരഞ്ഞെടുക്കുന്നു
RFC 1122-ൽ വിവരിച്ച IPv4 തീരുമാനം ലളിതമാണ്. ക്ലയന്റിന്റെ ബന്ധിപ്പിച്ച സബ്നെറ്റിനുള്ളിലെ ലക്ഷ്യത്തിൽ നേരിട്ട് ARP ഉപയോഗിച്ച് എത്തുന്നു, അതിന് പുറത്തുള്ള ലക്ഷ്യം കോൺഫിഗർ ചെയ്ത ഡിഫോൾട്ട് ഗേറ്റ്വേയിലേക്ക് പോകുന്നു. അതുകൊണ്ടാണ് സൈറ്റുകൾക്കിടയിലെ അതേ സബ്നെറ്റ് ട്രാഫിക് ഒരു റൗട്ടറിന്റെയും ഇടപെടലില്ലാതെ ബ്രിഡ്ജ് കടക്കാൻ കഴിയുന്നത്, അതുകൊണ്ടാണ് ഇന്റർനെറ്റ് ട്രാഫിക് ക്ലയന്റിന് ലഭിച്ച ഗേറ്റ്വേ വിലാസത്തെ പൂർണ്ണമായി ആശ്രയിക്കുന്നത്. രണ്ട് പെരുമാറ്റങ്ങളും സ്വതന്ത്രമാണ്, പ്രവർത്തിക്കുന്ന ഫയൽ പങ്കിടൽ ആദ്യത്തേത് മാത്രം തെളിയിക്കുന്നു.
ചെറിയ സൈറ്റിലെ ക്ലയന്റ് വലിയ സൈറ്റിന്റെ റൗട്ടർ ഉപയോഗിച്ച് കോൺഫിഗർ ചെയ്തിട്ടുണ്ടെങ്കിൽ, അതിന്റെ ഇന്റർനെറ്റ് ഫ്രെയിമുകൾ ആദ്യം ടണൽ കടന്ന് അവിടെ നിന്ന് പുറത്തുപോകുന്നു.
VPN ഉപകരണത്തിന്റെ സ്വന്തം ഡിഫോൾട്ട് റൂട്ട് മാറ്റുന്നത് ആ ക്ലയന്റിന്റെ ഗേറ്റ്വേയെ നീക്കില്ല, കാരണം ക്ലയന്റ് ഉപകരണം റൗട്ടറായി ഉപയോഗിക്കുന്നേയില്ല. ആ ഫ്രെയിമുകൾ വഹിക്കുന്ന ടണൽ നിലനിൽക്കാൻ ഉപകരണത്തിന് അതിന്റെ ദൂര പീയറിലേക്ക് പ്രത്യേക റൂട്ടും വേണം, ഇവ രണ്ടും കൂട്ടിക്കുഴയ്ക്കുന്നതാണ് ബ്രിഡ്ജ് വിപുലീകരണം സ്വന്തം ഗതാഗതം തകർക്കുന്ന വഴി.
DHCP ഉദ്ദേശിച്ച എക്സിറ്റ് പ്രകടിപ്പിക്കട്ടെ
DHCP മറുപടിയിലെ ഓപ്ഷൻ 3 ക്ലയന്റിന്റെ സബ്നെറ്റിലെ റൗട്ടർ വിലാസങ്ങളുടെ പട്ടിക മുൻഗണനാ ക്രമത്തിൽ നൽകുന്നു, ക്ലയന്റുകൾ സാധാരണയായി ആദ്യം മറുപടി നൽകുന്നത് എടുക്കുന്നു. സംവിധാനം കൊള്ളാം; ഉടമസ്ഥതയാണ് ഡിസൈനുകൾ പിഴയ്ക്കുന്നിടം. ഏറ്റവും അടുത്ത DHCP സെർവർ ഏറ്റവും അടുത്ത ഗേറ്റ്വേ നൽകുമെന്ന് അനുമാനിക്കുന്നതിന് പകരം ഓരോ സൈറ്റിലും യഥാർത്ഥ ലീസ് എന്ത് നൽകുന്നു എന്ന് രേഖപ്പെടുത്തുക.
ഒരു ഏകോപിത അലൊക്കേറ്റർ പ്രവർത്തിപ്പിക്കുക, അല്ലെങ്കിൽ ഒരേ നയത്തിനായി വ്യക്തമായി കോൺഫിഗർ ചെയ്ത രണ്ടെണ്ണം, നയത്തിന് ഒരു ഉടമയെ നൽകുക. ദൂര സൈറ്റിൽ ചേർത്ത രണ്ടാമത്തെ സ്വതന്ത്ര അലൊക്കേറ്റർ പ്രാദേശികത സൃഷ്ടിക്കുന്നില്ല, അത് ഒരേ ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്നിന് രണ്ട് അധികാരങ്ങൾ സൃഷ്ടിക്കുന്നു.
രണ്ട് സൈറ്റുകളുടെയും ക്രമീകരണങ്ങൾ ഒരുപോലെ കാണപ്പെടാൻ മാത്രം ഒരു ഗേറ്റ്വേ വിലാസം രണ്ട് സ്വതന്ത്രമായി സജീവമായ റൗട്ടറുകൾക്ക് നൽകരുത്. ബ്രിഡ്ജ് ചെയ്ത സെഗ്മെന്റിലുടനീളം പങ്കിട്ട വെർച്വൽ വിലാസം സ്വന്തം ആവശ്യകതകളുള്ള ആദ്യ-ഹോപ്പ് റിഡണ്ടൻസി ഡിസൈനാണ്, കൈകൊണ്ട് നിർമ്മിച്ച പതിപ്പ് ഇടയ്ക്കിടെ പാക്കറ്റ് നഷ്ടമെന്ന് തോന്നിക്കുന്ന ARP സംഘർഷങ്ങൾ ഉണ്ടാക്കുന്നു. ആപ്ലിക്കേഷന് യഥാർത്ഥത്തിൽ പങ്കിട്ട ലെയർ 2 സെഗ്മെന്റ് ആവശ്യമില്ലെങ്കിൽ, പ്രാദേശിക ഡിഫോൾട്ടുകളുള്ള വേർതിരിച്ച റൗട്ടഡ് പ്രിഫിക്സുകൾ പ്രവർത്തിപ്പിക്കാൻ എളുപ്പവും സംഭവസമയത്ത് വിശദീകരിക്കാൻ എളുപ്പവുമാണ്.
നാല് കാര്യങ്ങൾ വെവ്വേറെ പരിശോധിക്കുക
ഒന്നല്ല, നാല് നിരീക്ഷണങ്ങൾ ആവശ്യപ്പെടുക. ഓരോ സൈറ്റിലും പുതിയ DHCP ലീസ് എടുത്ത് ലഭിച്ച റൗട്ടറും മാസ്കും രേഖപ്പെടുത്തുക. മറ്റേ സൈറ്റിൽ അതേ സബ്നെറ്റിലെ ഒരു സേവനത്തിൽ എത്തി പാത റൗട്ടഡ് വഴിത്തിരിവല്ല, ബ്രിഡ്ജാണെന്ന് സ്ഥിരീകരിക്കുക. ഓരോ സൈറ്റിലും പൊതു ഇന്റർനെറ്റിൽ നിന്ന് എന്തെങ്കിലും എടുത്ത് ഏത് അപ്ലിങ്ക് അത് വഹിച്ചു എന്ന് സ്ഥിരീകരിക്കുക. പിന്നീട് ടണൽ വീഴ്ത്തി എന്ത് തകരുന്നു എന്ന് നോക്കുക, കാരണം ബ്രിഡ്ജ് പരാജയപ്പെടുമ്പോൾ എല്ലാ കണക്ഷനും നഷ്ടപ്പെടുന്ന സൈറ്റ് ആരും ശ്രദ്ധിക്കാതെ ദൂര ഗേറ്റ്വേയെ ആശ്രയിച്ചിരുന്നു.
ആ നാല് ഫലങ്ങൾ സൈറ്റുകൾക്കിടയിലുള്ള ബ്രിഡ്ജ്, പ്രാദേശിക എക്സിറ്റ് അല്ലെങ്കിൽ ആകസ്മിക ബാക്ക്ഹോൾ ഉണ്ടോ എന്ന് പറയുന്നു, അവ ശേഖരിക്കാൻ പത്ത് മിനിറ്റ് എടുക്കും.
ഡിസൈൻ തത്വം മിന്നുന്നതല്ല: ബ്രിഡ്ജിംഗ് പ്രാപ്യത തീരുമാനിക്കുന്നു, DHCP ഗേറ്റ്വേ തീരുമാനിക്കുന്നു, ഉപകരണത്തിലെ റൗട്ടിംഗ് പട്ടിക ടണലിന്റെ സ്വന്തം പാത തീരുമാനിക്കുന്നു. മൂന്നും വേറിട്ട സംഭാഷണങ്ങളിൽ സൂക്ഷിക്കുക, കാരണം മൂന്നും ശരിയാക്കാൻ ശ്രമിക്കുന്ന ഒരു മാറ്റം സാധാരണയായി രണ്ടെണ്ണം തകർക്കുന്നു.