Варьирование TTL в локальной сети

878
robut

У меня есть беспроводной маршрутизатор за модемом маршрутизатора.

Если я пингую свой маршрутизатор-модем (два прыжка), все выглядит хорошо: 

robut@host:~$ ping 172.X.X.36 PING 172.X.X.36 (172.X.X.36) 56(84) bytes of data. 64 bytes from 172.X.X.36: icmp_seq=1 ttl=253 time=6.64 ms 64 bytes from 172.X.X.36: icmp_seq=2 ttl=253 time=5.08 ms 64 bytes from 172.X.X.36: icmp_seq=3 ttl=253 time=477 ms 64 bytes from 172.X.X.36: icmp_seq=4 ttl=253 time=7.97 ms 64 bytes from 172.X.X.36: icmp_seq=5 ttl=253 time=5.05 ms 64 bytes from 172.X.X.36: icmp_seq=6 ttl=253 time=5.02 ms 64 bytes from 172.X.X.36: icmp_seq=7 ttl=253 time=5.27 ms 64 bytes from 172.X.X.36: icmp_seq=8 ttl=253 time=5.58 ms

ОДНАКО, если я пингую внешний интерфейс непосредственного беспроводного маршрутизатора (ОДИН переход), происходит что-то f #! Ky:
(Я отметил некоторые крайние аномалии.)

robut@host:~$ ping 172.X.X.37 PING 172.X.X.37 (172.X.X.37) 56(84) bytes of data. 64 bytes from 172.X.X.37: icmp_seq=1 ttl=116 time=0.564 ms 64 bytes from 172.X.X.37: icmp_seq=2 ttl=65 time=1.17 ms 64 bytes from 172.X.X.37: icmp_seq=3 ttl=65 time=0.623 ms 64 bytes from 172.X.X.37: icmp_seq=4 ttl=65 time=0.609 ms 64 bytes from 172.X.X.37: icmp_seq=5 ttl=116 time=0.969 ms 64 bytes from 172.X.X.37: icmp_seq=6 ttl=44 time=4.11 ms 64 bytes from 172.X.X.37: icmp_seq=7 ttl=65 time=0.993 ms 64 bytes from 172.X.X.37: icmp_seq=8 ttl=65 time=4.35 ms 64 bytes from 172.X.X.37: icmp_seq=9 ttl=44 time=23.8 ms 64 bytes from 172.X.X.37: icmp_seq=10 ttl=44 time=0.736 ms 64 bytes from 172.X.X.37: icmp_seq=11 ttl=44 time=0.685 ms 64 bytes from 172.X.X.37: icmp_seq=12 ttl=116 time=3.75 ms 64 bytes from 172.X.X.37: icmp_seq=13 ttl=116 time=4.63 ms 64 bytes from 172.X.X.37: icmp_seq=14 ttl=116 time=71.2 ms 64 bytes from 172.X.X.37: icmp_seq=15 ttl=116 time=387 ms <######## 64 bytes from 172.X.X.37: icmp_seq=16 ttl=44 time=11.5 ms 64 bytes from 172.X.X.37: icmp_seq=17 ttl=65 time=2.76 ms 64 bytes from 172.X.X.37: icmp_seq=18 ttl=65 time=3.14 ms 64 bytes from 172.X.X.37: icmp_seq=19 ttl=65 time=3.78 ms 64 bytes from 172.X.X.37: icmp_seq=20 ttl=65 time=3.25 ms 64 bytes from 172.X.X.37: icmp_seq=21 ttl=65 time=13.8 ms 64 bytes from 172.X.X.37: icmp_seq=22 ttl=7 time=160 ms <######## 64 bytes from 172.X.X.37: icmp_seq=23 ttl=65 time=97.8 ms 64 bytes from 172.X.X.37: icmp_seq=24 ttl=65 time=2.40 ms 64 bytes from 172.X.X.37: icmp_seq=25 ttl=116 time=12.9 ms 64 bytes from 172.X.X.37: icmp_seq=26 ttl=44 time=0.687 ms 64 bytes from 172.X.X.37: icmp_seq=27 ttl=44 time=1.62 ms 64 bytes from 172.X.X.37: icmp_seq=28 ttl=116 time=0.658 ms <######## 64 bytes from 172.X.X.37: icmp_seq=29 ttl=44 time=0.655 ms 64 bytes from 172.X.X.37: icmp_seq=30 ttl=44 time=23.6 ms 64 bytes from 172.X.X.37: icmp_seq=31 ttl=65 time=114 ms 64 bytes from 172.X.X.37: icmp_seq=32 ttl=65 time=0.603 ms 64 bytes from 172.X.X.37: icmp_seq=33 ttl=65 time=1.98 ms 64 bytes from 172.X.X.37: icmp_seq=34 ttl=65 time=0.626 ms 64 bytes from 172.X.X.37: icmp_seq=35 ttl=116 time=3.73 ms 64 bytes from 172.X.X.37: icmp_seq=36 ttl=65 time=0.718 ms 64 bytes from 172.X.X.37: icmp_seq=37 ttl=65 time=0.577 ms 64 bytes from 172.X.X.37: icmp_seq=38 ttl=116 time=1.58 ms

