अपने VPN पोर्ट को चिह्नित करना वॉइस कॉल को प्राथमिकता नहीं देता
VPN पोर्ट को प्राथमिकता के रूप में चिह्नित करना कॉल और बैकअप को एक ही टनल में आगे बढ़ाता है। वॉइस को एन्क्रिप्शन से पहले वर्गीकरण और आपके नियंत्रण वाली कतार चाहिए।
VPN के UDP पोर्ट को उच्च प्राथमिकता के रूप में चिह्नित करना वॉइस QoS का सबसे आम बदलाव है, और यह कॉल को उसी टनल को साझा करने वाले फ़ाइल स्थानांतरण से अलग नहीं करता। दोनों प्रवाह उसी एन्क्रिप्टेड सॉकेट से बाहर जाते हैं। निशान अगले हॉप को बताता है कि सब कुछ समान रूप से मायने रखता है, जो कुछ न कहने के बराबर है। कॉल की रक्षा भरोसेमंद वर्गीकरण एन्क्रिप्शन से पहले और एक कतार जिसे आप वास्तव में नियंत्रित करते हैं, करती है।
टनल उस प्रवाह को छिपाती है जिसे आप वर्गीकृत करना चाहते थे
एन्क्रिप्शन अंदरूनी हेडर को प्रति टनल एक बाहरी हेडर से बदल देता है। उसके बाद, वॉइस और बैकअप ट्रैफ़िक एक ही स्रोत, गंतव्य और परिवहन पोर्ट दिखाते हैं, इसलिए टनल पोर्ट पर आधारित वर्गीकरणकर्ता उन्हें अलग नहीं कर सकता। आप जिसे भी आगे बढ़ाएँ, उसे पूरा एक साथ आगे बढ़ाएँ।
मूल एप्लिकेशन द्वारा सेट किया गया DSCP मान केवल तभी बचता है जब कोई उसे बाहर कॉपी करे। OpenVPN 2.6 में passtos है, जो IPv4 विस्तार के साथ प्रलेखित है; IPsec टनल सीमा पर अपनी कॉपी या मैपिंग नीति लागू करता है। उस कदम के बिना बाहरी पैकेट टनल इंटरफ़ेस के किसी भी डिफ़ॉल्ट से चिह्नित हो जाता है, और नीचे की कतार को कभी पता नहीं चलता कि अंदर कॉल है।
कॉपी किए गए निशान क्लाइंट द्वारा दिए गए किसी भी मान जितने ही संदेह के योग्य हैं। एक वर्कस्टेशन बैकअप कार्य के लिए त्वरित अग्रेषण का दावा कर सकता है, इसलिए भरोसा सीमा पर स्वीकृति और पुनः-चिह्नन निशान पर विश्वास करने से पहले डिज़ाइन में होना चाहिए।
प्राथमिकता केवल वहीं गिनी जाती है जहाँ कतार बनती है
संतृप्त अपलिंक ही अच्छे कोडेक को रोबोटिक आवाज़ में बदलता है, और भरने वाली कतार आमतौर पर एक्सेस डिवाइस या प्रदाता के बफ़र में होती है। आउटबाउंड पथ को उपयोगी दर तक, टनल और लिंक ओवरहेड घटाकर, ढालना ही उस कतार को आपके प्रशासित हार्डवेयर पर रखता है, किसी और के बफ़र में नहीं।
न्यायपूर्ण कतारबद्धता और सक्रिय कतार प्रबंधन वॉइस वर्ग के बिना भी मदद करते हैं, क्योंकि वे एक बड़े प्रवाह को बफ़र भरने से रोकते हैं। Linux पर CAKE ढालना, प्रति-प्रवाह न्याय और वैकल्पिक Diffserv वर्गों को एक ही qdisc में जोड़ता है, और तैनात नेटवर्क प्रबंधक के पास वही कॉन्फ़िगरेशन होना चाहिए, दूसरी प्रतिस्पर्धी कतार व्यवस्था नहीं। ढालना के बिना, बड़े ट्रैफ़िक से ऊपर का वर्ग भी पहले से भरे बफ़र के पीछे प्रतीक्षा करता है।
इनग्रेस हैंडलिंग बेकार नहीं है, लेकिन यह पैकेट के प्राप्ति लिंक पार करने के बाद काम करती है। यह प्रतिक्रियाशील प्रेषक को प्रभावित कर सकती है और अपस्ट्रीम में पहले से खर्च हुई देरी वापस नहीं ला सकती, इसलिए यह शमन है, गारंटी नहीं।
| Stage | What you can control | What to verify |
|---|---|---|
| Application to client | Which flows are trusted for marking | The marked packets are the ones you intended |
| Tunnel boundary | Whether the inner mark is copied outward | Outer header carries the expected value |
| Your uplink | Shaping rate and class treatment | Queue counters move for the voice class |
| Provider path | Almost nothing | Whether the service enforces the marking at all |
| Receiving side | Local policy after arrival | Delay that is already in the past |
सार्वजनिक इंटरनेट में क्या टिकता है
Diffserv आर्किटेक्चर प्रशासनिक डोमेन के भीतर व्यवहार का वर्णन करता है, इसलिए प्रदाता सीमा पर निशान को अनदेखा या फिर से लिख सकता है। विपरीत दावा, कि हर नेटवर्क इसे हमेशा हटा देता है, उतना ही आधारहीन है। ईमानदार सवाल यह है कि यह विशिष्ट पथ संविदा और पुलिसिंग के तहत क्या करने को बाध्य है। कहीं पढ़े गए नियम को दोहराने के बजाय चिह्नित प्रोब से इसकी जाँच करें।
पूछें कि प्रदाता वर्ग के साथ क्या करता है, फिर उसे मापें। जो निशान सुरक्षित रहता है पर निर्धारित नहीं होता, वह सजावट है; जो पथ निशान देखे बिना निर्धारण करता है, वह अलग समस्या है, और दोनों को अलग सुधार चाहिए।
चरण को अलग करने वाली माप योजना
नियंत्रित प्रतिस्पर्धी अपलोड के साथ एक सामान्य कॉल करें, फिर उसे तारयुक्त लिंक पर दोहराएँ। देखें कि कॉल ने क्या खोया, वर्ग काउंटरों ने क्या दर्ज किया और इंटरफ़ेस योजना की घोषित गति के बजाय अपनी वास्तविक सीमा के कितने करीब चलता है।
tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.netयदि वॉइस वर्ग का काउंटर शून्य पर ही रहे, तो वर्गीकरण या निशान कॉपी करना टूटा हुआ है और कोई भी प्राथमिकता मदद नहीं करेगी। यदि देरी बढ़ती रहने के साथ वर्ग काउंटर स्थानीय रूप से हिलता है, तो अवरोध आपके गेटवे से परे है। दोनों में से कोई भी परिणाम प्राथमिकता मान बढ़ाकर ठीक नहीं होता।