Advanced Search Options
We have advanced search options to make it easier to locate posts, questions and answers on this community.
More information can be found at Advanced Search Options
If you are looking for something specific, please check if someone else has already asked or answered the same question.
Frequently Asked Questions
(Quick links to the current most searched topics)
How can I pause and rewind live TV using the Spectrum TV app?
Spectrum TV App Supported Devices
Why does Spectrum Backbone route all durango colorado traffic to seattle wa?
I'm located in Durango CO, spectrum customer, what I've noticed is that all traffic from SW colorado (Durango) spectrum customers is routed up through Seattle WA. This inefficent routing adds a ton of additional latency for latency sensitive applications(online gaming, voip calls)
This is especially bad when you need to reach resources on the east coast. I get somewhere near 160ms to eastcoast destinations.
current traceroute showing destinations are routed Durango->Grand Junction->Missoula->Seattle:
% traceroute 188.8.131.52
traceroute to 184.108.40.206 (220.127.116.11), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 2.373 ms 0.933 ms 1.009 ms
2 * * *
3 lag-63.durncocu02h.netops.charter.com (18.104.22.168) 10.198 ms 11.212 ms 16.384 ms
4 lag-10.durncocu01h.netops.charter.com (22.214.171.124) 10.631 ms 12.353 ms 11.304 ms
5 lag-27.gdjtco0602h.netops.charter.com (126.96.36.199) 12.842 ms 13.541 ms 70.935 ms
6 lag-24.msslmt33zp0.netops.charter.com (188.8.131.52) 44.256 ms 54.198 ms 53.881 ms
7 lag-702.bbr02sttlwa.netops.charter.com (184.108.40.206) 67.354 ms 60.284 ms 60.103 ms
8 lag-802.prr01sttlwa.netops.charter.com (220.127.116.11) 64.304 ms 74.736 ms 64.673 ms
9 18.104.22.168 (22.214.171.124) 73.851 ms
096-034-158-069.biz.spectrum.com (126.96.36.199) 68.127 ms 58.285 ms
10 * * *
11 dns.google (188.8.131.52) 63.751 ms 56.662 ms
184.108.40.206 (220.127.116.11) 55.187 ms
What I would expect is spectrum routes traffic to Denver as it is a larger hub site for internet and would vastly improve latency for customers in Durango.
What's really interesting is that I have seen the path via Denver as recent as evening of Nov 18 and took a traceroute at that time.
path that is preferred:
% traceroute 18.104.22.168 traceroute to 22.214.171.124 (126.96.36.199), 64 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 1.664 ms 1.162 ms 1.039 ms 2 * * * 3 lag-63.durncocu02h.netops.charter.com (188.8.131.52) 11.335 ms 11.732 ms 13.375 ms 4 lag-10.durncocu01h.netops.charter.com (184.108.40.206) 12.150 ms 12.420 ms 11.587 ms 5 lag-27.gdjtco0602h.netops.charter.com (220.127.116.11) 21.865 ms 13.019 ms 13.520 ms 6 lag-10.gdjtco0601h.netops.charter.com (18.104.22.168) 28.136 ms 16.170 ms 14.123 ms 7 lag-24.dnvtco56zp0.netops.charter.com (22.214.171.124) 18.789 ms 20.290 ms 18.042 ms 8 lag-702.bbr01dnvrco.netops.charter.com (126.96.36.199) 19.498 ms 20.669 ms 23.499 ms 9 lag-801.prr02dnvrco.netops.charter.com (188.8.131.52) 19.224 ms 19.143 ms 19.626 ms 10 096-034-157-003.biz.spectrum.com (184.108.40.206) 18.434 ms 096-034-157-001.biz.spectrum.com (220.127.116.11) 22.201 ms 096-034-157-003.biz.spectrum.com (18.104.22.168) 17.897 ms 11 * * * 12 dns.google (22.214.171.124) 17.949 ms 126.96.36.199 (188.8.131.52) 18.790 ms dns.google (184.108.40.206) 21.737 ms
But since then the non-ideal path has taken over as stated above. Users in Durango would greatly appreciate some insight on why the more efficient path is not the default path for day-to-day use.
James_M Posts: 3,944 ADMIN
Hi & welcome!
Generally speaking, internet traffic is routed on the path of least resistance. There are multiple reasons that traffic may be routed on a specific path as opposed to another path, and the most common is simple congestion.
Think of it like driving on the highway. While there may be a more direct path from A to B, congestion in the form of higher than usual traffic, or a disabled vehicle may mean that the direct path may not be the most efficient path. So going the long way around the block to get the corner may simply be faster.
In terms of lag, generally anything less than 100ms is acceptable and 40-60ms is optimal. Anything less than 40ms is excellent.
The trace routes provided above do not show anything of concern. If you are experiencing an issue on a regular basis, please provide three trace routes that domonstrate the issue (from the command prompt ie: H:\>tracert google.com) to three different websites and if there is an issue, we can forward it to out network engineers for investigation.
Thanks for the question!0
HT_Greenfield Posts: 278 Contributor
Maybe the network topology and traffic routing is largely driven by where the server farms are at for the highest volume type of traffic which is TV streaming and maybe there's a big ole TV streaming server farm hosted by AWS there in Seattle. Sorry, man, but TV streaming is the big man on campus now of days and other types of traffic are just going to have to go with the flow.1
To re-use your example, the current path is akin to driving from Durango to Denver, but having to drive to Denver via Seattle, which adds 1000s miles to the path, when the 'road' or fiber path clearly already exists between Durango and Denver (as seen in my optimal traceroute). I fail to understand how the more circuitous path is less congested than the shorter path, if congestion is the case, then I would expect the ideal path during low/non-peak hours. In this case the non-optimal path is taken all the time. Can you explain why things were routed much more optimally on Nov18 and changed the next day?
Since this is a daily pain point for me I would greatly appreciate more technical details as to why this occurring and would happily discuss further with network engineers (I am one myself).
Unfortunately, our network engineers are not customer facing. If you are experiencing an issue with your service, please provide the trace routes menioned previously so we can investigate further.
Otherwise, we will happily forward your feedback and suggestion.
Here's a current traceroute show casing how circuitous the routing is at 155+ms to US-EAST-1 (Amazon Virginia destination). This is well above your threshold of 100ms provided.
$ traceroute 220.127.116.11
traceroute to 18.104.22.168 (22.214.171.124), 30 hops max, 60 byte packets
1 RT-N66U-C050 (192.168.1.1) 0.482 ms 0.643 ms 0.692 ms
2 * * *
3 lag-63.durncocu02h.netops.charter.com (126.96.36.199) 11.346 ms 12.394 ms 12.365 ms
4 lag-10.durncocu01h.netops.charter.com (188.8.131.52) 12.660 ms 12.625 ms 12.674 ms
5 lag-27.gdjtco0602h.netops.charter.com (184.108.40.206) 14.815 ms 14.776 ms 14.748 ms
6 lag-24.msslmt33zp0.netops.charter.com (220.127.116.11) 46.189 ms 46.150 ms 46.072 ms
7 lag-702.bbr02sttlwa.netops.charter.com (18.104.22.168) 69.793 ms 56.475 ms 58.623 ms
8 lag-805.bbr02snjsca.netops.charter.com (22.214.171.124) 89.699 ms 90.540 ms 100.363 ms
9 * lag-2.bbr01dnvrco.netops.charter.com (126.96.36.199) 100.824 ms 333.762 ms
10 lag-800.bbr02dnvrco.netops.charter.com (188.8.131.52) 108.119 ms 100.088 ms 102.604 ms
11 lag-805.bbr01euclwi.netops.charter.com (184.108.40.206) 143.246 ms 140.474 ms 150.416 ms
12 lag-801.prr01mplsmn.netops.charter.com (220.127.116.11) 136.473 ms 145.269 ms 146.160 ms
13 18.104.22.168 (22.214.171.124) 136.256 ms 126.96.36.199 (188.8.131.52) 138.445 ms 136.780 ms
14 184.108.40.206 (220.127.116.11) 146.290 ms 18.104.22.168 (22.214.171.124) 156.052 ms 126.96.36.199 (188.8.131.52) 150.422 ms
15 184.108.40.206 (220.127.116.11) 136.984 ms 18.104.22.168 (22.214.171.124) 146.437 ms 126.96.36.199 (188.8.131.52) 146.015 ms
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 184.108.40.206 (220.127.116.11) 165.115 ms 18.104.22.168 (22.214.171.124) 164.643 ms 126.96.36.199 (188.8.131.52) 165.436 ms
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 ec2-23-23-255-255.compute-1.amazonaws.com (184.108.40.206) 166.642 ms * *
ping -c 10 220.127.116.11
PING 18.104.22.168 (22.214.171.124) 56(84) bytes of data.
64 bytes from 126.96.36.199: icmp_seq=1 ttl=230 time=154 ms
64 bytes from 188.8.131.52: icmp_seq=2 ttl=230 time=154 ms
64 bytes from 184.108.40.206: icmp_seq=3 ttl=230 time=155 ms
64 bytes from 220.127.116.11: icmp_seq=4 ttl=230 time=155 ms
64 bytes from 18.104.22.168: icmp_seq=5 ttl=230 time=154 ms
64 bytes from 22.214.171.124: icmp_seq=6 ttl=230 time=154 ms
64 bytes from 126.96.36.199: icmp_seq=7 ttl=230 time=155 ms
64 bytes from 188.8.131.52: icmp_seq=8 ttl=230 time=156 ms
64 bytes from 184.108.40.206: icmp_seq=9 ttl=230 time=155 ms
64 bytes from 220.127.116.11: icmp_seq=10 ttl=230 time=155 ms
--- 18.104.22.168 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 154.006/154.705/155.674/0.515 ms
Thanks. I was able to locate your account using your registration information. I am seeing some signal issues that would need to be addressed first with a service call. If you would like assistance setting up a service call with a technician, please let us know.
The issue I'm describing would not be fixed with a truck roll to my place; the issue I'm pointing out is related to how all traffic in the town is routed and not specific to my address.
Hate to say it, but may have to wait until the next round of BGP announcements are made... not every network runs on the same refresh cycles either.
It is an unfortunate downside to some of the automation that takes place... stale metrics in the tables when there is a sudden shift in traffic patterns. It can sometimes take a while for things to right the ship again.
Keep in mind that some of the routing decisions may eventually fall out of Spectrum's hands. Once you get handed off to a peering partner or someone's edge networks, it is in someone else's wheelhouse and you are then subject to the metrics saved in their tables. This can sometimes happen pretty early in the route, not always midway like when you got handed off to Amazon at hop 13 (22.214.171.124 and 126.96.36.199).
In the short term, Can opt to try a VPN to get around it. Sometimes you can get lucky if you power down the modem for a long while (like over night, while out of town for a trip or something). If it manages to switch to a different enough subnet, the routing may latch a better route that puts you into a different region for that next hop out of your area that otherwise points you to a more optimal peering assignment or entry point to the endpoint's perimeter network.
May be a bigger problem in general with east/west traffic atm. Poked around a looking glass from two locations in Denver to that aws address, and the IGP results they use were not pretty...
Should also note that icmp echo is far from a perfect diagnosis tool... one of the lower priority items when a node starts to get busy. Some are even set to outright ignore them as a rule.
Pretty much what the general public has to work with though. Usually good enough to point tier3 and such in the general direction.... just have learned to not take them as definitive proof of where a problem lies.
Might want to poke around with the cloudping tool:
There are more tools out there where you can get more info... EC2 reachability and additional diagnostics. Some games have their own suite of tools you can use as well through their support portals.
May want to take them up on the tech visit... signs of more localized bad jitter (at times as bad as 60%).
Whatever is the root cause of that could be compounding things.
The process has to start somewhere... isolate and address each problem you can to get things rooted out properly.
Yes I took them up on a truck roll since customer service said I was due for modem replacement anyway (upgrade to docsis 3.1).
Long story short, modem was replaced, signal checked, etc. All of that is/was fine.
Of course the backbone issue still exists because it has nothing to do with my local modem connection. This is an issue with how spectrum backbone routes sources of this network segment towards the internet.
Also note my test towards 188.8.131.52 IS an ec2-reachability ip from http://ec2-reachability.amazonaws.com/
All us-east-1 destinations will get routed this non-optimal way until spectrum can sort out their backbone routing to leverage Denver peering.