Пингование внутреннего интерфейса возвращает аналогичные результаты. Я подключен без проводов - завтра проверим проводной.

ОБНОВЛЕНИЕ
Проверено проводной. Похожая ерунда (выделите строки): 

robut@host:~$ ping 172.X.X.37 PING 172.X.X.37 (172.X.X.37) 56(84) bytes of data. 64 bytes from 172.X.X.37: icmp_seq=1 ttl=44 time=0.219 ms 64 bytes from 172.X.X.37: icmp_seq=111 ttl=13 time=0.235 ms 64 bytes from 172.X.X.37: icmp_seq=112 ttl=5 time=0.247 ms 64 bytes from 172.X.X.37: icmp_seq=113 ttl=13 time=0.218 ms 64 bytes from 172.X.X.37: icmp_seq=114 ttl=5 time=0.260 ms 64 bytes from 172.X.X.37: icmp_seq=133 ttl=65 time=0.227 ms 64 bytes from 172.X.X.37: icmp_seq=134 ttl=5 time=0.205 ms 64 bytes from 172.X.X.37: icmp_seq=135 ttl=44 time=0.233 ms 64 bytes from 172.X.X.37: icmp_seq=136 ttl=67 time=0.204 ms 64 bytes from 172.X.X.37: icmp_seq=137 ttl=44 time=0.197 ms 64 bytes from 172.X.X.37: icmp_seq=138 ttl=67 time=0.204 ms 64 bytes from 172.X.X.37: icmp_seq=139 ttl=44 time=0.182 ms 64 bytes from 172.X.X.37: icmp_seq=140 ttl=65 time=0.165 ms 64 bytes from 172.X.X.37: icmp_seq=141 ttl=44 time=0.188 ms 64 bytes from 172.X.X.37: icmp_seq=142 ttl=65 time=0.223 ms 64 bytes from 172.X.X.37: icmp_seq=212 ttl=5 time=0.242 ms 64 bytes from 172.X.X.37: icmp_seq=213 ttl=80 time=0.193 ms 64 bytes from 172.X.X.37: icmp_seq=214 ttl=5 time=0.204 ms 64 bytes from 172.X.X.37: icmp_seq=233 ttl=44 time=0.195 ms 64 bytes from 172.X.X.37: icmp_seq=234 ttl=50 time=0.178 ms 64 bytes from 172.X.X.37: icmp_seq=235 ttl=44 time=0.182 ms 64 bytes from 172.X.X.37: icmp_seq=254 ttl=5 time=0.236 ms

Итак: что дает?
Почему TTL не 254 на всех ответах ICMP?
Обратите внимание, что TTL не кажется прямо коррелированным со временем, так как есть «ttl = 7 время = 160 мс», но также «ttl = 116 время = 387 мс» и «ttl = 116 время = 0,658 мс».

Мой беспроводной маршрутизатор - это просто POS?

3
Вау, это безумие. Я подозреваю, что ваш роутер это просто POS. Вероятно, он неправильно обрабатывает NAT-loopback (иначе называемый NAT) и пытается перенаправить эти пинги на шлюз по умолчанию. Но почему TTL повсюду и все же пинги все еще возвращаются к вам (по крайней мере, на стороне беспроводной связи), я понятия не имею. Если бы он застрял в цикле пересылки, я бы ожидал, что он застрянет до тех пор, пока не истечет время ожидания (TTL = 0) и не будет отброшен, не возвращаясь к вам. Spiff 8 лет назад 1
@Spiff Спасибо за ответ. Как уже упоминалось, проверка внутреннего интерфейса приводит к аналогичной ерунде (TTL = 44 чаще всего, но я видел 10, 111, 64). Я попытался отключить NAT (без других изменений), и теперь я не могу получить доступ к веб-странице администратора (она перенаправляет на /access_deny.htm, но на эту страницу 404s). Таким образом, кажется, что да, может быть, маршрутизатор ошибочно направляет / передает трафик на свой интерфейс WAN, а затем обратно, даже для вещей в локальной сети. Несмотря на это, я все еще могу пропинговать внутренний интерфейс маршрутизатора с выключенным NAT ... и теперь я видел возвращенные значения TTL 255. @ _ @ robut 8 лет назад 0

1 ответ на вопрос

0
Terry

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

64 байта из 172.XX36: icmp_seq = 3 ttl = 253 время = 477 мс

Однако переменные TTL, кажется, предполагают, что у вас есть проблема маршрутизации где-то

Я бы запустил traceroute (или tracert в Windows), чтобы попытаться увидеть, куда на самом деле идут ваши эхо-запросы

Похожие вопросы