MPLS ശാഖാ റൂട്ടിംഗ്: CE എന്ത് പഠിക്കുന്നു, ആരിൽ നിന്ന്

ഒരു ശാഖയിലെ ഹോസ്റ്റ് മറ്റൊരു ശാഖയിലെ സെർവറിലേക്ക് കണക്ഷൻ തുറക്കുന്നു, രണ്ട് സൈറ്റുകളും ഒരേ മാനേജുചെയ്ത MPLS ലെയർ 3 VPN-ന് പിന്നിലാണ്. ഹോസ്റ്റിന് സ്വന്തം ഡിഫോൾട്ട് ഗേറ്റ്വേ മാത്രം അറിയാം, മറ്റൊന്നും അറിയില്ല, ഇത് ശരിയാണ്. പ്രധാനമായത്, പ്രാദേശിക കസ്റ്റമർ എഡ്ജ് പാക്കറ്റ് തന്റെ പ്രൊവൈഡർ എഡ്ജിന് കൈമാറുന്നു എന്നതും, പ്രൊവൈഡറുടെ VPN റൂട്ടിംഗ് അവസ്ഥ അത് ലക്ഷ്യ പ്രിഫിക്സ് ഉള്ള ശാഖയിലേക്ക് എത്തിക്കുന്നു എന്നതുമാണ്.

പാതയിലുടനീളം ഒരു പാക്കറ്റ് പിന്തുടരുന്നത്, ഏത് ഭാഗം ഉപഭോക്താവിന്റെ ഉത്തരവാദിത്തമാണ്, ഏത് ഭാഗം സേവനത്തിന്റേതാണ് എന്ന് കാണാനുള്ള വേഗതയേറിയ വഴിയാണ്.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

ഓരോ ഹോപ്പിന്റെയും ജോലി അവസാനിക്കുന്നിടം

CE-A-ന് വിദൂര LAN-ലേക്ക് ഒരു റൂട്ട് വേണം, അത് അതിന്റെ പ്രാദേശിക പ്രൊവൈഡർ ബന്ധത്തിലേക്ക് ചൂണ്ടണം, വിദൂര ശാഖയുടെ WAN വിലാസത്തിലേക്കല്ല. തുടർന്ന് പ്രൊവൈഡർ VPN റൂട്ടിംഗ് അവസ്ഥ ഉപയോഗിച്ച് പാക്കറ്റ് തന്റെ കോർ വഴി കൊണ്ടുപോകുന്നു, CE-B അത് ലക്ഷ്യ LAN-ൽ എത്തിക്കുന്നു. ഒരു ഘട്ടത്തിലും ഹോസ്റ്റിന് ലേബലുകളോ VRF-കളോ എതിർവശത്തെ ഇന്റർനെറ്റ് സർക്യൂട്ടോ മനസ്സിലാക്കേണ്ടതില്ല.

ടിക്കറ്റുകളിൽ ആവർത്തിച്ച് വരുന്ന തെറ്റ്, ശാഖ A-യിൽ ശാഖ B-യുടെ WAN വിലാസം അടുത്ത ഹോപ്പായി ക്രമീകരിക്കുന്നതാണ്. രണ്ട് ശാഖകളും ഒരേ സേവനം വാങ്ങിയതിനാൽ അവർ അയൽക്കാരായിരിക്കണമെന്ന് തോന്നുന്നു. എന്നാൽ അവർ അല്ല: അടുത്ത ഹോപ്പ് നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ ഉള്ള റൂട്ടിംഗ് ഡിസൈനിലൂടെ എത്തിച്ചേരാവുന്നതായിരിക്കണം, വിദൂര CE സാധാരണയായി നിങ്ങൾ കൈകാര്യം ചെയ്യാത്ത ഉപകരണങ്ങൾക്ക് പിന്നിൽ പല ഹോപ്പുകൾ അകലെയാണ്. ഈ അനുമാനത്തിൽ നിർമ്മിച്ച സ്റ്റാറ്റിക് റൂട്ട് സജീവമായി കാണപ്പെടുന്നു, എന്നാൽ ഒന്നിലേക്കും പരിഹരിക്കുന്നില്ല, ഇത് ഇല്ലാത്ത റൂട്ടിനേക്കാൾ മോശമാണ്, കാരണം പട്ടികയിൽ അത് ശരിയായി കാണപ്പെടുന്നു.

