RCA „Blackhole“ im Overlay: Mit Telemetrie beweisen

Ein RCA „Blackhole“ im Overlay zu schreiben ist anspruchsvoller als ein klassisches „Link down“-Postmortem, weil die sichtbaren Symptome oft nicht zur eigentlichen Ursache passen. In EVPN/VXLAN- und ähnlichen Overlay-Fabrics kann der Underlay vollständig „grün“ sein (VTEP-Reachability stabil, BGP-Sessions up), während einzelne Flows oder ganze Segmente trotzdem im Nirgendwo verschwinden. Genau das ist ein Blackhole: Pakete werden gesendet, aber auf dem Weg nicht zugestellt – ohne dass es zwingend einen offensichtlichen physischen Ausfall gibt. Der operative Knackpunkt ist die Beweisführung. Ein gutes RCA muss nicht nur eine plausible Geschichte erzählen, sondern mit Telemetrie belegen, wo der Traffic verloren ging, warum er verloren ging und welche Mechanismen dazu geführt haben, dass die üblichen Alarmierungen nicht sofort anschlugen. „Mit Telemetrie beweisen“ bedeutet dabei: Underlay- und Overlay-Sicht strikt trennen, Messpunkte entlang des Pfades definieren, Baselines heranziehen und Korrelationen zeitlich sauber herstellen. Dieser Leitfaden zeigt praxisnah, wie Sie ein RCA für Overlay-Blackholes strukturieren, welche Beweisartefakte besonders überzeugend sind (Route-Type-Daten, Next-Hop-Reachability, MTU/PMTUD-Indizien, ECMP-Pfadbeweise, Drops/Queue-Counter, ARP/ND-Bindings, Multihoming/DF-Events), und wie Sie aus den Daten konkrete Corrective Actions ableiten, ohne in Vermutungen oder Vendor-spezifische Details zu verfallen.

Was „Blackhole“ im Overlay konkret bedeutet

Ein Blackhole liegt vor, wenn Pakete auf dem geplanten Pfad verschwinden, ohne dass der Sender eine unmittelbare, eindeutige Fehlermeldung erhält. In Overlays kann das mehrere Formen annehmen:

• Flow-spezifisches Blackholing: nur bestimmte 5-Tuples (Quell-/Ziel-IP, Ports, Protokoll) scheitern, oft ECMP- oder Policy-getrieben.
• Segment-spezifisches Blackholing: ein VNI/VRF ist betroffen (z. B. falscher RT-Import oder fehlende EVPN-Route Types).
• Größenabhängiges Blackholing: kleine Pakete gehen, große Pakete droppen (MTU/PMTUD, Fragmentation, Encapsulation-Overhead).
• Richtungsabhängiges Blackholing: Hinweg funktioniert, Rückweg nicht (Asymmetrie, Stateful Service Insertion, Multihoming-Instabilität).

Im Gegensatz zu klassischen VLAN-Domänen ist „der Pfad“ im Overlay nicht nur eine physische Strecke. Er besteht aus Underlay (IP-Transport zwischen VTEPs) und Overlay (EVPN-Control-Plane + VXLAN-Data-Plane). Daher muss ein RCA immer beide Ebenen adressieren.

Warum Blackholes im Overlay so oft „mysteriös“ wirken

Overlay-Blackholes werden häufig nicht sofort erkannt, weil mehrere Mechanismen Symptome maskieren:

• TCP verschleiert Drops: Retransmissions halten Verbindungen scheinbar am Leben, bis Timeouts auftreten.
• Control Plane ist nicht Data Plane: BGP/EVPN kann stabil sein, obwohl Data-Plane-Pakete droppen (z. B. MTU oder pfadspezifische Drops).
• ECMP verteilt Flows: nur ein Pfad ist kaputt, daher scheitern nur bestimmte Flows.
• ARP/ND-Suppression: Bindings können stale sein; ARP sieht „ok“ aus, aber Unicast geht ins Leere.
• Schutzmechanismen greifen still: CoPP, Storm-Control, ACLs oder Policer droppen, ohne dass es als „Interface down“ erscheint.

RCA-Grundstruktur: So bauen Sie die Beweisführung auf

Ein RCA, das im Review Bestand hat, folgt einer klaren Struktur, die Beweise zwingend macht. Bewährt hat sich ein fünfstufiges Modell:

