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 राम्रो लाग्छ» लाई अर्को इन्जिनियरले टेक्न सक्ने कुरामा बदल्छ।