Topic 'Re: Bad Gateway' in forum 'Time Warner Internet Services' - dslreports.com

Re: Bad Gateway

Wed, 07 Nov 2012 17:29:43 EDT

Napsterbater posted : Still 93ms at the destination just like your first post, so I say not different.

Re: Bad Gateway

Wed, 07 Nov 2012 15:21:44 EDT

bluepoint posted : It's getting better. :)

Host Information for "myservices.timwewarnercable.com":  IP address:   69.43.161.162  Host name:    myservices.timwewarnercable.com Tracing route to "69.43.161.162" over max. 30 hops:    1:     0 ms  192.168.1.1   2:    30 ms  68.174.228.1    (cpe-68-174-228-1.si.res.rr.com)   3:    15 ms  24.164.129.218  (24-164-129-218.si.rr.com)   4:    15 ms  24.164.128.34   (tenge-0-4-0-4-nycmny1-rtr02.si.rr.com)   5:     0 ms  184.152.112.147 (bun119.nycmnytg-rtr001.nyc.rr.com)   6:     0 ms  24.29.148.250   (bun6-nycmnytg-rtr002.nyc.rr.com)   7:    15 ms  107.14.19.24      8:    15 ms  66.109.6.161    (ae-1-0.pr0.nyc30.tbone.rr.com)   9:    15 ms  216.55.0.65      10:    78 ms  216.156.0.21    (vb1011.rar3.washington-dc.us.xo.net)  11:    78 ms  207.88.12.9     (te-3-0-0.rar3.atlanta-ga.us.xo.net)  12:    93 ms  207.88.12.2     (te-3-0-0.rar3.dallas-tx.us.xo.net)  13:    79 ms  216.156.0.126   (ae0d0.mcr2.sandiego-ca.us.xo.net)  14:    78 ms  216.55.27.26     15:    95 ms  69.43.169.112   (ge5-2-6509-a.castleaccess.com)  16:   109 ms  69.43.129.188    17:    93 ms  69.43.161.162   The target host "69.43.161.162" have been reached. Query finished.

Re: Bad Gateway

Tue, 06 Nov 2012 13:14:34 EDT

DrDrew posted :

said by bluepoint:

It's true all the traceroute I posted have good acceptable hop readings except for the gateway but before this storm, those hops that answers @15ms were @10ms or less.

15ms is still EXCELLENT, especially 4 hops out.

Besides the last hop time is what matters. If it's 90ms now and the intermediate hops drop to 5ms, the last hop can still be 90ms and that 10ms drop on the intermediate hops won't have made any difference. If that gateway hop starts responding, even at 30ms, and the last hop is still at 90ms, again it won't have made any difference.

Just for some perspective.... a blink of an eye take 200-300ms.
--
If it's important, back it up... twice. Even 99.999% availability isn't enough sometimes.

Re: Bad Gateway

Tue, 06 Nov 2012 12:51:54 EDT

bluepoint posted :

said by djrobx:

What a lot of us are trying to tell you is that ICMP deproritization in routers is common, not specifically indicative of a problem, and that you should focus on a different method of testing.

I understand deprioritation in routers, what I'm trying to figure out is, why is the gateway not responding anymore, is it because Sandy made a damage to the infrastructure? It used to answer to pings within 30ms or less anytime since I have this service before Sandy and now it's taking a very long time to answer the request(timeout). You agree with me it's harder to diagnose performance problem without the missing data. It's easy to say to ignore the gateway not answering and focus on the rest of the hops. It's true all the traceroute I posted have good acceptable hop readings except for the gateway but before this storm, those hops that answers @15ms were @10ms or less. If you were a gamer, those are better ping times. All I'm saying here is, I understand Sandy made some damages in our area and probably is the cause of all of these abnormal readings. I've checked the maintenance site in my area and there are areas that are still down plus hub maintenances this week and next. Maybe this is just a temporary setback, I believe once TWC lit the rest of my area and finish the maintenance next week, it will be back to normal.

Re: Bad Gateway

Tue, 06 Nov 2012 11:14:11 EDT

DrDrew posted :

said by bluepoint:

You were correct ps3.sony.com is non existent.
Trying myservices now, the gateway is back to not responding.

