Dupleks-uoverenskomst på ein VPN-gatewayport: les båe endar

Ein filkopi gjennom tunnelen stoppar i eitt sekund, held fram, og VPN-loggene viser ingenting. Applikasjonen gjev nettet skulda, nettet gjev applikasjonen skulda, og svitsjporten har vore oppe i elleve månader. Denne gjennomgangen byrjar ved pausen og arbeider seg utover mot den fysiske lenkja: kva porten faktisk gjer, kva den fjerne enden gjer, og kva teljarane gjorde medan du såg på. Det er verd å gjere dette før nokon rører ein dupleksinnstilling.

Start ved pausen, ikkje ved porten

Skildre symptomet på ein måte som kan testast. Eit stopp på kring eitt sekund under ein masseoverføring er eit anna problem enn ei tilkopling som nullstiller seg, og ein pause som skjer ein gong i timen er annleis enn ein som skjer kvart par sekund. Skriv ned arbeidslasta, retninga og det omtrentlege intervallet.

Reproduser det deretter medan du ser på grensesnittet. Eit fysisk problem viser seg som rørsle i teljarane under den råka arbeidslasta, og eit problem som slett ikkje flyttar teljarane ligg truleg over lenkjelaget. Sjå i eitt minutt, ikkje eitt sekund, fordi desse feila ofte treng vedvarande trafikk før dei viser seg. Overvaking i tomgang provar ingenting om ei lenkje som berre oppfører seg dårleg under last.

Dette er viktig fordi dupleks-uoverenskomst har ein signatur: feil som berre dukkar opp under last, i retninga av trafikken, medan små ping og interaktive økter held seg perfekte. Viss trafikk i tomgang òg feilar, sjå ein annan stad først.

Les driftstilstanden i båe endar

Den lagra konfigurasjonen er ikkje driftstilstanden. Ein port kan vere konfigurert for autoforhandling og enda på halv dupleks, eller vere konfigurert til ein fast fart som den andre enden aldri godtok. Les kva lenkja gjer akkurat no på båe sider.

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

Noter fart, dupleks og om autoforhandling er slått på, og hent deretter dei same tre fakta frå svitsjen ved sida av eller porten til leverandøren. Éin ende åleine seier ingenting, fordi uoverenskomsten er eit tilhøve og ikkje ei innstilling. Set båe radene i saka ved sida av kvarandre, med tida du las dei. Helvta av verdien av øvinga er å ha dei to avlesingane på éin stad.

Viss du ikkje kan lese den fjerne enden, kan du ikkje diagnostisere dette. Be eigaren om driftstilstanden og teljarane, eller ordne tilgang før du byrjar å endre di side.

Korleis 10/100-halvduplekstilfellet ser ut

På 10/100-koparlenkjer kan eit autoforhandlande endepunkt oppdage farten til ein tvinga partnar utan å lære dupleksinnstillinga hans. Parallell deteksjon avgjer farten frå signalet, og dupleks vert anteke i staden for forhandla, så den eine sida kan enda på halv dupleks medan den andre køyrer full.

Ciscos rettleiding for autoforhandling forklarer nettopp det tilfellet. Det er ikkje eit argument for å slå av forhandling overalt, og det seier ingenting nyttig om gigabit-kopar, der dupleks er fast og autoforhandling er naudsynt for at lenkja i det heile skal kome opp.

Det observerande beviset er ei blanding av feil som berre finst i éi retning: FCS- eller CRC-feil på full-duplekssida, kollisjonar eller seine kollisjonar på halvduplekssida, og gjennomstrøyming som kollapsar under last medan latensen er normal i tomgang. Den asymmetrien er signaturen. Ei lenkje som berre er overlasta, forverrar seg i båe retningar og til alle tider.

Endre båe endar samstundes, med ein veg tilbake

Ein duplekskorreksjon er ei koordinert endring, ikkje ei lokal. Å tvinge di side utan at den fjerne enden er samd, er måten ei fungerande lenkje vert ei øydelagd ei, og at CLI-en godtek kommandoen provar berre at syntaksen var gyldig.

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

Før du køyrer noko slikt, stadfest at plattforma støttar kombinasjonen og at den fjerne enden vert endra i same vindauget. Hald på ein uavhengig måte å administrere eininga på, fordi porten du er i ferd med å endre kan vere den som ber administrasjonsøkta di.

På mange moderne lenkjer er det rette svaret å la autoforhandling vere slått på i båe endar i staden for å tvinge noko. Tvang er ei kur mot ein bestemd uoverenskomst på ein bestemd teknologi, ikkje ei generell betring. Særleg gigabit-kopar treng autoforhandling for at lenkja skal kome opp, så rådet for 10/100 vert ikkje overført.

Stadfest at teljarane rørte seg til det betre

Etter endringa, les driftstilstanden på nytt i båe endar og stadfest at dei er samde. Køyr deretter den same arbeidslasta som gav pausen, og samanlikn teljeforskjellar i staden for levetidstotalar, fordi ein total som har samla seg i eitt år ikkje kan fortelje deg kva som skjedde dei siste ti minutta.

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

Ei lenkje utan nye feil under same last er beviset du mangla. Ei lenkje som framleis feilar, eller ei der teljarane aldri rørte seg, sender deg til neste grense i staden for djupare ned i dupleksdiskusjonen. Båe utfall er framgang, som er meir enn konfigurasjonsfila kan gje deg. Ikkje hopp over den andre avlesinga fordi den første såg rett ut.

Skriv tala før og etter i saka med tidsstempel. Den registreringa er det som gjer «VPN-en kjennest betre» til noko den neste ingeniøren kan byggje vidare på.