Bad Routing from DTAG in Germany?

Thanks for your Report. I will probably create a Support Ticket this evening because nobody from Cloudflare responded till now

Ticktet’s probably a good idea, thanks!
Just to add though: I‘ve also created a ticket through (their DNS solution) so maybe we can get some attention from multiple sources.

1 Like

I created a Ticket with the Cloudflare Support.
Ticketnumber is 2102224 if anyone from Cloudflare should see this and want to look


This kinda annoying this thread got 20 reply and no one replied from cf.

Yes, let’s see when I get a response to the ticket. They are currently warning of longer waiting times than usual.

@cloonan You are in the CCs for the Ticket. Could you maybe look if there are any new Infos because i didnt recieved any Form of Answer to the Ticket yet. Would be really nice if someone from Cloudflare would say something. At least that they look at it or something like that

Update: I got an update on my ticket. The employee did another traceroute from Amsterdam and Frankfurt and both times he landed in Paris. Cloudflare will check this now.

Hi again,

On checking with our network team, Amsterdam should be back and serving requests:

Router: gin-f2c-thar1
Site: DE, Frankfurt, F2C
Command: traceroute inet4 as-number-lookup

traceroute to (, 30 hops max, 52 byte packets
 1 (  6.651 ms  6.570 ms  6.651 ms
     MPLS Label=39 CoS=0 TTL=1 S=1
 2 (  6.675 ms  7.025 ms *
     MPLS Label=29 CoS=0 TTL=1 S=1
 3 ( [AS  13335]  6.726 ms  6.388 ms  7.386 ms

Still working on Frankfurt, that may take a little longer.

1 Like

Awesome, thank you very much for the update and staying on this!

Im still in contact with the Support. It worked for maybe 1 hour the day i reported back and then got routed over Paris again. So the Support is still on it

1 Like

Thanks for the update, I haven’t even heard anything back yet from support.

thank you very much for staying on this issue and getting in contact with cloudflare

I got this reply 2 days ago.

Thanks for your patience here.

The Cloudflare Network engineering team is conducting some tests in the FRA data center so traffic is expected to go to other locations for the time being.

I reopend the Ticket now because the Problem is still there and i dont believe that a Test is the Reason for this.

1 Like

Update: I have now received a response from a Cloudflare Escalation Engineer. Cloudflare is aware of the problem and knows that it has existed for more than 2 months, yet Cloudflare does not have a timetable for when the problem will be fixed.


First of all, I’d like to apologize for the routing issue you’re seeing. We have been running tests since early January 2021 to investigate a critical issue within our Frankfurt PoP. As part of this test, we shut off our peering session with Tata in Frankfurt. In the absence of Frankfurt, you can expect traffic to route to our datacenters in Paris or Amsterdam instead. I’m afraid that there’s no ETA right now on when this test may conclude. You are correct that this issue is ongoing and has been ongoing for >2 months.

Sorry for the inconvenience. Please let us know if you have any further questions or concerns.

I’m afraid there is nothing we can do but wait until Cloudflare finds the problem in Frankfurt and re-enables the peering session.

That’s a bit disappointing but thanks for the update.
Could you maybe mention that there is also an issue with the TATA services in Paris, as we have discussed above?
Being routed through Paris shouldn’t be a problem by itself but it seems to have issues as well.

I can confirm this issue as well. It started exactly the second week of January, on 11.2.2021.
I am connected via Unitymedia/Vodafone. I have a smokeping running and there is an increase in latency since week 2 of this year where it jumped from little less than 10ms to an average of almost 20ms.

I am literally in Frankfurt but after TATA it goes to Clouldflare Paris.
Here is my traceroute.

[email protected] ~> traceroute
traceroute to (, 64 hops max, 52 byte packets
 1 (  4.479 ms  1.540 ms  2.082 ms
 2  * * *
 3 (  66.037 ms  134.185 ms  11.176 ms
 4 (  16.663 ms  14.941 ms  9.847 ms
 5 (  151.006 ms  29.347 ms  148.171 ms
 6 (  15.617 ms  12.382 ms  11.253 ms
 7 (  154.987 ms  143.808 ms  178.002 ms
 8 (  26.732 ms  34.646 ms  146.722 ms
 9 (  25.982 ms  37.998 ms  29.404 ms
10 (  30.413 ms  52.480 ms  32.613 ms
11 (  55.084 ms  29.809 ms  33.163 ms
12 (  33.687 ms  27.958 ms  25.755 ms

I dont really see a Problem other than the increased latency and slower Downstream due to slow Transfer Speeds inside Tatas Network. What Problem do you exactly have again?

This fits to the statement of the Cloudflare employee that they have switched off their peering with Tata in Frankfurt at the beginning of the year to fix a problem which they have not managed so far. From the network of O2 you can reach Cloudflare’s Frankfurt POP normally because it runs over the DECIX and not over Tata. But the DTAG and Vodafone are routing over TATA which ends in Paris, because the disabled Frankfurt Tata Peering

At least Vodafone landline internet connections route via TATA. If I connect via my mobile phone (VF) and do a trace, then it goes straight from VF to DECIX and CF.

I guess it is because your vodafone mobile contract is made with “vodafone deutschland” which has a different peering than Vodafone west (ex unitymedia) that runs your HFC connection when living in baden-württemberg, Nordrhein-Westfalren or Hessen.
Vodafone West is using liberty global infrastructure ( which uses TATA as transit to Cloudflare.

The latency when it jumps to TATA was just really bad, outside of what you’d expect even when taking the longer route (Sometimes seconds for me) but it’s actually not the case anymore so I’ll withdraw that part. :smile: