सॉकेट साइट पैकेट नुकसान का समस्या निवारण

समस्या

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

संभव कारण

यात्रा के दौरान पैकेट गिराने के कई कारण हो सकते हैं। कुछ सामान्य कारण हैं:

• आईएसपी साथियों के मुद्दे
• लिंक भीड़
• गलत कॉन्फ़िगरेशन (बैंडविड्थ सेटिंग्स या नेटवर्क कार्ड की गति और डुप्लेक्स)
• हार्डवेयर विफलता
• नेटवर्क उपकरण पर उच्च CPU
• माइक्रो-बर्स्ट हैंडलिंग

Cato में पैकेट नुकसान को समझना

Cato में पैकेट नुकसान की पहचान करने का एक अच्छा तरीका है एनालिटिक्स स्क्रीन का उपयोग करना Cato प्रबंधन एप्लिकेशन में। पैकेट नुकसान और त्याग दिया गया ग्राफ़ समय के साथ पैकेट नुकसान को दिखाते हैं और आपको विशिष्ट समय-सीमाओं पर ध्यान केंद्रित करने देते हैं। ये ग्राफ़ पहचानने में उपयोगी हैं कि पैकेट नुकसान हो रहा है या नहीं और यह अतीत में कब हुआ। इसके अलावा, आप पैकेट नुकसान के प्रकार की पहचान कर सकते हैं: प्रदाता नुकसान या Cato त्याग दिया गया।

नोट: एनालिटिक्स ग्राफ़ में सबसे छोटा डेटा बकेट नमूना का आकार 5 सेकेंड है। परिणामस्वरूप, 5ms के भीतर एक माइक्रो-बर्स्ट को प्रदर्शित औसत के भीतर मानकीकरण किया जाएगा और एनालिटिक्स ग्राफ़ में एक पीक के रूप में नहीं दिखाया जाएगा।

1. प्रदाता नुकसान

यह Socket और PoP के बीच पैकेट नुकसान का एक उदाहरण है। हालांकि अधिकांश प्रदाता पैकेट नुकसान Cato के नियंत्रण के बाहर अंतिम मील पर नेटवर्क कनेक्टिविटी मुद्दों के कारण है, यह जरूरी नहीं कि Cato से संबंधित समस्या को बाहर कर दे।

Cato कैसे प्रदाता नुकसान को मापता है 

प्रदाता नुकसान को Socket और PoP दोनों पर एक दिए गए लिंक पर कितने पैकेट भेजे गए हैं और कितने पैकेट प्राप्त किए गए हैं, की गणना करके मापा जाता है।

• डाउनस्ट्रीम पैकेट नुकसान PoP द्वारा भेजे गए पैकेटों की संख्या और Socket द्वारा प्राप्त पैकेटों की संख्या के बीच का अंतर है, जिसे प्रतिशत के रूप में व्यक्त किया गया है।

सूत्र:

• अपस्ट्रीम पैकेट नुकसान Socket द्वारा भेजे गए पैकेटों की संख्या और PoP द्वारा प्राप्त पैकेटों की संख्या के बीच का अंतर है, जिसे प्रतिशत के रूप में व्यक्त किया गया है।

सूत्र:

जिस तरह से Cato प्रदाता पैकेट नुकसान की गणना करता है, इसका मतलब है कि जैसे भी सरल हो, आप तुरंत ISP पर पूरी जिम्मेदारी नहीं डाल सकते। संभव है कि आपके पास Socket और ISP राउटर के बीच उपकरण हो जो पैकेट नुकसान का योगदान देता हो, या हो सकता है कि PoP के करीब नेटवर्क मार्ग में समस्याएँ हों जिन पर ISP का नियंत्रण नहीं है।

2. Cato त्याग दिया गया

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

केटो पैकेट नुकसान से संबंधित किसी भी समस्याओं की संभावना गलत कॉन्फ़िगरेशन के कारण होती है। महत्वपूर्ण एप्लिकेशन्स, जैसे VoIP, को उच्चतम बैंडविड्थ प्रबंधन प्राथमिकता दी जानी चाहिए। अगर भीड़ होती है, तो केटो द्वारा निम्न प्राथमिकता का ट्रैफ़िक ड्रॉप किया जाता है, लेकिन उच्च प्राथमिकता का ट्रैफ़िक नहीं। हमेशा सुनिश्चित करें कि ट्रैफ़िक को उचित बैंडविड्थ प्रबंधन प्राथमिकताएँ सौंपा गया है।

