dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
2495
kokkatc
join:2012-12-20

kokkatc

Member

[CA] COX HSI - High Latency - Bad routing help - San Diego

Hello,

I'm a cox customer with their best HSI package, 50mb/5mb. My issue has nothing to do with bandwidth as my bandwidth is never a problem, my routing however is a huge problem for gaming.

As long as I've had Cox, my latency to the game servers I frequent (California LA servers) have always been questionably high. When I run a traceroute on these servers I quickly discover that I'm being routed from San Diego -> Atlanta -> Los Angeles... When I try and play on San Diego servers that are literally miles from me, I'm routed from San Diego -> San Jose -> La -> San Diego. I'm tired of dealing with this ridiculous routing which significantly impacts my latency.

Yes, we can run a trace-route and discover which hop is causing the issue, but then what? Once we find the problem router, what can we actually do to fix this? I've tried calling Cox tech support, tier 2, but I never receive any useful help. I'm simply told, "Oh, you're being routed to so and so, there's nothing we can do about that, sorry."

I've also tried changing my IP address multiple times by changing my mac address then rebooting hoping I land on a more advantageous subnet. I have managed to land on a different subnet at times, but the routing is no better.

I've had to resort to using game proxies and VPN's to change my routing which works to some degree, but can we somehow fix this 'routing' issue once we discover the problem via trace-route?

Thanks in advance,

-T

Anonguy
@cox.net

Anonguy

Anon

Can you post some examples?

CoxTech1
join:2002-04-25
Chesapeake, VA

CoxTech1 to kokkatc

Member

to kokkatc
Based on the path you described it sounds like the remote host isn't on cox and therefore is taking the shortest path off of our network and onto the next connecting network. If you have any trace routes showing problems perhaps we could take a look and see what's going on.

odog
Minister of internet doohickies
Premium Member
join:2001-08-05
Atlanta, GA
Nokia BGW320-505

odog to kokkatc

Premium Member

to kokkatc
It's all about peering. Cox peers to the internet in very specific places. I don't remember them all off the top of the head, but I'm pretty sure it is San Jose, Dallas, Atlanta, NYC, and Chicago.(might also be Los Angeles as well)

Post some traceroutes, that will help diagnose if there is an actual routing issue.
nickphx
join:2009-10-29
Phoenix, AZ

nickphx to kokkatc

Member

to kokkatc
How are you determining the physical location of the IP addresses in the traceroute? Most tools rely on the address data provided to ARIN and that is not always the physical location of the device..

I seriously doubt cox would run traffic from SD -> ATL -> LA considering LA is a major peering hub.

When I traceroute to a colo I have here in Phoenix from my Cox connection, my traffic leaves Phoenix, goes to LA, then back to Phoenix. Do I blame COX for this? No. While both COX and my colo provider share equal blame in this problem (it takes 2 to peer), it's not all COX's fault.

If the colo provider peered with COX here in Phoenix, my traffic wouldn't take the scenic route.

I looked into getting a connection from COX at my colo since COX is "on net" there.. Their prices per mbit were 10x above market and completely not worth it for me to save ~30ms.

Why don't you provide the output of traceroute as well as the destination IP address?
Needleinthha
join:2009-11-30
Chandler, AZ

Needleinthha

Member

said by nickphx:

When I traceroute to a colo I have here in Phoenix from my Cox connection, my traffic leaves Phoenix, goes to LA, then back to Phoenix. Do I blame COX for this? No. While both COX and my colo provider share equal blame in this problem (it takes 2 to peer), it's not all COX's fault.

Not trying to advertize (im not affiliated with them), but I use atjeu for colo (they are in phoenix) and they use cox so it's a direct connection from here, doesn't route through LA. I get ~10ms pings, really awesome.

It is really annoying that cox doesn't peer in phoenix...that just about EVERYTHING has to goto LA, SF, etc...oh well.
kokkatc
join:2012-12-20

kokkatc

Member

Couple traceroute examples.

San Diego to Los Angeles Server:

Tracing route to jennyfur.pelican.org [76.74.236.91]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 1.0.16.172.in-addr.arpa [172.16.0.1]
2 8 ms 8 ms 8 ms 1.0.133.10.in-addr.arpa [10.133.0.1]
3 8 ms 8 ms 8 ms ip68-6-12-132.sd.sd.cox.net [68.6.12.132]
4 9 ms 8 ms 9 ms 202.11.6.68.in-addr.arpa [68.6.11.202]
5 12 ms 9 ms 8 ms fed1dsrj01-xe130.0.rd.sd.cox.net [68.6.8.0]
6 * * 39 ms 68.1.5.140
7 39 ms 40 ms 38 ms 10ge.ten1-3.dal-eqx-cor-1.peer1.net [206.223.118
.30]
8 45 ms 44 ms 44 ms 10ge.ten1-2.la-600w-cor-2.peer1.net [216.187.124
.121]
9 47 ms 44 ms 48 ms 10ge.xe-0-3-0.lax-600w-sbcor-2.peer1.net [216.18
7.88.46]
10 48 ms 45 ms 46 ms 10ge.xe-0-0-2.lax-600w-sbdis-1.peer1.net [216.18
7.88.138]
11 44 ms 45 ms 44 ms jennyfur.pelican.org [76.74.236.91]

