Niezgodność duplexu na porcie bramy VPN: przeczytaj oba końce

Kopiowanie pliku przez tunel zatrzymuje się na sekundę, wznawia i logi VPN nic nie pokazują. Aplikacja obwinia sieć, sieć obwinia aplikację, a port przełącznika działa od jedenastu miesięcy. Ten przewodnik zaczyna się od pauzy i wychodzi na zewnątrz do łącza fizycznego: co port naprawdę robi, co robi drugi koniec i co robiły liczniki, kiedy patrzyłeś. Warto to zrobić, zanim ktokolwiek dotknie ustawienia duplexu.

Zacznij od pauzy, nie od portu

Opisz objaw w sposób, który da się sprawdzić. Zatrzymanie na około sekundę podczas masowego transferu to inny problem niż połączenie, które się resetuje, a pauza raz na godzinę różni się od tej co kilka sekund. Zanotuj obciążenie, kierunek i przybliżony interwał.

Następnie odtwórz to, obserwując interfejs. Problem fizyczny objawia się ruchem w licznikach podczas dotkniętego obciążenia, a problem, który w ogóle nie porusza liczników, znajduje się prawdopodobnie powyżej warstwy łącza. Obserwuj minutę, nie sekundę, bo te usterki często wymagają stałego ruchu, zanim się pojawią. Monitoring w spoczynku niczego nie dowodzi o łączu, które źle się zachowuje tylko pod obciążeniem.

To ważne, bo niezgodność duplexu ma sygnaturę: błędy pojawiające się tylko pod obciążeniem, w kierunku ruchu, podczas gdy małe pingi i sesje interaktywne pozostają bezbłędne. Jeśli ruch w spoczynku też zawodzi, najpierw poszukaj gdzie indziej.

Odczytaj tryb pracy na obu końcach

Zapisana konfiguracja nie jest stanem pracy. Port może być skonfigurowany do autonegocjacji i skończyć na połowie duplexu, albo skonfigurowany na stałą prędkość, na którą drugi koniec nigdy się nie zgodził. Odczytaj, co łącze robi teraz po obu stronach.

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

Zapisz prędkość, duplex i to, czy autonegocjacja jest włączona, a następnie pobierz te same trzy fakty z sąsiedniego przełącznika lub portu dostawcy. Jeden koniec sam nic nie mówi, bo niezgodność jest relacją, a nie ustawieniem. Umieść oba wiersze obok siebie w zgłoszeniu, z czasem, w którym je odczytałeś. Połowa wartości tego ćwiczenia to mieć oba odczyty w jednym miejscu.

Jeśli nie możesz odczytać drugiego końca, nie możesz tego zdiagnozować. Poproś właściciela o tryb pracy i liczniki albo zorganizuj dostęp, zanim zaczniesz zmieniać swoją stronę.

Jak wygląda przypadek 10/100 w połowie duplexu

Na łączach miedzianych 10/100 końcówka autonegocjująca może wykryć prędkość wymuszonego partnera, nie poznając jego ustawienia duplexu. Detekcja równoległa określa prędkość z sygnału, a duplex jest zakładany, a nie negocjowany, więc jedna strona może skończyć na połowie duplexu, podczas gdy druga działa na pełnym.

Wytyczne Cisco dotyczące autonegocjacji wyjaśniają właśnie ten przypadek. To nie jest argument za wyłączaniem negocjacji wszędzie i nie mówi nic użytecznego o miedzi gigabitowej, gdzie duplex jest stały, a autonegocjacja jest konieczna, aby łącze w ogóle się podniosło.

Obserwowalny dowód to mieszanka błędów, które istnieją tylko w jednym kierunku: błędy FCS lub CRC po stronie pełnego duplexu, kolizje lub późne kolizje po stronie połowy duplexu oraz przepustowość, która załamuje się pod obciążeniem, podczas gdy opóźnienie pozostaje normalne w spoczynku. Ta asymetria jest sygnaturą. Łącze, które jest po prostu przeciążone, pogarsza się w obu kierunkach i przez cały czas.

Zmień oba końce razem, z drogą powrotną

Korekta duplexu to zmiana skoordynowana, a nie lokalna. Wymuszenie swojej strony bez zgody drugiego końca to sposób, w jaki działające łącze staje się zepsute, a przyjęcie polecenia przez CLI dowodzi tylko, że składnia była poprawna.

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

Zanim uruchomisz coś takiego, potwierdź, że platforma obsługuje tę kombinację i że drugi koniec zostanie zmieniony w tym samym oknie. Zachowaj niezależny sposób administrowania urządzeniem, ponieważ port, który zamierzasz zmienić, może być tym, który przenosi twoją sesję zarządzania.

Na wielu nowoczesnych łączach poprawną odpowiedzią jest pozostawienie autonegocjacji włączonej na obu końcach, zamiast czegokolwiek wymuszać. Wymuszanie jest lekiem na konkretną niezgodność w konkretnej technologii, a nie ogólną poprawą. Zwłaszcza miedź gigabitowa potrzebuje autonegocjacji, aby łącze się podniosło, więc rada dla 10/100 nie przenosi się.

Potwierdź, że liczniki ruszyły na lepsze

Po zmianie odczytaj ponownie stan pracy na obu końcach i potwierdź, że się zgadzają. Następnie uruchom to samo obciążenie, które wywołało pauzę, i porównaj różnice liczników, a nie sumy od początku życia, ponieważ suma narastająca przez rok nie powie ci, co się stało w ostatnich dziesięciu minutach.

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

Łącze bez nowych błędów przy tym samym obciążeniu to dowód, którego ci brakowało. Łącze, które nadal błęduje, albo takie, w którym liczniki w ogóle się nie ruszyły, wysyła cię do następnej granicy, a nie głębiej w spór o duplex. Oba wyniki to postęp, co jest więcej, niż może dać plik konfiguracyjny. Nie pomijaj drugiego odczytu tylko dlatego, że pierwszy wyglądał dobrze.

Zapisz liczby przed i po w zgłoszeniu ze znacznikami czasu. To właśnie ten zapis zamienia «VPN działa lepiej» w coś, na czym następny inżynier może się oprzeć.