Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Comprendre la segmentation de nœud Junos

Présentation de la segmentation de nœud Junos

La segmentation de nœud Junos permet aux fournisseurs de services et aux grandes entreprises de créer une infrastructure réseau qui regroupe plusieurs fonctions de routage en un seul équipement physique. Il permet d’héberger plusieurs services sur une seule infrastructure physique tout en évitant la complexité opérationnelle associée. Il maintient également la séparation opérationnelle, fonctionnelle et administrative des fonctions hébergées sur l’appareil.

Grâce à la segmentation de nœud Junos, vous pouvez créer plusieurs partitions dans un seul routeur physique MX Series. Ces partitions sont appelées fonctions réseau invitées (GNF). Chaque GNF se comporte comme un routeur indépendant doté de ses propres plans de contrôle, de données et de gestion. Vous pouvez ainsi exécuter plusieurs services sur un seul routeur MX Series convergé, tout en maintenant une isolation opérationnelle entre eux. Vous pouvez utiliser le même équipement physique pour créer des partitions parallèles qui ne partagent ni le plan de contrôle ni le plan de transfert, mais seulement le même châssis, le même espace et la même alimentation.

Vous pouvez également envoyer du trafic entre GNF via la fabric du commutateur à l’aide d’une interface de fabricaf () abstraite, une pseudo-interface qui se présente comme une interface Ethernet de pointe. Une interface de structure abstraite facilite le routage, le contrôle des données et la gestion du trafic entre les GNF.

La segmentation de nœud Junos propose deux modèles : un modèle de serveur externe et un modèle dans le châssis. Dans le modèle de serveur externe, les GNF sont hébergés sur deux serveurs x86 standard. Pour le modèle intégré au châssis, les GNF sont hébergés sur les moteurs de routage du routeur MX Series lui-même.

La segmentation de nœud Junos prend en charge la compatibilité logicielle multiversion, ce qui permet de mettre à niveau indépendamment les GNF.

Avantages de la segmentation de nœud Junos

  • Converged network—Grâce à la segmentation de nœud Junos, les fournisseurs de services peuvent consolider plusieurs services réseau (périphérie vidéo, périphérie vocale, etc.) sur un seul routeur physique, tout en maintenant une séparation opérationnelle entre eux. Vous pouvez réaliser une convergence horizontale et verticale. La convergence horizontale consolide les fonctions de routeur d’une même couche sur un seul routeur, tandis que la convergence verticale regroupe les fonctions de routeur de différentes couches en un seul routeur.

  • Improved scalability: l’utilisation de partitions de routage virtuelles en lieu et place d’équipements physiques améliore la programmabilité et l’évolutivité du réseau. Les fournisseurs de services et les entreprises peuvent ainsi répondre aux exigences d’infrastructure sans avoir à acheter de matériel supplémentaire.

  • Easy risk management: bien que plusieurs fonctions réseau convergent sur un même châssis, toutes les fonctions sont exécutées de manière indépendante et bénéficient d’une séparation à la fois administrative, fonctionnelle et opérationnelle. Le partitionnement d’un système physique (passerelle de réseau haut débit BNG, par exemple) en plusieurs instances logiques indépendantes permet d’isoler les pannes. Les partitions ne partagent ni le plan de contrôle ni le plan de transfert, mais seulement le même châssis, le même espace et la même alimentation. Ainsi, une panne au sein d’une partition n’affecte pas le reste du service.

  • Reduced network costs: la segmentation de nœud Junos permet l’interconnexion des GNF par le biais de fabrics de commutation internes. Elles exploitent l’interface abstraite (af), une pseudo-interface représentant un comportement d’interface Ethernet de pointe. Une fois af l’interface en place, les entreprises n’ont plus besoin de dépendre d’interfaces physiques pour connecter les GNF, ce qui se traduit par des économies considérables.

  • Reduced time-to-market for new services and capabilities: chaque GNF peut fonctionner avec une version différente du logiciel Junos. Cet avantage permet aux entreprises de faire évoluer chaque GNF à son propre rythme. Si un nouveau service ou une nouvelle fonctionnalité doit être déployé sur un GNF spécifique et qu’il nécessite une nouvelle version logicielle, seul le GNF concerné doit être mis à jour. Parallèlement à cette agilité accrue, la segmentation de nœud Junos permet aux fournisseurs de services et aux entreprises d’introduire un modèle économique « everything-as-a-service » très flexible pour répondre rapidement aux conditions changeantes du marché.