The gateway not responding doesn't really seem to have any particular effect on your connection from the traces you've posted, a mere pothole on your data highway. The several hops following the gateway all seem to be responding with good times. Even the last hop times are good and never unusual.

For now I'd say ignore your odd gateway IP response and look for some other symptoms that coincide with your son's gaming problems.
--
If it's important, back it up... twice. Even 99.999% availability isn't enough sometimes.

Re: Bad Gateway

Tue, 06 Nov 2012 10:05:31 EDT

djrobx posted :

That's what I'm trying to point at the router is busy. Why was it pinging 30ms before the storm and 2000ms now? What do you think happens? Wouldn't you think gaming will be affected?

No one but the techs working on the network can tell you what's different and why.

What a lot of us are trying to tell you is that ICMP deproritization in routers is common, not specifically indicative of a problem, and that you should focus on a different method of testing. When I had AT&T U-verse, the gateway only responded to me very early in the morning.

For what it's worth, I don't like it either. Without having reliable traces, it's much harder to be able to clearly identify where performance bottlenecks begin.
--
AT&T U-Hearse - RIP Unlimited Internet 1995-2011
Rethink Billable.

Re: Bad Gateway

Tue, 06 Nov 2012 00:01:37 EDT

bluepoint posted : You were correct ps3.sony.com is non existent.
Trying myservices now, the gateway is back to not responding.

Host Information for "myservices.timwewarnercable.com":  IP address:   69.43.161.162  Host name:    myservices.timwewarnercable.com Tracing route to "69.43.161.162" over max. 30 hops:    1:     0 ms  192.168.1.1   2:     *     Request timed out.   3:    15 ms  24.164.129.218  (24-164-129-218.si.rr.com)   4:    15 ms  24.164.128.34   (tenge-0-4-0-4-nycmny1-rtr02.si.rr.com)   5:    22 ms  184.152.112.147 (bun119.nycmnytg-rtr001.nyc.rr.com)   6:    15 ms  24.29.148.250   (bun6-nycmnytg-rtr002.nyc.rr.com)   7:    15 ms  107.14.19.24      8:    15 ms  66.109.6.161    (ae-1-0.pr0.nyc30.tbone.rr.com)   9:    15 ms  216.55.0.65      10:    93 ms  216.156.0.21    (vb1011.rar3.washington-dc.us.xo.net)  11:    93 ms  207.88.12.9     (te-3-0-0.rar3.atlanta-ga.us.xo.net)  12:    93 ms  207.88.12.2     (te-3-0-0.rar3.dallas-tx.us.xo.net)  13:    94 ms  216.156.0.126   (ae0d0.mcr2.sandiego-ca.us.xo.net)  14:    93 ms  216.55.27.26     15:   286 ms  69.43.169.112   (ge5-2-6509-a.castleaccess.com)  16:    93 ms  69.43.129.188    17:    78 ms  69.43.161.162   The target host "69.43.161.162" have been reached. Query finished.

BTW, I ask my son about the server name were his PS3 connects when he plays, he doesn't know. He said it just connects. :huh:

Re: Bad Gateway

Mon, 05 Nov 2012 22:20:38 EDT

DrDrew posted :

said by bluepoint:

PS3.sony.com does exist.

You don't even understand what you're looking at. Check the IP and traces for dsjflsdjfllsdjlsdjfljsdfljsdf.com and compare them to ps3.sony.com

What you are seeing is the result of OpenDNS non-existent domain redirects. Use another, non-redirecting, DNS server or disable OpenDNS "Domain Typos>Enable typo correction" and try those traces and whois again.

You will find ps3.sony.com doesn't exist.
--
If it's important, back it up... twice. Even 99.999% availability isn't enough sometimes.

Re: Bad Gateway

Mon, 05 Nov 2012 21:33:11 EDT

hobgoblin posted : "People who have an idea, probably not you."

Thanks for that, You probably have one of the most knowledgeable person I know posting in the thread but you appear to be looking for an answer that satisfies you rather than listening to facts.

Oh well. Maybe one of the New York City Network engineers will wander in and fill you in on all the facts. Don't hold your breath.

Hob
--
"A foolish consistency is the hobgoblin of little minds."
- Ralph Waldo Emerson

