Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Grundlegendes zum Junos Node Slicing

Junos Node Slicing – Übersicht

Junos Node Slicing ermöglicht es Service Providern und großen Unternehmen, eine Netzwerkinfrastruktur zu erstellen, die mehrere Routing-Funktionen in einem einzigen physischen Gerät konsolidiert. Es hilft beim Hosten mehrerer Dienste auf einer einzigen physischen Infrastruktur und vermeidet gleichzeitig die damit verbundene betriebliche Komplexität. Außerdem wird die betriebliche, funktionale und administrative Trennung der auf dem Gerät gehosteten Funktionen beibehalten.

Mit Junos Node Slicing können Sie mehrere Partitionen in einem einzigen physischen Router der MX-Serie erstellen. Diese Partitionen werden als Gastnetzwerkfunktionen (GNFs) bezeichnet. Jeder GNF verhält sich wie ein unabhängiger Router mit eigener dedizierter Steuerungs-, Daten- und Verwaltungsebene. Auf diese Weise können Sie mehrere Services auf einem einzigen konvergenten Router der MX-Serie ausführen und gleichzeitig die betriebliche Isolation zwischen ihnen aufrechterhalten. Sie können dasselbe physische Gerät nutzen, um parallele Partitionen zu erstellen, die sich nicht die Steuerungs- oder Weiterleitungsebene teilen, sondern nur das gleiche Gehäuse, den gleichen Platz und die gleiche Leistung.

Sie können Datenverkehr zwischen GNFs auch über die Switch-Fabric senden, indem Sie eine abstrahierte Fabric-Schnittstelle () verwenden, eine Pseudo-Schnittstelle, die sich wie eine erstklassige Ethernet-Schnittstelleaf verhält. Eine abstrahierte Fabric-Schnittstelle erleichtert die Routing-Steuerung, den Daten- und Verwaltungsverkehr zwischen GNFs.

Junos Node Slicing bietet zwei Modelle: ein externes Servermodell und ein In-Chassis-Modell. Beim externen Servermodell werden die GNFs auf einem Paar branchenüblicher x86-Server gehostet. Beim In-Chassis-Modell werden die GNFs auf den Routing-Engines des Routers der MX-Serie selbst gehostet.

Junos Node Slicing unterstützt Multiversion-Softwarekompatibilität, sodass die GNFs unabhängig voneinander aktualisiert werden können.

Vorteile von Junos Node Slicing

  • Converged network—Mit Junos Node Slicing können Service Provider mehrere Netzwerkservices wie Video-Edge und Voice Edge in einem einzigen physischen Router konsolidieren und dabei die operative Trennung zwischen ihnen beibehalten. Sie können sowohl horizontale als auch vertikale Konvergenz erreichen. Bei der horizontalen Konvergenz werden Routerfunktionen derselben Schicht in einem einzigen Router konsolidiert, während bei der vertikalen Konvergenz Routerfunktionen verschiedener Schichten in einem einzigen Router zusammengefasst werden.

  • Improved scalability—Die Fokussierung auf virtuelle Routing-Partitionen anstelle von physischen Geräten verbessert die Programmierbarkeit und Skalierbarkeit des Netzwerks und ermöglicht es Service Providern und Unternehmen, auf Infrastrukturanforderungen zu reagieren, ohne zusätzliche Hardware kaufen zu müssen.

  • Easy risk management—Obwohl mehrere Netzwerkfunktionen in einem einzigen Chassis zusammenlaufen, werden alle Funktionen unabhängig voneinander ausgeführt und profitieren von betrieblicher, funktionaler und administrativer Trennung. Durch die Partitionierung eines physischen Systems, z. B. Broadband Network Gateway (BNG), in mehrere unabhängige logische Instanzen wird sichergestellt, dass Fehler isoliert werden. Die Partitionen teilen sich nicht die Steuerungs- oder Weiterleitungsebene, sondern nur das gleiche Gehäuse, den gleichen Platz und die gleiche Leistung. Dies bedeutet, dass ein Ausfall in einer Partition keinen weitreichenden Dienstausfall verursacht.

  • Reduced network costs—Junos Node Slicing ermöglicht die Verbindung von GNFs über interne Switching-Fabrics, wodurch die abstrahierte Fabric-Schnittstelle () genutzt wird, eine Pseudo-Schnittstelle, die ein erstklassiges Ethernet-Schnittstellenverhaltenaf darstellt. Mit af der vorhandenen Schnittstelle sind Unternehmen nicht mehr auf physische Schnittstellen angewiesen, um GNFs zu verbinden, was zu erheblichen Einsparungen führt.

  • Reduced time-to-market for new services and capabilities—Jeder GNF kann mit einer anderen Junos-Softwareversion betrieben werden. Dieser Vorteil ermöglicht es den Unternehmen, jeden GNF in seinem eigenen Tempo weiterzuentwickeln. Wenn ein neuer Dienst oder eine neue Funktion auf einem bestimmten GNF bereitgestellt werden muss und dafür eine neue Softwareversion erforderlich ist, muss nur der betreffende GNF aktualisiert werden. Darüber hinaus ermöglicht Junos Node Slicing Service Providern und Unternehmen dank der erhöhten Agilität die Einführung eines hochflexiblen Everything-as-a-Service-Geschäftsmodells, um schnell auf sich ständig ändernde Marktbedingungen zu reagieren.

