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

Hello,
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 (kp.org, ralphs.com, ikea.com). 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.
91108
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
[email protected]:~$ ping www.ikea.com
PING e11958.x.akamaiedge.net (23.214.243.195) 56(84) bytes of data.
64 bytes from a23-214-243-195.deploy.static.akamaitechnologies.com (23.214.243.195): icmp_seq=1 ttl=54 time=82.2 ms
64 bytes from a23-214-243-195.deploy.static.akamaitechnologies.com (23.214.243.195): icmp_seq=2 ttl=54 time=86.0 ms
64 bytes from a23-214-243-195.deploy.static.akamaitechnologies.com (23.214.243.195): icmp_seq=3 ttl=54 time=85.5 ms
64 bytes from a23-214-243-195.deploy.static.akamaitechnologies.com (23.214.243.195): icmp_seq=4 ttl=54 time=85.2 ms
64 bytes from a23-214-243-195.deploy.static.akamaitechnologies.com (23.214.243.195): icmp_seq=5 ttl=54 time=89.5 ms
64 bytes from a23-214-243-195.deploy.static.akamaitechnologies.com (23.214.243.195): icmp_seq=6 ttl=54 time=84.2 ms
64 bytes from a23-214-243-195.deploy.static.akamaitechnologies.com (23.214.243.195): icmp_seq=7 ttl=54 time=88.2 ms
64 bytes from a23-214-243-195.deploy.static.akamaitechnologies.com (23.214.243.195): icmp_seq=8 ttl=54 time=83.6 ms
64 bytes from a23-214-243-195.deploy.static.akamaitechnologies.com (23.214.243.195): icmp_seq=9 ttl=54 time=89.7 ms
64 bytes from a23-214-243-195.deploy.static.akamaitechnologies.com (23.214.243.195): icmp_seq=10 ttl=54 time=87.1 ms
^C
--- e11958.x.akamaiedge.net 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 www.ikea.com
traceroute to www.ikea.com (23.214.243.195), 30 hops max, 60 byte packets
1 _gateway (172.20.1.1) 0.476 ms 40.788 ms 40.779 ms
2 142.254.183.205 (142.254.183.205) 11.058 ms 11.160 ms 10.967 ms
3 agg63.lsdwcaro01h.socal.rr.com (24.30.174.193) 11.310 ms 11.650 ms 11.648 ms
4 agg21.lamrcadq01r.socal.rr.com (72.129.10.192) 15.230 ms 19.345 ms 19.649 ms
5 agg28.lsancarc01r.socal.rr.com (72.129.9.0) 17.295 ms 17.337 ms 17.279 ms
6 bu-ether16.atlngamq46w-bcr00.tbone.rr.com (66.109.6.92) 25.101 ms 16.945 ms 14.124 ms
7 66.109.5.123 (66.109.5.123) 12.183 ms 14.652 ms 28.533 ms
8 las-b24-link.telia.net (62.115.156.224) 92.960 ms 92.791 ms 92.800 ms
9 ntt-ic-326358-las-b24.c.telia.net (213.248.103.171) 94.002 ms 93.677 ms 93.596 ms
10 ae-0.a00.lsanca07.us.bb.gin.ntt.net (129.250.2.104) 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
-
erichowey Posts: 4
I've resolved the issue with the help of the Ubiquiti community.
When using DNS results returned by DNS Server 1.1.1.1, traffic to Akamai is filtered. When using DNS results returned by Spectrum's DNS Servers, the sites load.
The fact I can't use a 3rd party DNS server and have a fully working connection is really disappointing. I also applaud the Ubiquiti community for stepping up and helping when the issue was clearly not on their end. Everyone here just wanted to point fingers at my router being the issue.
0
Replies
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.
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.
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.
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.
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.
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.
Julia
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.