ഓരോ ടണലിനുമുള്ള QoS നിങ്ങളുടെ ഹബ്ബിന്റെ മൊത്തം അപ്‌ലിങ്ക് പരിമിതപ്പെടുത്തുന്നില്ല

ഈ വിശ്വാസം ഗണിതം പോലെ തോന്നുന്നു: അഞ്ച് സ്പോക്കുകൾ, ഓരോന്നും 5 Mbit/s ആയി രൂപപ്പെടുത്തിയത്, അതിനാൽ ഹബ്ബ് പരമാവധി 25 Mbit/s വഹിക്കുന്നു. ആദ്യ പകുതി ശരിയാണ്, നിഗമനം അല്ല. ഓരോ ടണലിനുമുള്ള നയം ഓരോ ടണലിനും ഒരിക്കൽ പ്രയോഗിക്കുന്നു, ഓരോ ഹബ്ബിനും ഒരിക്കലല്ല, കൂടാതെ അഞ്ച് ടണലുകളും കടക്കുന്ന പങ്കിട്ട അപ്ലിങ്ക് ആ കണക്കിൽ ഒരിക്കലും പ്രത്യക്ഷപ്പെടുന്നില്ല. അപ്ലിങ്കിലെ തിരക്ക് കൃത്യമായി അതേപടി തുടരുന്നു.

ഈ വിശ്വാസം എവിടെ നിന്ന് വരുന്നു

ആശയക്കുഴപ്പം മനസ്സിലാക്കാം, കാരണം NHRP ഗ്രൂപ്പ് വിവരങ്ങൾ ഒരു നയ നിർവചനം മുഴുവൻ സ്പോക്ക് കൂട്ടത്തിനും ബാധകമാകാൻ അനുവദിക്കുന്നു. അത് കോൺഫിഗറേഷൻ ഫയലിലെ പങ്കിട്ട ബജറ്റ് പോലെ വായിക്കുന്നു. യഥാർത്ഥത്തിൽ അതിന്റെ അർത്ഥം ഓരോ സ്പോക്കും ആ നിർവചനത്തിന്റെ സ്വന്തം ഇൻസ്റ്റൻസ് നേടുന്നു എന്നാണ്.

അതിനാൽ ഓരോ സ്പോക്കിനും 5 Mbit/s എന്നത് ഓരോ ടണലിനുമുള്ള പരിധിയാണ്, ടണലുകളുടെ എണ്ണത്തിന് തുല്യം പരിധികളുണ്ട്.

ഒരു നയ ഇൻസ്റ്റൻസ് നിയന്ത്രിക്കുന്നത്

Cisco-യുടെ IOS XE-യിലെ DMVPN-ിൽ ഓരോ ടണലിനുമുള്ള QoS മാർഗ്ഗദർശി NHRP ഗ്രൂപ്പ് വിവരങ്ങളിലൂടെ തിരഞ്ഞെടുത്ത് ഓരോ സ്പോക്കിനും വെവ്വേറെ പ്രയോഗിക്കുന്ന ഹബ്ബ് എഗ്രസ് നയം വിവരിക്കുന്നു. ആ വാക്യത്തിൽ നിന്ന് രണ്ട് പരിമിതികൾ ഉരുത്തിരിയുന്നു, രണ്ടും അവഗണിക്കപ്പെടുന്നു. നിരക്ക് പങ്കിട്ട ബക്കറ്റിനല്ല, ഒരു സ്പോക്കിനാണ്, കൂടാതെ ഈ സവിശേഷത ഹബ്ബിൽ നിന്ന് സ്പോക്കിലേക്കുള്ള ട്രാഫിക് നിയന്ത്രിക്കുന്നു, അല്ലാതെ തിരിച്ചല്ല.

സ്പോക്കിന്റെ അയയ്ക്കൽ ദിശ സ്വതന്ത്രമായി ആസൂത്രണം ചെയ്യുക. ഹബ്ബ് എഗ്രസ് നയത്തിൽ ശാഖ അപ്ലോഡ് ചെയ്യുന്നതിനെ പരിമിതപ്പെടുത്തുന്ന ഒന്നുമില്ല.

മൊത്തം പരിധി പങ്കിട്ട കുരുക്കിൽ വയ്ക്കുക