Composants de la segmentation de nœud Junos

La segmentation de nœud Junos vous permet de partitionner un seul routeur MX Series pour le faire apparaître comme plusieurs routeurs indépendants. Chaque partition possède son propre plan de contrôle Junos OS, qui s’exécute comme une machine virtuelle (VM), et un ensemble dédié de cartes de ligne. Chaque partition est appelée fonction réseau invitée (GNF).

Le routeur MX Series fonctionne comme le système de base (BSYS). Le BSYS possède tous les composants physiques du routeur, y compris les cartes de ligne et la structure de commutation. Le BSYS attribue des cartes de ligne aux GNF.

Le logiciel Juniper Device Manager (JDM) orchestre les machines virtuelles GNF. Dans JDM, une machine virtuelle GNF est appelée fonction de réseau virtuel (VNF). Un GNF comprend donc une VNF et un ensemble de cartes de ligne.

Grâce à la configuration au BSYS, vous pouvez affecter des cartes de ligne du châssis à différents GNF. De plus, selon le type de carte de ligne, vous pouvez même affecter des ensembles de PFE dans une carte de ligne à différents GNF. Voir Vue d’ensemble de la carte de sous-ligne pour plus de détails.

La segmentation de nœud Junos prend en charge deux modèles :

  • Modèle de serveur externe

  • Modèle intégré au châssis

Dans le modèle de serveur externe, les JDM et les VNF sont hébergés sur une paire de serveurs externes x86 standard.

La figure 1 montre trois GNF avec leurs cartes de ligne dédiées fonctionnant sur un serveur externe.

Figure 1 : GNF sur un serveur High-level network architecture diagram showing an x86 server with Juniper Device Manager managing GNFs and an MX Series chassis with Base System and FPCs linked to GNFs. externe

Voir Connexion des serveurs et du routeur pour plus d’informations sur la connexion d’un routeur MX Series à une paire de serveurs x86 externes.

Dans le modèle intégré au châssis, tous les composants (JDM, BSYS, ainsi que les GNF) s’exécutent dans le moteur de routage du routeur MX Series. Voir Figure 2.

Figure 2 : découpage de nœud Junos dans le châssis MX Series Chassis diagram showing internal structure. Highlights Routing Engine with JDM, BSYS, GNF 1, GNF 2, GNF 3. GNFs connect to FPCs: FPC 1, 2, 3 for GNF 1; FPC 5, 6 for GNF 2; FPC 7, 8 for GNF 3.

Système de base (BSYS)

Dans le cas de la segmentation de nœud Junos, le routeur MX Series fonctionne comme le système de base (BSYS). Le BSYS possède tous les composants physiques du routeur, y compris toutes les cartes de ligne et la fabric. Grâce à la configuration de Junos OS au niveau du BSYS, vous pouvez affecter des cartes de ligne aux GNF et définir des interfaces de fabric abstraites (af) entre les GNF. Le logiciel BSYS s’exécute sur une paire de moteurs de routage redondants du routeur MX Series.

Fonction réseau invité (GNF)

Une fonction réseau invitée (GNF) possède logiquement les cartes d’interface qui lui sont attribuées par le système de base (BSYS) et maintient l’état de transfert des cartes d’interface. Vous pouvez configurer plusieurs GNF sur un routeur MX Series (voir Configuration des fonctions réseau invitées). Le plan de contrôle Junos OS de chaque GNF s’exécute comme une machine virtuelle (VM). Le logiciel Juniper Device Manager (JDM) orchestre les machines virtuelles GNF. Dans le contexte JDM, les GNF sont appelés fonctions de réseau virtuel (VNF).

Un GNF est équivalent à un routeur autonome. Les GNF sont configurés et administrés indépendamment, et sont isolés les uns des autres sur le plan opérationnel.

La création d’un GNF nécessite deux ensembles de configurations, l’un à effectuer au BSYS et l’autre au JDM.

Un GNF est défini par un ID. Cet ID doit être le même au BSYS et au JDM.

La partie BSYS de la configuration GNF comprend l’attribution d’un ID et d’un ensemble de cartes de ligne.

