DSCP मार्किंग की प्रदात्याचे QoS वचन? यापैकी काहीही करार नाही

काहीतरी मार्क होते, रांग कॉन्फिगर होते आणि मग कोणी विचारते की रचना प्रत्यक्षात कोणती गुणवत्ता हमी देते. प्रामाणिक उत्तर असे आहे की तुम्ही सीमेवर भेटणाऱ्या कराराचे दोन अर्धे भाग वर्णन केले आहेत. प्रदाता जो वर्ग स्वीकारतो आणि जी हाताळणी लागू करतो ती तुम्ही नावाने सांगू शकत नाही तोपर्यंत स्थानिक कॉन्फिगरेशन हेतू आहे, वचन नाही. दोन्ही अर्धे भाग महत्त्वाचे आहेत आणि एकातून दुसरा काढता येत नाही.

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

योग्य मार्किंग कुठे शांतपणे मरू शकते

प्रत्येक कार्यभारासाठी स्थानिक जुळणी अट, बोगद्यात होणारे कोणतेही मार्किंग, प्रदाता स्वीकारतो ते मूल्य आणि ते मूल्य निवडते तो सेवा वर्ग लिहून सुरुवात करा. चार स्तंभ, आणि अपयश सहसा दुसऱ्या आणि तिसऱ्याच्या मध्ये राहतात.

आतून बाहेरच्या शीर्षलेखाकडे मार्किंगचे वर्तन ही पारंपरिक समस्या आहे. एन्क्रिप्टेड किंवा बोगद्याच्या मार्गातील पॅकेटमध्ये तुमचा वर्गीकरणकर्ता पाहू शकतो असा आतील शीर्षलेख आणि प्रदात्याची उपकरणे पाहू शकतात असा बाहेरील शीर्षलेख असतो, आणि एकाची दुसऱ्यात प्रत करणे हा कॉन्फिगरेशनचा निर्णय आहे, स्वयंचलित गुणधर्म नाही. फक्त आतील शीर्षलेख मार्क करा आणि प्रदाता बाहेरीलचे वर्गीकरण करतो, सहसा डीफॉल्ट म्हणून, म्हणूनच योग्यरीत्या मार्क केलेला प्रवाह तुमच्या बाजूने एकही चुकीची कॉन्फिगर केलेली ओळ नसताना चुकीच्या वर्गात पोहोचू शकतो.

स्थानिकपणे नाव दिलेला वर्गही रिकामा राहू शकतो कारण त्याची जुळणी अट खऱ्या पॅकेटवर कधीही सक्रिय होत नाही. पोर्ट हलतात, अनुप्रयोग अनेक प्रवाह वापरतात, आणि विक्रेत्याने दोन आवृत्त्यांपूर्वी वापरणे थांबवलेल्या सुप्रसिद्ध पोर्टवरील जुळणी शून्य काउंटरची रांग आणि चालू कॉन्फिगरेशनमध्ये परिपूर्ण दिसणारे धोरण तयार करते.

मार्किंगवर कुठे विश्वास ठेवायचा हे स्पष्टपणे ठरवा. बोगदा सामायिक करणाऱ्या सर्व गोष्टी वर करणे कॉलसोबत मोठ्या हस्तांतरणांनाही वर करते, आणि पडताळणीशिवाय तुमचे मार्किंग स्वीकारणारा प्रदाता तुम्हाला स्वतःला इजा करण्याचा मार्ग देतो. करार गेटवेला सुपूर्दीच्या वेळी पुन्हा मार्क करण्याची परवानगी देत असेल तर ते लिखित सांगा, कारण दोन संघांच्या गृहीतकांचा फरक सहसा तिथेच पडतो.

शेड्युलर प्रत्यक्षात काय विभागतो

स्थानिक धोरणाची स्वतःची अर्थशास्त्र पद्धत आहे, आणि सर्वाधिक गैरसमज “remaining” या शब्दामुळे होतो. IOS XE शेड्युलिंग मार्गदर्शक वर्णन करतो त्या प्लॅटफॉर्मवर bandwidth remaining percent अतिरिक्त वजन ठरवते, प्रत्येक वर्ग मागील वर्गाने सोडलेल्यातून वाटा घेतो अशा क्रमातील एक पायरी नाही. न वाटलेले टक्के फाइलमधील शेवटच्या वर्गासाठी राखीव ठेवण्याऐवजी पात्र न कॉन्फिगर केलेल्या रांगांमध्ये पसरवले जातात.

