Изменения TTL во время непрерывного пинга

Мы используем Viasat и подключаем модем непосредственно к балансировщику нагрузки на основе Linux.

Я SSH'ed в loadbalancer, используя замазку и пинговал Google

Когда я пинговал Google, это результат:

- PING 8.8.8.8 (8.8.8.8) from x.x.x.x : 64(92) bytes of data.

- 72 bytes from 8.8.8.8: icmp_seq=1 ttl=123 time=4.02 ms
- 72 bytes from 8.8.8.8: icmp_seq=2 ttl=123 time=8.40 ms
- 72 bytes from 8.8.8.8: icmp_seq=3 ttl=123 time=11.1 ms
- 72 bytes from 8.8.8.8: icmp_seq=4 ttl=123 time=16.2 ms
- 72 bytes from 8.8.8.8: icmp_seq=5 ttl=123 time=7.37 ms
- 72 bytes from 8.8.8.8: icmp_seq=6 ttl=123 time=10.0 ms
- 72 bytes from 8.8.8.8: icmp_seq=7 ttl=123 time=12.9 ms
- 72 bytes from 8.8.8.8: icmp_seq=8 ttl=123 time=7.04 ms
- 72 bytes from 8.8.8.8: icmp_seq=9 ttl=123 time=11.4 ms
- 72 bytes from 8.8.8.8: icmp_seq=10 ttl=123 time=10.5 ms
- 72 bytes from 8.8.8.8: icmp_seq=11 ttl=123 time=7.30 ms
- 72 bytes from 8.8.8.8: icmp_seq=12 ttl=123 time=4.42 ms
- 72 bytes from 8.8.8.8: icmp_seq=13 ttl=123 time=12.9 ms
- 72 bytes from 8.8.8.8: icmp_seq=14 ttl=55 time=573 ms
- 72 bytes from 8.8.8.8: icmp_seq=15 ttl=123 time=9.64 ms
- 72 bytes from 8.8.8.8: icmp_seq=16 ttl=123 time=12.0 ms
- 72 bytes from 8.8.8.8: icmp_seq=17 ttl=123 time=6.09 ms
- 72 bytes from 8.8.8.8: icmp_seq=18 ttl=123 time=9.14 ms
- 72 bytes from 8.8.8.8: icmp_seq=19 ttl=55 time=567 ms
- 72 bytes from 8.8.8.8: icmp_seq=20 ttl=55 time=556 ms
- 72 bytes from 8.8.8.8: icmp_seq=21 ttl=55 time=567 ms
- 72 bytes from 8.8.8.8: icmp_seq=22 ttl=123 time=7.83 ms
- 72 bytes from 8.8.8.8: icmp_seq=23 ttl=55 time=557 ms
- 72 bytes from 8.8.8.8: icmp_seq=24 ttl=55 time=555 ms
- 72 bytes from 8.8.8.8: icmp_seq=25 ttl=55 time=564 ms
- 72 bytes from 8.8.8.8: icmp_seq=26 ttl=55 time=565 ms
- 72 bytes from 8.8.8.8: icmp_seq=27 ttl=55 time=562 ms
- 72 bytes from 8.8.8.8: icmp_seq=28 ttl=123 time=10.0 ms
- 72 bytes from 8.8.8.8: icmp_seq=29 ttl=123 time=13.0 ms
- 72 bytes from 8.8.8.8: icmp_seq=30 ttl=123 time=12.5 ms
- 72 bytes from 8.8.8.8: icmp_seq=31 ttl=123 time=5.36 ms
- 72 bytes from 8.8.8.8: icmp_seq=32 ttl=123 time=8.44 ms
- 72 bytes from 8.8.8.8: icmp_seq=33 ttl=123 time=10.8 ms
- ^C
- --- 8.8.8.8 ping statistics ---
- 33 packets transmitted, 33 received, 0% packet loss, time 47026ms
- rtt min/avg/max/mdev = 4.020/160.648/573.236/246.800 ms

These entries:
72 bytes from 8.8.8.8: icmp_seq=19 ttl=55 time=567 ms

