BGP-Monitoring: Sessions, Prefixes und Anomaly Detection

BGP-Monitoring ist für Provider, Carrier und größere Enterprise-Netze eine Kernfunktion, weil BGP nicht nur „ein Routing-Protokoll“ ist, sondern die Verkehrslenkung, Verfügbarkeit und Stabilität vieler Dienste bestimmt. In der Praxis scheitern Incidents selten daran, dass BGP „komplett ausfällt“, sondern daran, dass sich das Routing schleichend verändert: Sessions flappen sporadisch, Prefixes fehlen nach einem Policy-Change, ein Route Leak lässt Prefix Counts explodieren, oder ein einzelner Upstream liefert plötzlich instabile Updates (Churn). Genau hier setzt modernes BGP-Monitoring an: Es verbindet Session-Health (Transport vs. Control Plane), Routing-Inhalte (received/accepted/advertised Prefixes, Attribute, Best Path) und Anomaly Detection (Abweichungen gegenüber Baselines). Damit können Sie nicht nur Ausfälle schneller erkennen, sondern auch proaktiv verhindern, dass kleine Unregelmäßigkeiten zu großflächigen Outages werden. Dieser Artikel zeigt praxisnah, wie Sie BGP-Monitoring aufbauen: Welche Signale wirklich zählen, wie Sie sinnvolle Schwellenwerte definieren, wie Sie False Positives vermeiden und wie Sie aus Alarmen ein „evidence-based“ Runbook machen, das im NOC in Minuten zu einer belastbaren Diagnose führt.

Warum „Session up“ kein ausreichendes BGP-Monitoring ist

Viele Monitoring-Setups beginnen und enden mit „BGP Session Established“. Das ist ein notwendiger, aber nicht hinreichender Zustand. Eine Session kann stabil sein, während die Datenebene (Interconnect, MTU, Congestion) degradiert, oder während Policy-Änderungen dazu führen, dass wichtige Prefixes nicht mehr akzeptiert werden. Umgekehrt kann eine Session flappen, ohne dass Kunden etwas merken, wenn Redundanzen sauber greifen. Professionelles BGP-Monitoring muss deshalb drei Perspektiven zusammenführen:

• Sessions: Ist die Nachbarschaft stabil und warum (Transport vs. Config vs. CPU/CoPP)?
• Prefixes: Welche Routen werden empfangen, akzeptiert und angekündigt – und ist das im erwarteten Band?
• Anomalien: Welche Abweichungen deuten auf Hijacks, Leaks, Instabilität oder drohende Congestion hin?

Für BGP-Grundlagen ist RFC 4271 die Referenz. Für robustes Fehlermanagement bei BGP UPDATEs ist RFC 7606 hilfreich, weil es beschreibt, wie man Fehler behandelt, ohne die gesamte Session unnötig zu resetten.

Baustein 1: Session-Monitoring richtig aufsetzen

Session-Monitoring beantwortet die Frage: Ist die BGP-Nachbarschaft stabil, und wenn nicht, ist die Ursache eher Transport (L1/L2/L3), Konfiguration/Policy oder Ressourcen (CPU, CoPP, Control Plane)?

Pflichtsignale für BGP Sessions

• State: Established/Idle/Active/Connect und State-Transitions.
• Uptime: Zeit seit letztem Establish; kurze Uptime ist ein Warnsignal.
• Flap-Rate: Anzahl Resets pro Zeitfenster (z. B. 1h/24h/7d).
• Notifications: letzte BGP NOTIFICATION-Codes (wenn vorhanden) als schneller Hinweis auf Config/Policy/Update-Probleme.
• Keepalive/Hold Timer Events: Indiz, ob Pakete nicht ankamen (Transport oder CPU).
• Transport-Indizien: Interface Errors, LACP Member Flaps, CRC/FEC, Queue Drops, TCP Retransmissions (wenn messbar).

Flap-Rate als einfache Alarmmetrik (MathML)

