New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I'm heading to Miami next month to sort this. Digital Reality has been really dragging their feet on breaking down the quadranet cage so we haven't been able to fix Cogent.
Anycast is fixed!
Its actually much better than it was since Terabit has an NY location, instead of everything getting yeeted to Kansas.
Francisco
Yepp, NA is fixed. Would just recommend to get AU/Oceania and Asia-East (JP etc)* on the route to US-WEST (seems to be a black box between GSL and BF and FTS by mtr, but >300ms sounds like EU/CH not US-West - esp. not with GSL which are great for AU-US).
But then again I have no idea if this doable with BGP or your setup or your upstreams setup. Maybe your upstream has only SGP and sends the routes to EU?
*while e.g. India/Singapore etc. should stay on EU/CH.
I'll look at adjusting the route for @Francisco. Right now most of Oceania & Asia run to our Singapore POP, then route to Zurich. If Zurich isn't available based on health checking it falls back to Vegas.
Edit: Check if that's better for you now.
Hi Silvercreek, thanks, that is what I thought (Asia routed through Singapore).
Actually now I see some timeouts again in East Asia, and Singapore also having a higher latency than e.g. 10 hours ago?
https://globalping.io/?measurement=2fuxnDiA9itDCSYcd000215IT,2l8C28jLs7YG6eswR000215IT
(only Sydney reduced the latency for ~40ms)
It should be a bit better now. Asia is a bit special, SG for us has 3x the capacity of Sydney & Seoul & Tokyo, so we prefer routing it there because of the flood sizes we're eating for BuyVM (it's been ~72hrs with 800G-1Tbps fairly non-stop). I may just push some over to Tokyo to see if that makes it happier.
@Francisco so I hope you all had a nice labor day holiday.
Now to make the restart into work more dreadful: do you consider the current state of the anycast transition as finished or do you plan on optimizing it more, and if so, how?
Because with the current state, the anycast ips are barely reachable from Asia and AU/Oceania, while eg. your normal (non-anycast) ranges in NJ are.
I fully understand your upstreams concern if that much traffic is hitting those anycast ranges in Asia as he reported.
But an anycast ip that is practically not really reachable from a lot of countries defies the logic a bit, I'd say.
With GSL via BF it surely is better now in the US but compared to the small Cogent as upstream interim day and the time before w/ Path as upstream, the AU/Asia situation is no fun atm.
Reachable as in? It’s dead dead or just some meh routing? If you can pm me what you’re seeing we can debug. My usual probes are ping.pe so I’ll need more feedback.
Francisco
Ping.pe looks better for ping, I'm mostly testing mtr via globalping.io.
Or via ping.sx, e.g. if you choose xTom Tokyo, Tencent cloud Seoul, Apernet Melbourne etc. as probe for mtr, you get a 100% loss.
I'm having the same with e.g. shockhosting in Tokyo.
(I'm testing against the .1 in both of your anycast /24 ranges, so same as in the above globalping measurement link)
And via ping.pe, mtr shows problems as well esp. for Japan, AU etc, see e.g. here: https://s.ping.pe/w/Q/snap_wQPhxPeN.html (Netactuate JP, DODO JP, Netactuate AU, Vultr JP all show 100% loss as the gre tunnel does not seem to accept the traffic).
Btw. in regard to shock hosting, I also tested the return path, that is BV LV->Shockhosting JP and this goes through both via normal ip (~110ms) as well as via anycast ip (~180ms), but from JP to LV only the normal ip is reachable via mtr, the anycast is 100% loss stopping after the gre.gsl.tools