RFC 4364 ഉപഭോക്താവിന്റെയും പ്രൊവൈഡറുടെയും അതിരുകൾ തമ്മിലുള്ള കൈമാറ്റത്തെ പ്രൊവൈഡറുടെ VPN റൂട്ട് വിതരണത്തിൽ നിന്ന് വേർതിരിക്കുന്നു, ഈ ഗൈഡ് പ്രതിപാദിക്കുന്ന അതിർത്തി കൃത്യമായി അതാണ്. ഉപഭോക്താവിന്റെ ജോലി, തന്റെ അതിരിനോട് എന്ത് എത്തിക്കാനാകുമെന്ന് പറയുകയും സേവനം തിരികെ നൽകുന്ന എത്തിച്ചേരാവുന്നത അംഗീകരിക്കുകയുമാണ്.

കൈമാറ്റം എന്തിൽ യോജിക്കണം

പ്രൊവൈഡറുമായി ചേർന്ന് സംവിധാനം തിരഞ്ഞെടുക്കുക, അവരെ ഒഴിവാക്കി അല്ല. സ്റ്റാറ്റിക് റൂട്ടുകൾ, BGP, അല്ലെങ്കിൽ CE-യും PE-യും തമ്മിലുള്ള റൂട്ടിംഗ് പ്രോട്ടോക്കോൾ ക്രമീകരണം എല്ലാം സാധുവാണ്, OSPF-ന് അത്തരം കൈമാറ്റത്തിന് നിർവചിച്ച MPLS VPN മാതൃകയുണ്ട്. ഇവയൊന്നും രണ്ട് വിദൂര ഉപഭോക്തൃ അതിരുകൾക്കിടയിൽ വ്യക്തമാക്കാത്ത പ്രൊവൈഡർ കോറിലൂടെ OSPF അയൽബന്ധം നിർമ്മിക്കാനുള്ള കാരണമല്ല, കാരണം അത് പ്രൊവൈഡർ സമ്മതിക്കാത്തതും പിന്തുണയ്ക്കാനാകാത്തതുമായ ഡിസൈനാണ്.

പുതിയ LAN പ്രവർത്തനക്ഷമമാക്കുന്നതിന് മുമ്പ് നാല് കാര്യങ്ങൾ എഴുതിവയ്ക്കുക: പ്രിഫിക്സ്, CE-യിലെ പ്രാദേശിക അടുത്ത റൂട്ട്, പ്രൊവൈഡർ സ്വീകരിക്കുന്ന പ്രഖ്യാപനം, പ്രൊവൈഡർ തിരികെ നൽകുന്ന റൂട്ടുകൾ. കരാർ അനുശാസിക്കുന്ന ഏതെങ്കിലും ഫിൽട്ടറിംഗ്, പ്രിഫിക്സ് പരിധി അല്ലെങ്കിൽ സൈറ്റുകൾക്കിടയിലുള്ള നിയന്ത്രണം ചേർക്കുക. ആരോഗ്യകരമായ അയൽബന്ധം വിവരം കൈമാറാനുള്ള ഒരു ചാനലാണ്, ഒരു നിർദ്ദിഷ്ട പ്രിഫിക്സ് സ്വീകരിച്ചു എന്നതിന്റെ തെളിവല്ല; നിങ്ങളുടെ പുതിയ സബ്നെറ്റ് ഒരു ഫിൽട്ടറിൽ ഇരിക്കുമ്പോൾ സെഷൻ സജീവമായിരിക്കാം.

തുടർന്ന് മറുപടി പിന്തുടരുക. ശാഖ B-യ്ക്ക് ഉറവിട LAN-ലേക്ക് തിരികെ ഒരു റൂട്ട് വേണം, സ്വീകരിക്കുന്ന വശത്തെ ഹോസ്റ്റിന് സ്വന്തം ഗേറ്റ്വേയും സ്വന്തം സേവനാനുമതികളും വേണം. CE-A-യിൽ പ്രത്യക്ഷപ്പെടുന്ന ഒരു റൂട്ട് പകുതി യാത്ര മാത്രം സ്ഥാപിക്കുന്നു, ആ പകുതി യാത്രയാണ് ping പരിശോധനയുടെ ഒരു ദിശ ആരോഗ്യകരമായി തോന്നുകയും ആപ്ലിക്കേഷൻ ഇപ്പോഴും പരാജയപ്പെടുകയും ചെയ്യുന്നതിന്റെ കാരണം.

ഏൽക്കുന്നതിന് മുമ്പ് രണ്ട് കൈമാറ്റങ്ങളും പരിശോധിക്കുക

രണ്ട് ഉപഭോക്തൃ അതിരുകളിലും റൂട്ടിംഗ് അവസ്ഥ ശേഖരിക്കുക, ഉദ്ദേശിച്ച LAN പ്രിഫിക്സുകൾ VPN-ലേക്ക് സ്വീകരിച്ചുവെന്ന് പ്രൊവൈഡറുമായി സ്ഥിരീകരിക്കുക, തുടർന്ന് ഓരോ ദിശയിലും അനുവദനീയമായ ഒരു ആപ്ലിക്കേഷൻ പരീക്ഷിക്കുക. റൂട്ട് പട്ടികകൾ മാത്രം ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നുവെന്ന് തെളിയിക്കുന്നില്ല, ആപ്ലിക്കേഷൻ പരിശോധന മാത്രം പ്രവർത്തിക്കാത്തപ്പോൾ ഏത് നിയന്ത്രണ തലം പരാജയപ്പെട്ടുവെന്ന് പറയുന്നുമില്ല.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

