CDN Probleme erkennen: Traceroute und Anycast verstehen

Red Snapper

1 month ago

CDN Probleme erkennen ist in der Praxis oft schwieriger als klassische „Server down“-Fehleranalyse. Denn bei einem Content Delivery Network (CDN) ist der Zielserver, den ein Nutzer erreicht, nicht zwingend der „eigentliche“ Origin-Server, sondern ein Edge-Standort des CDN – häufig sogar unter derselben IP-Adresse (Anycast). Dadurch können Störungen sehr selektiv wirken: Ein Standort in Deutschland hat plötzlich langsame Downloads, während Nutzer in Frankreich nichts merken. Oder eine Webseite ist im Büro schnell, im Homeoffice langsam. Häufig sind nicht die Anwendung oder der Origin die Ursache, sondern die Auswahl des Edge-Standorts, das Routing des Internetproviders, ein Peering-Problem, ein fehlerhaftes Geo/ASN-Mapping, eine falsch konfigurierte Cache-Policy oder ein fehlerhafter Redirect. Genau hier helfen Netzwerktools wie Traceroute, MTR und ein sauberes Verständnis von Anycast und DNS-basierter CDN-Steuerung. Wer weiß, worauf er achten muss, kann aus wenigen Messungen ableiten, ob das Problem im eigenen Netz, beim ISP, im CDN-Backbone oder am Origin liegt. Dieser Artikel erklärt die wichtigsten Konzepte verständlich, zeigt typische Fehlerbilder und gibt eine praxistaugliche Methode, um CDN-Probleme systematisch zu erkennen und belastbar zu dokumentieren.

CDN-Grundlagen: Was ein CDN tatsächlich macht

Ein CDN verteilt Inhalte (statisch und oft auch dynamisch) auf viele Edge-Standorte weltweit. Ziel ist, Inhalte näher am Nutzer auszuliefern, die Origin-Infrastruktur zu entlasten und Latenz sowie Paketverlust zu reduzieren. Technisch besteht ein CDN typischerweise aus drei Ebenen:

DNS/Traffic Steering: Auswahl eines passenden Edge-Standorts oder PoP (Point of Presence) auf Basis von Geografie, ASN, Last und Policies.
Edge/Cache: Server am Rand, die Inhalte cachen oder Anfragen weiterleiten (Reverse Proxy).
Origin: Ihre eigentliche Infrastruktur (z. B. Webserver, Object Storage, API-Backend), die bei Cache Miss oder für dynamische Inhalte kontaktiert wird.

CDN-Probleme entstehen häufig nicht, weil „das CDN“ kaputt ist, sondern weil die Auswahl des Edges suboptimal ist oder weil der Pfad zwischen Nutzer und Edge (oder Edge und Origin) gestört ist.

Anycast vs. DNS-Loadbalancing: Warum die gleiche IP zu unterschiedlichen Servern führt

Viele CDNs nutzen Anycast für ihre Edge-IP-Adressen. Das bedeutet: Mehrere Standorte announcen dieselbe IP-Adresse über BGP. Der Nutzer erreicht dann den Standort, zu dem sein Netzwerk „den besten“ BGP-Pfad hat – was nicht zwingend geografisch der nächste sein muss.

So funktioniert Anycast vereinfacht

Ein CDN annonciert dieselbe IP aus mehreren PoPs.
Ihr ISP bzw. das Internet-Routing entscheidet anhand von BGP-Pfaden, welcher PoP „gewonnen“ wird.
Ändert sich Peering oder Routing, kann derselbe Nutzer plötzlich in einem anderen PoP landen – ohne dass DNS etwas ändert.

DNS-basiertes Steering (häufig kombiniert)

Viele CDNs kombinieren Anycast mit DNS-Steuerung: DNS liefert je nach Region/Resolver unterschiedliche Namen oder IPs, und Anycast entscheidet innerhalb des CDN-Anycast-Raums zusätzlich über den konkreten PoP. Das führt zu einem wichtigen Troubleshooting-Punkt: Sie müssen immer prüfen, ob der „falsche“ PoP durch DNS-Auswahl, durch Anycast-Routing oder durch beides entsteht.

Typische Symptome von CDN-Problemen

