Я администратор небольшой сети и расследую проблему, на которую жалуются мои пользователи. Корень их жалоб в следующем 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
работает следующим образом:
- Сначала отправляет пачку ICMP-запросов с TTL 1, 2, 3, 4, 5, 6. Каждый TTL отправляется 3 раза. То есть 18 пакетов :)
- Он ждет некоторое время всех ответов (
Time Exceeded
). - Когда вернутся все ответы, покажите результаты.
- ..или дождаться истечения времени ожидания и показать результаты, в которых отсутствующие ответы будут отмечены звездочками.
А причина тайм-аутов в том, что маршрутизаторы получают все 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 из ограничения.
Итак, напоследок, вопросы:
- Если вам знаком этот тип
traceroute
проблем, как вы их решили? - Если вы знакомы с настройками ядра, упомянутыми выше, какие значения являются «достаточно хорошими»?
- Как правильно изменить способ,
icmp_ratemask
чтобы не ограничиватьTime Exceeded
сообщения и чтобыtraceroute
работа работала без сбоев? - И дополнительно - есть ли какие-либо нарушения безопасности при изменении этих (или любых связанных) настроек? Я не хочу быть атакованным DoS или быть источником DDoS-атаки для кого-либо.
решение1
Как часть политик плоскости управления на переходах ICMP-пробы в основном игнорируются. Я бы предложил выделенный экземпляр на prem smokeping, если вы хотите иметь более подробные, с точки зрения метрик и тенденций, исторические данные.