विश्लेषिकी पैकेट नुकसान का व्यापक दृश्य प्रदान करती हैं। हालांकि, जब तक आप केटो द्वारा त्यागे गए पैकेट नुकसान से निपट नहीं रहे हैं, केवल विश्लेषिकी आपको यह नहीं बता सकती कि पैकेट नुकसान का कारण क्या है या पैकेट नुकसान कहाँ हो रहा है। 

पैकेट हानि को हल कैसे करें

1. पैकेट हानि के स्कोप का निर्धारण

जब आप शुरू करते हैं, तो यह पता लगाना वास्तव में महत्वपूर्ण हो जाता है कि कौन या क्या पैकेट नुकसान का अनुभव कर रहा है। क्या साइट पर हर उपयोगकर्ता पैकेट नुकसान का अनुभव कर रहा है, या यह केवल एक अकेला एंडपॉइंट तक सीमित है? क्या पैकेट नुकसान इंटरनेट पर हो रहा है या WAN पर? क्या पैकेट नुकसान से कई साइट प्रभावित हैं, या सिर्फ एक? क्या सभी ट्रैफ़िक प्रभावित हो रहा है, या यह केवल एक निश्चित एप्लिकेशन तक सीमित है? क्या पैकेट भिन्न हानि निरंतर होती है, या यह केवल रुक-रुक कर होती है?

ऊपर के प्रश्नों के उत्तरों को जानकर आप संबंधित CMA घटनाएँ पहचानने में मदद सकते हैं और समस्या निवारण प्रक्रिया के दौरान समय बचा सकते हैं। जितनी अधिक जानकारियाँ आप पहले से जानते हैं, आपका समस्या निवारण उतना अधिक केन्द्रित हो सकता है।

2. साइट एनालिटिक्स की जाँच - पैकेट हानि ग्राफ

क्या पैकेट हानि साइट की एनालिटिक्स पैकेट हानि ग्राफ पर दिखाई दे रही है? हमें विभिन्न विश्लेषणात्मक ग्राफों पर आधारित सिफ़ारिशें होती हैं जो पैकेट हानि और त्यागे गए पैकेट्स दिखा सकती हैं।

कोई पैकेट हानि नहीं

यह संभव है कि विश्लेषिकी स्क्रीन में कोई पैकेट हानि प्रदर्शित किए बिना पैकेट हानि मौजूद हो। स्थानीय नेटवर्क पर एक समस्या हो सकती है, या यह PoP-संबंधी समस्या हो सकती है। Socket से LAN साइड IP को पिंग करने के लिए UI नेटवर्क टूल का उपयोग करना कारण की पहचान करने का एक अच्छा तरीका हो सकता है।

पैकेट नुकसान

यदि ग्राफ़ पर पैकेट नुकसान दिखाया गया है, तो यह गलत बैंडविड्थ कॉन्फ़िगरेशन के कारण हो सकता है। कृपया नीचे बैंडविड्थ कॉन्फ़िगरेशन की जाँच में उल्लिखित कॉन्फ़िगर की गई बैंडविड्थ को देख लें।

प्रदाता पैकेट नुकसान के लिए, जाँचें कि क्या केवल तब ड्रॉप्स मौजूद हैं जब ट्रैफ़िक स्पाइक्स (विस्फोट) होते हैं। अगर ऐसा है, तो एप्लिकेशन एनालिटिक्स पेज का उपयोग करके स्पाइक्स का कारण बनने वाले ट्रैफ़िक की पहचान करें। आप ट्रैफ़िक को एक प्रतिबंधात्मक बैंडविड्थ प्रबंधन प्रोफ़ाइल को सौंपकर एप्लिकेशन ट्रैफ़िक को सीमित कर सकते हैं।

अक्सर, हम ऐसे मामलों को देखते हैं जहाँ थ्रूपुट आमतौर पर कम होता है, लेकिन विस्फोटक स्पाइक्स के कारण पैकेट हानि हो जाती है। हमें ध्यान में रखना होगा कि इंटरनेट सेवा प्रदाता का अपना ट्रैफ़िक आकारण नीति है, और ऐसे मामले में, संभावना है कि इंटरनेट सेवा प्रदाता की नीति और Cato की ट्रैफिक आकारण नीति में अलग-अलग विस्फोटकता नीतियाँ हैं। विस्फोटकता के बारे में अधिक जानकारी के लिए, नीचे देखें माइक्रो-विस्फोट जाँचना

3. साइट एनालिटिक्स की जाँच - अस्वीकृत पैकेट ग्राफ

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