Komponenten von Junos Node Slicing

Junos Node Slicing ermöglicht es Ihnen, einen einzelnen Router der MX-Serie zu partitionieren, damit er als mehrere, unabhängige Router angezeigt wird. Jede Partition verfügt über eine eigene Junos OS-Steuerungsebene, die als virtuelle Maschine (VM) ausgeführt wird, und einen dedizierten Satz von Linecards. Jede Partition wird als Gastnetzwerkfunktion (GNF) bezeichnet.

Der Router der MX-Serie fungiert als Basissystem (BSYS). Das BSYS besitzt alle physischen Komponenten des Routers, einschließlich der Linecards und der Switching-Fabric. Das BSYS weist den GNFs Linecards zu.

Die Juniper Device Manager (JDM)-Software orchestriert die GNF-VMs. In JDM wird eine GNF-VM als virtuelle Netzwerkfunktion (VNF) bezeichnet. Ein GNF besteht also aus einer VNF und einem Satz von Linecards.

Durch die Konfiguration am BSYS können Sie Linecards des Chassis verschiedenen GNFs zuweisen und je nach Linecard-Typ sogar Sätze von PFEs innerhalb einer Linecard verschiedenen GNFs zuweisen. Weitere Informationen finden Sie unter Übersicht über die Subline Card .

Junos Node Slicing unterstützt zwei Modelle:

  • Externes Servermodell

  • In-Chassis-Modell

Beim externen Servermodell werden JDM und VNFs auf einem Paar externer, branchenüblicher x86-Server gehostet.

Abbildung 1 zeigt drei GNFs mit ihren dedizierten Linecards, die auf einem externen Server ausgeführt werden.

Abbildung 1: GNFs auf externem Server GNFs on External Server

Informationen zum Verbinden eines Routers der MX-Serie mit einem Paar externer x86-Server finden Sie unter Verbinden der Server und des Routers .

Beim In-Chassis-Modell werden alle Komponenten (JDM, BSYS sowie GNFs) innerhalb der Routing-Engine des Routers der MX-Serie ausgeführt. Siehe Abbildung 2.

Abbildung 2: Junos Node Slicing In-chassis Junos Node Slicing im Gehäuse

Basissystem (BSYS)

Beim Junos Node Slicing fungiert der Router der MX-Serie als Basissystem (BSYS). Das BSYS besitzt alle physischen Komponenten des Routers, einschließlich aller Linecards und der Fabric. Über die Junos OS-Konfiguration am BSYS können Sie GNFs Linecards zuweisen und abstrahierte Fabric-Schnittstellen zwischenaf GNFs definieren. Die BSYS-Software läuft auf einem Paar redundanter Routing-Engines des Routers der MX-Serie.

Gastnetzwerkfunktion (GNF)

Eine Gastnetzwerkfunktion (GNF) ist logischer Eigentümer der Linecards, die ihr vom Basissystem (BSYS) zugewiesen wurden, und verwaltet den Weiterleitungsstatus der Linecards. Sie können mehrere GNFs auf einem Router der MX-Serie konfigurieren (siehe Konfigurieren von Gastnetzwerkfunktionen). Die Junos OS-Steuerungsebene jeder GNF wird als virtuelle Maschine (VM) ausgeführt. Die Juniper Device Manager (JDM)-Software orchestriert die GNF-VMs. Im JDM-Kontext werden die GNFs als Virtual Network Functions (VNF) bezeichnet.

Ein GNF entspricht einem eigenständigen Router. GNFs werden unabhängig voneinander konfiguriert und verwaltet und operativ voneinander isoliert.

Das Erstellen eines GNF erfordert zwei Sätze von Konfigurationen, von denen eine am BSYS und die andere am JDM ausgeführt wird.

Ein GNF wird durch eine ID definiert. Diese ID muss bei BSYS und JDM identisch sein.

Der BSYS-Teil der GNF-Konfiguration besteht darin, ihr eine ID und einen Satz von Linecards zu geben.

Der JDM-Teil der GNF-Konfiguration umfasst die Angabe der folgenden Attribute:

  • Ein VNF-Name.

  • EINE GNF-ID. Diese ID muss mit der GNF-ID übereinstimmen, die im BSYS verwendet wird.

  • Der Plattformtyp der MX-Serie (für das externe Servermodell).

  • Ein Junos OS-Image, das für die VNF verwendet werden soll.

  • Die VNF-Serverressourcenvorlage.

