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<mailto: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