Cato QoS भी उस कतार में विस्फोट के कारण, प्राथमिकता की परवाह किए बिना, किसी भी पैकेट को अस्वीकार कर सकता है। विस्फोट प्रबंधन की प्रकृति के कारण यह व्यवहार भी अपेक्षित है। प्राथमिकता विश्लेषक पृष्ठ का उपयोग यह पहचानने के लिए किया जा सकता है कि क्या ट्रैफिक विस्फोट उन पैकेटों के अस्वीकार होने के समय हो रहा है। अधिक जानकारी के लिए, देखें सॉकेट ट्रैफिक प्राथमिकता और QoS।

एनालिटिक्स स्क्रीन में प्राथमिकता विश्लेषक प्रत्येक QoS प्राथमिकता के लिए अपस्ट्रीम और डाउनस्ट्रीम दिशा में पैकेट हानि दिखाता है।

4. (वैकल्पिक) अंतिम मील का अनुभव निगरानी

अनुभव निगरानी लाइसेंस वाले ग्राहक संभावित पैकेट हानि और पैकेट अस्वीकार के लिए अंतिम मील और एप्लिकेशन प्रदर्शन टैब देख सकते हैं। डेटा को साइट नेटवर्क एनालिटिक्स पृष्ठ के निष्कर्षों के साथ जोड़कर यह बेहतर समझने के लिए कहाँ से समस्या उत्पन्न हो रही है।

5. साइट एनालिटिक्स की जाँच - अंतिम मील पैकेट हानि

आकलन करने के लिए कि क्या इंटरनेट सेवा प्रदाता समस्याओं का सामना कर रहा है, एनालिटिक्स स्क्रीन में अंतिम मील टैब का उपयोग करें यह जाँचने के लिए कि क्या किसी भी विलंबता परिवर्तन या पैकेट हानि जो WAN लिंक पर दिखाई देती है। प्रदायक पैकेट हानि के विपरीत, अंतिम मील डेटा लोकप्रिय वेबसाइटों के लिए ICMP परीक्षणों पर आधारित है। अनुशंसा के रूप में, पिंग किए जाने योग्य अतिरिक्त सेवा आईपी अंतिम मील निगरानी पृष्ठ पर जोड़े जा सकते हैं। उदाहरण के लिए, यदि VoIP से संबंधित समस्याएँ हैं, तो SIP सर्वर IP को IPs में से एक के रूप में सेट किया जा सकता है।

यदि इंटरनेट सेवा प्रदाता से संबंधित पैकेट हानि का संदेह है, तो अपने इंटरनेट सेवा प्रदाता से निम्नलिखित सवाल पूछें:

1. क्या आप UDP/443 या UDP/1337 (DTLS) ट्रैफ़िक पर QoS लागू कर रहे हैं?
2. क्या आप UDP ट्रैफिक पर कोई DoS सुरक्षा लागू कर रहे हैं जो PoP IP पर पैकेट हानि कर सकती है?
3. क्या आपके राउटर(s) में PoP IP के रास्ते में भीड़भाड़ या उच्च CPU है?
4. क्या आप सब्सक्राइब की गई लाइन दर से अधिक बर्स्टिंग की अनुमति देते हैं?

6. बैंडविड्थ कॉन्फ़िगरेशन की जाँच की जा रही है

पैकेट नुकसान लिंक भीड़भाड़ के कारण हो सकता है, और यह महत्वपूर्ण है कि प्रत्येक WAN लिंक के लिए बैंडविड्थ को Cato प्रबंधन अनुप्रयोग में सही तरीके से कॉन्फ़िगर किया गया है। सुनिश्चित करें कि कॉन्फ़िगर की गई बैंडविड्थ साइट कॉन्फ़िगरेशन में आईएसपी द्वारा प्रदान की गई बैंडविड्थ के साथ मेल खाती है। Cato साइट लाइसेंस की शर्तों के अनुसार सॉकेट WAN इंटरफ़ेस बैंडविड्थ सेटिंग को कॉन्फ़िगर करें।

Azure/AWS परिवेशों में पारंपरिक बैंडविड्थ सीमाएं नहीं होती हैं। इसके बजाय, कॉन्फ़िगर की गई साइट बैंडविड्थ को vSocket के लिए समर्थित बैंडविड्थ से कभी भी अधिक नहीं होना चाहिए। Azure के लिए, संस्करण 21 से, Standard_D8ls_v5 VM आकार 2Gbps तक समर्थन करता है। AWS में, c5n.xlarge इन्स्टेंस आकार 2Gbps से अधिक बैंडविड्थ प्रदान करता है। यह सुनिश्चित करना महत्वपूर्ण है कि साइट की कॉन्फ़िगर की गई बैंडविड्थ सही सीमा के भीतर रहे ताकि इष्टतम प्रदर्शन किया जा सके।