• 1) Impact definieren: wer war betroffen, welche Services, welcher Zeitraum, welche Symptome.
• 2) Pfad modellieren: Sender → Edge/VTEP → Underlay → Remote VTEP → Empfänger (inkl. Service Insertion, falls vorhanden).
• 3) Hypothesenliste: Underlay, Overlay-Control-Plane, Overlay-Data-Plane, Multihoming, MTU/PMTUD, Policy/Steering.
• 4) Telemetriebeweise pro Hypothese: pro Ebene klare „Pass/Fail“-Belege.
• 5) Root Cause + Corrective Actions: Ursache eindeutig, Actions messbar, Validation definiert.

Messpunkte: Wo Sie Telemetrie sammeln müssen, um ein Blackhole zu beweisen

Beweisführung scheitert oft daran, dass zwar Daten existieren, aber nicht entlang eines konsistenten Pfades. Für Overlays sollten Sie Messpunkte standardisieren:

• Endpoint-Messpunkt: Sender- und Empfänger-Sicht (Latency, Loss, TCP Retransmissions, ICMP).
• Ingress-VTEP/Leaf: Counters für Encapsulation, VXLAN egress, Queue Drops, ACL/Policer-Hits.
• Underlay-Links: ECMP/LAG Member-Status, Drops/Errors, MTU-Indizien, Pfadwechsel.
• Egress-VTEP/Leaf: Decapsulation/Ingress, Flooding/BUM-Indikatoren, ARP/ND/Bindings, MAC mobility.
• Optional Service-Knoten: Firewall/LB/WAF (Session Drops, NAT, Health Checks), wenn Steering involviert ist.

Die häufigsten Root-Cause-Klassen für Overlay-Blackholes

Für Troubleshooting und RCA lohnt sich eine Taxonomie. Sie hilft, ähnliche Incidents zu clustern und echte Prävention abzuleiten.

Root-Cause-Klasse A: Underlay-Blackhole (trotz „Link up“)

Das Underlay kann Pakete droppen, obwohl Interfaces up sind. Typische Ursachen: ECMP-Pfad mit fehlerhafter MTU, asymmetrische LAG-Mitglieder, Queue Drops unter Last, ACL/Policer im Underlay oder ein Partial Failure (z. B. Optik-Degradation ohne Link-Down).

• Signatur: nur bestimmte Flows betroffen, häufig abhängig von ECMP; große Pakete besonders betroffen.
• Beweisartefakte: pfadspezifische Drops/Errors, MTU/Fragmentation-Indizien, ECMP-Hash-Korrelation.

Root-Cause-Klasse B: Overlay-Control-Plane-Blackhole (EVPN-Route fehlt oder falsch)

Wenn EVPN-Routen fehlen oder nicht importiert werden, wird Traffic falsch zugestellt oder geflutet, was wiederum zu Drops führen kann. Häufige Auslöser sind RT-Mismatch, falsches VNI/VRF-Mapping oder fehlende Route Types.

• Signatur: Segment „unsichtbar“, Type-2 oder Type-5 Counts brechen ein, Unknown Unicast steigt.
• Beweisartefakte: EVPN Route Presence/Absence (Type 2/3/5), RT-Import/Export-Status, Next-Hop-Plausibilität.

Root-Cause-Klasse C: Overlay-Data-Plane-Blackhole (Encapsulation/Decapsulation/Policies)

Die Control Plane kann korrekt sein, aber die Data Plane dropt aufgrund von MTU, VXLAN-UDP/Port-Handling, CoPP/ACLs am VTEP oder Mirror-/Offload-Anomalien. Besonders häufig: MTU Underlay vs. Overlay und PMTUD-Blockaden.

• Signatur: EVPN stabil, aber „nur große Payloads“ brechen; Retransmissions steigen; ICMP „Packet Too Big“ fehlt.
• Beweisartefakte: Größenabhängige Tests, PMTUD-ICMP-Policy, Drops auf VTEP-Uplinks.

Root-Cause-Klasse D: Multihoming/DF/Split-Horizon-Probleme

In EVPN Multihoming oder MLAG/EVPN-Mischungen können DF-Wahl, ESI-Inkonsistenzen oder Split-Horizon-Fehler zu Blackholes führen, insbesondere nach Failover oder Re-Join.

