Peering-Incident: Sicherstellen, ob das Problem im Interconnect oder Transit liegt

Ein „Peering-Incident“ wirkt im NOC oft wie ein einziges Symptom („Kunde erreicht Ziel X nicht“), kann aber zwei sehr unterschiedliche Ursachen haben: ein Problem im Interconnect (also am direkten Peering-Link, am IX-Port, am Cross-Connect, am L2/L3-Edge) oder ein Problem im Transit (Upstream-Path, Provider-Core, Remote-Policy, externe Störung außerhalb des direkten Peering-Pfads). Genau hier entscheidet sich, ob Sie mit dem IX-Partner/Peer sprechen müssen, ob ein Transit-Provider betroffen ist oder ob Sie intern am Edge nachschärfen (Routing-Policy, MTU, Congestion, QoS, DDoS-Mitigation, Optik). Der Kern einer sauberen Analyse ist daher nicht „mehr Tools“, sondern ein reproduzierbares Vorgehen, das die Frage schnell beantwortet: Ist der Fehler auf dem direkten Peering-Pfad sichtbar – oder erst jenseits davon? In diesem Artikel erhalten Sie ein praxisnahes Playbook, um bei einem Peering-Incident belastbar festzustellen, ob das Problem im Interconnect oder im Transit liegt. Sie lernen, wie Sie Symptome strukturiert aufnehmen, welche Messpunkte Sie an Edge und Route-Policy prüfen, wie Sie mit mehreren Vantage Points Beweise sammeln und wie Sie aus BGP-, Interface- und Traffic-Signalen eine klare Entscheidung ableiten, ohne sich in Vermutungen zu verlieren.

Begriffe sauber trennen: Peering, Interconnect und Transit im Incident-Kontext

Im Alltag werden „Peering-Probleme“ oft unscharf beschrieben. Für eine schnelle Isolation braucht es klare Begriffe:

• Interconnect: die physische und logische Verbindung zum Peer, z. B. Cross-Connect, IX-Port, LAG, VLAN/PNI, BGP-Session am Edge. Alles bis einschließlich Ihrer und der Peer-Routerports.
• Peering-Pfad: der Verkehr, der aufgrund Ihrer Routing-Policy über den Peer läuft (meist direkt, ohne Transit).
• Transit: Upstream-Provider, der Internet-Routing bereitstellt; Probleme können in dessen Netz, dessen Peers oder weiter im Internet liegen.

Für die BGP-Grundlagen ist RFC 4271 (BGP-4) die zentrale Referenz. Der Incident-Mehrwert entsteht jedoch durch Betriebsdisziplin: Welche Daten beweisen „Interconnect“ und welche beweisen „Transit“?

Symptomaufnahme: Welche Signale sind typisch für Interconnect vs. Transit?

Bevor Sie messen, müssen Sie das Symptom präzisieren. Drei Symptomklassen reichen oft, um den Suchraum drastisch zu verkleinern:

• Reachability-Ausfall: Ziel-Prefixe sind gar nicht erreichbar (Timeout), oft selektiv (nur bestimmte Destinationen/ASNs).
• Degradation: hohe Latenz, Jitter oder Packet Loss, häufig zeitabhängig (Peak-Zeiten).
• Asymmetrie: Hinweg und Rückweg verhalten sich unterschiedlich (z. B. nur Inbound oder nur Outbound betroffen).

Typische Muster:

• Interconnect-indikativ: BGP-Session flappt, Interface-Errors steigen, Drops/Discards am Peering-Port, Probleme betreffen viele Ziele hinter dem Peer gleichzeitig, oder es gibt klare Kapazitäts-/Congestion-Signale am direkten Link.
• Transit-indikativ: BGP-Session zum Peer ist stabil, lokale Port-Telemetrie ist sauber, aber bestimmte AS-Pfade sind kaputt; andere Pfade funktionieren; Probleme treten „hinter“ dem Peer/Upstream auf (z. B. nur Ziele in einer Region).

Schritt 1: Interconnect-Baseline prüfen (L1/L2/L3 am Peering-Port)

