Layer 3: „Ping geht, App fällt aus“ – L3- oder L7-Problem eindeutig klären

„Ping geht, App fällt aus“ gehört zu den häufigsten und gleichzeitig irreführendsten Aussagen im On-Call- und NOC-Alltag. Ein erfolgreicher ICMP-Ping beweist nämlich nur sehr wenig: Er zeigt, dass zwischen zwei Endpunkten grundsätzlich IP-Konnektivität möglich ist und dass ICMP nicht blockiert wird. Er beweist jedoch nicht, dass TCP-Verbindungen stabil aufgebaut werden können, dass Path MTU stimmt, dass NAT- oder Firewall-States korrekt sind, dass DNS zum richtigen Ziel auflöst oder dass die Anwendung auf Layer 7 gesund antwortet. Genau hier entstehen lange MTTRs: Teams bleiben zu früh bei „Netzwerk ist grün“ stehen oder suchen zu lange in Layer 7, obwohl ein Layer-3- oder Layer-4-Problem die eigentliche Ursache ist. In diesem Artikel lernen Sie, wie Sie in wenigen Schritten eindeutig klären, ob es ein L3-Problem (Routing, MTU, Fragmentierung, asymmetrische Pfade, ACLs) oder ein L7-Problem (HTTP, Auth, API, TLS, Applikationslogik) ist – mit reproduzierbaren Checks, klaren Indikatoren und einer Dokumentation, die Eskalationen an Netzwerk- oder Applikationsteams sauber begründet.

Warum Ping als „Beweis“ oft nicht ausreicht

Ping nutzt ICMP Echo Request/Reply. Viele Netze behandeln ICMP anders als TCP/UDP: ICMP wird bewusst erlaubt, damit Monitoring funktioniert, während Applikationsports restriktiv gefiltert werden. Außerdem kann ICMP priorisiert, rate-limitiert oder in Hardware schneller verarbeitet werden als regulärer Datenverkehr. Und selbst wenn ICMP-Pakete hin und zurück kommen, kann die Anwendung scheitern, weil TCP-Handshake, TLS-Handshake, HTTP-Header, Payload-Größe oder Session-State betroffen sind.

• ICMP ≠ TCP: Ping sagt nichts über TCP 3-Way-Handshake, Retransmits oder Window-Scaling.
• ICMP ≠ MTU: Kleine Echo-Pakete laufen, große Payloads fragmentieren oder werden gedroppt.
• ICMP ≠ DNS: Ping gegen IP kann gehen, App über Hostname fällt aus (falsches DNS oder Split-Horizon).
• ICMP ≠ TLS/HTTP: Anwendung kann wegen Zertifikat, SNI, Headern oder Auth scheitern.

Für ICMP-Grundlagen ist RFC 792 eine sinnvolle Referenz. Für IP selbst ist RFC 791 relevant.

Das Ziel: L3- oder L7-Problem eindeutig abgrenzen

Eine saubere Abgrenzung folgt einem einfachen Prinzip: Arbeiten Sie sich von „Transport kann eine Session aufbauen“ bis „Applikation antwortet korrekt“ vor, und dokumentieren Sie an welcher Stufe es bricht. In der Praxis ist die wichtigste Trennlinie nicht zwischen L3 und L7, sondern zwischen L3/L4-Konnektivität und Session-/Applikationsverhalten. Deshalb nutzen viele Runbooks eine „L3/L4-Gate“-Prüfung: Wenn TCP zuverlässig aufgebaut und Daten übertragen werden, ist ein reines L3-Problem unwahrscheinlich.

Praktischer Decision Tree: In 10 Minuten zur eindeutigen Richtung

• 1) Prüfen Sie DNS vs. IP: Geht der Zugriff per IP, aber nicht per Hostname, ist DNS oder SNI/TLS wahrscheinlicher als Routing.
• 2) Prüfen Sie TCP-Handshake: Kommt SYN/SYN-ACK/ACK sauber zustande? Wenn nein: eher L3/L4 (Firewall, Routing, NAT, ACL).
• 3) Prüfen Sie Applikationsport statt ICMP: Ist der Zielport erreichbar (z. B. 443, 8443, 5432)?
• 4) Prüfen Sie TLS/HTTP: Kommt ein TLS-Handshake zustande? Kommt eine HTTP-Response mit Statuscode?
• 5) Prüfen Sie Payload/MTU: Scheitert es nur bei großen Antworten oder Uploads? Dann MTU/Fragmentierung oder Proxy/LB-Limits prüfen.

