AUF DIESER SEITE
Konfigurieren eines Routers der MX-Serie für den Betrieb im BSYS-Modus (externes Servermodell)
Installieren des JDM-RPM-Pakets auf x86-Servern mit RHEL (externes Servermodell)
Installieren des JDM-Ubuntu-Pakets auf x86-Servern mit Ubuntu 20.04 (externes Servermodell)
Konfigurieren von Nicht-Root-Benutzern in JDM (Junos Node Slicing)
Konfigurieren des Routers der MX-Serie für den Betrieb im Gehäusemodus
Installieren und Konfigurieren von JDM für In-Chassis-Modelle
Konfigurieren von abstrahierten Fabric-Schnittstellen zwischen einem Paar von GNFs
Optimieren des Fabric-Pfads für eine abstrahierte Fabric-Schnittstelle
SNMP-Trap-Unterstützung: Konfigurieren des NMS-Servers (externes Servermodell)
Einrichten von Junos Node Slicing
Wenn Sie das externe Servermodell verwenden, müssen Sie die im Kapitel Vorbereiten der Einrichtung von Junos Node Slicing beschriebenen Verfahren abgeschlossen haben, bevor Sie mit dem Einrichten des Junos Node Slicing fortfahren.
Konfigurieren eines Routers der MX-Serie für den Betrieb im BSYS-Modus (externes Servermodell)
Stellen Sie sicher, dass der Router der MX-Serie mit den x86-Servern verbunden ist, wie unter Verbinden der Server und des Routers beschrieben.
Für Junos Node Slicing muss der Router der MX-Serie als Basissystem (BSYS) fungieren.
Führen Sie die folgenden Schritte aus, um einen Router der MX-Serie für den Betrieb im BSYS-Modus zu konfigurieren:
Von einem Router im BSYS-Modus wird nicht erwartet, dass er andere Funktionen ausführt als die, die zum Ausführen der grundlegenden Verwaltungsfunktionen in Junos Node Slicing erforderlich sind. Es wird z. B. nicht erwartet, dass das BSYS über Schnittstellenkonfigurationen verfügt, die den im System installierten Linecards zugeordnet sind. Stattdessen verfügen Gastnetzwerkfunktionen (GNFs) über die vollwertigen Routerkonfigurationen.
Installieren des JDM-RPM-Pakets auf x86-Servern mit RHEL (externes Servermodell)
Stellen Sie vor der Installation des JDM-RPM-Pakets für x86-Server sicher, dass Sie die zusätzlichen Pakete installiert haben, wie unter Installieren zusätzlicher Pakete für JDM beschrieben.
Laden Sie das JDM-RPM-Paket für x86-Server mit RHEL wie folgt herunter, und installieren Sie es:
Um das Paket auf x86-Servern mit RHEL zu installieren, führen Sie auf jedem der Server die folgenden Schritte aus:
Wiederholen Sie die Schritte für den zweiten Server.
Installieren des JDM-Ubuntu-Pakets auf x86-Servern mit Ubuntu 20.04 (externes Servermodell)
Stellen Sie vor der Installation des JDM-Ubuntu-Pakets für x86-Server sicher, dass Sie die zusätzlichen Pakete installiert haben. Weitere Informationen finden Sie unter Zusätzliche Pakete für JDM installieren.
Laden Sie das JDM-Ubuntu-Paket für x86-Server mit Ubuntu 20.04 wie folgt herunter und installieren Sie es:
Um das JDM-Paket auf den x86-Servern unter Ubuntu 20.04 zu installieren, führen Sie auf jedem der Server die folgenden Schritte aus:
Wiederholen Sie die Schritte für den zweiten Server.
JDM auf x86-Servern konfigurieren (externes Servermodell)
Führen Sie die folgenden Schritte aus, um JDM auf jedem der x86-Server zu konfigurieren.
Konfigurieren von Nicht-Root-Benutzern in JDM (Junos Node Slicing)
Im externen Servermodell können Sie ab Junos OS Version 18.3R1 Nicht-Root-Benutzer im Juniper Device Manager (JDM) für Junos Node Slicing erstellen. Sie benötigen ein Root-Konto, um einen Nicht-Root-Benutzer zu erstellen. Die Nicht-Root-Benutzer können sich über die JDM-Konsole oder über SSH bei JDM anmelden. Jedem Nicht-Root-Benutzer wird ein Benutzername zugewiesen und eine vordefinierte Anmeldeklasse zugewiesen.
Die Nicht-Root-Benutzer können die folgenden Funktionen ausführen:
Interagieren Sie mit JDM.
Orchestrieren und Verwalten von Gastnetzwerkfunktionen (GNFs).
Überwachen Sie den Status des JDM, des Hostservers und der GNFs mithilfe von JDM-CLI-Befehlen.
Die Nicht-Root-Benutzerkonten funktionieren nur innerhalb von JDM, nicht auf dem Hostserver.
So erstellen Sie Nicht-Root-Benutzer in JDM:
Tabelle 1 enthält die vordefinierten Anmeldeklassen, die JDM für Nicht-Root-Benutzer unterstützt:
Login-Klasse |
Erlaubnisse |
|---|---|
Superuser |
|
Operator |
|
schreibgeschützt |
Ähnlich wie die Operator-Klasse, mit dem Unterschied, dass die Benutzer Daemons nicht innerhalb von JDM neu starten können. |
unbefugt |
Ping- und Traceroute-Operationen. |
JDM-Schnittstellen konfigurieren (externes Servermodell)
Wenn Sie die im JDM konfigurierten Serverschnittstellen ändern möchten, führen Sie die folgenden Schritte aus:
Im JDM müssen Sie Folgendes konfigurieren:
Die beiden 10-Gbit/s-Server-Ports, die mit dem Router der MX-Serie verbunden sind.
Der Serverport, der als JDM-Management-Port verwendet werden soll.
Der Serverport, der als GNF-Verwaltungsport verwendet werden soll.
Daher müssen Sie auf jedem Server Folgendes identifizieren, bevor Sie mit der Konfiguration der Ports beginnen:
Die Serverschnittstellen
p3p1(z. B. undp3p2), die mitCB0undCB1auf dem Router der MX-Serie verbunden sind.Die Serverschnittstellen
em2(z. B. undem3), die für die JDM-Verwaltung und die GNF-Verwaltung verwendet werden sollen.
Weitere Informationen finden Sie in der Abbildung Verbinden der Server und des Routers.
Sie benötigen diese Informationen sowohl für als auch
server0server1für .Diese Schnittstellen sind nur auf dem Linux-Host sichtbar.
Um die x86-Serverschnittstellen in JDM zu konfigurieren, führen Sie auf beiden Servern die folgenden Schritte aus:
JDM-Beispielkonfigurationen finden Sie unter Beispielkonfiguration für Junos Node Slicing.
Wenn Sie die im JDM konfigurierten Serverschnittstellen ändern möchten, müssen Sie die GNFs löschen (falls sie konfiguriert wurden), die Schnittstellen wie oben beschrieben konfigurieren, JDM von der Shell aus neu starten, die GNFs neu konfigurieren und aktivieren und die Änderungen übernehmen.
Ab Junos OS Version 19.2R1 unterstützt Junos Node Slicing die Zuweisung eines weltweit eindeutigen MAC-Adressbereichs (bereitgestellt von Juniper Networks) für GNFs.
Konfigurieren des Routers der MX-Serie für den Betrieb im Gehäusemodus
Um Junos Node Slicing im Gehäuse zu konfigurieren, muss auf dem Router der MX-Serie einer der folgenden Routing-Engines-Typen installiert sein:
-
RE-S-X6-128G (verwendet in MX480- und MX960-Routern)
-
REMX2K-X8-128G (verwendet in MX2010- und MX2020-Routern)
-
REMX2008-X8-128G (verwendet in MX2008-Routern)
-
Beim In-Chassis-Modell werden das Basissystem (BSYS), der Juniper Device Manager (JDM) und alle Gastnetzwerkfunktionen (GNFs) innerhalb der Routing-Engine des Routers der MX-Serie ausgeführt. BSYS und GNFs werden auf dem Host als virtuelle Maschinen (VMs) ausgeführt. Zunächst müssen Sie den Ressourcenbedarf des eigenständigen Routers der MX-Serie wie folgt reduzieren:
Alle Dateien am Speicherort /var/ , einschließlich der Protokolldateien (/var/log) und Coredateien (/var/crash), werden gelöscht, wenn Sie den VM-Host nach dem Konfigurieren der set vmhost resize vjunos compact Anweisung neu starten. Sie müssen alle Dateien speichern, die sich derzeit in /var/log oder /var/crash befinden, bevor Sie mit der Konfiguration der Größenänderung des VM-Hosts fortfahren, wenn Sie sie als Referenz verwenden möchten.
Installieren und Konfigurieren von JDM für In-Chassis-Modelle
Die in diesem Thema aufgeführten Schritte gelten nur für die Junos Nodes Slicing-Konfiguration im Gehäuse.
- Installieren des JDM-RPM-Pakets auf einem Router der MX-Serie (In-Chassis-Modell)
- JDM konfigurieren (In-Chassis-Modell)
Installieren des JDM-RPM-Pakets auf einem Router der MX-Serie (In-Chassis-Modell)
Bevor Sie das Juniper Device Manager (JDM) RPM-Paket auf einem Router der MX-Serie installieren, müssen Sie den Router der MX-Serie so konfigurieren, dass er im BSYS-Modus im Gehäuse betrieben werden kann. Weitere Informationen finden Sie unter Konfigurieren des Routers der MX-Serie für den Betrieb im Gehäusemodus.
Das RPM-Paket jns-jdm-vmhost ist für die Bereitstellung von Junos Node Slicing im Gehäuse vorgesehen, während das RPM-Paket jns-jdm für externe Server verwendet wird, die auf Junos Node Slicing basieren.
JDM konfigurieren (In-Chassis-Modell)
Führen Sie die folgenden Schritte aus, um JDM auf beiden Routing-Engines eines Routers der MX-Serie zu konfigurieren:
Beim In-Chassis Junos Node Slicing ist es nicht möglich, Datenverkehr zwischen den Verwaltungsschnittstellen derselben Routing-Engine anzupingen oder zu senden (z. B. von der Routing-Engine 0 von GNF1 zur Routing-Engine 0 von GNF2 oder von der Routing-Engine 0 von GNF1 zu JDM).
Im In-Chassis-Modus können Sie keine
scpOperation zwischen der BSYS- und der JDM-Verwaltungsschnittstelle ausführen.Sie müssen den SSH-Schlüsselaustausch wie in Schritt 7 beschrieben durchgeführt haben, bevor Sie Schritt 8 versuchen. Wenn Sie Schritt 8 ausführen, ohne Schritt 7 abzuschließen, zeigt das System eine Fehlermeldung an, wie im folgenden Beispiel gezeigt:
Failed to fetch JDM software version from server1. If authentication of peer server is not done yet, try running request server authenticate-peer-server.
Ab Junos OS Version 19.2R1 unterstützt Junos Node Slicing die Zuweisung eines weltweit eindeutigen MAC-Adressbereichs (bereitgestellt von Juniper Networks) für GNFs.
Zuweisen von MAC-Adressen zum GNF
Ab Junos OS Version 19.2R1 unterstützt Junos Node Slicing die Zuweisung eines weltweit eindeutigen MAC-Adressbereichs (bereitgestellt von Juniper Networks) für GNFs.
Um den weltweit eindeutigen MAC-Adressbereich für die GNFs zu erhalten, wenden Sie sich an Ihren Ansprechpartner bei Juniper Networks und geben Sie Ihre GNF-Lizenz-SSRN (Software Support Reference Number) an, die Ihnen beim Kauf der GNF-Lizenz elektronisch zugesandt wurde. Informationen zur Verwendung der SSRN in Ihrer GNF-Lizenz finden Sie im Artikel KB11364 der Wissensdatenbank von Juniper Networks.
Für jede GNF-Lizenz erhalten Sie dann eine "erweiterte SSRN", die den weltweit eindeutigen MAC-Adressbereich enthält, der von Juniper Networks für diese GNF-Lizenz zugewiesen wurde. Anschließend müssen Sie diese erweiterte SSRN in der JDM-CLI wie folgt konfigurieren:
root@jdm#set system vnf-license-supplement vnf-id gnf-id license-supplement-string augmented-ssrn-stringroot@jdm#commit
Eine erweiterte SSRN darf nur für eine GNF-ID verwendet werden. Im JDM werden die GNF-VMs als virtuelle Netzwerkfunktionen (VNFs) bezeichnet. Die GNF-ID ist eines seiner Attribute. Die Attribute einer VNF werden im folgenden Abschnitt Gastnetzwerkfunktionen konfigurieren ausführlich beschrieben.
Standardmäßig wird die erweiterte SSRN validiert. Sollten Sie diese Validierung einmal überspringen müssen, können Sie das Attribut no-validate in der CLI wie folgt verwenden: Beispiel:
set system vnf-license-supplement vnf-id gnf-id license-supplement-string augmented-ssrn-string [no-validate].
Sie können die erweiterte SSRN nur dann für eine GNF-ID konfigurieren, wenn die GNF nicht betriebsbereit ist und noch nicht bereitgestellt wurde. Sie müssen zuerst die erweiterte SSRN für eine GNF-ID konfigurieren, bevor Sie die GNF konfigurieren. Wenn die GNF-ID bereits bereitgestellt wurde, müssen Sie zuerst die GNF für diese GNF-ID auf beiden Servern (im Falle des externen Servermodells) oder auf beiden Routing-Engines (im Fall des Junos Node Slicing-Modells im Gehäuse) löschen, bevor Sie die erweiterte SSRN konfigurieren.
Ebenso müssen Sie zuerst die GNF für eine bestimmte GNF-ID auf beiden Servern (im Falle des externen Servermodells) oder auf beiden Routing-Engines (im Fall des Junos-Node Slicing-Modells im Gehäuse) löschen, bevor Sie die erweiterte SSRN für die GNF-ID löschen.
Sie können keine erweiterte SSRN auf eine GNF anwenden, die auf Junos OS 19.1R1 oder älter basiert.
Verwenden Sie den Junos CLI-Befehl
show chassis mac-addresses, um zu bestätigen, dass der zugewiesene MAC-Adressbereich für eine GNF angewendet wurde, wenn die GNF in Betrieb genommen wird – die Ausgabe stimmt mit einer Teilzeichenfolge der erweiterten SSRN überein.
Konfigurieren von Gastnetzwerkfunktionen
Die Konfiguration einer Gastnetzwerkfunktion (GNF) umfasst zwei Aufgaben, von denen eine am BSYS und die andere am JDM ausgeführt wird.
- Bevor Sie versuchen, eine GNF zu erstellen, müssen Sie sicherstellen, dass Sie die Commit-Synchronisation als Teil der JDM-Konfiguration konfiguriert haben, damit die zufälligen MAC-Präfixe, die von den JDM-Instanzen generiert werden, synchron sind. Um zu überprüfen, ob die zufälligen MAC-Präfixe synchron sind, verwenden Sie den CLI-Befehl
show server connectionsodershow system random-mac-prefixbei JDM. Wenn die zufälligen MAC-Präfixe nicht synchron sind, löst die Software den folgenden Hauptalarm aus:Mismatched MAC address pool between GNF RE0 and GNF RE1. Um den Alarm anzuzeigen, verwenden Sie den Befehl show system alarms. -
Bevor Sie versuchen, eine GNF zu erstellen, müssen Sie sicherstellen, dass die Server (oder Routing-Engines im Fall des In-Chassis-Modells) über ausreichende Ressourcen (CPU, Arbeitsspeicher, Speicher) für diese GNF verfügen.
-
Sie müssen jedem GNF eine ID zuweisen. Diese ID muss am BSYS und am JDM identisch sein.
Geben Sie im BSYS eine GNF an, indem Sie ihr eine ID und einen Satz von Linecards zuweisen, indem Sie die Konfiguration anwenden, wie im folgenden Beispiel gezeigt:
user@router# set chassis network-slices guest-network-functions gnf 1 fpcs 4
user@router# commit
Im JDM werden die GNF-VMs als virtuelle Netzwerkfunktionen (VNFs) bezeichnet. Eine VNF hat die 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.
-
Ein Junos OS-Image für die GNF, das von der Juniper-Downloadseite heruntergeladen werden kann.
Wählen Sie auf der Seite "Downloads " die Option "Alle Produkte > Junos Node Slicing – Guest Network Function " aus, um ein Junos-Image für die GNF herunterzuladen.
Die VNF-Serverressourcenvorlage.
Führen Sie im JDM die folgenden Schritte aus, um eine VNF zu konfigurieren:
Verwenden Sie den JDM-Shell-Befehl
scp, um das Junos OS Node Slicing-Image für GNF abzurufen und im lokalen JDM-Verzeichnis /var/jdm-usr/gnf-images abzulegen (wiederholen Sie diesen Schritt, um die GNF-Konfigurationsdatei abzurufen).root@jdm:~#
scp source-location-of-the-gnf-image /var/jdm-usr/gnf-imagesroot@jdm:~#scp source-location-of-the-gnf-configuration-file /var/jdm-usr/gnf-configWeisen Sie dieses Image einer GNF zu, indem Sie den Befehl JDM CLI verwenden, wie im folgenden Beispiel gezeigt:
root@test-jdm-server0>
request virtual-network-functions test-gnf add-image /var/jdm-usr/gnf-images/junos-install-ns-mx-x86-64-17.4R1.10.tgz all-serversServer0: Added image: /vm-primary/test-gnf/test-gnf.img Server1: Added image: /vm-primary/test-gnf/test-gnf.img-
Konfigurieren Sie die VNF, indem Sie die Konfigurationsanweisungen anwenden, wie im folgenden Beispiel gezeigt:
root@test-jdm-server0#
set virtual-network-functionstest-gnfid1root@test-jdm-server0#
set virtual-network-functionstest-gnfchassis-type mx2020root@test-jdm-server0#
set virtual-network-functionstest-gnfresource-template2core-16groot@test-jdm-server0#
set system vnf-license-supplement vnf-id 1 license-supplement-string RTU00023003204-01-AABBCCDDEE00-1100-01-411CKonfigurieren Sie für In-Chassis-Modelle nicht den Plattformtyp (
set virtual-network-functionstest-gnfchassis-type mx2020). Es wird automatisch erkannt.Ab Junos OS Version 19.2R1 unterstützt Junos Node Slicing die Zuweisung eines weltweit eindeutigen MAC-Adressbereichs (bereitgestellt von Juniper Networks) für GNFs.
Wenn Sie auch eine Baseline- oder anfängliche Junos OS-Konfiguration für eine GNF angeben möchten, bereiten Sie die GNF-Konfigurationsdatei (Beispiel: /var/jdm-usr/gnf-config/test-gnf.conf) sowohl auf den Servern (server0 und server1) für das externe Servermodell als auch auf den Routing-Engines (re0 und re1) für das In-Chassis-Modell vor und geben Sie den Dateinamen als Parameter in der
base-configAnweisung an, wie unten gezeigt:root@test-jdm-server0#
set virtual-network-functions test-gnf base-config /var/jdm-usr/gnf-config/test-gnf.confroot@test-jdm-server0#
commit synchronizeAnmerkung:Stellen Sie sicher, dass:
-
Sie verwenden dieselbe GNF-ID wie diejenige, die zuvor in BSYS angegeben wurde.
-
Der Dateiname der Basiskonfiguration (mit dem Pfad) ist auf beiden Servern bzw. Routingmodulen identisch.
-
Die Syntax des Inhalts der Baselinedatei ist im Junos OS-Konfigurationsformat.
-
Der hier verwendete GNF-Name ist derselbe wie der, der dem Junos OS-Image für GNF in Schritt 2 zugewiesen wurde.
-
Um zu überprüfen, ob die VNF erstellt wurde, führen Sie den folgenden JDM-CLI-Befehl aus:
root@test-jdm-server0>
show virtual-network-functions test-gnfMelden Sie sich bei der VNF-Konsole an, indem Sie den folgenden JDM-CLI-Befehl ausführen:
root@test-jdm-server0>
request virtual-network-functions test-gnf consoleAnmerkung:Denken Sie daran, sich von der VNF-Konsole abzumelden, nachdem Sie Ihre Konfigurationsaufgaben abgeschlossen haben. Es wird empfohlen, ein Leerlauf-Timeout mit dem Befehl
set system login idle-timeout minutesfestzulegen. Andernfalls, wenn ein Benutzer vergisst, sich von der VNF-Konsolensitzung abzumelden, kann sich ein anderer Benutzer anmelden, ohne die Anmeldeinformationen anzugeben. Weitere Informationen finden Sie unter Systemanmeldung (Junos Node Slicing).Konfigurieren Sie die VNF auf die gleiche Weise wie eine Routing-Engine der MX-Serie.
Die CLI-Eingabeaufforderung für das In-Chassis-Modell lautet
root@jdm#.Beispielkonfigurationen finden Sie unter Beispielkonfiguration für Junos Node Slicing.
Wenn Sie im Falle des externen Servermodells zuvor physische x86-CB-Schnittstellen oder die GNF-Verwaltungsschnittstelle von der Linux-Shell heruntergefahren haben (mit dem Befehl
ifconfig interface-name down), werden diese automatisch beim Start des GNF aufgerufen.
Konfigurieren von abstrahierten Fabric-Schnittstellen zwischen einem Paar von GNFs
Das Erstellen einer abstrahierten Fabric-Schnittstelle (af) zwischen zwei Gastnetzwerkfunktionen (GNFs) umfasst Konfigurationen sowohl am Basissystem (BSYS) als auch am GNF. Abstrahierte Fabric-Schnittstellen werden auf GNFs basierend auf der BSYS-Konfiguration erstellt, die dann an diese GNFs gesendet wird.
-
Zwischen einem Paar von GNFs kann nur eine
afSchnittstelle konfiguriert werden. - In einem Junos Node Slicing-Setup, bei dem jeder GNF eine einzelne FPC zugewiesen ist, fällt die zugehörige abstrahierte Fabric-Schnittstelle aus, wenn die Packet Forwarding Engines der FPC, die der Remote-GNF zugewiesen sind, über die Fabric nicht mehr erreichbar sind. Beispiele für Fehler, die dieses Verhalten verursachen können, sind PFE-Fabric-Erreichbarkeitsfehler und CMERROR-Ereignisse, die eine Aktion auslösen
pfe disable(verwenden Sie denshow chassis fpc errorsBefehl für die Details). Wenn einem GNF mehrere FPCs zugewiesen sind, werden die lokalen FPCs, die melden, dass alle Peer-Paketweiterleitungs-Engines ausgefallen sind, von der Bestimmung des abstrahierten Fabric-Schnittstellenstatus entfernt.
So konfigurieren af Sie Schnittstellen zwischen einem GNF-Paar:
-
Wenden Sie am BSYS die Konfiguration wie im folgenden Beispiel gezeigt an:
user@router#
set chassis network-slices guest-network-functions gnf 2 af4 peer-gnf id 4user@router#set chassis network-slices guest-network-functions gnf 2 af4 peer-gnf af2user@router#set chassis network-slices guest-network-functions gnf 4 af2 peer-gnf id 2user@router#set chassis network-slices guest-network-functions gnf 4 af2 peer-gnf af4In diesem Beispiel
af2ist die abstrahierte Fabric-Schnittstelleninstanz 2 undaf4die abstrahierte Fabric-Schnittstelleninstanz 4.Anmerkung:Die zulässigen
afSchnittstellenwerte reichen vonaf0bisaf9.Die GNF-Schnittstelle
afist sichtbar und aktiv. Sie können eineafSchnittstelle wie jede andere Schnittstelle konfigurieren. Wenden Sie im GNF die Konfiguration wie im folgenden Beispiel gezeigt an:
user@router-gnf-b#
set interfaces af4 unit 0 family inet address 10.10.10.1/24user@router-gnf-d#set interfaces af2 unit 0 family inet address 10.10.10.2/24
Wenn Sie Konfigurationen der MPLS-Familie auf die
afSchnittstellen anwenden möchten, können Sie den Befehlset interfaces af-name unit logical-unit-number family mplsauf beide GNFs anwenden, zwischen denen dieafSchnittstelle konfiguriert ist.Beispielkonfigurationen
affinden Sie unter Beispielkonfiguration für Junos Node Slicing.
Class of Service für abstrahierte Fabric-Schnittstellen
Die Class of Service (CoS)-Paketklassifizierung weist ein eingehendes Paket basierend auf der Weiterleitungsklasse des Pakets einer Ausgabewarteschlange zu. Weitere Informationen finden Sie im CoS-Konfigurationsleitfaden .
In den folgenden Abschnitten werden die Weiterleitungszuordnung von Klassen zu Warteschlangen sowie die Verhaltensaggregat-Klassifizierer (BA) und Umschreibungen erläutert, die von den abstrahierten Fabricschnittstellen (af) unterstützt werden.
Weiterleiten von Klassen-zu-Warteschlangen-Zuordnungen
Eine af Schnittstelle ist eine simulierte WAN-Schnittstelle mit den meisten Funktionen jeder anderen Schnittstelle, mit der Ausnahme, dass der Datenverkehr, der einer Remote-Paketweiterleitungs-Engine zugewiesen ist, weiterhin die beiden Fabric-Warteschlangen (niedrige/hohe Priorität) durchlaufen muss.
Derzeit arbeitet eine af Schnittstelle nur im 2-Warteschlangen-Modus. Daher sind alle warteschlangenbasierten Funktionen wie Planung, Überwachung und Strukturierung nicht auf einer af Schnittstelle verfügbar.
Pakete auf der af Schnittstelle erben die Fabric-Warteschlange, die durch die Fabric-Priorität bestimmt wird, die für die Weiterleitungsklasse konfiguriert ist, zu der das Paket gehört. Sehen Sie sich z. B. die folgende Konfiguration der Weiterleitungsklasse für die Warteschlange an:
[Bearbeiten]
user@router# show class-of-service forwarding-classes
class Economy queue-num 0 priority low; /* Low fabric priority */
class Stream queue-num 1;
class Business queue-num 2;
class Voice queue-num 3;
class NetControl queue-num 3;
class Business2 queue-num 4;
class Business3 queue-num 5;
class VoiceSig queue-num 6 priority high; /* High fabric priority */
class VoiceRTP queue-num 7;
Wie im vorherigen Beispiel gezeigt, untersucht der Code im Weiterleitungspfad bei der Klassifizierung eines Pakets in die Weiterleitungsklasse VoiceSigdie Fabric-Priorität dieser Weiterleitungsklasse und entscheidet, welche Fabric-Warteschlange für dieses Paket ausgewählt werden soll. In diesem Fall wird die Fabric-Warteschlange mit hoher Priorität ausgewählt.
BA-Klassifikatoren und -Umschreibungen
Der BA-Klassifizierer (Behavior Aggregate) ordnet einen CoS-Wert (Class-of-Service) einer Weiterleitungsklasse und einer Verlustpriorität zu. Die Kombination aus Weiterleitungsklasse und Verlustpriorität bestimmt die CoS-Behandlung des Pakets im Router. Die folgenden BA-Klassifizierer und -Umschreibungen werden unterstützt:
Inet-Precedence-Klassifikator und -Umschreibung
DSCP-Klassifizierung und -Umschreibung
MPLS EXP-Klassifikator und -Umschreibung
Sie können auch Umschreibungen für IP-Pakete anwenden, die in den MPLS-Tunnel eingehen, und sowohl EXP- als auch IPv4-Service-Bits (ToS) neu schreiben. Dieser Ansatz funktioniert wie bei anderen normalen Schnittstellen.
DSCP v6-Klassifikator und -Umschreibung für IP v6-Datenverkehr
Folgendes wird nicht unterstützt:
IEEE 802.1-Klassifizierung und -Umschreibung
IEEE 802.1AD (QinQ)-Klassifizierung und -Umschreibung
Weitere Informationen zu CoS-BA-Klassifikatoren finden Sie im CoS-Konfigurationsleitfaden .
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.
user@router#set chassis network-slices guest-network-functions gnf id af-name collapsed-forward (monitor | optimize)user@router#commit
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.
Siehe auch
SNMP-Trap-Unterstützung: Konfigurieren des NMS-Servers (externes Servermodell)
Der Juniper Device Manager (JDM) unterstützt die folgenden SNMP-Traps:
LinkUp- und linkDown-Traps für JDM-Schnittstellen.
Es werden standardmäßige LinkUp/LinkDown-SNMP-Traps generiert. Es wird ein Standard-Community-String
jdmverwendet.LinkUp/LinkDown-Traps für Host-Schnittstellen.
Es werden standardmäßige
linkUp/linkDownSNMP-Traps generiert. Es wird ein Standard-Community-Stringhostverwendet.Fallen bei JDM-zu-JDM-Konnektivitätsverlust/-wiedergewinnung.
JDM-zu-JDM-Traps für den Verlust/die Wiedererlangung der Konnektivität werden mithilfe generischer Syslog-Traps (jnxSyslogTrap) über die Hostverwaltungsschnittstelle gesendet.
Der JDM-Konnektivitäts-Downtrap
JDM_JDM_LINK_DOWNwird gesendet, wenn das JDM nicht in der Lage ist, mit dem Peer-JDM auf einem anderen Servercb0odercb1einer anderen Verbindung zu kommunizieren. Sehen Sie sich das folgende Beispiel an:{ SNMPv2c C=host { V2Trap(296) R=1299287309 .1.3.6.1.2.1.1.3.0=42761992 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.2636.4.12.0.1 .1.3.6.1.4.1.2636.3.35.1.1.1.2.1="JDM_JDM_LINK_DOWN" .1.3.6.1.4.1.2636.3.35.1.1.1.3.1="" .1.3.6.1.4.1.2636.3.35.1.1.1.4.1=5 .1.3.6.1.4.1.2636.3.35.1.1.1.5.1=24 .1.3.6.1.4.1.2636.3.35.1.1.1.6.1=0 .1.3.6.1.4.1.2636.3.35.1.1.1.7.1="jdmmon" .1.3.6.1.4.1.2636.3.35.1.1.1.8.1="JDM-HOST" .1.3.6.1.4.1.2636.3.35.1.1.1.9.1="JDM to JDM Connection Lost" .1.3.6.1.6.3.1.1.4.3.0.0=”” } }Der JDM-zu-JDM-Konnektivitäts-Up-Trap
JDM_JDM_LINK_UPwird gesendet, wenn entweder die oder-Verbindungcb0cb1hergestellt wird, und JDMs auf beiden Servern können wieder kommunizieren. Sehen Sie sich das folgende Beispiel an:{ SNMPv2c C=host { V2Trap(292) R=998879760 .1.3.6.1.2.1.1.3.0=42762230 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.2636.4.12.0.1 .1.3.6.1.4.1.2636.3.35.1.1.1.2.1="JDM_JDM_LINK_UP" .1.3.6.1.4.1.2636.3.35.1.1.1.3.1="" .1.3.6.1.4.1.2636.3.35.1.1.1.4.1=5 .1.3.6.1.4.1.2636.3.35.1.1.1.5.1=24 .1.3.6.1.4.1.2636.3.35.1.1.1.6.1=0 .1.3.6.1.4.1.2636.3.35.1.1.1.7.1="jdmmon" .1.3.6.1.4.1.2636.3.35.1.1.1.8.1="JDM-HOST" .1.3.6.1.4.1.2636.3.35.1.1.1.9.1="JDM to JDM Connection Up" .1.3.6.1.6.3.1.1.4.3.0.0="" } }VM (GNF) up/down –
libvirtGuestNotifBenachrichtigungen.Für GNF-Start-/Shutdown-Ereignisse werden die Standardbenachrichtigungen
libvirtGuestNotifgeneriert. WeiterelibvirtMIBInformationen zu Benachrichtigungen finden Sie auf dieser Webseite. Sehen Sie sich auch das folgende Beispiel an:HOST [UDP: [127.0.0.1]:53568->[127.0.0.1]]: Trap , DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (636682) 1:46:06.82, SNMPv2-MIB::snmpTrapOID.0 = OID: LIBVIRT-MIB::libvirtGuestNotif, LIBVIRT-MIB::libvirtGuestName.0 = STRING: "gnf1", LIBVIRT-MIB::libvirtGuestUUID.1 = STRING: 7ad4bc2a-16db-d8c0-1f5a-6cb777e17cd8, LIBVIRT-MIB::libvirtGuestState.2 = INTEGER: running(1), LIBVIRT-MIB::libvirtGuestRowStatus.3 = INTEGER: active(1)
SNMP-Traps werden an den NMS-Zielserver gesendet. Informationen zur Konfiguration der NMS-Zielserverdetails im JDM finden Sie im folgenden Beispiel:
[Bearbeiten]
root@jdm#show snmp | display setroot@jdm#set snmp name nameroot@jdm#set snmp description descriptionroot@jdm#set snmp location locationroot@jdm#set snmp contact user's emailroot@jdm#set snmp trap-group tg-1 targets target ip address1root@jdm#set snmp trap-group tg-1 targets target ip address2
JDM schreibt keine Konfiguration in die SNMP-Konfigurationsdatei des Hosts (/etc/snmp/snmpd.conf). Daher haben die JDM-Installation und die anschließende Konfiguration keine Auswirkungen auf das Host-SNMP. Der CLI-Befehl SNMP-Konfiguration in JDM wird nur verwendet, um die Datei snmpd.conf des JDM zu konfigurieren, die im Container vorhanden ist. Um den linkUp/Down-Trap zu generieren, müssen Sie die Konfiguration, wie im folgenden Beispiel gezeigt, manuell in die Datei snmpd.conf des Hostservers (/etc/snmp/snmpd.conf) einfügen:
createUser trapUser iquerySecName trapUser rouser trapUser defaultMonitors yes notificationEvent linkUpTrap linkUp ifIndex ifAdminStatus ifOperStatus ifDescr notificationEvent linkDownTrap linkDown ifIndex ifAdminStatus ifOperStatus ifDescr monitor -r 10 -e linkUpTrap "Generate linkUp" ifOperStatus != 2 monitor -r 10 -e linkDownTrap "Generate linkDown" ifOperStatus == 2 trap2sink <NMS-IP> host
Ersetzen Sie im obigen Beispiel <NMS-IP> durch die IP-Adresse der Network Management Station (NMS).
Chassis-Konfigurationshierarchie bei BSYS und GNF
Beim Junos Node Slicing besitzt das BSYS alle physischen Komponenten des Routers, einschließlich der Linecards und der Fabric, während die GNFs den Weiterleitungsstatus auf ihren jeweiligen Linecards beibehalten. Im Einklang mit dieser geteilten Verantwortung sollte die Junos CLI-Konfiguration unter der chassis Hierarchie (falls vorhanden) am BSYS oder am GNF wie folgt angewendet werden:
Parameter auf physischer Ebene unter der
chassisKonfigurationshierarchie sollten am BSYS angewendet werden. Beispielsweise ist die Konfiguration für die Behandlung physischer Fehler in einem FPC ein Parameter auf physikalischer Ebene und sollte daher auf das BSYS angewendet werden.At BSYS Junos CLI: [edit] user@router#
set chassis fpc fpc slot error major threshold threshold value action alarmLogische Parameter oder Parameter auf Feature-Ebene unter der
chassisKonfigurationshierarchie sollten auf den GNF angewendet werden, der dem FPC zugeordnet ist. Beispielsweise ist die Konfiguration für max-queues pro Linecard ein Parameter auf logischer Ebene und sollte daher auf den GNF angewendet werden.At GNF Junos CLI: [edit] user@router#
set chassis fpc fpc slot max-queues valueAusnahmsweise sollten die folgenden beiden Parameter unter der
chassisKonfigurationshierarchie sowohl bei BSYS als auch bei GNF angewendet werden:At both BSYS and GNF CLI: [edit] user@router#
set chassis network-services network services modeuser@router#set chassis fpc fpc slot flexible-queueing-mode
Konfigurieren von Sub Line Cards und Zuweisen zu GNFs
Eine Übersicht über untergeordnete Linecards finden Sie unter Übersicht über untergeordnete Linecards.
-
Diese Funktion gilt für die MPC11E-Linecard (Modellnummer: MX2K-MPC11E) auf den MX2010- und MX2020-Routern, die in der externen serverbasierten Junos-Node Slicing-Einrichtung verwendet werden.
-
Stellen Sie sicher, dass auf jeder Routing-Engine aller GNFs und im BSYS Junos OS Version 21.2R1 oder höher ausgeführt wird.
Um eine MPC11E weiter in Unterlinecards (SLCs) aufzuteilen, müssen Sie die fpc-slice CLI-Option unter der set chassis network-slices guest-network-functions gnf Hierarchie in BSYS verwenden.
Bevor Sie die Konfiguration bestätigen, müssen Sie alle von der Linecard unterstützten SLCs konfigurieren und den SLCs alle erforderlichen Ressourcen wie Core, DRAM und Paketweiterleitungsmodule zuweisen. Eine MPC11E-Linecard unterstützt zwei SLCs.
GNFs unterstützen die folgenden Kombinationen aus vollständigen Linecards und SLCs:
-
GNF mit MPC11E SLCs
-
GNF mit MPC11E SLCs und MPC9
-
GNF mit MPC11E SLCs und MPC11E
-
GNF mit MPC11E SLCs, MPC9, MPC11E
Führen Sie die folgenden Schritte aus, um SLCs zu konfigurieren und GNFs zuzuweisen:
-
Sie müssen alle folgenden CLI-Anweisungen gleichzeitig für alle SLCs konfigurieren (wie in den folgenden Schritten gezeigt). Jede spätere Änderung an dieser Konfiguration führt dazu, dass die gesamte Linecard neu gestartet wird.
- Wenn Sie falsche Werte konfigurieren (z. B. nicht unterstützte Paketweiterleitungs-Engine-Bereiche, CPU-Kerne oder DRAM-Werte), schlägt der Konfigurationscommit mit einer entsprechenden Meldung fehl, die auf den Fehler hinweist.
Siehe auch
Beispielkonfiguration für Junos Node Slicing
In diesem Abschnitt finden Sie Beispielkonfigurationen für das Junos Node Slicing.
- JDM-Beispielkonfiguration (externes Servermodell)
- JDM-Beispielkonfiguration (In-Chassis-Modell)
- Beispiel für eine BSYS-Konfiguration mit abstrahierter Fabric-Schnittstelle
- Beispiel für eine abstrahierte Fabric-Konfiguration bei GNF mit Class of Service
- Beispielausgabe für den abstrahierten Fabric-Schnittstellenstatus bei einem GNF
JDM-Beispielkonfiguration (externes Servermodell)
root@test-jdm-server0> show configuration
groups {
server0 {
system {
host-name test-jdm-server0;
}
server {
interfaces {
cb0 p3p1;
cb1 p3p2;
jdm-management em2;
vnf-management em3;
}
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.112/21;
}
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
server1 {
system {
host-name test-jdm-server1;
}
server {
interfaces {
cb0 p3p1;
cb1 p3p2;
jdm-management em2;
vnf-management em3;
}
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.113/21;
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
}
}
apply-groups [ server0 server1 ];
system {
root-authentication {
encrypted-password "..."; ## SECRET-DATA
}
services {
ssh;
netconf {
ssh;
rfc-compliant;
}
}
}
virtual-network-functions {
test-gnf {
id 1;
chassis-type mx2020;
resource-template 2core-16g;
base-config /var/jdm-usr/gnf-config/test-gnf.conf;
}
}
JDM-Beispielkonfiguration (In-Chassis-Modell)
root@test-jdm-server0> show configuration
groups {
server0 {
system {
host-name test-jdm-server0;
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.112/21;
}
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
server1 {
system {
host-name test-jdm-server1;
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.113/21;
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
}
}
apply-groups [ server0 server1 ];
system {
root-authentication {
encrypted-password "..."; ## SECRET-DATA
}
services {
ssh;
netconf {
ssh;
rfc-compliant;
}
}
}
virtual-network-functions {
test-gnf {
id 1;
resource-template 2core-16g;
base-config /var/jdm-usr/gnf-config/test-gnf.conf;
}
}
Beispiel für eine BSYS-Konfiguration mit abstrahierter Fabric-Schnittstelle
user@router> show configuration chassis
network-slices {
guest-network-functions {
gnf 1 {
af2 {
peer-gnf id 2 af1;
}
af4 {
peer-gnf id 4 af1;
}
description gnf-a;
fpcs [ 0 19];
}
gnf 2 {
af1 {
peer-gnf id 1 af2;
}
af4 {
peer-gnf id 4 af2;
}
description gnf-b;
fpcs [ 1 6 ];
}
gnf 4 {
af1 {
peer-gnf id 1 af4;
}
af2 {
peer-gnf id 2 af4;
}
description gnf-d;
fpcs [ 3 4 ];
}
}
}
Beispiel für eine abstrahierte Fabric-Konfiguration bei GNF mit Class of Service
Angenommen, es gibt eine abstrahierte Fabric(af)-Schnittstelle zwischen GNF1 und GNF2. Die folgende Beispielkonfiguration veranschaulicht, wie in einem Szenario, in dem Datenverkehr von GNF1 zu GNF2 kommt, Umschreibungen auf die af Schnittstelle bei GNF1 und Klassifizierer auf die Schnittstelle auf GNF2 af angewendet werden:
GNF1 Configuration
interfaces {
xe-4/0/0 {
unit 0 {
family inet {
address 22.1.2.2/24;
}
}
}
af2 {
unit 0 {
family inet {
address 32.1.2.1/24;
}
}
}
}
class-of-service {
classifiers {
dscp testdscp {
forwarding-class assured-forwarding {
loss-priority low code-points [ 001001 000000 ];
}
}
}
interfaces {
xe-4/0/0 {
unit 0 {
classifiers {
dscp testdscp;
}
}
classifiers {
dscp testdscp;
}
}
af1 {
unit 0 {
rewrite-rules {
dscp testdscp; /*Rewrite rule applied on egress AF interface on GNF1.*/
}
}
}
}
rewrite-rules {
dscp testdscp {
forwarding-class assured-forwarding {
loss-priority low code-point 001001;
}
}
}
}
GNF2 Configuration
interfaces {
xe-3/0/0:0 {
unit 0 {
family inet {
address 42.1.2.1/24;
}
}
}
af1 {
unit 0 {
family inet {
address 32.1.2.2/24;
}
}
}
}
class-of-service {
classifiers {
dscp testdscp {
forwarding-class network-control {
loss-priority low code-points 001001;
}
}
}
interfaces {
af1 {
unit 0 {
classifiers {
dscp testdscp; /*Classifier applied on AF at ingress of GNF2*/
}
}
}
}
}
Beispielausgabe für den abstrahierten Fabric-Schnittstellenstatus bei einem GNF
user@router-gnf-b> show interfaces af9
Physical interface: af9, Enabled, Physical link is Up
Interface index: 209, SNMP ifIndex: 527
Type: Ethernet, Link-level type: Ethernet, MTU: 1514, Speed: 370000mbps
Device flags : Present Running
Interface flags: Internal: 0x4000
Link type : Full-Duplex
Link flags : None
Current address: 00:90:69:2b:00:4c, Hardware address: 00:90:69:2b:00:4c
Last flapped : 2018-09-12 01:44:01 PDT (00:01:02 ago)
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
Bandwidth : 370 Gbps
Peer GNF id : 9
Peer GNF Forwarding element(FE) view :
FPC slot:FE num FE Bandwidth(Gbps) Status Transmit Packets Transmit Bytes
6:0 130 Up 0 0
12:0 120 Up 0 0
12:1 120 Up 0 0
Residual Transmit Statistics :
Packets : 0 Bytes : 0
Fabric Queue Statistics :
FPC slot:FE num High priority(pkts) Low priority(pkts)
6:0 0 0
12:0 0 0
12:1 0 0
FPC slot:FE num High priority(bytes) Low priority(bytes)
6:0 0 0
12:0 0 0
12:1 0 0
Residual Queue Statistics :
High priority(pkts) Low priority(pkts)
0 0
High priority(bytes) Low priority(bytes)
0 0
Logical interface af9.0 (Index 332) (SNMP ifIndex 528)
Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2
Input packets : 0
Output packets: 13
Protocol inet, MTU: 1500
Beispielkonfiguration für Sub Line Cards
Dieser Abschnitt enthält Beispielkonfigurationen für Sub Line Cards (SLCs).
- Beispielkonfiguration für das symmetrische Sub-Linecard-Profil
- Beispielkonfiguration für das asymmetrische Sub-Linecard-Profil
Beispielkonfiguration für das symmetrische Sub-Linecard-Profil
Im symmetrischen Profil ist nur eine Kombination von Ressourcen möglich.
Im Folgenden finden Sie eine Beispielkonfiguration zum Aufteilen von FPC 1 (MPC11E) im symmetrischen Sub-Linecard-Profil:
set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 pfe-id-list 0-3set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 cores 4set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 dram 13set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 pfe-id-list 4-7set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 cores 4set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 dram 13
Diese Konfiguration würde wie folgt aussehen:
root@bsys> show chassis network-slices guest-network-functions
gnf 1{
fpc-slice {
fpc 1{
slc 1{
pfe-id-list 0-3;
cores 4;
dram 13;
}
}
}
}
gnf 2{
fpc-slice {
fpc 1{
slc 2{
pfe-id-list 4-7;
cores 4;
dram 13;
}
}
}
}
Beispielkonfiguration für das asymmetrische Sub-Linecard-Profil
Im asymmetrischen Profil sind zwei Konfigurationen möglich, je nachdem, wie die PFEs oder Packet Forwarding Engines [0-7] auf die beiden SLCs aufgeteilt sind. In einer Beispielkonfiguration werden die ersten beiden Packet Forwarding Engines [0-1] einem SLC und die restlichen Packet Forwarding Engines [2-7] dem anderen SLC zugewiesen. In der anderen Beispielkonfiguration werden die letzten beiden Packet Forwarding Engines [6-7] einem SLC und die restlichen Packet Forwarding Engines [0-5] dem anderen SLC zugewiesen.
Die folgende Beispielkonfiguration ist ein Beispiel für die Aufteilung [0-1 2-7].
Im folgenden Beispiel stimmen die CPU-Kern- und DRAM-Zuweisungen für die SLCs mit einer der Spalten unter der Ressourcenkombination "Asymmetrisches Profil" überein, wie in der Tabelle "Von MPC11E unterstützte SLC-Profile " auf der Übersichtsseite "Sub Line Card " dargestellt.
set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 pfe-id-list 0-1set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 cores 4set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 dram 17set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 pfe-id-list 2-7set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 cores 4set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 dram 9
Diese Konfiguration würde wie folgt aussehen:
root@bsys> show chassis network-slices guest-network-functions
gnf 1{
fpc-slice {
fpc 1{
slc 1{
pfe-id-list 0-1;
cores 4;
dram 17;
}
}
}
}
gnf 2{
fpc-slice {
fpc 1{
slc 2{
pfe-id-list 2-7;
cores 4;
dram 9;
}
}
}
}