La partie JDM de la configuration GNF comprend la spécification des attributs suivants :

  • Nom d’une VNF.

  • UN ID GNF. Cet identifiant doit être le même que l’identifiant GNF utilisé au BSYS.

  • Type de plate-forme MX Series (pour le modèle de serveur externe).

  • Une image de Junos OS à utiliser pour la VNF.

  • Le modèle de ressource de serveur VNF.

Le modèle de ressource serveur définit le nombre de cœurs de processeur dédiés (physiques) et la taille de DRAM à affecter à un GNF. Pour obtenir la liste des modèles de ressources serveur prédéfinis disponibles pour les GNF, reportez-vous à la section Exigences en ressources matérielles serveur (par GNF) dans Exigences matérielles et logicielles minimales pour le découpage de nœud Junos.

Une fois qu’un GNF est configuré, vous pouvez y accéder en vous connectant au port de console virtuelle du GNF. À l’aide de la CLI de Junos OS au niveau du GNF, vous pouvez configurer les propriétés système GNF telles que le nom d’hôte et l’adresse IP de gestion, puis y accéder via son port de gestion.

Gestionnaire de périphériques de Juniper (JDM)

Le Gestionnaire de périphériques de Juniper (JDM), un conteneur Linux virtualisé, permet de provisionner et de gérer les machines virtuelles GNF.

JDM prend en charge les CLI de type Junos OS, NETCONF pour la configuration et la gestion et SNMP pour la surveillance.

Remarque :

Dans le modèle intégré au châssis, JDM ne prend pas en charge SNMP.

Une instance JDM est hébergée sur chacun des serveurs x86 du modèle de serveur externe et sur chaque moteur de routage pour le modèle dans le châssis. Les instances JDM sont généralement configurées en tant qu’homologues qui synchronisent les configurations GNF : lorsqu’une VM GNF est créée sur un serveur, sa VM de sauvegarde est automatiquement créée sur l’autre serveur ou moteur de routage.

Une adresse IP et un compte administrateur doivent être configurés sur le JDM. Une fois ceux-ci configurés, vous pouvez vous connecter directement au JDM.

Voir aussi

Interface de fabric abstraite

L’interface de fabric abstraite (af) est une pseudo-interface qui représente un comportement d’interface Ethernet de première classe. Une af interface facilite le routage, le contrôle et la gestion du trafic entre les fonctions réseau invitées (GNF) via la fabric du commutateur. Une af interface est créée sur un GNF pour communiquer avec son homologue GNF lorsque les deux GNF sont configurés pour être connectés l’un à l’autre. Les interfaces de structure abstraites doivent être créées par BSYS. La bande passante des af interfaces change dynamiquement en fonction de l’insertion ou de l’accessibilité de la carte d’interface/MPC distante. La fabric étant le support de communication entre les GNF, af les interfaces sont considérées comme des interfaces WAN équivalentes. Voir Figure 3.

Figure 3 : interface High-level architecture of a networking system showing interconnections: GNF1 with FPC0, GNF2 with FPC4, PFEs linked via green fabric labeled Fabric, central AF point, and data paths as black lines. de fabric abstraite

Comprendre la bande passante des interfaces de fabric abstraites

Une interface de fabric abstraite (af) connecte deux GNF à travers la fabric et agrège tous les moteurs de transfert de paquets (PFE) qui connectent les deux GNF. Une af interface peut exploiter la somme de la bande passante de chaque moteur de transfert de paquets appartenant à l’interface af .

Par exemple, si GNF1 a une MPC8 (qui a quatre moteurs de transfert de paquets d’une capacité de 240 Gbit/s chacun) et que GNF1 est connecté à GNF2 et GNF3 à l’aide d’interfaces af (af1 et af2), la capacité d’interface maximale af sur GNF1 sera de 4 x 240 Gbit/s = 960 Gbit/s.

GNF1—af1——GNF2

GNF1—af2——GNF3

Dans ce cas, af1 et af2 partagent la capacité de 960 Gbit/s.

Pour plus d’informations sur la bande passante prise en charge sur chaque MPC, reportez-vous au Tableau 1.

Fonctionnalités prises en charge sur les interfaces de fabric abstraites