Die Serverressourcenvorlage definiert die Anzahl der dedizierten (physischen) CPU-Kerne und die Größe des DRAM, der einem GNF zugewiesen werden soll. Eine Liste der vordefinierten Serverressourcenvorlagen, die für GNFs verfügbar sind, finden Sie im Abschnitt Anforderungen an die Serverhardwareressourcen (pro GNF) unter Minimale Hardware- und Softwareanforderungen für Junos Node Slicing.

Nachdem ein GNF konfiguriert wurde, können Sie darauf zugreifen, indem Sie eine Verbindung zum Port der virtuellen Konsole des GNF herstellen. Mit der Junos OS CLI am GNF können Sie dann die GNF-Systemeigenschaften wie Hostname und Verwaltungs-IP-Adresse konfigurieren und anschließend über den Management-Port darauf zugreifen.

Juniper Geräte-Manager (JDM)

Der Juniper Device Manager (JDM), ein virtualisierter Linux-Container, ermöglicht die Bereitstellung und Verwaltung der GNF-VMs.

JDM unterstützt Junos OS-ähnliche CLI, NETCONF für Konfiguration und Management und SNMP für die Überwachung.

Hinweis:

Beim In-Chassis-Modell unterstützt JDM SNMP nicht.

Eine JDM-Instanz wird auf jedem der x86-Server im externen Servermodell und auf jeder Routing-Engine für das In-Chassis-Modell gehostet. Die JDM-Instanzen werden in der Regel als Peers konfiguriert, die die GNF-Konfigurationen synchronisieren: Wenn eine GNF-VM auf einem Server erstellt wird, wird ihre Backup-VM automatisch auf dem anderen Server oder Routing-Engine erstellt.

Eine IP-Adresse und ein Administratorkonto müssen auf dem JDM konfiguriert werden. Nachdem diese konfiguriert wurden, können Sie sich direkt beim JDM anmelden.

Abstrahierte Fabric-Schnittstelle

Die abstrahierte Fabric-Schnittstelle () ist eine Pseudo-Schnittstelle, die ein erstklassiges Ethernet-Schnittstellenverhaltenaf darstellt. Eine af Schnittstelle erleichtert das Routing, die Steuerung und die Verwaltung des Datenverkehrs zwischen Gastnetzwerkfunktionen (GNFs) durch die Switch-Fabric. Auf einem GNF wird eine af Schnittstelle erstellt, um mit dem Peer-GNF zu kommunizieren, wenn die beiden GNFs so konfiguriert sind, dass sie miteinander verbunden sind. Abstrahierte Fabric-Schnittstellen müssen bei BSYS erstellt werden. Die Bandbreite der Schnittstellen ändert sich dynamisch basierend auf dem Einsetzen oder der Erreichbarkeit der af Remote-Linecard/MPC. Da die Fabric das Kommunikationsmedium zwischen GNFs ist, af werden Schnittstellen als äquivalente WAN-Schnittstellen betrachtet. Siehe Abbildung 3.

Abbildung 3: Abstrahierte Fabric-Schnittstelle Abstracted Fabric Interface

Grundlegendes zur Bandbreite der abstrahierten Fabric-Schnittstelle

Eine abstrahierte Fabric-Schnittstelle (af) verbindet zwei GNFs über die Fabric und aggregiert alle Packet Forwarding Engines (PFEs), die die beiden GNFs verbinden. Eine af Schnittstelle kann die Summe der Bandbreite jeder zur Schnittstelle gehörenden af Paketweiterleitungs-Engine nutzen.

Wenn GNF1 beispielsweise über eine MPC8 verfügt (die über vier Packet Forwarding Engines mit jeweils 240 Gbit/s Kapazität verfügt) und GNF1 über af Schnittstellen (af1 und af2) mit GNF2 und GNF3 verbunden ist, beträgt die maximale af Schnittstellenkapazität auf GNF1 4 x 240 Gbit/s = 960 Gbit/s.

GNF1—af1——GNF2

GNF1—af2——GNF3

Hier teilen sich af1 und af2 die Kapazität von 960 Gbit/s.

Informationen zur Bandbreite, die von den einzelnen MPCs unterstützt wird, finden Sie in Tabelle 1.

Funktionen, die auf abstrahierten Fabric-Schnittstellen unterstützt werden

