വലിയ നക്ഷത്രാകാര VPN-ന്റെ വലിപ്പം നിർണ്ണയിക്കൽ: BGP തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് എണ്ണുക
പ്രിഫിക്സുകൾ എളുപ്പമുള്ള സംഖ്യയാണ്. സെഷനുകൾ, അപ്ഡേറ്റ് പ്രവാഹം, ഒരു ഹബ് പരാജയത്തിന് ശേഷമുള്ള വീണ്ടെടുപ്പ് എന്നിവയാണ് ആയിരക്കണക്കിന് ശാഖകളിൽ ഡിസൈൻ നിലനിൽക്കുമോ എന്ന് തീരുമാനിക്കുന്നത്.
മൂവായിരം ശാഖകൾ എന്നത് റൂട്ടിംഗ് പ്രശ്നമായി തോന്നാം, പക്ഷേ പെരുമാറ്റം കണക്കെഴുത്ത് പ്രശ്നമാണ്. പ്രിഫിക്സുകളുടെ ആകെ എണ്ണം പത്ത് മിനിറ്റിനുള്ളിൽ കണക്കാക്കാം, വേദനിപ്പിക്കുന്ന സംഖ്യ അതായിരിക്കുന്നത് അപൂർവമാണ്. വേദനിപ്പിക്കുന്നത് ഓരോ സെഷനിലുമുള്ള ജോലി, പങ്കിട്ട ഘടകം പരാജയപ്പെടുമ്പോഴുള്ള അപ്ഡേറ്റ് പ്രവാഹം, ഫോർവേഡിംഗ് പുതിയ ടോപ്പോളജിയുമായി വീണ്ടും യോജിക്കാൻ എടുക്കുന്ന സമയം എന്നിവയാണ്.
അതിനാൽ ഗണിതം ശരിയായ ക്രമത്തിൽ ചെയ്യുക. ബന്ധങ്ങൾ എണ്ണുക, പ്രിഫിക്സുകളും ബദലുകളും എണ്ണുക, പിന്നെ മോശം ഒരു മണിക്കൂറിൽ എന്ത് സംഭവിക്കുന്നു എന്ന് എണ്ണുക, അതിനുശേഷം മാത്രം പ്രോട്ടോക്കോളുകളും പ്ലാറ്റ്ഫോമുകളും താരതമ്യം ചെയ്യുക. വിപരീത ക്രമത്തിൽ ഈ അഭ്യാസം മേശപ്പുറത്തുള്ള വിവരങ്ങൾ കൊണ്ട് ആർക്കും തീർപ്പാക്കാനാകാത്ത റൂട്ട് പരിധികളെക്കുറിച്ചുള്ള തർക്കമായി മാറും.
നാല് ബജറ്റുകൾ, ഒന്നല്ല
ഓരോ ബജറ്റും വ്യത്യസ്ത ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു, ഓരോന്നും വ്യത്യസ്ത പ്ലാറ്റ്ഫോമിൽ നിർണ്ണായക പരിമിതിയാകാം. അവ വെവ്വേറെ എഴുതുന്നത് ഒരു വലിയ പ്രിഫിക്സ് സംഖ്യ മുഴുവൻ ഡിസൈനിന്റെയും സ്ഥാനം ഏൽക്കുന്നത് തടയുന്നു.
| Budget | What you are really counting |
|---|---|
| Sessions | Peers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count |
| Prefixes | Alternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see |
| Churn | Updates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event |
| Recovery | Time to detect, reselect, reinstall and restore the application, measured end to end rather than per box |
അവസാനത്തെ രണ്ടെണ്ണമാണ് ഡിസൈൻ അവലോകനത്തിൽ ഒഴിവാക്കപ്പെടുന്നത്. സ്ഥിരാവസ്ഥയിൽ മെമ്മറിയിൽ സുഖമായി ഇരിക്കുന്ന നെറ്റ്‌വർക്ക് പോലും നാനൂറ് ശാഖകൾ രണ്ട് മിനിറ്റിനുള്ളിൽ വീണ്ടും ബന്ധിപ്പിക്കുമ്പോൾ മോശമായി പെരുമാറാം, കാരണം നിയന്ത്രണ-തലത്തിന് ഒഴിവാക്കാനാകുന്നതിനേക്കാൾ വേഗത്തിൽ ജോലി എത്തുന്നു. പ്രവാഹത്തിന്റെ വലിപ്പം ഒരു സംഖ്യയായി എഴുതുക, സേവനം എത്രനേരം അധഃപതിച്ച് നിൽക്കാമെന്നതും കൂടി. ഇത് അവ്യക്തമായ ആശങ്കയെ ആർക്കെങ്കിലും യഥാർത്ഥത്തിൽ നടത്താവുന്ന ഒരു പരീക്ഷയാക്കി മാറ്റുന്നു.
നാലിലും ഒരു പ്ലാറ്റ്ഫോം ചോദ്യവും ഒളിഞ്ഞിരിക്കുന്നു: എൻക്രിപ്ഷൻ, ഫോർവേഡിംഗ്, റൂട്ടിംഗ് ഒരേ CPU പങ്കിടുന്നുണ്ടോ അതോ വേറിട്ട പാതകളുണ്ടോ. ഒരേ റൂട്ട് ശേഷിയുള്ള രണ്ട് ഉപകരണങ്ങൾ പ്രവാഹത്തിൽ വളരെ വ്യത്യസ്തമായി പെരുമാറാം, ഡാറ്റാഷീറ്റ് നിങ്ങൾ ഏതാണ് വാങ്ങുന്നതെന്ന് അപൂർവമായി മാത്രം പറയുന്നു.
സ്വന്തം സംഖ്യകൾ ഉപയോഗിച്ച് ഗണിതം ചെയ്യുക
ഒരു സാങ്കൽപ്പിക ഡിസൈൻ എടുക്കുക: 3,000 ശാഖകൾ, സമാഹരണത്തിന് മുമ്പ് ഓരോന്നിനും മൂന്ന് പ്രിഫിക്സ്, പകരം വയ്ക്കലിനായി ഓരോ ശാഖയ്ക്കും രണ്ട് ഹബ്ബുകൾ. ഹബ്ബ് ജോടി സംഗ്രഹത്തിന് മുമ്പ് ഏകദേശം 9,000 ശാഖാ പ്രിഫിക്സുകൾ വയ്ക്കേണ്ടതുണ്ട്, ഓരോ ശാഖയും രണ്ടുമായി പീയർ ചെയ്താൽ ഡിസൈൻ 6,000 ശാഖ-ഹബ്ബ് സെഷനുകൾ അർത്ഥമാക്കുന്നു.
ഇപ്പോൾ പ്രിഫിക്സ് അല്ലാത്ത ഭാഗങ്ങൾ ചേർക്കുക. ഓരോ സെഷനും ഒന്നും മാറുന്നില്ലെങ്കിലും അവസ്ഥയും കാലിക സന്ദേശങ്ങളും വഹിക്കുന്നു. വേഗത്തിലുള്ള മാറ്റം പ്രതീക്ഷിക്കുന്നുവെങ്കിൽ ഓരോ ഹബ്ബിനും ഓരോ പ്രിഫിക്സിന് ഒന്നിലധികം പാതകൾ സൂക്ഷിക്കാം, അതിനാൽ ബദലുകളുടെ എണ്ണം തിരഞ്ഞെടുത്തവയുടെ എണ്ണത്തെ കവിയാം. ഓരോ സ്പോക്കിന്റെയും കാഴ്ച പ്രത്യേക നയ തീരുമാനമാണ്: ഓരോ ശാഖയ്ക്കും മറ്റെല്ലാവരുടെയും റൂട്ടുകൾ നൽകുന്നത് ഹബ്ബ് ഭാഗത്തെ എണ്ണം വെളിപ്പെടുത്താത്ത രീതിയിൽ ജോലി ഗുണിക്കുന്നു.
ഇവ ഡിസൈൻ സംഭാഷണത്തിനുള്ള ആസൂത്രണ സംഖ്യകളാണ്, ഏതെങ്കിലും ഉൽപ്പന്നത്തിന്റെ അളവല്ല. അഭ്യാസത്തിന്റെ ഉപയോഗപ്രദമായ ഫലം വക്രത്തിന്റെ ആകൃതിയാണ്, ഒരു പ്രത്യേക റൗട്ടർ എവിടെ കീഴടങ്ങുന്നു എന്ന അവകാശവാദമല്ല.
BGP നിങ്ങൾക്ക് എന്ത് നൽകുന്നു, IGP നിങ്ങൾക്ക് എന്ത് നൽകുന്നു
BGP റൗട്ടർ സ്വീകരിച്ചത്, തിരഞ്ഞെടുത്തത്, പ്രഖ്യാപിക്കുന്നത് എന്നിവ വേർതിരിക്കുന്നു, അവയോരോന്നും നയത്താൽ നിയന്ത്രിക്കപ്പെടുന്നു. ശാഖാ നെറ്റ്‌വർക്കിന് കൃത്യമായി അതാണ് വേണ്ടത്, കാരണം ഒരു സ്പോക്ക് സാധാരണയായി ഡിഫോൾട്ട് റൂട്ട്, കേന്ദ്ര സേവനങ്ങൾ, വളരെ കുറച്ച് മറ്റ് കാര്യങ്ങൾ എന്നിവ കാണണം. അവസാന പട്ടിക മാത്രം എണ്ണുന്നത് ബദലുകളും പ്രഖ്യാപനങ്ങളും മറയ്ക്കുന്നു, പകരം വയ്ക്കൽ ചേർക്കുമ്പോൾ വളരുന്ന ഭാഗങ്ങൾ കൃത്യമായി അവയാണ്.
IGP സ്വയം തെറ്റല്ല. ടോപ്പോളജി, മേഖലാ ഘടന, അയൽപക്ക മാതൃക എന്നിവ സേവനത്തിന് യോജിക്കുമ്പോൾ, ലിങ്ക്-സ്റ്റേറ്റ് പ്രോട്ടോക്കോൾ വേഗത്തിൽ സംവദിക്കുന്നു, കുറച്ച് നയ കെട്ടുപണി മതി. കെണി അത് BGP പോലെ ഓരോ അയൽക്കാരനും ഉള്ള കയറ്റുമതി നിയന്ത്രണം പ്രകടിപ്പിക്കാമെന്ന് കരുതുന്നതാണ്: OSPF മേഖല വെള്ളപ്പൊക്ക അതിർത്തിയാണ്, ഒരു ശാഖയിൽ തൂക്കിയിടാവുന്ന ഫിൽട്ടറല്ല.
ഏതായാലും, ആദ്യം ദൃശ്യതാ മാതൃക തീരുമാനിക്കുക. ഡിഫോൾട്ട് റൂട്ടുകൾ, കേന്ദ്ര സേവനങ്ങൾക്കുള്ള സംഗ്രഹങ്ങൾ, അല്ലെങ്കിൽ പൂർണ്ണ ശാഖാ വിശദാംശങ്ങൾ എന്നിവ മൂന്ന് വ്യത്യസ്ത ഉൽപ്പന്നങ്ങളാണ്, കൂടുതൽ നിർദ്ദിഷ്ട പരാജയം മറയ്ക്കുന്ന സംഗ്രഹം എഴുതേണ്ട ഡിസൈൻ തീരുമാനമാണ്, തകരാറിനിടയിൽ കണ്ടെത്തേണ്ടതല്ല.
പ്രവാഹം പരീക്ഷിക്കുക, സ്ഥിരാവസ്ഥയല്ല
നിങ്ങൾ യഥാർത്ഥത്തിൽ പ്രതീക്ഷിക്കുന്ന പരാജയത്തിന് ചുറ്റും താരതമ്യം കെട്ടിപ്പടുക്കുക: ഹബ്ബ് ഡൗൺ, പ്രാദേശിക WAN സംഭവം, അല്ലെങ്കിൽ പകുതി സൈറ്റുകൾ ഒരുമിച്ച് ഓഫ്‌ലൈനാക്കുന്ന അറ്റകുറ്റപ്പണി വിൻഡോ. ശാഖയുടെ വീക്ഷണത്തിൽ നിന്ന് വീണ്ടെടുപ്പ് അളക്കുക, ആപ്ലിക്കേഷൻ ഉൾപ്പെടെ, കാരണം സെക്കൻഡുകളിൽ സംവദിക്കുന്ന നിയന്ത്രണ-തലം സെഷൻ വീണ്ടും സ്ഥാപിക്കാൻ മിനിറ്റുകൾ എടുക്കുന്നുവെങ്കിൽ വലിയ കാര്യമല്ല.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPFപ്ലാറ്റ്ഫോം വിശ്രമത്തിൽ എന്ത് ചെയ്യുന്നു എന്നല്ല, പ്രവാഹത്തിന്റെ ഉച്ചകോടിയിൽ എന്ത് ചെയ്യുന്നു എന്ന് രേഖപ്പെടുത്തുക, സുരക്ഷാ സവിശേഷതകൾ ഓണാക്കി അത് ആവർത്തിക്കുക. ശാന്തമായ ഒരു പട്ടിക മാത്രം കാണിക്കുന്ന തെളിവ് മെമ്മറി പരീക്ഷയാണ്, മെമ്മറി ഒരിക്കലും രസകരമായ സംഖ്യയായിരുന്നില്ല.