Here's a server hosted in Dallas, Texas (US). For some reason it's choosing a route through Aus, Singapore and Germany over a direct route to LAX. Anyone else seeing similar routing issues?
![]() ![]() ![]() |
|
you read the multiple other threads on this?
https://www.geekzone.co.nz/forums.asp?forumid=81&topicid=300668
https://www.geekzone.co.nz/forums.asp?forumid=81&topicid=300526
Seems to be a issue often with them
Jase2985:
you read the multiple other threads on this?
https://www.geekzone.co.nz/forums.asp?forumid=81&topicid=300668
https://www.geekzone.co.nz/forums.asp?forumid=81&topicid=300526
Seems to be a issue often with them
I've read through these, I'm gonna try removing my static IP and give that a try as it seems like latency / routing is somewhat better with CG-NAT otherwise I'll probably look at switching from 2d.
The provider of this server that I am running a traceroute through has emailed 2d on multiple occasions and has had no response which is pretty disappointing.
Linux: @ctv Is the provider of the server a 2degrees customer? If yes have they got a SLA in place with 2degrees?
Routing is best effort and not guaranteed to take the most direct path
No, they are a US-based hosting provider.
Here's a traceroute from my friend on MyRepublic which has much better routing to this provider than I currently do.
Looks to be fixed now. I've just had the static IP removed and now routing is back to normal.
Why would a static IP cause so many problems? that is a bit concerning
Any views expressed on these forums are my own and don't necessarily reflect those of my employer.
Linux: This is something 2degrees needs to look into
Wonder if it was the specific IP range, he was on that was causing the issue
Any views expressed on these forums are my own and don't necessarily reflect those of my employer.
nztim:
Wonder if it was the specific IP range, he was on that was causing the issue
It's clear from the traceroutes that it's the forward (not reverse) routes that is the issue here and that route table on the BNG is different to CG-NAT. If explanations in past threads are anything to go by, 2degrees have a relatively complex system of load balancing traffic out across different cable systems and upstream providers.
It also doesn't help that the destination network is (temporarily or permanently) re-routing their traffic across geographically distributed DDoS mitigating scrubbing centres.
Linux: Did you log an official ticket with 2degrees over the phone with examples?
I'll try to email, tried calling and I was given the "please try again later, the queue is too long" response. Considering the issue is now fixed on my end, I'm not interested in calling multiple times / sitting in queues.
Sounds like you worked around the issue, not fixed it.
yitz:
nztim:
Wonder if it was the specific IP range, he was on that was causing the issue
It's clear from the traceroutes that it's the forward (not reverse) routes that is the issue here and that route table on the BNG is different to CG-NAT. If explanations in past threads are anything to go by, 2degrees have a relatively complex system of load balancing traffic out across different cable systems and upstream providers.
It also doesn't help that the destination network is (temporarily or permanently) re-routing their traffic across geographically distributed DDoS mitigating scrubbing centres.
Their PoP is in LAX, it's just tagged wrong in those traceroutes for whatever reason. You're also correct, it's their anycast DDoS protection.
I believe that it shouldn't cause any issues being in LAX but I may be wrong. They were also not the only provider that I had issues with. I'd say it was a coinflip to have good/bad routing with different providers around the world.
gehenna:
Sounds like you worked around the issue, not fixed it.
Correct, I will try to reach out to get this fixed.
|
![]() ![]() ![]() |