Trace complete.

-------------------

San Diego to San Diego Server (15 miles away)

Tracing route to jennyfur.pelican.org [76.74.236.91]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 1.0.16.172.in-addr.arpa [172.16.0.1]
2 8 ms 8 ms 8 ms 1.0.133.10.in-addr.arpa [10.133.0.1]
3 8 ms 8 ms 8 ms ip68-6-12-132.sd.sd.cox.net [68.6.12.132]
4 9 ms 8 ms 9 ms 202.11.6.68.in-addr.arpa [68.6.11.202]
5 12 ms 9 ms 8 ms fed1dsrj01-xe130.0.rd.sd.cox.net [68.6.8.0]
6 * * 39 ms 68.1.5.140
7 39 ms 40 ms 38 ms 10ge.ten1-3.dal-eqx-cor-1.peer1.net [206.223.118
.30]
8 45 ms 44 ms 44 ms 10ge.ten1-2.la-600w-cor-2.peer1.net [216.187.124
.121]
9 47 ms 44 ms 48 ms 10ge.xe-0-3-0.lax-600w-sbcor-2.peer1.net [216.18
7.88.46]
10 48 ms 45 ms 46 ms 10ge.xe-0-0-2.lax-600w-sbdis-1.peer1.net [216.18
7.88.138]
11 44 ms 45 ms 44 ms jennyfur.pelican.org [76.74.236.91]

Trace complete.

------------------

I generally ping better or the same to Texas servers than I do to California servers. It's quite frustrating.
nickphx
join:2009-10-29
Phoenix, AZ

nickphx to Needleinthha

Member

to Needleinthha
The services they provide are nowhere near what I needed or I would have used them. I have 2 full 42u cabinets at phoenix nap, each with 30amp circuits and two 1gig connections with HE.net.. Not bashing Atjeu, but they're more of a mom & pop place to put a machine..
nickphx

nickphx to kokkatc

Member

to kokkatc
If you look at that second traceroute, COX handed it off to PEER1 in San Diego at hop 7... So that "poor routing" is on PEER1, not COX.

Those two traceroutes are to the same IP address...
Ameth
join:2011-07-20
ARRIS eXtreme SB6120
Asus RT-AC66

Ameth

Member

said by nickphx:

Those two traceroutes are to the same IP address...

I noticed that too. Each location should have a different IP.
m8trix
join:2003-12-24
Chandler, AZ

m8trix to kokkatc

Member

to kokkatc
looking at your trace route and being a fellow gamer(bf3,tf2,css,ect) i dont see any issue with your ping in those trace route as there is little to no difference in game performance between getting a 10 ping and 50 ping and the highest i see you hit is 48ms. ping usually does not become a problem to you hit 100ms or higher

so my question to you is what issue are you running into that makes you think your ping is the cause of your problem
kokkatc
join:2012-12-20

kokkatc

Member

said by m8trix:

looking at your trace route and being a fellow gamer(bf3,tf2,css,ect) i dont see any issue with your ping in those trace route as there is little to no difference in game performance between getting a 10 ping and 50 ping and the highest i see you hit is 48ms. ping usually does not become a problem to you hit 100ms or higher

so my question to you is what issue are you running into that makes you think your ping is the cause of your problem

This is where I disagree with you, completely. Pinging 50s to los angeles servers from San Diego when I ping 40s to Texas servers from San Diego is unacceptable. Pinging 50s to a server literally 8 miles from me because I'm routed to San Jose then back to San Diego, is also 'poor routing.'

FYI, and in my opinion, there's a huge difference between pinging 50s than teens, 20s, or even 30s in a fast paced FPS. Although, that's not the issue, the issue is the routing and if Cox has the ability to redirect routing, change the node your on, perhaps even your subnet. I'm trying to get some clear answers.

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

NormanS

MVM

said by kokkatc:

Pinging 50s to los angeles servers from San Diego when I ping 40s to Texas servers from San Diego is unacceptable. Pinging 50s to a server literally 8 miles from me because I'm routed to San Jose then back to San Diego, is also 'poor routing.'

... the issue is the routing and if Cox has the ability to redirect routing, change the node your on, perhaps even your subnet. I'm trying to get some clear answers.

