Zusammenfassung

  • RFC 9736 trennt Peer-Up- und Initiation-TLVs und verlangt, die Reihenfolge wiederholter String-TLVs zu erhalten. Geklärt wird die Code-Zuständigkeit, nicht das Verhalten installierter Software.
  • Belastbare Aussagen brauchen eine Belegkette vom Register und der Sender-Version über Wire Bytes, Parser und Speicherung bis zu Session, Route, Forwarding, Maßnahme und Ergebnis.

Zwei Kontexte brauchen zwei Nummernräume

Initiation beschreibt das überwachte System, Peer Up eine BGP-Sitzung. RFC 7854 ließ beide dennoch denselben Information-TLV-Namensraum verwenden. Mit jeder Erweiterung wurde diese Abkürzung problematischer: Ein Type Code hatte ohne den umgebenden Nachrichtentyp keinen eindeutigen Besitzer.

RFC 9736 trennt die Register. Das bestehende wird zu BMP Initiation Information TLVs, daneben entsteht BMP Peer Up Message TLVs. Bei Initiation bleiben String als Type 0, sysDescr als Type 1 und sysName als Type 2. Bei Peer Up gelten String als Type 0, VRF/Table Name als Type 3 und Admin Label als Type 4. Die jeweils anderen Codes sind reserviert.

Auch die Binärregeln sind präzise. Ein String ist eine UTF-8-Folge, deren Ende das Length-Feld bestimmt; ein Nullzeichen ist nicht erforderlich. Peer-Up-Information ist optional und über Message Length erkennbar. String darf mehrfach vorkommen, und der Empfänger muss die Reihenfolge beim Berichten erhalten. Wer mehrere Werte in eine einzelne Datenbankspalte presst, hat den Nachweis verändert, obwohl der Datensatz plausibel aussieht.

Normative Kompatibilität ist kein Release-Inventar

Der RFC sagt, dass konforme Implementierungen der RFCs 7854, 8671 und 9069 auch RFC 9736 entsprechen. Das ordnet bereits definierte Peer-Up-Typen rückwirkungsfrei dem neuen Register zu. Es zertifiziert kein Produkt und keine installierte Version.

Ein Collector kann nur den letzten wiederholten String speichern. Er kann Type 3 erkennen und trotzdem den Tabellennamen dem falschen emulierten Loc-RIB-Peer zuordnen. Er kann einen künftigen unbekannten Typ still verwerfen. IANA kann in allen drei Fällen korrekt sein, während die lokale Beweiskette bricht.

Darum beginnt die Prüfung vor dem Decode. Zu sichern sind die genauen Peer-Up-Bytes, BMP-Session, Sender-Build und -Konfiguration, Message Length und TLV-Reihenfolge. Die Aufnahme wird an Collector-Build, Parser-Schema, Längenprüfung und Unknown-Type-Policy gebunden. Anschließend werden Raw-Ingest, decodiertes Objekt und persistierter Datensatz verglichen. Ohne Original lässt sich nicht entscheiden, ob ein Wert auf dem Draht fehlte oder im Pipeline-Schritt verschwand.

Peer Up ist nicht Feed-Vollständigkeit

Nach RFC 7854 berichtet Peer Up den Übergang einer überwachten BGP-Sitzung zu Established und enthält beide OPEN-Nachrichten sowie TCP-Informationen. Beim Start einer BMP-Session wird Peer Up jedoch auch für bereits etablierte Peers gesendet. Die Ankunftszeit ist deshalb nicht automatisch die Entstehungszeit der BGP-Sitzung.

RFC 8671 trennt Peer Up/Down ausdrücklich davon, ob Route Monitoring oder Route Mirroring für Adj-RIB-In oder Adj-RIB-Out gesendet wird. Initiation, Peer Up, initialer RIB-Dump, End-of-RIB und inkrementelle Updates sind unterschiedliche Nachweise. Eine gültige Peer-Up-Meldung beweist keine vollständige Route-Sicht.

RFC 9069 modelliert Loc-RIB über emulierte Peers, möglicherweise mehrere je Tabelle und Adressfamilie. VRF/Table Name hilft, ist aber keine globale Identität. Peer Distinguisher, BGP ID und OPEN Capabilities müssen ebenfalls passen.

Die operative Belegkette

Ein belastbarer Vorgang nennt Registerstand, Sender-Build, BMP-Session und Peer-Epoche, Wire Bytes, Parser-Version, Unknown-Policy, Raw- und Decode-Beleg, Session-Korrelation, Feed-Abdeckung, RIB/FIB- oder aktive Beobachtung, autorisierte Maßnahme und unabhängiges Ergebnis.

Die Kette darf bei „unbekannt“ enden. Peer Up kann einen Session-Bericht belegen, ohne Routenannahme zu belegen. Ein vollständiger Feed kann das Hardware-Forwarding offenlassen. Forwarding kann den Geschäftseffekt offenlassen. RFC 9736 stärkt den Anfang; professionelle Kontrolle verhindert, dass daraus ein Urteil über das Ende wird.