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 composants clés du logiciel système sont les suivants :

• VNF : une VNF est une offre consolidée qui contient tous les composants requis pour prendre en charge 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 exécutée sur le système d’exploitation hôte, Wind River Linux. Le JCP fonctionne comme le 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.

  Outre la gestion des châssis, JCP permet :

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

  • Gestion des fonctions réseau virtualisées (VNF) invitées 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 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. 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 Ethernet 1 Gigabit 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 les fonctions de chemin d’accès aux données pour les services de couche 3 à couche 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 : le système d’exploitation hôte, WindRiver Linux. Dans Junos OS version 18.1R1, la version Linux de WindRiver est 8.

• Pont OVS (Open vSwitch) : le pont OVS est un pont système compatible VLAN, qui agit comme le fond de panier NFV auquel les VNF et FPC se connectent. En outre, vous pouvez créer des ponts OVS personnalisés pour isoler la connectivité entre 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 fonctionnalités Junos prises en charge sur NFX150.

Pour plus d’informations sur les fonctionnalités prises en charge, consultez l’Explorateur de fonctionnalités.

Les équipements NFX150 offrent les modes de fonctionnement suivants :

• Mode de débit : fournit un maximum de ressources (CPU et mémoire) pour le logiciel 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 équipements NFX150-S1 et NFX150-S1E. Si le mappage OVS est présent dans des 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 pour éviter tout échec de validation de configuration.

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

• Mode calcul : fournit un minimum de ressources pour le logiciel Junos et un maximum de ressources pour les VNF tierces.

• Mode personnalisé : fournit une option permettant d’allouer des ressources aux composants 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 de calcul, hybride et de 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 le débit dans les versions de Junos OS antérieures à 21.4R1. À partir de Junos OS version 21.4R1, le mode par défaut est le calcul.

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

Par exemple :

• Mappez les interfaces du plan de données de couche 3 au SR-IOV :

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

• Mappez 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 sur 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 modifier 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, assurez-vous qu’il n’y a pas de conflits entre ressources et configuration. Par exemple, si vous passez d’un mode de calcul qui prend en charge les VNF à un mode de 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é au SR-IOV, le passage du mode hybride ou informatique au mode débit génère une erreur.

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

Les processeurs physiques utilisés pour épingler un émulateur peuvent chevaucher les processeurs utilisés pour les composants du système Juniper, à l’exception du processeur physique 0. Ce chevauchement peut avoir un impact sur les performances d’un ou plusieurs composants système et VNF Juniper.

• Comment définir un modèle de mode personnalisé
• Mappage du cœur au 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 afin qu’elle réponde aux exigences d’utilisation de la fonctionnalité ou du niveau d’é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 sous 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é sous licence ou le niveau de mise à l’échelle est effectivement utilisé par l’appareil (et non lors de sa première validation). En d’autres termes, vous pouvez valider des fonctionnalités sous licence ou des limites de mise à l’échelle pour la configuration de l’appareil, mais la période de grâce ne commence pas tant que l’appareil n’utilise pas la fonctionnalité sous licence ou dépasse un niveau de mise à l’échelle sous 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. Une fois la période de grâce expirée, 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’appareil signale toute violation de licence sous forme de message de journal d’avertissement chaque fois qu’une configuration contenant une fonctionnalité ou une échelle limite d’utilisation nécessitant 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.