DSCP मार्किङ वा प्रदायकको QoS वाचा? दुवैमध्ये कुनै पनि सम्झौता होइन

केही कुरा मार्क हुन्छ, एउटा लामो कन्फिगर हुन्छ, र त्यसपछि कसैले सोध्छ कि डिजाइनले वास्तवमा कस्तो गुणस्तरको ग्यारेन्टी गर्छ। इमानदार जवाफ यो हो कि तपाईंले सीमामा भेटिने सम्झौताका दुई आधा भाग वर्णन गर्नुभयो। प्रदायकले स्वीकार गर्ने वर्ग र त्यसले लागू गर्ने उपचारको नाम बताउन सक्नु अघिसम्म, स्थानीय कन्फिगरेसन एउटा मनसाय हो, वाचा होइन। दुवै आधा भाग महत्त्वपूर्ण छन् र एउटाबाट अर्को अनुमान गर्न सकिँदैन।

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

सही मार्किङ कहाँ चुपचाप मर्न सक्छ

प्रत्येक कार्यभारका लागि स्थानीय मिलान सर्त, सुरुङभित्र हुने कुनै पनि मार्किङ, प्रदायकले स्वीकार गर्ने मान र त्यो मानले छान्ने सेवा वर्ग लेखेर सुरु गर्नुहोस्। चार स्तम्भ, र असफलताहरू सामान्यतया दोस्रो र तेस्रोको बीचमा बस्छन्।

भित्रबाट बाहिर हेडरतर्फ मार्किङको व्यवहार शास्त्रीय समस्या हो। इन्क्रिप्टेड वा सुरुङ मार्गभित्रको प्याकेटले तपाईंको वर्गीकरणकर्ताले देख्न सक्ने भित्री हेडर र प्रदायकको उपकरणले देख्न सक्ने बाहिरी हेडर बोक्छ, र एउटालाई अर्कोमा प्रतिलिपि गर्नु कन्फिगरेसनको निर्णय हो, स्वचालित गुण होइन। केवल भित्री हेडर मार्क गर्नुहोस् र प्रदायकले बाहिरीको वर्गीकरण गर्छ, सामान्यतया पूर्वनिर्धारित रूपमा, त्यसैले सही रूपमा मार्क गरिएको प्रवाह तपाईंको पक्षमा एउटै गलत कन्फिगर गरिएको लाइन बिना गलत वर्गमा पुग्न सक्छ।

स्थानीय रूपमा नाम दिइएको वर्ग पनि खाली रहन सक्छ किनभने यसको मिलान सर्त वास्तविक प्याकेटमा कहिल्यै सक्रिय हुँदैन। पोर्ट सर्छन्, अनुप्रयोगहरूले धेरै प्रवाह प्रयोग गर्छन्, र विक्रेताले दुई रिलिज अघि प्रयोग गर्न छोडेको परिचित पोर्टमा मिलानले शून्य काउन्टर भएको लाम र चलिरहेको कन्फिगरेसनमा उत्तम देखिने नीति उत्पन्न गर्छ।

मार्किङमा कहाँ भरोसा गर्ने स्पष्ट रूपमा निर्णय गर्नुहोस्। सुरुङ साझा गर्ने सबैलाई माथि उठाउँदा कलसँगै ठूला स्थानान्तरण पनि माथि उठ्छन्, र प्रमाणीकरण बिना तपाईंको मार्किङ स्वीकार गर्ने प्रदायकले तपाईंलाई आफैलाई हानि गर्ने बाटो दिन्छ। यदि सम्झौताले गेटवेलाई हस्तान्तरणमा पुनः मार्क गर्न अनुमति दिन्छ भने त्यो लिखित रूपमा भन्नुहोस्, किनभने दुई टोलीका अनुमान सामान्यतया त्यहीँ बाटो छुट्टिन्छन्।

शेड्युलरले वास्तवमा के विभाजन गर्छ

स्थानीय नीतिको आफ्नै अर्थशास्त्र छ, र सबैभन्दा धेरै गलतफहमी “remaining” शब्दले ल्याउँछ। IOS XE शेड्युलिङ गाइडले वर्णन गर्ने प्लेटफर्ममा bandwidth remaining percent अतिरिक्त भार तोक्छ, प्रत्येक वर्गले अघिल्लो वर्गले छोडेकोबाट हिस्सा लिने क्रमको एउटा चरण होइन। नतोकिएका प्रतिशतहरू फाइलको अन्तिम वर्गका लागि आरक्षित गर्नुको सट्टा योग्य नकन्फिगर गरिएका लामहरूमा फैलाइन्छ।

