Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Curious traceroute results - anyone seen this?

In a data center environment with three security zones, tracing from an appserver in the middle zone to a db server in the inner zone (through an FWSM) gives results like:

From appserverA

Tracing route to dbserver-42 [10.17.120.32]

over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 172.31.60.1

2 <1 ms <1 ms <1 ms dbserver-42 [10.17.120.32]

3 <1 ms <1 ms <1 ms dbserver-42 [10.17.120.32]

4 3 ms 3 ms 3 ms dbserver-42 [10.17.120.32]

5 5 ms 3 ms 3 ms dbserver-42 [10.17.120.32]

6 3 ms 3 ms 3 ms dbserver-42 [10.17.120.32]

Trace complete.

The IP config and route tables on both boxes look OK. Tracing from a different appserver to a different dbserver:

From appserverB

Tracing route to dbserver-41.domain.net [10.25.60.41]

over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 172.31.60.1

2 <1 ms <1 ms <1 ms dbserver-41.domain.net [10.25.60.41]

3 <1 ms <1 ms <1 ms dbserver-41.domain.net [10.25.60.41]

4 <1 ms <1 ms <1 ms dbserver-41.domain.net [10.25.60.41]

5 <1 ms <1 ms <1 ms dbserver-41.domain.net [10.25.60.41]

Trace complete.

---

Any idea what might cause this, and whether it could be impacting performance of the tcp database connections between these servers?

Thanks!

Paul

  • LAN Switching and Routing
2 ACCEPTED SOLUTIONS

Accepted Solutions

Re: Curious traceroute results - anyone seen this?

Hi this is happening because of ASA/PIX behaviour , which must be in between dbserver & host from where you are executing the traceroute.

The PIX does not support the traceroute command. When a traceroute is issued from the outside, the PIX

does not display its own interface IP address nor does it display the IP addresses of the inside networks.

The

destination address is displayed multiple times for each internal hop.

When NAT is enabled in PIX 7.0, the IP addresses of the PIX interfaces and the real IP addresses of the

intermediate hops cannot be seen. However, in PIX 7.0, NAT is not essential and can be disabled with the no

nat-control command. If the NAT rule is removed, the real IP address can be seen if it is a routeable one.

HTH..rate if helpful

Re: Curious traceroute results - anyone seen this?

To make ASA/PIX showup as hop in tracert you need to apply "set connection decrement-ttl" in "global_policy" in "default_class"

Apart from above need to allow ICMP type 11 & time-exceeded on outside interface of PIX/ASA.

HTH..rate if helpful..

3 REPLIES

Re: Curious traceroute results - anyone seen this?

Hi this is happening because of ASA/PIX behaviour , which must be in between dbserver & host from where you are executing the traceroute.

The PIX does not support the traceroute command. When a traceroute is issued from the outside, the PIX

does not display its own interface IP address nor does it display the IP addresses of the inside networks.

The

destination address is displayed multiple times for each internal hop.

When NAT is enabled in PIX 7.0, the IP addresses of the PIX interfaces and the real IP addresses of the

intermediate hops cannot be seen. However, in PIX 7.0, NAT is not essential and can be disabled with the no

nat-control command. If the NAT rule is removed, the real IP address can be seen if it is a routeable one.

HTH..rate if helpful

Re: Curious traceroute results - anyone seen this?

To make ASA/PIX showup as hop in tracert you need to apply "set connection decrement-ttl" in "global_policy" in "default_class"

Apart from above need to allow ICMP type 11 & time-exceeded on outside interface of PIX/ASA.

HTH..rate if helpful..

New Member

Re: Curious traceroute results - anyone seen this?

Thank you Satish for the very quick and helpful responses. Good to know this is "normal."

136
Views
5
Helpful
3
Replies
This widget could not be displayed.