Задержка 20–200 мс в 10.0.10.0/24: отделите дуплекс от Wi‑Fi и storm

Короткий ответ

В LAN 10.0.10.0/24 RTT до шлюза 10.0.10.1 должен быть долями миллисекунды на гигабитном меди, единицы мс на загруженном Wi‑Fi. Если ping 10.0.10.1 даёт десятки и сотни мс — это не «провайдер». Разведите: (1) mismatch duplex/speed, (2) радио, (3) storm/петля, (4) узел-назначение задыхается по CPU/очереди, (5) зеркало/SPAN на порту.

Не обновляйте прошивку коммутатора, пока не сняли ping -n 50, статистику NIC и не сравнили кабель vs Wi‑Fi vs другой порт.

Симптомы и как отличить

• ping 10.0.10.1 min/avg/max сильно разъехались (1 / 80 / 400);
• SMB «залипает», голос в LAN рвётся;
• один ПК тормозит, сосед на том же свитче — нет.

Ping до 8.8.8.8 30 мс при ping до 10.0.10.1 0.4 мс — WAN. Обратное — LAN.

Возможные причины

1. 100 Mbps Half Duplex против Full на свитче — коллизии, late collision.
2. Wi‑Fi: помехи, power save, роуминг между точками.
3. Broadcast/multicast storm, петля без STP.
4. CPU 100% на VM/хосте: ICMP обрабатывается медленно, хотя линк гигабит.
5. QoS/шейпер на SVI по ошибке.
6. Старый USB-NIC, EEE (Energy-Efficient Ethernet) баг.
7. Антивирусный инспектор на стеке.
8. Перегруженный vSwitch, coalescing.

Диагностика

1. Базовый RTT до L2/L3 якорей

С проблемного Windows:

Get-NetIPConfiguration
ping -n 50 10.0.10.1
ping -n 50 10.0.10.2
ping -n 20 10.0.10.10
Get-NetAdapter | Format-Table Name, LinkSpeed, FullDuplex, Status

Ubuntu:

ip -br link
ethtool eth0
ping -c 50 10.0.10.1
ping -c 50 10.0.10.2

Снимите те же 50 пингов с соседнего ПК в том же VLAN. Если сосед 0.3 мс, вы 80 мс — проблема на вашем порту/адаптере/Wi‑Fi, не шлюз.

2. Дуплекс и ошибки линка

ethtool eth0
ethtool -S eth0 | grep -Ei 'err|crc|collision|drop|rx_|tx_'

Windows:

Get-NetAdapterStatistics | Format-List *
Get-NetAdapterAdvancedProperty -Name 'Ethernet' | Where-Object DisplayName -Match 'Speed|Duplex|EEE|Offload'

100 Mbps Half при гигабитном свитче — mismatch. CRC растут — кабель, порт, дуплекс.

3. Wi‑Fi vs кабель

Повторите ping на том же ноутбуке по кабелю в порт 10.0.10.0/24. Если кабель 0.4 мс, Wi‑Fi 40–200 мс — радио, не маршрутизация. Смотрите RSSI, канал, band steering. Не «оптимизируйте DNS».

4. Storm и CPU

На шлюзе Ubuntu:

uptime
ss -s
sudo ip -s link
# всплеск RX broadcast:
watch -n 1 'ip -s link show eth0'

На коммутаторе: show interface counters broadcast, CPU. Ping до шлюза высокий у всех — шлюз или шторм. Только у одного — NIC/кабель/Wi‑Fi.

Get-Counter '\Processor(_Total)\% Processor Time'
Get-Process | Sort-Object CPU -Descending | Select-Object -First 8

Высокий CPU + высокий ping на этом хосте при нормальном ping с соседа на этот же IP — очередь/стек назначения.

5. Не виртуализация ли

На VM: сравните ping с гипервизора до 10.0.10.1 и из гостя. Разница — vNIC, balloon, CPU ready. Не путайте с асимметрией.

Решение

Сценарий A. Duplex mismatch

