Traceroutes - First-Tier FIOS support can't see/can't fix

[destruya]

For about the past 96 hours, I've had broken links outbound and inbound on traceroutes.  I was told Wednesday evening that there was a 'core router' problem in my immediate area, and that it'd be fixed within 12 hours, and that I'd be attached to the 'larger ticket' of those who'd had the same complaint.

According to Verizon, the problem's 'fixed,' but I'm still showing broken links in the chain:

C:\Users\pbdye>tracert www.verizon.com

Tracing route to e10696.g.akamaiedge.net [23.196.56.206]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  Wireless_Broadband_Router.home [192.168.1.1]
  2    17 ms     7 ms     6 ms  L100.WASHDC-VFTTP-100.verizon-gni.net [173.66.23
5.1]
  3     9 ms     9 ms     9 ms  G101-0-0-23.WASHDC-LCR-22.verizon-gni.net [100.4
1.135.166]
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6    47 ms    11 ms    11 ms  0.ae2.BR2.IAD8.ALTER.NET [140.222.229.169]
  7    10 ms    11 ms    10 ms  64.212.107.57
  8    10 ms    15 ms     9 ms  lag17-30G.csr2.DCA3.gblx.net [67.16.149.161]
  9    15 ms    13 ms    12 ms  akamai.ethernet14-1.csr2.dca3.gblx.net [64.214.1
29.106]
 10    12 ms    12 ms    11 ms  a23-196-56-206.deploy.static.akamaitechnologies.
com [23.196.56.206]

Trace complete.

I use verizon.com because I want to spend as little time outside the Verizon network as possible.  I know hops 4 and 5 are still within the FiOS network because I pretty routinely traceroute to find latency issues.  But trying to explain this to a first-tier tech is getting me nowhere, because all they're concerned with is 'does it work?,' and when the answer is 'yes,' anything that follows that seems to take on the tone of Charlie Brown's teacher.

They've already released my IP address, 'reset my router' (something I already did)...I'm trying to get to someone who actually *administrates* the FiOS network.

[destruya]

And it's not just outgoing - when I use a 'traceroute me' website, I get this path inward:

traceroute.exe to ({edited for privacy}), 30 hops max, 38 byte packets
 1  209.132.180.92 (209.132.180.92) [AS31976] hostmaster@redhat.com  0.429 ms  0.313 ms  0.317 ms
 2  transit-2-180-132-209.redhat.com (209.132.180.2) [AS31976] hostmaster@redhat.com  0.590 ms  0.519 ms  0.570 ms
 3  ip-163-181-132-209.redhat.com (209.132.181.163) [AS31976] hostmaster@redhat.com  0.452 ms  0.606 ms  0.421 ms
 4  te0-0-1-0.nr11.b019174-0.phx02.atlas.cogentco.com (38.88.238.29) [AS174] dns@cogentco.com  1.230 ms  1.210 ms  0.875 ms
 5  154.24.18.25 (154.24.18.25) [(null)] dns@cogentco.com  1.271 ms  1.503 ms  1.176 ms
 6  te0-4-1-6.ccr22.phx02.atlas.cogentco.com (154.54.1.229) [AS174] dns@cogentco.com  1.774 ms  1.701 ms  1.422 ms
 7  be2331.ccr22.lax01.atlas.cogentco.com (154.54.30.193) [AS174] dns@cogentco.com  13.213 ms  13.412 ms  13.397 ms
 8  be2179.ccr23.lax05.atlas.cogentco.com (154.54.41.82) [AS174] dns@cogentco.com  13.663 ms  13.728 ms  13.429 ms
 9  uunet.lax05.atlas.cogentco.com (154.54.13.86) [AS174] dns@cogentco.com  12.759 ms  12.921 ms  12.841 ms
10  * * *
11  * * *
12  pool-.washdc.fios.verizon.net ({edited for privacy}2) [(null)] dns@verizon.com  72.156 ms  72.805 ms  74.235 ms

[cf05]

I'm having the same issue. Just switched from Comcast expecting great things. A little dissapointed so far. During online games I have a great ping (15-20ms to a McLean, VA based server), but have really bad packetloss, no doubt in connection with the 4th hop timing out regularly. Hopefully this is temporary, otherwise I'll be pretty upset.

Tracing route to verizon.com [23.15.9.178]
over a maximum of 30 hops:

1 1 ms 1 ms <1 ms FIOS_Quantum_Gateway.fios-router.home [192.168.1
.1]
2 6 ms 6 ms 5 ms lo0-100.RCMDVA-VFTTP-302.verizon-gni.net [71.115
.29.1]
3 9 ms 9 ms 8 ms T0-5-0-7.RCMDVA-LCR-22.verizon-gni.net [100.41.1
30.140]
4 * * * Request timed out.
5 10 ms 17 ms 11 ms 0.xe-4-1-2.XL4.IAD8.ALTER.NET [152.63.32.21]
6 10 ms 11 ms 25 ms TenGigE0-7-0-4.GW1.IAD8.ALTER.NET [152.63.36.222
]
7 10 ms 12 ms 13 ms akamai.customer.alter.net [152.179.50.158]
8 12 ms 10 ms 10 ms a23-15-9-178.deploy.static.akamaitechnologies.co
m [23.15.9.178]

Trace complete.

[seitzbg]

Please try using:

http://sourceforge.net/projects/winmtr/

Also, the only thing that matters is the destination latency.  A lot of times routers de-prioritize ICMP and like others said a hop with * * * doesn't mean it's a 'bad' traceroute.  Post up some results with WinMTR.

[cf05]

