ഓരോ VRF-നും ഒരു ലേബൽ അല്ലെങ്കിൽ ഓരോ പ്രിഫിക്സിനും ഒരു ലേബൽ? യഥാർത്ഥ ശേഷി ബിൽ

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

ലേബൽ നീക്കിയ ശേഷം പുറത്തേക്കുള്ള റൗട്ടർ പാക്കറ്റുമായി എന്ത് ചെയ്യണം എന്നതിനെയും തിരഞ്ഞെടുപ്പ് ആശ്രയിച്ചിരിക്കുന്നു. ലേബൽ ഗണിതമല്ല, ആ പ്രവർത്തന വ്യത്യാസമാണ് തീരുമാനത്തെ നയിക്കേണ്ടത്.

ഓരോ അനുവദനം യഥാർത്ഥത്തിൽ എന്ത് ലാഭിക്കുന്നു

പ്രിഫിക്സിന് ഒരു അനുവദനം ഫോർവേഡിംഗ് വിവരങ്ങൾ ലേബലിൽ വഹിക്കുന്നു. പുറത്തേക്കുള്ള റൗട്ടറിന് ലക്ഷ്യസ്ഥാന തിരയൽ കൂടാതെ പാക്കറ്റ് നേരിട്ട് ശരിയായ അയൽക്കൂട്ടത്തിലേക്ക് അയക്കാം, അതിനാലാണ് ഇത് വലിയ VRF റൂട്ട് സെറ്റുകൾക്ക് നന്നായി സ്കെയിൽ ചെയ്യുന്നത്, അതിനാലാണ് ഇത് ഓരോ VRF-ലും ഓരോ പ്രഖ്യാപിത പ്രിഫിക്സിനും ഒരു ലേബൽ ചെലവഴിക്കുന്നത്. VRF-ന് ഒരു അനുവദനം, ഉദാഹരണത്തിന് Junos vrf-table-label, ഓരോ റൂട്ടിംഗ് ഇൻസ്റ്റൻസിനും ഒരു ലേബൽ പ്രഖ്യാപിക്കുകയും VRF പട്ടിക തിരഞ്ഞെടുക്കാൻ ആ ലേബൽ ഉപയോഗിക്കുകയും ചെയ്യുന്നു; തുടർന്ന് റൗട്ടർ പട്ടികയ്ക്കുള്ളിൽ IP തിരയൽ നടത്തുന്നു.

അത് ട്യൂണിംഗ് നോബ് അല്ല, യഥാർത്ഥ വാസ്തുവിദ്യാ വ്യത്യാസമാണ്. VRF-ന് ലേബലിംഗ് നിങ്ങൾക്ക് ചെറിയ ലേബൽ സ്ഥലവും ലളിതമായ ലേബൽ പ്രഖ്യാപനവും നൽകുന്നു, എന്നാൽ ഒരു തിരയലിന്റെയും ലക്ഷ്യസ്ഥാനത്തെക്കുറിച്ച് ഒന്നും പറയാത്ത ലേബലിന്റെയും വിലയ്ക്ക്. പ്രിഫിക്സിന് ലേബലിംഗ് പുറത്തേക്കുള്ള ലൈൻ കാർഡിന് മുൻകൂട്ടി കൂടുതൽ വിവരങ്ങൾ നൽകുന്നു, നിങ്ങൾ വഹിക്കുന്ന റൂട്ടുകൾക്ക് ആനുപാതികമായി ലേബലുകൾ ചെലവഴിക്കുന്നു.

ലേബൽ ലെഡ്ജർ ചെറുതാണ്

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

തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് സേവനത്തിനും ഗതാഗതത്തിനും ലേബലുകൾ എണ്ണുക. VRF-ന് ഒരു ഡിസൈനിന് ഇപ്പോഴും loopback-കൾക്കും പാതയിലെ ഓരോ ഹോപ്പിനും ഗതാഗത ലേബലുകൾ ആവശ്യമാണ്, ഇപ്പോഴും അയൽക്കൂട്ട അവസ്ഥ ആവശ്യമാണ്. ഡിസൈൻ സംക്ഷേപം സേവന ലേബലുകൾ മാത്രം എണ്ണുന്നുവെങ്കിൽ, ലാഭം തെറ്റായ ലെഡ്ജറിൽ അളക്കുകയാണ്.

