Duplex-eltérés egy VPN-átjáró portján: olvassa el mindkét végét

Egy fájlmásolás az alagúton át egy másodpercre megáll, folytatódik, és a VPN naplói semmit sem mutatnak. Az alkalmazás a hálózatot hibáztatja, a hálózat az alkalmazást, a kapcsolóport pedig tizenegy hónapja üzemel. Ez a végigvezetés a szünetnél kezdődik, és kifelé halad a fizikai kapcsolatig: mit tesz valójában a port, mit tesz a távoli vég, és mit tettek a számlálók, miközben figyelt. Érdemes megtenni, mielőtt bárki hozzányúl egy duplex beállításhoz.

A szünettől induljon, ne a porttól

Írja le a tünetet úgy, hogy tesztelhető legyen. A körülbelül egy másodperces megakadás nagy átvitel közben más probléma, mint az újrainduló kapcsolat, és az óránként egyszer előforduló szünet más, mint a néhány másodpercenkénti. Jegyezze fel a terhelést, az irányt és a hozzávetőleges időközt.

Ezután ismételje meg, miközben a csatolót figyeli. A fizikai probléma a számlálók mozgásaként jelenik meg az érintett terhelés alatt, és az a probléma, amely egyáltalán nem mozdítja meg a számlálókat, valószínűleg a kapcsolati réteg felett van. Egy percig figyeljen, ne egy másodpercig, mert ezek a hibák gyakran tartós forgalmat igényelnek, mielőtt megjelennének. Az üresjárati megfigyelés semmit sem bizonyít egy olyan kapcsolatról, amely csak terhelés alatt viselkedik rosszul.

Ez azért fontos, mert a duplex-eltérésnek jellegzetes nyoma van: csak terhelés alatt, a forgalom irányában megjelenő hibák, miközben a kis pingek és az interaktív munkamenetek hibátlanok maradnak. Ha az üresjárati forgalom is hibázik, először máshol keressen.

Olvassa el az üzemmódot mindkét végén

A mentett konfiguráció nem az üzemállapot. Egy port lehet automatikus egyeztetésre beállítva, és mégis fél duplexre juthat, vagy olyan rögzített sebességre állítva, amelyhez a másik vég soha nem járult hozzá. Olvassa el, mit tesz a kapcsolat jelenleg mindkét oldalon.

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

Jegyezze fel a sebességet, a duplexet és azt, hogy az automatikus egyeztetés be van-e kapcsolva, majd szerezze be ugyanezt a három tényt a szomszédos kapcsolótól vagy a szolgáltató portjától. Egy vég önmagában semmit sem mond, mert az eltérés viszony, nem beállítás. Tegye mindkét sort egymás mellé a jegybe, azzal az időponttal, amikor olvasta őket. A gyakorlat értékének fele az, hogy a két leolvasás egy helyen van.

Ha nem tudja olvasni a távoli véget, nem tudja diagnosztizálni ezt. Kérje meg a tulajdonost az üzemmódra és a számlálókra, vagy intézze el a hozzáférést, mielőtt elkezdi módosítani a saját oldalát.

Hogyan néz ki a 10/100-as fél duplex eset

A 10/100-as rézkábeleken az automatikusan egyeztető végpont képes felismerni a kényszerített partner sebességét anélkül, hogy megtanulná annak duplex beállítását. A párhuzamos felismerés a jelből határozza meg a sebességet, a duplexet pedig egyeztetés helyett feltételezik, így az egyik oldal fél duplexen maradhat, míg a másik teljes duplexen fut.

A Cisco automatikus egyeztetésről szóló útmutatója pontosan ezt az esetet magyarázza. Ez nem érv az egyeztetés mindenhol való kikapcsolására, és semmi hasznosat nem mond a gigabites rézről, ahol a duplex rögzített, és az automatikus egyeztetés szükséges ahhoz, hogy a kapcsolat egyáltalán létrejöjjön.

A megfigyelhető bizonyíték olyan hibák keveréke, amelyek csak egy irányban léteznek: FCS- vagy CRC-hibák a teljes duplex oldalon, ütközések vagy késői ütközések a fél duplex oldalon, és a terhelés alatt összeomló átviteli sebesség, miközben a késleltetés üresjáratban normális marad. Ez az aszimmetria a jellegzetes nyom. Egy egyszerűen túlterhelt kapcsolat mindkét irányban és mindenkor romlik.

Mindkét végét egyszerre módosítsa, visszaúttal

A duplex javítása összehangolt változtatás, nem helyi. A saját oldal kényszerítése a távoli vég egyetértése nélkül az az út, amelyen egy működő kapcsolat elromlottá válik, és az, hogy a CLI elfogadja a parancsot, csak azt bizonyítja, hogy a szintaxis érvényes volt.

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

Mielőtt ilyesmit futtat, győződjön meg arról, hogy a platform támogatja a kombinációt, és hogy a távoli vég ugyanabban az ablakban módosul. Tartson fenn egy független módot az eszköz felügyeletére, mert a port, amelyet módosítani készül, lehet az, amely a felügyeleti munkamenetét szállítja.

Sok modern kapcsolaton a helyes válasz az, hogy mindkét végén bekapcsolva hagyja az automatikus egyeztetést, ahelyett hogy bármit is kényszerítene. A kényszerítés egy adott technológia adott eltérésének ellenszere, nem általános javítás. Különösen a gigabites réznek van szüksége automatikus egyeztetésre, hogy a kapcsolat egyáltalán létrejöjjön, ezért a 10/100-ra vonatkozó tanács nem vihető át.

Győződjön meg róla, hogy a számlálók a jobb irányba mozdultak

A módosítás után olvassa el újra az üzemállapotot mindkét végén, és győződjön meg róla, hogy megegyeznek. Ezután futtassa ugyanazt a terhelést, amely a szünetet okozta, és hasonlítsa össze a számlálók különbségeit, ne az élettartam-összegeket, mert egy éven át halmozódó összeg nem tudja megmondani, mi történt az utolsó tíz percben.

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

Az a kapcsolat, amely ugyanazon terhelés alatt nem mutat új hibákat, az a bizonyíték, amely hiányzott. Az a kapcsolat, amely még mindig hibázik, vagy amelyben a számlálók egyáltalán nem mozdultak, a következő határhoz küldi, nem pedig mélyebbre a duplex-vitába. Mindkét kimenet haladás, ami több annál, amit a konfigurációs fájl adhat. Ne hagyja ki a második leolvasást, mert az első helyesnek tűnt.

Írja be az előtte és utána értékeket a jegybe időbélyegekkel. Ez a feljegyzés az, ami a «a VPN jobbnak tűnik» mondatot olyasmivé alakítja, amire a következő mérnök építhet.