Zusammenfassung

  • Vier VPN-Routen mit demselben Präfix P1 treten in einem IETF-Entwurf vom 27. Oktober gegeneinander an. PE1 wählt RD22 für VPN11. Der BMP-Bericht nennt anschließend RD11 als empfangende Instanz und verliert RD22 als Herkunft der ausgewählten Route.
  • Revision 02 schlägt ein Feld für die entfernte VRF-Identität auch bei EVPN-Type-5-Routen vor. Sender und Collector können es auslassen beziehungsweise ignorieren. Wer grenzüberschreitende Routenimporte kontrollieren will, muss die Herkunft im eigenen Betrieb verbindlich machen.

Vier Bewerber für P1

Der Entwurf zeichnet ein kleines, aufschlussreiches Netz. PE2 liefert drei VPN-Routen für P1 aus RD21, RD22 und RD23; PE3 liefert eine vierte aus RD31. Alle tragen ein Route Target, das VPN11 auf PE1 zur Übernahme berechtigt. PE1 entscheidet sich im Beispiel für RD22. Der BMP-Server erhält anschließend den ausgewählten Eintrag in VPN11: P1, einen Next Hop und RD11. Die Kennung des empfangenden Fachs ist da. Die Kennung des gewählten Absenders fehlt.

Es handelt sich um ein konstruiertes Beispiel, nicht um einen bekannten Störfall. Gerade deshalb lässt sich die Aussage sauber prüfen. Die Überwachung weiß, dass P1 in VPN11 liegt. Sie kann aus diesem Datensatz nicht ablesen, ob P1 von RD21 oder RD22 kam. Beide Kandidaten stammen im Beispiel von PE2; der Next Hop ist also kein Ersatz für die Quellinstanz. Ein Bericht über den Zustand der Zieltabelle wird als Bericht über einen Übergang zwischen Instanzen ausgegeben.

Im IETF Datatracker steht der Text als aktiver individueller Internet-Draft. Er dokumentiert weder eine verabschiedete Norm noch einen gemessenen Einsatz. Er legt eine Frage auf den Tisch, die ein Kontrollgremium beantworten muss: Wer darf die Überwachung eines VRF-Übergangs als ausreichend bezeichnen, wenn der Nachweis nur die empfangende Seite nennt?

Ein ausgewählter Weg ohne Herkunftsschild

RFC 9069 erweitert BMP um die Beobachtung der lokalen Loc-RIB. Dort stehen Routen, die der lokale BGP-Entscheidungsprozess gewählt hat. Für einen Collector ist das nützlich: Er muss die Auswahl nicht aus sämtlichen Eingangskandidaten nachbauen. Das Protokoll beschreibt allerdings den lokalen Tabellenkontext. Bei VPN-Routen wird die Peer Address mit Nullen gefüllt; der Peer Distinguisher steht für die gemeldete lokale Instanz. Im Beispiel ist das RD11. Die Auswahl von RD22 wird durch diese Angabe nicht mitgeliefert.

PE1 hat die Kandidaten gesehen. Die Informationslücke liegt im Export an den BMP-Server. Das ist mehr als Wortklauberei, weil eine Betriebsprüfung an der falschen Stelle suchen würde, wenn sie dem Router einen Gedächtnisverlust zuschreibt. Für die Frage „Welche Route ist in VPN11 ausgewählt?“ ist der Bericht brauchbar. Für die Frage „Aus welcher entfernten Instanz kam genau diese Route?“ fehlt ein Feld.

Dieses Feld wollen die Autoren als Remote VRF Information TLV ergänzen: Adressfamilie, entfernte BGP-Kennung und entfernter Route Distinguisher. Dann könnte derselbe Eintrag RD11 als Ziel und RD22 als Quelle der gewählten Route tragen. Zusätzliche optionale TLVs betreffen das MPLS-Label und die SRv6-SID der entfernten VPN-Route. Diese Werte helfen bei technischen Folgefragen, ersetzen aber die Identität der Quellinstanz nicht.

Ein Route Target macht einen Import möglich. Eine lokale Richtlinie entscheidet, ob und wie er erfolgen soll. Wer die Einhaltung dieser Richtlinie überwacht, muss einen Wechsel der Quelle erkennen können, auch wenn P1 und VPN11 gleich bleiben. Sonst kann RD22 durch RD21 ersetzt werden, während das Dashboard dieselbe ordentliche Kachel für P1 in VPN11 zeigt. Die Kachel beschreibt einen wahren Ausschnitt; sie lässt den entscheidenden Übergang weg.

EVPN bekommt denselben blinden Fleck

Revision 01 behandelte die VPN-Route. Revision 02 ergänzt EVPN Type 5, wenn Routen über Integrated Routing and Bridging zwischen EVIs gelangen. Im Beispiel beginnt P1 in EVI21 auf PE2 und wird in EVI11 auf PE1 übernommen. Ohne neues Feld sieht der BMP-Server P1 in EVI11 und PE2 als Next Hop, aber nicht EVI21 als entfernte Quellinstanz. Das vorgeschlagene TLV kann AFI 25, SAFI 70, die entfernte BGP-Kennung und RD21 tragen.

Der Entwurf verweist auf einen weiteren Vorschlag für EVPN-BMP-Statistiken. Zähler pro EVI können die Menge übernommener Routen beschreiben. Der Zähler sagt nicht, welche EVI diese eine P1 geliefert hat. Er kann den Anlass zur Untersuchung geben; die Routenkennung macht die konkrete Herkunft prüfbar.

Die Beobachtung endet zunächst bei BGP. Eine Loc-RIB meldet die lokale Auswahl, keinen nachgewiesenen Eintrag in der Forwarding-Tabelle, keinen übertragenen Datenstrom und keinen Diensteffekt. Das Herkunftsfeld stärkt die Erklärung der Auswahl. Wer daraus eine Lieferbestätigung macht, überzieht den Befund erneut.

Zweimal freiwillig, einmal verschwunden

Ein BMP-Sprecher mit Unterstützung für die Erweiterung darf das TLV anhängen. Ein Collector darf es ignorieren und bleibt mit RFC 9069 kompatibel. Die Typwerte sind im IANA-Abschnitt noch offen. Zwischen einem veröffentlichten Vorschlag und einem durchsuchbaren RD22 in der Betriebsdatenbank liegen deshalb mindestens drei Entscheidungen: senden, behalten, verwenden.

Der Sicherheitsabschnitt verlangt autorisierte und vertrauenswürdige Überwachungsgeräte für BMP-Sitzungen. Das regelt die Vertrauensgrenze am Zugang zum Datenstrom. Wer die entfernte Kennung archiviert, wer ihr Fehlen meldet und wer diese Lücke akzeptieren darf, steht damit noch nicht fest. Eine grüne BMP-Verbindung kann eine fehlende Spalte im Bericht glänzend überdecken.

Sources