प्रति-टनेल QoS तुमच्या हबच्या एकूण अपलिंकला मर्यादित करत नाही
प्रत्येकी 5 Mbit असलेले पाच स्पोक 10 Mbit अपलिंक नाहीत, आणि प्रति-टनेल धोरणाने तो फरक कधीच पाहिला नाही. सामायिक अडथळ्याचे बजेट वेगळे करा.
हा विश्वास अंकगणितासारखा वाटतो: पाच स्पोक, प्रत्येक 5 Mbit/s वर आकारलेला, म्हणून हब जास्तीत जास्त 25 Mbit/s वाहून नेतो। पहिला अर्धा खरा आहे आणि निष्कर्ष नाही। प्रति-टनेल धोरण प्रत्येक टनेलसाठी एकदा लागू होते, प्रत्येक हबसाठी एकदा नाही, आणि पाचही टनेल ज्या सामायिक अपलिंकमधून जातात ती त्या गणनेत कधीच येत नाही। अपलिंकवरील गर्दी अगदी तशीच राहते।
हा विश्वास कुठून येतो
गोंधळ समजण्यासारखा आहे, कारण NHRP गट माहिती एका धोरण व्याख्येला स्पोकच्या संपूर्ण संचावर लागू होऊ देतात। ते कॉन्फिगरेशन फाइलमधील सामायिक बजेटसारखे वाचले जाते। प्रत्यक्षात त्याचा अर्थ प्रत्येक स्पोकला त्या व्याख्येची स्वतःची प्रत मिळते।
म्हणून प्रति स्पोक 5 Mbit/s ही प्रति-टनेल उच्च मर्यादा आहे, आणि टनेल जितक्या तितक्या मर्यादा आहेत।
एक धोरण प्रत काय नियंत्रित करते
Cisco चे IOS XE वरील DMVPN मधील प्रति-टनेल QoS मार्गदर्शक NHRP गट माहितीद्वारे निवडले आणि प्रत्येक स्पोकवर स्वतंत्रपणे लागू केले जाणारे हब निर्गमन धोरण वर्णन करते। त्या वाक्यातून दोन मर्यादा येतात आणि दोन्हीकडे दुर्लक्ष केले जाते। दर एका स्पोकचा आहे, सामायिक बादलीचा नाही, आणि हे वैशिष्ट्य हबकडून स्पोककडे जाणारा रहदारी नियंत्रित करते, उलट नाही।
स्पोकची पाठवण्याची दिशा स्वतंत्रपणे नियोजित करा। हब निर्गमन धोरणात शाखा काय अपलोड करते हे मर्यादित करणारे काहीही नाही।
एकूण मर्यादा सामायिक अडथळ्यावर ठेवा
एकूण रक्कम ती खरोखर स्पर्धा करते तिथे आकारली जाणे आवश्यक आहे: त्या भौतिक इंटरफेसवर जी सर्व टनेल सामायिक करतात। Cisco भौतिक इंटरफेसवरील class-default शेपरला या वैशिष्ट्यासाठी समर्थित एकाचवेळी भौतिक धोरण म्हणून नोंदवते, हे तुम्ही लिहू शकता अशा कोणत्याही श्रेणीपेक्षा अरुंद विधान आहे। तुम्ही तयार केलेले कोणतेही अनियंत्रित दुसरे भौतिक धोरण कोणी उलटे सिद्ध करेपर्यंत समर्थित नाही असे गृहीत धरा।
मग सर्व स्पोक एकाच वेळी व्यस्त असताना काय होते ते ठरवा। कोणता रहदारी स्वीकारला जातो, कोणत्या वर्गाला प्राधान्य मिळते, आणि कोणती रांग स्पर्धा धारण करते। प्रति-स्पोक मर्यादा यापैकी कोणत्याही प्रश्नाचे उत्तर देत नाही, कारण प्रत्येक स्पोक स्वतंत्रपणे विचारात घेतला जातो।
आकारणीची एकके आणि ओव्हरहेड हिशोब प्रत्यक्ष हस्तांतरणाशी जुळवा। दराच्या गणनेतून तुम्ही बाहेर ठेवलेला एनकॅप्स्युलेशन ओव्हरहेड कॉन्फिगर केलेल्या संख्येपूर्वी भरून जाणारी लिंक म्हणून दिसतो।
काउंटर एका विशिष्ट पद्धतीने खोटे बोलतात
तुम्ही आकारत असलेल्या स्तरावर काउंटर वाचा। तोच Cisco मार्गदर्शक सूचित करतो की या रचनेत मुख्य इंटरफेस धोरण काउंटर अचूक नसू शकतात। तो काउंटरबद्दलचा इशारा आहे, वर्ग जुळतो किंवा टाकून देतो याचा पुरावा नाही। तो अनुप्रयोग निकालापासून वेगळा ठेवा, जो वापरकर्त्याला जाणवणारी एकमेव गोष्ट आहे।
जुने traffic-shape उदाहरण असंबंधित धोरण नकाशाच्या शेजारी कॉपी करणे हे सिद्ध करत नाही की दोन्ही दर एकाच पॅकेटवर नियंत्रण ठेवतात।
एकूण रकमेची चाचणी करा, केवळ मर्यादेची नाही
एका व्यस्त स्पोकपासून सुरुवात करा आणि तो त्याच्या मर्यादेपर्यंत पोहोचतो याची खात्री करा। नंतर मंजूर योजनेअंतर्गत सर्वांकडून एकाच वेळी रहदारी द्या, आणि प्रति-टनेल संख्यांच्या शेजारी भौतिक इंटरफेस पहा। जर प्रत्येक स्पोक त्याच्या मर्यादेवर बसला असेल आणि अपलिंक तुंबलेली असेल व विलंब वाढत असेल, तर प्रति-स्पोक धोरण नक्की डिझाइन केल्याप्रमाणे काम करत आहे आणि बजेट अजूनही चुकीचे आहे।
त्या टप्प्यावरील उपाय क्षमता किंवा प्रवेशाचा निर्णय आहे। प्रति-स्पोक संख्या पुन्हा जुळवणे फक्त कोणती शाखा आधी तक्रार करते ते बदलते।