topic Traceroute Same Destination Differing Hops in Network Security

Traceroute Same Destination Differing Hops

Patrick19 — Tue, 19 Mar 2019 16:59:51 GMT

We are doing a tracert to our internet router.

The first time it takes 3 hops

The first hop is the Cisco L3 core switches

The second hop the firewall

The third hop the internet router.

The second time i do a tracert from the same machine an few seconds later i get

The first hop is the Cisco L3 core switches

The second hop the internet router.

Just worried we have a direct connection to the internet router.

I very sure this is not the case but i cant explain the differing results.

Re: Traceroute Same Destination Differing Hops

luis_cordova — Tue, 19 Mar 2019 17:11:24 GMT

Hi @Patrick19 ,

Maybe this discussion can help you:

https://community.cisco.com/t5/switching/traceroute-output-do-not-show-firewall-as-next-hop-while/td-p/2981682

Regards

Re: Traceroute Same Destination Differing Hops

Rob Ingram — Tue, 19 Mar 2019 17:14:38 GMT

Hi,
The ASA would not normally appear as a hop in a traceroute. You can enable it by doing the following:-

policy-map global_policy
class class-default
set connection decrement-ttl

HTH

Re: Traceroute Same Destination Differing Hops

balaji.bandi — Tue, 19 Mar 2019 17:15:24 GMT

Can you please show the output and what are the devices like L3 Switch, FW , Internet and what model and what version of IOS it running.

show us your routing table to understand better, how your configuration done.

Re: Traceroute Same Destination Differing Hops

Jaderson Pessoa — Tue, 19 Mar 2019 18:24:16 GMT

Hello @Patrick19 ,

In addition to other posts.

a) a router is replying with ICMP "TTL expired" when received a packet with TTL=1 (no matter of destination address).

b) a reouter is decreasing TTL value before forwarding an IP packet

c) GRE encapsulation is copying the TTL value from the original packet which is then encapsulted (including the original header with the original TTL).

So the GRE packet has an (external) TTL field within the IP header plus another (internal) TTL value within the encapsulated packet.

Now the source device is sending traceroute packets.

Starts with a packet with TTL = 1, then packet with TTL = 2 followed, then TTL = 3, etc.

Which means:

In your tracerout output:

3 10.10.30.3 - i.e., the router received a packet with TTL = 1 and replied with ICMP "TTL expired"

Next packet was received with TTL = 2 by your 10.10.3.3 router.

It decreases the TTL value to TTL = 1 before forwarding.

As there is a GRE tunnel used to forward it to the next hop, the router encapsulates the original packet to a GRE packet while copying TTL = 1 to the external TTL field.

When the next hop receives the GRE packet, it's seeing the external TTL = 1 and replies with ICMP "TTL expired".

And you see:

4 10.10.40.4

Next traceroute packet was recived with TTL = 3 by the 10.10.30.3 router.

And forwarded to the GRE tunnel with TTL = 2 within the external and internal TTL field.

As the external TTL is 2, the 10.10.40.4 router continues by decapsulating the packet.

When decapsulated, the extra step specified in the RFC follows: "The payload packet's TTL MUST be decremented when
the packet is decapsulated to insure that no packet lives forever."

So the TTL of the decapsulated packet is decreased from 2 to 1.

And the router handles the packet like just received, i.e., it is seeing a packet arrived with TTL = 1.

So replies with ICMP "TTL expired" again (using the tunel port as the source IP), and you see:

5 10.10.40.4

The next packet comes with TTL=3 and is forwarded to the next hop with TTL=1, which has

6 10.10.50.5

as a result.

Original post here: https://community.cisco.com/t5/routing/tracert-show-same-hop-twice/td-p/1502358