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

Потери — не «сеть плохая», а конкретный участок: клиентский NIC, access-порт, uplink, шлюз 10.0.10.1, WAN, назначение. Снимите ping с достаточным числом пакетов до ближнего якоря (10.0.10.1), до DNS 10.0.10.2, до цели, затем tracert/traceroute. Hop, начиная с которого появляются * * * и растёт loss до цели — кандидат. Не путайте ICMP rate-limit на промежуточном маршрутизаторе с drop полезного TCP.

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

  • Sent = 100, Lost = 12 (12%) до соседа;
  • голос/RDP с артефактами;
  • SMB копирует, скорость пилит зубцами.

Отличия:

  • RTT высокий, потерь 0 — задержка.
  • Только крупные пакеты — MTU.
  • Порт мигает — flapping.
  • Только TCP 443, ping 0% loss — фильтр, не loss канала; пинг vs сайт.

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

  1. Плохой кабель, CRC, дуплекс.
  2. Wi‑Fi помехи, roaming.
  3. Перегрузка порта/uplink, tail drop.
  4. Storm control режет легитимный flood.
  5. ACL/firewall drop (выглядит как loss).
  6. Микрофлап линка.
  7. Баг offload/VMXNET.
  8. Полисер на SVI.

Диагностика

1. Три якоря, много пакетов

С Windows-клиента 10.0.10.10:

ping -n 100 10.0.10.1
ping -n 100 10.0.10.2
ping -n 100 10.0.20.10
Get-NetAdapterStatistics
ping -c 100 10.0.10.1
ping -c 100 10.0.10.2
ping -c 100 -s 1200 10.0.10.1

Интерпретация:

  • Loss до 10.0.10.1 — L2/L3 до шлюза (кабель, VLAN, сам шлюз).
  • До шлюза 0%, до удалённой сети есть — дальше шлюза: маршрут, NAT, WAN.
  • До шлюза 0%, до 10.0.10.2 есть — порт/хост DNS, не вся LAN.

2. Hop за hop

tracert -d 10.0.20.10
Test-NetConnection 10.0.20.10 -TraceRoute
traceroute -n 10.0.20.10
mtr -n -c 50 10.0.20.10

mtr/WinMTR удобнее одноразового traceroute: виден loss на каждом хопе. Помните: потеря только на промежуточном hop при 0% на последующих — часто ICMP limit, не drop транзита. Смотрите loss на последнем хопе и на TCP.

3. Не только ICMP

Test-NetConnection 10.0.20.10 -Port 445
Get-NetTCPConnection -RemoteAddress 10.0.20.10 -ErrorAction SilentlyContinue
ss -ti dst 10.0.20.10
# retrans, rtt

На Ubuntu-сервере: nstat / netstat -s | retrans. Потери ICMP 0 при TCP retrans — очередь/ACL приложения или PMTUD.

4. Направления

С обеих сторон: A→B и B→A. Односторонние потери — асимметрия или firewall на обратном пути.

5. Счётчики порта

CRC, input errors, output drops на access и uplink. Растут output drops — перегруз, не «битый диск клиента».

Решение

Сценарий A. Loss до 10.0.10.1

Кабель, порт, NIC, VLAN. Смените порт и патч-корд по одному изменению. Проверьте storm/flap.

Сценарий B. Loss только за шлюзом

Смотрите WAN/IPsec, очереди NAT, политику. Не трогайте LAN-коммутатор.

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

Сравните с кабелем. Если кабель 0% — не обновляйте ядро «от потерь». Точка, канал, мощность, резай клиент isolation.

Сценарий D. ACL

Явный deny в логе firewall совпадает с «loss». Разрешите нужный протокол, не ICMP any.

Сценарий E. Перегруз

Расширьте uplink, ограничьте бэкап, включите разумный QoS. Не «отключайте контроль потока навсегда» без замера.

6. Воспроизводимый стенд hop-by-hop

Потери нельзя закрыть фразой «пинг плавает». Зафиксируйте три якоря из одной консоли без смены ПК: 10.0.10.1, 10.0.10.2, цель. Для каждого — не меньше 100 ICMP и один TCP-порт, который реально нужен (445, 443, 3389). Если до шлюза 0%, до DNS 8% — не меняйте патч-корд пользователя, идите на порт/хост 10.0.10.2. Если оба якоря чистые, а до 10.0.20.10 loss — смотрите uplink и NAT, не access.

На Ubuntu добавьте mtr -n -c 100 и сохраните. Windows-аналог — pathping -n -q 50 10.0.20.10, понимая, что он медленный и тоже ICMP. Параллельно Get-NetNeighbor / ip neigh: при flap ARP потери выглядят как «сеть моргает», хотя это соседство. Сравните направление A→B и B→A теми же числами пакетов. Односторонние 12% при обратных 0% почти никогда не «плохой кабель в одну сторону»: это ACL, uRPF, асимметрия или Wi‑Fi isolation.

Не запускайте одновременно iperf saturating и ping-тест на том же 1G, если хотите увидеть скрытые потери: вы сами создадите tail drop. Сначала idle-замер, потом нагрузка как отдельный шаг. В заявке: проценты, размер пакета, DF или нет, время суток, провод или эфир. Иначе следующий инженер начнёт сначала.

Типичная ловушка: traceroute показывает 100% на hop 2, ping до цели 0% loss. Это ICMP rate-limit. Не меняйте «второй маршрутизатор», пока TCP до цели чистый. Другая ловушка: 1% loss в LAN на меди — уже много для SMB; не списывайте на «шум ICMP».

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

ping -n 200 10.0.10.1
ping -n 200 10.0.20.10
tracert -d 10.0.20.10
ping -c 200 10.0.10.1
mtr -n -c 100 10.0.20.10

0% (или согласованный SLA, например <0.1%) на якорях, TCP-сессия без разрывов 10 минут, счётчики errors не растут. Повторите в прайм-тайм.

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

  • Потери кратны 30–60 с — STP reconvergence / flapping.
  • Только jumbo — MTU.
  • Только к Windows с включённым rate-limit ICMP — измерьте TCP.
  • Кластер: VIP плавает, ARP не обновился — ARP.

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

  • Мониторинг loss до SVI и до ключевых серверов TCP, не один ping.
  • Пороги CRC.
  • Не смешивать backup VLAN с пользовательским на тонком uplink без QoS.
  • Документировать, где ICMP фильтруется.

FAQ

2% loss в ping — это плохо для SMB?

Да, SMB/TCP будет ретрансмитить. Для голоса ещё хуже. 0% в LAN — нормальная цель на меди.

Почему traceroute показывает * , а сайт открывается?

Промежуточный хоп не отвечает на TTL-expired, транзит жив. Смотрите последний хоп и TCP.

ping -l 65500 для проверки потерь?

Бессмысленно и вредно. Используйте 32–1472 с DF для MTU, для loss — обычный размер и много пакетов.

Можно ли игнорировать потери до шлюза, если интернет есть?

Нет. Это деградация LAN; интернет может идти через Wi‑Fi/другую сеть. Чините якорь.

Windows пишет Destination host unreachable, не timeout. Это loss?

Unreachable — ICMP от кого-то (часто свой стек: нет ARP). Timeout — тишина. Это разные ветки: ARP/маршрут vs drop/фильтр.