DSCP അടയാളപ്പെടുത്തലോ ദാതാവിന്റെ QoS വാഗ്ദാനമോ? രണ്ടും കരാറല്ല

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

local match → queue and marking → provider classifier
  → provider treatment → destination

ശരിയായ അടയാളപ്പെടുത്തൽ എവിടെ നിശബ്ദമായി മരിക്കാം

ഓരോ വർക്ക്ലോഡിനും പ്രാദേശിക പൊരുത്ത കണ്ടീഷൻ, ടണലിനുള്ളിൽ സംഭവിക്കുന്ന ഏത് അടയാളപ്പെടുത്തലും, ദാതാവ് സ്വീകരിക്കുന്ന മൂല്യവും ആ മൂല്യം തിരഞ്ഞെടുക്കുന്ന സേവന ക്ലാസും എഴുതി തുടങ്ങുക. നാല് നിരകൾ, പരാജയങ്ങൾ സാധാരണയായി രണ്ടാമത്തേതിനും മൂന്നാമത്തേതിനും ഇടയിൽ കഴിയുന്നു.

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

പ്രാദേശികമായി പേരിട്ട ക്ലാസും ശൂന്യമായി നിൽക്കാം, കാരണം അതിന്റെ പൊരുത്ത കണ്ടീഷൻ യഥാർത്ഥ പാക്കറ്റുകളിൽ ഒരിക്കലും സജീവമാകുന്നില്ല. പോർട്ടുകൾ നീങ്ങുന്നു, ആപ്ലിക്കേഷനുകൾ പല ഒഴുക്കുകൾ ഉപയോഗിക്കുന്നു, വിൽപ്പനക്കാരൻ രണ്ട് റിലീസുകൾക്ക് മുമ്പ് ഉപയോഗിക്കുന്നത് നിർത്തിയ ഒരു അറിയപ്പെടുന്ന പോർട്ടിലെ പൊരുത്തം പൂജ്യം കൗണ്ടറുകളുള്ള ഒരു ക്യൂവും പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷനിൽ തികഞ്ഞതായി തോന്നുന്ന ഒരു നയവും സൃഷ്ടിക്കുന്നു.

അടയാളപ്പെടുത്തലുകൾ എവിടെ വിശ്വസിക്കുന്നു എന്ന് വ്യക്തമായി തീരുമാനിക്കുക. ഒരു ടണൽ പങ്കിടുന്ന എല്ലാം ഉയർത്തുന്നത് കോളുകൾക്കൊപ്പം ബൾക്ക് കൈമാറ്റങ്ങളും ഉയർത്തുന്നു, പരിശോധനയില്ലാതെ നിങ്ങളുടെ അടയാളപ്പെടുത്തൽ സ്വീകരിക്കുന്ന ദാതാവ് സ്വയം ദ്രോഹിക്കാനുള്ള ഒരു വഴി നൽകുന്നു. കരാർ ഗേറ്റ്വേയ്ക്ക് കൈമാറ്റത്തിൽ വീണ്ടും അടയാളപ്പെടുത്താൻ അനുവദിക്കുന്നുവെങ്കിൽ അത് എഴുതി വയ്ക്കുക, കാരണം രണ്ട് ടീമുകളുടെ അനുമാനങ്ങൾ സാധാരണയായി വേർതിരിയുന്നത് അവിടെയാണ്.

ഷെഡ്യൂളർ യഥാർത്ഥത്തിൽ എന്ത് വിഭജിക്കുന്നു

പ്രാദേശിക നയത്തിന് സ്വന്തം അർത്ഥശാസ്ത്രമുണ്ട്, ഏറ്റവും കൂടുതൽ തെറ്റിദ്ധാരണ “remaining” എന്ന വാക്ക് സൃഷ്ടിക്കുന്നു. IOS XE ഷെഡ്യൂളിംഗ് ഗൈഡ് വിവരിക്കുന്ന പ്ലാറ്റ്ഫോമുകളിൽ bandwidth remaining percent അധിക ഭാരം സജ്ജമാക്കുന്നു, ഓരോ ക്ലാസും മുൻ ക്ലാസ് വിട്ടതിൽ നിന്ന് ഒരു വിഹിതം എടുക്കുന്ന ക്രമത്തിലെ ഒരു ഘട്ടമല്ല. അനുവദിക്കാത്ത ശതമാനങ്ങൾ ഫയലിലെ അവസാന ക്ലാസിനായി സംവരണം ചെയ്യുന്നതിന് പകരം യോഗ്യമായ കോൺഫിഗർ ചെയ്യാത്ത ക്യൂകളിൽ വിതരണം ചെയ്യുന്നു.

