tcptraceroute: Hop не отвечает
AFAIK tcptraceroute - лучший инструмент для проверки, не блокирует ли брандмауэр TCP-соединение со службой. (Если вы знаете инструмент получше, дайте ему комментарий)
Некоторые прыжки не отвечают. См. * * *
remotehost:~ # tcptraceroute ftp.example.com ftp
Selected device eth0, address 10.172.19.11, port 40768 for outgoing packets
Tracing the path to ftp.example.com (10.101.7.124) on TCP port 21 (ftp), 30 hops max
1 * * *
2 172.18.56.12 0.407 ms 0.222 ms 0.230 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 10.102.1.1 32.017 ms 31.728 ms 31.486 ms
8 * * *
9 10.101.7.124 [open] 31.728 ms 32.391 ms 33.549 ms
Есть ли термин для поведения этих переходов?
Как это вызвать, если переход не отвечает, и я вижу * * * в выводе?
(К сожалению, я не У меня 300 репутации, и я не могу создать новый тег "tcptraceroute")
Предыстория: я хотел бы рассказать людям, как они несут ответственность за сеть, что они должны использовать маршрутизаторы, которые делают СЕЙЧАС-Я-Я-ПРОПУСТИТЕ- ВОЛШЕБНЫЙ СРОК.
На самом деле нет точного слова для этого, но чтобы помочь вам в диалоге с теми, кто управляет этой сетью, вы можете обратиться к CoPP (Control Plane Policing)
Стоит отметить, что на самом деле устройство может быть настроено не на отклонение этих пакетов, а просто на ограничение скорости, поэтому, если вам нужны ответы, вы можете попросить их исключить определенные IP-адреса из лимита скорости или поднять лимит на все, если вам это нужно.
Предупреждаю, что у вас могут возникнуть трудности с внесением этих изменений сетевой командой, поскольку они необходимы для защиты устройства от DoS-атак или нормальной перегрузки на плоскости управления.
Из Cisco's docs ниже приведены некоторые эффекты, которые можно увидеть, если плоскость управления перегружена:
- Сниженное качество обслуживания (например, плохой голос, видео или критический трафик приложений)
- Высокоуровневый процессор или процессор коммутатора
- Закрытия маршрута из-за потери обновлений протокола маршрутизации или keepalives
- Нестабильная топология 2-го уровня
- Медленные или не отвечающие на запросы интерактивные сеансы с истощением ресурсов процессора CLI
- Неизбирательные падения входящих пакетов
Как уже говорилось в комментариях, реального ответа на этот вопрос нет (поэтому я чувствую себя немного глупо за то, что набираю этот текст, но для комментария он стал бы слишком длинным). То, что вы видите, это просто tcptraceroute , говорящий, что он не получил ответ от прыжка. Для этого нет термина, это просто способ, которым была создана трассировка. Когда прыжок не отвечает на ICMP запрос, вы получаете ответ *, что означает, что ничего не было возвращено, поэтому ответ в виде времени ping-ответа не может быть определен.
Итак, для того, чтобы разобраться с вашим фоном:
Я хотел бы рассказать людям, как они отвечают за сеть, что они должны использовать маршрутизаторы, которые делают NOW-I-AM-MISSING-THE-MAGIC-TERM.
Просто скажите им, что их маршрутизаторы должны блокировать ICMP-запросы, и вуаля, они поймут, что вы имеете в виду, всего лишь несколькими словами. Также потому, что это не столько функция, сколько настройка. Поэтому вы не "используете маршрутизаторы, которые блокируют ICMP-запросы", вы инструктируете их делать это (это может быть настройка по умолчанию, но все же это настройка). Люди, ответственные за сеть, должны это знать.
.