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

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

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

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

# трассировка -nI 10.0.0.2
traceroute до 10.0.0.2 (10.0.0.2), макс. 30 переходов, пакеты по 60 байт
 1 192.168.0.1 3,919 мс 3,866 мс 4,117 мс
 2 10.41.13.1 4,149 мс 6,714 мс 6,707 мс
 3 10.41.1.11 8,475 мс 8,468 мс 8,705 мс
 4 10.0.0.2 8,697 мс 9,428 мс 9,707 мс

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

# трассировка -nI 10.0.0.2
traceroute до 10.0.0.2 (10.0.0.2), макс. 30 переходов, пакеты по 60 байт
 1 192.168.0.1 3,190 мс 3,140 мс 3,128 мс
 2 10.41.13.1 3,119 мс 3,113 мс *
 3 10.41.1.11 3,697 мс * 3,683 мс
 4 10.0.0.2 4,531 мс 4,524 мс 5,171 мс
# трассировка -nI 10.0.0.2
traceroute до 10.0.0.2 (10.0.0.2), макс. 30 переходов, пакеты по 60 байт
 1 192.168.0.1 3,471 мс 3,405 мс 3,388 мс
 2 10.41.13.1 3,372 мс 3,359 мс 3,350 мс
 3 10.41.1.11 5,039 мс * *
 4 10.0.0.2 5,105 мс 5,484 мс 5,473 мс

Я исследовал немного с tcpdump и узнал, что трассировка работает так:

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

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

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

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

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

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

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

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

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