Потеря пакетов и сетевые петли - две главные причины, по которым трафик не доходит до цели или зацикливается, пока не истечёт TTL. Диагностика начинается с трёх инструментов: traceroute для быстрого осмотра пути, mtr для непрерывного замера потерь на каждом хопе и tcpdump для захвата доказательств петли. Дальше - проверка таблиц маршрутизации и системных логов, чтобы отделить ошибку конфигурации от проблем с каналом. В этой статье собран проверенный алгоритм действий, который сокращает время простоя с часов до минут.
Быстрый старт: алгоритм диагностики проблем маршрутизации
Когда сервис недоступен, а ping показывает потери, нужен чёткий план. Вот последовательность, которая позволяет локализовать проблему без лишних движений.
- Запустите mtr до целевого узла. Утилита покажет потери и задержки на каждом хопе в реальном времени. Если потери растут от какого-то узла к цели - проблема на этом участке. Подробнее в разделе «Локализация источника потери пакетов с помощью mtr».
- Проверьте таблицу маршрутизации на проблемном узле. Команда
ip route showвыявит конфликтующие подсети, неверный шлюз или отсутствие обратного маршрута. Методика разобрана в разделе «Проверка и оптимизация таблиц маршрутизации». - Захватите трафик через tcpdump. Если подозреваете петлю, фильтр
icmp[icmptype] == 11покажет сообщения TTL expired. Дублирующиеся пакеты с уменьшающимся TTL - прямой признак зацикливания. Инструкция в разделе «Поиск и устранение сетевых петель». - Проанализируйте системные логи.
journalctl -u networkingили логи демонов маршрутизации покажут, связана ли проблема с конфигурацией или с состоянием канала. Критерии классификации - в разделе «Анализ системных логов».
Этот алгоритм - база. Если вы сталкиваетесь с маршрутизацией в VPN, асимметричными маршрутами или проблемами на уровне BGP, рекомендую полный чек-лист диагностики маршрутизации для DevOps и сисадминов. Там разобраны проверки интерфейсов, ARP-таблиц и межсетевых экранов с готовыми командами.
Инструменты диагностики: traceroute, mtr и tcpdump
Эти три утилиты закрывают 90% задач по поиску проблем маршрутизации. Каждая решает свою часть головоломки: traceroute даёт мгновенный снимок пути, mtr собирает статистику во времени, tcpdump предоставляет неопровержимые доказательства на уровне пакетов.
traceroute: первый взгляд на путь пакета
traceroute отправляет пакеты с последовательно увеличивающимся TTL. Каждый маршрутизатор на пути, получив пакет с TTL=1, отбрасывает его и отправляет обратно ICMP Time Exceeded. Так вы видите все промежуточные узлы.
Типичный вывод:
$ traceroute -n 8.8.8.8
1 192.168.1.1 0.512 ms 0.489 ms 0.475 ms
2 10.0.0.1 1.234 ms 1.198 ms 1.221 ms
3 * * *
4 72.14.237.130 12.451 ms 12.389 ms 12.412 ms
5 8.8.8.8 12.678 ms 12.601 ms 12.589 msЗвёздочки на третьем хопе при нормальном прохождении трафика дальше - не повод для паники. Многие провайдеры настраивают rate limiting для ICMP-ответов. Маршрутизатор пропускает трафик, но не отвечает на служебные запросы traceroute. Если звёздочки идут с определённого хопа и до конца - вот это уже обрыв.
Асимметричные маршруты traceroute не показывает напрямую. Пакет может идти к цели через один набор узлов, а обратно - через другой. Для обнаружения таких ситуаций нужен отдельный подход к диагностике асимметричной маршрутизации с анализом двух направлений.
mtr: непрерывный мониторинг потерь и задержек
mtr объединяет логику traceroute и ping. Вместо трёх проб на хоп он отправляет пакеты непрерывно и собирает статистику: процент потерь, среднюю, минимальную и максимальную задержку. Это критически важно для перемежающихся проблем, когда одиночный traceroute может показать «всё чисто», а через минуту начинаются потери.
Запуск в режиме отчёта с 50 циклами:
$ mtr -r -c 50 8.8.8.8Интерактивный режим (просто mtr 8.8.8.8) обновляет статистику в реальном времени. Ключевые столбцы:
- Loss% - процент потерянных пакетов на этом хопе.
- Avg - средняя задержка.
- Best/Wrst - минимальная и максимальная задержка за цикл измерений.
- StDev - стандартное отклонение задержки. Высокое значение указывает на нестабильность канала.
Пример: Loss% на четвёртом хопе 2%, на пятом 2%, на целевом узле 25%. Потери нарастают к цели - проблема на участке между пятым хопом и целевым узлом. Если Loss% 10% на втором хопе, а на всех последующих 0%, это rate limiting ICMP на конкретном маршрутизаторе, а не реальная потеря трафика.
tcpdump: глубокий анализ трафика на проблемном узле
tcpdump захватывает пакеты с сетевого интерфейса и позволяет увидеть то, что скрыто от утилит трассировки. Для диагностики маршрутизации полезны три сценария.
Фильтрация ICMP-пакетов определённого типа:
$ tcpdump -i eth0 'icmp[icmptype] == 11'Этот фильтр показывает только сообщения TTL expired - главный индикатор петель. Если пакеты с одним и тем же идентификатором приходят многократно с разных узлов, трафик зациклен.
Захват трафика на конкретный хост с ограничением по количеству пакетов:
$ tcpdump -i eth0 host 192.168.1.100 -c 100 -w capture.pcapФайл capture.pcap затем можно открыть в Wireshark для визуального анализа. Это удобно, когда нужно показать проблему коллегам или задокументировать инцидент.
Обнаружение дублирующихся пакетов:
При петле один и тот же пакет проходит через проблемный узел несколько раз. В tcpdump это выглядит как повторяющиеся строки с одинаковыми IP-идентификаторами, но уменьшающимся TTL. Заметили пять копий одного пакета с TTL от 64 до 60 - петля подтверждена.
Локализация источника потери пакетов с помощью mtr
mtr - основной инструмент для точного определения участка сети, на котором теряются пакеты. Правильная интерпретация отчёта позволяет отличить реальную проблему от особенностей поведения промежуточных маршрутизаторов.
Интерпретация отчета mtr: где начинаются потери?
Главное правило: смотрите на динамику потерь от хопа к хопу. Есть три типичных паттерна.
Паттерн 1: Потери на одном хопе, дальше чисто. На третьем хопе Loss% = 30%, на четвёртом и далее 0%. Это классический rate limiting ICMP. Маршрутизатор занят обработкой трафика и не отвечает на служебные запросы, но пакеты пропускает. Проблемы с маршрутизацией нет.
Паттерн 2: Потери начинаются на хопе N и сохраняются до цели. На четвёртом хопе Loss% = 5%, на пятом 5%, на целевом узле 5%. Проблема на участке между четвёртым хопом и целью. Проверяйте канал, нагрузку на маршрутизатор, возможные ошибки на интерфейсах.
Паттерн 3: Потери нарастают к цели. На четвёртом хопе 2%, на пятом 10%, на целевом 35%. Каждый следующий узел добавляет потери. Это может указывать на перегрузку канала или проблемы с MTU, вызывающие фрагментацию и отбрасывание пакетов. Для глубокого анализа таких ситуаций используйте руководство по диагностике с traceroute, mtr и ip route, где разобраны сценарии с black hole в BGP и проблемами MTU в туннелях.
Практический пример. Запускаем mtr до проблемного сервера на 100 циклов:
$ mtr -r -c 100 10.20.30.40
Start: 2026-07-28T10:15:00+0300
HOST: admin-workstation Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 100 0.3 0.4 0.3 1.2 0.1
2. 10.0.0.1 0.0% 100 1.1 1.3 1.0 5.8 0.5
3. 172.16.0.1 0.0% 100 5.2 5.4 5.0 8.1 0.4
4. 10.20.30.1 12.0% 100 15.3 16.1 14.8 45.2 4.8
5. 10.20.30.40 12.0% 100 15.8 16.3 15.0 44.9 4.6Потери 12% появляются на четвёртом хопе и сохраняются на целевом узле. Проблема на участке между хопами 3 и 4 или на самом четвёртом хопе. Проверяем интерфейсы на четвёртом узле: ip -s link show показывает ошибки и отброшенные пакеты. Обнаруживаем CRC errors на uplink-интерфейсе - замена патч-корда решает проблему.
Поиск и устранение сетевых петель
Сетевая петля возникает, когда пакет бесконечно циркулирует между узлами из-за некорректных записей в таблицах маршрутизации. Симптомы: полная потеря связности до подсети, экспоненциальный рост трафика на интерфейсах, сообщения TTL expired в логах.
Как tcpdump помогает увидеть петлю
Первый признак петли при захвате трафика - многократное повторение одних и тех же пакетов. Запускаем захват на подозрительном интерфейсе:
$ tcpdump -i eth1 -n 'icmp[icmptype] == 11'Вывод при наличии петли выглядит так:
10:23:45.123456 IP 192.168.1.1 > 192.168.1.100: ICMP time exceeded in-transit, length 56
10:23:45.124012 IP 10.0.0.1 > 192.168.1.100: ICMP time exceeded in-transit, length 56
10:23:45.124567 IP 192.168.1.1 > 192.168.1.100: ICMP time exceeded in-transit, length 56
10:23:45.125123 IP 10.0.0.1 > 192.168.1.100: ICMP time exceeded in-transit, length 56Два узла поочерёдно отправляют ICMP time exceeded для одного и того же пакета. Пакет ходит между 192.168.1.1 и 10.0.0.1, пока TTL не обнулится. Для более детального анализа захватите весь трафик между этими узлами:
$ tcpdump -i eth1 -n host 192.168.1.1 and host 10.0.0.1 -w loop.pcapОткройте файл в Wireshark и проверьте поле TTL в IP-заголовке. Если TTL монотонно уменьшается при каждом прохождении - петля подтверждена.
Исправление таблиц маршрутизации для разрыва петли
После обнаружения петли нужно найти и исправить записи, которые её создают. На каждом узле, участвующем в петле, выполните:
$ ip route showИщите две записи, которые ссылаются друг на друга. Классический пример петли на статических маршрутах:
На узле A:
10.20.30.0/24 via 192.168.1.2 dev eth0На узле B:
192.168.1.0/24 via 10.20.30.1 dev eth0Узел A отправляет пакеты для сети 10.20.30.0/24 на узел B. Узел B, не имея прямого доступа к 10.20.30.0/24, отправляет их обратно на узел A. Петля готова.
Исправление: на узле B должен быть либо прямой интерфейс в сеть 10.20.30.0/24, либо маршрут через другой шлюз, который действительно знает дорогу. Удаляем некорректный маршрут:
$ ip route del 192.168.1.0/24 via 10.20.30.1Добавляем правильный:
$ ip route add 192.168.1.0/24 via 10.20.30.254Петля разорвана. Для предотвращения повторения проблемы проверьте конфигурационные файлы (в /etc/network/interfaces или /etc/netplan/) и убедитесь, что статические маршруты не конфликтуют.
Проверка и оптимизация таблиц маршрутизации
Таблица маршрутизации - мозг сетевого стека. Одна неверная запись способна отправить трафик в чёрную дыру или создать петлю. Регулярный аудит таблиц на ключевых узлах предотвращает инциденты.
Типичные ошибки в таблицах маршрутизации
Неправильный default gateway. Шлюз по умолчанию указывает на узел, который не имеет выхода в нужную сеть. Симптом: локальная сеть работает, внешние ресурсы недоступны. Проверка: ip route show default. Сравните с фактическим шлюзом провайдера.
Конфликтующие подсети. Два интерфейса имеют адреса из одной подсети или пересекающиеся диапазоны. Симптом: непредсказуемое поведение, пакеты уходят не на тот интерфейс. Проверка: ip addr show на всех интерфейсах, сверка с таблицей маршрутизации.
Отсутствие обратного маршрута. Пакет доходит до цели, но ответ не может вернуться, потому что на целевом узле нет маршрута к источнику. Симптом: TCP-соединение зависает на SYN_SENT, UDP-пакеты теряются в одну сторону. Проверка: на целевом узле выполните ip route get <адрес_источника>. Если ответа нет - обратный маршрут отсутствует.
Петли из-за статических маршрутов. Два узла указывают друг на друга как на шлюз для одной и той же сети. Разобрано в предыдущем разделе.
Неверная метрика маршрута. При нескольких путях до одной сети трафик идёт через медленный или перегруженный канал, потому что у него ниже метрика. Проверка: ip route show <сеть> покажет все маршруты с метриками. Исправление: ip route replace <сеть> via <шлюз> metric <значение>.
Для комплексной проверки таблиц на всех узлах сети используйте методику диагностики проблем маршрутизации для DevOps и сисадминов. Там разобрана трассировка в распределённых системах и анализ логов веб-серверов для поиска причин сбоев.
Анализ системных логов: отличаем ошибки конфигурации от проблем с каналом
Системные логи - источник объективных данных о характере проблемы. Ошибки конфигурации воспроизводятся постоянно и не зависят от нагрузки. Проблемы с каналом перемежающиеся, усиливаются при росте трафика и часто сопровождаются ошибками на физическом уровне.
Ключевые сообщения в логах и их значение
| Сообщение в логе | Вероятная причина | Действие |
|---|---|---|
ICMP redirect |
Неоптимальная маршрутизация. Маршрутизатор сообщает, что есть более короткий путь. | Проверьте таблицу маршрутизации, добавьте прямой маршрут через указанный шлюз. |
packet too big, MTU |
Пакет превышает MTU интерфейса, фрагментация запрещена (DF-флаг). | Настройте Path MTU Discovery или уменьшите MTU на отправителе. |
TTL expired |
Петля маршрутизации или слишком длинный путь. | Запустите traceroute, проверьте таблицы маршрутизации на петли. |
neighbor down |
Потеря связи с соседним маршрутизатором в динамической маршрутизации. | Проверьте физическое соединение, аутентификацию соседа, состояние протокола. |
CRC error |
Повреждение кадра на физическом уровне. | Замените кабель, проверьте порт коммутатора, обновите драйвер сетевой карты. |
interface down/up |
Флэппинг интерфейса - частое переключение состояния. | Проверьте кабель, настройки автосогласования, duplex mismatch. |
destination host unreachable |
Маршрутизатор не имеет маршрута к целевой сети. | Проверьте таблицу маршрутизации на источнике и всех промежуточных узлах. |
Источники логов на Linux:
/var/log/syslog- общесистемный лог.journalctl -u networking- логи сетевой подсистемы.journalctl -u ospfdилиjournalctl -u bgpd- логи демонов динамической маршрутизации.dmesg | grep -i eth- сообщения ядра о сетевых интерфейсах.
Критерий классификации: ошибка конфигурации проявляется сразу после изменения настроек и воспроизводится при каждом обращении. Проблема с каналом возникает спорадически, часто коррелирует с нагрузкой и сопровождается физическими ошибками на интерфейсах. Если ip -s link show показывает ненулевые счётчики errors и dropped, а в логах есть CRC errors - начинайте с проверки физического уровня.
Глубокое понимание типичных ошибок проектирования маршрутизации помогает предотвращать проблемы до их возникновения. В статье о типичных ошибках в проектировании маршрутизации разобраны deadlocks, потеря данных и неэффективные пути обработки с готовыми конфигурациями Circuit Breaker и Retry для Kubernetes и Nginx.