• Signatur: MAC-Flapping ohne klassischen Loop, intermittierende Erreichbarkeit nach Link-/Node-Events, BUM-Spikes.
• Beweisartefakte: DF-Change-Events, MAC mobility/move Rate, Segment-States (Type 1/4/2), Failover-Timeline.

Root-Cause-Klasse E: Service Insertion / Stateful Device Asymmetrie

Firewall/LB-Steering kann Hin- und Rückweg asymmetrisch machen. Dann sieht es wie ein Overlay-Blackhole aus, ist aber ein Policy-/Steering-Designfehler oder ein Health-Check-Problem.

• Signatur: nur bestimmte Ports/Flows betroffen, Session Resets, Richtung asymmetrisch, Probleme unter Last oder nach Failover.
• Beweisartefakte: Flow-Logs (Hin/Rückweg über Service), Session-Counter, NAT-Logs, Steering-Match-Counter.

Beweisführung mit Telemetrie: Der „Gating“-Ansatz

Damit ein RCA nicht zu einer Debatte wird, arbeiten Sie mit Gates: Jede Hypothese wird durch eindeutige Pass/Fail-Belege ausgeschlossen oder bestätigt. Der Ablauf ist bewusst streng: erst Underlay-Transport, dann Overlay-Control-Plane, dann Overlay-Data-Plane.

Gate 1: Underlay ist wirklich transportfähig

• VTEP-Reachability: VTEP/Loopback-IPs erreichbar und stabil (keine Flaps im Zeitfenster).
• Pfadvielfalt: ECMP/LAG Member stabil, keine einseitigen Member-Ausfälle.
• Drops/Errors: keine pfadspezifischen Drops, die mit den betroffenen Flows korrelieren.

Gate 2: EVPN-Objekte sind vorhanden und sichtbar

• RT-Import/Export: betroffene VRF/EVI importiert die richtigen RTs (keine „unsichtbaren“ Segmente).
• Route Types: Type 2 für betroffene Hosts, Type 5 für betroffene Präfixe, Type 3 für BUM (wenn relevant).
• Next Hop plausibel: Next Hop zeigt auf den richtigen VTEP und ist underlay-seitig erreichbar.

Gate 3: Data Plane zeigt den Drop-Ort

• Ingress vs. Egress Counters: Pakete verlassen Ingress-VTEP, kommen aber nicht am Egress-VTEP an (oder umgekehrt).
• Queue/ACL/Policer Hits: Drops an einem konkreten Interface/Policy-Knoten nachweisbar.
• Größenabhängigkeit: Verlust tritt ab bestimmter Paketgröße auf (MTU/PMTUD).

Drop-Ort als einfaches Differenzmodell (MathML)

$\mathrm{Loss}=\mathrm{Packets}\_\mathrm{ingress\_sent}-\mathrm{Packets}\_\mathrm{egress\_received}$

Wenn Sie diese Differenz zeitlich und pro Flow/Segment korrelieren, entsteht ein belastbarer Beweis: Der Verlust ist nicht „gefühlter Impact“, sondern messbar auf einer konkreten Strecke.

Telemetrieartefakte, die in RCAs besonders überzeugend sind

Viele Datenpunkte sind „nice to have“. Einige sind jedoch in Reviews immer wieder die Load-Bearing-Beweise, weil sie direkt Ursache und Wirkung verknüpfen.

Artefakt 1: Zeitreihe „Flow-Symptom“ vs. „Drop-Counter“

• Beispiel: TCP Retransmissions steigen ab 12:03, zeitgleich steigen Queue Drops auf Underlay-Link X oder Policer-Drops auf VTEP-Y.
• Warum überzeugend: zeitliche Korrelation plus mechanistischer Zusammenhang.

Artefakt 2: Route-Type-Deltas (Before/After)

• Beispiel: Type-2 Route Count für VNI 105 sinkt abrupt nach Change; Unknown Unicast steigt; nach RT-Fix normalisiert sich beides.
• Warum überzeugend: zeigt, dass die Control Plane die „Wahrheit“ verloren hat und Flooding/Blackhole folgte.

Artefakt 3: „Large vs. Small“-Beweis bei MTU/PMTUD

• Beispiel: kleine Pakete (z. B. 64–256 Byte) ok, größere Payloads droppen; ICMP „Packet Too Big“/„Frag Needed“ fehlt; nach ICMP-Policy-Fix sinken Retransmissions.
• Warum überzeugend: reproduzierbar, klarer Kipp-Punkt.

