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 વધુ સારું લાગે છે» ને એવી વસ્તુમાં ફેરવે છે જેના પર આગલો એન્જિનિયર બાંધી શકે.