Der schnellste Gewinn kommt aus einer harten Baseline am Interconnect. Ziel ist eine klare Aussage: „Der Port und die direkte Nachbarschaft sind gesund“ oder „hier ist bereits der Fehler sichtbar“.

Physik und Linkzustand (L1)

• Port up/down und Flap-Historie: wiederkehrende Flaps sprechen stark für Interconnect-Probleme (Optik, Patch, Cross-Connect, LAG-Member).
• Errors und Signalqualität: CRC, FCS, Symbol Errors, Rx/Tx-Power (bei Optik), LOS/LOF-Meldungen.
• Lane- und FEC-Indikatoren: bei 100G/400G können Vorfehler (Pre-FEC) frühe Degradation anzeigen, bevor der Link „down“ geht.

Layer 2/Interface-Hygiene

• MTU und Encapsulation: Mismatches führen zu „Ping geht, Applikation nicht“; prüfen Sie End-to-End-MTU bis zum Peer.
• LAG/LACP (falls vorhanden): Member-Status, ungleich verteilte Errors, Hash-Imbalance und Member-Flaps.
• Queueing und Drops: Output Drops, Tail Drops, WRED/ECN (falls aktiv), Discards durch Policers oder Shaping.

Layer 3 und unmittelbarer Nachbar

• ARP/ND-Stabilität: häufige ARP/ND-Neulernvorgänge können auf L2-Probleme oder Filter hindeuten.
• ICMP/PMTUD-Signale: fehlende ICMP-Fragmentation Needed (oder IPv6 Packet Too Big) kann MTU-Probleme verschleiern.

Schritt 2: BGP-Session ist nicht gleich „Routing ist gesund“

Viele Incidents werden falsch eingeordnet, weil „BGP ist up“ als Entwarnung gilt. Für die Interconnect-vs-Transit-Frage sind mindestens vier BGP-Sichten relevant:

• Session Health: Establishment, Flaps, Hold Timer Expired, TCP-Retransmits.
• Prefix-Counts: plötzliche Einbrüche oder Spikes (Max-Prefix-Events) sind starke Indikatoren für Policy- oder Leak-Probleme.
• Best-Path-Änderungen: hat sich LocalPref, AS-Path oder MED verändert? Laufen betroffene Ziele plötzlich über einen anderen Exit?
• Export-/Import-Policy: was senden Sie an den Peer, was akzeptieren Sie? Ein „leises“ Policy-Problem kann wie ein Transit-Ausfall aussehen.

Als Hintergrund zu Route-Leaks ist RFC 7908 nützlich, weil es typische Leak-Klassen beschreibt, die im Incident schnell geprüft werden können.

Schritt 3: Pfad-Beweise sammeln – mit mehreren Vantage Points

Um sicher zu unterscheiden, ob der Fehler am Interconnect oder jenseits davon liegt, brauchen Sie Pfadbeweise. Eine einzelne Traceroute reicht selten, weil Rückwege, ICMP-Policy und Anycast zu Fehlinterpretationen führen. Bewährt haben sich drei Perspektiven:

• Von innen nach außen: Traceroute/Paris-Traceroute aus Ihrem Netz (mehrere PoPs) zu betroffenen Zielen.
• Von außen nach innen: Messungen aus externen Sonden/Looking-Glasses in Richtung Ihrer Prefixes.
• Control-Plane-Sicht: BGP-Routing-Informationen aus Route-Views/Collectors (wie sieht die Welt Ihren Pfad?).

Für externe Messpunkte sind RIPE Atlas und öffentliche Looking-Glass-Übersichten in der Praxis besonders hilfreich, weil Sie unabhängig von Kundenendgeräten testen können.

Interconnect-typische Failure Modes: Wie sie sich in Daten zeigen

Wenn das Problem im Interconnect liegt, sehen Sie es oft in unmittelbarer Nähe Ihrer Edge-Interfaces oder in symmetrischen Mustern über viele Ziele hinter dem Peer.

Kapazitätsengpass oder Congestion am Peering-Link

• Hohe Auslastung nahe Line Rate: korreliert mit Loss/Jitter in Peak-Zeiten.
• Output Drops / Queue Drops: steigen zeitgleich mit Kundenbeschwerden.
• Nur Peering-Traffic betroffen: Ziele hinter dem Peer degradieren; Transit-Ziele bleiben stabil.

Ein praktischer Loss-Indikator über ein Zeitfenster lässt sich aus Countern ableiten:

$\mathrm{Loss}\_\mathrm{Rate}=\frac{\mathrm{Drops}+\mathrm{Discards}}{\mathrm{Packets}\_\mathrm{Out}}$

Wenn dieser Wert am Peering-Port signifikant ansteigt und zeitlich mit der Degradation korreliert, ist „Interconnect“ als Ursache sehr wahrscheinlich.

Optik-/L1-Degradation ohne harten Link-Down

• CRC/FCS steigt langsam: Symptome wirken wie „random loss“ oder „sporadische Timeouts“.
• FEC-Korrekturwerte steigen: Vorstufe eines späteren Totalausfalls.
• Nur ein LAG-Member auffällig: erzeugt intermittierende Probleme, obwohl Bundle „up“ bleibt.

MTU-/PMTUD-Probleme am Übergang

• Kleine Pakete ok, große brechen: z. B. TCP-Handshake ok, aber Downloads hängen.
• ICMP gefiltert: PMTUD kann nicht funktionieren; Symptome ähneln Congestion.

Transit-typische Failure Modes: Hinweise jenseits des direkten Peers

Wenn Interconnect-Telemetrie sauber ist, BGP stabil bleibt und dennoch Ziele nicht erreichbar sind, rückt Transit/Remote-Path in den Fokus. Typische Muster:

• Nur bestimmte Ziel-ASNs/Regionen betroffen: deutet auf ein Problem in einem entfernten Segment oder einem spezifischen Upstream-Pfad hin.
• Pfadwechsel verbessert/verschlechtert das Problem: alternative Exits (anderer Transit, anderer Peer, anderer IX) zeigen sofort Unterschiede.
• Inbound-Asymmetrie: Outbound funktioniert, Inbound kommt über einen kaputten Pfad zurück (oder umgekehrt).

Hier helfen BGP- und Pfadanalysen: AS-Path-Änderungen, neue Origin-AS, RPKI-Invalids oder plötzlich andere Next-Hops. Für Origin-Validierung ist RFC 6811 eine etablierte Referenz.

Entscheidungslogik: Interconnect oder Transit – ein belastbares Raster

Statt „Gefühl“ empfiehlt sich ein Raster aus Beweisen. Je mehr Kriterien einer Seite erfüllen, desto höher die Sicherheit.

• Interconnect sehr wahrscheinlich, wenn:
  • Interface-Errors/Drops am Peering-Port steigen.
  • BGP-Session flappt oder zeigt TCP-Retransmits/Keepalive-Probleme.
  • Viele Ziele hinter dem Peer gleichzeitig betroffen sind.
  • Problem verschwindet beim Umrouten auf anderen Interconnect (z. B. anderer IX-Port/PNI zum selben Peer).
• Transit sehr wahrscheinlich, wenn:
  • Peering-Port ist sauber (Errors/Drops unauffällig), BGP stabil.
  • Nur bestimmte Ziel-ASNs/Prefix-Gruppen betroffen.
  • Traceroutes zeigen Probleme erst nach dem Peer/Upstream-Hop.
  • Mehrere unabhängige externe Messpunkte bestätigen den Fehler in einer bestimmten AS-Region.

Pfad-Experiment: Traffic kontrolliert umleiten, um Hypothesen zu testen

Wenn Sie über mehrere Exits verfügen, ist ein kontrolliertes Pfad-Experiment eines der stärksten Diagnosemittel. Ziel ist nicht „Dauerlösung“, sondern Beweisführung:

• Outbound-Test: ändern Sie LocalPref/Communities selektiv für betroffene Prefixes, sodass Traffic über einen anderen Peer/Transit geht.
• Inbound-Test: nutzen Sie AS-Path-Prepending oder Communities an Upstreams, um Rückwege zu beeinflussen (vorsichtig und nur mit klarer Beobachtung).
• Scope klein halten: testen Sie nur eine repräsentative Präfixgruppe oder einen Teilverkehr, um Nebenwirkungen zu vermeiden.