മൂന്ന് ഔട്ട്പുട്ടുകളും ഒരുമിച്ച് വായിക്കുക. ആദ്യത്തേത് അതിർ എന്ത് വിശ്വസിക്കുന്നു എന്ന് പറയുന്നു, രണ്ടാമത്തേത് എന്ത്, ഏത് പിയറിൽ നിന്ന് പഠിച്ചു എന്ന് പറയുന്നു, മൂന്നാമത്തേത് യഥാർത്ഥത്തിൽ എന്ത് കൈമാറും എന്ന് പറയുന്നു. അവ തമ്മിലുള്ള വൈരുദ്ധ്യം സാധാരണയായി നഷ്ടപ്പെട്ട പ്രഖ്യാപനമല്ല, നയമോ ആവർത്തനമോ ഉള്ള പ്രശ്നമാണ്, പ്രൊവൈഡറിനോട് അന്വേഷണം ആവശ്യപ്പെടുന്നതിന് മുമ്പ് അത് പരിഹരിക്കുന്നത് മൂല്യവത്താണ്. ഈ മൂന്ന് ഔട്ട്പുട്ടുകളും ഓപ്പറേറ്ററുമായുള്ള കോളിലേക്ക് കൊണ്ടുപോകുക, കാരണം പിന്തുണാ എഞ്ചിനീയർ മറ്റൊരു വിധത്തിൽ ചോദിക്കുമായിരുന്ന ഭൂരിഭാഗം ചോദ്യങ്ങൾക്കും അവ ഉത്തരം നൽകുന്നു.

സേവനം എന്ത് നൽകുന്നില്ലെന്ന് അറിയുക

ഇത് ലെയർ 3-ന്റെ റൂട്ട് ചെയ്ത ആക്സസ് ആണ്. ഓഫീസുകൾക്കിടയിൽ ബ്രോഡ്കാസ്റ്റ് വ്യാപിപ്പിക്കുന്ന ലെയർ 2 സർക്യൂട്ടല്ല ഇത്, അതിനാൽ ഡിസ്കവറി പ്രോട്ടോക്കോളുകൾ, ബ്രോഡ്കാസ്റ്റിനെ ആശ്രയിക്കുന്ന ആപ്ലിക്കേഷനുകൾ, പങ്കിട്ട സെഗ്മെന്റ് അനുമാനങ്ങൾ എന്നിവ അതിനൊപ്പം യാത്ര ചെയ്യുന്നില്ല. പ്രിന്റിംഗ്, പേര് ബ്രൗസിംഗ്, പ്രാദേശിക സെഗ്മെന്റിനെ ആശ്രയിക്കുന്ന എല്ലാത്തിനും സ്വന്തം ഡിസൈൻ വേണം.

VPN വേർതിരിക്കൽ എൻക്രിപ്ഷനുമല്ല. ലേബൽ സ്വിച്ചിംഗ് പ്രൊവൈഡറുടെ നെറ്റ്വർക്കിനുള്ളിൽ ഉപഭോക്താക്കളെ വേർതിരിച്ചു നിർത്തുന്നു, കരാർ രഹസ്യസ്വഭാവം ആവശ്യപ്പെടുന്നുവെങ്കിൽ അത് പേലോഡിനെ രഹസ്യമാക്കുന്നില്ല. അത് പ്രധാനമായിടത്ത് ആപ്ലിക്കേഷനോ ഓവർലേയോ അത് നൽകണം.

അവസാനമായി, സൈറ്റിന്റെ റൂട്ടിംഗ് കോൺഫിഗറേഷന് സമീപം സേവന മാതൃക എഴുതി സൂക്ഷിക്കുക. സബ്നെറ്റ് ചേർക്കുന്ന അടുത്ത എഞ്ചിനീയർക്ക് ഏത് പ്രിഫിക്സുകൾ പ്രഖ്യാപിക്കുന്നു, ആരാണ് അവ സ്വീകരിക്കുന്നത്, പ്രതീക്ഷിത തിരിച്ചുവരവ് പാത ഏതാണ് എന്ന് വായിക്കാൻ കഴിയണം: BGP/MPLS IP VPN സ്പെസിഫിക്കേഷൻ ഇവയുടെയെല്ലാം പിന്നിലെ മാതൃകയ്ക്കുള്ള റഫറൻസാണ്.