Ping, but can't trace?

[bradjones]

I am able to ping a device on another network, however I can NOT complete a trace to that device.

Any ideas???

Thanks for your imput.

-Brad

[smif101]

Do you even get your default gateway to show up with the trace? If so it might be getting blocked by a firewall.

[bradjones]

I have an extended access-list on both router, but I have disabled them.

During the trace from a PC on the network, I hit the gateway then get timeouts. If I trace from the router using the WAN or LAN interface as the source I am able to successfully trace to the end device and see all the hops.

[Harold Ritter]

Make sure the subnet from which you are tracing is advertised by your routing protocol.

Hope this helps,

[Richard Burts]

The original post stated that he could ping to the destination but not trace to it. If that is true then the subnet is being advertised. And it demonstrates successful IP connectivity - he has valid routes to get there and they have valid routes to get back.

In my experience when one type of IP traffic is successful (ping in this case) and other types of IP traffic are not (trace in this case) it is almost always a problem of filtering by someone along the path or something like policy routing that changes the path for some types of traffic.

HTH

Rick

[Harold Ritter]

Makes sense. I omitted to read the first post. Certainly looks like an ACL issue.

Thanks,

[bradjones]

Is this something that my ISP is doing???

As I mentioned, I have disabled the ACL's on both of my routers.

What is the difference between a ping and a trace... they are both ICMP traffic - right?

[Harold Ritter]

In your previous post, you mention "I hit the gateway then get timeouts", which probably means tat the culprit is the next device in the path.

There is indeed a difference between ping and traceroute depending on what platform you use. On a Cisco router (and on most unix hosts) traceroute is implemented by sending UDP packets instead of icmp packets. So an ACL might allow one but not the other. On MS OSes, icmp packets are used to implement traceroutes. Is the host you are using for the trace Unix or MS based?

Hope this helps,

[bradjones]

The device on the network that I am tracing from is a WinXP Pro workstation.

I am able to trace to that workstation from the router.

[bradjones]

I have done some more testing and have discovered that I can successfully ping and trace to that network device is I do so from a Unix workstation, but if I try to trace from a Windows PC I am unsuccessful.

What's up with that?

[Richard Burts]

If trace worked from one but not the other I could understand that because as Harold has explained the MicroSoft implementation of tracert uses ICMP while the Unix (and Cisco) implementation of traceroute use UDP.

But what I think you are saying here is that both ping and trace work from the Unix workstation and both ping and tracert fail from the Windows PC. If I am understanding correctly what you are describing then it sounds to me like there must be some difference in IP addressing between the Unix and the Windows devices. Can you verify how they are configured (especially what IP addresses, what netmask, and what default gateway)?

HTH

Rick

[bradjones]

Windows NT4.0 Server:

IP: 192.168.4.21/24

GW: 192.168.4.1

* Successful Ping

* Unsuccessful Trace

Windows XP Pro PC:

IP: 192.168.4.120/24

GW: 192.168.4.1

* Successful Ping

* Unsuccessful Trace

HPUX 11.1 Server:

IP: 192.168.4.25/24

GW: 192.168.4.1

* Successfull Ping

* Successfull Trace

==================================================================================

TRACEROUTE FROM WINDOWS NT4.0 SERVER (192.168.4.21) TO CBCR ROUTER (192.168.25.1)

CBCR#

02:28:29: UDP: rcvd src=192.168.4.21(137), dst=192.168.25.1(137), length=58

02:28:29: ICMP: dst (192.168.25.1) port unreachable sent to 192.168.4.21

02:28:30: UDP: rcvd src=192.168.4.21(137), dst=192.168.25.1(137), length=58

02:28:30: ICMP: dst (192.168.25.1) port unreachable sent to 192.168.4.21

02:28:32: UDP: rcvd src=192.168.4.21(137), dst=192.168.25.1(137), length=58

02:28:32: ICMP: dst (192.168.25.1) port unreachable sent to 192.168.4.21

CBCR#

** Windows uses netbios-ns (UDP 137) for traceroute.

==================================================================================

TRACEROUTE FROM UNIX WORKSTATION (192.168.4.25) to CBCR ROUTER (192.168.25.1)

CBCR#

02:30:37: UDP: rcvd src=192.168.4.25(45578), dst=192.168.25.1(33438), length=28

02:30:37: ICMP: dst (192.168.25.1) port unreachable sent to 192.168.4.25

02:30:37: UDP: rcvd src=192.168.4.25(45578), dst=192.168.25.1(33439), length=28

02:30:42: UDP: rcvd src=192.168.4.25(45578), dst=192.168.25.1(33440), length=28

02:30:42: ICMP: dst (192.168.25.1) port unreachable sent to 192.168.4.25

CBCR#

** Unix uses a random UDP ports for traceroute.

==================================================================================

PING FROM UNIX WORKSTATION (192.168.4.25) TO CBCR ROUTER (192.168.25.1)

CBCR#

02:35:01: ICMP: echo reply sent, src 192.168.25.1, dst 192.168.4.25

02:35:02: ICMP: echo reply sent, src 192.168.25.1, dst 192.168.4.25

02:35:03: ICMP: echo reply sent, src 192.168.25.1, dst 192.168.4.25

02:35:09: ICMP: echo reply sent, src 192.168.25.1, dst 192.168.4.25

02:35:10: ICMP: echo reply sent, src 192.168.25.1, dst 192.168.4.25

CBCR#

===================================================================================

PING FROM UNIX WORKSTATION (192.168.4.25) to WINDOWS WORKSTATION (192.168.25.100)

nothing logged.

===================================================================================

[Richard Burts]

I am assuming that what you have posted is output from the target (CBCR) which was running debug ip icmp.

I would say that at least from the perspective of the CBCR router that both traces were successful. The probe packet got to the target router and the target router responded with ICMP port unreachable - which is the correct response that lets you know that you got to the target and do not need to increment the TTL any more. If responses get back to one device but do not get back to another device, I would think first that maybe they are forwarded to one and filtered from the other. But since the devices are all on a common subnet that does not seem likely. Is there possibly any kind of internal firewall on the Windows boxes that is denying the port unreachable response to the Windows boxes?

HTH

Rick

[spremkumar]

hi

they might hve blocked 92Byte ICMP packet which is being created by Nachi worm and blocked in most of the isps using route-maps .

u can try out from unix or linux box if u r hving one coz those boxes uses jacbson trace..

regds

[peter.mainwaring]

If it is a problem with a 92byte ping, why not try ping -l 128 a.b.c.d - this will make the packet size 128 bytes (well, its bigger than that actually with the headers etc.), but it should prove whether or not there is a block on 92 byte ICMP packets.

Pete