മൊത്തം അത് യഥാർത്ഥത്തിൽ മത്സരിക്കുന്നിടത്ത് രൂപപ്പെടുത്തണം: എല്ലാ ടണലുകളും പങ്കിടുന്ന ഭൗതിക ഇന്റർഫേസിൽ. Cisco ഈ സവിശേഷതയ്ക്ക് പിന്തുണയുള്ള ഒരേസമയ ഭൗതിക നയമായി ഭൗതിക ഇന്റർഫേസിലെ class-default ഷേപ്പർ രേഖപ്പെടുത്തുന്നു, ഇത് നിങ്ങൾക്ക് ടൈപ്പ് ചെയ്യാവുന്ന ഏത് ശ്രേണിയെക്കാളും ഇടുങ്ങിയ പ്രസ്താവനയാണ്. നിങ്ങൾ കണ്ടുപിടിച്ച ഏകപക്ഷീയമായ രണ്ടാമത്തെ ഭൗതിക നയത്തിന് ആരെങ്കിലും വിപരീതം തെളിയിക്കുന്നതുവരെ പിന്തുണയില്ലെന്ന് കരുതുക.

തുടർന്ന് എല്ലാ സ്പോക്കുകളും ഒരേസമയം തിരക്കിലായിരിക്കുമ്പോൾ എന്ത് സംഭവിക്കുമെന്ന് തീരുമാനിക്കുക. ഏത് ട്രാഫിക് അനുവദിക്കുന്നു, ഏത് ക്ലാസിന് മുൻഗണന ലഭിക്കുന്നു, ഏത് ക്യൂവിനാണ് മത്സരം. ഓരോ സ്പോക്കിനുമുള്ള പരിധി ഈ ചോദ്യങ്ങളിൽ ഒന്നിനും ഉത്തരം നൽകുന്നില്ല, കാരണം ഓരോ സ്പോക്കും ഒറ്റയ്ക്കാണ് പരിഗണിക്കുന്നത്.

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

കൗണ്ടറുകൾ ഒരു പ്രത്യേക രീതിയിൽ കള്ളം പറയുന്നു

നിങ്ങൾ ഷേപ്പ് ചെയ്യുന്ന ലെയറിൽ കൗണ്ടറുകൾ വായിക്കുക. അതേ Cisco മാർഗ്ഗദർശി ഈ ക്രമീകരണത്തിൽ പ്രധാന ഇന്റർഫേസ് നയ കൗണ്ടറുകൾ കൃത്യമല്ലാതിരിക്കാമെന്ന് മുന്നറിയിപ്പ് നൽകുന്നു. അത് കൗണ്ടറിനെക്കുറിച്ചുള്ള മുന്നറിയിപ്പാണ്, ഒരു ക്ലാസ് പൊരുത്തപ്പെടുന്നു അല്ലെങ്കിൽ ഉപേക്ഷിക്കുന്നു എന്നതിന് തെളിവല്ല. അത് ആപ്ലിക്കേഷൻ ഫലത്തിൽ നിന്ന് വേർതിരിക്കുക, ഉപയോക്താവ് അനുഭവിക്കുന്ന ഏക കാര്യം അതാണ്.

പഴയ traffic-shape ഉദാഹരണം ബന്ധമില്ലാത്ത ഒരു നയ മാപ്പിന് അടുത്ത് പകർത്തുന്നത് രണ്ട് നിരക്കുകളും ഒരേ പാക്കറ്റുകൾ നിയന്ത്രിക്കുന്നു എന്ന് തെളിയിക്കുന്നില്ല.

പരിധി മാത്രമല്ല, മൊത്തം പരിശോധിക്കുക

ഒരു തിരക്കുള്ള സ്പോക്കിൽ നിന്ന് തുടങ്ങി അത് അതിന്റെ പരിധിയിൽ എത്തുന്നുവെന്ന് ഉറപ്പാക്കുക. തുടർന്ന് അനുവദിച്ച പ്ലാൻ പ്രകാരം എല്ലാവരിൽ നിന്നും ഒരേസമയം ട്രാഫിക് നൽകുക, ഓരോ ടണലിനുമുള്ള സംഖ്യകൾക്കൊപ്പം ഭൗതിക ഇന്റർഫേസ് നിരീക്ഷിക്കുക. ഓരോ സ്പോക്കും അതിന്റെ പരിധിയിൽ ഇരിക്കുമ്പോൾ അപ്ലിങ്ക് തിങ്ങുകയും കാലതാമസം ഉയരുകയും ചെയ്താൽ, ഓരോ സ്പോക്കിനുമുള്ള നയം രൂപകൽപ്പന ചെയ്തതുപോലെ പ്രവർത്തിക്കുന്നു, ബജറ്റ് ഇപ്പോഴും തെറ്റാണ്.

ആ ഘട്ടത്തിലെ പരിഹാരം ശേഷി അല്ലെങ്കിൽ പ്രവേശന തീരുമാനമാണ്. ഓരോ സ്പോക്കിനുമുള്ള സംഖ്യകൾ വീണ്ടും ക്രമീകരിക്കുന്നത് ഏത് ശാഖ ആദ്യം പരാതിപ്പെടുന്നു എന്നത് മാത്രം മാറ്റുന്നു.