Probleme bei Verbindungen zu Amazon CloudFront

[#1]

Hallo zusammen!

Ich stelle zur Zeit massive Probleme bei allerlei Verbindungen in Richtung Amazon Web Services fest und bin mir nicht sicher wo ich diese sonst melden könnte.

Im Dezember gab es bereits Probleme mit verschiedenen S3 Verbindungen (z.B. zu GitHub), welche inzwischen gelöst scheinen. Nun bin ich abe ran dem Punkt, an dem Verbindungen zu Amazon CloudFront kaum funktionsfähig sind. Viele Seiten sind hierdurch unerträglich langsam oder teilweise gar nicht zu erreichen. Ein gutes Beispiel hierfür ist das Telekom-Hilft Forum, welches für mich kaum benutzbar ist.

Um auszuschließen dass das Problem bei mir im internen Netz liegt, habe ich hier noch zwei MTR traces:

❯ mtr -rn -c 100 media.forgecdn.net
Start: 2021-02-22T15:02:17+0100
HOST: thor.home.intranet          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.10.1               0.0%   100    0.7   1.3   0.7  37.1   3.6
  2.|-- 62.155.245.56              0.0%   100    5.5   8.6   4.5 189.2  19.5
  3.|-- 217.5.113.74               0.0%   100   10.5 495.8  10.3 3005. 655.4
  4.|-- 217.5.113.74               0.0%   100   10.2 169.3   9.9 1804. 353.7
  5.|-- 80.157.204.66              0.0%   100    9.7  11.4   9.2  37.8   4.3
  6.|-- 213.200.119.214            0.0%   100   18.7  19.9  18.5  48.1   4.5
  7.|-- 77.67.121.254              0.0%   100   20.0  20.7  19.3  29.3   1.5
  8.|-- 52.93.16.68               51.0%   100  179.3 181.0 179.2 185.2   1.5
  9.|-- 52.93.16.81               43.0%   100  173.8 174.2 170.7 175.6   0.7
 10.|-- 52.46.93.215              41.0%   100  178.8 180.4 178.5 223.7   5.9
 11.|-- 52.95.60.64               48.0%   100  174.5 175.7 173.4 200.4   4.1
 12.|-- 52.95.60.155              33.0%   100   73.6  69.1  33.3 122.4  23.9
 13.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
 14.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
 15.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
 16.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
 17.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
 18.|-- 13.249.9.127              40.0%   100  178.4 179.8 177.8 216.1   5.4

❯ mtr -rn -c 100 telekomhilft.telekom.de
Start: 2021-02-22T15:04:46+0100
HOST: thor.home.intranet          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.10.1               0.0%   100    1.2   1.0   0.8   1.4   0.1
  2.|-- 62.155.245.56              0.0%   100    5.0   6.9   4.6  36.4   5.4
  3.|-- 62.159.99.154              0.0%   100   97.6  12.5  10.8  97.6   8.6
  4.|-- 62.159.99.154              0.0%   100   30.5  11.2  10.1  30.5   2.0
  5.|-- 80.157.204.66              0.0%   100   10.1  13.0   9.4 100.2  10.8
  6.|-- 213.200.119.214            0.0%   100   54.1  20.1  18.3  54.1   4.7
  7.|-- 77.67.121.254              0.0%   100   20.2  20.4  19.5  25.2   1.0
  8.|-- 52.93.16.84               31.0%   100   31.5  50.8  28.2  81.4  11.1
  9.|-- 52.93.16.167              49.0%   100  179.1 180.0 173.2 203.8   5.1
 10.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
 11.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
 12.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
 13.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
 14.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
 15.|-- 143.204.226.98            49.0%   100  178.2 177.8 174.5 179.2   0.8

Die gängigen Problemlösungsversuche (Router einige Minuten vom Strom trennen, etc.) habe ich selbstverständlich schon ausprobiert - ohne Erfolg.

[#2]

@Timur K. Danke auch von mir für das Nachhaken und Kümmern! Ich arbeite selbst im Netzwerksupport und weiß, dass solche Probleme nicht immer leicht nachzuvollziehen sind. Danke für's Dranbleiben!

[#3]

@home35

Gerne doch und vielen Dank für dein Feedback

Gruß
Timur K.

[#4]

Hallo an alle, 

ich habe auch massive Probleme mit der Verbindung zu einigen Diensten. Was bringt mir eine 100Mbit Leitung, wenn die Geschwindigkeit lediglich bei Speedtests anliegt..

Bei Tidal braucht es mehrere Sekunden bis ein Lied startet, ein Softwareupdate meines Samsung-Handys (800MByte) hat eine gute Stunde gedauert, aktualisieren von Anwendungen über die Paketverwaltung bei Linux dauert einen ganzen Nachmittag und Amazon.de kann man beim Laden der Bilder zusehen.

Ich hoffe, dass möglichst schnell eine Lösung des Problems gefunden werden kann!

[#5]

@Mobil-Funker

Vielen Dank für dein Feedback. Wir stehen zu Amazon in Kontakt und bitten bis zu Behebung um Geduld.

Gruß
Timur K.

[#6]

Hallo zusammen,

um diesen Post nicht sterben zu lassen, hier ein aktueller Stand:

Stand 08.03.2021 - Leider immer schlimmer. Man sieht in meinem Graphen ganz genau, dass wenn die lieben Deutschen schalfen gehen (so ab 1 Uhr nachts), die Leitung frei ist. Sobald "wir" aufstehen (gegen 06:00 Uhr) beginnt der Spaß. Heute kann ich wieder nicht arbeiten.

Also, wie gesagt, ist ein REMINDER, dass das Problem auch HEUTE noch existiert!

[#7]

Ich möchte die Aussage von @sttwebs bekräftigen, dass Problem ist nach wie vor vorhanden. Seit gestern (07.03.) läuft es wieder besonders schlecht, heute sind diverse Dienste Richtung Cloudfront quasi gar nicht nutzbar. Es bleibt abzuwarten...

[#8]

Hallo zusammen,

gibt es in dieser Angelegenheit vielleicht ein Update @Timur K.? In den letzten zwei Wochen scheint sich nicht viel getan zu haben und es ist langsam etwas frustrierend. Hier mal wieder tracerts zu teleomhilft.telekom.de, was heute ebenfalls wieder extrem schlecht läuft:

Routenverfolgung zu d289pckehalujw.cloudfront.net [143.204.226.98] über maximal 30 Hops:

1 1 ms <1 ms 1 ms 192.168.0.1
2 38 ms 23 ms * 62.155.243.206 <------------------ ??
3 48 ms 61 ms 77 ms 217.5.112.206
4 41 ms 48 ms 56 ms 217.5.112.206
5 76 ms 73 ms 75 ms 80.157.204.66
6 19 ms 20 ms 23 ms 213.200.119.214
7 60 ms 47 ms 60 ms 77.67.122.2
8 * * * Zeitüberschreitung der Anforderung. <------------------ ??
9 68 ms 57 ms 42 ms 52.93.16.161
...
15 * 60 ms 30 ms 143.204.226.98 <--------------

Routenverfolgung zu d289pckehalujw.cloudfront.net [143.204.226.112] über maximal 30 Hops:

1 35 ms 30 ms 25 ms 62.155.243.206
2 52 ms 43 ms 58 ms 62.155.243.206
3 * 76 ms * 217.5.112.206 <------------------ ??
4 20 ms 19 ms 18 ms 217.5.112.206
5 9 ms 10 ms 10 ms 80.157.204.66
6 50 ms 41 ms 28 ms 213.200.119.214
7 32 ms 29 ms 30 ms 77.67.121.254
8 87 ms 88 ms * 52.93.16.132
9 * * * Zeitüberschreitung der Anforderung. <------------------ ??
...
16 * 62 ms 50 ms 143.204.226.112 <--------------

Routenverfolgung zu d289pckehalujw.cloudfront.net [143.204.226.42] über maximal 30 Hops:

1 2 ms <1 ms <1 ms 192.168.0.1
2 13 ms 13 ms 15 ms 62.155.243.206
3 26 ms 34 ms 43 ms 217.5.91.46
4 9 ms 9 ms 10 ms 217.5.91.46
5 28 ms 56 ms 78 ms 80.157.204.66
6 58 ms 83 ms 83 ms 213.200.119.214
7 22 ms 28 ms 41 ms 77.67.121.254
8 81 ms 56 ms * 52.93.16.36 <--------------
9 24 ms * 55 ms 52.93.16.161 <--------------
...
15 70 ms 68 ms 63 ms 143.204.226.42

Das Problem ist nach wie vor da und es scheint immer schlimmer zu werden... Twitch (VOD) läuft weiterhin mit im Schnitt 100 KByte/s und sinkend, für einen Steam Download muss ich an die 10 Server abklappern, bis ich eine sinnvolle Anbindung bekomme und weitere von mir genutzte Dienste wie eveonline.com (z.B. Download von resources.eveonline.com) bewegen sich weiterhin bei < 100 KByte/s.

Ein Wireshark Mitschnitt eines Twitch (VOD-)Streams zeigt mir mehr TCP retransmissions als sonstwas, zufälliges Beispiel:

Das kann so echt nicht weitergehen! Ich mein, das ist schon bissl heftig. Soll es mir nun "im besten Netz Deutschlands" nur noch via VPN Strecke in die Niederlande vergönnt sein, nen populäres Streamingangebot zu nutzen? Das wäre dann doch eher peinlich.

Und das ist genau der Punkt: Schmeiß ich nen VPN sonstwohin an, läuft alles bestens. @sttwebs hatte ja vor Wochen bereits aufgezeigt, dass Unitymedia als ISP dieses Problem nicht hat. Es kann also kaum nur bei Amazon hängen. Ich bin damit ja auch nicht alleine. Erst Anfang März gab es lt. eurem Twitteraccount das gleiche Problem mit Twitch, nur andersrum: Telekom Nutzer konnten nur noch VODs auf Twitch aufrufen, Livestreams liefen gar nicht mehr (Twitch Fehler "2000" wenn ich mich recht entsinne). Seltsamerweise ist bei mir eben wie gesagt andersrum, was wohl weiterhin unterstreicht, dass es sich um regionsabhängige routing/peering Probleme handelt.

Und ich mein, mir geht es jetzt nicht nur um Twitch an sich, aber das ist eben der Dienst, den ich privat am besten nachvollziehen kann.

Es wäre echt gut, wenn sich hier etwas bewegt! Es ist ja schließlich im Interesse aller Beteiligten, dass diverse Dienste auch genutzt werden können.

Danke und Gruß,
M.

[#9]

Hallo,

ich scheine das Problem gefunden und (vorerst) "gelöst" zu haben. In meinem Fall sind offensichtlich die verwendeten DNS Server ein Problem. Klingt zwar nicht besonders naheliegend, aber nach mehrfachen empirischen Tests ist das Ergebnis eindeutig.

Ich verwende die DNS Server von Cloudflare 1.1.1.1 und 1.0.0.1. Sind diese beiden Server im Router konfiguriert, tritt das Problem nachvollziehbar immer wieder auf, sprich: Massiver Paketverlust Richtung AWS/Cloudfront. Konfiguriere ich den Router um auf die DNS Server des ISP, also der Telekom, ist das Problem sofort weg:

DNS = Cloudflare (1.1.1.1 + 1.0.0.1) -> Router Neustart -> Peering Richtung AWS/Cloudfront extrem fehlerbehaftet

DNS = ISP (aktuell: 217.237.148.102 + 217.237.151.115) -> Router Neustart -> Problem weg

Ich habe die obigen zwei Schritte nun mehrfach wiederholt und es lässt sich immer wieder zu 100% reproduzieren. Auch im Wireshark sind keinen DUP ACKs/Retransmissions mehr nachvollziehbar, sobald der Router mit den DNS Servern der Telekom neu gestartet ist. Starte ich den Router mit den 1.1.1.1/1.0.0.1 DNS'n neu, ist das Problem wieder da.

nslookup sagt folgendes:

> telekomhilft.telekom.de
Server:  one.one.one.one
Address:  1.1.1.1

Nicht autorisierende Antwort:
Name:    d289pckehalujw.cloudfront.net
Addresses:  2600:9000:2113:b400:3:5126:fb00:93a1
          2600:9000:2113:f400:3:5126:fb00:93a1
          2600:9000:2113:2000:3:5126:fb00:93a1
          2600:9000:2113:2a00:3:5126:fb00:93a1
          2600:9000:2113:ea00:3:5126:fb00:93a1
          2600:9000:2113:4c00:3:5126:fb00:93a1
          2600:9000:2113:6000:3:5126:fb00:93a1
          2600:9000:2113:8400:3:5126:fb00:93a1
          143.204.226.57
          143.204.226.42
          143.204.226.112
          143.204.226.98
Aliases:  telekomhilft.telekom.de
          riokc95758.lithium.com

> telekomhilft.telekom.de
Server:  [192.168.0.1] = Router mit den DNS der Telekom
Address:  192.168.0.1

Nicht autorisierende Antwort:
Name:    d289pckehalujw.cloudfront.net
Addresses:  2600:9000:2156:1600:3:5126:fb00:93a1
          2600:9000:2156:3c00:3:5126:fb00:93a1
          2600:9000:2156:2800:3:5126:fb00:93a1
          2600:9000:2156:5000:3:5126:fb00:93a1
          2600:9000:2156:dc00:3:5126:fb00:93a1
          2600:9000:2156:7a00:3:5126:fb00:93a1
          2600:9000:2156:b200:3:5126:fb00:93a1
          2600:9000:2156:f800:3:5126:fb00:93a1
          143.204.90.121
          143.204.90.14
          143.204.90.27
          143.204.90.124
Aliases:  telekomhilft.telekom.de
          riokc95758.lithium.com

Es werden durchaus verschiedene v4 IPs geliefert. Allem Anschein nach gibt es wohl ein Problem damit, die von 1.1.1.1/1.0.0.1 aufgelösten IPs fehlerfrei zu erreichen?

Ich kann nur sagen, dass es sich bei mir genau so verhält. Ich werde das weiter beobachten, ob es sich damit wirklich getan hat, wenn die ISP DNS Server verwendet werden.

Wäre interessant zu wissen @tschwend @sttwebs, ob ihr auch alternative DNS Server verwendet oder nicht.

Gruß,

M.

[#10]

Sehr interessanter Fund @home35 - ich hatte in der Tat AUCH den 1.1.1.1/1.0.0.1 DNS eingerichtet. Ich habe die DNS-Server in meinem Domain Controller abgeändert und werde meine Systeme umbauen, ich denke ich kann die nächste Woche sagen, ob es etwas gebracht hat.

[#11]

Hallo zusammen!

Wie auch ihr habe ich Cloudflare DNS als meinen Haupt-DNS eingerichtet. Andere alternative DNS Anbieter (wie z.B. Quad9, 9.9.9.9) oder auch Google scheinen das Problem nicht zu haben.

Ich habe bei mir nun einmal auf Quad9 umgestellt und werde das weiter beobachten. Dennoch wäre es schön, die trotz allem bestehende Routing- oder Peeringproblem zu finden und diese entsprechend zu lösen. Dass der DNS aus unterschiedlichsten Gründen einen anderen Zielserver auswählt (z.B. ECS/EDNS), maskiert dieses das Problem ja nur. Es ist mMn lediglich Glück, dass man nicht über die selben Netze geroutet wird.

Gruß

[#12]

Das sehe ich genauso @tschwend.

@Timur K.

Das Problem an sich scheint zumindest identifiziert zu sein. Wenn die DNS Server von Cloudflare verwendet werden, 1.1.1.1 und 1.0.0.1, kommt es zu den im Thread vielzitierten Routing-/Peeringproblemen Richtung AWS/Cloudfront. Evtl. kann man diese konkrete Information, sofern noch nicht bekannt, nochmals an die relevanten Fachabteilungen weitergeben. Denn grundsätzlich sind das Problem sicher nicht die Cloudflare Server. In der Tat ist es u.U. nur eine Frage der Zeit, bis das Problem auch mit anderen DNS Servern auftritt. Zumal es mit den Cloudflare DNS'n bis vor wenigen Wochen ebenfalls sauber funktioniert hatte.

[#13]

Hallo zusammen,

also der DNS-Schwenk hat defintiv eine Besserung erbracht. Ich muss täglich mit registry.redhat.io arbeiten. Dies war auch vorher meine CloudFront IP mit über 30% Paketverlust. Mit den Telekom-DNS-Servern bekomme ich natürlich eine neue IP ausgespuckt. Das erklärt dann auch "den anderen Weg".

Der Paketverlust geht gegen null.
Telekom-Leitung:

okd4-services.sttproductions.de (10.83.30.210)                                                                                                                                      2021-03-16T17:37:46+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                                                                                                    Packets               Pings
 Host                                                                                                                                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 10.83.30.253                                                                                                                                                   0.0%  3835    0.8   1.1   0.6 168.4   8.3
 2. 172.16.83.254                                                                                                                                                  0.0%  3834    0.8   0.5   0.3  10.7   0.5
 3. 62.155.246.210                                                                                                                                                 0.3%  3834   38.2   3.2   0.9  76.4   6.9
 4. 217.0.198.10                                                                                                                                                   0.3%  3834    3.0 288.0   1.9 5567. 791.0
 5. 80.156.160.158                                                                                                                                                 0.4%  3834    2.8   7.5   1.6  93.9   9.8
 6. 192.168.224.151                                                                                                                                                0.3%  3834    2.7   2.4   1.4  49.1   1.8
    192.168.224.23
 7. 192.168.230.27                                                                                                                                                 0.4%  3834    3.2   2.3   1.3  19.7   1.4
 8. 192.168.237.3                                                                                                                                                  0.2%  3834    2.8   2.3   1.3  29.6   1.7
    192.168.224.21
 9. 96.16.143.23                                                                                                                                                   0.4%  3834    2.2   2.2   1.2  31.2   1.6

Unity-Leitung:

c-ulin-01 (192.168.210.113)                                                                                                                                                         2021-03-16T17:39:49+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                                                                                                    Packets               Pings
 Host                                                                                                                                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.210.254                                                                                                                                                0.0%  3950    0.4   0.2   0.1   2.3   0.3
 2. 178.200.118.1                                                                                                                                                  0.0%  3950    6.9  10.7   3.3 127.5  12.5
 3. 81.210.129.132                                                                                                                                                 0.0%  3950    7.8   8.1   2.5  71.0   5.1
 4. 84.116.197.245                                                                                                                                                 0.0%  3950   15.3  10.2   3.8 3034.  53.4
 5. 84.116.134.217                                                                                                                                                 0.0%  3950    8.6   8.3   3.0  74.3   4.4
 6. 213.46.171.70                                                                                                                                                 67.1%  3950  132.2 396.7   7.0 9636. 1403.
 7. 72.246.31.243                                                                                                                                                  0.0%  3950    8.1   7.1   2.8  25.7   1.5

Da mir aber traceroute alleine nicht als Besserungs-Beweis gelangt hat, habe ich mehrere Systeme über registry.redhat.io ausgerollt (eine Installation meiner Systeme sind ungefähr 30GB). Mit dem CF-DNS Servern war es ein Wunder wenn eine Installation durchging, heute gingen bis zu 5 Installationen durch ohne Probleme.

Dennoch, auch wenn das nun Abhilfe schafft, frage ich mich, warum hier nun ein DNS-Server Zwang entsteht? Mit Unity war es egal ob ich Unity-DNS, Google-DNS oder CF-DNS Server verwendet habe.

Ich wäre an einer EHRLICHEN Antwort des Support-Teams interessiert und zwar:
Arbeitet man an diesem Problem nun WIRKLICH oder heißt es simpel und einfach "nutzt unsere DNS-Server und gut ist".

[#14]

@home35 @sttwebs @tschwend
Hallo Zusammen,

entschuldigt bitte die späte Nachricht. Ich kann euren Unmut verstehen und verstehe, dass es nicht gerade angenehm ist.
Bezüglich des Cloudflare DNS, müsst Ihr euch bitte an Cloudflare direkt wenden. Wir haben leider keinen Einfluss auf das Routing von Cloudflare.
Weitere Informationen zu Cloudflare liegen nicht vor.

Gruß
Timur K.

[#15]

@Timur K. 

Hallo Timur!

Anscheinend ging da etwas Information auf dem Weg verloren: Die Verbindung zu CloudFlare ist wunderbar. Es geht darum, dass der CloudFlare DNS (evtl. zufällig, evtl. wegen fehlenden Ortsinformationen) zu etwas anderen Amazon-IPs auflöst. Die Server sind relativ sicher sehr ähnliche, da die Pingzeiten sich nur minimal unterscheiden. Was jedoch anders ist, ist dass die IPs zu anderen Subnetzen gehören welche wiederrum von der Telekom anders geroutet werden.

Im letzten Punkt steckt hierbei das Problem. Das Routing hierbei läuft zufällig über Netze in denen das Peering Probleme zu machen scheint. Aus diesem Grund ist auch das einfache ändern des DNS keine dauerhafte Lösung, da das zugrundeliegende Problem weiterhin besteht.

[#16]

@tschwend

Vielen Dank für dein Feedback. Ich kann dich verstehen. Das ist die Rückmeldung von der Fachabteilung.
Wir haben da leider keinen Einfluss auf das CloudFlare DNS. Daher bitte direkt an CloudFlare wenden, damit die das prüfen können.

Gruß
Timur K.

[#17]

@Timur K. 

Sorry, dass ich so lange geschwiegen habe, aber mit einer nun funktionierenden Leitung (danke nochmals an @home35 @tschwend für eure Hilfe) kann ich meine Arbeit nachholen.

Ich wollte meine Vorredner nochmals unterstützen und nochmal auf das Problem deutlich zeigen und zwar:

- Nutzung des CF DNS Servers - Verantwortung: Der Endnutzer

- Einträge des CF DNS Servers - Verantwortung: CF _und_ die Zulieferer der DATEN (könnte Telekom sein, muss aber nicht).

- Das ROUTING der gemeldet IPs vom CF/TELEKOM/GOOGLE DNS Server -  DEFINITIVE die NETZBETREIBER.

D.h. auch wenn der CF DNS Server nicht in der Verantwortung der Telekom liegt, so liegt dennoch das Routing in der Verantwortung der Netzbetreiber, also der Telekom.

Ein Beispiel:

Telekom DNS Server meldet von www.beispieldomain.de die IP 1.2.3.4

CF DNS Server meldet von www.beispieldomain.de die IP 4.3.2.1

Egal welche IP, der Internetnutzer (so einer wie ich) muss von seinem Hausanschluss, bis zu einer der IPs geführt werden. DIESE FÜHRUNG macht der Netzbetreiber, aka. Routing/Peering und das ist die TELEKOM.

Beispiel:

Hausanschluss -> Telekom-Verteiler -> sieht eine GUTE ROUTE zu IP 1.2.3.4 = Alles super!

Hausanschluss -> Telekom-Verteiler -> sieht eine ROUTE zu 4.3.2.1, die ist aber stark ausgelastet, schlecht nutzbar, etc. = der User schreit im Telekom Forum nach Hilfe!

Die Aufgabe der Telekom wäre es daher nun herauszufinden:

Warum ist der Weg (Routing) zu 1.2.3.4 besser als der Weg (Routing) zu 4.3.2.1

Wenn die Telekom das nicht kümmert, denn sie könnte behaupten "tja, nutze halt bitte unseren und keinen anderen DNS", dann wäre das in meinen Augen ein DNS Zwang (wir steigern uns vom Routerzwang zum DNS-Zwang) und das heißt wiederum, die Telekom kann uns Zugriffe (wenn sie wollte) auf diverse Seiten erschweren/ganz verhindern (siehe China).

My 5 cents, ich hoffe die Erklärung hilft für das Verständnis.

Cheers und Frohe Ostern!

[#18]

@sttwebs

Vielen Dank für dein Feedback. Ich kann deinen Unmut verstehen. Ich kann mich da aber nur wiederholen. Wir sind nicht alleine bei dem Peering verantwortlich. Es sind immer mehrere Parteien im Boot, die sich daran halten müssen. Wir haben auf unserer Seite geprüft. Auf das Routing bzw. auf welchen Weg es an uns zurückgegeben wird, haben wir keinen Einfluss drauf. Daher hier bitte noch mal an CF wenden, damit diese das prüfen können.

Gruß
Timur K.

[#19]

@Timur K. 

Verstanden.

Mit der nun aktuellen Aussage - gibt es zumindest ein offizielles Statement?

Die letzten Aussagen zusammengefasst waren:

- Es gibt keine Probleme

- Es gibt Probleme beim Peering mit Amazon

- Wenn es Probleme mit CF gibt, bitte an CF direkt gehen

Wie gesagt, die User @tschwend @home35 hier im Forum verdienen mindestens einen Monat Gratiszugang -  die haben einen tollen Job mit der Problemanalyse geleistet, was ich vom Telekom Support leider nicht behaupten kann.

Ich fühle mich zwar freundlich behandelt (dafür danke ich auch), aber "geholfen" fühlte ich mich nicht wirklich. Ich will jetzt auch keinen unnötigen Streit vom Zaun brechen, ich möchte nur meine Erwartung für die Zukunft richtig ausrichten in Bezug auf solche Probleme.

Und damit erstmal... FROHE OSTERN!