Have you tried pinging bitly.com from PC1 as well as PC2? Keep in mind that not all systems will respond to the ICMP echo request packets issued by ping and traceroute commands. I tried ping bitly.com
from systems, one Linux, one Microsoft Windows, and one OS X system, at three locations. All showed "request timed out" or 100% packet loss, yet I could access the website from them. So it appears to me that the ICMP echo request packets are being blocked somewhere along the path.
That isn't unusual. Many companies and organizations will block that type of traffic for various reasons. Sometimes it is done at a firewall for security reasons, so that outside entities can't map their network. Sometimes routers won't respond or give such traffic very low priority for performance reasons, so you may see asterisks at some hops for those reasons even though the system is processing other types of network traffic nominally.
The screen shot you posted of output from a tracert command shows the round-trip times for packets sent to routers along the network path from the system running the command to the end host. I can see that the round-trip time (RTT) for packets to ix-0-100.tcore1.MLV-Mumbai-as6453.net [180.87.38.5]
is about 21 milliseconds. But then, at the next hop, if-9-5.tcore1.WYN-Marseille.as6453.net [80.231.217.17]
at hop 9, the RTT jumps dramatically to about 127 ms with one packet being lost. That's not a horrible RTT at that point, but it's not great either. When I ran a tracert to the www.bitly.com from three separate locations where network service is provided by three different Internet service providers, though all within a 50 mile radius, I see RTTs at that hop of about 11 ms at one location, 18 ms at another, and 71 ms at the third. At hop 20 for your tracert, the RTT is up to about a quarter of a second. Again, that's not horrible, but it isn't great, either.
Though I don't think the tracert output you posted can be used to discern the cause of the discrepancy between systems on your local area network (LAN). I also see all asterisks for hops after te1-2.r1.colo-fo.ilg1.vrsn.net [69.58.176.198]
in most cases, though I saw the next hop 69.58.176.194 respond occasionally, so, perhaps there is some network congestion at that hop or the router is giving a very low priority to ICMP traffic.
I am able to access www.bitly.com from a browser, though, and when I tested the response time for the site from pingdom.com it showed a good response time for the website from Stockholm in Sweden stating the "website is faster than 49% of all tested websites". A WebsitePulse test also showed a good response time.
So to explain the discrepancy between systems on your LAN, are the results consistent? E.g., have you tried several time to access www.bitly.com from both PC1 and PC2 and can you consistently access www.bitly.com from PC2, but not PC1? And have you tested access to Facebook from both systems multiple times? Are both systems using the same network path to get access to external websites? E.g., is one using wireless network connectivity while the other is using a wired connection? Are you using the same DNS servers for both systems? You can check to see if both systems are using the same router as the first hop and are using the same Domain Name System (DNS) servers on Microsoft Windows systems using the command ipconfig/all
. Do they have the same default gateway and DNS servers? Are you testing with the same browser on both systems? Is the browser on one system configured to use a proxy server, while the other does not use a proxy server?
1Is it always like that or does it occur only at times. I also used to have such a problems which corrects by itself. It might be a problem with ISP. Try a hard refresh. – sajinmp – 2015-06-27T08:27:57.980
Does the situation the same after changing DNS IP settings? – Renju Chandran chingath – 2015-06-27T12:47:36.110