Dupleks-uoverensstemmelse på en VPN-gatewayport: læs begge ender

En filkopi gennem tunnelen går i stå et sekund, fortsætter, og VPN-loggen viser intet. Applikationen bebrejder netværket, netværket bebrejder applikationen, og switchporten har været oppe i elleve måneder. Denne gennemgang starter ved pausen og arbejder udad mod det fysiske link: hvad porten faktisk gør, hvad den fjerne ende gør, og hvad tællerne gjorde, mens du så på. Det er værd at gøre, før nogen rører ved en dupleksindstilling.

Start ved pausen, ikke ved porten

Beskriv symptomet på en måde, der kan testes. Et stop på omkring et sekund under en bulkoverførsel er et andet problem end en forbindelse, der nulstilles, og en pause, der sker en gang i timen, er forskellig fra en, der sker hvert par sekunder. Skriv arbejdsbelastningen, retningen og det omtrentlige interval ned.

Reproducér det derefter, mens du ser på interfacet. Et fysisk problem viser sig som bevægelse i tællerne under den berørte arbejdsbelastning, og et problem, der slet ikke flytter tællerne, ligger sandsynligvis over linklaget. Se i et minut, ikke et sekund, fordi disse fejl ofte kræver vedvarende trafik, før de viser sig. Overvågning i tomgang beviser intet om et link, der kun opfører sig dårligt under belastning.

Det er vigtigt, fordi dupleks-uoverensstemmelse har en signatur: fejl, der kun opstår under belastning, i trafikkens retning, mens små pings og interaktive sessioner forbliver perfekte. Hvis trafik i tomgang også fejler, så kig et andet sted først.

Læs driftstilstanden i begge ender

Den gemte konfiguration er ikke driftstilstanden. En port kan være konfigureret til autoforhandling og ende på halv dupleks, eller være konfigureret til en fast hastighed, som den anden ende aldrig accepterede. Læs, hvad linket aktuelt gør på begge sider.

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

Notér hastighed, dupleks og om autoforhandling er slået til, og hent derefter de samme tre fakta fra den tilstødende switch eller udbyderport. Én ende alene siger intet, fordi uoverensstemmelsen er en relation og ikke en indstilling. Sæt begge rækker i sagen ved siden af hinanden, med det tidspunkt, du læste dem. Halvdelen af værdien ved øvelsen er at have de to aflæsninger samme sted.

Hvis du ikke kan læse den fjerne ende, kan du ikke diagnosticere dette. Bed ejeren om driftstilstanden og tællerne, eller arrangér adgang, før du begynder at ændre din side.

Sådan ser 10/100-halvduplekstilfældet ud

På 10/100-kobberlink kan et autoforhandlende endepunkt registrere hastigheden på en tvunget partner uden at lære dens dupleksindstilling. Parallel registrering bestemmer hastigheden ud fra signalet, og dupleks antages i stedet for at blive forhandlet, så den ene side kan ende på halv dupleks, mens den anden kører fuld.

Ciscos vejledning om autoforhandling forklarer netop det tilfælde. Det er ikke et argument for at slå forhandling fra overalt, og det siger intet brugbart om gigabit-kobber, hvor dupleks er fast, og autoforhandling er nødvendig, for at linket overhovedet kommer op.

Det observerbare bevis er en blanding af fejl, der kun findes i én retning: FCS- eller CRC-fejl på fuldduplekssiden, kollisioner eller sene kollisioner på halvduplekssiden, og gennemstrømning, der kollapser under belastning, mens latenstiden er normal i tomgang. Den asymmetri er signaturen. Et link, der blot er overbelastet, forringes i begge retninger og hele tiden.

Ændr begge ender sammen, med en vej tilbage

En dupleksrettelse er en koordineret ændring, ikke en lokal. At tvinge din side uden den fjerne endes accept er måden, hvorpå et fungerende link bliver et ødelagt et, og at CLI'en accepterer kommandoen beviser kun, at syntaksen var gyldig.

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

Før du kører noget af den slags, skal du bekræfte, at platformen understøtter kombinationen, og at den fjerne ende ændres i samme vindue. Bevar en uafhængig måde at administrere enheden på, fordi den port, du er ved at ændre, kan være den, der bærer din administrationssession.

På mange moderne links er det rigtige svar at lade autoforhandling være slået til i begge ender i stedet for at tvinge noget. Tvang er en kur mod en bestemt uoverensstemmelse på en bestemt teknologi, ikke en generel forbedring. Især gigabit-kobber har brug for autoforhandling for at få linket op, så rådet for 10/100 overføres ikke.

Bekræft, at tællerne flyttede sig til det bedre

Efter ændringen skal du læse driftstilstanden igen i begge ender og bekræfte, at de er enige. Kør derefter den samme arbejdsbelastning, der gav pausen, og sammenlign tællerforskelle i stedet for livstidstal, fordi et total, der har hobet sig op i et år, ikke kan fortælle dig, hvad der skete i de sidste ti minutter.

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

Et link uden nye fejl under samme belastning er det bevis, du manglede. Et link, der stadig fejler, eller et hvor tællerne slet ikke flyttede sig, sender dig til den næste grænse i stedet for dybere ned i dupleksdiskussionen. Begge udfald er fremskridt, hvilket er mere, end konfigurationsfilen kan give dig. Spring ikke den anden aflæsning over, fordi den første så rigtig ud.

Skriv tallene før og efter i sagen med tidsstempler. Den registrering er det, der gør «VPN'en føles bedre» til noget, den næste ingeniør kan bygge videre på.