Schritt 1: DNS ausschließen oder bestätigen

Viele „Ping geht, App fällt aus“-Fälle sind DNS-Fälle. Ping wird häufig gegen eine IP durchgeführt oder gegen einen Namen, der in einer anderen Resolver-Sicht auflöst als die Applikation (z. B. Container/Pod-Resolver, Client-VPN-Resolver, Split DNS). Außerdem kann die App eine andere Zieladresse nutzen als Ping, etwa weil sie einen FQDN, einen Service-Discovery-Namen oder mehrere A/AAAA-Records verwendet.

• Gleiches Ziel? Prüfen Sie, ob Ping und App wirklich dasselbe Ziel verwenden (Hostname, IP, Port).
• TTL und Rotation: Kurze DNS-TTLs können dazu führen, dass Ping eine andere IP trifft als die App Sekunden später.
• IPv4 vs IPv6: App bevorzugt AAAA, Ping nutzt IPv4 (oder umgekehrt). Das kann zu „geht/geht nicht“ führen.

Für DNS ist RFC 1035 eine grundlegende Referenz.

Schritt 2: TCP-Handshake als harte Trennlinie nutzen

Wenn eine Anwendung über TCP läuft (HTTP(S), Datenbanken, APIs), ist der TCP-Handshake der schnellste „Reality Check“. Ein echter L3-Fehler zeigt sich häufig als Timeouts (SYN ohne SYN-ACK), während viele L7-Probleme erst nach erfolgreichem Aufbau auftreten (z. B. TLS-Fehler, 401/403, 5xx, Timeouts bei Requests).

• SYN Timeout: Zielport nicht erreichbar oder Rückweg fehlt (Routing/Firewall/NAT/ACL).
• SYN-ACK kommt, aber danach Abbruch: Zwischenzustand möglich, z. B. State-Firewall, asymmetrischer Rückweg, RST durch Zwischenkomponente.
• Handshake ok, App hängt: eher L5–L7 (TLS, Auth, Applikationslogik, Backend-Abhängigkeiten).

Für TCP ist RFC 9293 (aktuelle TCP-Spezifikation) eine passende Referenz.

Schritt 3: „Port offen“ ist nicht gleich „App gesund“

Ein offener Port beweist, dass ein Dienst irgendwie lauscht und dass L3/L4 zumindest grundsätzlich funktioniert. Trotzdem kann eine App fallen, weil sie auf Health-Checks antwortet, aber bei echten Requests scheitert. Load Balancer können außerdem Verbindungen annehmen, obwohl Backends degraded sind, oder sie können bestimmte Pfade/Methoden blockieren.

• Layer-4-LB: TCP-Connect klappt, aber Backend-Timeouts oder Reset bei Datenübertragung.
• Layer-7-LB/Proxy: HTTP 200 auf „/health“, aber 5xx oder Timeout auf produktiven Endpunkten.
• Policy-Unterschiede: ICMP erlaubt, TCP/UDP gefiltert; oder 443 erlaubt, 8443 nicht.

Schritt 4: TLS und HTTP als L7-Indikatoren

Wenn Ping und TCP-Handshake ok sind, ist der nächste saubere Test der TLS-Handshake (bei HTTPS) und danach eine echte HTTP-Anfrage. Hier können Sie sehr klar zwischen Netzwerk- und Applikationsproblemen unterscheiden, weil ein HTTP-Statuscode bereits zeigt, dass die Anwendungsschicht erreicht wurde.

• TLS-Handshake schlägt fehl: häufig Zertifikat, SNI/Hostname, Cipher-Policies, Proxy-Interception oder Zeitabweichung.
• HTTP 401/403: App erreichbar, aber Auth/Policy/Token problematisch (klarer L7-Fall).
• HTTP 404: falscher Pfad oder falsches Target (DNS, Routing zum falschen Service, Ingress-Regel).
• HTTP 5xx: App/Backend instabil (L7), kann aber durch Netzwerk zu Backends ausgelöst werden.

Für HTTP/1.1 ist RFC 9112 relevant, und für HTTP Semantik RFC 9110. Für TLS bietet RFC 8446 (TLS 1.3) einen fundierten Rahmen.

Typische L3/L4-Ursachen, obwohl Ping funktioniert

Wenn Sie bereits sehen, dass TCP nicht sauber aufgebaut wird oder dass Datenübertragung bricht, sind diese Ursachen besonders häufig. Sie sind oft „unsichtbar“, wenn man nur pingt.

