Neshoda duplexu na portu VPN brány: čtěte oba konce

Kopírování souboru tunelem na sekundu zamrzne, pokračuje a záznamy VPN nic neukazují. Aplikace viní síť, síť viní aplikaci a port přepínače je zapnutý už jedenáct měsíců. Tento rozbor začíná u pauzy a jde směrem k fyzickému spoji: co port skutečně dělá, co dělá vzdálený konec a co dělaly čítače, když jste se dívali. Stojí za to to udělat, než se někdo dotkne nastavení duplexu.

Začněte u pauzy, ne u portu

Popište symptom tak, aby se dal testovat. Zaseknutí kolem sekundy při hromadném přenosu je jiný problém než spojení, které se resetuje, a pauza jednou za hodinu je jiná než ta, která nastává každých několik sekund. Zapište zátěž, směr a přibližný interval.

Potom to zopakujte, zatímco sledujete rozhraní. Fyzický problém se projeví jako pohyb čítačů během postižené zátěže a problém, který vůbec nepohne čítači, je pravděpodobně nad vrstvou spoje. Sledujte minutu, ne sekundu, protože tyto závady často potřebují trvalý provoz, než se objeví. Monitorování v klidu nic nedokazuje o spoji, který se chová špatně jen pod zátěží.

To je důležité, protože neshoda duplexu má podpis: chyby, které se objevují jen pod zátěží, ve směru provozu, zatímco malé pings a interaktivní relace zůstávají bezchybné. Pokud selhává i provoz v klidu, hledejte nejdřív jinde.

Přečtěte provozní režim na obou koncích

Uložená konfigurace není provozní stav. Port může být nakonfigurován pro automatické vyjednávání a skončit v polovičním duplexu, nebo být nakonfigurován na pevnou rychlost, se kterou druhý konec nikdy nesouhlasil. Přečtěte, co spoj právě teď dělá na obou stranách.

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

Zapište rychlost, duplex a zda je zapnuté automatické vyjednávání, a pak získejte stejné tři údaje od sousedního přepínače nebo portu poskytovatele. Jeden konec sám o sobě nic neříká, protože neshoda je vztah, ne nastavení. Dejte oba řádky do tiketu vedle sebe, s časem, kdy jste je četli. Polovina hodnoty cvičení je mít obě čtení na jednom místě.

Pokud nemůžete přečíst vzdálený konec, nemůžete to diagnostikovat. Požádejte vlastníka o provozní režim a čítače, nebo si před začátkem změn na své straně zajistěte přístup.

Jak vypadá případ 10/100 v polovičním duplexu

Na měděných spojích 10/100 může koncový bod s automatickým vyjednáváním zjistit rychlost vynuceného protějšku, aniž by se dozvěděl jeho nastavení duplexu. Paralelní detekce určí rychlost ze signálu a duplex se předpokládá místo vyjednávání, takže jedna strana může skončit v polovičním duplexu, zatímco druhá běží na plný.

Cisco pokyny k automatickému vyjednávání vysvětlují právě tento případ. Není to argument pro vypnutí vyjednávání všude a neříká nic užitečného o gigabitové mědi, kde je duplex pevný a automatické vyjednávání je nutné, aby spoj vůbec vznikl.

Pozorovatelný důkaz je směs chyb, které existují jen v jednom směru: chyby FCS nebo CRC na straně plného duplexu, kolize nebo pozdní kolize na straně polovičního duplexu a propustnost, která se pod zátěží zhroutí, zatímco latence zůstává v klidu normální. Tato asymetrie je podpis. Spoj, který je jen přetížený, degraduje v obou směrech a po celou dobu.

Měňte oba konce společně, s cestou zpět

Oprava duplexu je koordinovaná změna, ne místní. Vynucení své strany bez souhlasu vzdáleného konce je způsob, jak se funkční spoj stane nefunkčním, a to, že CLI příkaz přijme, dokazuje jen to, že syntaxe byla platná.

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

Než něco takového spustíte, potvrďte, že platforma tuto kombinaci podporuje a že vzdálený konec bude změněn ve stejném okně. Zachovejte nezávislý způsob správy zařízení, protože port, který se chystáte změnit, může být právě ten, který nese vaši řídicí relaci.

Na mnoha moderních spojích je správnou odpovědí nechat automatické vyjednávání zapnuté na obou koncích, místo aby se něco vynucovalo. Vynucení je lék na konkrétní neshodu u konkrétní technologie, ne obecné zlepšení. Právě gigabitová měď potřebuje automatické vyjednávání, aby spoj vůbec vznikl, takže rada pro 10/100 se sem nepřenáší.

Potvrďte, že se čítače pohnuly k lepšímu

Po změně znovu přečtěte provozní stav na obou koncích a potvrďte, že si odpovídají. Potom spusťte stejnou zátěž, která vyvolala pauzu, a porovnejte rozdíly čítačů, ne celkové součty za celou dobu, protože součet, který se hromadí rok, vám neřekne, co se stalo v posledních deseti minutách.

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

Spoj bez nových chyb při stejné zátěži je důkaz, který vám chyběl. Spoj, který stále chybuje, nebo ten, kde se čítače vůbec nepohnuly, vás pošle k další hranici, místo hlouběji do hádky o duplexu. Oba výsledky jsou pokrok, což je víc, než vám konfigurační soubor může dát. Nepřeskakujte druhé čtení proto, že první vypadalo správně.

Zapište čísla před a po do tiketu s časovými značkami. Právě tento záznam mění «VPN je cítit lépe» v něco, na čem může další inženýr stavět.