DSCP मार्किंग या प्रदाता का QoS वादा? इनमें से कोई अनुबंध नहीं है

कुछ मार्क होता है, एक कतार कॉन्फ़िगर होती है, और फिर कोई पूछता है कि डिज़ाइन वास्तव में कौन-सी गुणवत्ता की गारंटी देता है। ईमानदार जवाब यह है कि आपने एक अनुबंध के दो अर्धांश लिखे हैं जो एक सीमा पर मिलते हैं। जब तक आप उस वर्ग का नाम नहीं बता सकते जिसे प्रदाता स्वीकार करता है और वह व्यवहार जो वह लागू करता है, स्थानीय कॉन्फ़िगरेशन एक मंशा है, वादा नहीं। दोनों अर्धांश मायने रखते हैं, और एक से दूसरे का अनुमान नहीं लगाया जा सकता।

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

एक सही मार्किंग कहाँ चुपचाप मर सकती है

हर वर्कलोड के लिए स्थानीय मिलान शर्त, सुरंग के भीतर होने वाली कोई भी मार्किंग, वह मान जिसे प्रदाता स्वीकार करता है और वह सेवा वर्ग जिसे वह मान चुनता है, लिखकर शुरू करें। चार स्तंभ, और विफलताएँ आमतौर पर दूसरे और तीसरे के बीच रहती हैं।

अंदर से बाहर मार्किंग का व्यवहार क्लासिक समस्या है। एन्क्रिप्टेड या सुरंग वाले पथ में एक पैकेट अंदर का हेडर ले जाता है जिसे आपका वर्गीकरणकर्ता देख सकता है और बाहर का हेडर जिसे प्रदाता का उपकरण देख सकता है, और एक को दूसरे में कॉपी करना कॉन्फ़िगरेशन का निर्णय है, स्वचालित गुण नहीं। केवल अंदर का हेडर मार्क करें और प्रदाता बाहर वाले को वर्गीकृत करता है, आमतौर पर डिफ़ॉल्ट के रूप में, इसलिए सही ढंग से मार्क किया गया प्रवाह आपकी ओर से एक भी गलत कॉन्फ़िगर की गई पंक्ति के बिना गलत वर्ग में पहुँच सकता है।

स्थानीय रूप से नामित वर्ग भी खाली रह सकता है क्योंकि उसकी मिलान शर्त वास्तविक पैकेटों पर कभी सक्रिय नहीं होती। पोर्ट बदलते हैं, एप्लिकेशन कई प्रवाह इस्तेमाल करते हैं, और किसी जाने-पहचाने पोर्ट पर मिलान जिसे विक्रेता ने दो रिलीज़ पहले उपयोग करना बंद कर दिया था, शून्य काउंटर वाली कतार और चल रहे कॉन्फ़िगरेशन में बिल्कुल सही दिखने वाली नीति बनाता है।

स्पष्ट रूप से तय करें कि मार्किंग पर कहाँ भरोसा किया जाता है। सुरंग साझा करने वाली हर चीज़ को बढ़ावा देना कॉल के साथ-साथ बल्क ट्रांसफ़र को भी बढ़ावा देता है, और जो प्रदाता सत्यापन के बिना आपकी मार्किंग स्वीकार करता है वह आपको खुद को नुकसान पहुँचाने का रास्ता देता है। अगर अनुबंध गेटवे को हैंडऑफ़ पर फिर से मार्क करने की अनुमति देता है, तो इसे लिखित में कहें, क्योंकि दो टीमों की धारणाएँ आमतौर पर ठीक उसी बिंदु पर अलग होती हैं।

शेड्यूलर वास्तव में क्या बाँटता है

स्थानीय नीति की अपनी अर्थ-व्यवस्था है, और सबसे ज़्यादा गलतफ़हमी “remaining” शब्द पैदा करता है। IOS XE शेड्यूलिंग गाइड में वर्णित प्लेटफ़ॉर्म पर, bandwidth remaining percent एक अतिरिक्त भार तय करता है, ऐसे क्रम का चरण नहीं जहाँ हर वर्ग पिछले वर्ग द्वारा छोड़े गए हिस्से से भाग लेता है। आवंटित न किए गए प्रतिशत फ़ाइल के अंतिम वर्ग के लिए आरक्षित होने के बजाय पात्र गैर-कॉन्फ़िगर कतारों में फैलाए जाते हैं।