Abstrahierte Fabricschnittstellen unterstützen die folgenden Funktionen:

  • Einheitliches In-Service-Software-Upgrade (ISSU)

  • Hyper-Modus-Konfiguration auf BSYS-Ebene (ab Junos OS Version 19.3R2). Diese Funktion wird auf den Linecards MPC6E, MPC8E, MPC9E und MPC11E unterstützt.

    Hinweis:
    • Es ist nicht möglich, unterschiedliche Hypermodus-Konfigurationen für einzelne GNFs zu verwenden, da diese die Konfiguration von der BSYS erben.

    • Die Router MX2020 und MX2010 mit SFB3 werden standardmäßig im Hyper-Modus angezeigt. Wenn der Hyper-Modus in einem GNF deaktiviert werden soll, müssen Sie ihn im BSYS konfigurieren, und er gilt für alle GNFs dieses Chassis.

  • Load Balancing basierend auf den vorhandenen Remote-GNF-Linecards

  • Class of Service (CoS)-Unterstützung:

    • Inet-Präzedenz-Klassifizierer und -Umschreibung

    • DSCP-Klassifizierung und -Umschreibung

    • MPLS EXP-Klassifikator und -Umschreibung

    • DSCP v6-Klassifikator und -Umschreibung für IP v6-Datenverkehr

  • Unterstützung für OSPF-, IS-IS-, BGP-, OSPFv3-Protokolle und L3VPN

    Hinweis:

    Die Nicht-Schnittstellenaf unterstützen alle Protokolle, die unter Junos OS funktionieren.

  • Multicast-Weiterleitung

  • Graceful Routing Engine Switchover (GRES)

  • MPLS-Anwendungen, bei denen die af Schnittstelle als Core-Schnittstelle fungiert (L3VPN, VPLS, L2VPN, L2CKT, EVPN und IP over MPLS)

  • Die folgenden Protokollfamilien werden unterstützt:

    • IPv4-Weiterleitung

    • IPv6-Weiterleitung

    • MPLS

    • ISO

    • CCC

  • Unterstützung für JTI-Sensoren (Junos Telemetry Interface)

  • Ab Junos OS Version 19.1R1 unterstützen Gastnetzwerkfunktionen (GNFs) Ethernet-VPNs (EVPN) mit VXLAN-Kapselung (Virtual Extensible LAN Protocol). Diese Unterstützung ist mit nicht-(d. h. physischen) Schnittstellen und af Schnittstellen als Core-Schnittstelleaf verfügbar. Diese Unterstützung ist für die MPC11E-Linecard nicht verfügbar.

  • In der af Schnittstellenkonfiguration unterstützen afGNFs -fähige MPCs. Tabelle 1 listet die -fähigen MPCs, die Anzahl der pro MPC unterstützten PFEs und die afpro MPC unterstützte Bandbreite auf.

    Tabelle 1: Unterstützte Abstracted Fabric-fähige MPCs

    MPC

    Erste Veröffentlichung

    Anzahl der PFEs

    Gesamtbandbreite

    MPC7E-MRATE

    17.4R1

    2

    480G (240*2)

    MPC7E-10G

    17.4R1

    2

    480G (240*2)

    MX2K-MPC8E

    17.4R1

    4

    960G (240*4)

    MX2K-MPC9E

    17.4R1

    4

    1,6 Zähne (400*4)

    MPC2E

    19.1R1

    2

    80 (40*2)

    MPC2E NG

    17.4R1

    1

    80G

    MPC2E NG Q

    17.4R1

    1

    80G

    MPC3E

    19.1R1

    1

    130G

    MPC3E NG

    17.4R1

    1

    130G

    MPC3E NG Q

    17.4R1

    1

    130G

    32x10GE MPC4E

    19.1R1

    2

    260G (130*2)

    2x100GE + 8x10GE MPC4E

    19.1R1

    2

    260G (130*2)

    MPC5E-40G10G

    18.3R1

    2

    240G (120*2)

    MPC5EQ-40G10G

    18.3R1

    2

    240G (120*2)

    MPC5E-40G100G

    18.3R1

    2

    240G (120*2)

    MPC5EQ-40G100G

    18.3R1

    2

    240G (120*2)

    MX2K-MPC6E

    18.3R1

    4

    520G (130*4)

    Multiservices-MPC (MS-MPC)

    19.1R1

    1

    120G

    16x10GE MPC

    19.1R1

    4

    160G (40*4)

    MX2K-MPC11E

    19.3R2

    8

    4 Zähne (500 G*8)

Hinweis:

Es wird empfohlen, die MTU-Einstellungen auf der af Schnittstelle so einzustellen, dass sie am maximal zulässigen Wert auf den XE/GE-Schnittstellen ausgerichtet sind. Dadurch wird eine minimale oder keine Fragmentierung der Pakete über die af Schnittstelle sichergestellt.

Einschränkungen der abstrahierten Fabric-Schnittstelle

