☰

traceroute: иногда маршрутизаторы не отвечают, и пользователь видит тайм-ауты

tag-icon • tag-icon linux timeout rate-limiting icmp traceroute
traceroute: иногда маршрутизаторы не отвечают, и пользователь видит тайм-ауты

Я администратор небольшой сети и расследую проблему, на которую жалуются мои пользователи. Корень их жалоб в следующем traceroute: иногда маршрутизаторы на пути просто не отвечают на tracerouteзонды, и пользователи видят тайм-ауты (те самые *s вместо RTT).

Сеть состоит из нескольких маршрутизаторов Linux, соединенных по Ethernet/беспроводной сети. Маршрутизаторы Linux простаивают на 99%, загрузка канала 20 Мбит/с, 2000 пакетов/с. Беспроводная связь надежна. PING для всех маршрутизаторов на пути составляет 10 мс, с некоторыми отклонениями, конечно. Flood PING для любого из этих хостов выполняется в течение нескольких минут без потери пакетов (и я имею в виду 0 потерянных пакетов). Загрузка некоторых огромных файлов по сети: в среднем 10,2 МБ/с.

Примерправильный tracerouteвыглядит так:

# traceroute -nI 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  192.168.0.1  3.919 ms  3.866 ms  4.117 ms
 2  10.41.13.1  4.149 ms  6.714 ms  6.707 ms
 3  10.41.1.11  8.475 ms  8.468 ms  8.705 ms
 4  10.0.0.2  8.697 ms  9.428 ms  9.707 ms

Theпроблематичный tracerouteвыглядят так:

# traceroute -nI 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  192.168.0.1  3.190 ms  3.140 ms  3.128 ms
 2  10.41.13.1  3.119 ms  3.113 ms *
 3  10.41.1.11  3.697 ms *  3.683 ms
 4  10.0.0.2  4.531 ms  4.524 ms  5.171 ms
# traceroute -nI 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  192.168.0.1  3.471 ms  3.405 ms  3.388 ms
 2  10.41.13.1  3.372 ms  3.359 ms  3.350 ms
 3  10.41.1.11  5.039 ms * *
 4  10.0.0.2  5.105 ms  5.484 ms  5.473 ms

Я немного поисследовал tcpdumpи выяснил, что это tracerouteработает следующим образом:

  1. Сначала отправляет пачку ICMP-запросов с TTL 1, 2, 3, 4, 5, 6. Каждый TTL отправляется 3 раза. То есть 18 пакетов :)
  2. Он ждет некоторое время всех ответов ( Time Exceeded).
  3. Когда вернутся все ответы, покажите результаты.
  4. ..или дождаться истечения времени ожидания и показать результаты, в которых отсутствующие ответы будут отмечены звездочками.

А причина тайм-аутов в том, что маршрутизаторы получают все 3 соответствующих запроса, но иногда не отвечают, они не отправляют ICMP Time Exceeded.

Я подозреваю, что есть какие-то настройки, которые задают такое поведение на маршрутизаторе. А именноicmp_ratelimit,icmp_ratemask,icmp_msgs_per_secиicmp_msgs_burst. Все как-то описанов документации kernel.org. И вот в чем я потерпел неудачу. Я не придумал никаких значений этих переменных, чтобы все работало tracerouteвсегда.

Я попробовал установить это на всех маршрутизаторах:

  • icmp_ratelimitустановить 0(ничего не ограничивать)
  • icmp_msgs_per_secустановлено значение 10000(должно быть достаточно высоким)
  • icmp_msgs_burstустановлен на 5000(высокий уровень)

Мне это не помогло, я вижу то же самое поведение, случайные таймауты. Я не стал возиться с icmp_ratemask, потому что не совсем понимаю, как исключить Time Exceeded's из ограничения.

Итак, напоследок, вопросы:

  1. Если вам знаком этот тип tracerouteпроблем, как вы их решили?
  2. Если вы знакомы с настройками ядра, упомянутыми выше, какие значения являются «достаточно хорошими»?
  3. Как правильно изменить способ, icmp_ratemaskчтобы не ограничивать Time Exceededсообщения и чтобы tracerouteработа работала без сбоев?
  4. И дополнительно - есть ли какие-либо нарушения безопасности при изменении этих (или любых связанных) настроек? Я не хочу быть атакованным DoS или быть источником DDoS-атаки для кого-либо.

решение1

Как часть политик плоскости управления на переходах ICMP-пробы в основном игнорируются. Я бы предложил выделенный экземпляр на prem smokeping, если вы хотите иметь более подробные, с точки зрения метрик и тенденций, исторические данные.

Связанный контент