Dear Grzegorz, Thanks for your helpful suggestions. I ended up discussing the situation with TDC's peering manager. Between him and the engineer who initially responded at peering@tdk.net, the problem was diagnosed as the UK AS only announcing the relevant prefix to Cogent (even though they have three other transits available), and Cogent refusing to peer with TDC in Europe. He has solved the problem by very kindly arranging a direct route between TDC and the UK AS, although this route is non-redundant so traffic may be temporarily routed via North America again if there are any outages. During the discussion with the peering manager, the hint came up again that the reason behind the UK prefix not being advertised for all available transits may be financial. As Gert said, the proper solution would have been to terminate the contract with the UK AS (and tell them why), and switch to another provider. If the contract with them was under our control I would have had no hesitation in doing that, but we have no influence there. By contrast, the help I got from TDC was first-class :) Thanks again, Peter. On 31/07/2026 12:32, Peter Keller via routing-wg wrote:
Dear Grzegorz,
Many thanks for this helpful info, I really appreciate it. I'll follow it up next week, and update the list with the outcome.
Regards,
Peter.
On 30/07/2026 19:51, Ponikierski, Grzegorz wrote:
On base of Cogent LG I can also add that Cogent learns 93.178.128.0/18 (prefix including 93.178.170.33) from GTT in Canada (community 174:22003):
From Cogent in DE: Thu Jul 30 18:46:35.437 UTC
BGP routing table entry for 93.178.128.0/18
Versions:
Process bRIB/RIB SendTblVer
Speaker 1966517666 1966517666
Last Modified: Jul 22 09:27:33.936 for 1w1d
Paths: (1 available, best #1)
Path #1: Received by speaker 0
3257 3292 3292 3292 3292
66.28.1.207 (metric 186060) from 38.28.1.83 (66.28.1.207)
Origin IGP, metric 4294967294, localpref 100, valid, internal, best, group-best, import-candidate
Received Path ID 0, Local Path ID 1, version 1966517666
Community: 174:10050 174:20666 174:21000 174:22003
Originator: 66.28.1.207, Cluster list: 38.28.1.83, 38.28.2.71, 38.28.1.123, 66.28.1.3
Regards,
Grzegorz
*From: *"Ponikierski, Grzegorz" <gponikie@akamai.com> *Date: *Thursday, 30 July 2026 at 19:50 *To: *Peter Keller <pkeller@globalphasing.com>, "routing-wg@ripe.net" <routing-wg@ripe.net> *Subject: *Re: [routing-wg] Re: Traffic between Cambridge (UK) and TDC-hosted destination (AS3292, Denmark) tromboning via North America ??? possible GTT interconnect issue
Hi Peter,
Indeed, there are some providers who refuse to cooperate until you provide customer ID and circuit ID, but there are many more decent people working in the industry. I suggest writing to TDS NOC (peering@tdk.net) and ask if they are aware that traffic from some Tier 1 providers towards them flies from UK to DK via US. If this is not intentional due to cost cutting, then it should be very important for them to fix it, and they will have leverage on GTT to do it quickly. Traceroutes which you presented should be enough to start investigation on TDS and GTT side. But you can provide even more. Using GTT LG we know that GTT receives route towards this IP from TDS in Europe because from LON, AMS, CPH. It’s nicely visible in GTT looking glass:
From GTT in LON: traceroute to 93.178.170.33 (93.178.170.33), 12 hops max, 52 byte packets
1 ae7.lr3-lon1.ip4.gtt.net (89.149.137.106) 1.181 ms 1.350 ms 1.715 ms
MPLS Label=459754 CoS=0 TTL=1 S=1
2 ae34.cr1-lon1.ip4.gtt.net (89.149.137.189) 2.031 ms 1.162 ms 5.376 ms
3 xe-10-2-0-0.ldn4nqp1.uk.ip.tdc.net (195.215.109.17) 2.008 ms 3.010 ms 0.806 ms
4 lo0-0.lynqe10.dk.ip.tdc.net (93.178.170.33) 20.684 ms 20.042 ms 19.981 ms
From GTT in AMS: traceroute to 93.178.170.33 (93.178.170.33), 12 hops max, 52 byte packets
1 ae0.lr8-ams1.ip4.gtt.net (89.149.128.65) 0.533 ms 0.584 ms 0.371 ms
MPLS Label=545111 CoS=0 TTL=1 S=1
2 ae22.lr4-ams1.ip4.gtt.net (141.136.108.81) 0.726 ms 1.298 ms 0.968 ms
MPLS Label=92139 CoS=0 TTL=1 S=1
3 ae10.lr1-ams2.ip4.gtt.net (89.149.181.94) 0.945 ms 0.919 ms 0.967 ms
MPLS Label=177031 CoS=0 TTL=1 S=1
4 ae7.cr1-ams2.ip4.gtt.net (213.254.231.86) 0.855 ms 0.823 ms 0.765 ms
5 ge8-0.1000M.asd9nxg1.ip.tele.dk (213.200.75.30) 1.011 ms 22.789 ms 0.962 ms
6 lo0-0.lynqe10.dk.ip.tdc.net (93.178.170.33) 11.877 ms 11.875 ms 12.804 ms
From GTT in CPH: traceroute to 93.178.170.33 (93.178.170.33), 12 hops max, 52 byte packets
1 xe-7-0-6-0.alb2nqp8.dk.ip.tdc.net (195.215.109.101) 0.855 ms 0.759 ms 0.651 ms
2 ae0-0.banqe13.dk.ip.tdc.net (83.88.16.31) 1.317 ms 3.292 ms 3.522 ms
3 lo0-0.lynqe10.dk.ip.tdc.net (93.178.170.33) 4.269 ms 1.759 ms 1.563 ms
It can suggest issues between GTT and impacted Tier 1 providers like Cogent and NTT. Or TDS on purpose used GTT’s communities to push back Cogent and NTT ;)
Anyway, please ping TDS directly.
Regards,
Grzegorz
*From: *Peter Keller via routing-wg <routing-wg@ripe.net> *Reply-To: *Peter Keller <pkeller@globalphasing.com> *Date: *Wednesday, 29 July 2026 at 19:31 *To: *"routing-wg@ripe.net" <routing-wg@ripe.net> *Subject: *[routing-wg] Re: Traffic between Cambridge (UK) and TDC-hosted destination (AS3292, Denmark) tromboning via North America ??? possible GTT interconnect issue
Hi, On 29/07/2026 18: 11, Gert Doering wrote: Hi, On Wed, Jul 29, 2026 at 06: 04: 19PM +0100, Peter Keller via routing-wg wrote: *Context / timeline: * The end-user's building-managed ISP changed their upstream international connectivity provider.
ZjQcmQRYFpfptBannerStart
*This Message Is From an External Sender *
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi,
On 29/07/2026 18:11, Gert Doering wrote:
Hi,
On Wed, Jul 29, 2026 at 06:04:19PM +0100, Peter Keller via routing-wg wrote:
*Context / timeline:*
The end-user's building-managed ISP changed their upstream international
connectivity provider. Prior to this change, routing to the affected
destination appeared to transit Colt directly into TDC in Europe with no
issues. Since the change, we have observed the latency problem described
below. We have not been able to confirm with certainty which provider the
ISP switched to, but the timing strongly correlates with the onset of the
issue.
Basically, this won't ever get fixed until the end user raises a ticket
with their provider, and if it doesn't get fixed in a reasonable timeframe,
raise a big stink and change ISP.
Yes, you are absolutely right, but:
* at the UK end, we have very little say in this because our main internet connection is provided by the building manager. We do have a backup connection which is not affected by this problem (so far), and obviously we are not going to relinquish it any time soon ;-)
* this was one of my first suggestions to my colleague at the Danish end, and he did investigate the possibility. However, it seems that all consumer ISPs in Denmark end up going via the same provider, so that is unlikely to solve the problem.
Depending on what other replies I get, I may try to take this back to the UK ISP, but their initial response was that it was out of their scope.
Regards,
Peter
There is a reason why some transits are cheap, and ISPs that do not
care for anything but "ooh cheap transit" need to hear from their customers
why this wasn't such a good idea. They control their network, they need
to take responsibility for it.
(Do I sound like 20 years of talking to "wanna buy cheap transit?" has
worn out my patience with certain transit networks a bit? maybe ;-) ).
Gert Doering
-- NetMaster
----- To unsubscribe from this mailing list or change your subscription options, please visit:https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at:https://www.ripe.net/membership/mail/mailman-3-migration/