Zusammenfassung

  • Die am 29. September veröffentlichte Fassung 07 des LSR-Entwurfs über Remote-IDs einzelner Layer-2-Bundle-Mitglieder verlangt den exakten, von null verschiedenen 32-Bit-Wert, den der Nachbar für dasselbe Mitglied als lokale Kennung ankündigt. Fassung 06 hatte empfohlen, dafür die per LLDP ermittelte Port ID zu verwenden.
  • LLDP und LACP können beim Auffinden des Nachbarports helfen. Ihre Kennungen haben aber nicht zwingend den Wert oder das Format der benötigten Mitglieds-ID. Auch eine authentisierte IGP-Ankündigung beweist nicht die Richtigkeit der zuvor ermittelten Layer-2-Zuordnung.

Ein logischer Link kann aus mehreren physischen Verbindungen bestehen. Für die gewöhnliche Beschreibung des Bündels reicht die logische Sicht; für Traffic Engineering auf einzelnen Mitgliedern und die Eingrenzung eines Ausfalls braucht ein Controller die Paarung jeder Leitung. Der IETF-Entwurf Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members beschreibt, wie OSPF und IS-IS solche Remote-IDs ankündigen und BGP-LS sie an einen Controller bringen könnte. Die jüngste Revision schärft nicht die Existenz der Bündel, sondern den Wahrheitsgehalt einer beworbenen Nummer.

Der Unterschied zur Fassung 06 vom 22. August ist deutlich. Damals galt LLDP als empfohlener Weg, um die Port ID der Gegenstelle zu erfahren; diese ID sollte für die Remote-ID-Ankündigung genutzt werden. Auch aus LACP-Portnummern abgeleitete Werte wurden erwähnt. Fassung 07 ersetzt diese Abkürzung durch eine exakte Beziehung: Beide Router vergeben für ihre Bundle-Mitglieder jeweils eine lokale, von null verschiedene 32-Bit-Kennung. Was ein Router als Remote-ID für ein Mitglied angibt, muss genau dem entsprechen, was der andere Router für dasselbe Mitglied als lokale ID veröffentlicht. Erst dann ist die Paarung aus beiden Blickrichtungen überprüfbar.

Warum reicht ein Portfund nicht aus? Die LLDP Port ID hängt von ihrem Subtyp ab und muss kein 32-Bit-Zahlenwert sein. LACP Actor und Partner Port Numbers sind 16 Bit breit und werden an beiden Enden unabhängig vergeben. Aus ihnen lässt sich ein Nachbarport erkennen; wie er zur in den Routingattributen angekündigten lokalen Mitgliedskennung des Nachbarn gehört, bestimmt jedoch die jeweilige Implementierung. Der neue Text lässt die Beschaffung des exakten Werts ausdrücklich außerhalb seines Regelungsbereichs. Konfiguration und eigene Discovery-Verfahren bleiben möglich.

LLDP und LACP sind nicht ausgeschlossen, nur ihre ungeprüfte Gleichsetzung mit der Routing-ID.

Ein hypothetischer Fehler zeigt die Konsequenz. Router R1 entdeckt an Mitglied A einen Port auf R2, ordnet ihm aber die falsche numerische Mitgliedskennung zu und kündigt die Paarung an. Die IGP-Authentisierung kann bestätigen, dass R1 diese Information gesendet hat. Sie bestätigt weder die Frische der Layer-2-Quelle noch, ob deren Portbezeichnung richtig in die Mitgliedskennung übersetzt wurde. Die neue Sicherheitsbetrachtung nennt dies eine Vertrauensgrenze und beschreibt mögliche Fehlentscheidungen bei Pfadsteuerung oder Störungskorrelation. Der Entwurf belegt damit keinen realen Vorfall und keinen Fehler eines bestimmten Herstellers.

Auch eine leere Remote-ID ist kein Beleg dafür, dass auf der anderen Seite kein Mitglied existiert. Vielleicht wurde der Wert noch nicht gelernt oder gar nicht angekündigt; bei einseitiger Unterstützung der Erweiterung ist das besonders naheliegend. IS-IS kann Null als Platzhalter für einen unbekannten Wert in einer geordneten Liste verwenden. BGP-LS exportiert das betreffende Mitglied dann ohne Remote-ID-Unter-TLV, nicht mit Null als gültiger Kennung. Der BGP-LS-Propagator prüft die Semantik nicht; der Verbraucher muss die Gegenseitigkeit bewerten und über eine Reaktion entscheiden.

Im Datatracker ist Fassung 07 weiterhin ein aktiver Internet-Draft im IESG Last Call bis zum 13. Oktober, mit dem angestrebten Status Proposed Standard. Ein RFC ist sie noch nicht. Dass die Ankündigung pro Link eingeschaltet werden muss und standardmäßig aus bleibt, stand bereits in Fassung 06. Neu ist die klare Grenze zwischen einer gefundenen Portspur und einer belastbaren Remote-ID.

Quellen