Based on a trace route from my provider, Peer 1 is the preferred route for your destination. Where Cox connects with Peer 1 may be determined by Peer 1; Cox may not have a choice in the matter.
cookiesowns
join:2010-08-31
Irvine, CA

cookiesowns to kokkatc

Member

to kokkatc
Those two traceroutes are to the same end point..

The issue is with peer1 btw. As far as I know peer1 has peering with cox, or uses similar peering fabric to certain areas.

The traceroute you provided shows that your CMTS hands off to equinix peer1 in Dallas, then hauls the traffic back to 600west LA.

I'm not sure on the return path, but from what I can tell based on the latency, Peer1 is taking a scenic route to PaloAlto where cox commonly peers in California with peer1 ( known issue ) and back to your sandiego CMTS.

For me in LA, I commonly see this issue with peer1. Had several colod machines / ventrilo servers that would take a scenic route to my home connection here in OC. It would either loop around LA to PA then back to LA, or even loop to LA - Dal then back to LA. I've even seen a wierder one such as LA - PA - Dal - LA with peer1 once. I suggest you contact their NOC ( peer 1 ) and push them to resolve this.

Oh wow, my memory served me wrong. Cox is handing off to Peer1 in Dallas equinix for me, then back to LA. That would mean Peer1 has proper routes to cox, but cox's outbound to them is messed up.
kokkatc
join:2012-12-20

kokkatc

Member

Sorry about the late response.

Thanks for the INFO. I do have one question....

To my knowledge by NOC, you mean Networking Operations Center. How do I go about contacting the suspect NOC (peer1) to discuss the matter? Finding someone at Cox who even understands the basics of routing is tough to find, and I'm just a novice in networking.

Thanks again.
kokkatc

kokkatc to NormanS

Member

to NormanS
I have heard about 'Interconnect Agreements' that predetermine routing to some extent. To my understanding, this is typically decided between an ISP and Host Provider, I could be wrong.

My primary question relates to your statement, how Cox may not even have a choice in the matter. If Cox doesn't, then who does, and would one go about resolving such a routing issue?

FYI, my ping to google from San Diego, CA is 200ms. This seems rather absurd and relates to the 'routing' issue I'm talking about. At work, which is literally miles away from my house pings 8ms to google, and 8ms to the server I frequent the most. When I used ATT Internet (VDSL), I pinged 30s to google, 20s to the above sever I mentioned. No strange 'scenic' routes, usually a direct shot more or less. Cox has been a different story altogether.

CoxTech1
join:2002-04-25
Chesapeake, VA

CoxTech1

Member

If you're seeing that much latency to google you may have something else going on other than routing. As for getting routing changed that's kind of like asking for interstate highways to be moved. There's actually some flexibility but routing is largely subject to geography and topology of networks.

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

NormanS to kokkatc

MVM

to kokkatc
said by kokkatc:

My primary question relates to your statement, how Cox may not even have a choice in the matter. If Cox doesn't, then who does, and would one go about resolving such a routing issue?

I don't know; but I will offer a case-in-point. Before AT&T was bought by SBC, the favored Tier 1 peering was with Level 3. Level 3 has 3 (that I know of) West Coast peering centers: Seattle, Washington, San Jose, California, and Los Angeles, California. For reasons I don't completely understand, SBC peered with Level only in San Jose. So an SBC user in San Diego, California would see his TCP/IP traffic ride SBC transit from San Diego to San Jose, then be handed off to Level 3. If he was going to a web site in the Southeastern U.S., his packets would then double back south, to Los Angeles, before turning east; then through Dallas, Texas and Atlanta, Georgia before leaving Level 3 transit for the destination.

Then there is the case of a cousin's FiL down in Morgan Hill, California. Only about 20 miles from my house; but, while working on his computer, I tried tracing to my server (located in my garage). MH is about the northern limit of the Charter Central Coast market. Their transit hub is in San Luis Obispo, California. So the route from his computer to mine was:

• MH to SLO on Charter transit.
• SLO to SJ on AT&T transit.
• Jump to Level 3 transit in SJ.
• Jump to SBC transit in SJ.
• SJ to my SJ server via SBC transit through Pleasanton, California.

There are folks in Grant's Pass, Oregon who route north to Portland before routing south to San Jose, California.

Last Mile providers tend to peer with Tier 1 transit on factors of transit cost, and routing cost. A Tier 1 peer may give lower price if the provider peers at a hub preferred by the Tier 1 provider.

The decision basis is all very murky, to me, and probably requires requests to the user's provider's NOC. Your only hope, really, is that someone like CoxTech1 See Profile knows whom to contact, and actually sees a problem, or can convince a NOC engineer to check if there is a problem. And if the problem is beyond the Cox transit, as in peering capacity between Cogentco and AT&T, or with Blizzard capacity issues with their upstream (AT&T Services), Cox may not be able to do squat.