TTL Changes During Continuous Ping

pingtraceroutettl

We use Viasat and have the modem plugged directly into a linux based load balancer.

I SSH'ed into the loadbalancer using putty and pinged google

When I pinged google this is the result:

- 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

with that latency are the only ones resembling satellite latency and the rest well, certainly not sat. latency and the TTL changes from 123 to 55!

Also this ping is performed only out the load balancer's Sat. Modem interface. When you try to ping just the modem(Gateway) from the balancer or from an outside host it doesn't respond, like ICMP is blocked.

Same when we traceroute out the interface, the next hop(the gateway) is just * * *

Anyone with any experience with Viasat connections or any idea of whats going please help.

Best Answer

I believe your answer is going to come from some form of traceroute. But, as discussed in the comments, you have one path that is clearly not going through the satellite. Some systems have this utility named tracert or tracerout. tracepath offers similar functionality.

Note that you may need to run traceroute multiple times for it to actually catch the unexpected path. Also note that firewalls can and frequently do impair traceroute's effectiveness. While it's clear that icmp is not being blocked outright, security devices are fairly commonly configured to not generate the 'destination unreachable' icmp messages on which traceroute depends in its default mode of operation. Just because traceroute answers * * * for one TTL does not mean the next one won't have answers. Your ping test has verified that google.com will at least respond.

Another option could be ping -R. However, playing with this option myself, it appears Google doesn't support this usage, so you'll need to find a different target that will. This option works by including a header option that asks the routers to all record who they are on the packet as they pass it to the target, and then pass the response back to the source. I haven't used this option much, but I would guess that security devices may also mess with its output - either by just not mentioning their existence, or by dropping the request on the floor.

Related Topic