Re: Bad Gateway

Mon, 05 Nov 2012 20:59:50 EDT

bluepoint posted :

said by hobgoblin:

Who do you think is going to give you a factual answer here?

Hob

People who have an idea, probably not you. :uhh:

Re: Bad Gateway

Mon, 05 Nov 2012 20:43:38 EDT

hobgoblin posted : I am trying to remember how many times I have seen this discussion.

This made me smile

"All you're saying are guesses, I want a factual answer and I posted to get an answer and not to argue. I want to know why the gateway used to ping 30ms and now answering @2000ms or not at all."

Who do you think is going to give you a factual answer here?

Hob
--
"A foolish consistency is the hobgoblin of little minds."
- Ralph Waldo Emerson

Re: Bad Gateway

Mon, 05 Nov 2012 20:01:21 EDT

bluepoint posted : That's what I'm thinking that's why I'm waiting a bit for the smokes to clear. If you see my last trace, its back responding in the hundreds now, a little better.

Re: Bad Gateway

Mon, 05 Nov 2012 19:48:53 EDT

bluepoint posted :

said by DrDrew:

said by bluepoint:

My last post, the first trace, is to ps3.sony.com.

No... 67.215.65.132 it's actually the non-existent domain reply server from OpenDNS.

ps3.sony.com doesn't exist.

PS3.sony.com does exist.

Host Information for "ps3.sony.com": IP address: 67.215.65.132 Host name: ps3.sony.com Domain name: sony.com Top level: COM (Commercial) Domain Query Domain query for "sony.com" at "whois.internic.net": Whois Server Version 2.0 Domain names in the .com and .net domains can now be registeredwith many different competing registrars. Go to http://www.internic.netfor detailed information. Server Name: SONY.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM IP Address: 203.36.226.2 Registrar: INSTRA CORPORATION PTY, LTD. Whois Server: whois.instra.net Referral URL: http://www.instra.com Domain Name: SONY.COM Registrar: CSC CORPORATE DOMAINS, INC. Whois Server: whois.corporatedomains.com Referral URL: http://www.cscglobal.com Name Server: PDNS1.CSCDNS.NET Name Server: PDNS2.CSCDNS.NET Status: clientTransferProhibited Updated Date: 02-jul-2012 Creation Date: 07-jul-1989 Expiration Date: 06-jul-2014 >>> Last update of whois database: Tue, 06 Nov 2012 00:43:50 UTC <<< NOTICE: The expiration date displayed in this record is the date the registrar's sponsorship of the domain name registration in the registry is currently set to expire. This date does not necessarily reflect the expiration date of the domain name registrant's agreement with the sponsoring registrar. Users may consult the sponsoring registrar's Whois database to view the registrar's reported date of expiration for this registration. TERMS OF USE: You are not authorized to access or query our Whois database through the use of electronic processes that are high-volume and automated except as reasonably necessary to register domain names or modify existing registrations; the Data in VeriSign Global Registry Services' ("VeriSign") Whois database is provided by VeriSign for information purposes only, and to assist persons in obtaining information about or related to a domain name registration record. VeriSign does not guarantee its accuracy. By submitting a Whois query, you agree to abide by the following terms of use: You agree that you may use this Data only for lawful purposes and that under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail, telephone, or facsimile; or (2) enable high volume, automated, electronic processes that apply to VeriSign (or its computer systems). The compilation, repackaging, dissemination or other use of this Data is expressly prohibited without the prior written consent of VeriSign. You agree not to use electronic processes that are automated and high-volume to access or query the Whois database except as reasonably necessary to register domain names or modify existing registrations. VeriSign reserves the right to restrict your access to the Whois database in its sole discretion to ensure operational stability. VeriSign may restrict or terminate your access to the Whois database for failure to abide by these terms of use. VeriSign reserves the right to modify these terms at any time. The Registry database contains ONLY .COM, .NET, .EDU domains andRegistrars. The response of "whois.internic.net" points to the Whois server "whois.corporatedomains.com". Network Query Network query for "67.215.65.132" at "whois.iana.org": % IANA WHOIS server% for more information on IANA, visit http://www.iana.org% This query returned 1 object refer: whois.arin.net inetnum: 67.0.0.0 - 67.255.255.255organisation: ARINstatus: ALLOCATED whois: whois.arin.net changed: 2001-05source: IANA The response of "whois.iana.org" points to the Whois server "whois.arin.net". Query finished.

