Dieselbe iESI innerhalb einer Site, eindeutig über Sites hinweg: Junos-Stitching

Zwei Gateway-Paare bedienen zwei Rechenzentren, und jemand muss entscheiden, wie viele Interconnect-ESI-Werte das Design braucht. Die Antwort ist einer pro Gateway-Gruppe, nicht einer pro Fabric und nicht einer pro Gateway. Ein Fehler dabei erzeugt ein Fabric, das konfiguriert aussieht und den falschen Forwarder wählt, oder es führt zwei Sites zusammen, die getrennt bleiben sollten. Die Regel und ihre Ausnahmen gehören neben die Gateway-Liste geschrieben.

Zwei Bereiche, zwei Regeln

Innerhalb einer Site wirken die redundanten Interconnect-Gateways als ein Multihomed-Endpunkt, teilen also einen einzigen Interconnect-ESI. Ihre Peers müssen ein logisches Mitglied sehen statt zwei unabhängiger. Das ist der ganze Sinn des gemeinsamen Werts.

Zwischen Sites erhält jede Gateway-Gruppe ihren eigenen Wert. Zwei Rechenzentren, die eine Kennung teilen, werden in der Steuerungsebene zu einer Multihomed-Gruppe, was ein Stitching-Design über ein WAN normalerweise nicht beabsichtigt. Zwei Sites in einer Gruppe erben zudem gegenseitig ihre Fehlermodi.

Innerhalb einer Site: eine Identität für die Gruppe

Geben Sie dem Paar denselben Wert auf beiden Peers, im selben Service-Kontext, und erfassen Sie ihn im Kennungsinventar des Netzes statt in einem Chat-Thread. Eine Abweichung zwischen den beiden Mitgliedern ist der Fehlermodus, der eine Gruppe aus einem Mitglied und keinen offensichtlichen Alarm erzeugt. Vergleichen Sie beide Mitglieder, bevor Sie einer funktionierenden Sitzung glauben.

Das unterstützte Modell ist all-active. Dieselbe Referenz schließt Single-Active-Betrieb, automatisch abgeleitete LACP-Kennungen und source-bmac-Optionen für diese Stitching-Identität aus, sodass ein Design, das eines davon annahm, überprüft werden muss, bevor die Kennung überhaupt gewählt wird. Diese Einschränkung ist eine Designvorgabe, keine Fußnote.

Über Sites hinweg: unterschiedliche Werte oder eine bewusste Zusammenführung

Ein eindeutiger Wert pro Site hält die beiden Gateway-Gruppen getrennt. Wenn die Absicht wirklich darin besteht, eine Multihomed-Gruppe über Sites hinweg zu erweitern, ist das eine andere Architektur mit eigenen Folgen für Latenz, Fehler und Weiterleitung, und sie sollte als Architektur entschieden werden, nicht als Kennungswahl. Verlangen Sie diese Entscheidung schriftlich vor dem Wartungsfenster.

Schreiben Sie die beabsichtigte Unterscheidung in den Plan, damit ein späterer Ingenieur, der eine funktionierende Site-Vorlage kopiert, nicht deren Kennung mitimportiert.

Die Peer-Anweisung gehört zur Identität

Jedes Gateway der Gruppe listet seine lokalen Peers per Loopback-Adresse auf, und diese Beziehung lebt auf der globalen EVPN-Ebene statt innerhalb eines einzelnen MAC-VRF. Sie in die falsche Hierarchie zu setzen, ist ein häufiger Weg zu einer Konfiguration, die committet, aber nie die Gruppe bildet. Lesen Sie die Referenzhierarchie einmal und halten Sie sich dann daran.

Auch der Name der Anweisung hat sich verschoben. Juniper benannte die Anweisung interconnect peer-gateways in 24.2R1 um und stellte die interconnect-spezifische Form für Rechenzentrums-Interconnect in 24.4R1 wieder her. Ein Snippet aus dem Zwischenrelease kann daher einen Namen verwenden, den die eingesetzte Version nicht akzeptiert, oder umgekehrt. Notieren Sie das Release, aus dem das Snippet stammt, neben dem Snippet selbst.

Was das Teilen einer iESI nicht leistet

Sie definiert keine Route Targets, VNIs oder die lokale EVPN-Instanz für Sie. Diese bleiben separate Konfiguration, die auf beiden Seiten übereinstimmen muss, und eine Kennung, die passt, während ein Route Target nicht passt, erzeugt eine Gruppe, die sich bildet und nichts trägt. Vergleichen Sie beide Seiten dieser Einstellungen im selben Durchgang.

Sie beweist auch keine Peer-Erreichbarkeit und keine Wahl des designated forwarder. Testen Sie Unicast und das erforderliche Broadcast- und Multicast-Verhalten im Normalfall und wiederholen Sie es dann mit einem entfernten Gateway, damit das verbleibende Mitglied die Gruppe allein trägt.

Genau dieser zweite Lauf beweist, dass die Gruppe real ist.

Bewahren Sie die beobachtete Mitgliedschaft und den Service-Kontext zusammen mit den Testergebnissen auf. Eine spätere Kennungsänderung lässt sich dann als Multihoming-Änderung prüfen, was sie ist, und nicht als kosmetische Bearbeitung einer Zeichenkette. Die Ergebnisse sind der einzige Beleg dafür, dass die Kennung tut, was die Zeichnung sagt.