यदि कॉन्फ़िगर की गई बैंडविड्थ आईएसपी द्वारा प्रदान की गई बैंडविड्थ से कम है, तो Cato का QoS इंजन तब डेटा पैकेट ड्रॉप करना शुरू कर सकता है जब कॉन्फ़िगर की गई बैंडविड्थ सीमा पार कर ली जाती है। यदि ऐसा होता है, तो साइट के एनालिटिक्स थ्रूपुट ग्राफ पर साइट की कॉन्फ़िगर की गई बैंडविड्थ के स्तर के साथ Cato द्वारा त्यागे गए पैकेट के बराबर एक सपाट लेवल होगा।

यह समान व्यवहार तब भी हो सकता है जब बैंडविड्थ को सही तरीके से कॉन्फ़िगर किया गया है, परन्तु ISP लिंक भीड़भाड़ हो। हालांकि यह व्यवहार एक समस्या की गारंटी नहीं देता है, लेकिन यह अच्छी प्रक्रिया है कि यह सुनिश्चित करना कि इस स्थिति में बैंडविड्थ सही तरीके से कॉन्फ़िगर किया गया है।

यदि कॉन्फ़िगर की गई बैंडविड्थ आईएसपी द्वारा प्रदान की गई तुलना में अधिक है, तो Cato का QoS इंजन ISP की बैंडविड्थ सीमा पार करने पर सक्रिय नहीं होता, और इसलिए आईएसपी रैंडम तरीके से पैकेट ड्रॉप कर सकता है। यदि ऐसा होता है, तो आपको साइट एनालिटिक्स थ्रूपुट ग्राफ में निरंतर रेखा दिखाई देती है जो कॉन्फ़िगर की गई बैंडविड्थ स्तर से नीचे होती है और प्रदाता पैकेट हानि होती है।

प्रत्येक सॉकेट मॉडल के लिए सॉकेट थ्रूपुट और क्षमता जानकारी सॉकेट डेटाशीट में उपलब्ध है, इस लेख को देखें: X1700, X1600 & X1500 सॉकेट गाइड्स।

7. सॉकेट सीपीयू प्रदर्शन की जाँच करें

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

स्थिर सीपीयू उपयोग 90% से ऊपर सॉकेट प्रदर्शन को नकारात्मक रूप से प्रभावित कर सकता है और पैकेट नुकसान और उच्च विलंबता का कारण बन सकता है। यदि लगातार उच्च सीपीयू उपयोग देखा जाता है, तो संभावित हार्डवेयर प्रतिस्थापन का मूल्यांकन करने के लिए अपने खाता प्रतिनिधि से संपर्क करें (जैसे, X1500 से X1600)।

अधिक समस्या निवारण के लिए, समर्थन से संपर्क करें

रियल-टाइम सॉकेट सीपीयू उपयोग सॉकेट वेब यूआई में, हार्डवेयर स्थिति टैब के तहत देखा जा सकता है। प्रदर्शन की प्रवृत्तियों की पहचान करने के लिए सक्रिय उपयोग की ऐतिहासिक डेटा के साथ तुलना करें।

8. साइट पुनः कनेक्शन को छोड़ना

साइट का Cato क्लाउड से पुनः कनेक्शन पैकेट हानि का एक स्रोत है। होम > घटनाएँ की जाँच करें ताकि यह देखा जा सके कि क्या पैकेट हानि पुनः कनेक्शन घटनाओं के साथ मेल खाती है। घटनाओं को उप-प्रकार = 'पुनः कनेक्टेड' के रूप में फ़िल्टर करें।

पुनः कनेक्शन की घटनाएँ अस्वीकृति का कारण बताते हुए एक संदेश दिखाएंगी। पुनः कनेक्ट की गई घटनाओं को समझना देखें

9. Cato को बायपास कर रहा है

इंटरनेट पर पैकेट नुकसान के लिए, स्रोत या गंतव्य बायपास सेट अप करें ताकि Cato Cloud में किसी समस्या को जल्दी से नकारा जा सके। यह करने का सबसे आसान तरीका है कि साइट कॉन्फ़िगरेशन में एकल उपयोगकर्ता के आईपी पते के लिए स्रोत बायपास सेट अप करें और देखें कि क्या पैकेट नुकसान जारी रहता है। यदि पैकेट नुकसान जारी रहता है, तो समस्या LAN, सॉकेट या इंटरनेट सेवा प्रदाता में हो सकती है, लेकिन समस्या PoP से संबंधित नहीं होगी।

10. Ping परीक्षण चल रहा है

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

