VPN गेटवे पोर्ट पर डुप्लेक्स बेमेल: दोनों सिरे पढ़ें

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

पोर्ट से नहीं, रुकावट से शुरू करें

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

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

यह मायने रखता है क्योंकि डुप्लेक्स बेमेल की एक पहचान होती है: त्रुटियाँ जो केवल लोड के तहत, ट्रैफ़िक की दिशा में दिखती हैं, जबकि छोटे ping और इंटरैक्टिव सत्र बेदाग रहते हैं। यदि निष्क्रिय ट्रैफ़िक भी विफल हो, तो पहले कहीं और देखें।

दोनों सिरों पर ऑपरेशनल मोड पढ़ें

सहेजा गया कॉन्फ़िगरेशन ऑपरेशनल स्थिति नहीं है। कोई पोर्ट ऑटोनेगोशिएशन के लिए कॉन्फ़िगर होकर आधे डुप्लेक्स पर पहुँच सकता है, या ऐसी निश्चित गति पर कॉन्फ़िगर हो सकता है जिसे दूसरे सिरे ने कभी स्वीकार नहीं किया। पढ़ें कि लिंक अभी दोनों ओर क्या कर रहा है।

ethtool eth0
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0

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

यदि आप दूसरा सिरा नहीं पढ़ सकते, तो आप इसका निदान नहीं कर सकते। मालिक से ऑपरेशनल मोड और काउंटर माँगें, या अपनी ओर बदलना शुरू करने से पहले पहुँच की व्यवस्था करें।

10/100 आधे डुप्लेक्स का मामला कैसा दिखता है

10/100 तांबे के लिंक पर, ऑटोनेगोशिएट करने वाला सिरा बाध्य किए गए साथी की गति का पता लगा सकता है, पर उसकी डुप्लेक्स सेटिंग नहीं सीखता। समानांतर पहचान सिग्नल से गति तय करती है, और डुप्लेक्स बातचीत के बजाय मान लिया जाता है, इसलिए एक ओर आधे डुप्लेक्स पर रह सकती है जबकि दूसरी पूर्ण पर चल रही हो।

Cisco की ऑटोनेगोशिएशन मार्गदर्शिका उस विशिष्ट मामले को समझाती है। यह हर जगह नेगोशिएशन बंद करने का तर्क नहीं है, और गीगाबिट तांबे के बारे में यह कुछ उपयोगी नहीं कहती, जहाँ डुप्लेक्स निश्चित है और लिंक के उठने के लिए ऑटोनेगोशिएशन आवश्यक है।

देखी जा सकने वाली गवाही उन त्रुटियों का मिश्रण है जो केवल एक ही दिशा में होती हैं: पूर्ण डुप्लेक्स वाली ओर FCS या CRC त्रुटियाँ, आधे डुप्लेक्स वाली ओर टकराव या देर से टकराव, और लोड के तहत धराशायी होती थ्रूपुट, जबकि निष्क्रिय अवस्था में विलंब सामान्य रहता है। यही असमानता पहचान है। जो लिंक केवल अधिक भारित है, वह दोनों दिशाओं में और हर समय बिगड़ता है।

दोनों सिरे एक साथ बदलें, वापसी का रास्ता रखते हुए

डुप्लेक्स सुधार एक समन्वित बदलाव है, स्थानीय नहीं। दूसरे सिरे की सहमति के बिना अपनी ओर बाध्य करना वह तरीका है जिससे चलता हुआ लिंक टूटा हुआ बन जाता है, और CLI का कमांड स्वीकार करना केवल यह साबित करता है कि सिंटैक्स मान्य था।

sudo ethtool -s eth0 speed 100 duplex full autoneg off
ethtool eth0

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

कई आधुनिक लिंक पर सही उत्तर यह है कि कुछ भी बाध्य करने के बजाय दोनों सिरों पर ऑटोनेगोशिएशन चालू रहने दें। बाध्य करना किसी विशिष्ट तकनीक पर विशिष्ट बेमेल का उपाय है, सामान्य सुधार नहीं। विशेष रूप से गीगाबिट तांबे को लिंक उठाने के लिए ऑटोनेगोशिएशन चाहिए, इसलिए 10/100 की सलाह वहाँ लागू नहीं होती।

पुष्टि करें कि काउंटर बेहतर की ओर बढ़े

बदलाव के बाद, दोनों सिरों पर ऑपरेशनल स्थिति फिर पढ़ें और पुष्टि करें कि वे सहमत हैं। फिर वही कार्यभार चलाएँ जिसने रुकावट पैदा की थी और जीवनकाल के कुल योग के बजाय काउंटर अंतरों की तुलना करें, क्योंकि एक वर्ष से जमा होता कुल योग आपको नहीं बता सकता कि पिछले दस मिनटों में क्या हुआ।

ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0
ping -f -c 200 10.90.0.1

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

टिकट में टाइमस्टैम्प के साथ पहले और बाद की संख्याएँ लिखें। यही रिकॉर्ड «VPN बेहतर लग रहा है» को ऐसी चीज़ में बदलता है जिस पर अगला इंजीनियर खड़ा हो सके।