- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
NOC... NOC...
Tracing route to 63.109.222.1 over a maximum of 30 hops
1 2 ms 1 ms 1 ms 192.168.1.1
2 7 ms 7 ms 7 ms l100.washdc-vfttp-150.verizon-gni.net [71.191.56.1]
3 8 ms 11 ms 11 ms g1-8-4-4.washdc-lcr-22.verizon-gni.net [100.41.203.32]
4 60 ms 7 ms 7 ms ae6-0.res-bb-rtr2.verizon-gni.net [130.81.199.146]
5 * * * Request timed out.
6 * * * Request timed out.
7 11 ms 12 ms 11 ms 0.ae3.XT2.DCA5.ALTER.NET [140.222.225.199]
8 18 ms 15 ms 14 ms 0.xe-5-2-0.XL2.RIC3.ALTER.NET [152.63.3.174]
9 17 ms 15 ms 15 ms 0.xe-11-1-0.GW1.RIC3.ALTER.NET [152.63.41.218]
10 21 ms 19 ms 19 ms idp-gw.customer.alter.net [152.179.157.14]
11 21 ms 22 ms 23 ms 63.109.222.1
Trace complete.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What exactly is the issue that you're having? Routers can be configured to not respond to ICMP under higher loads, or in all cases.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is definitely a dropped route. Where I work, when I was using this route my calls would drop, not come through at all, or have horrible quality. Using a VPN that had a Tampa server stopped the problem by routing through the Level 3 backbone. This also had a side effect of adding latency.
Because of the loss of packets and issues, I had to switch providers to keep my job.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't see anything wrong with the traceroute personally, those aren't true time outs, if they were true time outs, your packets wouldn't have made it to the destination. Also there's no incrimental increase in latency that would indicate any kind of packet loss or latency issues.