सॉकेट UI आपको होस्ट का नाम या IP के द्वारा पिंग टूल के साथ पिंग करने की अनुमति देता है। आप उस इंटरफ़ेस का चयन कर सकते हैं जिस पर आप पिंग भेजना चाहते हैं, चाहे Cato के माध्यम से या सीधे WAN लिंक के माध्यम से। पिंग के नतीजों में किसी भी असंगति की तलाश करें, जैसे पैकेट नुकसान या उच्च विलंबता। यदि पैकेट नुकसान Cato के साथ और उसके बिना मौजूद है, तो यह इंटरनेट सेवा प्रदाता समस्या को इंगित कर सकता है। इसके अलावा, यदि लिंक्स में से एक 4G/LTE है, तो आपको याद रखना होगा कि ये लिंक्स पैकेट नुकसान के प्रति अधिक संवेदनशील होते हैं।

UI केवल 10 पिंग अनुरोध भेजती है, अत: यदि आपको अधिक पिंग की आवश्यकता है तो आपको पिंग बटन को फिर से क्लिक करना होगा। 

नोट: पिंग परीक्षण नेटवर्क के बुनियादी स्वास्थ्य की जांच के लिए प्रभावी होते हैं, लेकिन पिंग लोप का अभाव आवश्यक रूप से एक साफ लाइन का संकेत नहीं देता है।

11. ट्रेसरूट परीक्षण चल रहा है

ट्रेसरूट का उपयोग स्रोत और गंतव्य के बीच राउटर (हॉप्स) को पहचानने के लिए किया जाता है। यह प्रत्येक हॉप के लिए पैकेट नुकसान और विलंबता को प्रदर्शित करेगा।

ट्रेसरूट सॉकेट UI से ट्रेसरूट टूलका उपयोग कर चलाया जा सकता है। ट्रेसरूट चलाएं ताकि सॉकेट और गंतव्य के बीच WAN लिंक पर किसी भी हॉप पर किसी भी पैकेट नुकसान या अप्रत्याशित उच्च विलंबता को खोजा जा सके। UI केवल प्रत्येक हॉप के लिए एक पैकेट भेजती है और प्रत्येक हॉप के लिए पैकेट नुकसान दिखाती है। चूंकि केवल एक पैकेट भेजा जा रहा है, आपको केवल 0% या 100% नुकसान दिखाई देगा।

ट्रेसरूट परिणाम विश्लेषण

इस बात से अवगत रहें कि किसी भी एकल हॉप पर दिखाई देने वाला पैकेट नुकसान जरूरी नहीं की किसी समस्या का संकेत हो। एकल हॉप 100% पैकेट नुकसान दिखा सकता है बस इसलिए क्योंकि ICMP राउटर पर सक्षम नहीं है। ICMP दर सीमा के कारण बिना किसी समस्या के एक होप 100% से कम पैकेट नुकसान दिखा सकता है। यदि आप एक हॉप पर कुछ पैकेट हानि देखते हैं और अगले हॉप पर 0% पैकेट हानि होती है, तो आप संभावना से ICMP दर सीमितता को देख रहे हैं।

यदि वास्तविक पैकेट हानि की समस्या है, तो यह एक हॉप पर शुरू होगा और कई हॉप्स के लिए जारी रहेगा, प्रत्येक हॉप पैकेट हानि दिखाएगा। यह भी संभव है कि एक पथ पर कई राउटर पैकेट नुकसान में योगदान कर रहे हैं, इसलिए प्रत्येक हॉप पर पैकेट नुकसान की मात्रा अलग हो सकती है। उदाहरण के लिए, मार्ग में आठ हॉप्स हैं और ट्रेसरूट हॉप 3-7 के लिए पैकेट हानि दिखाता है।

12. उच्च ट्रैफ़िक लोड उत्पन्न कर पैकेट हानि को पहचानना

रियल टाइम स्क्रीन किसी भी वर्तमान थ्रूपुट परिवर्तनों को पहचान कर तत्काल पैकेट हानि और अस्वीकृत पैकेट को पहचानने में मदद कर सकती है। सॉकेट के स्पीड टेस्ट उपकरण का उपयोग कर समस्या निवारण करते समय उच्च मांग के कारण उच्च लोड का अनुकरण और पैकेट हानि को पुनः प्रस्तुत करें।

सॉकेट एसपीडटेस्ट काटो के माध्यम से परिणाम लिंक के लिए Cato प्रबंधन अनुप्रयोग में कॉन्फ़िगर की गई बैंडविड्थ के करीब आने की उम्मीद है। ध्यान दें कि DTLS टनल ओवरहेड (117 बाइट्स) थ्रूपुट को थोड़ी मात्रा में कम कर सकता है। 

