Présentation des fonctionnalités du NFX150

L’architecture logicielle du NFX150 est conçue pour fournir un plan de contrôle unifié qui fonctionne comme un point de gestion unique.

La figure 1 illustre l’architecture du NFX150.

Figure 1 : architecture NFX150

Les principaux composants du logiciel système sont les suivants :

• VNF : une VNF est une offre consolidée qui contient tous les composants nécessaires à la prise en charge d’un environnement réseau entièrement virtualisé. Vous pouvez configurer et utiliser des VNF tierces dans les chaînes de services.

• Plan de contrôle Junos (JCP) : le JCP est la machine virtuelle Junos qui s’exécute sur le système d’exploitation hôte, Wind River Linux. Le JCP fonctionne comme un point de gestion unique pour tous les composants. Le JCP contrôle le plan de données de couche 2, qui fournit les services de couche 2, et le plan de données de couche 3, qui fournit les services de couche 3 à 7.

  En plus de la gestion des châssis, JCP offre les fonctionnalités suivantes :

  • Configuration des fonctionnalités de sécurité avancées.

  • Gestion des fonctions réseau virtualisées invitées (VNF) au cours de leur cycle de vie.

  • Installation de VNF tierces.

  • Création de chaînes de services VNF.

  • Gestion des images VNF invitées (leurs fichiers binaires).

  • Gestion de l’inventaire du système et de l’utilisation des ressources.

  • Gestion de l’interface LTE.

• Juniper Device Manager (JDM) : conteneur d’applications qui gère les VNF et fournit des services d’infrastructure. Le JDM fonctionne en arrière-plan et les utilisateurs ne peuvent pas accéder directement à JDM.

• Plan de données L2 : plan de données de couche 2 qui gère le trafic de couche 2. Le plan de données de couche 2 transfère le trafic LAN vers le fond de panier NFV, Open vSwitch (OVS). Le plan de données de couche 2 est mappé au FPC0 virtuel sur le JCP. Par défaut, tous les ports physiques 1 Gigabit Ethernet sont mappés aux interfaces virtuelles du plan de données de couche 2.

• Plan de données L3 : plan de données de couche 3 qui fournit des fonctions de chemin de données pour les services de couche 3 à 7. Le plan de données de couche 3 est mappé au FPC1 virtuel sur le JCP. Par défaut, les deux ports SFP+ du châssis NFX150 sont mappés aux interfaces virtuelles du plan de données de couche 3.

• Linux : système d’exploitation hôte, WindRiver Linux. Dans Junos OS version 18.1R1, la version WindRiver Linux est 8.

• Pont vSwitch ouvert (OVS) : le pont OVS est un pont système compatible VLAN, qui fait office de fond de panier NFV auquel les VNF et les FPC se connectent. En outre, vous pouvez créer des ponts OVS personnalisés pour isoler la connectivité entre les différentes VNF.

• LTE : pilote conteneurisé qui assure la gestion de la connectivité 4G LTE. Le conteneur LTE est lié au FPC1 pour la gestion.

Les interfaces des appareils NFX150 comprennent des interfaces physiques, des interfaces virtuelles et l’interface LTE.

• Interfaces physiques
• Interfaces virtuelles
• LTE Interface
• Mappage d’interface

Le Tableau 5 répertorie les fonctions Junos prises en charge sur le NFX150.

Pour plus d’informations sur les fonctionnalités prises en charge, reportez-vous à la rubrique Explorateur de fonctionnalités.

Les équipements NFX150 offrent les modes de fonctionnement suivants :

• Mode débit : fournit les ressources maximales (CPU et mémoire) pour les logiciels Junos et les ressources restantes, le cas échéant, pour les VNF tierces.

  Note:

  Vous ne pouvez pas créer de VNF en mode débit.

  À partir de Junos OS version 21.1R1, le mappage d’OVS à l’interface de plan de données de couche 3 n’est pas pris en charge en mode débit sur les périphériques NFX150-S1 et NFX150-S1E. Si le mappage OVS est présent dans les versions antérieures à Junos OS version 21.1R1, vous devez modifier le mappage avant de mettre à niveau le périphérique vers Junos OS version 21.1R1 afin d’éviter un échec de validation de configuration.

• Mode hybride : assure une distribution équilibrée des ressources entre le logiciel Junos et les VNF tierces.

• Mode de calcul : fournit des ressources minimales pour les logiciels Junos et des ressources maximales pour les VNF tierces.

• Mode personnalisé : offre une option permettant d’allouer des ressources aux composants du système :

  • Plan de données de couche 2, plan de données de couche 3 et fond de panier NFV pour les modèles NFX150-S1 et NFX150-S1E

  • Plan de données de couche 2 et plan de données de couche 3 pour les modèles NFX150-C-S1, NFX150-C-S1-AE/AA et NFX150-C-S1E-AE/AA

  Note:

  Les modes calcul, hybride et débit sont pris en charge dans Junos OS version 19.1R1 ou ultérieure. Le mode personnalisé est pris en charge à partir de Junos OS version 22.1R1.

  Le mode par défaut est débit dans les versions de Junos OS antérieures à la version 21.4R1. À partir de Junos OS version 21.4R1, le mode par défaut est calcul.