• Asymmetrisches Routing: Hinweg ok, Rückweg anders und wird von State-Firewalls/NAT nicht akzeptiert.
• Firewall/ACL nur für ICMP offen: ICMP erlaubt, Applikationsport blockiert oder nur von bestimmten Quellen erlaubt.
• NAT-State/Timeout: Ping läuft, aber TCP-Sessions werden aufgrund kurzer State-Timeouts oder Exhaustion gekillt.
• Path MTU / Fragmentierung: Kleine Pakete ok, große Antworten brechen (besonders bei VPN, Tunneling, VXLAN, GRE).
• ECMP/Hashing: Einzelne Pfade in ECMP sind defekt; Ping trifft „guten“ Pfad, App-Flows landen auf „schlechtem“.
• QoS/Policing: ICMP wird priorisiert oder nicht limitiert, Applikationstraffic wird gedrosselt oder gedroppt.

Path-MTU als häufige Ursache bei „klein geht, groß geht nicht“

Ein klassisches Muster: Ping funktioniert, sogar ein TCP-Handshake funktioniert, aber Downloads, API-Responses oder TLS-Handshakes brechen ab. Ursache ist oft MTU-Mismatch oder geblocktes PMTUD. In IPv4 kann Fragmentierung zwar helfen, wird aber in vielen Netzen unzuverlässig oder gezielt eingeschränkt. In Tunneling-Szenarien (VPN, Overlay) ist das besonders relevant.

$\mathrm{EffektiveMTU}=\mathrm{LinkMTU}–\mathrm{Overhead}$

• Overhead-Beispiele: VPN-, GRE- oder VXLAN-Header reduzieren die nutzbare MTU.
• Symptom: Kleine Requests ok, größere Responses timeouten oder TLS-Handshakes hängen.
• Hinweis: Wenn „DF“ (Don’t Fragment) und ICMP „Fragmentation Needed“ geblockt sind, funktioniert PMTUD nicht zuverlässig.

Für PMTUD ist RFC 1191 (IPv4) eine wichtige Referenz.

Typische L7-Ursachen, obwohl Netzwerkpfad gesund ist

Wenn TCP stabil aufgebaut wird, TLS funktioniert und Sie HTTP-Responses sehen, liegt das Problem in den meisten Fällen in Layer 7 oder in abhängigen Backends der Anwendung. Das kann trotzdem „wie Netzwerk“ wirken, weil Timeouts, Retries und Load-Balancing entstehen.

• Auth/Token/Session: 401/403, abgelaufene Tokens, Clock Skew, falsche Audience/Issuer.
• Falsche Endpoint-/Route-Konfiguration: Ingress/Proxy routet auf falschen Service, 404/502/503.
• Backend-Degradation: Datenbank langsam, Cache down, Rate Limits, Threadpool erschöpft.
• TLS/SNI/Certificate Mismatch: Ping und TCP ok, aber TLS bricht wegen falschem Zertifikat oder SNI ab.
• App-spezifische Limits: Max Header Size, Body Size, Zeitlimits, WAF-Regeln, Content-Length/Chunking-Probleme.

Der „Eindeutigkeitstest“: Was Sie dokumentieren müssen, um Diskussionen zu vermeiden

Viele Eskalationen scheitern nicht an Technik, sondern an unklarer Evidence. Die beste Praxis ist, pro Layer ein eindeutiges „Ja/Nein“ zu dokumentieren: „DNS korrekt“, „TCP Handshake ok“, „TLS ok“, „HTTP Statuscode X“. Damit kann kein Team seriös behaupten, das Problem liege „bestimmt“ woanders.

• Zieldefinition: Hostname, aufgelöste IP(s), Port, Protokoll (HTTP/HTTPS/gRPC/etc.).
• DNS-Ergebnis: Resolver, Antwort (A/AAAA), TTL, ob mehrere IPs rotieren.
• Transport: TCP-Handshake erfolgreich? Gibt es RST/Timeout? Retransmits auffällig?
• TLS: Handshake erfolgreich? Zertifikat passt zum Hostnamen? SNI korrekt?
• HTTP: Statuscode, Latenz, Response-Header, ob ein spezifischer Pfad betroffen ist.
• Zeitfenster: Zeitpunkt der Messungen, Korrelation zu Changes oder Traffic-Spitzen.

Fehlermuster, die L3 und L7 oft „verwechseln“ lassen

