Hello I have a trace route issue, see attached
traceroute to 22.214.171.124 (126.96.36.199), 64 hops max, 72 byte packets
1 192.168.1.1 (192.168.1.1) 16.214 ms 5.087 ms 7.336 ms
2 188.8.131.52 (184.108.40.206) 16.093 ms 16.578 ms 12.706 ms
3 220.127.116.11 (18.104.22.168) 10.776 ms 16.932 ms 23.620 ms
4 22.214.171.124 (126.96.36.199) 37.490 ms 11.132 ms 13.785 ms
5 * lag-8.ear1.miami1.level3.net (188.8.131.52) 21.073 ms 16.955 ms
6 * ae-2-30.bear2.phoenix1.level3.net (184.108.40.206) 64.248 ms 69.327 ms
7 220.127.116.11 (18.104.22.168) 62.780 ms 304.650 ms 364.532 ms
8 22.214.171.124 (126.96.36.199) 794.598 ms 66.284 ms 63.604 ms
9 be39.trmc0215-01.ars.mgmt.phx3.gdg (188.8.131.52) 65.271 ms 65.384 ms 67.281 ms
10 ip-97-74-255-129.ip.secureserver.net (184.108.40.206) 64.658 ms 65.449 ms 68.271 ms
11 p3nlhg282c1282.shr.prod.phx3.secureserver.net (220.127.116.11) 66.786 ms 81.969 ms 66.231 ms
I tried from my office and also from home, the same issue with level3.
I contacted level3 but they told me to ask comcast to call them to fix the issue.
I already tried contact a representative on the chat with no response on the issue.
Can you please help?
The trace route is not revealing a problem.
It completed to the destination server with a normal amount of latency. The intermediate hops do not matter. Are you actually experiencing any issues or just focusing on the trace output ?
Any way to change the route?
I had the same issue at my office, sometimes I can't even access my own website, and the VOip phones stop working for the same issue with level3. they are too slow and inestable
No. No way. It's not even an issue. What performance issue are you having ? As stated only the last hop matters, and it's normal. And that is only one single destination. You may have something else going on
I see the latency after level3 is very high considering the others before level3
It doesn't work that way. Those hops with the (alleged) higher latency are just routers that are configured to de-prioritize / rate limit ICMP based ping packet probes as the latency isn't carrying through to the farther upstream hops or the destination server. It's not true latency. This is not to say that you are not actually experiencing an issue, it just that something else is going on.