tcptraceroute: Hop не отвечает

tcptraceroute: Hop не отвечает

Насколько мне известно, 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")

Предыстория: Я хотел бы сказать тем, кто несет ответственность за сеть, что они должны использовать маршрутизаторы, которые делают ТЕПЕРЬ-Я-УПУСКАЮ-ЭТОТ-МАГИЧЕСКИЙ-ТЕРМИН.

решение1

Точного слова для этого не существует, но чтобы помочь вам в диалоге с теми, кто управляет этой сетью, вы можете рассмотреть CoPP (Control Plane Policing).

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

Предупреждаю, что вам может быть сложно заставить сетевую команду внести эти изменения, поскольку они необходимы для защиты устройства от DoS-атак или перегрузки при обычном использовании на уровне управления.

ОтДокументы CiscoНиже приведены некоторые эффекты, которые можно наблюдать при перегрузке плоскости управления:

  • Снижение качества обслуживания (например, плохой трафик голоса, видео или критически важных приложений)
  • Высокая загрузка процессора маршрутизации или процессора коммутатора
  • Сбои в маршрутизации из-за потери обновлений протокола маршрутизации или пакетов keepalive
  • Нестабильная топология уровня 2
  • Медленные или неотзывчивые интерактивные сеансы с CLI
  • Истощение ресурсов процессора, таких как память и буферы
  • Беспорядочное отбрасывание входящих пакетов

решение2

Как уже было сказано в комментариях, на это нет реального ответа (поэтому я чувствую себя немного глупо, печатая это, но это было бы слишком длинно для комментария). То, что вы видите, просто tcptracerouteговорит о том, что он не получил ответа от перехода. Для этого нет термина, это просто способ, которым был разработан traceroute. Когда переход не отвечает на запрос ICMP, вы получаете ответ *, что означает, что ничего не было возвращено, поэтому ответ в виде времени ответа ping не может быть определен.

Итак, чтобы перейти к вашей биографии:

Я хотел бы сказать тем, кто несет ответственность за сеть, что они должны использовать маршрутизаторы, которые делают СЕЙЧАС-Я-ПРОПУСКАЮ-ЭТОТ-МАГИЧЕСКИЙ-ТЕРМИН.

Просто скажите им, что их маршрутизаторы должны блокировать запросы ICMP, и вуаля, они поймут, что вы имеете в виду, с помощью всего нескольких слов. Также потому, что это не столько функция, сколько настройка. Так что вы не «используете маршрутизаторы, которые блокируют запросы ICMP», вы инструктируете их делать это (это может быть настройка по умолчанию, но это все равно настройка). Люди, ответственные за сеть, должны это знать.

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