प्रति-टनल QoS आपके हब की कुल अपलिंक को सीमित नहीं करता

यह विश्वास अंकगणित जैसा लगता है: पाँच स्पोक, हर एक 5 Mbit/s पर ढाला गया, इसलिए हब अधिकतम 25 Mbit/s ढोता है। पहला आधा सच है और निष्कर्ष नहीं। प्रति-टनल नीति हर टनल पर एक बार लागू होती है, हर हब पर एक बार नहीं, और वह साझा अपलिंक जिससे पाँचों टनल गुज़रती हैं, उस गणना में कभी नहीं आती। अपलिंक पर भीड़ बिल्कुल वैसी ही बनी रहती है।

यह विश्वास कहाँ से आता है

भ्रम समझ में आता है, क्योंकि NHRP समूह जानकारी एक नीति परिभाषा को स्पोक के पूरे समूह पर लागू होने देती है। यह कॉन्फ़िगरेशन फ़ाइल में साझा बजट जैसा पढ़ा जाता है। वास्तव में इसका अर्थ है कि हर स्पोक को उस परिभाषा की अपनी प्रतिलिपि मिलती है।

इसलिए प्रति स्पोक 5 Mbit/s प्रति-टनल ऊपरी सीमा है, और जितनी टनल हैं उतनी ही सीमाएँ हैं।

एक नीति प्रतिलिपि क्या नियंत्रित करती है

Cisco की IOS XE पर DMVPN में प्रति-टनल QoS मार्गदर्शिका हब निकास नीति का वर्णन करती है जो NHRP समूह जानकारी से चुनी जाती है और हर स्पोक पर अलग से लागू होती है। उस वाक्य से दो सीमाएँ निकलती हैं, और दोनों अनदेखी की जाती हैं। दर एक स्पोक की है, साझा बाल्टी की नहीं, और यह सुविधा हब से स्पोक की ओर ट्रैफ़िक नियंत्रित करती है, उल्टा नहीं।

स्पोक की भेजने की दिशा की योजना स्वतंत्र रूप से बनाएँ। हब निकास नीति में कुछ भी यह सीमित नहीं करता कि शाखा क्या अपलोड करती है।

कुल सीमा साझा अवरोध पर रखें

कुल को वहाँ ढाला जाना चाहिए जहाँ वह वास्तव में प्रतिस्पर्धा करता है: उस भौतिक इंटरफ़ेस पर जिसे सभी टनल साझा करती हैं। Cisco भौतिक इंटरफ़ेस पर class-default शेपर को इस सुविधा के लिए समर्थित समवर्ती भौतिक नीति के रूप में दर्ज करता है, जो आप जो भी पदानुक्रम लिख सकते हैं उससे अधिक संकीर्ण कथन है। मान लें कि आपने जो मनमानी दूसरी भौतिक नीति बनाई है वह तब तक समर्थित नहीं है जब तक कोई उल्टा सिद्ध न करे।

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

शेपिंग इकाइयों और ओवरहेड लेखांकन को वास्तविक हैंडऑफ़ से मिलाएँ। जिस एनकैप्सुलेशन ओवरहेड को आप दर की गणना से बाहर छोड़ते हैं वह ऐसी लिंक के रूप में दिखता है जो कॉन्फ़िगर किए गए आंकड़े से पहले संतृप्त हो जाती है।

काउंटर एक विशेष तरीके से झूठ बोलते हैं

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

पुराने traffic-shape उदाहरण को किसी असंबंधित नीति मैप के बगल में कॉपी करना यह सिद्ध नहीं करता कि दोनों दरें एक ही पैकेट नियंत्रित करती हैं।

कुल का परीक्षण करें, केवल सीमा का नहीं

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

उस समय समाधान क्षमता या प्रवेश का निर्णय है। प्रति-स्पोक आंकड़ों को फिर से समायोजित करना केवल यह बदलता है कि कौन-सी शाखा पहले शिकायत करती है।