परीक्षण लिंक को संतृप्त कर देगा और नेटवर्क विश्लेषिकी स्क्रीन पर किसी भी इंटरनेट सेवा प्रदाता से संबंधित पैकेट हानि को दिखाएगा। यदि कॉन्फ़िगर की गई लिंक बैंडविड्थ आईएसपी द्वारा प्रदान की गई बैंडविड्थ से कम है, तो परीक्षण चलाते समय अस्वीकृत पैकेट अपेक्षित हैं।

प्रत्यक्ष स्पीड टेस्ट 

जब WAN पोर्ट के माध्यम से सीधे स्पीड टेस्ट चलाते हैं,  अपस्ट्रीम परिणाम Cato प्रबंधन अनुप्रयोग में कॉन्फ़िगर की गई बैंडविड्थ लाइसेंस के करीब होना चाहिए। सॉकेट फिर भी साइट के बैंडविड्थ लाइसेंस के अनुसार अपस्ट्रीम डायरेक्ट स्पीड टेस्ट के लिए QoS का उपयोग करेगा। दूसरी ओर,  डाउनस्ट्रीम परिणाम स्थानीय इंटरनेट सेवा प्रदाता की पूरी क्षमता दिखाएगा।

13. iPerf के साथ लिंक का परीक्षण करना

सॉकेट वेब यूआई आपको सॉकेट और Cato क्लाउड में जुड़े PoP के बीच अंतिम-माइल प्रदर्शन मुद्दों का निवारण करने के लिए iPerf tool का उपयोग करने देता है। वह सॉकेट जो iPerf क्लाइंट चला रहा है, वह जुड़े हुए PoP पर चल रहे iPerf सर्वर के खिलाफ परीक्षण करता है।

सॉकेट UI के टूल्स पेज से Cato के माध्यम से और सीधे WAN के माध्यम से iPerf परीक्षण चलाएं। प्रोटोकॉल के रूप में UDP का चयन करें (TCP फ्लो कंट्रोल को बाहर करने के लिए), दिशा (अपस्ट्रीम या डाउनस्ट्रीम) और लक्ष्य दर को कॉन्फ़िगर की गई बैंडविड्थ के रूप में सेट करें। यह उपकरण बेहतर पुष्टि कर सकता है कि Cato के माध्यम से और WAN के माध्यम से थ्रूपुट अपेक्षित हैं। ध्यान दें कि DTLS टनल ओवरहेड (117 बाइट्स) थ्रूपुट को थोड़ी मात्रा में कम कर सकता है। 

नीचे दिए गए उदाहरण में हम 45Mbps को लक्ष्य दर के रूप में सेट कर रहे हैं (जो कि Cato प्रबंधन अनुप्रयोग में कॉन्फ़िगर की गई बैंडविड्थ के समान है) और प्राप्त दर अपेक्षा से कम है, जिसमें पैकेट हानि 3.7% है

14. लिंक एग्रीगेशन (LAG) लिंक की जांच करना

सॉकेट और आंतरिक स्विच के बीच लिंक एग्रीगेशन (LAG) के गलत कॉन्फ़िगरेशन के कारण पैकेट हानि और उच्च विलंबता हो सकती है। इस विशेष समस्या का पता नेटवर्क विश्लेषिकी में नहीं लगाया जा सकता है, बल्कि इसे LAN के भीतर ट्रबलशूट करना आवश्यक है। Cato केवल स्टैटिक LAG का समर्थन करता है और LAG साथी को समान मोड का समर्थन करना चाहिए। LAG कॉन्फ़िगरेशन बेमेल पैकेट नुकसान का कारण बन जाएंगे।

अधिक ट्रबलशूटिंग जानकारी के लिए उच्च विलंबता और पैकेट हानि का अनुभव कर रहे लिंक एग्रीगेशन (LAG) लिंक देखें

15. सॉकेट की लिंक स्पीड की जांच

प्रदाता हानि का एक संभावित कारण सॉकेट लिंक का आधा डुप्लेक्स में चलना हो सकता है। इसका अर्थ है कि पैकेट एक समय में केवल एक दिशा (बाहरी या आंतरिक) में यात्रा कर सकते हैं जो थ्रूपुट को बहुत कम कर देता है और पैकेट नुकसान का कारण बनता है। सभी सॉकेट लिंक्स को बिना किसी अपवाद के हमेशा फुल-डुप्लेक्स पर होना चाहिए।

