मुद्दा
पैकेट नुकसान के स्रोत का निर्धारण और यह क्यों हो रहा है, हमेशा आसान नहीं होता। पैकेट इंटरनेट पर अलग-अलग आईएसपी और संगठनों के स्वामित्व वाले कई नेटवर्कों के माध्यम से गुजरते हैं, और आपको हर राउटर तक पहुंच प्राप्त नहीं होती है, जिससे आप लिंक की स्थिति और CPU लोड जैसी चीजों की जांच कर सकें। इसके अलावा, पैकेट नुकसान नेटवर्क पथ के किसी भी बिंदु पर हो सकता है।
संभावित कारण
यात्रा के दौरान पैकेट गिराने के कई कारण हो सकते हैं। कुछ सामान्य कारण हैं:
आईएसपी साथी समस्याएं
लिंक भीड़
गलत कॉन्फ़िगरेशन (बैंडविड्थ सेटिंग्स या नेटवर्क कार्ड की गति और डुप्लेक्स)
हार्डवेयर विफलता
नेटवर्क उपकरण पर उच्च CPU
माइक्रो-बर्स्ट हैंडलिंग
Cato में पैकेट नुकसान को समझना
Cato में पैकेट नुकसान की पहचान करने का एक अच्छा तरीका है एनालिटिक्स स्क्रीन का उपयोग करना Cato प्रबंधन एप्लिकेशन में। पैकेट नुकसान और त्याग दिया गया ग्राफ़ समय के साथ पैकेट नुकसान को दिखाते हैं और आपको विशिष्ट समय-सीमाओं पर ध्यान केंद्रित करने देते हैं। ये ग्राफ़ यह पहचानने में उपयोगी हैं कि पैकेट हानि हो रही है या नहीं और यह कब हुई थी।
Note:
नोट: एनालिटिक्स ग्राफ़ में सबसे छोटा डेटा बकेट नमूना का आकार 5 सेकेंड है। परिणामस्वरूप, 5ms के भीतर एक माइक्रो-बर्स्ट को प्रदर्शित औसत के भीतर मानकीकरण किया जाएगा और एनालिटिक्स ग्राफ़ में एक पीक के रूप में नहीं दिखाया जाएगा।
1. प्रदाता नुकसान
यह सॉकेट और PoP के बीच होता है। हालांकि अधिकांश प्रदाता पैकेट नुकसान Cato के नियंत्रण के बाहर अंतिम मील पर नेटवर्क कनेक्टिविटी मुद्दों के कारण है, यह जरूरी नहीं कि Cato से संबंधित समस्या को बाहर कर दे।
Cato कैसे प्रदाता नुकसान को मापता है
प्रदाता नुकसान को मापने के लिए सॉकेट और PoP दोनों पर दिए गए लिंक पर भेजे और प्राप्त किए गए पैकेटों की गणना की तुलना की जाती है।
डाउनस्ट्रीम पैकेट नुकसान वह अंतर है जो PoP द्वारा भेजे गए पैकेटों की संख्या और सॉकेट द्वारा प्राप्त किए गए पैकेटों की संख्या के बीच होता है, प्रतिशत के रूप में व्यक्त किया गया।
सूत्र:
अपस्ट्रीम पैकेट नुकसान वह अंतर है जो सॉकेट द्वारा भेजे गए पैकेटों की संख्या और PoP द्वारा प्राप्त किए गए पैकेटों की संख्या के बीच होता है, प्रतिशत के रूप में व्यक्त किया गया।
सूत्र:
Cato नेटवर्क्स द्वारा प्रदाता पैकेट नुकसान की गणना करने का तरीका यह है कि, जितना आसान यह हो सकता है, आप तुरंत ISP पर सभी दोष नहीं डाल सकते। संभव है कि आपके पास Socket और ISP राउटर के बीच उपकरण हो जो पैकेट नुकसान का योगदान देता हो, या हो सकता है कि PoP के करीब नेटवर्क मार्ग में समस्याएँ हों जिन पर ISP का नियंत्रण नहीं है।
2. Cato त्याग दिया गया
यह तब होता है जब Cato QoS जानबूझकर पैकेट छोड़ता है। जब QoS इंजन निम्न-प्राथमिकता पैकेटों को छोड़ने लगता है, तब:
जब कुल थ्रूपुट एक लिंक पर लिंक के लिए कॉन्फ़िगर बैंडविड्थ से मेल खाता है, तो भीड़ होती है।
अगर एक बैंडविड्थ प्रबंधन प्राथमिकता को एक कठिन थ्रूपुट सीमा के साथ कॉन्फ़िगर किया गया है और प्राथमिकता से मेल खाता ट्रैफ़िक सीमा तक पहुँचता है, तो केटो भी पैकेट्स को त्याग देता है।
विस्फोट के दौरान (यहां तक कि उच्च प्राथमिकता कतारें भी पैकेट छोड़ सकती हैं)।
Cato द्वारा त्यागे गए पैकेट नुकसान को अपेक्षित व्यवहार माना जाता है और यह अनिवार्य रूप से किसी समस्या का संकेत नहीं है।
Cato पैकेट नुकसान से जुड़े किसी भी मुद्दों की संभावना गलत कॉन्फ़िगरेशन के कारण होती है। महत्वपूर्ण एप्लिकेशन, जैसे VoIP, को उच्चतम बैंडविड्थ प्रबंधन प्राथमिकता दी जानी चाहिए। यदि भीड़ होती है, तो Cato निम्न-प्राथमिकता ट्रैफ़िक को छोड़ देता है, लेकिन यह उच्च-प्राथमिकता ट्रैफ़िक को नहीं छोड़ता। हमेशा सुनिश्चित करें कि उचित बैंडविड्थ प्रबंधन प्राथमिकताएँ आवंटित की गई हैं।
विश्लेषिकी पैकेट नुकसान का व्यापक दृश्य प्रदान करती हैं। हालांकि, जब तक आप Cato द्वारा त्यागे गए पैकेट नुकसान को नहीं संभाल रहे हैं, अकेले एनालिटिक्स के माध्यम से पैकेट नुकसान का कारण या स्थान नहीं बताया जा सकता है
पैकेट हानि को हल कैसे करें
1. पैकेट हानि के स्कोप का निर्धारण
जब आप शुरू करते हैं, तो यह पता लगाना वास्तव में महत्वपूर्ण है कि कौन या क्या पैकेट नुकसान का अनुभव कर रहा है।
क्या हर उपयोगकर्ता किसी साइट पर पैकेट नुकसान का अनुभव कर रहा है, या यह केवल एक विशिष्ट एंडपॉइंट तक सीमित है?
क्या पैकेट नुकसान इंटरनेट पर होता है या WAN पर?
क्या कई साइट्स पैकेट नुकसान से प्रभावित हैं, या केवल एक?
क्या सभी ट्रैफ़िक प्रभावित है, या यह केवल एक निश्चित एप्लिकेशन है?
क्या पैकेट नुकसान स्थिर है, या यह केवल समय-समय पर होता है?
ऊपर के सवालों के उत्तर जानने से आप संबंधित CMA घटनाएँ पहचान सकते हैं और समस्या निवारण प्रक्रिया के दौरान समय बचा सकते हैं। आप पहले से जितनी अधिक जानकारी जानते हैं, आपका समस्या निवारण उतना ही अधिक केंद्रित हो सकता है।
2. साइट एनालिटिक्स की जाँच - पैकेट हानि ग्राफ
क्या पैकेट हानि साइट की एनालिटिक्स पैकेट हानि ग्राफ पर दिखाई दे रही है? हमें विभिन्न विश्लेषणात्मक ग्राफों पर आधारित सिफ़ारिशें होती हैं जो पैकेट हानि और त्यागे गए पैकेट्स दिखा सकती हैं।
कोई पैकेट हानि नहीं
यह संभव है कि विश्लेषिकी स्क्रीन में कोई पैकेट हानि प्रदर्शित किए बिना पैकेट हानि मौजूद हो। स्थानीय नेटवर्क पर एक समस्या हो सकती है, या यह PoP-संबंधी समस्या हो सकती है। Socket से LAN साइड IP को पिंग करने के लिए UI नेटवर्क टूल का उपयोग करना कारण की पहचान करने का एक अच्छा तरीका हो सकता है।
पैकेट नुकसान
यदि ग्राफ़ पर पैकेट हानि दर्शाई गई है, तो यह गलत बैंडविड्थ कॉन्फ़िगरेशन के कारण हो सकता है। कृपया नीचे बैंडविड्थ कॉन्फ़िगरेशन की जाँच के लिए वर्णित कॉन्फ़िगर की गई बैंडविड्थ पर नज़र डालें। <\/span>
प्रदाता पैकेट नुकसान के लिए, जांचें कि क्या ड्रॉप्स केवल उस समय आते हैं जब ट्रैफिक स्पाइक्स (विस्फोट) होते हैं। अगर ऐसा है, तो एप्लिकेशन एनालिटिक्स पेज का उपयोग करके स्पाइक्स का कारण बनने वाले ट्रैफिक की पहचान करें। आप ट्रैफ़िक को एक प्रतिबंधात्मक बैंडविड्थ प्रबंधन प्रोफ़ाइल को सौंपकर एप्लिकेशन ट्रैफ़िक को सीमित कर सकते हैं।
अक्सर, हम ऐसे मामलों को देखते हैं जहाँ थ्रूपुट आमतौर पर कम होता है, लेकिन विस्फोटक स्पाइक्स के कारण पैकेट हानि हो जाती है। हमें ध्यान में रखना होगा कि इंटरनेट सेवा प्रदाता का अपना ट्रैफ़िक आकारण नीति है, और ऐसे मामले में, संभावना है कि इंटरनेट सेवा प्रदाता की नीति और Cato की ट्रैफिक आकारण नीति में अलग-अलग विस्फोटकता नीतियाँ हैं। विस्फोटकता के बारे में अधिक जानकारी के लिए, नीचे देखें माइक्रो-विस्फोट जाँचना
3. साइट एनालिटिक्स की जाँच - अस्वीकृत पैकेट ग्राफ
Cato अस्वीकृत पैकेट के लिए, आपको बैंडविड्थ प्राथमिकता भी जांचनी चाहिए। साइट की एनालिटिक्स स्क्रीन के तहत प्राथमिकता विश्लेषक की जांच करें कि कौन सी प्राथमिकता अस्वीकृत हो रही है। आप प्राथमिकता अनुभाग का विस्तार कर सकते हैं ताकि उस प्राथमिकता में शीर्ष एप्लिकेशन दिख सके। यदि पैकेट हानि केवल एक विशिष्ट एप्लिकेशन को प्रभावित कर रही है, तो आपको उस एप्लिकेशन की प्राथमिकता नेटवर्क नियम में बढ़ानी हो सकती है। याद रखें, Cato QoS को भीड़-जाम के समय कम प्राथमिकता वाले पैकेट ड्रॉप करने के लिए डिज़ाइन किया गया है, इसलिए Cato अस्वीकृत पैकेट हानि हमेशा समस्या नहीं होती।
Cato QoS भी उस कतार में विस्फोट के कारण, प्राथमिकता की परवाह किए बिना, किसी भी पैकेट को अस्वीकार कर सकता है। विस्फोट प्रबंधन की प्रकृति के कारण यह व्यवहार भी अपेक्षित है। प्राथमिकता विश्लेषक पृष्ठ का उपयोग यह पहचानने के लिए किया जा सकता है कि क्या ट्रैफिक विस्फोट उन पैकेटों के अस्वीकार होने के समय हो रहा है। अधिक जानकारी के लिए, देखें सॉकेट ट्रैफिक प्राथमिकता और QoS।
एनालिटिक्स स्क्रीन में प्राथमिकता विश्लेषक प्रत्येक QoS प्राथमिकता के लिए अपस्ट्रीम और डाउनस्ट्रीम दिशा में पैकेट हानि दिखाता है।
4. साइट एनालिटिक्स की जाँच - अंतिम मील पैकेट हानि
आईएसपी यदि समस्याओं का सामना कर रहा है पता लगाने के लिए, अंतिम मील टैब का उपयोग करें एनालिटिक्स स्क्रीन में किसी भी विलंबता परिवर्तनों या पैकेट हानि के लिए जाँच करें जो WAN लिंक पर दिखाई देती है। प्रदायक पैकेट हानि के विपरीत, अंतिम मील डेटा लोकप्रिय वेबसाइटों के लिए ICMP परीक्षणों पर आधारित है। अनुशंसा के रूप में, पिंग करने योग्य अतिरिक्त सेवा आईपी अंतिम मील निगरानी पृष्ठ पर जोड़े जा सकते हैं। उदाहरण के लिए, यदि VoIP से संबंधित समस्याएँ हैं, तो SIP सर्वर IP को IPs में से एक के रूप में सेट किया जा सकता है।
यदि इंटरनेट सेवा प्रदाता से संबंधित पैकेट हानि का संदेह है, तो अपने इंटरनेट सेवा प्रदाता से निम्नलिखित सवाल पूछें:
क्या आप UDP/443 या UDP/1337 (DTLS) ट्रैफ़िक पर QoS लागू कर रहे हैं?
क्या आप UDP ट्रैफिक पर कोई DoS सुरक्षा लागू कर रहे हैं जो PoP IP पर पैकेट हानि कर सकती है?
क्या आपके राउटर(s) में PoP IP के रास्ते में भीड़भाड़ या उच्च CPU है?
क्या आप सब्सक्राइब की गई लाइन दर से अधिक बर्स्टिंग की अनुमति देते हैं?
5. (वैकल्पिक) अंतिम मील का अनुभव निगरानी
अनुभव निगरानी लाइसेंस वाले ग्राहक संभावित पैकेट हानि और पैकेट अस्वीकृतियों के लिए अंतिम मील और एप्लिकेशन प्रदर्शन टैब देख सकते हैं। डेटा को साइट नेटवर्क एनालिटिक्स पृष्ठ के निष्कर्षों के साथ जोड़कर यह बेहतर समझने के लिए कहाँ से समस्या उत्पन्न हो रही है।
6. DTLS पोर्ट UDP/443 बदलें
कुछ इंटरनेट सेवा प्रदाता विशेष रूप से UDP/443 पर ट्रैफ़िक शेपिंग या QOS लागू कर सकते हैं। यहां तक कि जब लिंक अन्यथा स्थिर होता है, तो यह पैकेट नुकसान का कारण बन सकता है।
सॉकेट कॉन्फ़िगरेशन में, DTLS टनल पोर्ट को 443 से 1337 में बदलें।
परिवर्तन लागू करने के बाद, एनालिटिक्स स्क्रीन में पैकेट नुकसान और विलंबता की निगरानी करें।
यदि पैकेट नुकसान में सुधार होता है, तो यह पुष्टि करता है कि इंटरनेट सेवा प्रदाता UDP/443 ट्रैफ़िक को शेप कर रहा है। उस स्थिति में, टनल को 1337 पर रखें या ISP के साथ मुद्दे को बढ़ाएं।
7. बैंडविड्थ कॉन्फ़िगरेशन की जाँच की जा रही है
पैकेट हानि लिंक के भीड़भाड़ के कारण हो सकता है और यह महत्वूर्ण है कि प्रत्येक WAN लिंक के लिए बैंडविड्थ Cato प्रबंधन अनुप्रयोग में सही तरीके से कॉन्फ़िगर किया गया हो। सुनिश्चित करें कि कॉन्फ़िगर की गई बैंडविड्थ साइट कॉन्फ़िगरेशन में आईएसपी द्वारा प्रदान की गई बैंडविड्थ के साथ मेल खाती है। Cato साइट लाइसेंस के नियमों के अनुसार सॉकेट वैन इंटरफेस बैंडविड्थ सेटिंग को कॉन्फ़िगर करें.
Azure/AWS परिवेशों में पारंपरिक बैंडविड्थ सीमाएं नहीं होती हैं। इसके बजाय, कॉन्फ़िगर की गई साइट बैंडविड्थ को vSocket के लिए समर्थित बैंडविड्थ से कभी भी अधिक नहीं होना चाहिए। Azure के लिए, संस्करण 21 से, Standard_D8ls_v5 VM आकार 2Gbps तक समर्थन करता है। AWS में, c5n.xlarge इन्स्टेंस आकार 2Gbps से अधिक बैंडविड्थ प्रदान करता है। यह सुनिश्चित करना महत्वपूर्ण है कि साइट की कॉन्फ़िगर की गई बैंडविड्थ सही सीमा के भीतर रहे ताकि इष्टतम प्रदर्शन किया जा सके।
यदि कॉन्फ़िगर की गई बैंडविड्थ आईएसपी द्वारा प्रदान की गई बैंडविड्थ से कम है, तो Cato का QoS इंजन तब डेटा पैकेट ड्रॉप करना शुरू कर सकता है जब कॉन्फ़िगर की गई बैंडविड्थ सीमा पार कर ली जाती है। यदि ऐसा होता है, तो साइट के एनालिटिक्स थ्रूपुट ग्राफ पर साइट की कॉन्फ़िगर की गई बैंडविड्थ के स्तर के साथ Cato द्वारा त्यागे गए पैकेट के बराबर एक सपाट लेवल होगा।
यह समान व्यवहार तब भी हो सकता है जब बैंडविड्थ को सही तरीके से कॉन्फ़िगर किया गया है, परन्तु ISP लिंक भीड़भाड़ हो। हालांकि यह व्यवहार एक समस्या की गारंटी नहीं देता है, लेकिन यह अच्छी प्रक्रिया है कि यह सुनिश्चित करना कि इस स्थिति में बैंडविड्थ सही तरीके से कॉन्फ़िगर किया गया है।
यदि कॉन्फ़िगर की गई बैंडविड्थ आईएसपी द्वारा प्रदान की गई तुलना में अधिक है, तो Cato का QoS इंजन ISP की बैंडविड्थ सीमा पार करने पर सक्रिय नहीं होता, और इसलिए आईएसपी रैंडम तरीके से पैकेट ड्रॉप कर सकता है। यदि ऐसा होता है, तो आपको साइट एनालिटिक्स थ्रूपुट ग्राफ में निरंतर रेखा दिखाई देती है जो कॉन्फ़िगर की गई बैंडविड्थ स्तर से नीचे होती है और प्रदाता पैकेट हानि होती है।
प्रत्येक सॉकेट मॉडल के लिए सॉकेट थ्रूपुट और क्षमता जानकारी सॉकेट डेटाशीट में उपलब्ध है, इस लेख को देखें: X1700, X1600 & X1500 सॉकेट गाइड्स।
8. सॉकेट सीपीयू प्रदर्शन की जाँच करें
CMA में नेटवर्क एनालिटिक्स से, हार्डवेयर टैब का चयन करें। इस अनुभाग में प्रत्येक कोर के लिए ऐतिहासिक सीपीयू उपयोग प्रतिशत दिखाया गया है।
लगातार CPU उपयोग 90% से अधिक सॉकेट प्रदर्शन पर नकारात्मक प्रभाव डाल सकता है और पैकेट हानि और उच्च विलंबता का कारण बन सकता है। यदि लगातार उच्च CPU उपयोग देखा जाता है, तो संभावित हार्डवेयर प्रतिस्थापन का मूल्यांकन करने के लिए अपने खाता प्रतिनिधि से संपर्क करें (उदा., X1500 से X1600)।
अधिक समस्या निवारण के लिए, समर्थन से संपर्क करें।
रियल-टाइम सॉकेट सीपीयू उपयोग सॉकेट वेब यूआई में, हार्डवेयर स्थिति टैब के तहत देखा जा सकता है। प्रदर्शन की प्रवृत्तियों की पहचान करने के लिए सक्रिय उपयोग की ऐतिहासिक डेटा के साथ तुलना करें।
9. साइट पुनः कनेक्शन को छोड़ना
साइट का Cato क्लाउड से पुनः कनेक्शन पैकेट हानि का एक स्रोत है। होम > घटनाएँ की जाँच करें ताकि यह देखा जा सके कि क्या पैकेट हानि पुनः कनेक्शन घटनाओं के साथ मेल खाती है। घटनाओं को उप-प्रकार = 'पुनः कनेक्टेड' के रूप में फ़िल्टर करें।
पुनः कनेक्शन की घटनाएँ अस्वीकृति का कारण बताते हुए एक संदेश दिखाएंगी। पुनः कनेक्ट की गई घटनाओं को समझना देखें।
10. Cato को बायपास कर रहा है
इंटरनेट पर पैकेट नुकसान के लिए, स्रोत या गंतव्य bypass सेट अप करें ताकि Cato Cloud में किसी समस्या को जल्दी से नकारा जा सके। यह करने का सबसे आसान तरीका है कि साइट कॉन्फ़िगरेशन में एकल उपयोगकर्ता के आईपी पते के लिए स्रोत बायपास सेट अप करें और देखें कि क्या पैकेट नुकसान जारी रहता है। यदि पैकेट नुकसान जारी रहता है, तो समस्या LAN, सॉकेट, या इंटरनेट सेवा प्रदाता में हो सकती है, लेकिन समस्या PoP से संबंधित नहीं होगी।
11. पिंग टेस्ट चला रहा है
ऐसा आईपी पता जो पैकेट नुकसान से प्रभावित हो, उसके स्रोत और गंतव्य के बीच निरंतर पिंग शुरू करें। पिंग्स को ट्रेस करना आसान है और उन्हें पैकेट कैप्चर में विश्लेषण किया जा सकता है। जब कुछ पिंग अनुरोध अपनी गंतव्य पर नहीं पहुंचते हैं, तो यह संभवतः पैकेट नुकसान का अनुभव कर सकता है और यह अनुरोध समय समाप्ति के रूप में दिखाया जाएगा।
नोट: पैकेट कैप्चर CPU गहन हैं और प्रदर्शन ह्रास का कारण बन सकते हैं। कृपया सुनिश्चित करें कि पैकेट कैप्चर निष्क्रिय हैं जब तक सक्रिय रूप से समस्या का समाधान नहीं हो रहा है।
सॉकेट UI आपको होस्ट का नाम या IP के द्वारा पिंग टूल के साथ पिंग करने की अनुमति देता है। आप उस इंटरफ़ेस का चयन कर सकते हैं जिस पर आप पिंग भेजना चाहते हैं, चाहे Cato के माध्यम से या सीधे WAN लिंक के माध्यम से। पिंग के नतीजों में किसी भी असंगति की तलाश करें, जैसे पैकेट नुकसान या उच्च विलंबता। यदि पैकेट नुकसान Cato के साथ और उसके बिना मौजूद है, तो यह इंटरनेट सेवा प्रदाता समस्या को इंगित कर सकता है। इसके अलावा, यदि लिंक्स में से एक 4G/LTE है, तो आपको याद रखना होगा कि ये लिंक्स पैकेट नुकसान के प्रति अधिक संवेदनशील होते हैं.
UI केवल 10 पिंग अनुरोध भेजती है, अत: यदि आपको अधिक पिंग की आवश्यकता है तो आपको पिंग बटन को फिर से क्लिक करना होगा।
नोट: पिंग परीक्षण नेटवर्क के बुनियादी स्वास्थ्य की जांच के लिए प्रभावी होते हैं, लेकिन पिंग लोप का अभाव आवश्यक रूप से एक साफ लाइन का संकेत नहीं देता है।
12. ट्रेसरूट टेस्ट चला रहा है
ट्रैसरूट का उपयोग स्रोत और गंतव्य के बीच राउटर (हॉप्स) की पहचान करने के लिए किया जाता है। यह प्रत्येक हॉप के लिए पैकेट नुकसान और विलंबता को प्रदर्शित करेगा।
ट्रेसरूट सॉकेट UI से ट्रेसरूट टूल का उपयोग कर चलाया जा सकता है। ट्रेसरूट चलाएं ताकि सॉकेट और गंतव्य के बीच WAN लिंक पर किसी भी पैकेट हानि या अप्रत्याशित उच्च विलंबता का पता लगाया जा सके। टेस्ट चलाने और पैकेट हानि को मान्य करते समय अधिकतम गणना (200) को न्यूनतम अंतराल (0.1) पर सेट करने की सिफारिश की जाती है।
ट्रेसरूट परिणाम विश्लेषण
इस बात से अवगत रहें कि किसी भी एकल हॉप पर दिखाई देने वाला पैकेट नुकसान जरूरी नहीं की किसी समस्या का संकेत हो। एकल हॉप 100% पैकेट नुकसान दिखा सकता है बस इसलिए क्योंकि ICMP राउटर पर सक्षम नहीं है। ICMP दर सीमा के कारण बिना किसी समस्या के एक होप 100% से कम पैकेट नुकसान दिखा सकता है। यदि आप एक हॉप पर कुछ पैकेट हानि देखते हैं और अगले हॉप पर 0% पैकेट हानि होती है, तो आप संभावना से ICMP दर सीमितता को देख रहे हैं।
यदि पैकेट हानि के साथ वास्तविक समस्या है, तो यह एक होप पर शुरू होगा और कई होप्स के लिए जारी रहेगा, प्रत्येक होप पैकेट हानि दिखा रहा है। यह भी संभव है कि एक पथ पर कई राउटर पैकेट नुकसान में योगदान कर रहे हैं, इसलिए प्रत्येक हॉप पर पैकेट नुकसान की मात्रा अलग हो सकती है। उदाहरण के लिए, मार्ग में आठ होप हैं, और ट्रेसरूट होप 3-7 के लिए पैकेट हानि दिखाता है।
13. स्पीडटेस्ट के साथ लिंक परीक्षण
रियल-टाइम स्क्रीन तत्काल पैकेट हानि और अस्वीकृत पैकेट को पहचानने में मदद कर सकता है। समस्या निवारण के दौरान, उच्च मांग के कारण पैकेट नुकसान को पुन: उत्पन्न करने और उच्च भार को अनुकरण करने के लिए सॉकेट के speedtest tool का उपयोग करें।
सॉकेट स्पीडटेस्ट परिणाम काटो के माध्यम से लिंक के लिए Cato प्रबंधन अनुप्रयोग में कॉन्फ़िगर की गई बैंडविड्थ के करीब होने की उम्मीद है। हालांकि, DTLS टनल ओवरहेड (117 बाइट्स) थ्रूपुट को थोड़ा कम कर सकता है।
परीक्षण लिंक को संतृप्त कर देगा और नेटवर्क एनालिटिक्स स्क्रीन पर किसी भी इंटरनेट सेवा प्रदाता संबंधित पैकेट हानि को दिखाएगा। यदि कॉन्फ़िगर की गई लिंक बैंडविड्थ आईएसपी द्वारा प्रदान की गई बैंडविड्थ से कम है, तो परीक्षण चलाते समय अस्वीकृत पैकेट अपेक्षित हैं।
प्रत्यक्ष स्पीड टेस्ट
जब WAN पोर्ट के माध्यम से सीधे स्पीड टेस्ट चलाते हैं, अपस्ट्रीम परिणाम Cato प्रबंधन अनुप्रयोग में कॉन्फ़िगर की गई बैंडविड्थ लाइसेंस के करीब होना चाहिए. सॉकेट फिर भी साइट के बैंडविड्थ लाइसेंस के अनुसार अपस्ट्रीम डायरेक्ट स्पीड टेस्ट के लिए QoS का उपयोग करेगा. दूसरी ओर, डाउनस्ट्रीम परिणाम स्थानीय इंटरनेट सेवा प्रदाता की पूरी क्षमता दिखाएगा.
14. iPerf के साथ लिंक का परीक्षण
सॉकेट वेब यूआई आपको सॉकेट और Cato क्लाउड में जुड़े PoP के बीच अंतिम माइल प्रदर्शन मुद्दों का निवारण करने के लिए iPerf tool का उपयोग करने की अनुमति देता है। सॉकेट जो iPerf क्लाइंट चला रहा है, जुड़े PoP पर चल रहे iPerf सर्वर के खिलाफ परीक्षण करता है।
सॉकेट UI के टूल्स पेज से Cato के माध्यम से और सीधे WAN के माध्यम से iPerf परीक्षण चलाएं। प्रोटोकॉल के रूप में UDP का चयन करें (TCP फ्लो कंट्रोल को बाहर करने के लिए), दिशा (अपस्ट्रीम या डाउनस्ट्रीम) और लक्ष्य दर को कॉन्फ़िगर की गई बैंडविड्थ के रूप में सेट करें। यह उपकरण बेहतर पुष्टि कर सकता है कि Cato के माध्यम से और WAN के माध्यम से थ्रूपुट अपेक्षित हैं। ध्यान दें कि DTLS टनल ओवरहेड (117 बाइट्स) थ्रूपुट को थोड़ा कम कर सकता है।
नीचे दिए गए उदाहरण में हम 45Mbps को लक्ष्य दर के रूप में सेट कर रहे हैं (जो कि Cato प्रबंधन अनुप्रयोग में कॉन्फ़िगर की गई बैंडविड्थ के समान है) और प्राप्त दर अपेक्षा से कम है, जिसमें पैकेट हानि 3.7% है
15. लिंक एग्रीगेशन (LAG) लिंक की जांच करना
सॉकेट और आंतरिक स्विच के बीच लिंक एग्रीगेशन (LAG) के गलत कॉन्फ़िगरेशन के कारण पैकेट हानि और उच्च विलंबता हो सकती है। इस विशेष समस्या का पता नेटवर्क विश्लेषिकी में नहीं लगाया जा सकता है, बल्कि इसे LAN के भीतर ट्रबलशूट करना आवश्यक है। Cato केवल स्टैटिक LAG का समर्थन करता है और LAG साथी को समान मोड का समर्थन करना चाहिए। LAG कॉन्फ़िगरेशन बेमेल पैकेट नुकसान का कारण बन जाएंगे।
अधिक समस्या निवारण जानकारी के लिए देखें उच्च विलंबता और पैकेट हानि का अनुभव कर रहे लिंक एग्रीगेशन (LAG) लिंक।
16. सॉकेट की लिंक स्पीड की जांच
प्रदाता नुकसान का एक संभावित कारण यह है कि सॉकेट लिंक हाफ-डुप्लेक्स पर चल रहा है। इसका मतलब है कि पैकेट केवल एक दिशा में (आउटबाउंड या इनबाउंड) समय पर यात्रा कर सकते हैं, जो थ्रूपुट को बेहद कम कर देता है और पैकेट नुकसान का परिणाम होता है। सभी सॉकेट लिंक्स को बिना किसी अपवाद के हमेशा फुल-डुप्लेक्स पर होना चाहिए।
इसके अलावा, सुनिश्चित करें कि दोनों WAN और LAN लिंक स्पीड एक साइट के लिए कॉन्फ़िगर की गई बैंडविड्थ के बराबर या उससे अधिक है। लिंक की गति थ्रूपुट के लिए सीमाप्रदायक कारक हो सकती है। उदाहरण के लिए, यदि किसी साइट की कॉन्फ़िगर की गई बैंडविड्थ 200 Mbps है लेकिन LAN लिंक केवल 100 Mbps फुल-डुप्लेक्स पर तय है, तो सॉकेट से जुड़े कंप्यूटर 100 Mbps से अधिक थ्रूपुट हासिल नहीं कर सकते।
लिंक स्थिति की जांच करने के लिए, सॉकेट UI में लॉग इन करें और निगरानी पृष्ठ पर लिंक स्थिति देखें नीचे का उदाहरण 100 Mbps आधा-डुप्लेक्स में WAN1 लिंक दिखाता है।
यदि आप आधा-डुप्लेक्स पर या गलत गति पर सेट किए गए लिंक को देखते हैं, तो उस डिवाइस पर पोर्ट सेटिंग्स की जांच करें जिससे सॉकेट का लिंक जुड़ा है। सुनिश्चित करें कि यह ऑटो-नेगोशिएट पर सेट है या यह सॉकेट की गति सेटिंग्स से मेल खाता है। सभी सॉकेट लिंक्स डिफ़ॉल्ट रूप से ऑटो-नेगोशिएट पर सेट होते हैं, लेकिन आप नेटवर्क सेटिंग्स पृष्ठ के तहत गति को मजबूर कर सकते हैं।
यदि अन्य डिवाइस पर पोर्ट सेटिंग्स सही हैं, तो ईथरनेट केबल खराब हो सकता है। केबल को एक अच्छी ज्ञात के साथ बदलें और देखें कि डुप्लेक्स या गति बदलती है या नहीं। यदि वह काम नहीं करता है, तो एक लैपटॉप कंप्यूटर या अन्य डिवाइस को सॉकेट के पोर्ट से जोड़ें और लिंक स्थिति की जांच करें। दूसरे डिवाइस पर भी ऐसा ही करें। यदि सॉकेट का लिंक अपेक्षित गति और फुल-डुप्लेक्स पर आता है लेकिन दूसरे डिवाइस का लिंक नहीं दिखता है, तो आपको पता चल जाएगा कि समस्या दूसरे डिवाइस में है।
17. डुप्लिकेट IP के लिए जाँच कर रहा है
नेटवर्क में डुप्लिकेट IPs सॉकेट स्तर पर पैकेट हानि का कारण बनने वाली एक और समस्या है। सॉकेट आमतौर पर इसके कॉन्फ़िगर किए गए इंटरफेस IP पतों के साथ IP संघर्ष को पहचान सकता है। जब एक ही नेटवर्क के दो उपकरणों को एक ही आईपी पता सौंपा जाता है, तो आईपी संघर्ष मौजूद होता है। यदि ऐसा होता है, तो आप सॉकेट UI के मॉनिटर पेज पर निम्नलिखित त्रुटि देखेंगे।
जब WAN इंटरफेस पर स्थिर IP पता कॉन्फ़िगर किया जाता है, तो डुप्लिकेट IP का पता लगाना विफल हो सकता है, क्योंकि सॉकेट केवल निष्क्रिय रूप से IP संघर्ष की निगरानी करता है। यह केवल तब IP संघर्ष का पता लगाएगा जब सॉकेट संघर्षरत IP वाले डिवाइस से एक ARP प्राप्त करता है।
एक बार जब संघर्षरत IP मुद्दा हल हो जाता है, चेतावनी के WebUI से गायब होने में 24 घंटे तक का समय लग सकता है। देखें यहां तक कि हल होने के बाद भी सॉकेट UI पर रिपोर्ट किया गया IP पता संघर्ष।
18. माइक्रो-विस्फोट के लिए जाँच कर रहा है
पैकेट हानि का एक और संभावित कारण माइक्रो-बर्स्ट (विस्फोटकता) है। माइक्रो-बर्स्ट की विशेषता पैकेट या डेटा फ्रेम के अचानक वृद्धि से होती है जो बहुत ही छोटे समय सीमा में होती है, आमतौर पर केवल कुछ माइक्रोसेकंड से मिलीसेकंड तक चलती है। उन परिस्थितियों में जहां माइक्रो-बर्स्ट होते हैं और लिंक के दर सीमा को पार करते हैं, अंतिम-मील प्रदाता (ISP) अत्यधिक ट्रैफ़िक को गिरा सकती है, जिससे पैकेट हानि होती है।
नीचे दिए गए ग्राफ में, आप माइक्रो-बर्स्ट के कारण सामान्य पैकेट हानि और विस्फोटकता मूल्य सेटिंग्स समायोजित करने के बाद हुई सुधार को देख सकते हैं।
उपर्युक्त उदाहरण में विस्फोट स्तर का मान डिफ़ॉल्ट मान 0.2 से 0.01 में संशोधित किया गया था जिसका मतलब है कि सॉकेट और PoP ट्रैफ़िक पर अधिक आक्रामक संरचना लागू करते हैं, इस प्रकार पैकेट नुकसान की समस्या का समाधान होता है।
पैकेट हानि को कम करने के लिए विस्फोटकता स्तर की सेटिंग्स को समायोजित करना
अपस्ट्रीम और डाउनस्ट्रीम निर्देशों के लिए लागू डिफ़ॉल्ट विस्फोटकता मान 0.2 है। इस मान के साथ, सॉकेट और PoP पैकेट को मीडिया पर जितनी जल्दी हो सके उनकी क्रमानुसार विधि से अनुरूप करते हैं, जिससे समय अवधि बकेट के पहले माइक्रोसेकेंड में अधिक बाइट्स भेजने की अनुमति मिलती है। यह सेटिंग सीरियलाइजेशन देरी और समग्र विलंबता को कम करके प्रदर्शन को अनुकूलित करती है।
इस समस्या निवारण कदम के भाग के रूप में, आपको पैकेट हानि को कम करने तक विस्फोटकता स्तर को धीरे-धीरे कम करना होगा। जैसे आप विस्फोटकता स्तर का मान कम करते हैं, सॉकेट और PoP ट्रैफ़िक पर अधिक आक्रामक आकार लागू करते हैं, जिससे माइक्रो-बर्स्ट को सुचारू बनाते हैं। सबसे कम मान जो आप कॉन्फ़िगर कर सकते हैं वह 0.001 है।
सर्वश्रेष्ठ अभ्यास के अनुसार, विस्फोट स्तर को समायोजित करने के लिए मूल्य को धीरे-धीरे कम करना है (उदाहरण के लिए, 0.2 से 0.18 तक)। मूल्य को कम करने के बाद, साइट मॉनिटरिंग रियल टाइम या नेटवर्क एनालिटिक्स स्क्रीन में पैकेट नुकसान का विश्लेषण करके प्रभाव की जांच करें। यह ध्यान में रखें कि साइट मेट्रिक्स को अपडेट होने में आमतौर पर कुछ मिनट लगते हैं। पैकेट हानि को कम करने तक विस्फोटकता मान को कम करते रहें।
अगर इस प्रक्रिया से पैकेट नुकसान का समाधान नहीं होता है, तो यह माइक्रो-बर्स्ट्स के अलावा अन्य कारण से हो सकता है। इस मामले में, डिफ़ॉल्ट विस्फोट मूल्य 0.2 को पुनर्स्थापित करें और समर्थन से संपर्क करें आगे की सहायता के लिए।
विस्फोटकता स्तर को बदलना
विस्फोटकता स्तर को अपस्ट्रीम और डाउनस्ट्रीम दिशाओं के लिए समायोजित किया जा सकता है। यह सेटिंग साइट के सभी WAN लिंक को प्रभावित करती है।
कॉन्फ़िगरेशन साइट स्तर या खाता स्तर पर लागू किया जाता है। साइट स्तर की कॉन्फ़िगरेशन को खाता स्तर की तुलना में प्राथमिकता मिलती है।
बर्स्टिनेस स्तर कॉन्फ़िगर करने के लिए:
नेविगेशन मेनू से, खाता स्तर के लिए संसाधन > उन्नत कॉन्फ़िगरेशन या साइट स्तर सेटिंग के लिए साइट कॉन्फ़िगरेशन > उन्नत कॉन्फ़िगरेशन चुनें।
बर्स्टिनेस डाउनस्ट्रीम मान या बर्स्टिनेस अपस्ट्रीम मान चुनें।
सेटिंग सक्षम करें और मान को 0.001 - 0.2 के दायरे के बीच समायोजित करें।
लागू करें क्लिक करें
सहेजें पर क्लिक करें
टिप्पणियाँ.
यदि बर्स्टिनेस को पहले Cato समर्थन द्वारा समायोजित किया गया था, तो समायोजित मान 0.2 के डिफ़ॉल्ट मूल्य के बजाय दिखाया जाएगा
बर्स्टिनेस के मान केवल सॉकेट साइट्स के लिए समायोजित किए जा सकते हैं
Cato प्रबंधन एप्लिकेशन में सबसे छोटा डेटा बकेट 5 सेकंड का है, माइक्रोबर्स्ट्स सबसे छोटे डेटा बकेट में सामान्यीकृत होते हैं और सामान्यतः पहचानने में कठिन होते हैं।
10 Mbps और उससे कम बैंडविड्थ वाली साइटों के लिए विस्फोटकता मान 0.001 को सेट करना अनुशंसित नहीं है, क्योंकि यह साइट के लिए कनेक्टिविटी समस्याएँ उत्पन्न कर सकता है।