Les interfaces de structure abstraites prennent en charge les fonctionnalités suivantes :

  • Unified In-Service Software Upgrade (ISSU)

  • Configuration en mode Hyper au niveau BSYS (à partir de Junos OS version 19.3R2). Cette fonctionnalité est prise en charge sur les cartes de ligne MPC6E, MPC8E, MPC9E et MPC11E.

    Remarque :

    • Vous ne pouvez pas avoir différentes configurations en mode hyper pour les GNF individuels, car ils héritent de la configuration du BSYS.

    • Les routeurs MX2020 et MX2010 avec SFB3 apparaissent par défaut en mode hyper. Si vous exigez que le mode hyper soit désactivé sur n’importe quel GNF, vous devez le configurer sur le BSYS, et il s’appliquera à tous les GNF de ce châssis.

  • Équilibrage de charge en fonction des cartes de ligne GNF distantes présentes

  • Prise en charge de la classe de service (CoS) :

    • Classificateur et réécriture de la précédence Inet

    • Classificateur DSCP et réécriture

    • Classificateur et réécriture EXP MPLS

    • Classificateur DSCP v6 et réécriture pour le trafic IP v6

  • Prise en charge des protocoles OSPF, IS-IS, BGP, OSPFv3 et L3VPN

    Remarque :

    Les non-interfacesaf prennent en charge tous les protocoles fonctionnant sous Junos OS.

  • BFD pour BGP, IS-IS et OSPF à partir de Junos OS version 24.2R1.

  • Transfert multicast

  • GRES (Graceful moteur de routage switchover)

  • Applications MPLS où l’interface af agit comme interface principale (L3VPN, VPLS, L2VPN, L2CKT, EVPN et IP sur MPLS)

  • Les familles de protocoles suivantes sont prises en charge :

    • Transfert IPv4

    • Transfert IPv6

    • MPLS

    • L’ISO

    • Le CCC

  • Prise en charge des capteurs de l’interface de télémétrie Junos (JTI)

  • À partir de Junos OS version 19.1R1, les fonctions réseau invitées (GNF) prennent en charge les VPN Ethernet (EVPN) avec encapsulation du protocole VXLAN (VXLAN). Cette prise en charge est disponible avec une interface nonaf physique et af une interface en tant qu’interface centrale. Cette prise en charge n’est pas disponible pour la carte de ligne MPC11E.

  • Avec la configuration d’interface af , les GNF prennent en charge afles MPC -. Le Tableau 1 répertorie les afMPC -, le nombre de PFE pris en charge par MPC et la bande passante prise en charge par MPC.

    Tableau 1 : MPC abstraits fabric compatibles pris en charge

    MPC

    Version initiale

    Nombre d’EFP

    Bande passante totale

    MPC7E-MRATE

    17.4R1

    2

    480G (240*2)

    MPC7E-10G

    17.4R1

    2

    480G (240*2)

    MX2K-MPC8E

    17.4R1

    4

    960 G (240 *4)

    MX2K-MPC9E

    17.4R1

    4

    1,6 T (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

    260 G (130*2)

    2 x 100GE + 8 x 10GE MPC4E

    19.1R1

    2

    260 G (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)

    MPC multiservices (MS-MPC)

    19.1R1

    1

    120G

    MPC 16 x 10GE

    19.1R1

    4

    160 G (40 * 4)

    MX2K-MPC11E

    19.3R2

    8

    4T (500G*8)
Remarque :

Nous vous recommandons de définir les paramètres de la MTU sur l’interface af pour qu’ils s’alignent sur la valeur maximale autorisée sur les interfaces XE/GE. Cela garantit une fragmentation minimale, voire nulle, des paquets sur l’interface af .

Restrictions d’interface de fabric abstraite

Voici les restrictions actuelles des interfaces de structure abstraites :

  • Les configurations telles que l’interface de point af de terminaison unique, af l’incompatibilité de mappage interface-GNF ou le mappage de plusieurs af interfaces au même GNF distant ne sont pas vérifiées lors de la validation sur le BSYS. Assurez-vous d’avoir les bonnes configurations.

  • L’allocation de la bande passante est statique, en fonction du type MPC.

  • Il peut y avoir des pertes de trafic minimes (à la fois en transit et sur l’hôte) pendant la mise hors ligne/le redémarrage d’une MPC hébergée sur un GNF distant.

  • L’interopérabilité entre les MPC compatibles et les MPC qui ne le afsont pas afn’est pas prise en charge.

Voir aussi

Optimisation du chemin de la fabric pour une interface de fabric abstraite

Vous pouvez optimiser le trafic circulant sur les interfaces de structure abstraite (af) entre deux fonctions réseau invitées (GNF) en configurant un mode d’optimisation du chemin de fabric. Cette fonctionnalité réduit la consommation de bande passante de la fabric en empêchant tout saut supplémentaire de fabric (basculement des flux de trafic d’un moteur de transfert de paquets à un autre) avant que les paquets n’atteignent finalement le moteur de transfert de paquets de destination. fabric optimisation du chemin, prise en charge sur les MX2008, MX2010 et MX2020 avec MPC9E et MX2K-MPC11E, empêche un seul saut de trafic supplémentaire résultant d’un équilibrage de charge d’interface de fabric abstrait.

Vous pouvez configurer l’un des modes d’optimisation de chemin de fabric suivants :

  • monitor: si vous configurez ce mode, le GNF homologue surveille le flux de trafic et envoie au GNF source des informations sur le moteur de transfert de paquets vers lequel le trafic est actuellement transféré et le moteur de transfert de paquets souhaité qui pourrait fournir un chemin de trafic optimisé. Dans ce mode, le GNF source ne transfère pas le trafic vers le moteur de transfert de paquets souhaité.

  • optimize: si vous configurez ce mode, le GNF homologue surveille le flux de trafic et envoie au GNF source des informations sur le moteur de transfert de paquets vers lequel le trafic est actuellement transféré et le moteur de transfert de paquets souhaité qui pourrait fournir un chemin de trafic optimisé. Le GNF source transmet ensuite le trafic vers le moteur de transfert de paquets souhaité.

Pour configurer un mode d’optimisation du chemin de fabric, utilisez les commandes CLI suivantes sur BSYS.

Après avoir configuré l’optimisation du chemin de fabric, vous pouvez utiliser la commande show interfaces af-interface-name dans GNF pour afficher le nombre de paquets qui circulent actuellement sur le chemin optimal/non optimal.

Voir aussi

Choisir entre un modèle de serveur externe et un modèle dans le châssis

Le modèle de serveur externe vous permet de configurer plus d’instances de GNF à plus grande échelle, car vous pouvez choisir un serveur de capacité suffisante pour répondre aux exigences des GNF. Avec le modèle intégré au châssis, le nombre de GNF pouvant être configurés est fonction des exigences d’échelle des GNF constitutifs et de la capacité globale du moteur de routage.

Les modèles de segmentation de nœud Junos, côté serveur externe et dans le châssis, s’excluent mutuellement. Un routeur MX Series peut être configuré pour fonctionner sur un seul de ces modèles à la fois.

Comportement principal de BSYS et GNF

Les sections suivantes traitent du comportement principal de BSYS et GNF dans le contexte de la redondance du moteur de routage.

La figure 4 montre le comportement principal de GNF et BSYS avec la redondance du moteur de routage.

Figure 4 : Comportement du rôle principal du GNF et du BSYS (modèle de serveur externe) High-level architecture of redundant system with software and hardware mastership arbitration, featuring two x86 servers coordinating mastership roles.

Rôle principal de BSYS

Le comportement d’arbitrage du rôle principal du moteur de routage BSYS est identique à celui des moteurs de routage sur les routeurs MX Series.

Rôle principal du GNF

Le comportement d’arbitrage du rôle principal des machines virtuelles GNF est similaire à celui des moteurs de routage MX Series. Chaque GNF s’exécute comme une paire de machines virtuelles de sauvegarde principale. Une VM GNF qui s’exécute sur server0 (ou re0 pour un châssis) est équivalente à l’emplacement 0 du moteur de routage d’un routeur MX Series, et la VM GNF qui s’exécute sur server1 (ou re1 pour un châssis) est équivalente à l’emplacement 1 du moteur de routage d’un routeur MX Series.

Le rôle principal du GNF est indépendant du rôle principal du BSYS et de celui des autres GNF. L’arbitrage des rôles principaux GNF s’effectue via Junos OS. En cas de défaillance de la connectivité, le rôle principal des GNF est géré de manière conservatrice.

Le modèle de rôle principal GNF est le même pour les modèles de serveur externe que pour les modèles dans le châssis.

Remarque :

Comme pour les moteurs de routage MX Series, vous devez configurer le basculement GRES (Graceful moteur de routage switchover) au niveau de chaque GNF. Il s’agit d’une condition préalable pour que la machine virtuelle GNF de sauvegarde assume automatiquement le rôle principal en cas d’échec ou de redémarrage de la machine virtuelle GNF principale.

Rôles d’administrateur de la segmentation de nœud Junos

Les rôles d’administrateur suivants vous permettent d’effectuer les tâches de découpage du nœud :

  • Administrateur BSYS : responsable du châssis physique, ainsi que du provisionnement des GNF (attribution de cartes de ligne aux GNF). Des commandes CLI de Junos OS sont disponibles pour ces tâches.

  • Administrateur GNF : responsable de la configuration, du fonctionnement et de la gestion de Junos OS au niveau du GNF. Toutes les commandes CLI standard de Junos OS sont disponibles pour l’administrateur GNF pour ces tâches.

  • Administrateur JDM : responsable de la configuration des ports du serveur JDM (pour le modèle de serveur externe), ainsi que du provisionnement et de la gestion du cycle de vie des machines virtuelles GNF (VNF). Des commandes JDM CLI sont disponibles pour ces tâches.

Présentation de la carte de sous-ligne

Dans la segmentation de nœud Junos, chaque GNF comprend un ensemble de cartes de ligne (FPC). Par défaut, la granularité la plus fine fournie par un GNF se situe au niveau de la carte de ligne, car chaque GNF se voit attribuer des cartes de ligne entières (c’est-à-dire l’ensemble complet des moteurs de transfert de paquets dans chaque carte de ligne). Grâce à la fonctionnalité de carte de sous-ligne (SLC), vous pouvez définir une granularité encore plus fine du partitionnement, en affectant des sous-ensembles de moteurs de transfert de paquets dans une seule carte de ligne à différents GNF.

Ces sous-ensembles de moteurs de transfert de paquets définis par l’utilisateur dans une carte de ligne sont appelés cartes de sous-ligne (SLC). D’un point de vue opérationnel, les SLC fonctionnent comme des cartes de ligne indépendantes.

Lorsque vous découpez une carte de ligne, chaque SLC de cette carte de ligne doit être affecté à un GNF différent.

Vous pouvez affecter des SLC de plusieurs cartes de ligne au même GNF.

Dans une configuration de segmentation de nœud Junos avec la fonctionnalité SLC, un GNF peut comprendre un ensemble de cartes de ligne entières ainsi qu’un ensemble de tranches (SLC) de cartes de ligne, ce qui offre un niveau de flexibilité plus élevé.

Lorsqu’une carte de ligne est découpée, deux types d’instances logicielles s’exécutent sur cette carte de ligne : une seule instance de carte de ligne de base (BLC) et plusieurs instances SLC (autant que le nombre de tranches de cette carte de ligne). Actuellement, la capacité SLC n’est disponible que sur la MPC11E, qui prend en charge deux SLC. L’instance BLC est responsable de la gestion du matériel commun à tous les SLC de cette carte de ligne, tandis que chaque instance SLC est responsable de la gestion de l’ensemble des moteurs de transfert de paquets qui lui sont exclusivement affectés. L’instance BLC exécute le logiciel Junos du BSYS, tandis que chaque instance SLC exécute le logiciel Junos de son GNF associé.

Figure 5 : SLC attribués aux GNF dans une configuration de segmentation de nœud Junos basée sur un serveur externe High-level architecture diagram of a networking system showing Juniper Device Manager interacting with Guest Network Functions and Flexible PIC Concentrators.

Les SLC prennent en charge les interfaces de structure abstraites et le transfert réduit (voir Optimisation du chemin fabric pour les interfaces fabric abstraites). Vous pouvez utiliser la show interface af-interface-name commande pour afficher les statistiques d’équilibrage de charge des moteurs de transfert de paquets distants spécifiques à la tranche FPC. Voir Afficher les interfaces (fabric abstraite) pour plus de détails.

La capacité SLC est disponible uniquement sur la MPC11E (référence de modèle : MX2K-MPC11E).

Ressources de la carte de ligne pour les SLC

Un SLC ou une tranche d’une carte de ligne définit l’ensemble des moteurs de transfert de paquets (de cette carte de ligne) qui doivent fonctionner ensemble. Les moteurs de transfert de paquets d’une carte de ligne sont identifiés par des ID numériques. Si une carte de ligne possède 'n' moteurs de transfert de paquets, les moteurs de transfert de paquets individuels sont numérotés de 0 à (n-1). De plus, les cœurs CPU et la DRAM sur la carte de contrôle de la carte de ligne doivent également être divisés et alloués à la tranche. Pour définir un SLC, il faut donc définir les ressources de carte de ligne suivantes à dédier à ce SLC :

  • Une gamme de moteurs de transfert de paquets

  • Nombre de cœurs de processeur sur la carte de contrôle de la carte de ligne

  • La taille de la DRAM (en Go) sur la carte de contrôle de la carte de ligne

Remarque :

Une certaine quantité de DRAM est automatiquement réservée à l’instance BLC sur cette carte de ligne, et le reste est disponible pour les instances SLC.

Chaque SLC est identifié par un ID numérique, attribué par l’utilisateur.

Lorsqu’une carte de ligne est découpée, les partitions de ressources pour chaque tranche de cette carte de ligne doivent être complètement définies.

Ressources de la carte d’interface MPC11E pour les SLC

Une carte d’interface MPC11E possède :

  • 8 moteurs de transfert de paquets

  • 8 cœurs CPU sur la carte de contrôle

  • 32 Go de DRAM sur la carte de contrôle

5 Go de DRAM sont automatiquement réservés à l’utilisation de BLC, 1 Go de DRAM est alloué à l’hôte de la carte de ligne et les 26 Go restants sont disponibles pour les tranches SLC.

Une MPC11E est capable de prendre en charge deux SLC.

Le Tableau 2 définit deux types de profils d’allocation de ressources pris en charge par une MPC11E pour les deux SLC, appelés ici SLC1 et SLC2.

Dans le profil symétrique, les moteurs de transfert de paquets et les autres ressources de la carte de ligne sont répartis uniformément entre les tranches. Dans le profil asymétrique, seules les combinaisons de ressources de carte d’interface spécifiées dans le tableau 2 sont prises en charge.

Remarque :

Vous pouvez configurer les profils SLC suivants, en fonction de la façon dont les moteurs de transfert de paquets [0-7] sont répartis entre les deux SLC :

  • Moteurs de transfert de paquets 0-3 pour un SLC et 4-7 pour l’autre SLC (profil symétrique)

  • Moteurs de transfert de paquets 0-1 pour un SLC et 2-7 pour l’autre SLC (profil asymétrique)

  • Moteurs de transfert de paquets 0-5 pour un SLC et 6-7 pour l’autre SLC (profil asymétrique)

Dans le profil asymétrique, vous pouvez attribuer 9 Go ou 17 Go de DRAM à un SLC. Étant donné que toutes les ressources de la carte de ligne doivent être entièrement affectées et que le total de DRAM disponible pour les SLC est de 26 Go, l’attribution de 9 Go de DRAM à un SLC nécessite que les 17 Go restants soient affectés à l’autre SLC.

Tableau 2 : profils SLC pris en charge par MPC11E
 

Profil symétrique

Profil asymétrique

Type de ressource

SLC1

SLC2

SLC1

SLC2

moteur de transfert de paquets

4

4

2

6

DRAM

13 Go

13 Go

17 Go/9 Go

9 Go/17 Go

Processeur

4

4

4

4

Voir aussi : Configuration des cartes de sous-ligne et les affecter aux GNF et Gestion des cartes de sous-ligne.

Présentation de l’interopérabilité des logiciels multiversions

À partir de la version 17.4R1 de Junos OS, la segmentation de nœud Junos prend en charge la compatibilité logicielle multiversion, ce qui permet au BSYS d’interagir avec une fonction réseau invitée (GNF) qui exécute une version de Junos OS supérieure à la version logicielle du BSYS. Cette fonctionnalité prend en charge une plage de deux versions maximum entre GNF et BSYS. C’est-à-dire que le logiciel GNF peut avoir deux versions supérieures au logiciel BSYS. BSYS et GNF doivent tous deux répondre à une version minimale de Junos OS version 17.4R1.

Remarque :

Les restrictions de prise en charge de multiversion s’appliquent également au processus de mise à niveau unifié d’ISSU

Bien que la gestion des versions des logiciels JDM n’ait pas de restriction similaire en ce qui concerne les versions des logiciels GNF ou BSYS, nous vous recommandons de mettre à jour régulièrement le logiciel JDM. Une mise à niveau JDM n’affecte aucun des GNF en cours d’exécution.

Services nouvelle génération sur la segmentation de nœud Junos

La segmentation de nœud Junos prend en charge la carte de services MX-SPC3, une carte de services de sécurité qui fournit une puissance de traitement supplémentaire pour exécuter les services de nouvelle génération sur les plates-formes MX. Vous pouvez activer les services nouvelle génération au niveau de la fonction réseau invité (GNF) à l’aide de l’CLI request system enable unified-services sur GNF. Pour prendre en charge un MX-SPC3, un GNF doit être associé à une carte de ligne.

Dans une configuration de segmentation de nœud Junos, vous pouvez utiliser à la fois MX-SPC3 et MS-MPC sur le même châssis mais sur des moteurs de routage GNF différents. Si vous avez activé les services nouvelle génération au niveau de GNF, utilisez request system enable unified-services, le MX-SPC3 est mis en ligne. Si vous n’avez pas activé les services nouvelle génération, le MS-MPC est activé.

L’installation logicielle ou la mise à niveau d’une carte MX-SPC3 a lieu lorsque vous installez ou mettez à niveau le moteur de routage GNF associé.

Remarque :

Le MX-SPC3 ne prend pas en charge les interfaces de structure abstraites. Par conséquent, un GNF auquel est liée une carte MX-SPC3 doit également être associé à une carte de ligne.

Comparaison de la segmentation de nœud Junos avec les systèmes logiques

La segmentation de nœud Junos est une couche inférieure aux systèmes logiques de Junos. Les deux technologies ont des capacités qui se chevauchent mais diffèrent sur d’autres aspects. Avec la segmentation de nœud Junos, les cartes de ligne complètes, et donc les interfaces physiques, sont attribuées à un GNF, tandis qu’avec les systèmes logiques, une seule interface physique peut être partagée entre différents systèmes logiques, puisque plusieurs interfaces logiques définies sur une interface physique peuvent toutes être affectées à des systèmes logiques distincts. Cela signifie que les systèmes logiques permettent un partage avec une granularité plus fine que la segmentation de nœud Junos. Mais tous les systèmes logiques partagent un seul noyau Junos, exécutant donc nécessairement la même version de Junos, en plus de devoir partager le moteur de routage et les ressources physiques de la carte de ligne telles que le processeur, la mémoire et le stockage. Grâce à la segmentation de nœud Junos, chaque GNF obtient son propre équivalent d’une paire de moteurs de routage, ainsi que des cartes de ligne dédiées à ce GNF. Ainsi, les GNF ne partagent pas la plupart des ressources physiques : ils partagent uniquement le châssis et la structure du commutateur. Les GNF, contrairement aux systèmes logiques, peuvent être mis à niveau et administrés indépendamment comme un routeur autonome MX.

La segmentation de nœud Junos est une technologie qui complète, voire augmente les systèmes logiques, puisqu’un GNF peut lui-même avoir plusieurs systèmes logiques. Lorsque l’isolement physique, les ressources garanties et l’isolement administratif complet sont primordiaux, la segmentation de nœud Junos serait mieux adaptée. Et lorsque la granularité fine du partage, jusqu’au niveau de l’interface logique, est primordiale, un système logique serait la meilleure correspondance.

Licences pour la segmentation de nœud Junos

L’utilisation de la segmentation de nœud Junos nécessite des licences pour les GNF et les interfaces de structure abstraites à installer au niveau du BSYS. L’exécution d’un GNF sans licence installée au niveau du BSYS entraînera le message syslog et l’alarme mineure suivants :

Veuillez contacter Juniper Networks si vous avez des questions concernant les licences de segmentation de nœud Junos.

Documentation connexe