Dupleks-wanverhouding op 'n VPN-gatewaypoort: lees beide kante

'n Lêerkopie deur die tonnel staak vir 'n sekonde, hervat, en die VPN-logs wys niks. Die toepassing blameer die netwerk, die netwerk blameer die toepassing, en die skakelaarpoort is al elf maande op. Hierdie uiteensetting begin by die pouse en werk uitwaarts na die fisiese skakel: wat die poort werklik doen, wat die verre kant doen, en wat die tellers gedoen het terwyl jy gekyk het. Dit is die moeite werd om dit te doen voordat iemand aan 'n dupleksinstelling raak.

Begin by die pouse, nie by die poort nie

Beskryf die simptoom op 'n manier wat getoets kan word. 'n Staking van ongeveer 'n sekonde tydens groot oordrag is 'n ander probleem as 'n verbinding wat herstel, en 'n pouse wat een keer per uur gebeur is anders as een wat elke paar sekondes gebeur. Skryf die werklading, die rigting en die benaderde interval neer.

Reproduseer dit dan terwyl jy die koppelvlak dophou. 'n Fisiese probleem wys as beweging in die tellers tydens die betrokke werklading, en 'n probleem wat geen tellerbeweging hoegenaamd nie veroorsaak, is waarskynlik bo die skakellaag. Kyk vir 'n minuut, nie 'n sekonde nie, want hierdie foute het dikwels volgehoue verkeer nodig voordat hulle verskyn. Ledige monitering bewys niks oor 'n skakel wat net onder las verkeerd optree nie.

Dit maak saak omdat dupleks-wanverhoudings 'n kenmerk het: foute wat net onder las verskyn, in die rigting van die verkeer, terwyl klein pings en interaktiewe sessies perfek bly. As ledige verkeer ook faal, kyk eers elders.

Lees die operasionele modus aan beide kante

Die gestoorde konfigurasie is nie die operasionele toestand nie. 'n Poort kan vir outonegotiasie gekonfigureer wees en op half-dupleks beland, of vir 'n vaste spoed gekonfigureer wees wat die ander kant nooit aanvaar het nie. Lees wat die skakel tans aan beide kante doen.

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

Teken spoed, dupleks en of outonegotiasie aan is op, en kry dan dieselfde drie feite by die aangrensende skakelaar- of verskafferpoort. Een kant alleen sê niks, want die wanverhouding is 'n verhouding eerder as 'n instelling. Sit beide rye in die kaartjie langs mekaar, met die tyd toe jy dit gelees het. Die helfte van die waarde van die oefening is om die twee lesings op een plek te hê.

As jy nie die verre kant kan lees nie, kan jy dit nie diagnoseer nie. Vra die eienaar vir die operasionele modus en die tellers, of reël toegang voordat jy jou kant begin verander.

Hoe die 10/100 half-dupleksgeval lyk

Op 10/100 koperverbindings kan 'n outonegotiërende eindpunt die spoed van 'n geforseerde eweknie opspoor sonder om sy dupleksinstelling te leer. Parallelle opsporing bepaal die spoed uit die sein, en dupleks word aangeneem eerder as onderhandel, so een kant kan op half-dupleks beland terwyl die ander op volle dupleks werk.

Cisco se outonegotiasie-riglyne verduidelik daardie spesifieke geval. Dit is nie 'n argument om onderhandeling oral af te skakel nie, en dit sê niks nuttigs oor gigabit-koper nie, waar dupleks vas is en outonegotiasie nodig is vir die skakel om hoegenaamd op te kom.

Die waarneembare bewyse is 'n mengsel van foute wat net in een rigting bestaan: FCS- of CRC-foute aan die vol-duplekskant, botsings of laat botsings aan die half-duplekskant, en deurset wat onder las ineenstort terwyl latensie normaal bly wanneer dit ledig is. Daardie asimmetrie is die kenmerk. 'n Skakel wat bloot oorbesoek is, verswak in beide rigtings en te alle tye.

Verander beide kante saam, met 'n pad terug

'n Dupleksregstelling is 'n gekoördineerde verandering, nie 'n plaaslike een nie. Om jou kant te forseer sonder dat die verre kant instem, is hoe 'n werkende skakel 'n gebreekte een word, en die feit dat die CLI die opdrag aanvaar bewys net dat die sintaks geldig was.

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

Voordat jy iets soos dit hardloop, bevestig dat die platform die kombinasie ondersteun en dat die verre kant in dieselfde venster verander sal word. Bewaar 'n onafhanklike manier om die toestel te administreer, want die poort wat jy op die punt is om te verander, is dalk die een wat jou bestuursessie dra.

Op baie moderne skakels is die korrekte antwoord om outonegotiasie aan beide kante geaktiveer te laat eerder as om enigiets te forseer. Forseering is 'n middel vir 'n spesifieke wanverhouding op 'n spesifieke tegnologie, nie 'n algemene verbetering nie. Veral gigabit-koper het outonegotiasie nodig om die skakel hoegenaamd op te bring, so die 10/100-advies dra nie oor nie.

Bevestig die tellers het ten goede beweeg

Lees ná die verandering die operasionele toestand aan beide kante weer en bevestig dat hulle ooreenstem. Hardloop dan dieselfde werklading wat die pouse veroorsaak het en vergelyk tellerverskille eerder as lewenslange totale, want 'n totaal wat 'n jaar lank opgebou het, kan jou nie sê wat in die laaste tien minute gebeur het nie.

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

'n Skakel met geen nuwe foute onder dieselfde las is die bewys wat jy gemis het. 'n Skakel wat nog steeds foute gee, of een waar die tellers van die begin af nooit beweeg het nie, stuur jou na die volgende grens in plaas van dieper in die dupleksargument in. Enige uitkoms is vordering, wat meer is as wat die konfigurasielêer jou kan gee. Moenie die tweede lesing oorslaan omdat die eerste reg gelyk het nie.

Skryf die voor- en na-syfers met tydstempels in die kaartjie. Daardie rekord is wat “die VPN voel beter” verander in iets waarop die volgende ingenieur kan bou.