Im Folgenden sind die aktuellen Einschränkungen für abstrahierte Fabricschnittstellen aufgeführt:

  • Konfigurationen, wie z. B. eine einzelne Endpunktschnittstelle af , af eine Nichtübereinstimmung der Schnittstellen-zu-GNF-Zuordnung oder die Zuordnung mehrerer af Schnittstellen zu derselben Remote-GNF, werden während der Festschreibung auf dem BSYS nicht überprüft. Stellen Sie sicher, dass Sie über die richtigen Konfigurationen verfügen.

  • Die Bandbreitenzuweisung ist statisch und basiert auf dem MPC-Typ.

  • Während des Offline-/Neustarts einer MPC, die auf einem Remote-GNF gehostet wird, kann es zu minimalen Datenverkehrsverlusten (sowohl Transit als auch Host) kommen.

  • Die Interoperabilität zwischen MPCs, die -fähig sind af, und den MPCs, die nicht -fähig sind, wird nicht afunterstützt.

Optimieren des Fabric-Pfads für eine abstrahierte Fabric-Schnittstelle

Sie können den Datenverkehr, der über die abstrahierten Fabric-Schnittstellen (af) zwischen zwei Gastnetzwerkfunktionen (GNFs) fließt, optimieren, indem Sie einen Fabric-Pfadoptimierungsmodus konfigurieren. Diese Funktion reduziert den Bandbreitenverbrauch der Fabric, indem sie zusätzlichen Fabric-Hop (Umschalten von Datenverkehrsflüssen von einer Paketweiterleitungs-Engine zu einer anderen) verhindert, bevor die Pakete schließlich die Ziel-Paketweiterleitungs-Engine erreichen. Die Fabric-Pfadoptimierung, die auf MX2008, MX2010 und MX2020 mit MPC9E und MX2K-MPC11E unterstützt wird, verhindert nur einen einzigen zusätzlichen Datenverkehrssprung, der sich aus dem abstrahierten Lastausgleich der Fabric-Schnittstelle ergibt.

Sie können einen der folgenden Optimierungsmodi für den Fabric-Pfad konfigurieren:

  • monitor—Wenn Sie diesen Modus konfigurieren, überwacht die Peer-GNF den Datenverkehrsfluss und sendet Informationen über die Paketweiterleitungs-Engine, an die der Datenverkehr derzeit weitergeleitet wird, und die gewünschte Paketweiterleitungs-Engine, die einen optimierten Datenverkehrspfad bereitstellen könnte, an die Quell-GNF. In diesem Modus leitet die Quell-GNF den Datenverkehr nicht an die gewünschte Paketweiterleitungs-Engine weiter.

  • optimize—Wenn Sie diesen Modus konfigurieren, überwacht die Peer-GNF den Datenverkehrsfluss und sendet Informationen über die Paketweiterleitungs-Engine, an die der Datenverkehr derzeit weitergeleitet wird, und die gewünschte Paketweiterleitungs-Engine, die einen optimierten Datenverkehrspfad bereitstellen könnte, an die Quell-GNF. Die Quell-GNF leitet dann den Datenverkehr an die gewünschte Packet Forwarding Engine weiter.

Um einen Fabric-Pfadoptimierungsmodus zu konfigurieren, verwenden Sie die folgenden CLI-Befehle unter BSYS.

Nachdem Sie die Fabric-Pfadoptimierung konfiguriert haben, können Sie den Befehl show interfaces af-interface-name in GNF verwenden, um die Anzahl der Pakete anzuzeigen, die derzeit auf dem optimalen/nicht optimalen Pfad fließen.

Auswahl zwischen externem Servermodell und In-Chassis-Modell

Das externe Servermodell ermöglicht es Ihnen, mehr Instanzen von GNFs mit höherer Skalierung zu konfigurieren, da Sie einen Server mit ausreichender Kapazität auswählen können, um die GNF-Anforderungen zu erfüllen. Beim In-Chassis-Modell hängt die Anzahl der konfigurierbaren GNFs von den Skalierungsanforderungen der einzelnen GNFs und der Gesamtkapazität der Routing-Engine ab.

Die Modelle für externe Server und In-Chassis von Junos Node Slicing schließen sich gegenseitig aus. Ein Router der MX-Serie kann so konfiguriert werden, dass er jeweils nur in einem dieser Modelle funktioniert.

Primärrollenverhalten von BSYS und GNF

In den folgenden Abschnitten wird das primäre Rollenverhalten von BSYS und GNF im Kontext der Routing-Engine-Redundanz behandelt.

Abbildung 4 zeigt das primäre Rollenverhalten von GNF und BSYS mit Routing-Engine-Redundanz.

Abbildung 4: Primärrollenverhalten von GNF und BSYS (externes Servermodell) Primary-role Behavior of GNF and BSYS (External Server Model)

Primäre BSYS-Rolle

Das Verhalten der primären Rollenvermittlung der BSYS Routing-Engine ist identisch mit dem der Routing-Engines auf Routern der MX-Serie.

Primäre Rolle des GNF