$\mathrm{FlapRate}=\frac{\mathrm{session\_resets}}{\mathrm{time\_window}}$

Wichtig: Flap-Rate muss immer mit Transport- und Control-Plane-Signalen korreliert werden. Ein „BGP reset“ kann durch TCP-Probleme, MTU-Fragmentation, CoPP-Drops oder Policy-Fehler ausgelöst werden. Ohne Korrelation entstehen schnell falsche Tickets („Peer kaputt“) oder unnötige Eskalationen.

Transport vs. Config: Die schnellste Triage-Regel

• Transport-Verdacht: Neighbor-IP nicht stabil erreichbar, Interface/Optik-Errors, LACP flaps, zeitgleiche Packet Loss-Spikes.
• Config/Policy-Verdacht: Session bleibt in Active/Connect, Auth/TTL/Source-IP falsch, NOTIFICATION deutet auf Parameter- oder Update-Problem hin.
• Ressourcen-Verdacht: CPU-Spikes, Control Plane Policing greift, viele Sessions flappen gleichzeitig.

Baustein 2: Prefix-Monitoring für Routing-Integrität

Prefix-Monitoring ist der Teil, der die meisten „schleichenden“ Incidents früh sichtbar macht. Es misst nicht nur „wie viele Routen“, sondern auch „welche Routen“ und „mit welchen Eigenschaften“. Im Provider-Betrieb sind drei Zähler entscheidend:

• Received Prefixes: Routen, die vom Nachbarn geliefert werden (pre-policy).
• Accepted/Installed Prefixes: Routen, die nach Import-Policy akzeptiert werden (post-policy).
• Advertised Prefixes: Routen, die Sie an den Nachbarn announcen (post-export-policy).

Diese Trennung ist operativ Gold wert: Wenn received stark steigt, accepted aber stabil bleibt, haben Sie vermutlich korrekt gefiltert (Nachbar hat ein Problem). Wenn advertised unerwartet steigt, droht ein Leak aus Ihrem Netz.

Prefix-Delta und relative Abweichung (MathML)

$\Delta P=P\_\mathrm{current}-P\_\mathrm{baseline}$
$\mathrm{RelDev}=\frac{\mathrm{|\Delta P|}}{P\_\mathrm{baseline}}$

Baselines: Damit Prefix-Monitoring nicht zum Alarmrauschen wird

Prefix Counts schwanken in der Realität. Deaggregation bei DDoS-Mitigation, Policy-Änderungen bei Peers, Wartungen und Session-Resets erzeugen natürliche Bewegungen. Deshalb sind Baselines und Schwellenwerte entscheidend. Bewährte Prinzipien:

• Median statt Mittelwert: robuster gegen Ausreißer.
• Getrennt nach Rolle: Customer/Peer/Transit haben völlig unterschiedliche „Normalwerte“.
• Dual Stack separat: IPv4 und IPv6 getrennt monitoren (Counts und Anomalien unterscheiden sich stark).
• Absolute + relative Schwellen kombinieren: verhindert Overreaction bei kleinen Sessions und Underreaction bei großen.

Kombinierte Alarmbedingung (MathML)

$\mathrm{Alert}\Leftarrow \mathrm{|\Delta P|}\ge P\_\mathrm{abs}\wedge \mathrm{RelDev}\ge P\_\mathrm{rel}$

Prefix-Inhaltschecks: „Welche“ Routen fehlen oder sind neu?

Counts sind schnell, aber Inhalte sind der Beweis. Ein gutes Monitoring liefert bei Alarmen automatisch Beispiele:

• Top-N neue Prefixes: Welche Routen sind plötzlich hinzugekommen?
• Top-N verlorene Prefixes: Welche kritischen Präfixe sind verschwunden?
• Origin-AS Wechsel: Hat sich das Origin-AS für bekannte Prefixes geändert (Hijack-Indiz)?
• More-specific Flut: Ungewöhnlich viele /24 (v4) oder /48-/64 (v6) können Leak-/DDoS-Mitigationsignaturen sein.