റൂട്ട് ഫീഡുകൾ ലേബലുകൾക്ക് മുമ്പ് മെമ്മറി ചെലവഴിക്കുന്നു

സ്വീകരിച്ച ഓരോ പാതയും നിയന്ത്രണ തലത്തിലെ മെമ്മറി, അപ്ഡേറ്റ് പ്രോസസ്സിംഗ്, കൺവെർജൻസ് സമയം ചെലവഴിക്കുന്നു, VRF ഒരു ലേബലോ പതിനായിരമോ ഉപയോഗിച്ചാലും. VRF-നുള്ളിൽ മുഴുവൻ ഇന്റർനെറ്റ് ഫീഡ് BGP പാതകൾ, RIB, FIB എൻട്രികൾ, അവയ്ക്ക് പിന്നിലെ കലക്കം എന്നിവ കാരണം ചെലവേറിയതാണ്, പട്ടികയ്ക്ക് മുന്നിലെ ലേബൽ കാരണമല്ല. അതേ ഫീഡ് ആ വാടകക്കാരനുള്ളിൽ റൂട്ട് ചോർച്ചയുടെയോ നയ പിശകിന്റെയോ സ്വാധീന വ്യാസവും വർദ്ധിപ്പിക്കുന്നു.

അതിനാൽ ഉപഭോക്താവിന് യഥാർത്ഥത്തിൽ എന്ത് ആവശ്യമാണെന്ന് ചോദിക്കുക. കരാർ സ്വകാര്യ സൈറ്റുകളും സ്ഥിരസ്ഥിതി പുറത്തേക്കുള്ള പാതയും ആണെങ്കിൽ, മുഴുവൻ പട്ടികയും ആവശ്യകത കൂട്ടാതെ ചെലവ് കൂട്ടുന്നു. അത് ഒരു വാണിജ്യ ചോദ്യമാണ്, മുൻ ഡിസൈനിൽ നിന്ന് പകർന്ന ഊഹത്തിന് പകരം എഴുത്തിലുള്ള ഉത്തരത്തിന് അർഹമാണ്. സേവനത്തിന് നയത്തിനോ പ്രാദേശിക പുറത്തേക്കുള്ള തിരഞ്ഞെടുപ്പിനോ ഫീഡ് യഥാർത്ഥത്തിൽ ആവശ്യമാണെങ്കിൽ, അതിനെ സ്വന്തം ശേഷി സംവരണവും സ്വന്തം പരാജയ സ്വഭാവവുമുള്ള വ്യക്തമായ വരിയാക്കുക.

VRF-ന് ലേബലിംഗ് എപ്പോഴാണ് ശരിയായ സ്ഥിരസ്ഥിതി

പ്ലാറ്റ്ഫോം അതിനെ പിന്തുണയ്ക്കുന്നതായി രേഖപ്പെടുത്തുമ്പോൾ, VRF റൂട്ടുകളുടെ എണ്ണം വലുതാകുമ്പോൾ, പുറത്തേക്കുള്ള തിരയൽ ചെലവ് ട്രാഫിക് പ്രൊഫൈലിന് സ്വീകാര്യമാകുമ്പോൾ അത് നല്ല സ്ഥിരസ്ഥിതിയാണ്. ഫോർവേഡിംഗിൽ നിന്ന് അവസാന മൈക്രോസെക്കൻഡ് പിഴിഞ്ഞെടുക്കുന്നതിനേക്കാൾ പ്രവർത്തന ലാളിത്യം പ്രധാനമാകുമ്പോൾ അത് സ്വാഭാവിക തിരഞ്ഞെടുപ്പുമാണ്, കാരണം ഓരോ വാടകക്കാരനും ഒരു ലേബൽ എന്നത് ഓരോ പ്രിഫിക്സിനും ഒരു ലേബൽ എന്നതിനേക്കാൾ വിശദീകരിക്കാനും പരിശോധിക്കാനും എളുപ്പമാണ്.

