Duplexfel på en VPN-gatewayport: läs båda ändarna

En filkopiering genom tunneln stannar i en sekund, fortsätter, och VPN-loggarna visar ingenting. Applikationen skyller på nätet, nätet skyller på applikationen, och switchporten har varit uppe i elva månader. Den här genomgången börjar vid pausen och arbetar sig utåt mot den fysiska länken: vad porten faktiskt gör, vad den bortre änden gör och vad räknarna gjorde medan du tittade. Det är värt att göra innan någon rör en duplexinställning.

Börja vid pausen, inte vid porten

Beskriv symptomet på ett sätt som går att testa. Ett stopp på ungefär en sekund under en massöverföring är ett annat problem än en anslutning som återställs, och en paus som inträffar en gång i timmen skiljer sig från en som inträffar varje par sekunder. Skriv ned arbetsbelastningen, riktningen och det ungefärliga intervallet.

Reproducera det sedan medan du tittar på gränssnittet. Ett fysiskt problem visar sig som rörelse i räknarna under den berörda arbetsbelastningen, och ett problem som inte rör räknarna alls ligger förmodligen ovanför länklagret. Titta i en minut, inte en sekund, eftersom dessa fel ofta behöver ihållande trafik innan de syns. Övervakning i tomgång bevisar ingenting om en länk som bara beter sig illa under belastning.

Det spelar roll eftersom duplexfel har en signatur: fel som bara uppträder under belastning, i trafikens riktning, medan små ping och interaktiva sessioner förblir felfria. Om trafik i tomgång också misslyckas, leta någon annanstans först.

Läs driftläget i båda ändarna

Den sparade konfigurationen är inte driftläget. En port kan vara konfigurerad för autoförhandling och hamna på halv duplex, eller vara konfigurerad till en fast hastighet som den andra änden aldrig accepterade. Läs vad länken gör just nu på båda sidor.

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

Notera hastighet, duplex och om autoförhandling är på, och hämta sedan samma tre fakta från switchen intill eller leverantörens port. En ände ensam säger ingenting, eftersom felet är en relation och inte en inställning. Sätt båda raderna i ärendet bredvid varandra, med tiden du läste dem. Halva värdet av övningen är att ha de två avläsningarna på ett ställe.

Om du inte kan läsa den bortre änden kan du inte diagnostisera detta. Be ägaren om driftläget och räknarna, eller ordna åtkomst innan du börjar ändra din sida.

Hur 10/100-halvduplexfallet ser ut

På 10/100-kopparlänkar kan en autoförhandlande ände upptäcka hastigheten hos en tvingad partner utan att lära sig dess duplexinställning. Parallell detektering bestämmer hastigheten från signalen, och duplex antas i stället för att förhandlas, så ena sidan kan hamna på halv duplex medan den andra kör full.

Ciscos vägledning för autoförhandling förklarar just det fallet. Det är inte ett argument för att stänga av förhandling överallt, och det säger ingenting användbart om gigabitkoppar, där duplex är fast och autoförhandling krävs för att länken överhuvudtaget ska komma upp.

Det observerbara beviset är en blandning av fel som bara finns i en riktning: FCS- eller CRC-fel på full-duplexsidan, kollisioner eller sena kollisioner på halvduplexsidan, och genomströmning som kollapsar under belastning medan latensen är normal i tomgång. Den asymmetrin är signaturen. En länk som bara är överbelastad försämras i båda riktningarna och hela tiden.

Ändra båda ändarna samtidigt, med en väg tillbaka

En duplexkorrigering är en samordnad ändring, inte en lokal. Att tvinga din sida utan att den bortre änden håller med är hur en fungerande länk blir en trasig, och att CLI:t accepterar kommandot bevisar bara att syntaxen var giltig.

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

Innan du kör något sådant, bekräfta att plattformen stöder kombinationen och att den bortre änden ändras i samma fönster. Behåll ett oberoende sätt att administrera enheten, eftersom porten du är på väg att ändra kan vara den som bär din administrationssession.

På många moderna länkar är det rätta svaret att låta autoförhandling vara på i båda ändarna i stället för att tvinga något. Tvingande är ett botemedel mot ett specifikt fel på en specifik teknik, inte en allmän förbättring. Särskilt gigabitkoppar behöver autoförhandling för att länken ska komma upp, så rådet för 10/100 överförs inte.

Bekräfta att räknarna rörde sig till det bättre

Läs efter ändringen driftläget igen i båda ändarna och bekräfta att de stämmer överens. Kör sedan samma arbetsbelastning som gav pausen och jämför räknardifferenser i stället för livstidssummor, eftersom en summa som samlats i ett år inte kan berätta vad som hände de senaste tio minuterna.

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

En länk utan nya fel under samma belastning är det bevis du saknade. En länk som fortfarande får fel, eller en där räknarna aldrig rörde sig, skickar dig till nästa gräns i stället för djupare in i duplexdiskussionen. Båda utfallen är framsteg, vilket är mer än konfigurationsfilen kan ge dig. Hoppa inte över den andra avläsningen för att den första såg rätt ut.

Skriv siffrorna före och efter i ärendet med tidsstämplar. Den registreringen är det som gör «VPN:et känns bättre» till något nästa ingenjör kan bygga vidare på.