Für RPKI-basierte Origin Validation ist RFC 6811 relevant. Wenn Sie RPKI einsetzen, sollten Sie Invalid/NotFound/Valid-Quoten in Ihr Prefix-Monitoring integrieren, um Hijacks und Fehl-ROAs früh zu erkennen.

Baustein 3: Anomaly Detection – welche Anomalien wirklich zählen

Anomaly Detection im BGP-Kontext bedeutet nicht zwingend „KI“. In der Praxis reichen robuste Heuristiken, wenn sie auf die richtigen Signale angewendet werden. Wichtig ist, dass Anomalien nicht nur gemeldet werden, sondern als Hypothese in ein Runbook übersetzbar sind.

Anomalieklasse 1: Route Leak Indizien

• Prefix Count Spike bei Customer: received/accepted springt massiv nach oben.
• Advertised Spike zu Peer/Transit: Sie kündigen plötzlich viel mehr an (Outbound-Leak-Risiko).
• Churn steigt: Update-/Withdraw-Rate explodiert (Leak kann Storms auslösen).

Für rollenbasierte Leak-Prävention und -Erkennung ist RFC 9234 eine nützliche Referenz, weil es BGP-Rollen als operatives Modell etabliert.

Anomalieklasse 2: Hijack-Indizien

• Origin-AS Änderung: bekannter Prefix erscheint plötzlich mit anderem Origin.
• RPKI Invalid Spike: Anteil „Invalid“ steigt, besonders für hochwertige/geschäftskritische Prefixes.
• Unerwartete More-specifics: plötzlich viele spezifischere Routen zu einem bekannten Aggregat.

Als praxisnahe Orientierung für Routing-Security und organisatorische Mindeststandards eignet sich MANRS.

Anomalieklasse 3: Instabilität und Churn

Churn ist oft der Vorläufer von größeren Problemen: Session flaps, Peering-Fehler, IGP-Stürme, Control-Plane-Überlast. Deshalb ist Update-/Withdraw-Rate eine Pflichtmetrik.

• Update Rate: ungewöhnlich viele Updates pro Minute.
• Withdraw Rate: massenhaft Withdraws (Upstream-Event, Filter greift, Session reset).
• Best-Path Flaps: ein Prefix wechselt häufig den Next Hop (führt zu Traffic Instabilität).

Churn-Rate als einfache Metrik (MathML)

$\mathrm{ChurnRate}=\frac{\mathrm{updates}+\mathrm{withdraws}}{\mathrm{time\_window}}$

Anomalieklasse 4: Congestion- und Pfadshift-Indizien

BGP ist indirekt auch ein Congestion-Detektor, weil Routing-Änderungen Traffic verschieben. Ein Monitoring, das nur BGP betrachtet, sieht jedoch nicht, ob der neue Pfad überlastet ist. Deshalb sollten Sie BGP-Anomalien immer mit Interface-/Queue-Telemetrie und synthetischen Probes koppeln.

• Pfadwechsel: Best Path für wichtige Prefixes ändert sich ohne geplanten Change.
• Traffic-Shift: Auslastung springt auf bestimmten Peering-/Transit-Links.
• QoE-Indizien: Latenz/Loss-Probes verschlechtern sich zeitgleich.

Praktisches Alerting: Alarmregeln, die im NOC funktionieren

Alarmregeln müssen handlungsfähig sein. Zu viele Alarme erzeugen Noise und werden ignoriert. Bewährte Kategorien:

• Sev-1 (sofort): Session down bei Single-Homed Peer/Transit, advertised Spike (Outbound-Leak-Verdacht), RPKI Invalid Spike für kritische Prefixes.
• Sev-2 (zeitnah): Prefix Count Delta > Schwelle, Churn Spike, wiederholte Session Flaps.
• Sev-3 (beobachten): moderate Baseline-Abweichungen, die sich stabilisieren, oder NotFound/Valid-Quoten-Trends.

