BGP-Peering-Troubleshooting ist im Provider- und Carrier-Umfeld eine der häufigsten Ursachen für eskalierende Tickets, weil Symptome auf Kundenseite selten eindeutig sind: „Latenz hoch“, „Packet Loss“, „bestimmte Ziele unreachable“ oder „Traffic nimmt plötzlich einen anderen Pfad“. In der Praxis steckt dahinter meist eine von drei Klassen: ein Interconnect-Problem (physisch oder L2/L3 am Peering-Port), ein Policy-Problem (Filter, Attributes, Route-Leaks, fehlende Präfixe) oder Congestion (Überlastung, Queueing, Mikrobursting, Shaping). Die Kunst besteht darin, schnell zu entscheiden, welche Klasse vorliegt, und das mit belastbaren Daten zu belegen, statt mit Vermutungen. Dabei ist wichtig: BGP selbst transportiert die Steuerinformationen (Routen, Next Hops, Attributes), aber nicht die Nutzdaten. Ein BGP-Session-Status „Established“ ist deshalb kein Beweis dafür, dass Datenverkehr sauber läuft, und umgekehrt kann ein Data-Plane-Problem die BGP-Session stabil wirken lassen, während Kundenpakete droppen. Dieser Ops Guide zeigt, wie Sie BGP-Peering-Troubleshooting systematisch angehen: Welche Signaturen typisch für Interconnect, Policy oder Congestion sind, welche Minimaltests in welcher Reihenfolge sinnvoll sind, wie Sie mit Telemetrie einen Case beweisen und welche Evidence Packs Sie für Vendor-/Peer-Eskalationen standardisieren sollten.
Grundlage: Was BGP kann und was nicht
BGP (Border Gateway Protocol) ist ein Routing-Protokoll zur Verteilung von Präfixen und Pfad-Attributen zwischen autonomen Systemen. Es entscheidet, welche Routen im RIB landen und damit potenziell in die FIB programmiert werden. BGP stellt jedoch keine „Leitung“ bereit: Interconnect-Qualität und Datenebenen-Performance hängen von L1/L2, IP-Forwarding und Kapazität ab. Für die Begriffs- und Mechanikbasis ist RFC 4271 die Referenz, für BGP-Fehlerbehandlung sind RFC 7606 und für Graceful Restart RFC 4724 hilfreich.
- Control Plane: BGP Session, Keepalives, Updates, Policies (Import/Export).
- Data Plane: tatsächliche Paketweiterleitung, MTU, Queueing, Drops, ECMP, LAG.
- Ops-Konsequenz: Troubleshooting muss beide Ebenen trennen und dann wieder korrelieren.
Die drei Hauptursachenklassen: Interconnect, Policy, Congestion
Viele Peering-Incidents lassen sich mit einem schnellen Klassifikationsschema einordnen. Das Ziel ist nicht „sofort Root Cause“, sondern „schnell die richtige Fault Domain“.
- Interconnect: physische/optische Fehler, LACP/Port-Channel-Instabilität, VLAN/MTU/ACL am Peering-Port, ARP/ND-Probleme bei eBGP über L2.
- Policy: fehlende oder falsche Präfixe, Route-Leaks, falsche LocalPref/MED/AS-PATH, Communities falsch interpretiert, RPKI/IRR-bedingte Drops, Next-Hop/Recursive-Resolution-Probleme.
- Congestion: Auslastung, Queue Drops, Mikrobursts, Shaping/Policing, Bufferbloat, asymmetrische Kapazität (eine Richtung überlastet).
Symptom-Mapping: Welche Signaturen wofür sprechen
Die folgenden Muster sind in der Praxis besonders zuverlässig, um die Hypothese zu priorisieren.
Signaturen für Interconnect-Probleme
- Session flaps korrelieren mit Interface-Events: BGP geht down/up zeitgleich mit Link-Loss, LACP-Member-Flaps oder Optik-Warnungen.
- Einseitige Erreichbarkeit (Layer-2/ARP): Nachbar-IP gelegentlich nicht erreichbar, ARP/ND-Einträge flappen, MAC bewegt sich unerwartet.
- CRC/Errors/Discards: Fehlerzähler steigen, obwohl Auslastung moderat ist.
- MTU-Mismatch: kleine Pakete ok, größere Control- oder Data-Pakete problematisch; PMTUD-Indizien fehlen.
Signaturen für Policy-Probleme
- „Bestimmte Ziele“ oder „bestimmte Präfixe“ betroffen: Reachability-Ausfälle sind präfix-spezifisch, nicht last- oder zeitabhängig.
- Pfadwechsel ohne Link-/Laständerung: Traffic nimmt plötzlich einen anderen Transit/Peer, weil Attributes geändert wurden.
- Ungewöhnliche Route-Counts: deutlich weniger (oder deutlich mehr) empfangene/gesendete Präfixe als erwartet.
- Filtering-Events: RPKI/IRR-Validierung schlägt an, Max-Prefix greift, Communities werden nicht akzeptiert.
Signaturen für Congestion
- Loss/Latency korrelieren mit Auslastung: Spitzen treten zu Lastzeiten auf, verschwinden in Off-Peak.
- Queue Drops/ECN-Markierungen: Drops steigen bei hoher Rate; TCP zeigt Retransmissions; Latenz steigt deutlich.
- Asymmetrie: nur eine Richtung überlastet (z. B. inbound voll, outbound frei) oder nur ein Member im LAG dropt.
- Mikrobursts: Durchschnittsauslastung ok, aber kurze Peaks erzeugen Drops (sichtbar in High-Resolution-Telemetrie).
Runbook: BGP-Peering-Troubleshooting in der richtigen Reihenfolge
Das folgende Vorgehen ist als Minimal-Workflow gedacht. Es liefert schnelle Pass/Fail-Gates, damit Sie nicht in Details versinken.
Gate 1: Ist die Session wirklich stabil?
- Check: BGP-Session-Status (Established), Uptime, Flap-Historie, Keepalive/Hold Timer Events.
- Interpretation: Häufige Flaps sind fast immer Interconnect oder Control-Plane-Überlast; reine Policy-Probleme lassen Sessions meist stabil.
Gate 2: Interconnect-Health (L1/L2/L3 am Peering-Port)
- Check: Interface-Status, Optik/PHY-Warnungen, CRC/FEC/Discards, LACP-Member-Status, Speed/Duplex, VLAN/Encapsulation, ACL/Policer Hits.
- Check: Nachbar-IP Reachability (stabil, keine Loss-Spikes), ARP/ND-Stabilität (kein Flapping).
- Stop-Kriterium: Jede Form von physischer Instabilität oder steigenden Error-Countern hat Priorität vor Policy-Diskussionen.
Gate 3: Policy-/Routing-Sicht (Kontrollplane-Logik)
- Check: empfangene und gesendete Präfixanzahlen (Baseline vs. aktuell), Max-Prefix/Thresholds, Graceful Restart Status.
- Check: Best-Path-Entscheidung: LocalPref, AS-PATH, MED, Communities, Next-Hop-Validität (rekursiv erreichbar).
- Check: Filters/Validierung: RPKI-Status (Valid/Invalid/NotFound), IRR-Filter, Prefix-Limits.
Gate 4: Congestion-Analyse (Datenebene und Kapazität)
- Check: Link-Auslastung (95th, Peaks), Queue Drops, Buffer-Events, Policing/Shaping, ECN (falls genutzt).
- Check: Per-Member-Auslastung bei LAG/ECMP: dropt ein einzelner Member?
- Check: Zeitkorrelation: tritt Loss zu bestimmten Uhrzeiten oder nur bei bestimmten Traffic-Events auf?
Minimaltests, die sich im NOC bewährt haben
Diese Tests sind schnell, risikoarm und liefern häufig sofort eine Hypothese mit hoher Trefferquote.
- Neighbor-IP Probe: konstante ICMP/UDP-Probes (klein und groß), um Interconnect und MTU/PMTUD-Indizien zu trennen.
- Prefix-spezifische Probes: 2–3 betroffene Zielpräfixe gezielt testen (Traceroute/MTR mit Vorsicht interpretieren).
- Flow-Symmetrie: wenn möglich beide Richtungen testen (inbound vs. outbound), um asymmetrische Congestion zu erkennen.
- Route-Count Delta: Vorher/Nachher-Vergleich von accepted prefixes als sofortiger Policy-Indikator.
Policy-Fallen im Detail: Die häufigsten Ursachen in der Praxis
Wenn Interconnect stabil ist, sind Policy-Probleme häufig der nächste große Block. Im Peering-Umfeld treten einige Fehler wiederholt auf.
Max-Prefix und Schutzmechanismen
- Symptom: Session bleibt up oder wird reset; plötzlich fehlen viele Routen.
- Ursache: Max-Prefix greift oder Threshold überschritten; Routen werden verworfen oder Session wird geschützt.
- Beweis: Route-Count-Events und Logs, die Max-Prefix-Auslösung zeigen.
RPKI/IRR-Filtering
- Symptom: bestimmte Präfixe fehlen dauerhaft, oft selektiv.
- Ursache: RPKI-Invalid wird gedroppt oder IRR-Filter matchen nicht.
- Beweis: Validation-Status je Präfix, Filterhit-Counter, Vergleich „advertised vs. accepted“.
Für RPKI als Konzept und Einsatz im Routing-Ökosystem ist MANRS als praxisnahe Quelle hilfreich (Policy- und Operational Best Practices, ohne vendor-spezifisch zu sein).
Attribute-Fehler: LocalPref, MED, Communities
- Symptom: Traffic nimmt plötzlich teure/unerwünschte Pfade, obwohl Session ok ist.
- Ursache: falsche LocalPref-/Community-Policy, MED unerwartet berücksichtigt, AS-PATH-Prepending falsch.
- Beweis: Best-Path-Entscheidung pro betroffenem Präfix plus Policy-Diff im Change-Fenster.
Next-Hop-/Recursive-Resolution-Probleme
- Symptom: Route ist im BGP-RIB sichtbar, aber nicht im FIB oder nicht erreichbar.
- Ursache: Next Hop ist nicht rekursiv auflösbar, IGP/Static fehlt, oder Next-Hop-Tracking bricht.
- Beweis: „RIB vorhanden, FIB fehlt“ plus Next-Hop-Reachability und IGP/Static-Nachweis.
Congestion-Fallen im Detail: Warum „Link nicht voll“ trotzdem droppen kann
Congestion ist nicht gleich „Durchschnittsauslastung 100%“. Besonders im Backbone sind Mikrobursts und Queue-Design entscheidend. Ein Link kann im 1-Minuten-Average bei 40% liegen und trotzdem im Millisekundenbereich überlaufen.
Mikrobursts und Queue Drops
- Symptom: kurze Loss-Spikes, TCP Retransmissions, „spiky latency“, schwer reproduzierbar.
- Ursache: Bursty Traffic, Shaping-Interaktion, Buffergrenzen, Incast/elephant flows.
- Beweis: High-Resolution-Telemetrie (sub-second), Queue Drop Counter, ggf. ECN-Marks.
Asymmetrische Congestion
- Symptom: nur inbound oder nur outbound betroffen; Kunden sehen „download langsam“, upload ok (oder umgekehrt).
- Ursache: unterschiedliche Kapazität, Policers, Peering-Ratio-Policies, oder ungleiche Traffic-Verteilung.
- Beweis: getrennte Auslastungs- und Drop-Counter je Richtung, getrennte Probe-Resultate.
Loss-Rate als minimaler Beweis (MathML)
Interconnect-Fallen im Detail: Wenn Layer 1 „halb kaputt“ ist
Interconnect-Probleme sind oft nicht „link down“, sondern Degradation: CRCs, FEC-Korrekturen, Optik-Power am Rand, flappende LAG-Member oder ein einzelner fehlerhafter Patch. Das erzeugt Loss, der wie Congestion wirkt, aber nicht lastkorreliert ist.
- Symptom: Drops/Errors steigen ohne Auslastungspeak.
- Symptom: BGP flapped, aber nicht regelmäßig; Keepalives gehen verloren.
- Beweis: Error-Counter-Zeitreihe + optische Telemetrie + LACP-Member-Events.
MTR/Traceroute richtig einordnen: Warum „Loss am Hop“ nicht automatisch Congestion ist
Viele Eskalationen basieren auf MTR-Ausgaben. Operativ wichtig ist: Loss, der nur als ICMP-Reply-Loss auf einem Hop erscheint, beweist keinen Data-Plane-Loss. Viele Router priorisieren ICMP niedrig oder rate-limiten es. Aussagekräftiger ist Loss, der sich bis zum Ziel fortsetzt oder der in Datenebenen-Countern (Queue Drops) sichtbar wird.
- Best Practice: MTR nur als Hinweis nutzen, dann mit Interface-/Queue-Telemetrie und End-to-End-Probes verifizieren.
- Best Practice: Ziel-Loss (end-to-end) und zeitliche Korrelation sind stärker als Hop-Loss.
Evidence Pack: Pflichtdaten für Peer-/Carrier-Eskalation
Wenn Sie Interconnect-, Policy- oder Congestion-Cases eskalieren, entscheidet ein gutes Evidence Pack darüber, ob Sie schnell Hilfe bekommen. Diese Daten sind in der Praxis „Pflicht“:
- Zeitfenster (UTC): Start, Peak, aktuelle Lage, ggf. Change-Zeitpunkt.
- Peering-Identität: Peer-ASN, Sessions (v4/v6), Interface/LAG, Standort/IXP, IPs (sofern zulässig).
- Session-Health: Uptime, Flap-Historie, Notifications/Errors, Graceful Restart Events.
- Route-Health: accepted/advertised prefix counts, Max-Prefix-Status, betroffene Präfixe (Beispiele).
- Policy-Indizien: Änderungen an Communities/LocalPref/MED, Filterhit-Counter, RPKI/IRR Status.
- Interconnect-Health: CRC/FEC/Discards, LACP-Member-Flaps, Optik-Telemetrie, MTU-Indizien.
- Congestion-Health: Auslastung (Peaks), Queue Drops, Policer/Shaper Counters, Richtungssicht.
- End-to-End-Probes: Messungen zu ausgewählten Zielen (Loss/Latency), getrennt nach v4/v6 wenn relevant.
Entscheidungslogik: Interconnect, Policy oder Congestion als „Beweisstatement“ formulieren
Für interne RCAs und externe Eskalationen hilft eine standardisierte Aussageform, die Ursache nicht nur benennt, sondern beweisbar macht.
Beweisstatement für Interconnect
„Im Zeitraum X zeigen Interface-/Optik-/LAG-Telemetrie steigende Errors und Member-Flaps am Peering-Port. BGP-Flaps korrelieren zeitlich mit diesen Events. End-to-End-Probes zeigen Loss ohne Auslastungskorrelation. Damit ist Interconnect als primäre Fault Domain belegt.“
Beweisstatement für Policy
„BGP-Session ist stabil, Underlay/Interconnect ist fehlerfrei. Nach Change/Ereignis Y sinkt die accepted-prefix-count um Z, betroffene Präfixe fehlen im RIB/FIB bzw. werden durch Filter/RPKI als invalid verworfen. Das belegt ein Policy-/Routing-Problem.“
Beweisstatement für Congestion
„Loss/Latency-Spitzen korrelieren zeitlich mit Auslastungspeaks und steigenden Queue Drops/Policer-Countern am Peering-Link. Das Verhalten ist lastabhängig und verschwindet off-peak. Damit ist Congestion als primäre Ursache belegt.“
Outbound-Ressourcen
- RFC 4271 (BGP-4)
- RFC 7606 (Revised Error Handling for BGP UPDATE Messages)
- RFC 4724 (Graceful Restart Mechanism for BGP)
- RFC 5880 (BFD für schnelle Failure Detection)
- RFC 9293 (TCP, relevant für Keepalive-/Retransmission-Interpretation)
- MANRS (Routing-Security und Operational Best Practices)
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.
