Dupleks-uoverensstemmelse på en VPN-gatewayport: les begge ender

En filkopi gjennom tunnelen stopper i et sekund, fortsetter, og VPN-loggene viser ingenting. Applikasjonen gir nettverket skylden, nettverket gir applikasjonen skylden, og svitsjporten har vært oppe i elleve måneder. Denne gjennomgangen starter ved pausen og arbeider seg utover mot den fysiske linken: hva porten faktisk gjør, hva den fjerne enden gjør, og hva tellerne gjorde mens du så på. Det er verdt å gjøre før noen rører en dupleksinnstilling.

Start ved pausen, ikke ved porten

Beskriv symptomet på en måte som kan testes. Et stopp på rundt ett sekund under en masseoverføring er et annet problem enn en tilkobling som nullstilles, og en pause som skjer én gang i timen er forskjellig fra en som skjer hvert par sekunder. Skriv ned arbeidsbelastningen, retningen og det omtrentlige intervallet.

Reproduser det deretter mens du ser på grensesnittet. Et fysisk problem viser seg som bevegelse i tellerne under den berørte arbeidsbelastningen, og et problem som slett ikke flytter tellerne ligger sannsynligvis over lenkelaget. Se i ett minutt, ikke ett sekund, fordi disse feilene ofte trenger vedvarende trafikk før de vises. Overvåking i tomgang beviser ingenting om en link som bare oppfører seg dårlig under belastning.

Dette er viktig fordi dupleks-uoverensstemmelser har en signatur: feil som bare oppstår under belastning, i trafikkens retning, mens små ping og interaktive økter forblir perfekte. Hvis trafikk i tomgang også feiler, se et annet sted først.

Les driftstilstanden i begge ender

Den lagrede konfigurasjonen er ikke driftstilstanden. En port kan være konfigurert for autoforhandling og ende på halv dupleks, eller være konfigurert til en fast hastighet som den andre enden aldri godtok. Les hva linken gjør akkurat nå på begge sider.

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

Noter hastighet, dupleks og om autoforhandling er slått på, og hent deretter de samme tre fakta fra svitsjen ved siden av eller leverandørens port. Én ende alene sier ingenting, fordi uoverensstemmelsen er et forhold og ikke en innstilling. Sett begge radene i saken ved siden av hverandre, med tiden du leste dem. Halve verdien av øvelsen er å ha de to avlesningene på ett sted.

Hvis du ikke kan lese den fjerne enden, kan du ikke diagnostisere dette. Be eieren om driftstilstanden og tellerne, eller ordne tilgang før du begynner å endre din side.

Hvordan 10/100-halvduplekstilfellet ser ut

På 10/100-kobberlinker kan et autoforhandlende endepunkt oppdage hastigheten til en tvunget partner uten å lære dupleksinnstillingen dens. Parallell deteksjon bestemmer hastigheten fra signalet, og dupleks antas i stedet for å forhandles, så den ene siden kan ende på halv dupleks mens den andre kjører full.

Ciscos veiledning for autoforhandling forklarer nettopp det tilfellet. Det er ikke et argument for å slå av forhandling overalt, og det sier ingenting nyttig om gigabit-kobber, der dupleks er fast og autoforhandling er nødvendig for at linken i det hele tatt skal komme opp.

Det observerbare beviset er en blanding av feil som bare finnes i én retning: FCS- eller CRC-feil på full-duplekssiden, kollisjoner eller sene kollisjoner på halvduplekssiden, og gjennomstrømning som kollapser under belastning mens latensen er normal i tomgang. Den asymmetrien er signaturen. En link som bare er overbelastet, forringes i begge retninger og til alle tider.

Endre begge ender samtidig, med en vei tilbake

En duplekskorreksjon er en koordinert endring, ikke en lokal. Å tvinge din side uten at den fjerne enden er enig, er måten en fungerende link blir en ødelagt en, og at CLI-en godtar kommandoen beviser bare at syntaksen var gyldig.

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

Før du kjører noe slikt, bekreft at plattformen støtter kombinasjonen og at den fjerne enden blir endret i samme vindu. Behold en uavhengig måte å administrere enheten på, fordi porten du er i ferd med å endre kan være den som bærer administrasjonsøkten din.

På mange moderne linker er det riktige svaret å la autoforhandling være slått på i begge ender i stedet for å tvinge noe. Tvang er en kur mot en bestemt uoverensstemmelse på en bestemt teknologi, ikke en generell forbedring. Spesielt gigabit-kobber trenger autoforhandling for at linken skal komme opp, så rådet for 10/100 overføres ikke.

Bekreft at tellerne beveget seg til det bedre

Etter endringen, les driftstilstanden på nytt i begge ender og bekreft at de er enige. Kjør deretter den samme arbeidsbelastningen som ga pausen, og sammenlign tellerforskjeller i stedet for levetidstotaler, fordi en total som har samlet seg i ett år ikke kan fortelle deg hva som skjedde de siste ti minuttene.

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

En link uten nye feil under samme belastning er beviset du manglet. En link som fortsatt feiler, eller en der tellerne aldri beveget seg, sender deg til neste grense i stedet for dypere ned i dupleksdiskusjonen. Begge utfall er fremgang, som er mer enn konfigurasjonsfilen kan gi deg. Ikke hopp over den andre avlesningen fordi den første så riktig ut.

Skriv tallene før og etter i saken med tidsstempler. Den registreringen er det som gjør «VPN-en føles bedre» til noe den neste ingeniøren kan bygge videre på.