Yes, there is a loop somewhere in this path. I did ping -i 255 and tracert expired because at certain it reached a routing loop, right? I will just notify folks responsible for that target network about the problem. Thanks guys!!

edited output of tracert 192.168.0.3

(...)

13 222 ms 225 ms 222 ms 136.195.33.110

14 221 ms 224 ms 223 ms 136.195.33.109

15 228 ms 269 ms 229 ms 136.195.33.110

16 228 ms 229 ms 237 ms 136.195.33.109

17 234 ms 243 ms 249 ms 136.195.33.110

18 237 ms 250 ms 237 ms 136.195.33.109

19 240 ms 240 ms 239 ms 136.195.33.110

20 310 ms 241 ms 242 ms 136.195.33.109

21 244 ms 245 ms 244 ms 136.195.33.110

22 244 ms 257 ms 244 ms 136.195.33.109

23 298 ms 250 ms 255 ms 136.195.33.110

24 251 ms 253 ms 251 ms 136.195.33.109

25 258 ms 257 ms 275 ms 136.195.33.110

26 376 ms 272 ms 318 ms 136.195.33.109

27 261 ms 265 ms 262 ms 136.195.33.110

28 269 ms 270 ms 262 ms 136.195.33.109

29 268 ms 269 ms 273 ms 136.195.33.110

30 441 ms 386 ms 480 ms 136.195.33.109

Trace complete.

There's a routing loop. Router with IP 136.195.33.110 thinks the next hop address for destination 192.168.0.3 is 136.195.33.109 and 136.195.33.109 thinks the next hop address for destination 192.168.0.3 is 136.195.33.110. The packet keeps bouncing back and forth between these routers until the TTL reaches 0 then it's discarded and you receive the ICMP time exceeded message.

hi all,

I have one same kind of case where there is no lopp.. but tracert end on a point. this results in management issue only. not service issue. the node can not be managed

Dear 

I Have The Same Issue So Could You Please Provide The Solution. There's a Routing Loop 

Hi  Cisco Fellows ,

I am having TTL Exipred in transit on a specific Network.

I have a specific subnet 172.17.30.0/24 with servers. This subnet is reached through the firewall (10.81.0.2). the weird scenario is when a specific uplink (only VLANS across, not routing) goes down, Then connectivity to this subnet start failing "TTL Expired in transit" and the output is clear where the loop exist. HOw to solve it? 

See attached screenshot 

You describe your problem as expired in transit. But the output that you post does not show any messages about expired in transit. And the output does show that at 15 hops you are receiving a response from the target of the trace route. 

Your output does show what appears to be a small loop between 10.81.0.2 and 172.17.0.1. If you want to investigate this you could check the routing logic on these devices for the 172.17.30.0 network.

HTH

Rick

Hi Rick,

Well ...
I've checked the routing table on both sides...

The 10.81.0.2 is on the firewall side and 172.17.30.0 on the core switch side but is accessed through the firewall...

Core Switch static Routing table

Gateway of last resort is 10.79.141.9 to network 0.0.0.0

      10.0.0.0/8 is variably subnetted, 999 subnets, 15 masks
S        10.81.220.0/24 [1/0] via 10.81.0.2
S        10.81.230.0/24 [1/0] via 10.81.0.2
S        10.81.231.0/24 [1/0] via 10.81.0.2
S        10.81.232.0/24 [1/0] via 10.81.0.2
S        10.81.234.0/24 [1/0] via 10.81.0.2
S        10.81.236.0/24 [1/0] via 10.81.0.2
S        10.81.241.0/27 [1/0] via 10.81.0.2
S        10.81.242.0/27 [1/0] via 10.81.0.2
S        10.81.248.0/24 [1/0] via 10.81.250.254
S        10.81.249.0/24 [1/0] via 10.81.250.254
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
S        172.16.0.0/16 [1/0] via 10.81.0.2
S     172.17.0.0/16 [1/0] via 10.81.0.2

Attached the firewall routing table

I just can't find the routing issue or don't find a way to correct it.

Can you clarify the topology of this network? You tell us that 172.17.30.0 is on the core switch side but is accessed through the firewall. The routing information that you post from the core switch does not show the specific 172.17.30.0 and does show that 172.17.0.0/16 is reached through the firewall. How can that network be on the switch side if it does not show up in the core switch routing table?

HTH

Rick

Hi Rick

172.17.30.0 /24 is on the firewall yes. I might cut the part which shows that.

Is covered by 172.17.0.0/16 on the core.

S        10.81.220.0/24 [1/0] via 10.81.0.2
S        10.81.230.0/24 [1/0] via 10.81.0.2
S        10.81.231.0/24 [1/0] via 10.81.0.2
S        10.81.232.0/24 [1/0] via 10.81.0.2
S        10.81.234.0/24 [1/0] via 10.81.0.2
S        10.81.236.0/24 [1/0] via 10.81.0.2
S        10.81.241.0/27 [1/0] via 10.81.0.2
S        10.81.242.0/27 [1/0] via 10.81.0.2
S        10.81.248.0/24 [1/0] via 10.81.250.254
S        10.81.249.0/24 [1/0] via 10.81.250.254
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
S        172.16.0.0/16 [1/0] via 10.81.0.2
S     172.17.0.0/16 [1/0] via 10.81.0.2

What is weird is that only when a specific uplink distribution goes down I start to have this intermittence / delay on specific networks. however that uplink only have Layer 2 VLANs, it doesn't perform any Routing...

I still don't see any relation here Rick.

For example now that this specific uplink is running everything looks fine.

Tracing route to 172.17.30.71 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.81.19.1
  2     1 ms    <1 ms    <1 ms  10.81.0.2
  3     9 ms     1 ms     3 ms  172.17.0.1
  4    <1 ms    <1 ms    <1 ms  172.17.30.71

I am getting big complains here. Anyone to support.

Trace complete.

Thanks for clarifying the route for 172.17.0.0/16. I still do not understand the topology of this network well enough to effectively troubleshoot this issue.

I have been thinking of the trace route output you posted early in this discussion. It showed a brief loop and then showed that it got to the destination. One thing that can produce this behavior would be if a link were flapping. It goes down briefly and the loop is generated, then it comes back up and the loop is resolved. Is it possible that some link is flapping like that?

Another thought is that although the link that you describe has only layer 2 vlans, perhaps there is a layer 3 SVI associated with one of the vlans that is being impacted.

HTH

Rick