Page MenuHomePhabricator

Adjust routing policy to increase SSH session speed from East Asia to toolforge
Closed, ResolvedPublic

Description

When connecting from East Asia to toolforge (eqiad), the route tends to go through eqsin instead of connect directly to the US. This makes the latency much larger (compared to connect to other server located in US east), and the SSH connection lag when typing.

An example traceroute is provided below (connect from Tokyo, JP)

$ sudo traceroute --tcp --port=22 login.toolforge.org
traceroute to login.toolforge.org (185.15.56.66), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  91.200.240.71 (91.200.240.71)  0.427 ms  0.462 ms  0.450 ms
 4  * * *
 5  AS23959.xe-0-1-6.tedge0503.newote.bbtower.ad.jp (211.14.4.177)  0.652 ms  0.656 ms  0.636 ms
 6  xe-0-1-6.tedge0503.newote.bbtower.ad.jp (211.14.4.178)  0.520 ms  0.589 ms  0.547 ms
 7  172.29.0.10 (172.29.0.10)  0.756 ms  0.619 ms  0.558 ms
 8  unknown.telstraglobal.net (202.127.69.134)  1.387 ms  1.567 ms  1.673 ms
 9  i-95.jtha-core02.telstraglobal.net (202.47.216.145)  2.176 ms  1.993 ms  1.977 ms
10  i-1055.sgcn-core01.telstraglobal.net (202.84.140.173)  78.953 ms  80.143 ms  79.974 ms
11  i-25142.sgcn-core01.telstraglobal.net (202.84.136.26)  80.267 ms * i-1055.sgcn-core01.telstraglobal.net (202.84.140.173)  79.471 ms
12  i-91.istt04.telstraglobal.net (202.84.224.197)  79.429 ms  81.202 ms i-93.istt04.telstraglobal.net (202.84.224.190)  76.449 ms
13  14907.sgw.equinix.com (27.111.228.186)  80.084 ms  75.770 ms  78.965 ms
14  xe-5-1-2.cr1-codfw.wikimedia.org (103.102.166.139)  217.722 ms  218.542 ms  214.922 ms
15  xe-4-2-0.cr1-eqiad.wikimedia.org (208.80.153.220)  229.757 ms  233.257 ms  233.042 ms
16  * * *
17  cloudgw1001.eqiad1.wikimediacloud.org (185.15.56.245)  244.367 ms  241.160 ms  244.577 ms
18  login-buster.toolforge.org (185.15.56.66)  242.243 ms  255.406 ms  238.207 ms
19  login.tools.wmflabs.org (185.15.56.66)  255.831 ms  242.444 ms  244.644 ms

I suggest that when connecting to toolforge (eqiad) from areas closer to eqsin compared to eqiad (especially East Asia region), the routing does not detour to Singapore, but picks a closer route.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Thanks for the report.

This is because we advertise our "customer" prefixes from all our POPs to improve the user experience by transiting through our network instead of over the Internet.

As you pointed out there are edge cases, and perhaps those edge cases alone justify this type of routing ("cold potato"). This might also make our configuration simpler.

We will discuss it with @cmooney and get back to you.

Indeed thanks for the report.

@ayounsi overall I would agree with us making this change, at least for the WMCS Eqiad prefix (185.15.56.0/24).

Customer-originated prefixes should probably not be announced to the internet except for at the POPs where we receive them. While one might argue our own transport is more reliable, or at least we have eyes on it, it's likely to always incur a latency penalty for users. On balance I think it's better the customer goes internet -> destination pop.

The other question is if we should distribute them internally between POPs, i.e. what path our own servers in Eqsin would use to get to WMCS Eqiad or similar. I'm inclined to say we should keep that over our own transport, but happy to discuss.

Change 947993 had a related patch set uploaded (by Ayounsi; author: Ayounsi):

[operations/homer/public@master] Only advertise local customers to external peers

https://gerrit.wikimedia.org/r/947993

ayounsi moved this task from Backlog to This quarter on the netops board.

@cmooney mentioned me that the previous syntax didn't work, this is because the as-path-calc-length term ignores confederations.

I updated the patch and tested it in ulsfo, this works as expected:

cr3-ulsfo# run show route advertising-protocol bgp 4.15.72.113 
  Prefix		  Nexthop	       MED     Lclpref    AS path
* 185.15.56.0/24          Self                                    ?
* 185.71.138.0/24         Self                                    I
* 198.35.26.0/24          Self                                    I
* 198.35.27.0/24          Self                                    I
* 198.73.209.0/24         Self                                    11820 ?
[edit policy-options policy-statement BGP_outfilter term customers from]
+     protocol bgp;
+     as-path only_one_asn;
cr3-ulsfo# run show route advertising-protocol bgp 4.15.72.113
  Prefix		  Nexthop	       MED     Lclpref    AS path
* 185.71.138.0/24         Self                                    I
* 198.35.26.0/24          Self                                    I
* 198.35.27.0/24          Self                                    I
* 198.73.209.0/24         Self                                    11820 ?

Change 947993 merged by jenkins-bot:

[operations/homer/public@master] Only advertise local customers to external peers

https://gerrit.wikimedia.org/r/947993

Rolled everywhere, another example, cr1-codfw:

before
  Prefix		  Nexthop	       MED     Lclpref    AS path
* 185.15.56.0/24          Self                                    ?
* 185.15.57.0/24          Self                                    ?
* 185.71.138.0/24         Self                                    I
* 198.35.27.0/24          Self                                    I
* 198.73.209.0/24         Self                                    11820 ?
* 208.80.152.0/23         Self                                    I
after
  Prefix		  Nexthop	       MED     Lclpref    AS path
* 185.15.57.0/24          Self                                    ?
* 185.71.138.0/24         Self                                    I
* 198.35.27.0/24          Self                                    I
* 208.80.152.0/23         Self                                    I

The SF office as well as eqiad WMCS range are gone, but codfw WMCS is still there.

That should solve your issue, please reopen if needed.