CDN-Störungen wirken oft „komisch“ – genau das ist ein Hinweis. Diese Symptome sind besonders typisch:

Regionale Probleme: Nutzer in einem Land/ISP haben hohe Latenz, andere nicht.
Nur bestimmte Inhalte langsam: z. B. große Dateien oder Bilder, während HTML schnell ist (Cache/Origin-Path).
Intermittierende Peaks: zeitweise Timeouts oder starke Schwankungen (Peering-Flaps, Congestion).
„Mit VPN geht es, ohne VPN nicht“: VPN verändert den egress-ASN und damit Anycast-/Steering-Entscheidungen.
HTTP-Fehler am Edge: 502/503/504 von CDN-Edge (Origin unreachable, Origin overload, Policy).
Falsche Inhalte / veraltete Versionen: Cache Invalidation, TTL, stale content, falsche Cache Keys.

Traceroute richtig nutzen: Was es kann und was nicht

Traceroute ist im CDN-Kontext hilfreich, weil es den Netzwerkpfad (Hops) sichtbar macht und oft Hinweise liefert, in welchem Netz ein Problem entsteht (z. B. ISP-Backbone, Peering-Edge, CDN-AS). Aber: Traceroute ist kein Durchsatztest, und viele Router priorisieren ICMP/TTL-Expired unterschiedlich. Daher müssen Sie Traceroute-Ergebnisse vorsichtig interpretieren.

Worauf Sie bei Traceroute achten sollten

Sprünge in der Latenz: Ein deutlicher Sprung ab einem bestimmten Hop kann Congestion oder Umwege anzeigen.
Hops mit Sternchen (*): Nicht automatisch ein Fehler. Manche Geräte antworten nicht auf TTL-Expired, forwarden aber trotzdem normal.
Letzter erreichter Hop: Wenn der Pfad kurz vor dem Ziel endet, kann das Ziel ICMP blocken oder ein CDN-Edge ICMP nicht beantworten. Das sagt wenig über HTTP/HTTPS aus.
Wechselnde Pfade: Mehrfach messen (mehrere Runs), um ECMP/Load Balancing zu erkennen.

UDP, ICMP oder TCP Traceroute?

ICMP Traceroute: oft am einfachsten, wird aber manchmal gefiltert.
UDP Traceroute: klassisch, kann durch NAT/Firewall anders aussehen.
TCP Traceroute: sehr hilfreich für CDN/HTTPS, weil Sie auf Port 443 „tracen“ können und damit realitätsnäher sind (je nach Tool).

Anycast verstehen: Warum „nächster PoP“ nicht immer „bester PoP“ ist

Anycast folgt BGP-Realitäten. Ein ISP kann besseren Peering-Pfad zu einem PoP in einem Nachbarland haben als zum lokalen PoP. Zusätzlich spielen Traffic Engineering und Kostenmodelle eine Rolle. Das erklärt typische Beobachtungen:

Unerwartete Geografie: Nutzer in Berlin landen in einem PoP in Amsterdam oder London.
ISP-spezifische Unterschiede: Provider A nutzt lokales Peering, Provider B geht über Transit.
Plötzliche Änderungen: Nach Wartungsarbeiten oder Routing-Änderungen verschiebt sich der „beste“ Pfad.

Für Troubleshooting bedeutet das: Wenn Performanceprobleme nur bei bestimmten ISPs auftreten, ist Anycast-Routing ein Hauptverdächtiger. Dann müssen Sie Messungen aus mehreren Netzen vergleichen (z. B. Büro, Mobilfunk, anderer ISP, VPN-Egress).

Messmethodik: CDN-Probleme sauber eingrenzen

Eine robuste Methode ist, nicht nur „einmal zu testen“, sondern bewusst Vergleichsachsen einzubauen. Ziel ist, Ursache und Ort der Störung zu isolieren.

Vergleich über verschiedene Netze

Test aus dem Unternehmensnetz (Büro)
Test aus einem Mobilfunknetz
Test aus einem zweiten ISP (Homeoffice, Hotspot, Cloud-VM)
Optional: Test über VPN (ändert ASN/Egress)

Vergleich über verschiedene Ziele

CDN-Hostname (z. B. cdn.example.com)
Origin direkt (wenn erreichbar und erlaubt)
Ein spezifisches Asset (große Datei) vs. kleine Datei