यह अंतर मायने रखता है क्योंकि क्रमिक मानसिक मॉडल ऐसी भविष्यवाणियाँ देता है जो काउंटरों से कभी मेल नहीं खातीं। इंजीनियर परिणाम बदलने के लिए वर्गों का क्रम बदलते हैं, कोई अंतर नहीं देखते और निष्कर्ष निकालते हैं कि प्लेटफ़ॉर्म खराब है, जबकि कॉन्फ़िगरेशन का मतलब कभी वह नहीं था जो उन्होंने मान लिया।

पैरेंट शेपर दूसरा आम आश्चर्य है। नियंत्रित कतार को उपयोगी सेवा दर तक शेप करना अक्सर जानबूझकर होता है, क्योंकि यह भीड़ के बिंदु को उस डिवाइस पर ले जाता है जिसे आप प्रशासित करते हैं, न कि ऊपर की उस कतार पर जिसे आप प्रशासित नहीं करते। शेपिंग देरी जोड़ती है इसलिए शेपर हटाना नुकसान को हटाने के बजाय स्थानांतरित कर सकता है, और ओवरहेड लेखांकन या प्रदाता का पुलिसर प्रभावी दर को इंटरफ़ेस के संकेत से कम कर सकते हैं।

काउंटर बताते हैं कौन-सा आधा विफल हुआ

प्रभावित दिशा में चार संख्याओं की तुलना करें: क्या पेश किया गया, वर्ग किससे मिला, क्या कतार में गया या गिराया गया, और सेवा ने वास्तव में क्या दिया। वर्कलोड का विवरण और नीति का संस्करण अवलोकन के पास रखें, क्योंकि उनके बिना काउंटरों का स्क्रीनशॉट दोहराया नहीं जा सकता।

शाखाएँ अलग-अलग मालिकों की अलग-अलग समस्याएँ हैं। जो स्थानीय वर्ग किसी से मेल नहीं खाता वह आपकी ओर की वर्गीकरण बग है। जो वर्ग मेल खाता है, कतार में जाता है और गिराता है जबकि प्रदाता स्वच्छ डिलीवरी बताता है, वह आपके अपने शेड्यूलर या शेपर की ओर इशारा करता है। जो वर्ग स्थानीय रूप से सही दिखता है जबकि नुकसान हैंडऑफ़ के पार दिखता है, वह कैरियर के मैपिंग और अनुबंध में मापी गई सीमा की ओर इशारा करता है। तीनों में से कोई भी दूसरों को संपादित करके ठीक नहीं होता, इसलिए संख्याएँ एक साथ जुटाई जानी चाहिए।

RFC 2475 वर्गीकरण और कंडीशनिंग को प्रशासनिक डोमेन के भीतर किए गए काम के रूप में देखता है, और ठीक इसीलिए मार्किंग कतारों को शुरू से अंत तक आरक्षित नहीं कर सकती। IOS XE शेड्यूलिंग गाइड ऊपर वर्णित अतिरिक्त-भार व्यवहार का संदर्भ है, और मॉडलों के बीच गणना की गई दर ले जाने से पहले इसकी प्लेटफ़ॉर्म तुलनाएँ पढ़ने योग्य हैं।

अनुबंध एक ही जगह लिखें

स्थानीय मिलान, भरोसे की सीमा, प्रदाता वर्ग और मापा गया सेवा स्तर एक ही दस्तावेज़ में रखें जिस पर दोनों पक्ष हस्ताक्षर करें। तब प्रतिशत परिवर्तन का संदर्भ होता है, और गुणवत्ता शिकायत का मालिक होता है।

स्थानीय प्रतिशत बदलना किसी दूसरी कतार की गारंटी ठीक नहीं कर सकता, और कोई भी मार्किंग योजना ऐसी मैपिंग से नहीं बचती जिसे प्रदाता मानता न हो। दोनों अर्धांशों की तुलना करें, सीमा का नाम लें, और तभी कोई संख्या बताएँ।