Выставьте оба конца Auto/Auto или явно 1G Full (оба). Не оставляйте на ПК «100 Full», а на свитче Auto — получите half.

После смены:

Restart-NetAdapter -Name 'Ethernet'
Get-NetAdapter
ping -n 20 10.0.10.1

Сценарий B. Wi‑Fi

Фиксируйте 5 ГГц, уберите легаси 2.4 при возможности, проверьте соседние каналы. Временно отключите power save на клиенте для теста (не «навсегда» для всех ноутбуков без оценки батареи).

Сценарий C. Storm

Найдите петлю, включите STP/BPDU guard на access. Не отключайте STP «чтобы заработало быстрее». Порт с петлёй — статья про flapping.

Сценарий D. CPU узла

Снимите лишний процесс, live migration с перегруженного хоста. Не увеличивайте ICMP priority вместо лечения CPU.

Сценарий E. EEE/offload глюк

Отключите EEE на проблемном NIC точечно, проверьте RTT. Если помогло — оставьте изменение задокументированным, не трогайте все серверы сразу.

6. Замер не только ICMP

Высокий ping до 10.0.10.1 при живом TCP ещё не приговор каналу: Windows может деприоритизировать echo. Снимите RTT настоящей сессии:

Test-NetConnection 10.0.10.2 -Port 53
Get-NetTCPConnection -RemoteAddress 10.0.10.2 -ErrorAction SilentlyContinue

На Ubuntu ss -ti dst 10.0.10.1 покажет rtt: и retrans. Если TCP rtt 0.4 ms, а ping 80 ms — копайте ICMP/политику, не duplex. Обратная картина (TCP rtt 80 ms) подтверждает очередь/радио/коллизии. Повторите замер в нерабочее время: ночной RTT в норме, дневной высокий — congestion или бэкап, не «сломанный NIC навсегда». Для Wi‑Fi добавьте RSSI и канал в заявку, иначе эфирные 40 мс будут вечно списывать на шлюз 10.0.10.1.

Как проверить, что проблема устранена

ping -n 50 10.0.10.1
Test-NetConnection 10.0.10.2 -Port 53

ping -c 50 10.0.10.1

Критерий: avg RTT в LAN на меди < 1–2 мс (типично <1), jitter небольшой, потерь 0/50. Пользовательская проверка: RDP/SMB без пауз. Счётчики CRC не растут за 10 минут трафика.

Если не помогло

• Высокий ping только к одному серверу — диск/антивирус на нём, не сеть.
• Только после 17:00 — бэкап/репликация забивает uplink, это congestion; смотрите скорость и QoS.
• Через VPN в ту же подсеть — смотрите MTU и асимметрию, не LAN-коммутатор.
• Jumbo включён на одном конце — симптомы ближе к MTU.

Профилактика

• Autoneg везде, мониторинг CRC и duplex.
• Storm control на access, BPDU guard.
• Отдельный SSID/VLAN, не мешать IoT и corp.
• Алерт: RTT до SVI 10.0.10.1 > N мс с нескольких проб.

FAQ

Почему ping до шлюза 5 мс, а до соседнего ПК 80 мс?

Назначение загружено или путь не прямой (Wi‑Fi isolation, hairpin). Снимите traceroute даже в LAN — иногда пакеты уходят на 10.0.10.1 и обратно из‑за прокси ARP/маски.

Это нормально на виртуалке 2–3 мс?

На том же хосте часто <1 мс. 2–3 мс бывает при noisy neighbor. 50 мс — уже искать CPU ready/диск.

Нужно ли отключать QoS на Windows?

Не глобально. Сначала Get-NetQosPolicy. Если политика режет ICMP/SMB — точечно, не «QoS off forever».

Помогает ли смена DNS снизить ping в LAN?

Нет. DNS не участвует в ping 10.0.10.1. Если «лагает открытие сайтов» — измерьте отдельно DNS и TCP.

Late collision всегда duplex?

Почти всегда mismatch или плохой кабель/хаб. На чистом гигабитном full-duplex late collision не должен быть нормой.