Vergleich über verschiedene Protokolle

Traceroute/MTR (Pfad/Loss-Indikatoren)
HTTP(S)-Timing (DNS, TCP Connect, TLS, TTFB, Downloadrate)
Optional: Paketmitschnitt bei schwierigen Fällen (Retransmissions, MTU)

CDN-Probleme erkennen: Typische Root Causes und Indikatoren

Falscher PoP durch Anycast-Routing

Indiz: Traceroute zeigt einen langen Umweg oder einen Hop in einem weit entfernten Netz.
Indiz: Problem tritt nur bei bestimmten ISPs auf.
Maßnahme: Vergleichstests aus anderen ASNs, Dokumentation des erreichten PoP/ASN, Eskalation an CDN mit ISP/ASN/Traceroute.

Peering- oder Transit-Congestion

Indiz: Latenz steigt ab einem Hop, oft an einer Netzgrenze (AS-Edge), besonders zu Stoßzeiten.
Indiz: MTR zeigt Loss oder Jitter an bestimmten Hops (mit Vorsicht interpretieren).
Maßnahme: Zeitfenster dokumentieren, wiederholte Messungen, ggf. ISP/CDN-Peering-Team einschalten.

Cache Miss / Origin Bottleneck

Indiz: TTFB ist hoch, aber der Download selbst ist schnell (Edge wartet auf Origin-Antwort).
Indiz: Nur bestimmte Inhalte langsam (dynamisch, nicht-cachebar, selten angefragt).
Maßnahme: Cache-Header prüfen (Cache-Control, TTL), Origin-Performance messen, CDN-Logs/Headers (z. B. X-Cache, Age) auswerten.

Fehlerhafte Cache-Konfiguration

Indiz: Nutzer sehen veraltete Inhalte oder Inkonsistenzen zwischen Regionen.
Indiz: Unterschiedliche Antworten je nach PoP (Cache Keys variieren unerwartet, z. B. Query Strings, Cookies).
Maßnahme: Cache-Key-Design prüfen, Purge/Invalidate korrekt einsetzen, Versionierung über URLs (cache busting) standardisieren.

DNS/Geo-Steering fehlerhaft

Indiz: Unterschiedliche DNS-Antworten abhängig vom Resolver (Office vs. Home vs. Public DNS).
Indiz: Nutzer landen in unerwarteten Regionen, obwohl Anycast nicht die Hauptrolle spielt.
Maßnahme: DNS-Resolver-Pfad dokumentieren, TTL beachten, split-horizon/conditional forwarding prüfen.

HTTP/3/QUIC-Effekte

Viele CDNs unterstützen HTTP/3 über QUIC (UDP/443). Manche Unternehmensnetze blockieren UDP/443 oder behandeln es anders als TCP/443. Das kann zu Performance-Unterschieden oder Fallback-Verhalten führen.

Indiz: Im Büro langsam/instabil, im Mobilfunk schnell (oder umgekehrt).
Maßnahme: Test mit HTTP/3 deaktiviert vs. aktiviert (clientseitig), UDP/443-Policy prüfen, sauberes Fallback sicherstellen.

MTR als Ergänzung: Wenn Traceroute nicht reicht

MTR kombiniert Traceroute mit wiederholten Messungen und gibt dadurch ein besseres Gefühl für Jitter und sporadische Verluste. Dennoch gilt: Loss-Anzeigen auf Zwischenhops sind mit Vorsicht zu interpretieren, weil viele Router ICMP depriorisieren. Aussagekräftiger ist Verlust, der sich bis zum Ziel fortsetzt oder sich mit echten Applikationsproblemen deckt.

Sinnvoll: Um zeitabhängige Congestion sichtbar zu machen (Stoßzeiten).
Weniger sinnvoll: Als alleiniger „Beweis“ für Paketverlust auf einem Hop.

Praktische Auswertung: Wie Sie aus Traceroute/Anycast-Erkenntnissen Maßnahmen ableiten

Die wichtigste Fähigkeit ist, aus Messdaten eine Hypothese abzuleiten, die Sie verifizieren können. Diese Fragen helfen:

Erreichen alle betroffenen Nutzer denselben PoP oder unterschiedliche?
Ist der Pfad bei betroffenen Nutzern länger oder zeigt er „andere AS-Übergänge“?
Ist die Latenzsteigerung zeitabhängig (Peering-Congestion) oder konstant (Umweg/Policy)?
Ist TTFB hoch (Origin/Cache Miss) oder ist der Download selbst langsam (Transport/Throughput)?
Ist das Problem protokollspezifisch (UDP/443, HTTP/2 vs. HTTP/1.1)?

Beweisführung für CDN- oder ISP-Tickets: Was Sie liefern sollten

CDN-Teams können nur dann schnell helfen, wenn Sie reproduzierbare Daten liefern. Ein gutes Ticket enthält:

Betroffene URL/Hostname, betroffene Assets, Zeitfenster (mit Zeitzone)
Quellnetz/ASN/ISP (wenn möglich), Standort (Stadt/Land)
Erreichte IP(s) und ggf. Hinweis auf Anycast
Traceroute/MTR-Auszüge aus mehreren Netzen (betroffen vs. nicht betroffen)
HTTP-Timing: DNS, TCP Connect, TLS, TTFB, Downloadzeit (idealerweise mehrfach gemessen)
Hinweis, ob VPN/Proxy/Firewall im Pfad ist (und ob UDP/443 erlaubt ist)

Best Practices: CDN-Problemen vorbeugen und schneller diagnostizieren

Observability: Real User Monitoring (RUM) und synthetische Tests pro Region/ISP einführen.
Edge-Header nutzen: CDN-Response-Header (Cache Hit/Miss, PoP-ID, Age) standardmäßig auswerten.
Origin-Health: Origin-Latenz und Fehlerquoten getrennt vom Edge monitoren.
Cache-Design: klare TTL-Strategie, Versionierung, saubere Cache Keys, kontrollierte Invalidation.
Multi-CDN/Failover (optional): Für kritische Dienste kann Multi-CDN helfen, erfordert aber gutes Steering und Monitoring.
DNS-Strategie: Resolver-Pfade verstehen, TTLs bewusst setzen, Split-DNS sauber dokumentieren.

Outbound-Links zur Vertiefung

Checkliste: CDN Probleme erkennen mit Traceroute und Anycast

Symptom präzisieren: Region/ISP betroffen? Nur bestimmte Inhalte? Zeitabhängig oder konstant?
Auflösung dokumentieren: DNS-Antwort (A/AAAA), TTL, verwendeter Resolver; Anycast-IP erkennen.
Vergleich messen: Büro vs. Mobilfunk vs. anderer ISP vs. VPN-Egress; betroffen vs. nicht betroffen.
Traceroute sinnvoll wählen: bevorzugt TCP/443-Traceroute ergänzend zu ICMP/UDP; mehrere Runs wegen ECMP.
MTR ergänzen: Jitter/zeitabhängige Effekte sichtbar machen; Loss auf Zwischenhops vorsichtig interpretieren.
HTTP-Timing erfassen: DNS, TCP Connect, TLS, TTFB, Downloadzeit; Cache-Hit/Miss über Header prüfen.
Anycast-Hypothese prüfen: Landen betroffene Nutzer in einem anderen PoP? Längere AS-Pfade? Umwege?
Origin vs. Edge trennen: hoher TTFB deutet auf Origin/Cache Miss; langsamer Download eher auf Transport/Throughput.
Policy prüfen: Proxy/VPN/Firewall im Pfad? UDP/443 (HTTP/3) erlaubt oder blockiert? Fallback-Verhalten sauber?
Ticketfähig dokumentieren: Zeitfenster, ISP/ASN, Traceroutes, IPs, HTTP-Timings, betroffene URLs – dann zielgerichtet an CDN/ISP eskalieren.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Netzwerkdesign & Topologie-Planung
Router- & Switch-Konfiguration (Cisco IOS)
VLAN, Inter-VLAN Routing
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
NAT, ACL, DHCP, DNS-Konfiguration
Troubleshooting & Netzwerkoptimierung
Packet Tracer Projektentwicklung & Dokumentation
CCNA Lern- & Praxisunterstützung

Lieferumfang:

Konfigurationsdateien
Packet-Tracer-Dateien (.pkt)
Netzwerkdokumentation
Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.