To verizon.com below.

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| No response from host - 100 | 267 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 266 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 266 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 266 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 266 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 266 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 266 | 0 | 0 | 0 | 0 | 0 |
|a72-247-9-112.deploy.akamaitechnologies.com - 5 | 266 | 255 | 16 | 19 | 52 | 18 |
|________________________________________________|______|______|______|______|______|______|
WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir ( stanimir@cr.nivis.com )

[seitzbg]

---

@cf05 wrote:

To verizon.com below.

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| No response from host - 100 | 267 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 266 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 266 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 266 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 266 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 266 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 266 | 0 | 0 | 0 | 0 | 0 |
|a72-247-9-112.deploy.akamaitechnologies.com - 5 | 266 | 255 | 16 | 19 | 52 | 18 |
|________________________________________________|______|______|______|______|______|______|
@WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir ( stanimir@cr.nivis.com )

---

This looks more like your router/gateway is blocking the packets.  It should look something like:

https://www.bsd-unix.net/seitz/screenshots/2015-04-18_2146.png

Also, try this version: http://sourceforge.net/projects/winmtr/files/WinMTR-v092.zip/download

[cf05]

This isn't pretty:

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| FIOS_Quantum_Gateway.fios-router.home - 7 | 112 | 105 | 0 | 1 | 11 | 1 |
|lo0-100.RCMDVA-VFTTP-302.verizon-gni.net - 3 | 128 | 125 | 4 | 8 | 86 | 7 |
| T0-5-0-7.RCMDVA-LCR-21.verizon-gni.net - 4 | 123 | 119 | 5 | 8 | 17 | 7 |
| No response from host - 100 | 27 | 0 | 0 | 0 | 0 | 0 |
| 0.ae1.BR1.IAD8.ALTER.NET - 6 | 116 | 110 | 10 | 13 | 65 | 14 |
| ix-20-0.tcore1.AEQ-Ashburn.as6453.net - 5 | 120 | 115 | 10 | 12 | 54 | 13 |
| if-2-2.tcore2.AEQ-Ashburn.as6453.net - 5 | 121 | 116 | 19 | 21 | 33 | 23 |
| if-11-2.thar2.NJY-Newark.as6453.net - 31 | 62 | 43 | 18 | 22 | 99 | 25 |
| if-14-14.tcore2.NTO-New-York.as6453.net - 5 | 120 | 115 | 17 | 21 | 158 | 26 |
| 63.243.128.69 - 5 | 120 | 115 | 16 | 18 | 23 | 18 |
| 63.243.128.10 - 4 | 124 | 120 | 16 | 19 | 52 | 19 |
|a184-26-44-96.deploy.static.akamaitechnologies.com - 5 | 120 | 115 | 16 | 19 | 142 | 25 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

[destruya]

Good, so it's not just me.  And thanks for the editing, Elizabeth.

This isn't a peak time issue, either - I do a lot of work at night during off-peak times, and hop #4 is still down.  Granted, it's better than before, when hops 3 *and* 4 were down, but obviously one regional router/gateway got fixed, and the other one's still malfunctioning.

And I know dropped hops don't necessarily mean it's a *bad* connection, but I've been having packet loss issues and intermittent yet noticeable latency.  It's one of those 'tiny violin' problems - for people who don't tax their connection, the problem isn't vexing...but for people who *do* have to rely on low-latency, it's maddening.

[destruya]

This has actually gotten worse.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\pbdye>tracert www.verizon.com

Tracing route to e10696.g.akamaiedge.net [23.10.113.11]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  Wireless_Broadband_Router.home [192.168.1.1]
  2     7 ms     7 ms     6 ms  L100.WASHDC-VFTTP-100.verizon-gni.net [173.66.23
5.1]
  3    13 ms    11 ms     9 ms  G0-13-1-1.WASHDC-LCR-21.verizon-gni.net [130.81.
109.182]
  4    83 ms    49 ms    39 ms  ae3-0.RES-BB-RTR1.verizon-gni.net [130.81.199.13
0]
  5     *        *        *     Request timed out.
  6    33 ms    35 ms    33 ms  0.ae11.GW1.MIA19.ALTER.NET [140.222.225.77]
  7    34 ms    34 ms    34 ms  akamai.customer.alter.net [63.65.188.50]
  8    33 ms    34 ms    34 ms  a23-10-113-11.deploy.static.akamaitechnologies.c
om [23.10.113.11]

Trace complete.

So...Hop 4 is resolving, albeit slowly, and now it's Hop 5 that's 'broken.'

EDIT: Nope, Hop 4 still isn't resolving on anything other than verizon.com or .net.

[tns2]

AGAIN, this is not a problem.  Its common for these routers to do slow responses often timing out.

[cf05]

---

@tns_2 wrote:

AGAIN, this is not a problem.  Its common for these routers to do slow responses often timing out.

You're a tenured forum member and an 'MVP' for your number of posts. I'm surprised to read such a dismissive comment.

Which routers are 'these routers'? Can you be more specific on frequency beyond than 'common'? Into perpetuity? Having a regular timeout at the same hop does cause slow responses and regular timeouts, resulting in packetloss that is causing me significant issues and headache.

Please explain to me how exactly this is not a problem? It may meet a threshold that could be considered satisfactory to some, but the simple fact is that my Comcast connection was more consistent and exhibited dramatically less packetloss. This is not what I signed up for.

[seitzbg]

---

@tns_2 wrote:

AGAIN, this is not a problem.  Its common for these routers to do slow responses often timing out.

---

This is correct, the hops with * * * are not a problem at all.  The hops where you actually have increased latency are also not a problem, unless it carries through past that hop towards your destination.  Packet loss is also bad.  * * * is not a bad traceroute, repeat it a few times 🙂

[CRobGauth]

Its not uncommon for some intermediate devices to no respond to a traceroute.

Doesn't mean anything is wrong.