Re: Bad Gateway

Mon, 05 Nov 2012 19:17:56 EDT

DrDrew posted :

said by bluepoint:

My last post, the first trace, is to ps3.sony.com.

No... 67.215.65.132 it's actually the non-existent domain reply server from OpenDNS.

ps3.sony.com doesn't exist.

Re: Bad Gateway

Mon, 05 Nov 2012 19:11:50 EDT

Jabbu posted : I'm sure there are a lot of issues in NYC area with servers and routers.

Re: Bad Gateway

Mon, 05 Nov 2012 19:07:13 EDT

bluepoint posted : Okay then I have to wait, he won't be here until later.

Re: Bad Gateway

Mon, 05 Nov 2012 19:05:31 EDT

DrDrew posted :

said by bluepoint:

I would think the server is here in NYC. My last post, the first trace, is to ps3.sony.com.

ps3.sony.com could be totally unrelated to the server your son uses. It's like having some one trace to www.twcable.com when your own IP has issues.

Traces to the actual IP your son uses would be MUCH more helpful.
--
If it's important, back it up... twice. Even 99.999% availability isn't enough sometimes.

Re: Bad Gateway

Mon, 05 Nov 2012 18:59:34 EDT

bluepoint posted : It's a PS3 and I have to ask my son which server. I would think the server is here in NYC. My last post, the first trace, is to ps3.sony.com.

Re: Bad Gateway

Mon, 05 Nov 2012 18:50:50 EDT

DrDrew posted :

said by bluepoint:

Gaming is lagging. My son always got shot easily. :D

What game and server is he connected to? How? PC, console?

Re: Bad Gateway

Mon, 05 Nov 2012 18:49:13 EDT

bluepoint posted : Gaming is lagging. My son always got shot easily. :D

Re: Bad Gateway

Mon, 05 Nov 2012 18:48:49 EDT

DrDrew posted : Read this:
»www.nessoft.com/kb/article/packe···-24.html
or this:
»www.nessoft.com/kb/2

Re: Bad Gateway

Mon, 05 Nov 2012 18:46:20 EDT

Jabbu posted : What are you seeing? Constant lag or spikes?

Re: Bad Gateway

Mon, 05 Nov 2012 18:39:35 EDT

bluepoint posted : Ok I just did a tracert and it's better and it's responding. :uhh:

 1:     0 ms  192.168.1.12:   458 ms  68.174.228.1    (cpe-68-174-228-1.si.res.rr.com)3:    15 ms  24.164.129.218  (24-164-129-218.si.rr.com)4:     0 ms  24.164.128.34   (tenge-0-4-0-4-nycmny1-rtr02.si.rr.com)5:    15 ms  184.152.112.147 (bun119.nycmnytg-rtr001.nyc.rr.com)6:    15 ms  24.29.148.250   (bun6-nycmnytg-rtr002.nyc.rr.com)7:    15 ms  66.109.6.78     (ae-4-0.cr0.nyc30.tbone.rr.com)8:    15 ms  107.14.19.153  9:    31 ms  4.30.135.153    (xe-11-0-2.edge2.Newark1.Level3.net)10:    31 ms  4.69.156.30     (ae-31-51.ebr1.Newark1.Level3.net)11:    15 ms  4.69.132.97     (ae-2-2.ebr1.NewYork1.Level3.net)12:    15 ms  4.69.134.66     (ae-61-61.csw1.NewYork1.Level3.net)13:    15 ms  4.69.155.6      (ae-14-60.car4.NewYork1.Level3.net)14:    16 ms  4.53.94.218     (SPLICE-COMM.car4.NewYork1.Level3.net)15:    15 ms  67.215.65.132   (hit-nxdomain.opendns.com) The target host "67.215.65.132" have been reached. Query finished.    1:     0 ms  192.168.1.1   2:   405 ms  68.174.228.1    (cpe-68-174-228-1.si.res.rr.com)   3:     0 ms  24.164.129.218  (24-164-129-218.si.rr.com)   4:    15 ms  24.164.128.34   (tenge-0-4-0-4-nycmny1-rtr02.si.rr.com)   5:    31 ms  184.152.112.147 (bun119.nycmnytg-rtr001.nyc.rr.com)   6:    15 ms  24.29.148.250   (bun6-nycmnytg-rtr002.nyc.rr.com)   7:    16 ms  107.14.19.24      8:    15 ms  66.109.6.161    (ae-1-0.pr0.nyc30.tbone.rr.com)   9:    15 ms  216.55.0.65      10:    98 ms  216.156.0.21    (vb1011.rar3.washington-dc.us.xo.net)  11:    77 ms  207.88.12.9     (te-3-0-0.rar3.atlanta-ga.us.xo.net)  12:    94 ms  207.88.12.2     (te-3-0-0.rar3.dallas-tx.us.xo.net)  13:    78 ms  216.156.0.126   (ae0d0.mcr2.sandiego-ca.us.xo.net)  14:   358 ms  216.55.27.26     15:    94 ms  69.43.169.112   (ge5-2-6509-a.castleaccess.com)  16:   109 ms  69.43.129.188    17:    93 ms  69.43.161.162   The target host "69.43.161.162" have been reached. Query finished.

