Traffic between Cambridge (UK) and TDC-hosted destination (AS3292, Denmark) tromboning via North America — possible GTT interconnect issue
Hello, [This message was written with AI assistance because I am not an expert in this area, however a substantial amount of manual analysis lies behind it.] We're seeing persistent high latency and apparent trombone routing on traffic between an end-user site in Cambridge, UK and a destination hosted on TDC's network (AS3292) in Denmark. We'd appreciate any insight from operators familiar with this topology, particularly regarding GTT (AS3257) peering with TDC. *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. *Evidence gathered:* Traceroute from Cogent's own network (London → Denmark) shows traffic routed Liverpool → Montreal (Cogent backbone) → GTT in New York → back across the Atlantic to TDC: |1 * 2 be2422.ccr82.lon05.atlas.cogentco.com (154.54.57.61) 2.062 ms 3 port-channel3464.ccr91.lhr01.atlas.cogentco.com (154.54.75.150) 1.017 ms 4 be2133.ccr22.lpl01.atlas.cogentco.com (154.54.63.237) 6.998 ms 5 be3043.ccr22.ymq01.atlas.cogentco.com (154.54.44.166) 76.101 ms 6 be2089.rcr21.ymq02.atlas.cogentco.com (154.54.45.114) 76.498 ms 7 gtt.ymq02.atlas.cogentco.com (154.54.10.178) 76.219 ms 8 ae4.cr14-nyc3.ip4.gtt.net (141.136.105.9) 74.967 ms 9 ip4.gtt.net (208.116.142.170) 75.552 ms 10 lo0-0.lynqe10.dk.ip.tdc.net (93.178.170.33) 175.604 ms| Traceroute from NTT's looking glass (London router) shows a similar pattern, this time via Ashburn/Washington DC before handing to GTT: |1 ae-13.r27.asbnva02.us.bb.gin.ntt.net (129.250.2.111) 78.084 ms 2 ae-17.a05.asbnva02.us.bb.gin.ntt.net (129.250.5.7) 77.432 ms 3 ae-0.gtt.asbnva02.us.bb.gin.ntt.net (129.250.8.22) 78.836 ms 4 ae3.cr3-was1.ip4.gtt.net (213.200.112.218) 76.768 ms 5 ip4.gtt.net (208.97.204.10) 77.534 ms 6 lo0-0.lynqe10.dk.ip.tdc.net (93.178.170.33) 181.747 ms| By contrast, a traceroute via Colt (London) reaches the same destination in three hops entirely within Europe, at ~22ms: |1 212.36.131.20 [MPLS: Label 102112 Exp 0] 2 msec 2 ae23-0.ldn4nqp1.uk.ip.tdc.net (195.66.224.64) 2 msec 3 lo0-0.lynqe10.dk.ip.tdc.net (93.178.170.33) 22 msec| *Observation:* Two independent networks (Cogent and NTT) both hand off to GTT (AS3257) to reach this TDC (AS3292) prefix, and in both cases GTT appears to carry the traffic via North America before returning it to Denmark — adding roughly 150ms round-trip versus the direct European path Colt provides. This suggests GTT's interconnection with TDC for this prefix may currently be limited to (or preferred via) North American exchange points, despite TDC clearly supporting direct European peering (as demonstrated by Colt). Would anyone with visibility into GTT's or TDC's peering topology be able to confirm whether a European interconnect exists or is planned for this route? Any pointers to the right contact for a peering/routing query at either network would also be appreciated. Thanks in advance, Peter Keller.
I have poked someone who knows more about this, but it is my understanding that TDC has this odd policy where they only peer with some networks in the US, causing the exact "harpoon" routing you have observed On Wed, 29 Jul 2026 at 18:04, Peter Keller via routing-wg <routing-wg@ripe.net> wrote:
Hello,
[This message was written with AI assistance because I am not an expert in this area, however a substantial amount of manual analysis lies behind it.]
We're seeing persistent high latency and apparent trombone routing on traffic between an end-user site in Cambridge, UK and a destination hosted on TDC's network (AS3292) in Denmark. We'd appreciate any insight from operators familiar with this topology, particularly regarding GTT (AS3257) peering with TDC.
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.
Evidence gathered:
Traceroute from Cogent's own network (London → Denmark) shows traffic routed Liverpool → Montreal (Cogent backbone) → GTT in New York → back across the Atlantic to TDC:
1 * 2 be2422.ccr82.lon05.atlas.cogentco.com (154.54.57.61) 2.062 ms 3 port-channel3464.ccr91.lhr01.atlas.cogentco.com (154.54.75.150) 1.017 ms 4 be2133.ccr22.lpl01.atlas.cogentco.com (154.54.63.237) 6.998 ms 5 be3043.ccr22.ymq01.atlas.cogentco.com (154.54.44.166) 76.101 ms 6 be2089.rcr21.ymq02.atlas.cogentco.com (154.54.45.114) 76.498 ms 7 gtt.ymq02.atlas.cogentco.com (154.54.10.178) 76.219 ms 8 ae4.cr14-nyc3.ip4.gtt.net (141.136.105.9) 74.967 ms 9 ip4.gtt.net (208.116.142.170) 75.552 ms 10 lo0-0.lynqe10.dk.ip.tdc.net (93.178.170.33) 175.604 ms
Traceroute from NTT's looking glass (London router) shows a similar pattern, this time via Ashburn/Washington DC before handing to GTT:
1 ae-13.r27.asbnva02.us.bb.gin.ntt.net (129.250.2.111) 78.084 ms 2 ae-17.a05.asbnva02.us.bb.gin.ntt.net (129.250.5.7) 77.432 ms 3 ae-0.gtt.asbnva02.us.bb.gin.ntt.net (129.250.8.22) 78.836 ms 4 ae3.cr3-was1.ip4.gtt.net (213.200.112.218) 76.768 ms 5 ip4.gtt.net (208.97.204.10) 77.534 ms 6 lo0-0.lynqe10.dk.ip.tdc.net (93.178.170.33) 181.747 ms
By contrast, a traceroute via Colt (London) reaches the same destination in three hops entirely within Europe, at ~22ms:
1 212.36.131.20 [MPLS: Label 102112 Exp 0] 2 msec 2 ae23-0.ldn4nqp1.uk.ip.tdc.net (195.66.224.64) 2 msec 3 lo0-0.lynqe10.dk.ip.tdc.net (93.178.170.33) 22 msec
Observation: Two independent networks (Cogent and NTT) both hand off to GTT (AS3257) to reach this TDC (AS3292) prefix, and in both cases GTT appears to carry the traffic via North America before returning it to Denmark — adding roughly 150ms round-trip versus the direct European path Colt provides. This suggests GTT's interconnection with TDC for this prefix may currently be limited to (or preferred via) North American exchange points, despite TDC clearly supporting direct European peering (as demonstrated by Colt).
Would anyone with visibility into GTT's or TDC's peering topology be able to confirm whether a European interconnect exists or is planned for this route? Any pointers to the right contact for a peering/routing query at either network would also be appreciated.
Thanks in advance,
Peter Keller.
----- 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/
Hi On Wed, 29 Jul 2026 at 19:07, Ben Cartwright-Cox via routing-wg <routing-wg@ripe.net> wrote:
I have poked someone who knows more about this, but it is my understanding that TDC has this odd policy where they only peer with some networks in the US, causing the exact "harpoon" routing you have observed
OTOH, 3292 *mostly* sells paid transit in DK-area. If you are a "potential" transit customer. They will not peer with you. (Exceptions can apply) US it outside 3292's core market. Consequently, the peering policy on the flip side is much more (selectively) open. Hence the UK <=> Cogent <=> US peering <=> TDC <=> DK traffic pattern. The "maid's tale" is over a decade old. This story goes back to the 2000s.
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. 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 -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
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
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
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<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
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
participants (5)
-
Ben Cartwright-Cox -
Gert Doering -
netravnen+ripelist＠gmail.com -
Peter Keller -
Ponikierski, Grzegorz