DSCP માર્કિંગ કે પ્રોવાઇડરનું QoS વચન? બંનેમાંથી કોઈ કરાર નથી

કંઈક માર્ક થાય છે, એક કતાર ગોઠવાય છે, અને પછી કોઈ પૂછે છે કે ડિઝાઇન ખરેખર કઈ ગુણવત્તાની બાંયધરી આપે છે. પ્રામાણિક જવાબ એ છે કે તમે એક કરારના બે અડધા ભાગ વર્ણવ્યા છે જે સીમા પર મળે છે. જ્યાં સુધી તમે પ્રોવાઇડર સ્વીકારે તે વર્ગ અને તે લાગુ કરે તે સારવારનું નામ ન આપી શકો, ત્યાં સુધી સ્થાનિક રૂપરેખાંકન વચન નહીં પણ ઇરાદો છે. બંને અડધા ભાગ મહત્વપૂર્ણ છે, અને એકમાંથી બીજાનું અનુમાન કરી શકાતું નથી.

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

સાચું માર્કિંગ ક્યાં શાંતિથી મરી શકે છે

દરેક વર્કલોડ માટે સ્થાનિક મેચ શરત, ટનલની અંદર થતું કોઈપણ માર્કિંગ, પ્રોવાઇડર સ્વીકારે તે મૂલ્ય અને તે મૂલ્ય પસંદ કરે તે સેવા વર્ગ લખીને શરૂ કરો. ચાર કોલમ, અને નિષ્ફળતાઓ સામાન્ય રીતે બીજા અને ત્રીજા વચ્ચે રહે છે.

અંદરથી બહાર તરફ માર્કિંગનું વર્તન એ ઉત્તમ સમસ્યા છે. એન્ક્રિપ્ટેડ અથવા ટનલવાળા માર્ગમાંનું પેકેટ અંદરનું હેડર ધરાવે છે જે તમારો વર્ગીકરણકર્તા જોઈ શકે છે અને બહારનું હેડર જે પ્રોવાઇડરનાં સાધનો જોઈ શકે છે, અને એકને બીજામાં નકલ કરવી એ રૂપરેખાંકનનો નિર્ણય છે, આપમેળે મળતો ગુણધર્મ નથી. ફક્ત અંદરનું હેડર માર્ક કરો અને પ્રોવાઇડર બહારનું વર્ગીકૃત કરે છે, સામાન્ય રીતે ડિફોલ્ટ તરીકે, તેથી યોગ્ય રીતે માર્ક કરેલો પ્રવાહ તમારી બાજુએ એક પણ ખોટી રૂપરેખાંકિત લાઇન વિના ખોટા વર્ગમાં પહોંચી શકે છે.

સ્થાનિક રીતે નામ આપેલો વર્ગ પણ ખાલી રહી શકે છે કારણ કે તેની મેચ શરત વાસ્તવિક પેકેટો પર ક્યારેય સક્રિય થતી નથી. પોર્ટ ખસે છે, એપ્લિકેશનો ઘણા પ્રવાહો વાપરે છે, અને જાણીતા પોર્ટ પરની મેચ જે વિક્રેતાએ બે રિલીઝ પહેલાં વાપરવાનું બંધ કર્યું તે શૂન્ય કાઉન્ટરવાળી કતાર અને ચાલુ રૂપરેખાંકનમાં સંપૂર્ણ દેખાતી નીતિ બનાવે છે.

માર્કિંગ ક્યાં વિશ્વાસ કરવો તે સ્પષ્ટપણે નક્કી કરો. ટનલ વહેંચતું બધું ઉન્નત કરવું કૉલ સાથે બલ્ક ટ્રાન્સફર પણ ઉન્નત કરે છે, અને જે પ્રોવાઇડર ચકાસણી વિના તમારું માર્કિંગ સ્વીકારે છે તે તમને જાતને નુકસાન પહોંચાડવાનો રસ્તો આપે છે. જો કરાર ગેટવેને સોંપણી વખતે ફરી માર્ક કરવાની મંજૂરી આપે, તો તે લખિતમાં કહો, કારણ કે બે ટીમોની ધારણાઓ સામાન્ય રીતે એ જ બિંદુએ અલગ પડે છે.

શેડ્યુલર ખરેખર શું વિભાજિત કરે છે

સ્થાનિક નીતિનું પોતાનું અર્થશાસ્ત્ર છે, અને સૌથી વધુ ગેરસમજ “remaining” શબ્દ સર્જે છે. IOS XE શેડ્યુલિંગ માર્ગદર્શિકા જે પ્લેટફોર્મનું વર્ણન કરે છે તેમાં bandwidth remaining percent વધારાનું વજન સેટ કરે છે, એવા ક્રમમાં પગલું નહીં જ્યાં દરેક વર્ગ પાછલા વર્ગે છોડેલા ભાગમાંથી હિસ્સો લે છે. ન ફાળવેલી ટકાવારી ફાઇલના છેલ્લા વર્ગ માટે અનામત રાખવાને બદલે પાત્ર બિન-રૂપરેખાંકિત કતારોમાં ફેલાય છે.

