VPN गेटवे पोर्टवर ड्युप्लेक्स विसंगती: दोन्ही टोके वाचा
वेगावर बोलणी करणारा पण ड्युप्लेक्सवर न करणारा 10/100 पोर्ट लोडखाली त्रुटी निर्माण करतो. दोन्ही टोकांवर कार्यरत मोड वाचा, नंतर वेळेनुसार मोजलेले काउंटर तुलना करा.
टनेलमधून फाइल कॉपी एक सेकंद थांबते, पुन्हा सुरू होते, आणि 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 अधिक चांगले वाटते» याला पुढील अभियंता ज्यावर उभा राहू शकतो अशा गोष्टीत बदलते.