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 nud Junos

Présentation de la segmentation de nud Junos

La segmentation de nœud Junos permet aux fournisseurs de services et aux grandes entreprises de créer une infrastructure réseau qui consolide plusieurs fonctions de routage dans 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.

La segmentation de nœud Junos vous permet de créer plusieurs partitions dans un seul routeur physique MX Series. Ces partitions sont appelées fonctions de réseau invité (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 exploiter 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 les GNF via la structure de commutation à l’aide d’une interface de structure abstraite (af), une pseudo-interface qui se comporte comme une interface Ethernet de premier ordre. Une interface de structure abstraite facilite le routage du trafic de contrôle, de données et de gestion 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 une paire de serveurs x86 standard. Pour le modèle dans le 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, permettant ainsi une mise à niveau indépendante des GNF.

Avantages de la segmentation de nud Junos

  • Converged network—Grâce à la segmentation de nœud Junos, les fournisseurs de services peuvent regrouper plusieurs services réseau, tels que Video Edge et Voice Edge, sur un seul routeur physique, tout en maintenant une séparation opérationnelle entre eux. Vous pouvez réaliser une convergence à la fois horizontale et verticale. La convergence horizontale consolide les fonctions de routeur d’une même couche en un seul routeur, tandis que la convergence verticale regroupe les fonctions de routeur de différentes couches en un seul routeur.

  • Improved scalability—En se concentrant sur les partitions de routage virtuelles plutôt que sur les équipements physiques, le réseau est plus programmable et plus évolutif, ce qui permet aux fournisseurs de services et aux entreprises de répondre aux exigences d’infrastructure sans avoir à acheter de matériel supplémentaire.

  • Easy risk managementBien 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 opérationnelle, fonctionnelle et administrative. 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 via des structures de commutation internes, qui exploite l’interface de structure abstraite (af), une pseudo-interface qui représente un comportement d’interface Ethernet de première classe. Une fois af l’interface en place, les entreprises ne dépendent plus 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 sur une version différente du logiciel Junos. Cet avantage permet aux entreprises de faire évoluer chaque GNF à leur 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 commercial « everything-as-a-service » très flexible pour réagir rapidement aux conditions changeantes du marché.

Composants de la segmentation de nud 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 jeu de cartes de ligne dédié. Chaque partition est appelée fonction de réseau invité (GNF).

Le routeur MX Series fonctionne comme 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 réseau virtuelle (VNF). Un GNF se compose donc d’une VNF et d’un ensemble de cartes de ligne.

Grâce à la configuration au niveau du BSYS, vous pouvez affecter des cartes de ligne du châssis à différents GNF. De plus, en fonction du type de carte de ligne, vous pouvez même affecter des ensembles de PFE au sein d’une carte de ligne à différents GNF. Pour plus d’informations, reportez-vous à la section Présentation de la carte de sous-ligne .

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

  • Modèle de serveur externe

  • Modèle encastré dans le 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 de l’industrie.

La figure 1 illustre trois GNF avec leurs cartes de ligne dédiées s’exécutant sur un serveur externe.

Figure 1 : GNF sur un serveur GNFs on External Server externe

Reportez-vous à la section Connexion des serveurs et du routeur pour savoir comment connecter 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) fonctionnent dans le moteur de routage du routeur MX Series. Reportez-vous à la figure 2.

Figure 2 : segmentation de nud Junos dans le In-chassis Junos Node Slicing châssis

Système de base (BSYS)