En mode hybride et en mode calcul, vous pouvez mapper des interfaces de plan de données de couche 3 vers SR-IOV ou OVS. En mode débit, vous pouvez mapper des interfaces de plan de données de couche 3 uniquement sur SR-IOV.

Par exemple:

• Mapper les interfaces du plan de données de couche 3 à la SR-IOV :

  user@host# set vmhost virtualization-options interfaces ge-1/0/1 mapping interface heth-0-1

• Mapper les interfaces du plan de données de couche 3 à OVS :

  user@host# set vmhost virtualization-options interfaces ge-1/0/1

En mode hybride ou de calcul, vous pouvez créer des VNF à l’aide des processeurs disponibles dans chaque mode. Vous pouvez vérifier la disponibilité du processeur à l’aide de la show vmhost mode commande. Chaque VNF prend en charge un maximum de 10 interfaces (eth0 à eth9), y compris les deux interfaces de gestion eth0 et eth1.

Pour changer le mode actuel, exécutez la request vmhost mode mode-name commande. La request vmhost mode ? commande répertorie uniquement les modes prédéfinis, tels que les modes hybride, de calcul et de débit.

Avant de passer à un mode, exécutez les show system visibility cpu commandes et show vmhost mode pour vérifier la disponibilité des processeurs. Lorsque vous passez d’un mode de fonctionnement à l’autre, veillez à ce qu’il n’y ait pas de conflit entre les ressources et la configuration. Par exemple, si vous passez d’un mode de calcul qui prend en charge les VNF à un mode débit qui ne prend pas en charge les VNF, des conflits se produisent :

Si le plan de données de couche 3 n’est pas mappé à SR-IOV, le passage du mode hybride ou de calcul au mode débit génère une erreur.

Si vous épinglez un CPU virtuel à des CPU physiques pour une VNF, assurez-vous que les CPU physiques ne se chevauchent pas avec les CPU utilisés pour les composants système Juniper, y compris le CPU physique 0.

Les CPU physiques utilisés pour épingler un émulateur peuvent chevaucher ceux utilisés pour les composants système Juniper, à l’exception du CPU physique 0. Ce chevauchement peut affecter les performances d’un ou plusieurs composants du système Juniper et des VNF.

• Comment définir un modèle de mode personnalisé
• Mappage cœur-processeur sur NFX150

Pour les fonctionnalités ou les niveaux de mise à l’échelle qui nécessitent une licence, vous devez installer et configurer correctement la licence pour qu’elle réponde aux exigences d’utilisation de la fonctionnalité ou du niveau de mise à l’échelle pouvant faire l’objet d’une licence. L’appareil vous permet de valider une configuration qui spécifie une fonctionnalité ou une mise à l’échelle pouvant faire l’objet d’une licence sans licence pendant une période de grâce de 30 jours. La période de grâce est une subvention à court terme qui vous permet de commencer à utiliser les fonctionnalités du pack ou d’évoluer jusqu’aux limites du système (quelle que soit la limite de clé de licence) sans clé de licence installée. La période de grâce commence lorsque la fonctionnalité ou le niveau de mise à l’échelle pouvant faire l’objet d’une licence est effectivement utilisé par l’équipement (et non lors de sa première validation). En d’autres termes, vous pouvez valider des fonctionnalités ou des limites de mise à l’échelle pouvant faire l’objet d’une licence dans la configuration de l’appareil, mais la période de grâce ne commence pas tant que l’appareil n’utilise pas la fonctionnalité pouvant faire l’objet d’une licence ou ne dépasse pas un niveau de mise à l’échelle pouvant faire l’objet d’une licence.

Pour plus d’informations sur l’achat de licences logicielles, contactez votre représentant commercial Juniper Networks. Le logiciel Junos OS implémente une structure de licence basée sur l’honneur et vous offre une période de grâce de 30 jours pour utiliser cette fonctionnalité sans clé de licence installée. La période de grâce commence lorsque vous configurez la fonctionnalité et que votre appareil utilise la fonctionnalité sous licence pour la première fois, mais pas nécessairement lorsque vous installez la licence. Après l’expiration de la période de grâce, le système génère des messages de journal système indiquant que la fonctionnalité nécessite une licence. Pour effacer le message d’erreur et utiliser correctement la fonctionnalité sous licence, vous devez installer et vérifier la licence requise.

L’équipement signale toute violation de licence sous la forme d’un message d’avertissement chaque fois qu’une configuration contenant une fonctionnalité ou une limite d’échelle nécessite une licence est validée. Après la période de grâce de 30 jours, l’appareil signale périodiquement la violation aux messages syslog jusqu’à ce qu’une licence soit installée et correctement configurée sur l’appareil pour résoudre la violation.