Runbook: Von Alarm zu Diagnose in Minuten

Ein gutes BGP-Monitoring liefert nicht nur „rot“, sondern eine strukturierte Triage. Dieser Ablauf ist praxistauglich und skaliert.

Schritt: Session oder Prefix?

• Session alarmiert: State/Flaps/Notifications → Transport vs. Config vs. Ressourcen trennen.
• Prefix alarmiert: received/accepted/advertised Delta → Leak/Hijack/Policy-Fehler differenzieren.

Schritt: Rolle der Session berücksichtigen

• Customer: Prefix Spike ist hochverdächtig (Leak), strenge Filter/Max-Prefix prüfen.
• Peer: advertised Spike ist kritisch (Outbound-Leak-Risiko), Import-/Export-Policy prüfen.
• Transit: Churn und Pathshift stärker gewichten; Prefix Count schwankt stärker.

Schritt: Evidence automatisch anreichern

• Top-N Beispiele: neue/verlorene Prefixes, Origin-AS Änderungen, auffällige AS-PATHs.
• Policy-Indizien: Max-Prefix Events, RPKI Invalid/NotFound/Valid Quoten.
• Transport-Indizien: Interface Errors/Drops, LACP Member Issues, Queue Drops.

Schritt: Mitigation-Optionen vorbereiten

• Leak-Containment: Ingress-Filter schärfen, Max-Prefix senken, Export begrenzen.
• Hijack-Reaktion: RPKI Enforcement/Depräferenz, Kommunikation mit Upstreams/Peers, betroffene Prefixes schützen.
• Instabilität: Ursache suchen (Transport/CPU/Policy), unnötige Session-Resets vermeiden, Churn eindämmen.

Tooling: Woher die Daten kommen können

Die Umsetzung hängt von Ihrer Umgebung ab, aber die Datenquellen sind oft ähnlich:

• Router Telemetry: BGP neighbor stats, prefix counters, update counters, notifications.
• Streaming Telemetry: schnellere, hochauflösende Zähler für Churn und Prefix Deltas.
• Route Collectors: unabhängige Sicht auf BGP (intern/extern), hilfreich zur Verifikation von Leaks/Hijacks.
• Flow Monitoring: Traffic Shift und Impact (NetFlow/IPFIX), um BGP-Anomalien mit Kundenauswirkungen zu koppeln.

Als allgemein zugängliche, praxisnahe Referenz zum Peering-Ökosystem und zur Planung von Peerings eignet sich PeeringDB. Für IX- und Peering-Best-Practices ist Euro-IX eine hilfreiche Quelle.

Häufige Fehler im BGP-Monitoring und wie Sie sie vermeiden

• Nur Session-State überwachen: Prefixes und Churn fehlen → Leaks/Hijacks bleiben unentdeckt.
• Keine Baselines: jede normale Schwankung wird Alarm → Alert-Fatigue.
• Keine Rollenlogik: gleiche Schwellen für Customer und Transit → entweder zu empfindlich oder zu blind.
• Keine Beispiele im Alarm: NOC muss erst manuell suchen → MTTR steigt.
• Keine Korrelation: BGP-Anomalien ohne Interface-/Queue-/Probe-Daten → falsche Root-Cause-Hypothesen.

Outbound-Ressourcen

• RFC 4271 (BGP-4)
• RFC 7606 (BGP UPDATE Error Handling)
• RFC 6811 (BGP Prefix Origin Validation, RPKI)
• RFC 8210 (RPKI-to-Router Protocol, RTR)
• RFC 9234 (Route Leak Prevention and Detection Using Roles in BGP)
• MANRS (Routing Security Best Practices)
• PeeringDB (Peering- und ASN-Informationen)
• Euro-IX (Wissen rund um Internet Exchanges)

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.