Duplex-mismatch op een VPN-gatewaypoort: lees beide uiteinden

Een bestandskopie door de tunnel stokt een seconde, gaat verder, en de VPN-logs tonen niets. De applicatie geeft het netwerk de schuld, het netwerk geeft de applicatie de schuld, en de switchpoort staat al elf maanden aan. Deze uitleg begint bij de pauze en werkt naar buiten toe naar de fysieke link: wat de poort werkelijk doet, wat de verre kant doet, en wat de tellers deden terwijl u keek. Het is de moeite waard voordat iemand een duplexinstelling aanraakt.

Begin bij de pauze, niet bij de poort

Beschrijf het symptoom op een manier die te testen is. Een onderbreking van ongeveer een seconde tijdens een bulkoverdracht is een ander probleem dan een verbinding die reset, en een pauze die eens per uur optreedt verschilt van een die elke paar seconden optreedt. Noteer de werklast, de richting en het geschatte interval.

Reproduceer het daarna terwijl u de interface bekijkt. Een fysiek probleem uit zich als beweging in de tellers tijdens de getroffen werklast, en een probleem dat helemaal geen tellerbeweging geeft zit waarschijnlijk boven de linklaag. Kijk een minuut, geen seconde, want deze fouten hebben vaak aanhoudend verkeer nodig voordat ze verschijnen. Monitoring in rust bewijst niets over een link die zich alleen onder belasting slecht gedraagt.

Dit is belangrijk omdat duplex-mismatches een signatuur hebben: fouten die alleen onder belasting verschijnen, in de richting van het verkeer, terwijl kleine pings en interactieve sessies perfect blijven. Als verkeer in rust ook mislukt, kijk dan eerst elders.

Lees de operationele modus aan beide uiteinden

De opgeslagen configuratie is niet de operationele toestand. Een poort kan voor autonegotiatie zijn geconfigureerd en op halve duplex uitkomen, of op een vaste snelheid zijn geconfigureerd waarmee de andere kant nooit heeft ingestemd. Lees wat de link op dit moment aan beide kanten doet.

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

Noteer snelheid, duplex en of autonegotiatie aan staat, en haal daarna dezelfde drie feiten bij de aangrenzende switch of providerpoort. Eén uiteinde alleen zegt niets, want de mismatch is een relatie en geen instelling. Zet beide regels naast elkaar in het ticket, met de tijd waarop u ze las. De helft van de waarde van de oefening is dat de twee metingen op één plek staan.

Als u de verre kant niet kunt lezen, kunt u dit niet diagnosticeren. Vraag de eigenaar om de operationele modus en de tellers, of regel toegang voordat u uw kant gaat wijzigen.

Hoe het 10/100-halfduplexgeval eruitziet

Op 10/100-koperlinks kan een autonegotiërend uiteinde de snelheid van een geforceerde partner detecteren zonder de duplexinstelling ervan te leren. Parallelle detectie bepaalt de snelheid uit het signaal, en duplex wordt aangenomen in plaats van onderhandeld, zodat de ene kant op halve duplex kan eindigen terwijl de andere op volledige draait.

Cisco's richtlijn voor autonegotiatie legt precies dat geval uit. Het is geen argument om onderhandeling overal uit te schakelen, en het zegt niets nuttigs over gigabit-koper, waar duplex vastligt en autonegotiatie nodig is om de link überhaupt op te krijgen.

Het waarneembare bewijs is een mengeling van fouten die alleen in één richting bestaan: FCS- of CRC-fouten aan de volledige-duplexkant, botsingen of late botsingen aan de halve-duplexkant, en doorvoer die onder belasting instort terwijl de latentie in rust normaal blijft. Die asymmetrie is de signatuur. Een link die simpelweg overbelast is, verslechtert in beide richtingen en op elk moment.

Wijzig beide uiteinden tegelijk, met een weg terug

Een duplexcorrectie is een gecoördineerde wijziging, geen lokale. Uw kant forceren zonder instemming van de verre kant is hoe een werkende link een kapotte wordt, en dat de CLI het commando accepteert bewijst alleen dat de syntaxis geldig was.

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

Voordat u zoiets uitvoert, bevestig dat het platform de combinatie ondersteunt en dat de verre kant in hetzelfde venster wordt gewijzigd. Houd een onafhankelijke manier om het apparaat te beheren, want de poort die u gaat wijzigen kan degene zijn die uw beheersessie draagt.

Op veel moderne links is het juiste antwoord autonegotiatie aan beide uiteinden aan te laten staan in plaats van iets te forceren. Forceren is een middel tegen een specifieke mismatch op een specifieke technologie, geen algemene verbetering. Vooral gigabit-koper heeft autonegotiatie nodig om de link op te krijgen, dus het advies voor 10/100 gaat niet over.

Bevestig dat de tellers de goede kant op zijn gegaan

Lees na de wijziging de operationele toestand opnieuw aan beide uiteinden en bevestig dat ze overeenkomen. Voer daarna dezelfde werklast uit die de pauze veroorzaakte en vergelijk tellerverschillen in plaats van totalen sinds het begin, want een totaal dat een jaar lang oploopt kan u niet vertellen wat er in de laatste tien minuten is gebeurd.

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

Een link zonder nieuwe fouten onder dezelfde belasting is het bewijs dat u miste. Een link die nog steeds fouten geeft, of een waar de tellers helemaal niet zijn bewogen, stuurt u naar de volgende grens in plaats van dieper in de duplexdiscussie. Beide uitkomsten zijn vooruitgang, wat meer is dan het configuratiebestand u kan geven. Sla de tweede meting niet over omdat de eerste er goed uitzag.

Schrijf de cijfers voor en na met tijdstempels in het ticket. Die registratie is wat «de VPN voelt beter» verandert in iets waarop de volgende engineer kan bouwen.