इसके अलावा, सुनिश्चित करें कि दोनों WAN और LAN लिंक स्पीड एक साइट के लिए कॉन्फ़िगर की गई बैंडविड्थ के बराबर या उससे अधिक है। लिंक की गति थ्रूपुट के लिए सीमाप्रदायक कारक हो सकती है। उदाहरण के लिए, यदि किसी साइट की कॉन्फ़िगर की गई बैंडविड्थ 200 Mbps है लेकिन LAN लिंक केवल 100 Mbps फुल-डुप्लेक्स पर तय है, तो सॉकेट से जुड़े कंप्यूटर 100 Mbps से अधिक थ्रूपुट हासिल नहीं कर सकते।

लिंक स्थिति की जांच करने के लिए, सॉकेट UI में लॉग इन करें और निगरानी पृष्ठ पर लिंक स्थिति देखें नीचे का उदाहरण 100 Mbps आधा-डुप्लेक्स में WAN1 लिंक दिखाता है।

यदि आप आधा-डुप्लेक्स पर या गलत गति पर सेट किए गए लिंक को देखते हैं, तो उस डिवाइस पर पोर्ट सेटिंग्स की जांच करें जिससे सॉकेट का लिंक जुड़ा है। सुनिश्चित करें कि यह ऑटो-नेगोशिएट पर सेट है या यह सॉकेट की गति सेटिंग्स से मेल खाता है। सभी सॉकेट लिंक्स डिफ़ॉल्ट रूप से ऑटो-नेगोशिएट पर सेट होते हैं, लेकिन आप नेटवर्क सेटिंग्स पृष्ठ के तहत गति को मजबूर कर सकते हैं।

यदि अन्य डिवाइस पर पोर्ट सेटिंग्स सही हैं, तो ईथरनेट केबल खराब हो सकता है। केबल को एक अच्छी ज्ञात के साथ बदलें और देखें कि डुप्लेक्स या गति बदलती है या नहीं। यदि वह काम नहीं करता है, तो एक लैपटॉप कंप्यूटर या अन्य डिवाइस को सॉकेट के पोर्ट से जोड़ें और लिंक स्थिति की जांच करें। दूसरे डिवाइस पर भी ऐसा ही करें। यदि सॉकेट का लिंक अपेक्षित गति और फुल-डुप्लेक्स पर आता है लेकिन दूसरे डिवाइस का लिंक नहीं दिखता है, तो आपको पता चल जाएगा कि समस्या दूसरे डिवाइस में है।

16. डुप्लिकेट IP की जांच

नेटवर्क में डुप्लिकेट IPs सॉकेट स्तर पर पैकेट हानि का कारण बनने वाली एक और समस्या है। सॉकेट आमतौर पर इसके कॉन्फ़िगर किए गए इंटरफेस IP पतों के साथ IP संघर्ष को पहचान सकता है। जब एक ही नेटवर्क पर दो उपकरणों को समान IP पता आवंटित किया जाता है, तो IP संघर्ष होता है। अगर यह होता है, तो आप सॉकेट UI की मॉनिटर पृष्ठ पर नीचे दी गई त्रुटि देखेंगे।

जब WAN इंटरफेस पर स्थिर IP पता कॉन्फ़िगर किया जाता है, तो डुप्लिकेट IP का पता लगाना विफल हो सकता है, क्योंकि सॉकेट केवल निष्क्रिय रूप से IP संघर्ष की निगरानी करता है। यह केवल तब IP संघर्ष का पता लगाएगा जब सॉकेट संघर्षरत IP वाले डिवाइस से एक ARP प्राप्त करता है।

एक बार जब संघर्षरत IP मुद्दा हल हो जाता है, चेतावनी के WebUI से गायब होने में 24 घंटे तक का समय लग सकता है। देखें यहां तक कि हल होने के बाद भी सॉकेट UI पर रिपोर्ट किया गया IP पता संघर्ष

17. माइक्रो-बर्स्ट की जाँच कर रहे हैं

पैकेट हानि का एक और संभावित कारण माइक्रो-बर्स्ट (विस्फोटकता) है। माइक्रो-बर्स्ट की विशेषता पैकेट या डेटा फ्रेम के अचानक वृद्धि से होती है जो बहुत ही छोटे समय सीमा में होती है, आमतौर पर केवल कुछ माइक्रोसेकेंड से मिलीसेकेंड तक चलती है। उन परिस्थितियों में जहां माइक्रो-बर्स्ट होते हैं और लिंक के दर सीमा को पार करते हैं, अंतिम-मील प्रदाता (ISP) अत्यधिक ट्रैफ़िक को गिरा सकती है, जिससे पैकेट हानि होती है।

नीचे दिए गए ग्राफ में, आप माइक्रो-बर्स्ट के कारण सामान्य पैकेट हानि और विस्फोटकता मूल्य सेटिंग्स समायोजित करने के बाद हुई सुधार को देख सकते हैं। 