त्यो भिन्नता महत्त्वपूर्ण छ किनभने क्रमिक मानसिक मोडेलले काउन्टरसँग कहिल्यै नमिल्ने भविष्यवाणी दिन्छ। इन्जिनियरहरू नतिजा बदल्न वर्गहरूको क्रम बदल्छन्, कुनै भिन्नता देख्दैनन् र प्लेटफर्म बिग्रिएको निष्कर्ष निकाल्छन्, जबकि कन्फिगरेसनले उनीहरूले मानेको अर्थ कहिल्यै दिएको थिएन।

अभिभावक आकारकर्ता अर्को सामान्य आश्चर्य हो। नियन्त्रित लामलाई प्रयोगयोग्य सेवा दरसम्म आकार दिनु प्रायः जानाजानी हुन्छ, किनभने यसले भीडको बिन्दु तपाईंले व्यवस्थापन गर्ने यन्त्रमा सार्छ, तपाईंले व्यवस्थापन नगर्ने माथिल्लो लाममा होइन। आकार दिनु ढिलाइ थप्छ भनेर आकारकर्ता हटाउँदा क्षति हटाउनुको सट्टा स्थानान्तरण हुन सक्छ, र ओभरहेड हिसाब वा प्रदायकको पुलिसरले प्रभावकारी दर इन्टरफेसले संकेत गरेभन्दा कम बनाउन सक्छ।

काउन्टरले कुन आधा भाग असफल भयो भन्छन्

प्रभावित दिशामा चार अंक तुलना गर्नुहोस्: के प्रस्ताव गरियो, वर्ग केसँग मिल्यो, के लाममा गयो वा छोडियो, र सेवाले वास्तवमा के पुर्‍यायो। कार्यभारको विवरण र नीतिको संस्करण अवलोकनको छेउमा राख्नुहोस्, किनभने ती बिना काउन्टरको स्क्रिनसट पुनःउत्पादन गर्न सकिँदैन।

शाखाहरू फरक मालिकका फरक समस्या हुन्। केहीसँग नमिल्ने स्थानीय वर्ग तपाईंको पक्षको वर्गीकरण बग हो। मिल्ने, लाममा जाने र छोड्ने वर्ग, प्रदायकले सफा डेलिभरी रिपोर्ट गर्दा, तपाईंको आफ्नै शेड्युलर वा आकारकर्तातर्फ संकेत गर्छ। स्थानीय रूपमा सही देखिने वर्ग, क्षति हस्तान्तरणपछि देखा पर्दा, वाहकको म्यापिङ र सम्झौतामा मापन गरिएको सीमातर्फ संकेत गर्छ। तीनमध्ये कुनै पनि अरू सम्पादन गरेर सुधारिँदैन, त्यसैले अंकहरू सँगै जम्मा गर्नुपर्छ।

RFC 2475 ले वर्गीकरण र कन्डिसनिङलाई प्रशासनिक डोमेनभित्र गरिने कामका रूपमा प्रस्तुत गर्छ, र त्यसैकारण मार्किङले लामहरू टुप्पोदेखि टुप्पोसम्म आरक्षित गर्न सक्दैन। IOS XE शेड्युलिङ गाइड माथि वर्णन गरिएको अतिरिक्त-भार व्यवहारको सन्दर्भ हो, र मोडेलहरूबीच गणना गरिएको दर सार्नु अघि यसका प्लेटफर्म तुलनाहरू पढ्न लायक छन्।

सम्झौता एकै ठाउँमा लेख्नुहोस्

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

स्थानीय प्रतिशत बदल्नाले अर्को लामको ग्यारेन्टी मर्मत गर्न सक्दैन, र प्रदायकले पालना नगर्ने म्यापिङबाट कुनै पनि मार्किङ योजना बाँच्दैन। दुवै आधा भाग तुलना गर्नुहोस्, सीमाको नाम दिनुहोस्, र त्यसपछि मात्र अंक उद्धृत गर्नुहोस्।