केबल को दोष देने से पहले पैकेट लॉस को कैसे पढ़ें

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

एक पर भरोसा करने के बजाय तीन मापों की तुलना करें: प्रोब ने क्या देखा, इंटरफ़ेस काउंटरों ने क्या किया, और ऐप्लिकेशन वास्तव में किसका इंतज़ार कर रहा था।

पिंग प्रतिशत वास्तव में क्या मापता है

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

प्रोब के नतीजे को पथ के बारे में एक संकेत के रूप में रखें। फिर उस समय-निर्धारण और सीमा को खोजें जिसने उसे बनाया।

काउंटर डेल्टा की तुलना करें, आजीवन कुल की नहीं

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

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

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

अगर कोई ड्राइवर विस्तृत भौतिक काउंटर दिखाता है, तो उन्हें उस एडाप्टर के दस्तावेज़ के ज़रिए पढ़ें। दो निर्माताओं में “drop” नाम के हर फ़ील्ड को एक ही अर्थ देना वह तरीका है जिससे सामान्य लेखांकन की विचित्रता हार्डवेयर निदान बन जाती है।

खोया हुआ सेगमेंट लंबा इंतज़ार कैसे बनता है

सेगमेंट खोने के बाद ऐप्लिकेशन एक राउंड ट्रिप से कहीं ज़्यादा देर इंतज़ार कर सकता है। TCP राउंड-ट्रिप समय का अनुमान लगाता है, उस अनुमान से पुनःप्रेषण टाइमर निकालता है और जब पुनःप्रेषण भी विफल हो तो पीछे हटता है, इसलिए गलत पल में खोया एक सेगमेंट किसी अनुरोध को नोटिस करने योग्य अंतराल तक रोक सकता है। यह तंत्र RFC 6298 में निर्दिष्ट है, और यह बताता है कि तुच्छ दिखने वाली लॉस दर भी क्यों महसूस हो सकती है।

हालाँकि हर ठहराव पुनःप्रेषण समय-समाप्ति नहीं है। वही इंतज़ार नाम-समाधान, धीमे सर्वर या विफलता के बाद अपना अनुरोध दोबारा आज़माने वाले ऐप्लिकेशन से आ सकता है। उन मामलों को विफल क्रिया को परिवहन अवलोकनों और टनल के अपने सत्र घटनाओं के साथ संरेखित करके अलग करें। पुनःकनेक्ट के बिना डेटा पथ पर रुकावट नए हैंडशेक और क्रेडेंशियल के आदान-प्रदान से अलग घटना है।

जहाँ कैप्चर की अनुमति है, वहाँ उसे संकीर्ण रखें। आपको यह चाहिए कि अपेक्षित पैकेट या पावतियाँ किसी विशेष सीमा पर रुकती हैं या नहीं, यह तथ्य नहीं कि किसी व्यस्त ट्रेस में कहीं पुनःप्रेषण मौजूद है।

दूसरों को हिलाए बिना एक सीमा बदलें

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

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