हा फरक महत्त्वाचा आहे कारण क्रमिक मानसिक नमुना काउंटरशी कधीही जुळणारे अंदाज देत नाही. अभियंते निकाल बदलण्यासाठी वर्गांचा क्रम बदलतात, फरक दिसत नाही आणि प्लॅटफॉर्म बिघडले आहे असा निष्कर्ष काढतात, पण कॉन्फिगरेशनने त्यांनी गृहीत धरलेला अर्थ कधीच दिला नव्हता.

पालक आकारदाता हे दुसरे नेहमीचे आश्चर्य आहे. नियंत्रित रांगेला वापरण्यायोग्य सेवा दरापर्यंत आकार देणे बहुतेक वेळा जाणीवपूर्वक असते, कारण ते गर्दीचा बिंदू तुम्ही व्यवस्थापित करता त्या उपकरणाकडे हलवते, तुम्ही व्यवस्थापित करत नाही अशा वरच्या रांगेकडे नाही. आकार देणे विलंब वाढवते म्हणून आकारदाता काढून टाकल्यास तोटा काढून टाकण्याऐवजी स्थानांतरित होऊ शकतो, आणि ओव्हरहेड हिशोब किंवा प्रदात्याचा पोलिसर प्रभावी दर इंटरफेस सुचवतो त्यापेक्षा कमी करू शकतात.

काउंटर सांगतात कोणता अर्धा भाग अपयशी ठरला

प्रभावित दिशेने चार आकडे तुलना करा: काय देऊ केले, वर्ग कशाशी जुळला, काय रांगेत गेले किंवा टाकून दिले गेले, आणि सेवेने प्रत्यक्षात काय पोहोचवले. कार्यभाराचे वर्णन आणि धोरणाची आवृत्ती निरीक्षणाजवळ ठेवा, कारण त्यांशिवाय काउंटरचा स्क्रीनशॉट पुन्हा तयार करता येत नाही.

शाखा वेगवेगळ्या मालकांच्या वेगवेगळ्या समस्या आहेत. कशाशीही न जुळणारा स्थानिक वर्ग ही तुमच्या बाजूची वर्गीकरण चूक आहे. जुळणारा, रांगेत जाणारा आणि टाकून देणारा वर्ग, प्रदाता स्वच्छ वितरण सांगत असताना, तुमच्या स्वतःच्या शेड्युलरकडे किंवा आकारदात्याकडे निर्देश करतो. स्थानिकपणे बरोबर दिसणारा वर्ग, तोटा सुपूर्दीच्या पलीकडे दिसत असताना, कॅरियरच्या मॅपिंगकडे आणि करारातील मोजलेल्या सीमेकडे निर्देश करतो. तीनांपैकी कोणतेही इतर संपादित करून सुधारत नाही, म्हणून आकडे एकत्र गोळा करावे लागतात.

RFC 2475 वर्गीकरण आणि कंडिशनिंगला प्रशासकीय डोमेनमध्ये केलेले काम म्हणून मांडते, आणि म्हणूनच मार्किंग रांगा टोकापासून टोकापर्यंत राखीव ठेवू शकत नाही. IOS XE शेड्युलिंग मार्गदर्शक वर वर्णन केलेल्या अतिरिक्त-वजन वर्तनाचा संदर्भ आहे, आणि मॉडेल्समध्ये गणना केलेला दर हलवण्यापूर्वी त्याच्या प्लॅटफॉर्म तुलना वाचण्यासारख्या आहेत.

करार एकाच ठिकाणी लिहा

स्थानिक जुळणी, विश्वासाची सीमा, प्रदात्याचा वर्ग आणि मोजलेली सेवा पातळी दोन्ही पक्ष सही करतील अशा एका दस्तऐवजात ठेवा. मग टक्केवारीतील बदलाला संदर्भ असतो, आणि गुणवत्तेच्या तक्रारीला मालक असतो.

स्थानिक टक्केवारी बदलल्याने दुसऱ्या रांगेची हमी दुरुस्त होऊ शकत नाही, आणि प्रदाता ज्याचे पालन करत नाही अशा मॅपिंगमधून कोणतीही मार्किंग योजना टिकत नाही. दोन्ही अर्धे भाग तुलना करा, सीमेला नाव द्या आणि मगच आकडा उद्धृत करा.