Vor wenigen Stunden hatte ich hier im Blog ja eine Beobachtung gezeigt, dass bestimmte DSL-Verbindungen momentan nur zu sehr geringen Download-Raten von Microsoft-Updates führen. Aber die Saga geht noch weiter – ein Leser berichtete von gravierenden WSUS-Fehlern bei der Einrichtung. Mein spontaner Hinweis auf den oben erwähnten Blog-Beitrag ergab, dass die DSL-Verbindungsprobleme auch für WSUS-Installationsfehler verantwortlich sind.
Anzeige
Leserbeobachtung: WSUS lässt sich nicht konfigurieren
Blog-Leser Lutz S. hatte sich zum 10. Dezember 2024 (Patchday) am späten Abend per E-Mail gemeldet. Er wollte an diesem Tag testweise einen neuen Server unter Windows Server 2025 für sein privates Lab installieren. Das habe auch alles soweit geklappt, schrieb der Leser, und erwähnte, dass "das Thema mit der Erkennung der korrekten Netzwerkeinstellung nach Promotion eines Servers zum DC ja seit 2019 bekannt" sei. Auch wenn die bisherigen Registry-Einträge nicht mehr greifen, ein Einzeiler via PowerShell in der Aufgabenplanung helfe zum Neustart der NIC, schrieb Lutz.
Aber dann fingen die Probleme an. Lutz wollte auf dem Windows Server 2025 dann auch die WSUS-Rolle installieren. Hier trat plötzlich ein Problem auf, zu dem der Leser auch im Internet keine Lösung finden konnte.
Der Ersteinrichtung des WSUS bricht urplötzlich mit obiger Fehlermeldung, in dem Einrichtungsschritt, in dem das erste mal eine Verbindung zu den Microsoft-Servern gestartet wird, ab. Ein Proxy war beim Leser nicht im Einsatz, so dass dies also auszuschließen war. Der Leser beobachtete auch, dass weitere Syncs ebenso nach wenigen Minuten mit dem gleichen Fehler abbrechen.
Anzeige
Da der Leser angenommen hatte, dass dieser Fehler aktuell am Server 2025 liegt, hat er auf der gleichen Maschine einfach mal "fix" Windows Server 2022 aufgesetzt. Unter diesem Betriebssystem funktioniert der WSUS aktuell auf dem produktiven Server des Lesers einwandfrei.
Aber auch hier schlug der Ansatz fehl, es kam wieder zu obiger Fehlermeldung. Der Leser hat noch versucht, auf dem aktuellen, produktiven Server eine VM, nur mit der WSUS-Rolle, zu erstellen. Es ergab sich das gleiche Bild.
Der Leser hat sich das Log-File, welches vom WSUS erstellt wird, im Ordner SoftwareDistribution angeschaut. Er interpretierte dies dahingehend, dass Microsoft temporär irgendwelche Probleme habe, und fragte, ob mir was bekannt sei.
Mein Verweis auf die Download-Probleme hilft
Ich verwies den Blog-Leser auf meinen frischen Beitrag Microsoft Dez. 2024-Patchday: Langsame Downlods/Webseiten; wer/was ist schuld?, wo ich eine Beobachtung beim Download von Updates thematisiert hatte. Leserhinweise klagten über langsame Downloads von Microsoft Updates zum Dezember 2024-Patchday.
Rückmeldung des Lesers war, dass es tatsächlich mit dem DNS-Thema des obigen Blog- Beitrags zusammenhing. Der Leser hatte den Google-DNS-Server konfiguriert. Nach Änderung auf einen Telekom-DNS lief der Sync problemlos.
Anzeige
Was ist eine langsame DSL-Verbindung? Klassisch 1 bis 2 Mbit/s? Ist doch heutzutage alles vectoring mit 50 bis 250 Mbit/s.
DSL 16 ist auch noch oft anzutreffen, als wenignutzer/oma/opa Tarif völlig ausreichend z.B. bei 1&1 oä.
Ich glaube, der Vorposter ist dem Irrtum aufgesessen, dass ich mit "langsame DSL-Verbindungen" den gebuchten DSL-Tarif gemeint haben könnte (oder er wollte die Überschrift "aufspießen" und bewusst missverstehen). Ersteres geht aber aus dem Text hervor, dass es die ganz konkret zur Zeit über bestimmte DNS-Resolver feststellbaren Geschwindigkeitseinbrüche beim Zugriff auf bestimmte Microsoft-Dienste sind, die das Problem ausmachen. Selbst ein alter 1MBit DSL-Anschluss könnte 900 kB liefern – wenn es aber mit 10-20 kBit tröpfelt oder auf 0 sinkt, wird es schwierig.
Hat das denn bisher keiner der Betroffenen mal untersucht, welche IPs die unterschiedlichen Resolver für die entsprechenden Dienste zurückliefern und wie die Routen aussehen (ping / nslookup / tracert)?
Dann wird wohl wie auch am Betragsende beschrieben der falsche DNS und die darüber dann falschen zu entfernt liegenden Server verwendet.
Was hat schlechtes Peering am CIX mit Bandbreite zu tun?
Ich lade Sie gerne nach OWL in den Kreis Minden Lübbecke ein um Ihre generelle Aussage mal praktisch zu überprüfen. ;-)
Nur mal so ein Gedanke:
Vor einiger Zeit gabs da doch mal die Nachricht, dass die Telekom diverse Peering-Verbindungen eingestellt hat. Könnte es sein, dass damit die Verbindung zum Google-DNS geschwindigkeitsmäßig in die Knie gegangen ist bzw. am aktuellen Peering-Point wegen Überlast Packet Losses auftreten? Und deshalb DNS-Auflösungen ins Timeout rennen?
Weil wenn der entscheidende Unterschied der DNS-Server ist, kann es nur sowas sein, der Telekom-eigene DNS im eigenen Netz ist natürlich schnell (und ich setze jetzt einfach mal voraus, die lösen auf die gleichen IP-Adressen auf).
Ich habe leider gerade keinen Telekom-Anschluss zum selbsttesten verfügbar, vielleicht kann da ja mal ein Telekom-Nutzer nen Traceroute machen.
Gruß,
Werner
Es scheint momentan massive Probleme zu geben, wenn ich es nicht falsch sehe. Ich hänge über 1&1 ja auf Telekom-Infrastruktur. Hier mal einige tracert-Ausgaben.
tracert borncity.comRoutenverfolgung zu borncity.com [85.13.131.150]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 9 ms 8 ms 8 ms 192.0.0.1
3 8 ms 8 ms 8 ms 62.72.71.113
4 10 ms 8 ms 8 ms fra020isp005.versatel.de [80.81.193.80]
5 21 ms 23 ms 20 ms 80.81.192.39
6 24 ms 22 ms 22 ms dd54036.kasserver.com [85.13.131.150]
Ablaufverfolgung beendet.
Hier ein traceroute zur telekom.de:
tracert telekom.deRoutenverfolgung zu telekom.de [80.158.67.40]
über maximal 30 Hops:
1 1 ms <1 ms 1 ms fritz.box [192.168.178.1]
2 10 ms 13 ms 8 ms 192.0.0.1
3 9 ms 8 ms 8 ms 62.72.71.113
4 10 ms 9 ms 8 ms 62.67.18.94
5 10 ms 9 ms 9 ms ffm-b11-link.ip.twelve99.net [213.155.129.188]
6 11 ms 9 ms 9 ms dtag-ic-387601.ip.twelve99-cust.net [62.115.172.65]
7 11 ms 10 ms 10 ms f-ea17-i.F.DE.NET.DTAG.DE [217.0.195.38]
8 * * * Zeitüberschreitung der Anforderung.
9 * * * Zeitüberschreitung der Anforderung.
10 * * * Zeitüberschreitung der Anforderung.
11 * * * Zeitüberschreitung der Anforderung.
12 * * * Zeitüberschreitung der Anforderung.
13 * * * Zeitüberschreitung der Anforderung.
14 * * * Zeitüberschreitung der Anforderung.
15 * * * Zeitüberschreitung der Anforderung.
16 * * * Zeitüberschreitung der Anforderung.
17 * * * Zeitüberschreitung der Anforderung.
18 * *
Und noch ein tracerout zu microsoft.com
tracert microsoft.comRoutenverfolgung zu microsoft.com [2603:1030:20e:3::23c]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms fritz.box [2001:16b8:b701:d600:e228:6dff:fe73:7688]
2 10 ms 8 ms 8 ms 2001:1438::94:134:198:47
3 33 ms 29 ms 19 ms 2001:1438::62:214:42:131
4 26 ms 17 ms 8 ms 2a01:111:2000:1::3d8d
5 9 ms 9 ms 9 ms 2a01:111:2000:1::3d8e
6 14 ms 8 ms 9 ms 2a01:111:2000:2:8000::1591
7 99 ms * * ae123-0.icr02.ams21.ntwk.msn.net [2603:1060:1:12::f231]
8 * 98 ms * 2603:1060:1:10::f5ca
9 * * 100 ms 2603:1060:1:10::f7c6
10 98 ms * 99 ms 2603:1060:1:10::f051
11 * * 98 ms 2603:1060:1:10::f5dd
12 * 98 ms * be4.ibr01.ewr30.ntwk.msn.net [2603:1060:0:10::f1a9]
13 * * 99 ms 2603:1060:0:10::f3b6
14 250 ms 98 ms 98 ms be4.ibr03.bl20.ntwk.msn.net [2603:1060:0:10::f195]
15 * * * Zeitüberschreitung der Anforderung.
16 * * * Zeitüberschreitung der Anforderung.
17 98 ms 97 ms 97 ms 2603:10b0:312:81c0::96
18 99 ms 99 ms 98 ms 2603:10b0:312:8302::1e6
19 98 ms 97 ms 98 ms 2603:10b0:317:173::
20 98 ms 97 ms 97 ms 2603:10b0:317:173::16
21 98 ms 97 ms 97 ms 2603:1030:20e:3::23c
Ablaufverfolgung beendet.
Alles extrem zäh und mit Timeouts behaftet.
Welcher DNS wird verwendet? Standardwerte von 1&1 in der fritzbox vorkonfiguriert?
Ja
Jupp,
das sieht nicht gut aus im letzten Trace – der Link zu MSN (Hop 7) klemmt bösartig. Da wird aber eher dann nicht das DNS das Problem sein, sondern der WSUS mit seinen Verbindungen zu MS ins Timeout laufen.
Ich denke, da sollte die Telekom-Nutzer mal nen Ansturm auf die Telekom-Hotline veranstalten, schließlich zahlen sie ja ihre Anschlussgebühren für eine Verbindung ins gesamte Internet. Anders wird man dem nicht beikommen, fürchte ich.
Gruß,
Werner
Hmm…
Mit eingestelltem DNS-Resolver 1.1.1.2 (Cloudflare) an der (stabil überversorgten) T-DSL50-Leitung aus fast schon "Süd-Skandinavien" (in D "ganz oben" 😉):
Routenverfolgung zu borncity.com [85.13.131.150] über maximal 30 Abschnitte:1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 5 ms 4 ms 4 ms p3e9bf15e.dip0.t-ipconnect.de [62.155.241.94]
3 16 ms 16 ms 16 ms l-ea5-i.L.DE.NET.DTAG.DE [217.5.65.218]
4 22 ms 17 ms 18 ms 62.157.251.90
5 18 ms 17 ms 16 ms dd54036.kasserver.com [85.13.131.150]
Ablaufverfolgung beendet.
Routenverfolgung zu telekom.de [80.158.67.40] über maximal 30 Abschnitte:1 1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 7 ms 6 ms 4 ms p3e9bf15e.dip0.t-ipconnect.de [62.155.241.94]
3 9 ms 9 ms 9 ms hh-ea13-i.HH.DE.NET.DTAG.DE [217.5.74.110]
4 * * * Zeitüberschreitung der Anforderung.
. . .
30 * * * Zeitüberschreitung der Anforderung.
Ablaufverfolgung beendet.
Routenverfolgung zu microsoft.com [2603:1010:3:3::5b] über maximal 30 Abschnitte:1 1 ms <1 ms <1 ms fritz.box [2003:da:9738:f100:e228:6dff:fe6e:1ca3
]
2 5 ms 4 ms 5 ms 2003:0:8402:d800::1
3 * * * Zeitüberschreitung der Anforderung.
4 14 ms 12 ms 12 ms 2a01:111:2000:1::3b52
5 13 ms 12 ms 12 ms ae22-0.icr02.ber20.ntwk.msn.net [2a01:111:2000:2
:8000::a9e]
6 284 ms 284 ms 284 ms be102.ibr01.ber20.ntwk.msn.net [2603:1060:1:12::
f27e]
7 286 ms 285 ms 285 ms 2603:1060:1:10::f459
8 285 ms 284 ms 284 ms 2603:1060:1:10::f336
9 285 ms 297 ms 283 ms be3.ibr01.mrs20.ntwk.msn.net [2603:1060:1:10::f0
39]
10 286 ms * * 2603:1060:1:10::f58e
11 286 ms 285 ms * po12.yto20-0100-0001-01sw.ntwk.msn.net [2a01:111
:201:f200::8da]
12 282 ms 281 ms 282 ms 2603:1060:1:10::f7b9
13 * * * Zeitüberschreitung der Anforderung.
14 * 281 ms * be2.ibr02.ham30.ntwk.msn.net [2603:1060:1:10::f2
01]
15 * 286 ms * be14.ibr01.sg2.ntwk.msn.net [2603:1060:1:10::f11
1]
16 289 ms 285 ms 285 ms be1.ibr01.sg3.ntwk.msn.net [2603:1060:2:10::f041
]
17 * * 298 ms 2603:1060:2:10::f57e
18 282 ms 281 ms 281 ms 2a01:111:201:f200::805
19 280 ms 279 ms 281 ms 2a01:111:2000:6::4df5
20 286 ms 285 ms 285 ms 2603:10c0:2:b100::b6
21 282 ms 282 ms 282 ms 2603:10c0:2:b306::156
22 281 ms 282 ms 282 ms 2603:10c0:13:3df::
23 285 ms 285 ms 284 ms 2603:10c0:13:535::
24 287 ms 284 ms 283 ms 2603:1010:3:3::5b
Ablaufverfolgung beendet.
Bei mir läuft die Routenverfolgung zur T-kom schon viel früher in den Timeout als bei @Günter und zu M$ ist's halt 'ne andere IP, die aufgelöst wird.
Aber die Zeiten sind echt übel – so schlimm hatt' ich's auch noch nie. 🤷♂️
Kann der DNS was damit zu tun haben?
Timeouts sind ja im Traceroute nicht schlimm, weil der Betreiber der jeweiligen Hops auch in der Lage ist zu sagen, dass das Gerät nicht auf derartige Anfragen antworten soll. Das sagt letztlich nix aus.
Wenn du aber zu microsoft.com 280ms hast und zu deinem Blog nur 18ms, dann ist das eher ein Indikator massiver Überlastung oder des komplett falschen Routingweges. 280ms sind in etwa die Strecke Deutschland HongKong. Also nur zur Einordnung, welche Wege das Datenpaket da scheinbar geht. Hin und wieder kann man das beim traceroute an den Namen der Hops ablesen.
Was natürlich auch sein kann – IPv6 und IPv4 sind wie gesagt unterschiedlich im Routing. Das was für v4 gilt muss für v6 nicht auch gelten und umgekehrt. Kann also sein du erreichst eine Domain die Dual Stack "fährt" über v6 bescheiden und v4 gut und umgekehrt kann das ebenso sein.
Hier ist es noch schlimmer:
tracert microsoft.com
Routenverfolgung zu microsoft.com [2603:1030:c02:8::14]
über maximal 30 Hops:
1 5 ms 3 ms 4 ms fritz.box [2003:cb:8f2a:7200:e72:74ff:fec0:3a1f]
2 14 ms 11 ms 10 ms 2003:0:8000:c000::1
3 * * * Zeitüberschreitung der Anforderung.
4 17 ms 14 ms 13 ms 2a01:111:2000:1::3b52
5 14 ms 14 ms 15 ms ae21-0.icr01.ber20.ntwk.msn.net [2a01:111:2000:2:8000::a96]
6 173 ms 172 ms 172 ms be100.ibr01.ber20.ntwk.msn.net [2603:1060:1:12::f27a]
7 169 ms 166 ms 168 ms 2603:1060:1:10::f33d
8 178 ms 202 ms * be12.ibr02.jnb21.ntwk.msn.net [2603:1060:1:10::f2d2]
9 * * * Zeitüberschreitung der Anforderung.
10 * 234 ms 167 ms 2603:1060:1:10::f051
11 173 ms 173 ms * 2603:1060:1:10::f5dd
12 * 178 ms * be4.ibr01.ewr30.ntwk.msn.net [2603:1060:0:10::f1a9]
13 175 ms 224 ms 173 ms 2603:1060:0:10::f1fa
14 170 ms 307 ms 169 ms be6.ibr01.cys04.ntwk.msn.net [2603:1060:0:10::f226]
15 * * 261 ms 2603:1060:0:10::f456
16 * 168 ms * 2603:1060:0:10::f49a
17 174 ms 173 ms 179 ms be5.ibr01.cys04.ntwk.msn.net [2603:1060:0:10::f315]
18 172 ms 170 ms 170 ms be3.ibr03.bn6.ntwk.msn.net [2603:1060:0:10::f09d]
19 209 ms 171 ms 172 ms 2603:1060:0:12::f4b6
20 168 ms 167 ms 168 ms 2603:10b0:d02:8104::a
21 176 ms 175 ms 175 ms 2603:10b0:d02:8002::2a6
22 169 ms 168 ms 169 ms 2603:10b0:d02:8206::1c6
23 172 ms 171 ms 171 ms 2603:10b0:d07:5e3::
24 170 ms 169 ms 169 ms 2603:10b0:d07:5ee::
25 170 ms 169 ms 168 ms 2603:1030:c02:8::14
Ablaufverfolgung beendet.
Hier zu:
tracert borncity.com
Routenverfolgung zu borncity.com [85.13.131.150]
über maximal 30 Hops:
1 3 ms 4 ms 6 ms fritz.box [192.168.178.1]
2 10 ms 20 ms 10 ms p3e9bf017.dip0.t-ipconnect.de [62.155.240.23]
3 16 ms 16 ms 15 ms l-ea5-i.L.DE.NET.DTAG.DE [217.5.65.118]
4 19 ms 18 ms 17 ms 62.157.251.90
5 19 ms 18 ms 19 ms dd54036.kasserver.com [85.13.131.150]
Ablaufverfolgung beendet.
es sei daran erinnert, das groß Provider das IP über ein anderes Protokoll (ILS?) verschicken um nicht jeden kleinen Fipssell wieder und wieder Routen zu müssen.
das ICMP Ping ist sozusagen virtuell. Das fällt man mal auf, wenn das RTT einen konstanten Wert annimmt, egal wie weit der Hopp entfernt ist.
hier sind die 100ms auffällig.
Das macht es für Endkunden noch schwieriger das Netz zu analysieren
Bin auch bei der Telekom 200/40
Maximal kommen seit dem Wochenende 20/10 an.
Hallo,
ich habe als DNS 1.1.1.1 bzw. 1.0.0.1 (cloudflare) eingestellt.
Hier ein Traceroute zu BornCity.com
C:\ > tracert -h 30 borncity.com
Routenverfolgung zu borncity.com [85.13.131.150]
über maximal 30 Hops:
1 1 ms tracert -h 30 telekom.de
Routenverfolgung zu telekom.de [80.158.67.40]
über maximal 30 Hops:
1 1 ms 1 ms 1 ms speedport.ip [192.168.2.1]
2 17 ms 7 ms 5 ms p3e9bf605.dip0.t-ipconnect.de [62.155.246.5]
3 7 ms 7 ms 7 ms f-ea17-i.F.DE.NET.DTAG.DE [217.0.195.38]
4 * * * Zeitüberschreitung der Anforderung.
5 * * * Zeitüberschreitung der Anforderung.
6 * * * Zeitüberschreitung der Anforderung.
7 * * * Zeitüberschreitung der Anforderung.
8 * * * Zeitüberschreitung der Anforderung.
9 * * * Zeitüberschreitung der Anforderung.
10 * * * Zeitüberschreitung der Anforderung.
11 * * * Zeitüberschreitung der Anforderung.
12 * * * Zeitüberschreitung der Anforderung.
13 * * * Zeitüberschreitung der Anforderung.
14 * * * Zeitüberschreitung der Anforderung.
15 * * * Zeitüberschreitung der Anforderung.
16 * * * Zeitüberschreitung der Anforderung.
17 * * * Zeitüberschreitung der Anforderung.
18 * * * Zeitüberschreitung der Anforderung.
19 * * * Zeitüberschreitung der Anforderung.
20 * * * Zeitüberschreitung der Anforderung.
21 * * * Zeitüberschreitung der Anforderung.
22 * * * Zeitüberschreitung der Anforderung.
23 * * * Zeitüberschreitung der Anforderung.
24 * * * Zeitüberschreitung der Anforderung.
25 * * * Zeitüberschreitung der Anforderung.
26 * * * Zeitüberschreitung der Anforderung.
27 * * * Zeitüberschreitung der Anforderung.
28 * * * Zeitüberschreitung der Anforderung.
29 * * * Zeitüberschreitung der Anforderung.
30 * * * Zeitüberschreitung der Anforderung.
Ablaufverfolgung beendet.
Hier mein Traceroute zu Microsoft.com:
1 1 ms 1 ms 1 ms p200300c07f2ba13006a222fffe13e55a.dip0.t-ipconnect.de [2003:c0:7f2b:a130:6a2:22ff:fe13:e55a]
2 7 ms 5 ms 6 ms 2003:0:8300:2800::1
3 * * * Zeitüberschreitung der Anforderung.
4 6 ms 6 ms 5 ms 2a01:111:2000:1::365a
5 7 ms 6 ms 7 ms ae22-0.icr01.fra23.ntwk.msn.net [2a01:111:2000:2:8000::1609]
6 * * 96 ms ae103-0.icr02.ams21.ntwk.msn.net [2603:1060:1:12::f221]
7 * * 101 ms 2603:1060:1:10::f5ca
8 * 104 ms * 2603:1060:1:10::f7c6
9 96 ms 147 ms * 2603:1060:1:10::f051
10 * 101 ms * 2603:1060:1:10::f5dd
11 189 ms * * be4.ibr01.ewr30.ntwk.msn.net [2603:1060:0:10::f1a9]
12 * * * Zeitüberschreitung der Anforderung.
13 112 ms * * 2603:1060:0:10::f349
14 * * * Zeitüberschreitung der Anforderung.
15 * 95 ms 95 ms 2a01:111:2000:6::4761
16 95 ms 95 ms 95 ms 2603:10b0:312:81c0::a2
17 102 ms 101 ms 101 ms 2603:10b0:312:8204::50e
18 101 ms 101 ms 105 ms 2603:10b0:327:9fd::
19 95 ms 96 ms 95 ms 2603:10b0:327:b91::
20 95 ms 96 ms 95 ms 2603:1030:20e:3::23c
Ablaufverfolgung beendet.
Die telekom.de Webseite ist ja abrufbar, von daher düften die * eher was darüber aussagen, dass es die Telekom nicht so gerne sieht, wenn man ihr Netz per Tracert sondiert.
Ich nehme auch massive Probleme beim Download seit ca. 2-3 Wochen an Telekom-Anschlüssen wahr. Es handelt sich meist um Updates. Sei es GDATA (dazu gab es einen Heise Artikel), gestern Adobe Reader, etc.
Router Reboot ohne Erfolg, DNS wird der von der Telekom genutzt.
Problem tritt aber nur phasenweise auf. Bevorzugt am Abend.
Download von anderen Quellen wie z.B. libreoffice gehen aber rasend schnell. Speedtest auch unauffällig.
Nachtrag:
Mir ist noch folgendes aufgefallen:
Günters Trace zu Telekom.de
1 1 ms <1 ms 1 ms fritz.box [192.168.178.1]
2 10 ms 13 ms 8 ms 192.0.0.1
3 9 ms 8 ms 8 ms 62.72.71.113
4 10 ms 9 ms 8 ms 62.67.18.94
5 10 ms 9 ms 9 ms ffm-b11-link.ip.twelve99.net [213.155.129.188]
6 11 ms 9 ms 9 ms dtag-ic-387601.ip.twelve99-cust.net [62.115.172.65]
7 11 ms 10 ms 10 ms f-ea17-i.F.DE.NET.DTAG.DE [217.0.195.38]
Danach Ping-Sperre
und der Trace von untendrunter:
1 1 ms 1 ms 1 ms speedport.ip [192.168.2.1]
2 17 ms 7 ms 5 ms p3e9bf605.dip0.t-ipconnect.de [62.155.246.5]
3 7 ms 7 ms 7 ms f-ea17-i.F.DE.NET.DTAG.DE [217.0.195.38]
Danach Ping-Sperre
Nach Aussage sind beides Telekom-Nutzer. Beide landen bei f-ea17-i.F.DE.NET.DTAG.DE . Aber Günters Trace geht durch ein Fremdnetz: u.a. ffm-b11-link.ip.twelve99.net .
Was ist das für ein Routing? Kann die Telekom den Weg zu telekom.de nicht in ihrem eigenen Netz abbilden? Wenn so ein Routing 'außenrum' öfters passiert, ist es kein Wunder, wenn die Peerings überlastet sind, weil der Planer ziemlich sicher die Belastung durch 'außenrum'-Routing nicht eingeplant hat.
Gruß,
Werner
Ähm…
@Günter hat doch geschrieben, er hängt an 'nem 1&1-Anschluß – ich vermute da mal die (aufgekaufte) alte Versatel-Infrastruktur vor der T-kom-Anbindung.
Kann das sein?
– EDIT –
Ok, "Twelve99" schmeißt Tante G* mit "Arelion" (ehem. Telia Carrier bzw. TSIC), SWE raus.
> Was ist das für ein Routing?
Eins, das auf dem Prinzip der größten Ausfallsicherheit gedacht ist.
> Kann die Telekom den Weg zu telekom.de nicht in ihrem eigenen Netz abbilden?
Doch, kann sie, würde damit aber den Gedanken der Ausfallsicherheit durch einen Single Point of Failure ad Absurdum führen.
Dem kann ich jetzt so nicht folgen.
Wenn das Telekom-Netz ausfällt, dann ist telekom.de in diesem Netz eh nicht erreichbar. Wie erreicht man durch 'außenrum' Routing mehr Redundanz? Kann man im Fehlerfalle machen, wenn im eigenen Netz Teile ausgefallen sind, aber der Normalfall sollte das nicht sein, insbesondere wenn man wie die Telekomiker die Peeringpoints künstlich ausdünnt.
Ich hänge an einem 250/50 MBit/s Telekom Glasfaseranschluss mit Provider-DNS und der Download eines Windows Updates war eben auch sehr träge.
Kannst du dort nicht mal bei der Telekom anklopfen und fragen ob und was da los ist? Die Meldungen häufen sich ja hier doch. Auch ich stelle an meinem Telekom Anschluss Zuhause seit geraumer Zeit fest, dass die Dinge länger dauern.
Ich mache es anders und frage bei der 1&1 Pressebetreuung nach – muss mal schauen, ob ich die Telekom-Pressebetreuung mit ins Boot bekomme.
Mail ist gerade raus.
ich habe seit einiger Zeit massive Probleme ab Nachmittag bis 23 Uhr YouTube zu sehen.
Es hängt immer wieder.
Manche Shorts kommen gar nicht, oder in 5 Sekunden Stücken das nächste flutscht.
Die streams von ARD ZDF kommen problemlos.
Ich weiß nicht, wie ich das Messen sollte. Der Bandbreiten Test von RegTP sagt, das die Bandbreite da wäre.
Professionelle Antwort der 1 &1 Hotline: sie haben 56 Mbps auf ihrem Anschluss, das mit YouTube ist ein externes Problem, da können wir nichts ändern.
(Sie können uns auch nicht kündigen da wir nicht schuld an Netzengpässen sind)
ich glaube, da muss langsam Mal die Bundesnetzagentur eingreifen.
die Telekom scheint ihre Macht Position im Netz missbrauchen zu wollen.
Wiederverkäufer wie 1&1 gucken in die Röhre.
leider müssen Provider nicht offen legen mit wem sie peerrn oder nicht. es kann sich außerdem ändern. Der Endkunde ist der Verlierer.
RegTP wo bist Du?
Ich kann massive Probleme mit den Adobe Diensten bei unserem Telekom Firmen-Anschluß bestätigen. Gestern hat es 6 Stunden! gedauert, um die App "Creative Cloud" auf den aktuellen Stand zu bringen. Heute habe ich versucht die Anwendungen zu aktualisieren, aber da geht gar nichts. Photoshop von heute morgen bis jetzt 15%. Bei meinem Glasfaseranschluss (DG) konnte ich sämtliche Apps in unter einer Stunde updaten. Das ist jetzt auch nicht super schnell, aber funktioniert zumindest.
Auch ich bemerke an meinem Telekom-Anschluss (VDSL 100/40) seit einigen Wochen deutlich feststellbare Performance-Probleme / Performance-Unterschiede, je nachdem welche Ziele angesteuert werden:
Manche Webseiten laden ausgesprochen zäh oder gelegentlich auch gar nicht bzw. nach erst einem Refresh- außerhalb von irgendwelchen Stoßzeiten, wohlgemerkt. Das ganze erscheint wenig deterministisch.
U.a. betreibe ich über den Anschluss auch einen VPN-Tunnel via IPv4 zu einem FTTH-Anschluss der Deutschen Glasfaser, i.d.R habe ich durch den Tunnel tagsüber den nahezu maximalen Durchsatz von 95/38 erreicht während abends ab und an mal Performance-Probleme aufgetreten sind (speziell in den Wintermonaten) und der Durchsatz da schon mal auf 25% eingebrochen und die Latenz auf über 100ms RTT angestiegen ist (normal waren immer um die 20ms) und auch Packetloss von 10-15% feststellbar war.
Mittlerweile liegt der Durchsatz auch tagsüber meist bei *deutlich* unter 10 MBit/s – die Latenz bleibt interessanterweise recht konstant bei ca. 25ms ohne nennenswerten Packetloss.
Dass die Latenz gleich bleibt während der Durchsatz sinkt ist vollkommen atypisch für eine "normale" Überlastsituation und spricht mMn stark für die Nutzung von QoS-Mechanismen, also eine unterschiedliche Behandlung in Abhängigkeit des Payloads wo natürlich auch potenziell eine künstliche Einbremsung möglich ist.
Ändert man auf der Telekom-Seite die IP-Adresse (Re-Connect) verändert sich die Situation manchmal zum Positiven, zumindest für eine gewisse Zeit.
Die Sachlage lässt sich auch z.B. via speedtest.net nachvollziehen wenn man entsprechende Ziel-Server auswählt (z.B. vom Telekom-Anschluss zum Ziel-Server Deutsche Glasfaser Düsseldorf oder Frankfurt oder umgekehrt).
Die Verbindung Deutsche Glasfaser Telekom läuft via Zayo (ehem. AboveNet), welcher ebenfalls Tier-1 ist und somit potenziell die gleiche Problematik vorliegen könnte wie hinlänglich Bekannte zwischen der Telekom & Cogent…
M.E.n. liegt hier auch die Vermutung nahe, dass die Telekom versucht dieses Spiel mit allen Tier-1-Providern (Arelion, Lumen, GTT, …) zu treiben und da der Internet-Traffic speziell im Q3 eines Jahres stark ansteigt (Dunkle Jahreszeit, Urlaub, Streaming- & Gaming-Dienste, Online-Shopping, usw.) machen sich dort derartige Probleme auch stärker bemerkbar.
Letztendlich versucht die Telekom ihre aufgrund der Endkundenzahl in Europa vorhandene Marktmacht "bösartig" (und ggf. unter Verwendung von unlauteren Mitteln) auszunutzen um ihre Marktmacht weiter auszubauen – und kommt damit durch weil es keinerlei Regulierung gibt (die müsste ja global sein…) und es so gut wie unmöglich ist hier irgendwelchen unlauteren oder wettbewerbsverzerrenden Mittel nachzuweisen.
Auch haben Endkunden hier auch kaum eine vertragliche Grundlage für irgendwelche Forderungen, selbst wenn sie mit ihren Mitteln verwertbare Nachweise erbringen würden.
Die Endkunden sind in diesem Fall quasi die Geiseln…
Und zur sicherlich aufkommenden Frage warum "Provider X" sich nicht einfach direkt mit der Telekom zusammenschaltet (was die Probleme zweifelsohne lösen würde…):
Die Telekom verlangt für eine Zusammenschaltung Preise die teilweise 3x bis 5x höher liegen als das was marktüblich ist bzw. andere Provider verlangen. Es gibt meines Wissens nach weltweit kaum einen Provider der mehr Geld für Zusammenschaltungen verlangt als die Telekom.
Dieses Geschäftsgebaren wird dann indirekt auch noch teilweise durch die EU gedeckt die politisch ein Gegengewicht zu den US-Telcos haben möchte und da ist die Telekom ein nicht gerade kleines Pferd im überschaubaren Stall.
ein so hoher Paket los ist nicht zulässig.
schon im Eigeninteresse sollte ein seriöser Provider das vermeiden, denn die verlorenen Paket werden ja in der Regel wiederholt, was noch mehr Bandbreite kostet.
Zum Thema WSUS – meine letzten Versuche einen WSUS auf 2022 und 2025 Server out of the Box mit aktuellen Images bereit zu stellen benötigten immer erst ein bisschen Brechstange. Bspw. war bei allen Versuchen immer:
https://www.ajtek.ca/wsus/wsus-post-deployment-configuration-failed-windows-server-2022/
durchzuführen.
Und in der Tat, das stimmt exakt so wie dort beschrieben, der falsche Wert steht da drin und muss manuell geändert werden. Warum Microsoft auch immer das nicht gefixt bekommt über Monate.
Nichts desto trotz muss zumindest dieser Fehler erst im Laufe der Zeit rein gekommen sein, weil frühere Installationen (2012R2, 2019 bei mir) von vor Jahren liefen einfach durch.
Die Fehlermeldung der Log Datei zur Folge ist das Problem eher Datenbank related. Also hat nichts mit der INet Verbindung oder DNS zu tun.
Leider muss man sich hier in so einem Troubleshootingfall massiv selbst zwingen die Schritte zu Protokolieren die man durchführt, sonst ändert man sonstwas uns verursacht andere Verhaltensweise die letztlich zwar vielleicht zum Ziel führen, aber in der nachträglichen Aufzählung nicht das Problem waren. Ich kann mir beim besten willen nicht vorstellen, dass DNS hier zu einem Fehler führt.
Was btw. Faktisch bekannt ist – der Initiale Sync von WSUS kann erstens ewig dauern und zweitens mehrfach notwendig sein. Vor allem kommt es noch auf die Settings an. Treiber zu syncen ist bspw. nicht gut, weil das x-tausend Einträge sind, was dazu führt, dass das nicht durchlaufen wird. Fehler bzw. Abbrüche sind nicht selten aber auch so existent. Bei JEDEM neuen Start des Syncs wird immer wieder ein weiteres Stück vom Kuchen abgearbeitet bis das letztlich dann mal vollständig ist.
Wenn das also letztlich irgendwann einfach geht muss überhaupt eine Änderung irgend einer Einstellung zur Fehlerbehebung beigetragen haben, sondern es kann auch einfach nur sein, dass letztlich alle Pakete übermittelt wurden die es zu übermitteln gilt.
Hallo P.B.,
ich bin Derjenige, der das Problem mit dem WSUS unter Server 2025 hatte.
Die "Brechstange" Deines Links musste ich allerdings noch nie einsetzen.
Wie Günter ja in seinem Beitrag auf meine Rückmeldung hin ja geschrieben hatte, lag es einzig und allein am Google-DNS-Server.
Den nutze ich nur als "Fallback", falls die DNS-Server meines lokalen Providers oder der Telekom nicht erreichbar sind.
Im "Eifer des Gefechtes" hatte ich hier einfach zu Testzwecken den 8.8.8.8 eingetragen.
Und, zu Deiner Anmerkung, dass das Feherbild in der Log auf die Datenbank zurückzuführen ist:
Dem war nicht so, ich hab die DB mit SSMS geprüft.
Wie Günter ja in seinem Beitrag ausgeführt hatte, nach Änderung des DNS-Servers lief der Sync problemlos.
ein so hoher Paket los ist nicht zulässig.
schon im Eigeninteresse sollte ein seriöser Provider das vermeiden, denn die verlorenen Paket werden ja in der Regel wiederholt, was noch mehr Bandbreite kostet.
Fragt man in nslookup — egal ob google/cloudflare/quad9-dns — nach
"update.microsoft.com" oder "windowsupdate.microsoft.com"
erhält man als Antwort:
Nicht autorisierende Antwort:
Name: redir.update.msft.com.trafficmanager.net
Address: 20.109.209.108 ODER Address: 20.72.235.82
Eventuell liegt ja dort das Problem, vielleicht ist das "trafficmanagement" kaputt?
Interessant, ich nutze hier am Telekom-Anschluss natürlich einen Telekom-DNS im Router, und nun schaut mal:
C:\>nslookup update.microsoft.com
Server: UnKnown
Address: (streng_geheim)
*** update.microsoft.com wurde von UnKnown nicht gefunden: Query refused.
C:\>nslookup windowsupdate.microsoft.com
Server: UnKnown
Address: (streng_geheim)
*** windowsupdate.microsoft.com wurde von UnKnown nicht gefunden: Query refused.
C:\>nslookup update.microsoft.com 8.8.8.8
Server: dns.google
Address: 8.8.8.8
Nicht autorisierende Antwort:
Name: redir.update.msft.com.trafficmanager.net
Address: 20.72.235.82
Aliases: update.microsoft.com
C:\>nslookup windowsupdate.microsoft.com 8.8.8.8
Server: dns.google
Address: 8.8.8.8
Nicht autorisierende Antwort:
Name: redir.update.msft.com.trafficmanager.net
Address: 20.72.235.82
Aliases: windowsupdate.microsoft.com
Der Telekomiker ist irgendwie der Meinung, er kann das nicht auflösen!?!?
Noch ein Test:
C:\>nslookup windowsupdate.microsoft.com 217.237.150.51
Server: f-lb-b01.isp.t-ipnet.de
Address: 217.237.150.51
Nicht autorisierende Antwort:
Name: redir.update.msft.com.trafficmanager.net
Address: 20.72.235.82
Aliases: windowsupdate.microsoft.com
Usw. Das ist jetzt diffus seltsam. Das ist ein Telekom-DNS den ich in der Webseite meines Routers bei den Verbindungsdaten angezeigt bekomme. Der zweite ist 217.237.148.22, auch wenn ich den direkt anspreche, klappts. Nur wenn ich meinen Telekomrouter dort auflösen lasse, klappts nicht. Dafür hätte ich jetzt aber bitte gerne mal eine Erklärung…
@M.D.
das ist nicht entscheidend, die Updates kommen von "update.windowsupdate.com" wenn man die über Windows Update ziehen lässt. Oder wenn man über den Catalog geht, von anderen URLs.
Letztlich liegt der Kram bei Akamai und je nachdem welchen DNS Server man benutzt bzw. aus welchem Source Netz man dort anfragt, bekommt man den in der DNS Einstellung des Servers hinterlegten "nähesten" Cachingserver zurück. Das kann/muss aber nicht der performanteste sein.
Cloudflares 1.1.1.1 liefert übrigens auch andere Ziel IPs für download.windowsupdate.com zurück als Googles 8.8.8.8.
Adressen, wie update.microsoft.com werden von einem Windows System direkt über die dnsapi.dll aufgelöst. Es kommt zu keiner DNS Anfrage, die manipuliert sein könnte.
siehe zB:
https://petri.com/windows-10-ignoring-hosts-file-specific-name-resolution/
update.microsoft.com gehört dazu
Das ist so nicht korrekt bzw. entspricht nicht dem Verhalten welches sich beobachten lässt:
Für die in der dnsapi.dll aufgelisteten Domains wird lediglich die lokale hosts-Datei ignoriert und die Anfragen werden direkt an die konfigurierten DNS-Server gesendet.
Der Windows-DNS-Client behandelt diese Domains dann auch nicht anderes als jede andere Domain auch und entsprechend können die DNS-Anfragen durch die DNS-Server problemlos "manipuliert" (= umschreiben oder gänzlich blockieren) werden.
Grund für die damalige (= Ende 2004 mit Windows XP SP2) Implementation dieser "Funktion" sind / waren u.a. Viren & Malware welche über die hosts-Datei u.a. den Zugang zu den Microsoft Update- & Supportseiten blockiert haben.
In älteren Windows-Releases konnte man die dnsapi.dll auch einfach per Notepad öffnen und darin die betreffenden Domains im Klartext erkennen…
Danke! ich habe es nie hinterfragt
@Mark Heitbrink, (@P.B.)
Es ging mir gar nicht um etwaige Manipulationen. Es ging mir darum die Möglichkeit aufzuzeigen, dass man für dasselbe Ziel völlig unterschiedliche gültige Ziel-IPs erhält, und dementsprechend auch andere Routen. Und wenn man Pech hat, kann man halt das gerade höher belastete Ziel und/oder stärker belastete Routen erwischen. Und vielleicht werden gerade einige — providerabhängig — doppelt bestraft.
Die benannten SQLFehler treten btw. durch den initialen Sync bzw. während des initialen Sync des WSUS mit Microsoft völlig unabhängig der Internet Geschwindigkeit auf. Ich hab das soeben auf einen frisch installierten 2022 und 2025 System nachgestellt.
Und noch eine Sache, wer Probleme mit dem Wizard hat bricht diesen einfach mit Abbrechen ab und richtet den WSUS "fertig" in der Console ein. Es benötigt diesen Assistenten schlicht nicht. Mal davon ab, dass dieser sogar nachteilig ist, weil er dafür sorgt, dass der initiale Sync Daten in die DB schreibt, die man im Zweifel praktisch gar nicht haben möchte und für die es dann letztlich keine Löschroutinen gibt.
Zum Beispiel übel viele Spracheinträge pro Update Paket jeder erdenklichen Sprache – meist benötigt man ja nur die lokale Sprache und wenn noch ENG.
Best Practice ist eigentlich den Wizard zu beenden und VOR dem ersten Sync die Basis Konfig zu setzen. Also bspw. dass man keine Treiber syncen möchte oder welche Sprache man haben möchte. Dann wählt man möglichst wenig bis nichts aus der Produktauswahl und lässt initial den Sync durchführen um die dem Zeitpunkt vollständige Liste aller Produkte zu bekommen und synct dann noch ein zweites mal wenn man seine Produkte vollständig gewählt hat. Das ist mit Abstand die sinnigste Option um DB Overhead zu verhindern. (Bei WID bspw. sogar teilweise notwendig, weil 10GB Size Limit)
danke für die Insights
Bzgl. WSUS-Installations-Probleme
Ich habe letztens WSUS auf einem 2019 Server neu installieren müssen.
DB dazu auf einem vorhandenen SQL-Server (SQL 2017; war ursprünglich für altes PPS), wegen DB-Größe.
1. Die Installation des WSUS schlug zuerst fehl.
Ursache: In den Installations-Scripten (welches, weiss ich nicht mehr, habe das hier nicht vor mir) wird ein Datei-Pfad zusammengebaut und dort '\' statt '\\' verwendet. Nach Korrektur lief dieser Teil durch.
2. Die Installation der DB schlug ebenfalls fehl. Fehlermeldung in der Art, dass Variable @record* nicht deklariert war.
Ursache: Der SQL-Server war – Anforderung des alten PPS – mit Latin_BIN installiert worden. Damit ist er case-sensitiv. In den SQL-Scripten wurde @Record* deklariert. Verwendet wurde aber sowohl @record* als auch @Record*. Nach Korrektur in einheitlich @Record* lief das durch.
HTH CW
Fast paradiesische Verhältnisse hier:
Der Windows-Update-Client eines Windows 10 Computer verbindet mit ctldl.windowsupdate.com .
> tracert ctldl.windowsupdate.com
Routenverfolgung zu a767.dspw65.akamai.net [193.246.105.59] über maximal 30 Abschnitte:
1 <1 ms <1 ms <1 ms unsere.firma.tld [ge.hei.me.lan-ip]
2 <1 ms <1 ms <1 ms ipp—-r-002-gig0-1-0.ce.ip-plus.net [ge.hei.me.wan-router-ip]
3 <1 ms <1 ms <1 ms i79zhb-041-ten0-2-0-20×10440500.bb.ip-plus.net [217.193.58.85]
4 1 ms <1 ms 1 ms i79zhh-005-ae9.bb.ip-plus.net [138.187.129.24]
5 3 ms 8 ms 8 ms i79zhh-010-ae2.bb.ip-plus.net [138.187.129.45]
6 <1 ms <1 ms <1 ms 193.246.105.59
Auf Grund der Hop-Bezeichnungen kann ich herauslesen, dass der Akamai-Host ca. 15-20km Luftlinie entfernt ist und die ganze Strecke über Glasfaser läuft. Alle Hop liegen im AS des Providers (der Platzhirsch im Land). Für die Namensauflösung betreiben wir eigene DNS-Resolver.
Trotzdem dauerte das herunterladen vom "2024-12 Kumulatives Update für Windows 10 Version 22H2 für x64-basierte Systeme (KB5048652)" gerade eben 2-3 Min.