Tracert going into an infinite loop on trace to a loopback int

[sonikbaby]

Hello,

I was wondering if anyone can explain why tracert is doing this. It is not causeing any problems that I know of but am curious why it is happening.

It is the loopsback interface on our external FW. It pings fine, but if you do a tracert it will do this:

tracert 172.22.127.253

Tracing route to 172.22.127.253 over a maximum of 30 hops

  1     7 ms     4 ms     1 ms  172.19.16.1

  2     1 ms     1 ms     1 ms  172.19.0.1

  3     1 ms     1 ms     1 ms  xxxxxx.net [xxx.xxx.175.241]

  4     5 ms     5 ms     4 ms  xxxxx.net [xxx.xxx.200.2

6]

  5     5 ms    10 ms     5 ms  172.22.0.2

  6     5 ms     5 ms     5 ms  172.22.0.1

  7     5 ms     5 ms     7 ms  172.22.0.2

  8     6 ms     5 ms     4 ms  172.22.0.1

.1 and .2 are a router and layer 3 switch with static routing.

I ws thinking it might have something to do with the route tables?  I would think that that IP address would fall under the default route since there is not exact static or direct connection route to that subnet which is which would be  172.22.0.2 to 192.168.252.130 . Which it does, since PING does work but Tracert is not reporting that and just going back and forth between the two routers.

Here is the route tables for that network on these devices.

On .2

  172.22.0.0/16 is variably subnetted, 4 subnets, 2 masks

C       172.22.16.0/22 is directly connected, Vlan16

C       172.22.8.0/22 is directly connected, Vlan8

C       172.22.0.0/22 is directly connected, Vlan1

C       172.22.125.0/24 is directly connected, Vlan125

S*   0.0.0.0/0 [1/0] via 192.168.252.130

On .1

   172.22.0.0/16 is variably subnetted, 3 subnets, 2 masks

C       172.22.127.254/32 is directly connected, Loopback0

S       172.22.8.0/22 [1/0] via 172.22.0.2

C       172.22.0.0/22 is directly connected, GigabitEthernet0/0

S*   0.0.0.0/0 [1/0] via 172.22.0.2

Anyways thanks for anyinformation you can provide.

[Peter Paluch]

Hello,

This is interesting! Hmmm... I assume that the 192.168.252.130 is the firewall whose loopback address you are tracerouting, right?

I wonder why would the .2 decide to send the traceroute to .1 at all. The routing table on .2 as you've shown it does not even mention the .1 anywhere. Do you perhaps run Policy Based Routing on the .2? It seems as if UDP packets (which are used by traceroute) were forwarded to .1 while the ICMP messages are routed normally.

If not, can you perform these tests?

1. traceroute 172.22.127.253 from .1
2. traceroute 172.22.127.253 from .2
3. show ip cef 172.22.127.253 internal on .2 (post the results here)
4. show adjacency X.X.X.X internal on .2 where X.X.X.X is the next hop address determined from the previous step (post the results here)
5. show ip arp X.X.X.X on .2 (post the results here)

Thank you!

Best regards,

Peter