Das Verhalten der primären Rollenvermittlung der GNF-VM ähnelt dem der Routing-Engines der MX-Serie. Jeder GNF wird als primäres Backup-Paar von VMs ausgeführt. Eine GNF-VM, die auf (oder für In-Chassis) ausgeführt wird, entspricht dem Routing-Engine-Steckplatz 0 eines Routers der MX-Serie, und die GNF-VM, die auf server0 server1 (oder re0 re1 für In-Chassis) ausgeführt wird, entspricht dem Routing-Engine-Steckplatz 1 eines Routers der MX-Serie.

Die primäre Rolle des GNF ist unabhängig von der primären Rolle von BSYS und der anderer GNF. Die GNF-Schiedsgerichtsbarkeit für die primäre Rolle erfolgt über Junos OS. Unter Bedingungen mit Verbindungsfehlern wird die primäre GNF-Rolle konservativ gehandhabt.

Das primäre GNF-Rollenmodell ist für externe Server- und In-Chassis-Modelle identisch.

Hinweis:

Wie bei den Routing-Engines der MX-Serie müssen Sie bei jedem GNF den Graceful Routing Engine Switchover (GRES) konfigurieren. Dies ist eine Voraussetzung dafür, dass die Backup-GNF-VM automatisch die primäre Rolle übernimmt, wenn die primäre GNF-VM ausfällt oder neu gestartet wird.

Junos Node Slicing-Administratorrollen

Mit den folgenden Administratorrollen können Sie die Node-Slicing-Aufgaben ausführen:

  • BSYS-Administrator: Verantwortlich für das physische Gehäuse sowie für die GNF-Bereitstellung (Zuweisung von Linecards zu GNFs). Für diese Aufgaben stehen Junos OS CLI-Befehle zur Verfügung.

  • GNF-Administrator: Verantwortlich für die Konfiguration, den Betrieb und die Verwaltung von Junos OS beim GNF. Alle regulären CLI-Befehle von Junos OS stehen dem GNF-Administrator für diese Aufgaben zur Verfügung.

  • JDM-Administrator: Verantwortlich für die Konfiguration der JDM-Server-Ports (für das externe Servermodell) sowie für die Bereitstellung und das Lebenszyklusmanagement der GNF-VMs (VNFs). Für diese Aufgaben stehen JDM-CLI-Befehle zur Verfügung.

Übersicht über die Sub Line Card

Beim Junos Node Slicing besteht jeder GNF aus einem Satz von Linecards (FPCs). Standardmäßig befindet sich die feinste Granularität, die von einem GNF bereitgestellt wird, auf Linecard-Ebene, da jedem GNF ganze Linecards zugewiesen werden (d. h. der vollständige Satz von Paketweiterleitungsmodulen in jeder Linecard). Mit der SLC-Funktion (Sub Line Card) können Sie eine noch feinere Granularität der Partitionierung definieren, indem Sie Teilmengen von Paketweiterleitungsmodulen in einer einzigen Linecard verschiedenen GNFs zuweisen.

Solche benutzerdefinierten Teilmengen von Paketweiterleitungsmodulen in einer Linecard werden als Sub-Linecards (SLCs) bezeichnet. Operativ funktionieren SLCs wie unabhängige Linecards.

Wenn Sie eine Linecard aufteilen, muss jeder SLC dieser Linecard einem anderen GNF zugewiesen werden.

Sie können SLCs aus mehreren Linecards demselben GNF zuweisen.

In einem Junos Node Slicing-Setup mit der SLC-Funktion kann ein GNF sowohl einen Satz ganzer Linecards als auch einen Satz von Slices (SLCs) von Linecards umfassen, was ein höheres Maß an Flexibilität bietet.

Wenn eine Linecard in Scheiben geschnitten wird, werden zwei Arten von Softwareinstanzen auf dieser Linecard ausgeführt: eine einzelne BLC-Instanz (Base Line Card) und mehrere SLC-Instanzen (so viele wie die Anzahl der Slices dieser Linecard). Derzeit ist die SLC-Funktion nur auf der MPC11E verfügbar, die zwei SLCs unterstützt. Die BLC-Instanz ist für die Verwaltung der Hardware zuständig, die allen SLCs dieser Linecard gemeinsam ist, während jede SLC-Instanz für die Verwaltung der Gruppe von Paketweiterleitungs-Engines zuständig ist, die ihr exklusiv zugewiesen sind. Auf der BLC-Instanz wird die Junos-Software des BSYS ausgeführt, während auf jeder SLC-Instanz die Junos-Software des zugehörigen GNF ausgeführt wird.

Abbildung 5: SLCs, die GNFs in einem externen, serverbasierten Junos Node Slicing-Setup SLCs assigned to GNFs in an external server-based Junos node slicing setup zugewiesen wurden