Dans 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 structure. Grâce à la configuration de Junos OS au niveau de BSYS, vous pouvez affecter des cartes de ligne aux GNF et définir des interfaces de structure abstraite (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 de réseau invité (GNF) possède logiquement les cartes de ligne qui lui sont attribuées par le système de base (BSYS) et conserve l’état de transfert des cartes de ligne. Vous pouvez configurer plusieurs GNF sur un routeur MX Series (reportez-vous à la section Configuration des fonctions réseau invitées). Le plan de contrôle Junos OS de chaque GNF s’exécute sous la forme d’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 l’équivalent d’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 niveau du BSYS et l’autre au niveau du JDM.

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

La partie BSYS de la configuration GNF consiste à lui donner un ID et un ensemble de cartes de ligne.

La partie JDM de la configuration GNF consiste à spécifier les attributs suivants :

  • Un nom VNF.

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

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

  • Image Junos OS à utiliser pour la VNF.

  • 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 la DRAM à attribuer à 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 matière de ressources matérielles du serveur (par GNF) dans Configuration matérielle et logicielle minimale requise pour la segmentation de nud 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 Junos OS au niveau du GNF, vous pouvez ensuite 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 Juniper (JDM)

Juniper Device Manager (JDM), un conteneur Linux virtualisé, permet le provisionnement et la gestion des machines virtuelles GNF.

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

Note:

Dans le modèle dans le 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 machine virtuelle GNF est créée sur un serveur, sa machine virtuelle 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 structure abstraite

L’interface de structure 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 de réseau invitées (GNF) via la structure de commutation. 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. Des interfaces de structure abstraites doivent être créées au niveau de BSYS. La bande passante des af interfaces change dynamiquement en fonction de l’insertion ou de l’accessibilité de la carte de ligne distante/MPC. La structure étant le support de communication entre les GNF, af les interfaces sont considérées comme des interfaces WAN équivalentes. Reportez-vous à la figure 3.

Figure 3 : interface Abstracted Fabric Interface de structure abstraite

Comprendre la bande passante de l’interface de structure abstraite

Une interface de fabric abstraite (af) connecte deux GNF à travers la fabric et agrège tous les moteurs de transfert de paquets (PFE) qui relient 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 dispose d’un MPC8 (qui possède 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 est de 4 x 240 Gbit/s = 960 Gbit/s.

GNF1—af1——GNF2

GNF1—af2——GNF3

Ici, 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 structure abstraite

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

  • Mise à niveau logicielle en service unifié (ISSU)

  • Configuration du 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.

    Note:

    • Vous ne pouvez pas avoir différentes configurations d’hypermode pour les GNF individuels, car ils héritent de la configuration de BSYS.

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

  • Équilibrage de charge basé sur les cartes de ligne GNF distantes présentes

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

    • Classificateur et réécriture de précédence inet

    • Classificateur et réécriture DSCP

    • Classificateur MPLS EXP et réécriture

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

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

    Note:

    Les non-interfacesaf prennent en charge tous les protocoles fonctionnant sur 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 fait office d’interface af centrale (L3VPN, VPLS, L2VPN, L2CKT, EVPN et IP sur MPLS)

  • Les familles de protocoles suivantes sont prises en charge :

    • Transfert IPv4

    • Transfert IPv6

    • MPLS (en anglais)

    • ISO

    • CCC

  • Prise en charge des capteurs JTI (Junos Telemetry Interface)

  • À compter 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 (Virtual Extensible LAN). Cette prise en charge est disponible avec une interface non (c’est-à-direaf 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 de l’interface af , les GNF prennent en charge afles MPC compatibles. Le Tableau 1 répertorie les afMPC -capable, le nombre de PFE pris en charge par MPC et la bande passante prise en charge par MPC.

    Tableau 1 : MPC compatibles avec la fabric abstraite pris en charge

    MPC

    Version initiale

    Nombre de PFE

    Bande passante totale

    MPC7E-MRATE

    17.4R1

    2

    480G (240*2)

    MPC7E-10G

    17.4R1

    2

    480G (240*2)

    MX2K-MPC8E

    17.4R1

    4

    960G (240*4)

    MX2K-MPC9E

    17.4R1

    4

    1.6T (400*4)

    MPC2E (en anglais seulement)

    19.1R1

    2

    80 (40*2)

    MPC2E NG

    17.4R1

    1

    80 G

    MPC2E NG Q

    17.4R1

    1

    80 G

    MPC3E

    19.1R1

    1

    130 grammes

    MPC3E NG

    17.4R1

    1

    130 grammes

    MPC3E NG Q

    17.4R1

    1

    130 grammes

    32 x 10GE MPC4E

    19.1R1

    2

    260G (130*2)

    2 x 100GE + 8 x 10GE MPC4E

    19.1R1

    2

    260G (130*2)

    MPC5E-40G10G

    18.3R1

    2

    240G (120*2)

    MPC5EQ-40G10G

    18.3R1

    2

    240G (120*2)

    MPC5E-40G100G

    18.3R1

    2

    240G (120*2)

    MPC5EQ-40G100G

    18.3R1

    2

    240G (120*2)

    MX2K-MPC6E

    18.3R1

    4

    520G (130*4)

    MPC MULTISERVICES (MS-MPC)

    19.1R1

    1

    De 120 grammes

    MPC 16 x 10GE

    19.1R1

    4

    160G (40*4)

    MX2K-MPC11E

    19.3R2

    8

    4T (500G*8)
Note:

Nous vous recommandons de définir les paramètres 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 ou nulle des paquets sur l’interface af .

Restrictions de l’interface de structure abstraite

Voici les restrictions actuelles des interfaces de structure abstraites :

  • Les configurations telles que l’interface de point de terminaison af unique, af l’incompatibilité de mappage interface-GNF ou le mappage de plusieurs af interfaces vers le 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 et dépend du type de MPC.

  • Il peut y avoir des interruptions minimes de trafic (à la fois de transit et d’hôte) lors du déconnexion/redémarrage d’un MPC hébergé sur un GNF distant.

  • L’interopérabilité entre les MPC compatibles afavec et les MPC non afcompatibles n’est pas prise en charge.

Voir aussi

Optimisation du chemin d’accès à la structure pour l’interface de structure abstraite

Vous pouvez optimiser le trafic circulant sur les interfaces de fabric abstraite (af) entre deux fonctions réseau invitées (GNF) en configurant un mode d’optimisation du chemin d’accès à la fabric. Cette fonctionnalité réduit la consommation de la bande passante de la structure en empêchant tout saut supplémentaire de la structure (commutation 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. L’optimisation du chemin de fabric, prise en charge sur MX2008, MX2010 et MX2020 avec MPC9E et MX2K-MPC11E, empêche un seul saut de trafic supplémentaire résultant de l’équilibrage de charge abstrait de l’interface de fabric.

Vous pouvez configurer l’un des modes d’optimisation du chemin d’accès à la structure 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 sur 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 sur le moteur de transfert de paquets souhaité qui pourrait fournir un chemin de trafic optimisé. Le GNF source transfère ensuite le trafic vers le moteur de transfert de paquets souhaité.

Pour configurer un mode d’optimisation du chemin d’accès à la structure, utilisez les commandes CLI suivantes sur BSYS.

Après avoir configuré l’optimisation du chemin d’accès à la structure, 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

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

Le modèle de serveur externe vous permet de configurer davantage d’instances de GNF avec une échelle plus élevée, car vous pouvez choisir un serveur de capacité suffisante pour répondre aux exigences GNF. Avec le modèle dans le 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 serveur externe et dans le châssis de la segmentation de nœud Junos s’excluent mutuellement. Un routeur MX Series peut être configuré pour fonctionner dans un seul de ces modèles à la fois.

Comportement des rôles primaires de BSYS et GNF

Les sections suivantes traitent du comportement des rôles principaux de BSYS et GNF dans le contexte de la redondance des moteurs de routage.

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

Figure 4 : Comportement du rôle principal de GNF et BSYS (modèle de serveur externe) Primary-role Behavior of GNF and BSYS (External Server Model)

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 de GNF

Le comportement d’arbitrage du rôle principal de la machine virtuelle GNF est similaire à celui des moteurs de routage MX Series. Chaque GNF s’exécute en tant que paire de machines virtuelles de sauvegarde principale. Une VM GNF qui s’exécute sur server0 (ou re0 pour In-Chassis) 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 le 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 du rôle principal GNF s’effectue via Junos OS. En cas de défaillance de la connectivité, le rôle principal du GNF est géré de manière conservatrice.

Le modèle principal GNF est le même pour les serveurs externes et les modèles dans le châssis.

Note:

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

Rôles d’administrateur de segmentation de nud 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 GNF (affectation de cartes de ligne aux GNF). Des commandes CLI 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 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 du port 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 CLI JDM sont disponibles pour ces tâches.

Vue d’ensemble 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 trouve 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). Avec la fonctionnalité de carte de sous-ligne (SLC), vous pouvez définir une granularité de partitionnement encore plus fine, en affectant des sous-ensembles de moteurs de transfert de paquets dans une seule carte de ligne à différents GNF.

De tels 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 fonction SLC, un GNF peut comprendre un ensemble de cartes de ligne entières ainsi qu’un ensemble de tranches (SLC) de cartes de ligne, offrant 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 la 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 le 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 attribués. L’instance BLC exécute le logiciel Junos de BSYS, tandis que chaque instance SLC exécute le logiciel Junos de son GNF associé.

Figure 5 : SLC affectés aux GNF dans une configuration de segmentation de nœud Junos basée sur un serveur externe SLCs assigned to GNFs in an external server-based Junos node slicing setup

Les SLC prennent en charge l’interface de structure abstraite et le transfert réduit (voir Optimisation du chemin d’accès à la structure pour l’interface de structure abstraite). Vous pouvez utiliser la show interface af-interface-name commande pour afficher les statistiques d’équilibrage de charge des moteurs de transfert de paquets spécifiques à la tranche FPC distante. Pour plus d’informations, reportez-vous à la section show interfaces (structure abstraite).

La capacité SLC est disponible uniquement sur le MPC11E (numéro de modèle : MX2K-MPC11E).

Ressources sur les cartes 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 a 'n' moteurs de transfert de paquets, les moteurs de transfert de paquets individuels sont numérotés de 0 à (n-1). En outre, les cœurs de processeur et la DRAM sur la carte de contrôle de la carte de ligne doivent également être divisés et alloués à la tranche. Définir un SLC revient donc à définir les ressources de carte de ligne suivantes à dédier à ce SLC :

  • Une plage du moteur de transfert de paquets

  • Le 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

Note:

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 identifiant 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 de ligne MPC11E pour les SLC

Une carte de ligne MPC11E possède :

  • 8 moteurs de transfert de paquets

  • 8 cœurs de processeur 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 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.

Un 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 un 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 de ligne spécifiées indiquées dans le tableau 2 sont prises en charge.

Note:

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 attribuées et que la DRAM totale 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 attribués à l’autre SLC.

Tableau 2 : profils SLC pris en charge par MPC11E
 

Profil symétrique

Profil asymétrique

Type de ressource

Réf. SLC1

SLC2

Réf. SLC1

SLC2

moteur de transfert de paquets

4

4

2

6

DRAM

13 Go

13 Go

17 Go/9 Go

9 Go/17 Go

CPU

4

4

4

4

Voir aussi : Configuration des cartes de sous-ligne et leur affectation aux GNF et Gestion des cartes de sous-ligne.

Présentation de l’interopérabilité logicielle multiversion

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

Note:

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

Bien que la gestion des versions du logiciel JDM ne comporte pas de restriction similaire en ce qui concerne les versions logicielles GNF ou BSYS, nous vous recommandons de mettre régulièrement à jour 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’interface request system enable unified-services de ligne de commande sur GNF. Pour prendre en charge un MX-SPC3, une carte de ligne doit être associée à un GNF.

Dans une configuration de segmentation de nœud Junos, vous pouvez utiliser 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 de nouvelle génération sur GNF, le MX-SPC3 est activé à l’aide request system enable unified-servicesde . Si vous n’avez pas activé les services de nouvelle génération, le MS-MPC est activé.

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

Note:

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 nud Junos avec des systèmes logiques

La segmentation de nœud Junos est une couche inférieure aux systèmes logiques dans Junos. Les deux technologies ont des capacités qui se chevauchent, mais diffèrent sur d’autres aspects. La segmentation de nœud Junos affecte des cartes de ligne complètes, et donc des interfaces physiques, à un GNF, tandis qu’avec les systèmes logiques, une seule interface physique peut être partagée entre différents systèmes logiques, car 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 plus précis que la segmentation de nœud Junos. Cependant, 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 les ressources physiques du moteur de routage et de la carte de ligne telles que le processeur, la mémoire et le stockage. Avec la segmentation de nœud Junos, chaque GNF reçoit 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. Contrairement aux systèmes logiques, les GNF peuvent être mis à niveau et administrés indépendamment comme un routeur MX autonome.

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 contenir 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 là où une granularité fine du partage, jusqu’au niveau de l’interface logique, est primordiale, un système logique serait la meilleure solution.

Octroi de licences pour la segmentation de nud Junos

L’utilisation de la segmentation de nœud Junos nécessite l’installation de licences pour les GNF et les interfaces de fabric abstraites sur le BSYS. L’exécution d’un GNF sans licence installée sur le BSYS entraînera le message syslog suivant et une alarme mineure :

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

Documentation connexe