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.
Seems that lots of LA nodes' routing changed from NLayer to tinet ?
vastwelkin
Member
in General
I'm tracerouting my LA vpses from asia .
A few days ago, all of them went with NLayer which has great connectivity.
But today I found that almost all of them went with tinet which is very slow.
Have you got the same result if you are in asia?
Comments
Who are you with? We don't even have nLayer in our next much. Is this with Quadranet / Colocrossing?
Though, since the nLayer / Tinet merger, nLayer routes a lot of traffic via Tinet.
You'll also find that there has been reports of packet loss via nLayer recently hence the possible re-routing.
Yes indeed, I am also aware of this change.
Maybe ColoCrossing could tell us something.
Can you share some trace routes? Preferably in both directions.
it depend what datacenter they use,
bytheway didnt NLayer and tinet is same company?
That's right, but the networks haven't followed merged yet or may never. Just like Global Crossing and Level3.
Yeah this... They are supposed to be operating the networks separately but nLayer is a Tier 2 and Tinet is a tier 1 after all. I'm sure relying on Tinet more is financially beneficial to them.
Quadranet / Colocrossing, especially PacificRack, they all switched to tinet.
As a result, very slow indeed.
Quadranet IS Pacific Rack IS OC3 Networks. Just renamed renamed.
Possibly an issue with their nLayer side of things. Would contact them and get them to fix it.
Here are the trace routes, and I anonymized some of my server's ips.
From asia to LA:
From LA to asia:
tracepath 125.65.83.1
I see the problem, I will talk to GTT.
Cloud you share something? I could not find out where is the problem.
Traffic is going the wrong way out of Asia -- through Europe instead of across the Pacific.
It's likely on purpose. Rerouted on congestion.
Just spoke to ipeng at GTT/nLayer and I can confirm that this is a China Telecom routing preference. Not much we can do from our side.
Can I tell you something.... I understand customers from China are complaining a lot recently about the routing from China to West Coast of the US. eg LA. China Telecom is playing this cunning trick to all the customers who are using VPS outside China. They manipulate the BGP routing so instead of going straight through nlayer or other faster US provider, the traffic is mislead to Ireland then goes to the US. That's what they are doing. not sure if government is involved in this. but something for sure is not long ago China Telecom was promoting their shitty VPS in China.
Dear Biloh,
Please watch your language on this forum. The words I have quoted are well known to be offensive.
why china telecom word is offensive? that's just company name
Trust me, you dont wanna know.
We are working on a solution to this problem for CC customers.
Known trouble for weeks now... and now only for China! To find a "not-too-far" VPS network location from east or south east Asia is far from obvious.
I think it is probably an isolated issue. I use www.linkwan.com for a traceroute from China to 67.215.251.214.static.quadranet.com. They are reporting direct peering with nlayer at LA. I try different locations and all landed directly at LA.
From 101.226.4.176（西部数码成都服务器）To 67.215.251.214 的路由信息
Hop IP地址 节点域名 所在地 耗时(ms)
1 61.139.126.1 四川省成都市 0ms
2 118.117.93.105 四川省成都市 0ms
3 218.89.158.233 四川省眉山市ADSL 5ms
4 171.208.202.169 四川省成都市 5ms
5 202.97.43.153 四川省 35ms
6 202.97.33.166 上海市 35ms
7 202.97.60.182 上海市 38ms
8 202.97.52.150 电信骨干网 191ms
9 202.97.90.114 北京市 202ms
10 69.31.124.25 xe-5-0-3.ar1.lax2.us.nlayer... 218ms
11 69.31.121.254 as29761.xe-1-0-2.ar1.lax2.u... 203ms
12 96.44.180.42 colo-lax8 202ms
13 67.215.251.214 67.215.251.214.static.quadr... 199ms
It depends on the transit carrier. It's clearly an issue with Tinet and China Telecom. The easiest way would just be to route around it by using a different carrier for that route (this is why you need multiple carriers in the mix).
It can happen anywhere and at all locations, not just Asia (but Asia happens more often). We had a similar incident with level3 to China and had to route it to Savvis.
@concerto49 Can you force what route China telecom(or other user end carrier) use?
No? But you can control what you do. Outbound is easiest of course. Simplified examples (it may not be 100% correct implementation wise, but easier to understand).
E.g. nLayer -> China Telecom is congested. Right. Tell it to go PCCW -> China Telecom. You own the router and it goes out from your router so you can choose.
Inbound is harder. However, if you have enough carriers, you can always just stop announcing a carrier in the meantime until it's fixed (unless your pipes are always at full capacity and can't re-route).
E.g. China Telecom -> (they pick the best route) Tinet/nLayer/PCCW. You turn off nLayer. They can't pick it
But if you complete turn off nLayer, will that causing some unintended consequence? Probably yes. There maybe someone else in a carrier that highly relied on nLayer and causing them added latency.
It's a simplified example. You can use the communities to make changes http://onesc.net/communities/as4436/ A lot of work can go on behind the scenes to make a good network.