Any Sites Using Akamai CDN Times Out When Using a Ubiquiti Router(s)

erichoweyerichowey Posts: 4
edited January 5 in Internet 2020 Archive Jan 02, 2020



I have an issue that's bizzarely odd. If I'm using any of my Ubiquiti equipment, I cannot reach any sites that are using Akamai for CDN services (,, However, if I plug directly into the modem, the sites seem to load fine. Now before you all jump up and blame the Ubiquiti equipment, I happen to have a U-Verse connection as well. All of the sites mentioned above load perfectly when I use the U-Verse connection with the Ubiquiti equipment. I've been chasing this issue for days and it really has me scratching my head. I've also reached out to the Ubiquiti community and haven't gotten anywhere. We do not believe the issue lies with the Ubiquiti equipment. Unfortunately, if I can't get this issue resolved, I will be cancelling my Spectrum service and just use my AT&T connection. Ideally, I'd like to avoid this as the speeds with Spectrum are far better than AT&T, however, I cannot pay for a connection I cannot use.



Internet and Phone

Hitron E31T2V1 / Unifi USG 3P (Also replicable with my EdgeRouter Lite)

Unable to Post Signals with this modem. but Spectrum support says it's fine



Ikea Not Loading.png


[email protected]:~$ ping
PING ( 56(84) bytes of data.
64 bytes from ( icmp_seq=1 ttl=54 time=82.2 ms
64 bytes from ( icmp_seq=2 ttl=54 time=86.0 ms
64 bytes from ( icmp_seq=3 ttl=54 time=85.5 ms
64 bytes from ( icmp_seq=4 ttl=54 time=85.2 ms
64 bytes from ( icmp_seq=5 ttl=54 time=89.5 ms
64 bytes from ( icmp_seq=6 ttl=54 time=84.2 ms
64 bytes from ( icmp_seq=7 ttl=54 time=88.2 ms
64 bytes from ( icmp_seq=8 ttl=54 time=83.6 ms
64 bytes from ( icmp_seq=9 ttl=54 time=89.7 ms
64 bytes from ( icmp_seq=10 ttl=54 time=87.1 ms
--- ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 82.235/86.116/89.738/2.375 ms
[email protected]:~$ traceroute
traceroute to (, 30 hops max, 60 byte packets
1 _gateway ( 0.476 ms 40.788 ms 40.779 ms
2 ( 11.058 ms 11.160 ms 10.967 ms
3 ( 11.310 ms 11.650 ms 11.648 ms
4 ( 15.230 ms 19.345 ms 19.649 ms
5 ( 17.295 ms 17.337 ms 17.279 ms
6 ( 25.101 ms 16.945 ms 14.124 ms
7 ( 12.183 ms 14.652 ms 28.533 ms
8 ( 92.960 ms 92.791 ms 92.800 ms
9 ( 94.002 ms 93.677 ms 93.596 ms
10 ( 99.105 ms 99.137 ms 99.175 ms
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[email protected]:~$


Best Answer


  • RAIST5150RAIST5150 Posts: 835 ✭✭✭✭
    Jan 02, 2020
    Doesn't look like you are "timing out"... when you ping the site it goes through 100%.

    It looks more like that next hop in your tracert is set to not respnd to ICMP, so it stalls.

    It may be something up with the IP address you are getting from Spectrum.... may have somehow gotten flagged for malicious behavior.

    When you plugged directly into the modem, the system likely gave it a different public address because it picked up a different MAC address. Obviously, you would get a different address from ATT as well.

    Could try cloning your system's MAC address to see if it behaves again. If it does, leave it like that for at least a month or so (give the lease time to expire) before changing it back to default.
  • erichoweyerichowey Posts: 4
    Jan 02, 2020

    I've already tried cloning the MAC address for a different IP. I've also plugged in the Edgerouter vs the USG, which all results in a different IP. It still doesn't work.

  • karlbeckmankarlbeckman Posts: 2,254 ✭✭✭✭
    Jan 03, 2020

    The last responding IP address in your tracert is

    Running whois  on that IP I get NTT America, Inc. as the owner.  Everything seems to be blocked somewhere beyond that device, which is a couple of hops beyond Spectrum's IXP handoff.  Therefore there is nothing at all that Spectrum can do to resolve your issue. 


    You should contact the owners of the merchant sites you were trying to reach and make them aware that Akumai and/or NTTA are causing legitimate network traffic to their sites to be blocked, which is costing them business.  Note that by hosting numerous domains from a single IP, Akumai often gets hit with spam blocks, as Julia noted in her earlier reply. 

  • erichoweyerichowey Posts: 4
    Jan 03, 2020

    @karlbeckman wrote:

    Therefore there is nothing at all that Spectrum can do to resolve your issue. 

    I refuse to believe that. Spectrum has the power to open tickets with peering routes and alert them of the issue. Spectrum has the power to let Akamai know of the problem and try to work with them to resolve it. I'm sure there's other things they can do. I am in contact with these sites, but Spectrum also needs to help get this issue resovled. They're going to lose a paying customer if they do not.

  • RAIST5150RAIST5150 Posts: 835 ✭✭✭✭
    Jan 05, 2020
    As I a noted earlier, you do not appear to be getting blocked along your route.

    Your pings are getting through 100%.

    It is common practice for routers to be set to not respond to the ICMP ECHO requests during traces... either all the time or when traffic reaches a certain threshold.

    Unless a node is going down or grossly overloaded, pings and normal web traffic typically just get forwarded from hop to hop--unless somewhere along the line your address got flagged for some sort of malicious behavior that caused it to get blacklisted--in which case you would need to contact them about getting it released.

    This looks more like something connected to the website is rejecting you.
  • Julia_RJulia_R Posts: 4,500 Lead Mod
    Jan 05, 2020

    When you are directly connected to our modem, using the IP we are providing,  you are able to reach the sites? That tells us that there is no problem with our connection.


    You are only having the trouble while using your router. If you have an alternate router you 

    can test with that may help pinpoint where the issue resides. 



  • RAIST5150RAIST5150 Posts: 835 ✭✭✭✭
    Jan 07, 2020
    Cloudflare relies far more heavily on cached data... a trick they deploy to serve data faster. May have just been getting stale data, possibly bound to the next hop data being presented from the BGP lookups.

    Might find it works again if you flip back to it later, once new announcements propogate to their data set.

    Just as a general rule of thumb for the future, if you are going to go third-party like that, should try undoing that as part of your own troubleshooting step... or at least make sure to point out you are doing so. Could have saved you and others some time and frustration.

    Also... was kinda unfair to try pinning all routing related issues on Spectrum when you were intentionally polling pertinent routing data from a third-party network that is outside of their influence.

    EDIT: just out of curiosity, I manually set my DNS back to cloudflare exclusively, and was able to hit the mentioned sites just fine. Never visit those sites either, so they weren't cached hits. Have tested cloudflare out in the past and never had such issues... same goes for OpenDNS, Google, etc. Always wind up leaving auto config on the router, though some devices may have alternates still set.
This discussion has been closed.