PMTUD-Kernprinzip (MathML)

$\mathrm{PMTUD\_OK}\Leftarrow \mathrm{ICMP\_PacketTooBig}allowed\wedge \mathrm{PathMTU}\ge \mathrm{RequiredMTU}$

Artefakt 4: ECMP-Pfadbeweis

• Beispiel: nur Flows mit Hash auf Pfad A droppen; nach Entfernen/Repair von Link A sind alle Flows stabil.
• Warum überzeugend: erklärt „Intermittency“ ohne Spekulation.

Artefakt 5: Multihoming-/DF-Event-Korrelation

• Beispiel: DF-Change-Spike nach Link-Fail; danach MAC mobility steigt und bestimmte Flows blackholen; Stabilisierung nach DF-Fix oder ESI-Korrektur.
• Warum überzeugend: verbindet Failover-Mechanik mit Datenebenen-Symptom.

Wie Sie das RCA schreiben: Sprache, Struktur, Beweislogik

Auch der beste Datensatz wirkt schwach, wenn das RCA unstrukturiert ist. Eine praxistaugliche Schreibstruktur für Overlay-Blackholes:

• Incident Summary: ein Absatz, der Impact und Zeitraum klar nennt.
• Systemmodell: Underlay/Overlay-Topologie in Worten (VTEPs, VRFs/VNIs, Service Insertion falls vorhanden).
• Timeline: Events mit absoluten Zeiten (Change, First Symptom, Detection, Mitigation, Fix, Stabilitätsfenster).
• Evidence: pro Gate (Underlay, Control Plane, Data Plane) klare Belege mit „was wäre zu erwarten“ vs. „was wurde beobachtet“.
• Root Cause: ein Satz, der die Ursache technisch eindeutig beschreibt (kein „möglicherweise“).
• Corrective Actions: 3–8 Actions, jede messbar, mit Owner und Validierungsregel.

Corrective Actions: Wie Sie aus Telemetrie konkrete Prävention ableiten

Overlay-Blackholes sind häufig Wiederholungsfehler, wenn sie nicht in Guardrails übersetzt werden. Typische Actions, die in der Praxis Wirkung zeigen:

• RT-Drift-Detection: Alarm bei unerwarteten RT-Imports/Exports oder Route-Count-Drops pro Type.
• MTU-Compliance: Underlay-MTU als verbindlicher Standard, automatisierte Checks; PMTUD-ICMP gezielt erlauben.
• ECMP-Pfadmonitoring: per-member Drops/Errors überwachen; Hash- oder Pfadprobleme als eigene Fault Domain behandeln.
• Multihoming-Guardrails: DF-Change-Alerts, MAC mobility thresholds, Failover-Tests nach Changes.
• Service-Steering-Symmetrie: Flow-Logs/Telemetry, die Hin- und Rückweg über denselben Service belegen.
• Evidence-Pack-Automation: Standardpaket an Metriken/Logs automatisch beim Incident sammeln.

Validierungs-Checkliste: „Blackhole-Fix“ wirklich abgeschlossen?

• Reproduktion gestoppt: der betroffene Flow/Segment ist stabil, nicht nur „scheinbar besser“.
• Beweis-Metriken normalisiert: Drops/Queue-Counter bleiben im Baseline-Band; Retransmissions sinken.
• Underlay stabil: keine member-spezifischen Drops; VTEP-Reachability stabil.
• EVPN stabil: Route Types/Counts plausibel, keine Withdraw-Spikes, RT-Import korrekt.
• Stabilitätsfenster: definierte Zeit (z. B. 30–60 Minuten) ohne Rückfall, idealerweise unter repräsentativer Last.

Outbound-Ressourcen

• RFC 7432 (EVPN: Route Types, Multihoming, Control Plane)
• RFC 7348 (VXLAN: Encapsulation, UDP/4789 und Overhead)
• RFC 8365 (EVPN/VXLAN über IP-Underlay: Architekturhinweise)
• RFC 1191 (Path MTU Discovery IPv4)
• RFC 8201 (Path MTU Discovery IPv6)
• Wireshark Dokumentation (PCAP-Analyse, VXLAN-Decoding und Retransmission-Indikatoren)

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.