प्रति-टनेल QoS ले तपाईंको हबको कुल अपलिङ्क सीमित गर्दैन

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

यो विश्वास कहाँबाट आउँछ

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

त्यसैले प्रति स्पोक 5 Mbit/s प्रति-टनेल उच्च सीमा हो, र टनेल जति छन् त्यति सीमा छन्।

एउटा नीति प्रतिलेप के नियन्त्रण गर्छ

Cisco को IOS XE मा DMVPN मा प्रति-टनेल QoS मार्गदर्शिका ले NHRP समूह जानकारीद्वारा छानिएको र प्रत्येक स्पोकमा छुट्टै लागू हुने हब निर्गमन नीति वर्णन गर्छ। त्यो वाक्यबाट दुई सीमा आउँछन्, र दुवैलाई बेवास्ता गरिन्छ। दर एउटा स्पोकको हो, साझा बाल्टिनको होइन, र यो सुविधाले हबबाट स्पोकतिर ट्राफिक नियन्त्रण गर्छ, उल्टो होइन।

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

कुल सीमा साझा अवरोधमा राख्नुहोस्

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

त्यसपछि सबै स्पोक एकैसाथ व्यस्त हुँदा के हुन्छ भनी निर्णय गर्नुहोस्। कुन ट्राफिक स्वीकार गरिन्छ, कुन वर्गले प्राथमिकता पाउँछ, र कुन कतारसँग प्रतिस्पर्धा छ। प्रति-स्पोक सीमाले यी कुनै पनि प्रश्नको उत्तर दिँदैन, किनकि प्रत्येक स्पोक अलगै हेरिन्छ।

आकार दिने एकाइ र ओभरहेड लेखांकनलाई वास्तविक हस्तान्तरणसँग मिलाउनुहोस्। दरको गणनाबाट बाहिर राख्नुभएको इन्क्याप्सुलेसन ओभरहेड कन्फिगर गरिएको संख्याअघि नै भरिने लिङ्कको रूपमा देखिन्छ।

काउन्टरहरू एक विशेष तरिकाले झुटो बोल्छन्

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

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

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

एउटा व्यस्त स्पोकबाट सुरु गर्नुहोस् र त्यो आफ्नो सीमासम्म पुग्छ भनी पुष्टि गर्नुहोस्। त्यसपछि स्वीकृत योजनाअनुसार सबैबाट एकैसाथ ट्राफिक दिनुहोस्, र प्रति-टनेल संख्याको छेउमा भौतिक इन्टरफेस हेर्नुहोस्। यदि प्रत्येक स्पोक आफ्नो सीमामा बसिरहेको छ र अपलिङ्क जाम छ तथा ढिलाइ बढिरहेको छ भने, प्रति-स्पोक नीति डिजाइन गरिएअनुसारै काम गरिरहेको छ र बजेट अझै गलत छ।

त्यो बिन्दुमा समाधान क्षमता वा प्रवेशको निर्णय हो। प्रति-स्पोक संख्या पुनः समायोजन गर्नुले कुन शाखा पहिले गुनासो गर्छ त्यो मात्र बदल्छ।