Wichtig: Solche Tests müssen in einem Incident dokumentiert werden (Zeitpunkt, Scope, erwarteter Effekt), sonst verlieren Sie die RCA-Spur.

Kontrollplane-Signale: Route-Collectors, PeeringDB und Status-Checks

Um zu prüfen, ob ein Problem „nur bei Ihnen“ oder großflächig auftritt, helfen externe Kontrollplane- und Metadatenquellen:

• PeeringDB: validieren Sie schnell, ob Sie am richtigen Standort/IX mit dem richtigen Peer sprechen und welche Kontakt-/NOC-Informationen hinterlegt sind: PeeringDB.
• MANRS-Empfehlungen: als Best-Practice-Rahmen für Filter und Anti-Leak-Mechanismen: MANRS.
• RPKI-Validator-/Statussicht: prüfen Sie bei „invalid“/„not found“ Mustern, ob ROAs eine Rolle spielen (abhängig von Ihrer Policy).

Diese Quellen ersetzen keine Netztelemetrie, geben aber Kontext: Ist der Peer bekannt „down“? Gibt es Kontaktwege? Sind Filter- und Hygienepraktiken erwartbar?

Typische Fehler in der Incident-Analyse und wie Sie sie vermeiden

• „BGP up = alles gut“: falsch; Prefix-Counts, Best-Path und Export/Import sind genauso wichtig.
• Einzelne Traceroute überbewerten: ICMP kann gefiltert sein; nutzen Sie mehrere Vantage Points.
• MTU ignorieren: MTU-Probleme sehen aus wie Congestion; prüfen Sie systematisch PMTUD und große Flows.
• Asymmetrie vergessen: viele Peering-Probleme sind richtungsabhängig; messen Sie inbound und outbound getrennt.
• Keine Zeitkorrelation: ohne Timeline verlieren Sie Ursache-Wirkung (z. B. Peak-Congestion vs. Link-Degradation).

Minimal-Checklist für NOC und On-Call: In 10 Minuten zu einer belastbaren Aussage

• Symptom präzisieren: Ausfall, Degradation oder Asymmetrie? Welche Ziele/ASNs?
• Peering-Port prüfen: Link-Flaps, Errors, Drops, Auslastung, LAG-Member.
• BGP prüfen: Session stable? Prefix-Count verändert? Max-Prefix-Events? Best-Path-Wechsel?
• Pfad prüfen: Traceroutes aus mindestens zwei PoPs; ideal zusätzlich externe Messpunkte.
• Hypothese testen: kontrolliertes Re-Route eines kleinen Scopes, falls möglich.
• Entscheidung dokumentieren: „Interconnect“ oder „Transit“ mit den 2–3 stärksten Beweisen.

Best Practices zur Prävention: Damit Peering-Incidents seltener werden

• Max-Prefix + Warnschwellen: verhindert, dass Fehlannouncements Sessions destabilisieren.
• RPKI-Policy mit Monitoring: reduziert Origin-Hijacks, erfordert aber sauberes Rollout- und Alerting-Design.
• Kapazitäts- und Queue-Telemetrie am Interconnect: Congestion früh erkennen, bevor Kunden es tun.
• Standardisierte Communities/Policies: weniger Sonderfälle, weniger Leak-Risiko.
• Externe Vantage Points fest einplanen: RIPE Atlas-Sets oder feste Looking-Glass-Routinen im Incident-Runbook.

Outbound-Links für vertiefende Informationen

• RFC 4271: Border Gateway Protocol 4 (BGP-4)
• RFC 7908: Problemdefinition und Klassifikation von Route Leaks
• RFC 6811: BGP Prefix Origin Validation (RPKI)
• RIPE Atlas: Messplattform für externe Vantage Points
• PeeringDB: Interconnect- und Peering-Metadaten
• MANRS: Best Practices gegen Route Leaks und Routing-Incidents

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.