@ssingh made me aware of a user report from a Wikidough tester in Finland, who was hitting the Wikidough instance in eqiad, when presumably esams is closer to them.
The traceroute revealed the simple explanation, the user's ISP does not peer with us, and uses Lumen (Level 3 / AS3356) as transit. Lumen path presumably looks good to that ISP - two hops - and so they send it to them. Lumen as expected route the packets by one of our direct links to them, and thus it comes in to eqiad.
Creating this task as we may want to add some traffic-engineering communities to our announcement of the 185.71.138.0/24 Anycast range to Transit providers based on region.
Some communities which might be of use include:
|Transit Provider|Community|Provider's Description|
|------------------|--------------|--------------|
|Lumen| 64980:0|Announce to customers but not to EU peers |
|Lumen| 64984:0|Prepend 4x to all EU peers |
|NTT|2914:4013|prepend o/b to all customers 3x in North America|
|NTT|2914:4023|prepend o/b to all peers 3x in North America|
|NTT|2914:4213|prepend o/b to all customers 3x in Europe|
|NTT|2914:4223|prepend o/b to all peers 3x in Europe|
|Telia|1299:2003|Prepend 3 times to all European peers|
|Telia|1299:5003|Prepend 3 times to all North America peers|
Just a sample to give an idea of what we might do. Certainly it will help with Wikidough, as not only will users have higher latency DNS if their requests take a long path, but CDNs may direct them to server farms close to the Wikidough host, compounding the problem.