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