SLCs unterstützen abstrahierte Fabric-Schnittstellen und reduzierte Weiterleitungen (siehe Optimieren des Fabric-Pfads für abstrahierte Fabric-Schnittstelle). Sie können den show interface af-interface-name Befehl verwenden, um die Lastausgleichsstatistiken der Remote-FPC-Slice-spezifischen Paketweiterleitungs-Engines anzuzeigen. Weitere Informationen finden Sie unter Zeigen von Schnittstellen (abstrahiertes Fabric).

Die SLC-Funktion ist nur auf dem MPC11E (Modellnummer: MX2K-MPC11E) verfügbar.

Linecard-Ressourcen für SLCs

Ein SLC oder ein Slice einer Linecard definiert die Gruppe von Packet Forwarding Engines (dieser Linecard), die zusammen arbeiten müssen. Paketweiterleitungsmodule in einer Linecard werden durch numerische IDs identifiziert. Wenn eine Linecard über 'n' Paketweiterleitungs-Engines verfügt, werden die einzelnen Paketweiterleitungs-Module mit 0 bis (n-1) nummeriert. Darüber hinaus müssen auch CPU-Kerne und DRAM auf der Steuerplatine der Linecard aufgeteilt und dem Slice zugewiesen werden. Um einen SLC zu definieren, müssen Sie also die folgenden Linecard-Ressourcen definieren, die für dieses SLC reserviert werden sollen:

  • Eine Reihe von Paketweiterleitungs-Engines

  • Die Anzahl der CPU-Kerne auf der Steuerplatine der Linecard

  • Die Größe des DRAM (in GB) auf der Steuerplatine der Linecard

Hinweis:

Ein bestimmter Teil des DRAM wird automatisch für die BLC-Instanz auf dieser Linecard reserviert, der Rest ist für SLC-Instanzen verfügbar.

Jedes SLC wird durch eine numerische ID identifiziert, die vom Benutzer zugewiesen wird.

Wenn eine Linecard aufgeteilt wird, müssen die Ressourcenpartitionen für jeden Slice auf dieser Linecard vollständig definiert sein.

MPC11E Linecard-Ressourcen für SLCs

Eine MPC11E-Linecard verfügt über:

  • 8 Paketweiterleitungs-Engines

  • 8 CPU-Kerne auf der Steuerplatine

  • 32 GB DRAM auf der Steuerplatine

5 GB DRAM werden automatisch für die BLC-Nutzung reserviert, 1 GB DRAM wird dem Linecard-Host zugewiesen und die restlichen 26 GB stehen für SLC-Slices zur Verfügung.

Eine MPC11E ist in der Lage, zwei SLCs zu unterstützen.

In Tabelle 2 sind zwei Typen von Ressourcenzuordnungsprofilen definiert, die von einem MPC11E für die beiden SLCs unterstützt werden, die hier als SLC1 und SLC2 bezeichnet werden.

Im symmetrischen Profil werden die Paketweiterleitungsmodule und andere Linecard-Ressourcen gleichmäßig auf die Slices verteilt. Im asymmetrischen Profil werden nur die in Tabelle 2 angegebenen Linecard-Ressourcenkombinationen unterstützt.

Hinweis:

Sie können die folgenden SLC-Profile konfigurieren, je nachdem, wie die Packet Forwarding Engines [0-7] zwischen den beiden SLCs aufgeteilt sind:

  • Paketweiterleitungs-Engines 0-3 für einen SLC und 4-7 für den anderen SLC (symmetrisches Profil)

  • Paketweiterleitungs-Engines 0-1 für einen SLC und 2-7 für den anderen SLC (asymmetrisches Profil)

  • Packet Forwarding Engines 0-5 für einen SLC und 6-7 für den anderen SLC (asymmetrisches Profil)

Im asymmetrischen Profil können Sie einem SLC entweder 9 GB oder 17 GB DRAM zuweisen. Da alle Linecard-Ressourcen vollständig zugewiesen sein müssen und der gesamte für SLCs verfügbare DRAM 26 GB beträgt, erfordert die Zuweisung von 9 GB DRAM zu einem SLC, dass die restlichen 17 GB dem anderen SLC zugewiesen werden müssen.

Tabelle 2: Von MPC11E unterstützte SLC-Profile
 

Symmetrisches Profil

Asymmetrisches Profil

Ressourcentyp

SLC1

SLC2

SLC1

SLC2

Packet Forwarding Engine

4

4

2

6

DRAM

13 GB

13 GB

17 GB/9 GB

9 GB/17 GB

CPU

4

4

4

4

Siehe auch: Konfigurieren von Sub-Linecards und Zuweisen zu GNFs und Verwalten von Sub-Linecards.

Übersicht über die Interoperabilität von Multiversion-Software