Einige Muster sind besonders irreführend, weil sie sowohl durch Netzwerk als auch durch Applikation ausgelöst werden können. Hier hilft eine strukturierte Reihenfolge der Tests.

• Timeouts: Kann L3 (Drop), L4 (State/MTU), oder L7 (Backend hängt) sein. Entscheidend: Kommt überhaupt eine TCP-Session zustande?
• Intermittierend: Häufig ECMP-Pfadproblem, Load-Balancer-Backend-Flapping oder DNS-Rotation auf kranke Targets.
• Nur große Antworten brechen: oft MTU/PMTUD oder Proxy-Body-Limits; Ping sagt hier nahezu nichts.
• Nur bestimmte Clients betroffen: Policy/ACL per Source, NAT-Pool erschöpft, oder Auth/Feature-Flag nur für bestimmte Gruppen.

Stabiler Betrieb: Welche Monitoring-Signale wirklich helfen

Damit „Ping geht, App fällt aus“ nicht immer wieder neu beginnt, sollten Sie Monitoring so gestalten, dass es Layer-übergreifend prüft. Ein reines ICMP-Monitoring ist zu grob. Besser ist ein gestuftes Synthetic Monitoring: DNS → TCP → TLS → HTTP, jeweils mit klarer Fehlermeldung.

• DNS-Synthetics: Auflösung aus derselben Perspektive wie der Client (Standort/VPN/Cluster).
• TCP-Checks: Port-Connect als L4-Signal, getrennt von HTTP.
• TLS-Checks: Zertifikatsgültigkeit, SNI, Ablaufdaten, Handshake-Zeit.
• HTTP-Checks: Statuscodes und Latenzen für produktive Endpunkte, nicht nur „/health“.
• MTU/PMTUD-Indikatoren: Drops/Fragmentation/ICMP-Block-Events in Tunneling-Pfaden.

Mehrstufige Verfügbarkeit als messbare Größe (MathML)

$\mathrm{ServiceOK}=\mathrm{DNSOK}\wedge \mathrm{TCPOK}\wedge \mathrm{TLSOK}\wedge \mathrm{HTTPOK}$

Wenn Sie diese vier Signale getrennt messen, wird die Ursachenrichtung automatisch klarer: Ein Ausfall bei DNS/TCP deutet stärker auf Netzwerk/Plattform hin, ein Ausfall erst bei TLS/HTTP stärker auf Applikation, Zertifikate, Policies oder Backend-Abhängigkeiten.

Response-Plan für On-Call: Sichere Schritte ohne „Trial and Error“

Ein guter Response-Plan vermeidet riskante Änderungen, bevor die Ursache eingegrenzt ist. Gerade bei „Ping geht“ besteht die Gefahr, unnötig Routing oder Firewalls anzufassen, obwohl ein L7-Thema vorliegt. Umgekehrt ist es riskant, Applikationsrollouts zu starten, wenn TCP nicht zuverlässig aufgebaut wird.

• Schrittfolge fixieren: DNS → TCP → TLS → HTTP → Payload/MTU → Pfad-Asymmetrie.
• Nur eine Variable pro Schritt: nicht gleichzeitig DNS und Firewall ändern; sonst verlieren Sie Kausalität.
• Evidence vor Mitigation: mind. ein Snapshot der Fehlermeldung (Statuscode/Timeout), Ziel-IP, Zeitstempel.
• Bei Verdacht auf MTU: zuerst Tunneling-/Overlay-Overhead prüfen, dann PMTUD/ICMP-Policies, erst danach MTU global ändern.
• Bei Intermittency: prüfen, ob DNS mehrere Targets liefert oder ob ECMP/Load-Balancer-Backends flappen.

Outbound-Links für Standards und Grundlagen

• RFC 792 (ICMP) zur Einordnung dessen, was Ping tatsächlich misst.
• RFC 791 (IPv4) als Basis für Layer-3-Verständnis.
• RFC 9293 (TCP) für Transport-Mechanismen, Handshake und Retransmits.
• RFC 9110 (HTTP Semantics) zur Interpretation von HTTP-Statuscodes und Verhalten.
• RFC 9112 (HTTP/1.1) für Protokolldetails, die häufige L7-Fehler erklären.
• RFC 8446 (TLS 1.3) für TLS-Handshake- und Zertifikatsthemen.
• RFC 1191 (Path MTU Discovery) für das häufige „klein geht, groß geht nicht“-Fehlermuster.

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.