ആ വ്യത്യാസം പ്രധാനമാണ്, കാരണം ക്രമാനുഗത മാനസിക മാതൃക കൗണ്ടറുകളുമായി ഒരിക്കലും പൊരുത്തപ്പെടാത്ത പ്രവചനങ്ങൾ നൽകുന്നു. എൻജിനീയർമാർ ഫലം മാറ്റാൻ ക്ലാസുകൾ പുനഃക്രമീകരിക്കുന്നു, വ്യത്യാസം കാണുന്നില്ല, പ്ലാറ്റ്ഫോം തകർന്നിരിക്കുന്നു എന്ന് തീരുമാനിക്കുന്നു, എന്നാൽ കോൺഫിഗറേഷൻ അവർ അനുമാനിച്ചത് ഒരിക്കലും അർത്ഥമാക്കിയിരുന്നില്ല.

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

കൗണ്ടറുകൾ ഏത് പകുതി പരാജയപ്പെട്ടു എന്ന് പറയുന്നു

ബാധിത ദിശയിൽ നാല് സംഖ്യകൾ താരതമ്യം ചെയ്യുക: എന്ത് വാഗ്ദാനം ചെയ്തു, ക്ലാസ് എന്തിനോട് പൊരുത്തപ്പെട്ടു, എന്ത് ക്യൂവിൽ ചേർന്നു അല്ലെങ്കിൽ ഉപേക്ഷിക്കപ്പെട്ടു, സേവനം യഥാർത്ഥത്തിൽ എന്ത് എത്തിച്ചു. വർക്ക്ലോഡ് വിവരണവും നയ പതിപ്പും നിരീക്ഷണത്തിനൊപ്പം സൂക്ഷിക്കുക, കാരണം അവയില്ലാതെ കൗണ്ടറുകളുടെ സ്ക്രീൻഷോട്ട് പുനർനിർമ്മിക്കാൻ കഴിയില്ല.

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

RFC 2475 വർഗ്ഗീകരണത്തെയും കണ്ടീഷനിംഗിനെയും ഭരണപരമായ ഡൊമെയ്നുകൾക്കുള്ളിൽ ചെയ്യുന്ന ജോലിയായി ചട്ടക്കൂട്ടുന്നു, അതുകൊണ്ടുതന്നെ അടയാളപ്പെടുത്തലിന് ക്യൂകൾ അറ്റം മുതൽ അറ്റം വരെ സംവരണം ചെയ്യാനാവില്ല. IOS XE ഷെഡ്യൂളിംഗ് ഗൈഡ് മുകളിൽ വിവരിച്ച അധിക-ഭാര സ്വഭാവത്തിന്റെ റഫറൻസാണ്, മോഡലുകൾക്കിടയിൽ കണക്കാക്കിയ നിരക്ക് നീക്കുന്നതിന് മുമ്പ് അതിന്റെ പ്ലാറ്റ്ഫോം താരതമ്യങ്ങൾ വായിക്കുന്നത് മൂല്യവത്താണ്.

കരാർ ഒരിടത്ത് എഴുതുക

പ്രാദേശിക പൊരുത്തം, വിശ്വാസ അതിർത്തി, ദാതാവിന്റെ ക്ലാസ്, അളന്ന സേവന നില എന്നിവ ഇരുവിഭാഗവും ഒപ്പിടുന്ന ഒരു രേഖയിൽ ഇടുക. അപ്പോൾ ശതമാന മാറ്റത്തിന് സന്ദർഭമുണ്ട്, ഗുണനിലവാര പരാതിക്ക് ഉടമയുണ്ട്.

പ്രാദേശിക ശതമാനം മാറ്റുന്നത് മറ്റൊരു ക്യൂവിന്റെ ഗ്യാരണ്ടി നന്നാക്കാനാവില്ല, ദാതാവ് പാലിക്കാത്ത മാപ്പിംഗിൽ നിന്ന് ഏത് അടയാളപ്പെടുത്തൽ പദ്ധതിയും അതിജീവിക്കില്ല. രണ്ട് പകുതികളും താരതമ്യം ചെയ്യുക, അതിർത്തിക്ക് പേരിടുക, അതിനുശേഷം മാത്രം ഒരു സംഖ്യ ഉദ്ധരിക്കുക.