പ്ലാറ്റ്ഫോമിന്റെ രേഖകൾ ഈ സവിശേഷതയെ നിർദ്ദിഷ്ട ഹാർഡ്വെയർ അല്ലെങ്കിൽ റിലീസ് നിയന്ത്രണങ്ങളുമായി ബന്ധിപ്പിക്കുമ്പോൾ, അല്ലെങ്കിൽ ഡിസൈൻ പുറത്തേക്കുള്ള ഭാഗത്ത് പ്രിഫിക്സിന് ഫോർവേഡിംഗ് തീരുമാനങ്ങളെ ആശ്രയിക്കുമ്പോൾ അത് തെറ്റായ സ്ഥിരസ്ഥിതിയാണ്. സ്വഭാവം അനുമാനിക്കുന്നതിന് മുമ്പ് പ്ലാറ്റ്ഫോമിന്റെ സ്വന്തം statement റെഫറൻസ് വായിക്കുക; Junos കമാൻഡ് രേഖപ്പെടുത്തിയിട്ടുണ്ട്, പക്ഷേ അതിന് ചുറ്റുമുള്ള ഹാർഡ്വെയർ, റിലീസ് പരിധികളാണ് വിന്യാസം യഥാർത്ഥത്തിൽ തീരുമാനിക്കുന്നത്.

നിങ്ങൾക്ക് പ്രതിരോധിക്കാൻ കഴിയുന്ന ബജറ്റ്

ശേഷി വാദം അഞ്ച് വെവ്വേറെ സംഖ്യകളായി നിർമ്മിക്കുക: സ്വീകരിച്ച പാതകൾ, തിരഞ്ഞെടുത്ത റൂട്ടുകൾ, ഇൻസ്റ്റാൾ ചെയ്ത ഫോർവേഡിംഗ് എൻട്രികൾ, സേവന ലേബലുകൾ, ഗതാഗത ലേബലുകൾ. next-hop, അയൽക്കൂട്ട അവസ്ഥ, വാടകക്കാരുടെ എണ്ണം, റിഡണ്ടൻസി മാതൃക എന്നിവ ചേർക്കുക. ഒരു VRF-ന്റെ സുഗമമായ പാതയുടെ സ്നാപ്പ്ഷോട്ട് സ്കെയിൽ സംഖ്യയല്ല, ലേബൽ ഇടത്തിന്റെ നാമമാത്ര വലിപ്പം ലഭ്യമായ ഹാർഡ്വെയർ പട്ടികയുമല്ല.

തുടർന്ന് സ്ഥിരമായ അവസ്ഥയോടൊപ്പം പരാജയ മോഡിലും യോജിക്കുക. ഫീഡ് പകുതി വളരുമ്പോൾ, വാടകക്കാരൻ രണ്ടാമത്തെ VRF ചേർക്കുമ്പോൾ, അല്ലെങ്കിൽ പട്ടികയുടെ വലിപ്പം മാറ്റാൻ പ്ലാറ്റ്ഫോമിന് റീബൂട്ട് ആവശ്യമാകുമ്പോൾ എന്ത് സംഭവിക്കും? ആ ചോദ്യങ്ങളെ അതിജീവിക്കുന്ന ബജറ്റ് കടലാസിൽ മാത്രം പ്രവർത്തിക്കുന്ന ലേബൽ എണ്ണത്തേക്കാൾ മൂല്യമുള്ളതാണ്.

പുറത്തേക്കുള്ള പ്രവർത്തനത്തിൽ നിന്നും പ്ലാറ്റ്ഫോം പരിധികളിൽ നിന്നും അനുവദനം തിരഞ്ഞെടുക്കുക, തുടർന്ന് റൂട്ട് ഫീഡിനെ വ്യക്തമായ സേവന തീരുമാനമാക്കുക. ലേബൽ ഡിസൈനിന്റെ ദൃശ്യ ഭാഗമാണ്; റൂട്ടുകൾ എല്ലാ ദിവസവും നൽകേണ്ട ഭാഗമാണ്.