с такой задержкой - единственные, которые напоминают латентную задержку, а остальные хорошо, конечно, не сидели. задержка и TTL изменяется от 123 до 55!

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

То же самое, когда мы трассируем интерфейс, следующий переход (шлюз) просто * * *

Любой, кто имеет опыт работы с Viasat-соединениями или знает, что происходит, пожалуйста, помогите.

3 ответа

Я верю, что ваш ответ придет из какой-то формы traceroute, Но, как обсуждалось в комментариях, у вас есть один путь, который явно не проходит через спутник. В некоторых системах эта утилита называется tracert или же tracerout, tracepath предлагает аналогичную функциональность.

Обратите внимание, что вам может понадобиться запустить traceroute несколько раз, чтобы он действительно перехватил неожиданный путь. Также обратите внимание, что брандмауэры могут и часто ухудшают эффективность traceroute. Хотя очевидно, что icmp не блокируется напрямую, устройства безопасности довольно часто настраиваются так, чтобы они не генерировали сообщения icmp "пункт назначения недоступен", от которых traceroute зависит в режиме работы по умолчанию. То, что traceroute отвечает * * * за один TTL, не означает, что у следующего не будет ответов. Ваш тест ping подтвердил, что google.com по крайней мере ответит.

Другой вариант может быть ping -R, Однако, играя с этой опцией, похоже, Google не поддерживает это использование, поэтому вам нужно найти другую цель, которая будет. Эта опция работает путем включения опции заголовка, которая запрашивает у маршрутизаторов все записи о том, кто они есть в пакете, когда они передают его цели, а затем передают ответ обратно источнику. Я не очень часто использовал эту опцию, но я бы предположил, что устройства безопасности также могут запутаться в его результатах - либо просто не упоминая об их существовании, либо отбрасывая запрос на пол.

Я обнаружил, что 8.8.8.8 является балансом по умолчанию. Я должен был бы использовать 4.2.2.2, чтобы пинг выходил только из WAN2. Спасибо всем за ваши ответы, и я надеюсь, что мы все напрягли мозг, пытаясь понять это. Значит, мы все победим, верно? хе...

Это могут быть разные вещи. Во-первых, на странице руководства для ping в моей системе сказано следующее о TTL:

При нормальной работе ping печатает значение TTL из полученного пакета. Когда удаленная система получает пакет проверки связи, она может выполнить одно из трех действий с полем TTL в своем ответе:

  • Не меняй это; это то, что системы Berkeley Unix делали до выпуска 4.3BSD Tahoe. В этом случае значение TTL в полученном пакете будет 255 минус число маршрутизаторов в пути туда и обратно.

  • Установите его на 255; это то, что делают нынешние системы Berkeley Unix. В этом случае значение TTL в полученном пакете будет 255 минус число маршрутизаторов на пути от удаленной системы к хосту проверки связи.

  • Установите это к некоторому другому значению. Некоторые машины используют то же значение для пакетов ICMP, которое они используют для пакетов TCP, например, 30 или 60. Другие могут использовать полностью дикие значения.

Во-вторых, технически ничто не мешает маршрутизатору или устройству безопасности наложить максимальный TTL на трафик, проходящий через него, что может легко оказать воздействие, которое вы видите.

Итак, мое первое предложение заключается в том, что ваш трафик может быть сбалансирован по нагрузке на хост назначения, который использует TTL (например) 60 (вариант 3 выше)

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

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

Обратите внимание, что когда вы видите длинный ряд ответов "* * *" в traceroute, это признак того, что устройство между вами и вашим пунктом назначения делает что-то неожиданное с TTL, по крайней мере для ICMP-сообщений "пункт назначения недоступен", используемых traceroute (которые обрабатываются немного иначе, чем пакеты 'echo request', используемые ping).

Если ваша команда ping предлагает вам возможность установить TTL, вы можете попробовать несколько разных значений, чтобы увидеть, какие TTL вы получите в ответ.

Другие вопросы по тегам