Коротко — причин может быть несколько. Часто то, что видно в mtr/trace, выглядит как «потери на магистрали», но истинная причина может быть либо ложной (роутеры ограничивают/деприоритизируют ICMP/TTL‑ответы), либо реальной (перегрузка линков/политики QoS, DDoS, аппаратный/конфигурационный сбой, проблемы в BGP). Ниже — как отличить варианты и что делать дальше.
1) Почему такое может наблюдаться (основные причины)
- Дефолтное ограничение/деприоритизация ICMP и TTL‑ответов: многие ядровые маршрутизаторы отдают приоритет пользовательским потокам и отвечают на ICMP гораздо реже — mtr покажет «потери» на промежуточных хопах, но последняя цель при этом доступна.
- Перегрузка магистральных линков/пиров: если линк между AS12389 и какими‑то пирами/поставщиками перегружен, пакеты действительно будут теряться.
- Политики QoS / полисинг: например, policing на пирах для UDP/ICMP или максимум очередей, в результате — дропы для игровых/реального‑времени потоков.
- DDoS-атаки / всплески трафика: перегрузка CPU/FIB/интерфейсов.
- Аппаратные/ПО‑сбои, неверные конфигурации (напр., фильтры, ошибки ACL, маршрутизация).
- Проблемы BGP (ассиметрия, флапинг, перестановки путей) — может ухудшать доступность/увеличивать задержки.
- Метрологическая погрешность mtr/traceroute при работе через MPLS/VPN и при манипуляциях с TTL.
2) Как быстро понять — реальная потеря или просто ICMP‑artefact
- Проверьте достижимость конечной цели (последний хоп в traceroute). Если последний хоп не теряется, то вероятна деприоритизация ICMP на промежуточных роутерах и реальные TCP/UDP потери могут отсутствовать.
- Если потеря доходит до последнего хопа — это реальная потеря пакетов пользователям.
- Используйте TCP‑traceroute / mtr с TCP‑пакетами на порт, который реально использует приложение:
- mtr -r -c 100 --tcp -P 443 example.com
- traceroute -T -p 80 example.com
Это покажет поведение для TCP (чтобы не обманывало ICMP).
- Сделайте тесты потоков: iperf3 между двумя узлами, hping3 (SYN) или tcping к нужному порту — если теряются TCP‑сессии, проблема реальна.
- Сравните с разными маршрутами/вендорами: запустите тесты с разных провайдеров / VPN — если через VPN (маршрут минует AS12389) всё ок, проблема на стороне MTS.
- Соберите дополнительные данные: время, трассировки, mtr с параметрами (-r -c 100), tcpdump либо PCAP на клиенте (если возможно) — нужны для обращения в техподдержку.
3) Диагностика для провайдера / что полезно собрать перед обращением к MTS
- Полные mtr/traceroute (с tcp), с указанием времени и количества попыток.
- ping/iperf3/hping3 результаты, скриншоты/логи с задержками и потерями.
- IP/AS назначения: исходный IP, целевой IP, AS‑пути (ASPATH).
- Сниффы (pcap) — показывают реальные потери/повторные передачи.
- BGP‑таблица/последние апдейты (если есть) или ссылки на looking‑glass.
- Временные интервалы и частота проблемы (всегда/пиковые часы).
4) Что можно сделать пользователю прямо сейчас
- Попробовать VPN (WireGuard/OpenVPN) — если улучшение, значительная часть проблем на магистрали/пирах.
- Попробовать tcp‑traceroute к игровому серверу/порту, проверить last‑hop loss.
- Связаться с вашим локальным провайдером; попросить их открыть тикет в MTS NOC и приложить собранные логи.
- Для игр/важных сервисов — временно сменить маршрут (VPN/ребалансировка) или попробовать другой DNS/серверы, которые маршрутизируются иначе.
5) Что может и должен сделать оператор (MTS) при реальной проблеме
- Проверить состояние интерфейсов/큐ue/статистику drop на шардах/пирах.
- Проверить CPU/FIB, наличие DDoS/флудов, логи BGP (flap, ASPATH changes).
- Проверить QoS/политики полисинга, конфиги ACL.
- Провести тесты с пирами/IX‑партнёрами, поднять временные фильтры или перераспределить трафик.
- При необходимости — заменить оборудование/патчить ПО и уведомить NOC/клиентов.
6) Как правильно жаловаться/эскалировать
- Прислать в техподдержку MTS (через канал вашего провайдера или их NOC) полные mtr/traceroute, pcap, время/таймзоны, исходный и целевой IP, AS‑пути и указать, что проблема воспроизводится с разных узлов.
- Попросите номер инцидента, и если ответ долгий — требуйте эскалации к NOC/engineers.
Вывод: начинайте с проверки — mtr с TCP, тесты iperf3/hping3, сравнение через VPN и сбор логов. Если потеря доходит до последнего хопа — это реальная проблема на стороне AS12389 (конгестия/сбой) и нужно, чтобы ваш провайдер автоматически эскалировал на MTS с приложением собранных данных. Если же теряются только промежуточные хопы, то, скорее всего, это деприоритизация ICMP и реальная связь для TCP/UDP может быть лучше, чем показывает mtr.