Lukasz

I am not quite clear when you say that the last hop appears twice whether you mean something like this:

traceroute 10.26.67.226

Type escape sequence to abort.

Tracing the route to 10.26.67.226

1 10.26.68.1 24 msec 24 msec 28 msec

2 10.26.67.226 44 msec * 48 msec

where there are 2 response times reported or whether you mean something else.

If this is what you mean then I believe that the explanation is that the router to which you are doing the traceroute is rate limiting its responses, so that it responds to the first probe, rate limits its response to the second probe, and responds to the third probe.

If you meant something different then perhaps you can post an example of what you are talking about.

HTH

Rick

Rick:

I took it to mean that the last hop (the entire line) appears twice (sometimes more) when doing the trace.

Example (last hop):

10.26.68.1 24 msec 24 msec 28 msec

10.26.68.1 24 msec 24 msec 28 msec

10.26.68.1 24 msec 24 msec 28 msec

Thats happened to me, so thats how I interpreted his problem.

Victor

Victor

I can think of 2 logical explanations for the situation that you describe.

1) when the traceroute reaches the destination, the destination station should respond with some response other than the time exceeded (if it is a Cisco/Unix traceroute using UDP packets it should respond with port unreachable and if it is a Windows traceroute using echo request it should respond with echo response). As long as the sending station receives time exceeded messages (or some other response which is not interpreted as being the destination) it should continue to increment the TTL and send probes again. So your situation could be caused if the destintion is not sending the expected response.

2) there could be some firewall (or similar device) which is intercepting the probe packets and sending some response such as time exceeded.

It would be interesting to know what situation Lukasz has been dealing with.

HTH

Rick

Hello

Sorry I was on holidays.

It does not meter which server we are trying to trace. Every time we received two answers as the last hop. We try a trace from a PC and from a Cisco router but every time the result is the same.

We have a L2 FW on the road of the packets between the station that is doing ping and the final server.

When I have tried to do the trace on the path that do not pass the L2 FW the last hop appears only once.

I have attached the general diagram of the network. I am doing a trace from the PC to the SRV.

Regards

Lukasz

Lukasz

I have looked at the diagram that you posted and it helps a bit to understand the situation. It would be even more helpful if you would post the output from the trace.

Also from the diagram it looks like the router that is connected to the PC would have 2 paths (2 routes) to the subnet where the server is located. If that router were doing per packet load sharing it might explain the symptoms that you describe. Would you post the config of the router to which the PX is connected?

HTH

Rick

Hello

It is true that the router with PC 2 (router X) has two redundant paths to the same destination. It is using CEF with the default per-destination load-balancing.

Unfortunately I cannot post the config.

The output looks quite simple

RouterX#traceroute 192.168.0.1

Type escape sequence to abort.

Tracing the route to 192.168.0.1

1 192.168.0.1 0 msec 0 msec 0 msec

2 192.168.0.1 4 msec 0 msec 0 msec

Lukasz

Given the limited amount of information we do not know for sure. But at this point I would agree with Victor that it is most likely that the firewall is the one that is generating the responses and is responsible for the multiple entries with the same address.

HTH

Rick

Hello

We have found out that we were missing the fixup for icmp errors on our FW.

After we configure it the trace looks correctly.

Thanks

Lucas

Lucas

Thank you for posting back to the forum and indicating that the problem was solved and what the solution of the problem was. I am glad that Victor and I correctly suspected that it was a firewall issue. It makes the forum more useful when people can read about a problem and can read what resolved the problem.

The forum is an excellent place to learn about Cisco networking. I encourage you to continue your participation in the forum.

HTH

Rick