Ab Junos OS Version 17.4R1 unterstützt Junos Node Slicing Multiversion-Softwarekompatibilität, sodass das BSYS mit einer Gastnetzwerkfunktion (GNF) zusammenarbeiten kann, auf der eine Junos OS-Version ausgeführt wird, die höher ist als die Softwareversion des BSYS. Diese Funktion unterstützt einen Bereich von bis zu zwei Versionen zwischen GNF und BSYS. Das heißt, die GNF-Software kann zwei Versionen höher sein als die BSYS-Software. Sowohl BSYS als auch GNF müssen eine Mindestversionsanforderung von Junos OS Version 17.4R1 erfüllen.

Hinweis:

Die Einschränkungen bei der Multiversionsunterstützung gelten auch für den vereinheitlichten ISSU-Upgradeprozess.

Obwohl die JDM-Softwareversionsverwaltung keine ähnliche Einschränkung in Bezug auf die GNF- oder BSYS-Softwareversionen hat, empfehlen wir, die JDM-Software regelmäßig zu aktualisieren. Ein JDM-Upgrade wirkt sich auf keine der laufenden GNFs aus.

Services der nächsten Generation auf Junos Node Slicing

Junos Node Slicing unterstützt die MX-SPC3 Services Card, eine Security Services Card, die zusätzliche Rechenleistung für die Ausführung der Next Gen Services auf den MX-Plattformen bereitstellt. Sie können Next Gen Services bei der Gastnetzwerkfunktion (GNF) aktivieren, indem Sie die CLI request system enable unified-services unter GNF verwenden. Um einen MX-SPC3 zu unterstützen, muss einem GNF eine Linecard zugeordnet sein.

In einem Junos Node Slicing-Setup können Sie sowohl MX-SPC3 als auch MS-MPC auf demselben Gehäuse, aber auf unterschiedlichen GNF-Routing-Engines verwenden. Wenn Sie Next Gen Services bei GNF aktiviert haben, indem Sie , request system enable unified-serviceswird die MX-SPC3 online geschaltet. Wenn Sie Next Gen Services nicht aktiviert haben, wird die MS-MPC online geschaltet.

Die Softwareinstallation oder das Upgrade einer MX-SPC3-Karte erfolgt, wenn Sie die zugehörige GNF-Routing-Engine installieren oder aktualisieren.

Hinweis:

Die MX-SPC3 unterstützt keine abstrahierten Fabric-Schnittstellen. Daher muss einem GNF, mit dem eine MX-SPC3-Karte verknüpft ist, auch eine Linecard zugeordnet sein.

Vergleich von Junos Node Slicing mit logischen Systemen

Junos Node Slicing ist eine Ebene unterhalb der logischen Systeme in Junos. Beide Technologien haben einige überlappende Fähigkeiten, unterscheiden sich aber in anderen Aspekten. Beim Junos Node Slicing werden ganze Linecards und damit physische Schnittstellen einem GNF zugewiesen, während bei logischen Systemen eine einzelne physische Schnittstelle selbst von verschiedenen logischen Systemen gemeinsam genutzt werden kann, da mehrere logische Schnittstellen, die über eine physische Schnittstelle definiert sind, separaten logischen Systemen zugewiesen werden können. Das bedeutet, dass logische Systeme eine feinere Granularität der Freigabe ermöglichen als Junos Node Slicing. Alle logischen Systeme teilen sich jedoch einen einzigen Junos-Kernel, sodass zwangsläufig dieselbe Junos-Version ausgeführt wird, abgesehen davon, dass die Routing-Engine und die Linecard physische Ressourcen wie CPU, Arbeitsspeicher und Speicher gemeinsam nutzen müssen. Beim Junos Node Slicing erhält jeder GNF sein eigenes Äquivalent eines Routing-Engines-Paares sowie Linecards, die diesem GNF zugeordnet sind, sodass die GNFs nicht die meisten physischen Ressourcen gemeinsam nutzen, sondern nur das Gehäuse und die Switch-Fabric. GNFs können im Gegensatz zu logischen Systemen wie ein eigenständiger MX-Router unabhängig voneinander aufgerüstet und verwaltet werden.

Junos Node Slicing ist eine Technologie, die logische Systeme ergänzt oder sogar erweitert, da ein GNF selbst mehrere logische Systeme enthalten kann. Wenn physische Isolation, garantierte Ressourcen und vollständige administrative Isolation von größter Bedeutung sind, ist Junos Node Slicing die bessere Wahl. Und wenn eine feine Granularität der Freigabe bis hinunter zur logischen Schnittstellenebene von größter Bedeutung ist, wäre ein logisches System die bessere Wahl.

Lizenzierung für Junos Node Slicing

Für den Betrieb von Junos Node Slicing sind Lizenzen für die GNFs und abstrahierten Fabric-Schnittstellen erforderlich, die an der BSYS installiert werden müssen. Das Ausführen eines GNF ohne installierte Lizenz am BSYS führt zu der folgenden Syslog-Meldung und einem kleinen Alarm:

Wenden Sie sich an Juniper Networks, wenn Sie Fragen zu Junos Node Slicing-Lizenzen haben.