એ ભેદ મહત્વપૂર્ણ છે કારણ કે ક્રમિક માનસિક મોડેલ એવી આગાહીઓ આપે છે જે ક્યારેય કાઉન્ટર સાથે મેળ ખાતી નથી. ઇજનેરો પરિણામ બદલવા વર્ગોનું પુનર્ગઠન કરે છે, કોઈ ફરક જોતા નથી અને તારણ કાઢે છે કે પ્લેટફોર્મ બગડેલું છે, જ્યારે રૂપરેખાંકનનો અર્થ ક્યારેય તેમની ધારણા નહોતો.

પેરેન્ટ શેપર એ બીજું સામાન્ય આશ્ચર્ય છે. નિયંત્રિત કતારને વપરાયોગ્ય સેવા દર સુધી શેપ કરવું ઘણી વાર જાણી જોઈને હોય છે, કારણ કે તે કંજેશન બિંદુને તમે સંચાલિત કરો તે ઉપકરણ પર ખસેડે છે, તમે સંચાલિત ન કરો તે અપસ્ટ્રીમ કતાર પર નહીં. શેપિંગ વિલંબ ઉમેરે છે માટે શેપર દૂર કરવું નુકસાન દૂર કરવાને બદલે સ્થાનાંતરિત કરી શકે છે, અને ઓવરહેડ હિસાબ અથવા પ્રોવાઇડર પોલિસર અસરકારક દરને ઇન્ટરફેસ સૂચવે તેનાથી નીચો કરી શકે છે.

કાઉન્ટર કહે છે કયો અડધો ભાગ નિષ્ફળ ગયો

અસરગ્રસ્ત દિશામાં ચાર આંકડાની સરખામણી કરો: શું ઓફર થયું, વર્ગ શું મેચ થયો, શું કતારમાં ગયું કે છોડી દેવાયું, અને સેવાએ ખરેખર શું પહોંચાડ્યું. વર્કલોડનું વર્ણન અને નીતિની આવૃત્તિ અવલોકનની બાજુમાં રાખો, કારણ કે તેમના વિના કાઉન્ટરનો સ્ક્રીનશોટ પુનઃઉત્પાદિત કરી શકાતો નથી.

શાખાઓ જુદા જુદા માલિકોની જુદી જુદી સમસ્યાઓ છે. જે સ્થાનિક વર્ગ કંઈપણ મેચ કરતો નથી તે તમારી બાજુની વર્ગીકરણની ભૂલ છે. જે વર્ગ મેચ થાય, કતારમાં જાય અને છોડી દે જ્યારે પ્રોવાઇડર સ્વચ્છ ડિલિવરી જણાવે છે તે તમારા પોતાના શેડ્યુલર અથવા શેપર તરફ સંકેત કરે છે. જે વર્ગ સ્થાનિક રીતે સાચો દેખાય જ્યારે નુકસાન સોંપણીની પાર દેખાય છે તે કેરિયરના મેપિંગ અને કરારમાં માપેલી સીમા તરફ સંકેત કરે છે. ત્રણમાંથી કોઈ પણ બીજાને સંપાદિત કરીને સુધારી શકાતું નથી, તેથી આંકડા એકસાથે એકત્રિત કરવા પડે છે.

RFC 2475 વર્ગીકરણ અને કન્ડિશનિંગને વહીવટી ડોમેનની અંદર કરવામાં આવતા કામ તરીકે રજૂ કરે છે, અને એટલે જ માર્કિંગ શરૂઆતથી અંત સુધી કતારો અનામત રાખી શકતું નથી. IOS XE શેડ્યુલિંગ માર્ગદર્શિકા ઉપર વર્ણવેલા વધારાના વજનના વર્તનનો સંદર્ભ છે, અને મોડેલો વચ્ચે ગણતરી કરેલો દર ખસેડતા પહેલાં તેની પ્લેટફોર્મ સરખામણીઓ વાંચવા યોગ્ય છે.

કરાર એક જગ્યાએ લખો

સ્થાનિક મેચ, વિશ્વાસ સીમા, પ્રોવાઇડર વર્ગ અને માપેલી સેવા સ્તરને એક દસ્તાવેજમાં મૂકો જે બંને પક્ષો સહી કરે. પછી ટકાવારીના ફેરફારને સંદર્ભ મળે છે, અને ગુણવત્તાની ફરિયાદને માલિક મળે છે.

સ્થાનિક ટકાવારી બદલવાથી બીજી કતારની બાંયધરી સુધારી શકાતી નથી, અને પ્રોવાઇડર જે મેપિંગનું પાલન કરતું નથી તેનાથી કોઈ માર્કિંગ યોજના ટકતી નથી. બે અડધા ભાગની સરખામણી કરો, સીમાનું નામ આપો, અને પછી જ આંકડો ટાંકો.