Can ping but not Trace

[js358]

Hello:

Have our network segmented with a 3620 sitting in the middle. 1x sitting behind a firewall. 2x sitting behind another.

I can ping back and forth between the segments but. i cannot successfully trace. It hits the same interface on the 3620 and then dies......what can be the problem?

Thanks

[Kevin Dorrell]

The way trace works is to send out a packet with a time-to-live of 1. This hits the first router, which sends back an ICMP "TTL expired". You then send out a packet with a TTL=2, this gets as far as the second router, which then sends back an ICMP "TTL expired". You then send out a packet with TTL=3 ... you get the picture.

This relies on each router in the chain sending back an ICMP response when is gets a packet whose TTL has reached 1. If the router does not generate the ICMP, then no trace. Many firewalls do b^not generate ICMP "expired" messages.

It also depends on each element of the chain allowing ICMP "expired" messages to be delivered back to the tracing machine. Many firewalls do not, so the trace would be broken as soon as it reaches such a firewall.

Maybe that is what is happening.

Kevin Dorrell

Luxembourg

[js358]

Thanks...that's exactly what's happening then because the next hop is a firewall. My question I guess now would be exactly what does this mean as far as operability between the 2 segments. I can ping so connectivity is there...

From what you know from this post, will this have any negative affect?

Thanks again for your help.

JS

[Kevin Dorrell]

The reachability from one segment to the other will be determined by the firewall and the routing. The trace facility is merely a convenience for the NetAdmin, and has no direct impact on the real production traffic. By the same token, it is also a convenience to hackers, which is why most firewall will not give away (or even pass) information in an ICMP "expired". If you can ping from one segment to another, you already know that the routing is OK. Any other stuff that doesn't work - look first to the firewall rules.

Kevin Dorrell

Luxembourg

[js358]

Thanks alot Kevin - I'm kinda new to cisco/routing and you have been a big help.

JS

[marikakis]

Viewing the path that packets take with trace is useful

in troubleshooting cases where packets are routed to the final destination,

but you still want to verify that packets take the path you want them to take.

Common ping sends ICMP echo requests and receives ICMP echo replies.

Unix/cisco traceroute sends UDP traffic, and receives back

ICMP time exceeded from intermediate nodes

until the final destination is reached.

The final destination sends ICMP port unreachable.

The windows tracert is different from the traceroute utility found in unix/cisco devices.

The windows tracert has similar logic with the common ping utility,

in that it sends ICMP echo requests and receives ICMP echo replies.

Since you can successfully ping, you have many chances

to be able to tracert from a windows workstation.

To make a trace from a unix workstation work

like a windows tracert would, try the option :

traceroute -I

If you want a trace from a router to work or the above windows/unix trace fails,

you should probably have a look at your firewall as Kevin suggests,

and check your policy regarding UDP,

ICMP time exceeded , and ICMP port unreachable traffic.

M.