Regarding trace route

[satyammehrotra7779309]

Hi Guys,

I want to understand the out of the above traceroute for a web app.

I cannot open my web page and I want to know till which point the connection is going?

1) Can anyone please explain what line number 7 and 8 mean?

2)How come lines 9 and 10 replied if the 7&8 request timed out?

[Flavio Miranda]

Hi

 No logs have been attached.

Is it the page your are trying to access on the internet?  or it is a intranet page? 

[satyammehrotra7779309]

It's a Cisco VC solution. It is placed in our DC and the problem is that with some ISP we can access it but with a few, we can't.

So, I was trying to find if the people who can't open it from their internet, have their required ports blocked by their respective ISP's.

Because I think it can't be from our DC firewall side since many can people access it across the internet.

I just want to understand is whether the traffic is reaching 203.190.248.10 (Line 10) and what does lines 7 and 8 means.

[Richard Burts · Accepted solution]

There are many things about this that we do not know and that impacts our ability to fully answer about what is going on. The original poster asks 2 specific questions and we can answer them. First let us remember the basics of how traceroute (or tracert depending on platform) works. Traceroute works by sending probe packets toward the destination and manipulating the time to line of the probe packet. The first probe has RRL of 1. It gets to the first hop and times out. The device receiving the probe and setting TTL to 0 may send an ICMP error message and if so the originating device shows that hop. If the device does not send the ICMP error message then the originating device regards that as a time out. So the answers to the questions are:

1) lines 7 and 8 indicate that the device(s) that received the probe packet did not generate the ICMP error message. The originating device shows that as timeout and continues to increment the TTL and send probe packets.

2) 9 and 10 replied because they received probe packets and did send the ICMP error message.

The traceroute output does not explain why the web page is not working. But if the IP that appears to be the target of the traceroute is the device where the web page is hosted then it does indicate that IP connectivity is not the cause of the problem.

[Richard Burts]

While I was typing my response the original poster provided additional information and asked another question: "I just want to understand is whether the traffic is reaching 203.190.248.10 (Line 10) and what does lines 7 and 8 means." 

Based on the traceroute output we can say that yes the traffic is reaching 203.190.248.10. My previous response explained that 7 and 8 simply mean that the devices that received the probe packets and decremented the TTL to zero did not send the ICMP error message. But the traceroute continued to process to further next hops.

[satyammehrotra7779309]

Hi Richard,

Thanks for your help. This was exactly what I was looking for and I will mark this as an answer.

Further, the last IP 203.190.248.10 is one of our WAN IPs (we have more than 100 Public IPs).

What I want to ask is we created a single NAT rule in our Firewall from Any WAN which translates to our internal VC server.

I am confused because some people can connect from outside and some cannot. The only reason that comes into my mind is the port required by Cisco VC is blocked by some of the IPs. Is there any guess what could be the reason.

[Richard Burts]

You are welcome. I am glad that my explanations have been helpful. I am a little puzzled about the additional information and the question that you ask. In my initial response I commented that there are things that we do not know. That includes information about where the traceroute came from and what was the destination of the traceroute. I was assuming that the destination of the traceroute was 203.190.248.10 and that traceroute had gotten to the destination.  If that is right then the output looks fairly normal. But if that address is your WAN then perhaps the server address is different? And maybe the traceroute output is not so normal?

If you want to investigate further I might suggest these steps:

- get a traceroute from somewhere that does work and a traceroute from somewhere that does not work. Compare the outputs. The lines at the beginning will almost certainly be different - and that is to be expected. The important thing is whether the last several lines are the same or are different.

- check with some people who are successful and with some people who are not successful. Is there any possibility that there is some difference in how they access it? Is there any possibility that the DNS resolves to a different address for the people who are successful and for the people who are not successful?

- I have had experience with some customers who were having issues access some web sites. It turns out that somewhere along the data path their traffic was going through a vpn (or through a tunnel) and the extra packet length was causing issues because of fragmentation. Is that possibly the case here?

Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.

[satyammehrotra7779309]

Super thanks to you Rick. I did exactly the same you told me (tracert with one working and the other not working) and it turns out that LB was sending the packets to the wrong IP. It's fixed now.

[Richard Burts]

You are quite welcome. I am glad to know that my suggestions did help you to identify and fix the problem. Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.