I think they are probably working on those nodes.

Re: Bad Gateway

Mon, 05 Nov 2012 18:28:57 EDT

DrDrew posted :

said by bluepoint:

That's what I'm trying to point at the router is busy. Why was it pinging 30ms before the storm and 2000ms now? What do you think happens? Wouldn't you think gaming will be affected?

It's not 2000ms now, it's not responding now. At least that's what you said and showed originally.

If it's 2000ms then show us.

Use PingPlotter, run it for awhile, and post some graph screenshots. A single tracert with single hop times don't show enough to really give a good answer.
--
If it's important, back it up... twice. Even 99.999% availability isn't enough sometimes.

Re: Bad Gateway

Mon, 05 Nov 2012 18:16:41 EDT

bluepoint posted :

said by Jabbu:

The first hop is the router in the hub, its priority is phone traffic then data traffic and its least priority is icmp traffic. So if this router is busy, you WILL see a high delay in tracert.

That's what I'm trying to point at the router is busy. Why was it pinging 30ms before the storm and 2000ms now? What do you think happens? Wouldn't you think gaming will be affected?

"Network latency in a packet-switched network is measured either one-way (the time from the source sending a packet to the destination receiving it), or round-trip (the one-way latency from source to destination plus the one-way latency from the destination back to the source). Round-trip latency is more often quoted, because it can be measured from a single point. Note that round trip latency excludes the amount of time that a destination system spends processing the packet. Many software platforms provide a service called ping that can be used to measure round-trip latency. Ping performs no packet processing; it merely sends a response back when it receives a packet (i.e. performs a no-op), thus it is a relatively accurate way of measuring latency."
»en.wikipedia.org/wiki/Latency_(engineering)

Re: Bad Gateway

Mon, 05 Nov 2012 18:13:40 EDT

bluepoint posted : Ip's being reshuffled didn't happen at least here. We lost power for 3.5 days and I was surprise when the power came back the DHCP server gave me the same IP. It's like winning the lottery. :D

All you're saying are guesses, I want a factual answer and I posted to get an answer and not to argue. I want to know why the gateway used to ping 30ms and now answering @2000ms or not at all.

Re: Bad Gateway

Mon, 05 Nov 2012 18:13:09 EDT

Jabbu posted : I don't get your point.

You are saying your first hop is taking 2000ms, that would mean ALL your websites would take at least 2 seconds to start loading. All your gaming would have a 2000ms or more ping time. If this was real, a simple ping to google.com would also result in 2000ms, not 60ms.

The first hop is the router in the hub, its priority is phone traffic then data traffic and its least priority is icmp traffic. So if this router is busy, you WILL see a high delay in tracert.

Re: Bad Gateway

Mon, 05 Nov 2012 18:05:43 EDT

DrDrew posted : So before Sandy it was 30ms, now it's not responding? In between there was a large power outage. Patterns of usage have changed and software may have automatically been updated once the power came up.