उपरोक्त उदाहरण में विस्फोटकता स्तर का मान डिफ़ॉल्ट मान 0.2 से 0.01 पर संशोधित किया गया था, इसका अर्थ है कि सॉकेट और PoP ट्रैफ़िक पर अधिक आक्रामक आकार लागू करते हैं, जिससे पैकेट हानि समस्या का समाधान होता है।  

पैकेट हानि को कम करने के लिए विस्फोटकता स्तर की सेटिंग्स को समायोजित करना

अपस्ट्रीम और डाउनस्ट्रीम निर्देशों के लिए लागू डिफ़ॉल्ट विस्फोटकता मान 0.2 है। इस मान के साथ, सॉकेट और PoP पैकेट को मीडिया पर जितनी जल्दी हो सके उनकी क्रमानुसार विधि से अनुरूप करते हैं, जिससे समय अवधि बकेट के पहले माइक्रोसेकेंड में अधिक बाइट्स भेजने की अनुमति मिलती है। यह सेटिंग सीरियलाइजेशन देरी और समग्र विलंबता को कम करके प्रदर्शन को अनुकूलित करती है। 

इस समस्या निवारण कदम के भाग के रूप में, आपको पैकेट हानि को कम करने तक विस्फोटकता स्तर को धीरे-धीरे कम करना होगा। जैसे आप विस्फोटकता स्तर का मान कम करते हैं, सॉकेट और PoP ट्रैफ़िक पर अधिक आक्रामक आकार लागू करते हैं, जिससे माइक्रो-बर्स्ट को सुचारू बनाते हैं। सबसे कम मान जो आप कॉन्फ़िगर कर सकते हैं वह 0.001 है।

विस्फोटकता स्तर को समायोजित करने का सर्वोत्तम अभ्यास यह है कि मान को धीरे-धीरे कम किया जाए (उदाहरण के लिए, 0.2 से 0.18)।  मान को कम करने के बाद, साइट निगरानी वास्तविक समय या नेटवर्क विश्लेषिकी स्क्रीन में पैकेट हानि का विश्लेषण करके प्रभाव की निगरानी करें। यह ध्यान में रखें कि साइट मेट्रिक्स को अपडेट होने में आमतौर पर कुछ मिनट लगते हैं। पैकेट हानि को कम करने तक विस्फोटकता मान को कम करते रहें। 

यदि इस प्रक्रिया से पैकेट हानि का समाधान नहीं होता है, तो इसका अर्थ है कि इसका कारण माइक्रो-बर्स्ट के अलावा कुछ और है।  इस मामले में, डिफ़ॉल्ट विस्फोटकता मान 0.2 को पुनर्स्थापित करें और आगे की सहायता के लिए समर्थन से संपर्क करें। 

विस्फोटकता स्तर को बदलना

विस्फोटकता स्तर को अपस्ट्रीम और डाउनस्ट्रीम दिशाओं के लिए समायोजित किया जा सकता है। यह सेटिंग साइट के सभी WAN लिंक को प्रभावित करती है। 

कॉन्फ़िगरेशन साइट स्तर या खाता स्तर पर लागू किया जाता है। साइट स्तर की कॉन्फ़िगरेशन को खाता स्तर की तुलना में प्राथमिकता मिलती है।

बर्स्टिनेस स्तर कॉन्फ़िगर करने के लिए:

1. नेविगेशन मेनू से, खाता स्तर के लिए संसाधन > उन्नत कॉन्फ़िगरेशन या साइट स्तर सेटिंग के लिए साइट कॉन्फ़िगरेशन > उन्नत कॉन्फ़िगरेशन चुनें।
   
2. बर्स्टिनेस डाउनस्ट्रीम मान या बर्स्टिनेस अपस्ट्रीम मान चुनें।
3. सेटिंग सक्षम करें और मान को 0.001 - 0.2 के दायरे के बीच समायोजित करें।
   
4. लागू करें पर क्लिक करें
5. सहेजें पर क्लिक करें

नोट: 

• यदि बर्स्टिनेस को पहले Cato समर्थन द्वारा समायोजित किया गया था, तो समायोजित मान 0.2 के डिफ़ॉल्ट मूल्य के बजाय दिखाया जाएगा
• बर्स्टिनेस के मान केवल सॉकेट साइट्स के लिए समायोजित किए जा सकते हैं
• Cato प्रबंधन एप्लिकेशन में सबसे छोटा डेटा बकेट 5 सेकंड का है, माइक्रोबर्स्ट्स सबसे छोटे डेटा बकेट में सामान्यीकृत होते हैं और सामान्यतः पहचानने में कठिन होते हैं।