Slow Downloads Telekom/Germany


hope i found the most suitable place for this question:)

Since i/we changed our Internet-Provider to the Telekom ( ~2 weeks ago, we’re located in Germany too), we have A LOT of performance problems downloading anything from github. We get maximum download speed of ~100kb when downloading from those telekom connections.

There has been a lot of talk and some answers in the support forum, basically coming down to “there are no slow routes/paths to aws”, “the problem is with AWS routing”.

This has probably already been asked/answered somewhere, but i couldn’t find anything related…
Is anyone at github aware of the problems? Working on a solution or in contact with AWS?
Currently github it is completely unusable for us.




I have the same problem. I did not change my provider, but I’m also using Telekom.
My actual download speed is ~450 Bytes. Totally unusable in that form.

Totally forgot, here ist the link to the (german) support forum:

So far it seems to be with the route back from AWS S3 East via cogent to telekom.

Hey folks,

Thanks for the reports and apologies for the slow download speed! I work for GitHub from my home office in Luebeck, Germany, and am on a DTAG line as well. I’m not seeing any issues on my connection and get a steady 6 MB/s which is within the realm of what’s expected for a 50 MBit VDSL line.

If you could go to, execute the steps outlined on that page, and create a ticket with us, we can bring this up with our infrastructure and network engineers to take a look.


1 Like

Hey @fooforge,

thx for joining in.:wink: Not sure where the repos are hosted, but while cloning i also get a steady fast 6MB in Bonn/next to the TelekomHQ.
This seem to only relate to the release-downloads from S3 (is git-data also hosted on s3?)

Have you tried downloading a release file like “github com/aquasecurity/trivy/releases/download/v0.15.0/trivy_0.15.0_Linux-64bit deb” (sorry, can only put in 2 links per post as new user :)) ? Here i get a steady ISDN rate of 40kb/s. When i turn on VPN and route traffic through our office (which has a different provider) i get the max again.

I created a ticket, although probably not in the right place since none of the choices seemed to fit.

@strowi Happy to! :slight_smile:

I have tested this with both a (https) clone of GitHub - atom/atom: The hackable text editor and a download of the latest (deb) release at Release 1.54.0 · atom/atom · GitHub. The clone terminates on the nearest POP and then gets routed to our main data center in Virginia, the latter is hosted on S3. Both were maxing out at around 6 MB/s.

The good news is that I have found your ticket. I’ll make sure this goes to the right team. Thanks for creating that one!

1 Like

I am having a very similar issue, but this is specific to releases.

When downloading

Resolving (
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: [following]
--2021-01-14 19:30:50--
Resolving (
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 48526287 (46M) [application/octet-stream]
Saving to: ‘bellsoft-jre11.0.9.1+1-linux-amd64.tar.gz.2’

bellsoft-jre11.0.9.1+1-linux-amd64.tar.gz.2   0%[                                                                                           ]  33.55K  4.99KB/s    eta 2h 38m

While downloading archives ( is as fast as expected:

--2021-01-14 19:33:49--
Resolving (
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: [following]
--2021-01-14 19:33:49--
Resolving (
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/zip]
Saving to: ‘’                                     [          <=>                                                                              ]  11.92M  5.96MB/s               ^C

Speed results from github-debug:

2507998 bytes downloaded from at 26.54 Mbps

2507998 bytes downloaded from at 12.23 Mbps

2507998 bytes downloaded from at 8.29 Mbps

2507998 bytes downloaded from at 11.40 Mbps

I can confirm this problem from my side. I’ve run in a similar issue using CircleCI artifact downloads hosted on Amazon S3 as well. Investigations shows if you’re on a Deutsche Telekom (AS3320) connection they have capacity issues handing over traffic to Amazon US. You can test this using a looking glass app. In my case, the only way to get to S3 services is through AS3320, and you are doomed.

I’ve solved the problem using a VPN and tunneling my internet traffic to another ISP with a different AS path to the US in my case IONOS which was smart about, handing traffic off through Telianet which doesn’t have any issues and you get reasonable speedy downloads from S3.



We too had problems with downloads from since days. Today we could solve those by activating IPv6 in our Fritzbox.
What are your settings?

Edit: possibly only luck with a new IP at reconnect.

Any Updates? Downloading AUR-updates with under 30 kbps: packages with above only 50 mb are not downloadable to the end…



Seems like the problems are addressed and routing is adjusted, this path works for me


When I reported the problem the routing path looked like this and was unusable for me.

20-40% packet loss, depending on the IP.

For me this has been “temporarily” solved.
Since yesterday downloads are fast again, but we’ll see if this reappears with an ip-change.


Hi folks,

We have had multiple engineers from various teams look into the matter, and we have also been in touch with DTAG and AWS about the issue.

There seem to be capacity issues between AWS (US East) and DTAG which is to be resolved by those two parties.

The only advice I can give at this point is to continue to raise the issue with your service provider – which hurts as sending folks from one side to the other feels never great. We are also looking at some alternatives, but none of those are ready for prime time yet and will likely take a good amount of time to implement.

I’m sorry I don’t have better news for you at this time, but I hope this clears things up a bit at least.



Some annotations:

  • the issue only occurs on Telekom end-user-connections (“Privatkundenanschluss”)
  • the Telekom business connections appear to be unaffected (“Geschaeftskundenanschluss”)
  • the issue is worse from around 8am-23pm german time (office hours + evening), during night times the downloads are at an acceptable rate

@tobox agree on that, that’s also what I’ve noticed.
It’s maybe also worth noting that only some of the IP subnets of DTAG are affected by this. There are some subnets that are being peered directly from AWS to DTAG. The “slow” subnets are being routed from AWS over Cogent to DTAG which appears to be a very slow route.

Thx for the info @fooforge .

Reading up on the issue it seems to come down to a price-fight between DTAG and other carrieres that send much more traffic towards DTAG than they receive. DTAG wants those carriers to pay for the increased infrastructural costs.

1 Like

It’s such a shame, I though the DTAG is a “premium” provider.
And now I can’t download big files from github.
50…70kb per seconds with decreasing tendency the longer it takes! WTF.