During large power outages, IPs maybe shuffled and reassigned.

There are far too many things that can change to rely on a single posted trace route to really troubleshoot. All we're doing right now is guessing.
--
If it's important, back it up... twice. Even 99.999% availability isn't enough sometimes.

Re: Bad Gateway

Mon, 05 Nov 2012 17:35:15 EDT

bluepoint posted :

said by Jabbu:

said by bluepoint:

I do not agree, each hop contributes to latency and latency is important when you're gaming.

What do you not agree with?

Ping is ICMP, ICMP traffic routers do not care about, you know about QoS or CoS?

How do you explain seeing 2000ms on your first hop, but only 50ms on your destination?

So you are telling me ICMP packets are ignored and it means we do not pay attention to the trace results? The ms it represents for each hop is the speed the hop answers. It doesn't represent how fast it arrives to the hop. It's wrong to ignore the other routes and just be happy the the destination answers to your satisfaction.
In layman's words, it's just the same in a car race. One starts in a rough road and the other in a smooth road. If both cars races to reach the 1 mile finish line, which one do you think arrives first?

Re: Bad Gateway

Mon, 05 Nov 2012 17:20:14 EDT

bluepoint posted :

said by DrDrew:

So, it's busy tending to other higher priority requests. Before Sandy, the gateway answers within 30 ms anytime of day. How can you explain that?

Again, though it could be private addresses are blocked at the WAN port of your home router.

Like what I've said, the gateway has been responding everytime before the storm and as far as my network, the gateway is always seen as a public ip(68.xx.xx.xx).

Re: Bad Gateway

Mon, 05 Nov 2012 17:10:50 EDT

Jabbu posted :

said by bluepoint:

I do not agree, each hop contributes to latency and latency is important when you're gaming.

What do you not agree with?

Ping is ICMP, ICMP traffic routers do not care about, you know about QoS or CoS?

How do you explain seeing 2000ms on your first hop, but only 50ms on your destination?

Re: Bad Gateway

Mon, 05 Nov 2012 17:09:37 EDT

DrDrew posted :

said by bluepoint:

I do not agree, each hop contributes to latency and latency is important when you're gaming.

If the gateway hop was contributing to the latency in an unusual manor, you'd see it reflected in the hops following it.
--
If it's important, back it up... twice. Even 99.999% availability isn't enough sometimes.

Re: Bad Gateway

Mon, 05 Nov 2012 17:08:38 EDT

DrDrew posted :

said by bluepoint:

Okay, so seems you're not sure if it was done. I asked because two days ago I've seen it answer with 2000+ ms, an indication of a busy gateway.
Sometimes you can gauge the gateway's performance through the next hop to it, however, it's not always true. I've seen a very long response from the gateway but very short response from the next hop after it.

That doesn't mean the gateway is busy. It means the card management processor may be configured to put ICMP on a lower priority or the card manager is busy, but that frequently doesn't affect the packet passthrough on the gateway to another router.

Also, 2000+ms response time could be from your own network slowing down pings to the hops after it.

Again, though it could be private addresses are blocked at the WAN port of your home router causing the no response.

Lots of possibilities.... especially after a wide spread power outage.
--
If it's important, back it up... twice. Even 99.999% availability isn't enough sometimes.

Re: Bad Gateway

Mon, 05 Nov 2012 17:06:49 EDT

bluepoint posted : I do not agree, each hop contributes to latency and latency is important when you're gaming.

Re: Bad Gateway

Mon, 05 Nov 2012 17:03:13 EDT

Jabbu posted : Ping traffic is lowest priority, if you get a 2000ms in tracert, but the final hop is only 50ms, it means your data round trip to target is only 50ms, the 2000ms is not the issue, if it was a real issue you would see 2000ms, then 2005ms, 2011ms, 2016ms for example all the way to your target at lets say 2060ms.

Ping uses ICMP, and ICMP is the LAST thing a router may care about, hence your tracert showing a really high hop.

Re: Bad Gateway

Mon, 05 Nov 2012 16:45:23 EDT

bluepoint posted : Okay, so seems you're not sure if it was done. I asked because two days ago I've seen it answer with 2000+ ms, an indication of a busy gateway.
Sometimes you can gauge the gateway's performance through the next hop to it, however, it's not always true. I've seen a very long response from the gateway but very short response from the next hop after it.

If they do so, how are they going to diagnose those routers? There is really no advantage for TWC to have those gateways not respond to ICMP packets.

Re: Bad Gateway

Mon, 05 Nov 2012 16:22:57 EDT

DrDrew posted : I didn't choose to do anything, I'm not involved. Local TWC CMTS Engineers may have done it.

Figure the gateways performance is equal to the hop right after it, since all the traffic hitting the next hop has to go through the gateway. If the gateway hop was really causing a problem, you'd see it reflected in all of the hops after it.

I said "apparently" because I only have what you've posted to judge the issue on. It may be a couple of other reasons as I listed though.
--
If it's important, back it up... twice. Even 99.999% availability isn't enough sometimes.

Re: Bad Gateway

Mon, 05 Nov 2012 15:58:44 EDT

bluepoint posted : My son is complaining of slow gaming on his ps3 and without knowing the gateways performance I cannot figure out the problem. Is there any reason you guys choose to do this?
Oh BTW, you said apparently, meaning you're not sure?

Re: Bad Gateway

Mon, 05 Nov 2012 15:44:49 EDT

DrDrew posted :

said by bluepoint:

It was responding before Sandy, did they do the change?

Apparently they did. Although I've seen the same behavior if something on the home network is blocking RFC 1918 (private) addressed packets from crossing the WAN port and/or some VPN setups.

What exactly do you see wrong besides a single hop not responding to ICMP packets?

Re: Bad Gateway

Mon, 05 Nov 2012 15:40:31 EDT

bluepoint posted : How did you know nothing is wrong?

Re: Bad Gateway

Mon, 05 Nov 2012 15:37:52 EDT

bluepoint posted : It was responding before Sandy, did they do the change?

Re: Bad Gateway

Mon, 05 Nov 2012 14:37:42 EDT

Napsterbater posted : What are you gonna complain about? nothing is wrong.

Re: Bad Gateway

Mon, 05 Nov 2012 14:14:02 EDT

DrDrew posted : The gateway is set to not reply to ICMP packets, which is a common configuration. Nothing to improve since it's not broken and not hurting your connection. It's certainly not "bad".

Bad Gateway

Mon, 05 Nov 2012 12:18:19 EDT

bluepoint posted : Since power came back in our area after Sandy, our gateway is not responding to traceroute even if I set the timeout @10000ms. I'm not complaining yet, I know Sandy did some damage in our area but at some point if this doesn't improve I'll call support and see what they got.

Host Information for "myservices.timwewarnercable.com":  IP address:   69.43.161.162  Host name:    myservices.timwewarnercable.com Tracing route to "69.43.161.162" over max. 30 hops:    1:     0 ms  192.168.1.1   2:     *     Request timed out.   3:    15 ms  24.164.129.218  (24-164-129-218.si.rr.com)   4:    15 ms  24.164.128.34   (tenge-0-4-0-4-nycmny1-rtr02.si.rr.com)   5:    15 ms  184.152.112.147 (bun119.nycmnytg-rtr001.nyc.rr.com)   6:    15 ms  24.29.148.250   (bun6-nycmnytg-rtr002.nyc.rr.com)   7:    31 ms  107.14.19.24      8:    15 ms  66.109.6.161    (ae-1-0.pr0.nyc30.tbone.rr.com)   9:    15 ms  216.55.0.65      10:    77 ms  216.156.0.21    (vb1011.rar3.washington-dc.us.xo.net)  11:    78 ms  207.88.12.9     (te-3-0-0.rar3.atlanta-ga.us.xo.net)  12:    78 ms  207.88.12.2     (te-3-0-0.rar3.dallas-tx.us.xo.net)  13:    78 ms  216.156.0.126   (ae0d0.mcr2.sandiego-ca.us.xo.net)  14:    93 ms  216.55.27.26     15:   155 ms  69.43.169.112   (ge5-2-6509-a.castleaccess.com)  16:    93 ms  69.43.129.188    17:    93 ms  69.43.161.162   The target host "69.43.161.162" have been reached. Query finished.