SUR CETTE PAGE
Comprendre la gestion de la bande passante pour le multicast
Gestion de la bande passante et redémarrage progressif du PIM
Exemple : Définition des valeurs maximales de bande passante de l’interface
Exemple : Configuration de la multidiffusion avec des VLAN abonnés
Configuration du routage multicast sur des interfaces Demux IP
Exemples : Configuration de la gestion de la bande passante
Comprendre la gestion de la bande passante pour le multicast
La gestion de la bande passante vous permet de contrôler les flux multicast qui quittent une interface multicast. Ce contrôle vous permet de mieux gérer votre trafic multicast et de réduire, voire d’éliminer, les risques de surabonnement ou d’encombrement de l’interface.
La gestion de la bande passante permet d’éviter tout surabonnement de trafic multicast sur une interface. Lors de la gestion de la bande passante multicast, vous définissez la quantité maximale de bande passante multicast qu’une interface individuelle peut utiliser, ainsi que la bande passante utilisée par les flux multicast individuels.
Par exemple, le logiciel de routage ne peut pas ajouter de flux à une interface si cela dépasse la bande passante autorisée pour cette interface. Dans ce cas, l’interface est rejetée. Ce rejet n’empêche toutefois pas un protocole multicast (par exemple, PIM) d’envoyer un message de jointure en amont. Le trafic continue d’arriver sur le routeur, même si celui-ci n’envoie pas le flux à partir des interfaces sortantes attendues.
Vous pouvez configurer la bande passante de flux de manière statique en spécifiant une valeur de bande passante pour le flux en bits par seconde, ou vous pouvez permettre de mesurer la bande passante de flux et de la modifier de manière adaptative. Lors de l’utilisation de l’option de bande passante adaptative, le logiciel de routage interroge les statistiques des flux à mesurer toutes les 5 secondes et calcule la bande passante en fonction des requêtes. Le logiciel de routage utilise la valeur maximale mesurée au cours de la dernière minute (c’est-à-dire les 12 derniers points de mesure) comme bande passante de débit.
Pour plus d’informations, consultez les sections suivantes :
Gestion de la bande passante et redémarrage progressif du PIM
Lors du redémarrage progressif de PIM, après le redémarrage du processus de routage sur le moteur de routage, les interfaces précédemment admises sont toujours réadmises et la bande passante disponible est ajustée sur les interfaces. Lors de l’utilisation de l’option de bande passante adaptative, la mesure de la bande passante est initialement basée sur la bande passante de départ configurée ou par défaut, qui peut être inexacte pendant la première minute. Cela signifie que de nouveaux flux peuvent être rejetés à tort ou admis temporairement. Vous pouvez corriger ce problème en exécutant la commande opérationnelle clear multicast bandwidth-admission .
Si le redémarrage progressif de PIM n’est pas configuré, après le redémarrage du processus de routage, les interfaces précédemment admises ou rejetées peuvent être rejetées ou admises de manière imprévisible.
Voir aussi
Gestion de la bande passante et redondance des sources
Lors de l’utilisation de la redondance source, plusieurs sources (par exemple, s1 et s2) peuvent exister pour le même groupe de destination (g). Cependant, une seule des sources peut transmettre activement à tout moment. Dans ce cas, plusieurs entrées de transfert (s1,g) et (s2,g)] sont créées après que chacune d’entre elles soit passée par le processus d’admission.
Avec les sources redondantes, contrairement aux entrées non liées, un OIF qui est déjà admis pour une entrée (par exemple, (s1,g) - est automatiquement admis pour d’autres entrées redondantes (par exemple, (s2,g). La bande passante restante sur l’interface est déduite chaque fois qu’une interface sortante est ajoutée, même si un seul expéditeur transmet activement. En mesurant la bande passante, la bande passante déduite pour les entrées inactives est créditée lorsque le routeur détecte qu’aucun trafic n’est transmis.
Pour plus d’informations sur la définition de sources redondantes, consultez Exemple : configuration d’une carte de flux de multidiffusion.
Systèmes logiques et surabonnement de bande passante
Vous pouvez gérer la bande passante à la fois au niveau de l’interface physique et de l’interface logique . Toutefois, si plusieurs systèmes logiques partagent la même interface physique, l’interface peut être surabonnée. Le surabonnement se produit si la bande passante totale de toutes les valeurs de bande passante maximales configurées séparément pour les interfaces de chaque système logique dépasse la bande passante de l’interface physique.
Lors de l’affichage des informations sur la bande passante de l’interface, une valeur négative de la bande passante disponible indique un surabonnement sur l’interface.
La bande passante de l’interface peut être sursouscrite lorsque la bande passante maximale configurée diminue ou lorsque certaines bandes passantes de flux augmentent en raison d’une modification de configuration ou d’une augmentation réelle du taux de trafic.
La bande passante de l’interface peut redevenir disponible si l’une des situations suivantes se produit :
La bande passante maximale configurée augmente.
Certains flux ne sont plus transmis à partir des interfaces, et les réserves de bande passante correspondantes sont désormais disponibles pour d’autres flux.
Certaines bandes passantes de flux diminuent en raison d’un changement de configuration ou d’une diminution réelle du taux de trafic.
Les interfaces dont la demande de flux est rejetée en raison d’une bande passante insuffisante ne sont pas automatiquement réadmises, même lorsque la bande passante est à nouveau disponible. Les interfaces rejetées ont la possibilité d’être réadmises lorsque l’une des situations suivantes se produit :
Le protocole de routage multicast met à jour l’entrée de transfert du flux après la réception d’un message de jointure, de sortie ou d’élagage ou après un changement de topologie.
Le protocole de routage multicast met à jour l’entrée de transfert du flux en raison des modifications de configuration.
Vous réappliquez manuellement la gestion de la bande passante à un flux spécifique ou à tous les flux à l’aide de la commande opérationnelle clear multicast bandwidth-admission .
En outre, même si la bande passante précédemment disponible n’est plus disponible, les interfaces déjà admises ne sont pas supprimées tant que l’une des situations suivantes ne se produit pas :
Le protocole de routage multicast supprime explicitement les interfaces après réception d’un message leave ou prune ou après un changement de topologie.
Vous réappliquez manuellement la gestion de la bande passante à un flux spécifique ou à tous les flux à l’aide de la commande opérationnelle clear multicast bandwidth-admission .
Voir aussi
Exemple : Définition des valeurs maximales de bande passante de l’interface
Cet exemple vous montre comment configurer la bande passante maximale pour une interface physique ou logique.
Exigences
Avant de commencer :
Configurez les interfaces des routeurs.
Configurez un protocole de passerelle intérieure. Voir la bibliothèque des protocoles de routage Junos OS pour les périphériques de routage.
Configurez un protocole multicast. Cette fonctionnalité fonctionne avec les protocoles multicast suivants :
DVMRP (en anglais seulement)
PIM-DM
PIM-SM
PIM-SSM
Aperçu
Le paramètre de bande passante maximale applique le contrôle d’admission soit à la bande passante de l’interface configurée, soit à la vitesse native de l’interface sous-jacente (lorsqu’il n’y a pas de bande passante configurée pour l’interface).
Si vous configurez plusieurs interfaces logiques (par exemple, pour prendre en charge des VLAN ou des circuits virtuels permanents) sur la même interface physique sous-jacente et qu’aucune bande passante n’est configurée pour les interfaces logiques, il est supposé que les interfaces logiques ont toutes la même bande passante que l’interface sous-jacente. Cela peut entraîner un surabonnement. Pour éviter le surabonnement, configurez la bande passante des interfaces logiques ou configurez le contrôle d’admission au niveau de l’interface physique.
Il vous suffit de définir la bande passante maximale pour une interface sur laquelle vous souhaitez appliquer la gestion de la bande passante. Une interface qui n’a pas de bande passante maximale définie transmet tous les flux de multidiffusion tels que déterminés par le protocole de multidiffusion qui s’exécute sur l’interface (par exemple, PIM).
Si vous spécifiez la bande passante maximale sans inclure de valeur de bits par seconde, le contrôle d’admission est activé en fonction de la bande passante configurée pour l’interface. Dans l’exemple suivant, le contrôle d’admission est activé pour l’unité d’interface logique 200 et la bande passante maximale est de 20 Mbits/s. Si la bande passante n’est pas configurée sur l’interface, la bande passante maximale correspond à la vitesse de la liaison.
routing-options {
multicast {
interface fe-0/2/0.200 {
maximum-bandwidth;
}
interfaces {
fe-0/2/0 {
unit 200 {
bandwidth 20m;
}
}
}
Topologie
Configuration
Procédure
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
set interfaces fe-0/2/0 unit 200 bandwidth 20m set routing-options multicast interface fe-0/2/0.200 maximum-bandwidth set routing-options multicast interface fe-0/2/1 maximum-bandwidth 60m set routing-options multicast interface fe-0/2/1.200 maximum-bandwidth 10m
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande Junos OS.
Pour configurer une bande passante maximale :
Configurez la bande passante d’une interface logique.
[edit interfaces] user@host# set fe-0/2/0 unit 200 bandwidth 20m
Activez le contrôle d’admission sur l’interface logique.
[edit routing-options] user@host# set multicast interface fe-0/2/0.200 maximum-bandwidth
Sur une interface physique, activez le contrôle d’admission et définissez la bande passante maximale à 60 Mbit/s.
[edit routing-options] user@host# set multicast interface fe-0/2/1 maximum-bandwidth 60m
Pour une interface logique sur la même interface physique que celle décrite à l’étape 3, définissez une bande passante maximale plus petite.
[edit routing-options] user@host# set multicast interface fe-0/2/1.200 maximum-bandwidth 10m
Résultats
Confirmez votre configuration en entrant les commandes show interfaces et show routing-options .
user@host# show interfaces
fe-0/2/0 {
unit 200 {
bandwidth 20m;
}
}
user@host# show routing-options
multicast {
interface fe-0/2/0.200 {
maximum-bandwidth;
}
interface fe-0/2/1 {
maximum-bandwidth 60m;
}
interface fe-0/2/1.200 {
maximum-bandwidth 10m;
}
}
Vérification
Pour vérifier la configuration, exécutez la commande show multicast interface .
Exemple : Configuration de la multidiffusion avec des VLAN abonnés
Cet exemple montre comment configurer un routeur MX Series pour qu’il fonctionne comme un routeur de services haut débit (BSR).
Exigences
Cet exemple utilise les composants matériels suivants :
Un routeur MX Series ou un commutateur EX Series avec un PIC prenant en charge la mise en file d’attente de profil de contrôle du trafic
Un DSLAM
Avant de commencer :
Configurez un protocole de passerelle intérieure. Voir la bibliothèque des protocoles de routage Junos OS pour les périphériques de routage.
Configurez PIM et IGMP ou MLD sur les interfaces.
Vue d’ensemble et topologie
Lorsque plusieurs interfaces BSR reçoivent des demandes d’entrée et de sortie IGMP et MLD pour le même flux de multidiffusion, le BSR envoie une copie du flux de multidiffusion sur chaque interface. Les paquets de contrôle multicast (IGMP et MLD) et les paquets de données multicast circulent sur la même interface BSR, en même temps que les données unicast. Étant donné que l’ensemble du trafic par client possède sa propre interface sur le BSR, la comptabilité par client, le contrôle d’admission des appels (CAC) et l’ajustement de la qualité de service (QoS) sont pris en charge. La bande passante QoS utilisée par le multicast réduit la bande passante unicast.
Plusieurs interfaces sur le BSR peuvent se connecter à un périphérique partagé (par exemple, un DSLAM). Le BSR envoie le même flux multicast plusieurs fois à l’appareil partagé, gaspillant ainsi de la bande passante. Il est plus efficace d’envoyer le flux multicast une seule fois au DSLAM et de répliquer les flux multicast dans le DSLAM. Il existe deux approches que vous pouvez utiliser.
La première approche consiste à continuer d’envoyer des données unicast sur les interfaces par client, mais à faire en sorte que le DSLAM achemine toutes les demandes IGMP et MLD par client et les laisse au BSR sur une seule interface dédiée (un VLAN multicast). Le DSLAM reçoit les flux multicast du BSR sur l’interface dédiée sans réplication inutile et effectue la réplication nécessaire pour les clients. Étant donné que tous les paquets de contrôle et de données multicast n’utilisent qu’une seule interface, une seule copie d’un flux est envoyée, même s’il existe plusieurs requêtes. C’est ce qu’on appelle le mappage OIF (Reverse Outgoing Interface). Le mappage OIF inverse permet au BSR de propager l’état multicast de l’interface partagée aux interfaces client, ce qui permet de gérer la comptabilité par client et d’ajuster la qualité de service (QoS). Lorsqu’un client change de chaîne TV, la passerelle de routeur (RG) envoie une connexion IGMP ou MLD et laisse des messages au DSLAM. Le DSLAM transmet la demande au BSR de manière transparente via le VLAN multicast. Le BSR mappe la demande IGMP ou MLD à l’un des VLAN abonnés en fonction de l’adresse IP source ou de l’adresse MAC source. Lorsque le VLAN abonné est trouvé, l’ajustement de la qualité de service et la comptabilité sont effectués sur ce VLAN ou cette interface.
La deuxième approche consiste pour le DSLAM à continuer d’envoyer des données unicast et toutes les demandes d’entrée et de sortie IGMP et MLD par client au BSR sur les interfaces client individuelles, mais à faire en sorte que les flux multicast arrivent sur une seule interface dédiée. Si plusieurs clients demandent le même flux multicast, le BSR envoie une copie des données sur l’interface dédiée. Le DSLAM reçoit les flux multicast du BSR sur l’interface dédiée et effectue la réplication nécessaire pour les clients. Étant donné que les paquets de contrôle multicast utilisent de nombreuses interfaces client, la configuration sur le BSR doit spécifier comment mapper les paquets de données multicast de chaque client à l’interface de sortie dédiée unique. Le réglage de la qualité de service est pris en charge sur les interfaces client. CAC est pris en charge sur l’interface partagée. Cette deuxième approche est appelée mappage OIF multicast.
Le mappage OIF et le mappage OIF inverse ne sont pas pris en charge sur la même interface client ou interface partagée. Cet exemple montre comment configurer les deux approches différentes. Les deux approches prennent en charge l’ajustement de la QoS et les deux approches prennent en charge MLD/IPv6. L’exemple de mappage OIF inverse se concentre sur IGMP/IPv4 et permet d’ajuster la QoS. L’exemple de mappage OIF se concentre sur MLD/IPv6 et désactive l’ajustement QoS.
La première approche (cartographie OIF inversée) comprend les énoncés suivants :
flow-map : définit une carte de flux qui contrôle la bande passante de chaque flux.
maximum-bandwidth : active CAC.
reverse-oif-mapping : permet au périphérique de routage d’identifier un VLAN ou une interface d’abonné en fonction d’une demande de jointure ou de sortie IGMP ou MLD qu’il reçoit sur le VLAN multicast.
Une fois le VLAN abonné identifié, le périphérique de routage ajuste immédiatement la QoS (dans ce cas, la bande passante) sur ce VLAN en fonction de l’ajout ou de la suppression d’un abonné.
L’équipement de routage utilise les rapports de jointure ou de sortie IGMP et MLD pour obtenir les informations du VLAN abonné. Cela signifie que l’équipement de connexion (par exemple, le DSLAM) doit transmettre tous les rapports IGMP et MLD au périphérique de routage pour que cette fonctionnalité fonctionne correctement. L’utilisation de la suppression de rapports ou d’un proxy IGMP peut entraîner un dysfonctionnement du mappage OIF inverse.
subscriber-leave-timer : introduit un délai pour la mise à jour QoS. Après réception d’une demande de congé IGMP ou MLD, cette instruction définit un délai (entre 1 et 30 secondes) que le périphérique de routage attend avant de mettre à jour la QoS pour les interfaces d’abonné restantes. Vous pouvez utiliser ce délai pour réduire la fréquence à laquelle le périphérique de routage ajuste la bande passante QoS globale sur le VLAN lorsqu’un abonné envoie des messages de départ et de connexion rapides (par exemple, lors d’un changement de canal dans un réseau IPTV).
traffic-control-profile : configure un taux de mise en forme sur l’interface logique. Le taux de mise en forme configuré doit être configuré en tant que valeur absolue et non en tant que pourcentage.
La deuxième approche (cartographie OIF) comprend les énoncés suivants :
map-to-interface : dans une déclaration de stratégie, vous permet de créer la carte OIF.
La carte OIF est une instruction de stratégie de routage qui peut contenir plusieurs termes. Lorsque vous créez des cartes OIF, gardez à l’esprit les points suivants :
Si vous spécifiez une interface physique (par exemple, ge-0/0/0), un « .0 » est ajouté à l’interface pour créer une interface logique (par exemple, ge-0/0/0.0).
Configurez une stratégie de routage pour chaque système logique. Vous ne pouvez pas configurer les stratégies de routage de manière dynamique.
IGMP, MLD ou PIM doit également être configuré sur l’interface.
Vous ne pouvez pas mapper à une interface mappée.
Nous vous recommandons de configurer séparément les instructions de stratégie pour IGMP et MLD.
Spécifiez soit une interface logique, soit le mot-clé self. Le mot-clé self spécifie que les paquets de données multicast doivent être envoyés sur la même interface que les paquets de contrôle et qu’aucun mappage n’est effectué. Si aucun terme ne correspond, aucun paquet de données multicast n’est envoyé.
no-qos-adjust : désactive l’ajustement QoS.
L’ajustement QoS diminue la bande passante disponible sur l’interface client de la quantité de bande passante consommée par les flux multicast mappés de l’interface client à l’interface partagée. Cette action se produit toujours, sauf si elle est explicitement désactivée.
Si vous désactivez l’ajustement QoS, la bande passante disponible n’est pas réduite sur l’interface client lorsque des flux multicast sont ajoutés à l’interface partagée.
Note:Vous pouvez désactiver dynamiquement l’ajustement QoS pour les interfaces IGMP et MLD à l’aide de profils dynamiques.
oif-map : permet d’associer une carte à une interface IGMP ou MLD. La carte OIF est ensuite appliquée à toutes les requêtes IGMP ou MLD reçues sur l’interface configurée. Dans cet exemple, MLD est configuré pour les VLAN abonnés 1 et 2, et chaque VLAN pointe vers une carte OIF qui dirige une partie du trafic vers ge-2/3/9.4000, une partie vers ge-2/3/9.4001 et une partie vers self.
Note:Vous pouvez associer dynamiquement des cartes OIF à des interfaces IGMP à l’aide de profils dynamiques.
passive : définit IGMP ou MLD pour utiliser le mode passif.
En règle générale, l’interface de mappage OIF ne doit pas transmettre le trafic de contrôle IGMP ou MLD et doit être configurée de manière passive. Toutefois, l’implémentation de la carte OIF prend en charge l’exécution d’IGMP ou de MLD sur une interface (contrôle et données) en plus du mappage des flux de données vers la même interface. Dans ce cas, vous devez configurer IGMP ou MLD normalement (c’est-à-dire pas en mode passif) sur l’interface mappée. Dans cet exemple, les interfaces de mappage OIF (ge-2/3/9.4000 et ge-2/3/9.4001) sont configurées en tant que MLD passif.
Par défaut, la spécification de l’instruction passive signifie qu’aucune requête générale, requête spécifique à un groupe ou requêtes spécifique à une source de groupe n’est envoyée sur l’interface et que tout le trafic de contrôle reçu est ignoré par l’interface. Cependant, vous pouvez activer de manière sélective jusqu’à deux des trois options disponibles pour l’instruction passive tout en gardant les autres fonctions passives (inactives).
Ces options sont les suivantes :
send-general-query : lorsqu’elle est spécifiée, l’interface envoie des requêtes générales.
send-group-query : lorsqu’elle est spécifiée, l’interface envoie des requêtes spécifiques au groupe et à la source du groupe.
allow-receive : lorsque cette option est spécifiée, l’interface reçoit le trafic de contrôle.
Topologie
La figure 1 illustre le scénario.
Dans les deux approches, si plusieurs clients demandent le même flux multicast, le BSR envoie une copie du flux sur l’interface VLAN multicast partagée. Le DSLAM reçoit le flux multicast du BSR sur l’interface partagée et effectue la réplication nécessaire pour les clients.
Dans la première approche (mappage OIF inverse), le DSLAM utilise les VLAN d’abonné par client pour les données unicast uniquement. Les demandes d’adhésion et de sortie IGMP et MLD sont envoyées sur le VLAN multicast.
Dans la deuxième approche (mappage OIF), le DSLAM utilise les VLAN d’abonné par client pour les données unicast et pour les demandes d’entrée et de sortie IGMP et MLD. Le VLAN multicast n’est utilisé que pour les flux multicast, et non pour les demandes d’adhésion et de départ.
abonnés
Configuration
Configuration d’une carte OIF inverse
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
set class-of-service traffic-control-profiles tcp-ifl shaping-rate 20m set class-of-service interfaces ge-2/2/0 shaping-rate 240m set class-of-service interfaces ge-2/2/0 unit 50 output-traffic-control-profile tcp-ifl set class-of-service interfaces ge-2/2/0 unit 51 output-traffic-control-profile tcp-ifl set interfaces ge-2/0/0 unit 0 family inet address 30.0.0.2/24 set interfaces ge-2/2/0 hierarchical-scheduler set interfaces ge-2/2/0 vlan-tagging set interfaces ge-2/2/0 unit 10 vlan-id 10 set interfaces ge-2/2/0 unit 10 family inet address 40.0.0.2/24 set interfaces ge-2/2/0 unit 50 vlan-id 50 set interfaces ge-2/2/0 unit 50 family inet address 50.0.0.2/24 set interfaces ge-2/2/0 unit 51 vlan-id 51 set interfaces ge-2/2/0 unit 51 family inet address 50.0.1.2/24 set policy-options policy-statement all-mcast-groups from source-address-filter 30.0.0.0/8 orlonger set policy-options policy-statement all-mcast-groups then accept set protocols igmp interface all set protocols igmp interface fxp0.0 disable set protocols pim rp local address 20.0.0.2 set protocols pim interface all set protocols pim interface fxp0.0 disable set protocols pim interface ge-2/2/0.10 disable set routing-options multicast flow-map map1 policy all-mcast-groups set routing-options multicast flow-map map1 bandwidth 10m set routing-options multicast flow-map map1 bandwidth adaptive set routing-options multicast interface ge-2/2/0.10 maximum-bandwidth 500m set routing-options multicast interface ge-2/2/0.10 reverse-oif-mapping set routing-options multicast interface ge-2/2/0.10 subscriber-leave-timer 20
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande Junos OS.
Pour configurer le mappage OIF inverse :
Configurez une interface logique pour le trafic de données unicast.
[edit interfaces ge-2/0/0] user@host# set unit 0 family inet address 30.0.0.2/24
Configurez une interface logique pour le trafic de contrôle des abonnés.
[edit interfaces ge-2/2/0] user@host# set hierarchical-scheduler user@host# set vlan-tagging user@host# set unit 10 vlan-id 10 user@host# set unit 10 family inet address 40.0.0.2/24
Configurez deux interfaces logiques sur lesquelles des ajustements QoS sont effectués.
[edit interfaces ge-2/2/0] user@host# set unit 50 vlan-id 50 user@host# set unit 50 family inet address 50.0.0.2/24 user@host# set unit 51 vlan-id 51 user@host# set unit 51 family inet address 50.0.1.2/24
Configurez une stratégie.
[edit policy-options policy-statement all-mcast-groups] user@host# set from source-address-filter 30.0.0.0/8 orlonger user@host# set then accept
Activez une carte de flux qui fait référence à la stratégie.
[edit routing-options multicast] user@host# set flow-map map1 policy all-mcast-groups user@host# set flow-map map1 bandwidth 10m adaptive
Activez le mappage OIF sur l’interface logique qui reçoit le trafic de contrôle des abonnés.
[edit routing-options multicast] user@host# set interface ge-2/2/0.10 maximum-bandwidth 500m user@host# set interface ge-2/2/0.10 reverse-oif-mapping user@host# set interface ge-2/2/0.10 subscriber-leave-timer 20
Configurez PIM et IGMP.
[edit protocols] user@host# set igmp interface all user@host# set igmp interface fxp0.0 disable user@host# set pim rp local address 20.0.0.2 user@host# set pim interface all user@host# set pim interface fxp0.0 disable user@host# set pim interface ge-2/2/0.10 disable
Configurez le planificateur hiérarchique en configurant un taux de mise en forme pour l’interface physique et un taux de mise en forme plus lent pour les interfaces logiques sur lesquelles des ajustements de QoS sont effectués.
[edit class-of-service interfaces ge-2/2/0] user@host# set shaping-rate 240m user@host# set unit 50 output-traffic-control-profile tcp-ifl user@host# set unit 51 output-traffic-control-profile tcp-ifl [edit class-of-service traffic-control-profiles tcp-30m-no-smap] user@host# set shaping-rate 20m
Résultats
En mode configuration, confirmez votre configuration en entrant les commandes show class-of-service, show interfaces, show policy-options, show protocols, show routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@host# show class-of-service
traffic-control-profiles {
tcp-ifl {
shaping-rate 20m;
}
}
interfaces {
ge-2/2/0 {
shaping-rate 240m;
unit 50 {
output-traffic-control-profile tcp-ifl;
}
unit 51 {
output-traffic-control-profile tcp-ifl;
}
}
}
user@host# show interfaces
ge-2/0/0 {
unit 0 {
family inet {
address 30.0.0.2/24;
}
}
}
ge-2/2/0 {
hierarchical-scheduler;
vlan-tagging;
unit 10 {
vlan-id 10;
family inet {
address 40.0.0.2/24;
}
}
unit 50 {
vlan-id 50;
family inet {
address 50.0.0.2/24;
}
}
unit 51 {
vlan-id 51;
family inet {
address 50.0.1.2/24;
}
}
}
user@host# show policy-options
policy-statement all-mcast-groups {
from {
source-address-filter 30.0.0.0/8 orlonger;
}
then accept;
}
user@host# show protocols
igmp {
interface all;
interface fxp0.0 {
disable;
}
}
pim {
rp {
local {
address 20.0.0.2;
}
}
interface all;
interface fxp0.0 {
disable;
}
interface ge-2/2/0.10 {
disable;
}
}
user@host# show routing-options
multicast {
flow-map map1 {
policy all-mcast-groups;
bandwidth 10m adaptive;
}
interface ge-2/2/0.10 {
maximum-bandwidth 500m;
reverse-oif-mapping;
subscriber-leave-timer 20;
}
}
Si vous avez terminé de configurer l’appareil, entrez commit à partir du mode de configuration.
Configuration d’une carte OIF
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
set interfaces ge-2/3/8 unit 0 family inet6 address C300:0101::/24 set interfaces ge-2/3/9 vlan-tagging set interfaces ge-2/3/9 unit 1 vlan-id 1 set interfaces ge-2/3/9 unit 1 family inet6 address C400:0101::/24 set interfaces ge-2/3/9 unit 2 vlan-id 2 set interfaces ge-2/3/9 unit 2 family inet6 address C400:0201::/24 set interfaces ge-2/3/9 unit 4000 vlan-id 4000 set interfaces ge-2/3/9 unit 4000 family inet6 address C40F:A001::/24 set interfaces ge-2/3/9 unit 4001 vlan-id 4001 set interfaces ge-2/3/9 unit 4001 family inet6 address C40F:A101::/24 set policy-options policy-statement g539-v6 term g539-4000 from route-filter FF05:0101:0000::/39 orlonger set policy-options policy-statement g539-v6 term g539-4000 then map-to-interface ge-2/3/9.4000 set policy-options policy-statement g539-v6 term g539-4000 then accept set policy-options policy-statement g539-v6 term g539-4001 from route-filter FF05:0101:0200::/39 orlonger set policy-options policy-statement g539-v6 term g539-4001 then map-to-interface ge-2/3/9.4001 set policy-options policy-statement g539-v6 term g539-4001 then accept set policy-options policy-statement g539-v6 term self from route-filter FF05:0101:0700::/40 orlonger set policy-options policy-statement g539-v6 term self then map-to-interface self set policy-options policy-statement g539-v6 term self then accept set policy-options policy-statement g539-v6-all term g539 from route-filter 0::/0 orlonger set policy-options policy-statement g539-v6-all term g539 then map-to-interface ge-2/3/9.4000 set policy-options policy-statement g539-v6-all term g539 then accept set protocols mld interface fxp0.0 disable set protocols mld interface ge-2/3/9.4000 passive set protocols mld interface ge-2/3/9.4001 passive set protocols mld interface ge-2/3/9.1 version 1 set protocols mld interface ge-2/3/9.1 oif-map g539-v6 set protocols mld interface ge-2/3/9.2 version 2 set protocols mld interface ge-2/3/9.2 oif-map g539-v6 set protocols pim rp local address 20.0.0.4 set protocols pim rp local family inet6 address C000::1 set protocols pim interface ge-2/3/8.0 mode sparse set protocols pim interface ge-2/3/8.0 version 2 set routing-options multicast interface ge-2/3/9.1 no-qos-adjust set routing-options multicast interface ge-2/3/9.2 no-qos-adjust
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans la CLI, consultez le Guide de l’utilisateur de la CLI de Junos OS.
Pour configurer le mappage OIF inverse :
Configurez une interface logique pour le trafic de données unicast.
[edit interfaces ge-2/3/8 ] user@host# set unit 0 family inet6 address C300:0101::/24
Configurez les interfaces logiques pour les VLAN abonnés.
[edit interfaces ge-2/3/9] user@host# set vlan-tagging user@host# set unit 1 vlan-id 1 user@host# set unit 1 family inet6 address C400:0101::/24 user@host# set unit 2 vlan-id 2 user@host# set unit 2 family inet6 address C400:0201::/24 lo0 unit 0 family inet6 address C000::1/128 user@host# set unit 2 family inet6 address C400:0201::/24
Configurez deux interfaces logiques de mappage.
[edit interfaces ge-2/2/0] user@host# set unit 4000 vlan-id 4000 user@host# set unit 4000 family inet6 address C40F:A001::/24 user@host# set unit 4001 vlan-id 4001 user@host# set unit 4001 family inet6 address C40F:A101::/24
Configurez la carte OIF.
[edit policy-options policy-statement g539-v6] user@host# set term g539-4000 from route-filter FF05:0101:0000::/39 orlonger user@host# set then map-to-interface ge-2/3/9.4000 user@host# set then accept user@host# set term g539-4001 from route-filter FF05:0101:0200::/39 orlonger user@host# set then map-to-interface ge-2/3/9.4001 user@host# set then accept user@host# set term self from route-filter FF05:0101:0700::/40 orlonger user@host# set then map-to-interface self user@host# set then accept [edit policy-options policy-statement g539-v6-all] user@host# set term g539 from route-filter 0::/0 orlonger user@host# set then map-to-interface ge-2/3/9.4000 user@host# set then accept
Désactivez l’ajustement QoS sur les VLAN abonnés.
[edit routing-options multicast] user@host# set interface ge-2/3/9.1 no-qos-adjust user@host# set interface ge-2/3/9.2 no-qos-adjust
Configurez PIM et MLD. Pointez les VLAN abonnés MLD vers la carte OIF.
[edit protocols] user@host# set pim rp local address 20.0.0.4 user@host# set pim rp local family inet6 address C000::1 #C000::1 is the address of lo0 user@host# set pim interface ge-2/3/8.0 mode sparse user@host# set pim interface ge-2/3/8.0 version 2 user@host# set mld interface fxp0.0 disable user@host# set interface ge-2/3/9.4000 passive user@host# set interface ge-2/3/9.4001 passive user@host# set interface ge-2/3/9.1 version 1 user@host# set interface ge-2/3/9.1 oif-map g539-v6 user@host# set interface ge-2/3/9.2 version 2 user@host# set interface ge-2/3/9.2 oif-map g539-v6
Résultats
En mode configuration, confirmez votre configuration en entrant les commandes show interfaces, show policy-options, show protocols, show routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@host# show interfaces
ge-2/3/8 {
unit 0 {
family inet6 {
address C300:0101::/24;
}
}
}
ge-2/3/9 {
vlan-tagging;
unit 1 {
vlan-id 1;
family inet6 {
address C400:0101::/24;
}
}
unit 2 {
vlan-id 2;
family inet6 {
address C400:0201::/24;
}
}
unit 4000 {
vlan-id 4000;
family inet6 {
address C40F:A001::/24;
}
}
unit 4001 {
vlan-id 4001;
family inet6 {
address C40F:A101::/24;
}
}
}
user@host# show policy-options
policy-statement g539-v6 {
term g539-4000 {
from {
route-filter FF05:0101:0000::/39 orlonger;
}
then {
map-to-interface ge-2/3/9.4000;
accept;
}
}
term g539-4001 {
from {
route-filter FF05:0101:0200::/39 orlonger;
}
then {
map-to-interface ge-2/3/9.4001;
accept;
}
}
term self {
from {
route-filter FF05:0101:0700::/40 orlonger;
}
then {
map-to-interface self;
accept;
}
}
}
policy-statement g539-v6-all {
term g539 {
from {
route-filter 0::/0 orlonger;
}
then {
map-to-interface ge-2/3/9.4000;
accept;
}
}
}
user@host# show protocols
mld {
interface fxp0.0 {
disable;
}
interface ge-2/3/9.4000 {
passive;
}
interface ge-2/3/9.4001 {
passive;
}
interface ge-2/3/9.1 {
version 1;
oif-map g539-v6;
}
interface ge-2/3/9.2 {
version 2;
oif-map g539-v6;
}
}
pim {
rp {
local {
address 20.0.0.4;
family inet6 {
address C000::1;
}
}
}
interface ge-2/3/8.0 {
mode sparse;
version 2;
}
}
user@host# show routing-options
multicast {
interface ge-2/3/9.1 no-qos-adjust;
interface ge-2/3/9.2 no-qos-adjust;
}
Si vous avez terminé de configurer l’appareil, entrez commit à partir du mode de configuration.
Vérification
Pour vérifier la configuration, exécutez les commandes suivantes :
Afficher les statistiques IGMP
Afficher l’interface de classe de service
afficher les statistiques des interfaces
Afficher les statistiques MLD
afficher l’interface multicast
Afficher la politique
Configuration du routage multicast sur des interfaces Demux IP
Dans un réseau de gestion des abonnés, les champs des paquets envoyés à partir d’interfaces IP demux sont censés correspondre à un client spécifique qui réside de l’autre côté d’un équipement d’agrégation (par exemple, un nœud d’accès multiservice [MSAN]). Toutefois, les paquets envoyés d’un routeur de services haut débit (BSR) à un MSAN n’identifient pas l’interface demux. Une fois qu’il a obtenu un paquet, c’est au périphérique MSAN de déterminer quel client reçoit le paquet.
Selon l’intelligence du périphérique MSAN, déterminer quel client reçoit le paquet peut se faire de manière inefficace. Par exemple, lorsqu’il reçoit du trafic de contrôle IGMP, un MSAN peut transférer le trafic de contrôle à tous les clients au lieu d’un seul client prévu. En outre, une fois qu’une destination de flux de données est établie, bien qu’un MSAN puisse utiliser la surveillance IGMP pour déterminer quels hôtes résident dans un groupe particulier et limiter les flux de données à ce seul groupe, le MSAN doit toujours envoyer plusieurs copies du flux de données à chaque membre du groupe, même si ce flux de données n’est destiné qu’à un seul client du groupe.
Diverses fonctionnalités multicast, lorsqu’elles sont combinées, vous permettent d’éviter les inefficacités mentionnées ci-dessus. Ces fonctionnalités sont les suivantes :
Possibilité de configurer l’instruction de la famille d’interfaces IP demux afin d’utiliser inet pour l’interface principale numérotée ou non numérotée.
Possibilité de configurer IGMP sur l’interface principale pour envoyer des requêtes générales à tous les clients. La configuration demux empêche l’interface IGMP principale de recevoir des paquets de contrôle IGMP client. Au lieu de cela, tous les paquets de contrôle IGMP sont dirigés vers les interfaces demux. Toutefois, pour garantir qu’aucune jointure ne se produise sur l’interface principale :
Pour les interfaces IGMP statiques : incluez l’instruction passive send-general-query dans la configuration IGMP au niveau hiérarchique [edit protocols igmp interfaceinterface-name].
Pour les interfaces demux IGMP dynamiques : incluez l’instruction passive send-general-query au niveau hiérarchique [edit dynamic-profiles profile-name protocols igmp interfaceinterface-name].
Il est possible de mapper tous les groupes multicast à l’interface principale comme suit :
Pour les interfaces IGMP statiques : incluez l’instruction oif-map au niveau hiérarchique [modifier l’interface interface-nameigmp des protocoles].
Pour les interfaces demux IGMP dynamiques : incluez l’instruction oif-map au niveau hiérarchique [edit dynamic-profiles profile-name protocols igmp interfaceinterface-name].
À l’aide de l’instruction oif-map , vous pouvez mapper le même groupe IGMP à la même interface de sortie et n’envoyer qu’une seule copie du flux multicast à partir de l’interface.
La possibilité de configurer IGMP sur chaque interface demux. Pour éviter les requêtes générales en double :
Pour les interfaces IGMP statiques : incluez l’instruction passive allow-receive send-group-query au niveau hiérarchique [edit protocols igmp interfaceinterface-name].
Pour les interfaces demux dynamiques : incluez l’instruction passive allow-receive send-group-query au niveau hiérarchique [edit dynamic-profiles profile-name protocols igmp interfaceinterface-name].
Note:Pour n’envoyer qu’une seule copie de chaque groupe, quel que soit le nombre de clients qui les rejoignent, utilisez l’instruction oif-map comme mentionné précédemment.
Voir aussi
Classification des paquets par interface de sortie
Pour les routeurs de périphérie multiservice M320 et les routeurs centraux T Series de Juniper Networks dotés des interfaces de file d’attente intelligente (IQ), IQ2, IQE (Enhanced IQE), LSQ (Multiservices Link Services Intelligent Queuing) ou ATM2 PIC, vous pouvez classer les paquets unicast et multicast en fonction de l’interface de sortie. Pour le trafic unicast, vous pouvez également utiliser un filtre multichamp, mais seule la classification de l’interface de sortie s’applique au trafic multicast ainsi qu’au trafic unicast. Si vous configurez la classification de sortie d’une interface, vous ne pouvez pas effectuer de réécritures de point de code DSCP (Differentiated Services Codepoint) sur l’interface. Par défaut, le système n’effectue aucune classification en fonction de l’interface de sortie.
Sur un routeur MX Series qui contient des MPC et des MS-DPC, les paquets multicast sont abandonnés sur le routeur et ne sont pas traités correctement si le routeur contient des interfaces logiques LSQ MLPPP qui fonctionnent comme des récepteurs multicast et si le mode de services réseau est configuré en mode IP amélioré sur le routeur. Ce comportement est attendu avec les interfaces LSQ en conjonction avec le mode IP amélioré. Dans un tel scénario, si le mode IP amélioré n’est pas configuré, la multidiffusion fonctionne correctement. Toutefois, si le routeur contient des interfaces LSQ redondantes et un mode de services réseau IP amélioré configuré avec la localisation FIB, le multicast fonctionne correctement.
Pour activer la classification des paquets par l’interface de sortie, vous devez d’abord configurer une carte de classe de transfert et un ou plusieurs numéros de file d’attente pour l’interface de sortie au niveau de la [edit class-of-service forwarding-class-map forwarding-class-map-name] hiérarchie :
[edit class-of-service] forwarding-classes-interface-specific forwarding-class-map-name { class class-name queue-num queue-number [ restricted-queue queue-number ]; }
Pour les routeurs T Series limités à seulement quatre files d’attente, vous pouvez contrôler l’affectation de la file d’attente avec l’option restricted-queue ou autoriser le système à déterminer automatiquement la file d’attente de manière modulaire. Par exemple, un mappage affectant des paquets à la file d’attente 6 serait mappé à la file d’attente 2 sur un système à quatre files d’attente.
Si vous configurez une carte de classe de transfert de sortie associant une classe de transfert à un numéro de file d’attente, cette carte n’est pas prise en charge sur les interfaces de file d’attente intelligente (lsq-) de services de liaison multiservices.
Une fois que le mappage de classe de transfert a été configuré, vous appliquez le mappage à l’interface logique à l’aide de l’instruction output-forwarding-class-map au niveau de la [edit class-of-service interfaces interface-name unit logical-unit-number ] hiérarchie :
[edit class-of-service interfaces interface-name unit logical-unit-number] output-forwarding-class-map forwarding-class-map-name;
Tous les paramètres relatifs aux files d’attente et à la classe de transfert doivent également être configurés. Pour plus d’informations sur la configuration des classes de transfert et des files d’attente, consultez Configuration d’une classe de transfert personnalisée pour chaque file d’attente.
Cet exemple montre comment configurer une carte de classe de transfert spécifique à l’interface nommée FCMAP1 qui restreint les files d’attente 5 et 6 à différentes files d’attente sur des systèmes à quatre files d’attente et s’applique FCMAP1 ensuite à de l’interface unit 0 ge-6/0/0:
[edit class-of-service]
forwarding-class-map FCMAP1 {
class FC1 queue-num 6 restricted-queue 3;
class FC2 queue-num 5 restricted-queue 2;
class FC3 queue-num 3;
class FC4 queue-num 0;
class FC3 queue-num 0;
class FC4 queue-num 1;
}
[edit class-of-service]
interfaces {
ge-6/0/0 unit 0 {
output-forwarding-class-map FCMAP1;
}
}
Notez que sans l’option restricted-queue dans FCMAP1, l’exemple affecterait FC1 et FC2 aux files d’attente 2 et 1, respectivement, sur un système limité à quatre files d’attente.
Utilisez la show class-of-service forwarding-class forwarding-class-map-name commande pour afficher la configuration de la file d’attente de mappage de la classe de transfert :
user@host> show class-of-service forwarding-class FCMAP2 Forwarding class ID Queue Restricted queue FC1 0 6 3 FC2 1 5 2 FC3 2 3 3 FC4 3 0 0 FC5 4 0 0 FC6 5 1 1 FC7 6 6 2 FC8 7 7 3
Utilisez la show class-of-service interface interface-name commande pour afficher les cartes de classe de transfert (et d’autres informations) affectées à une interface logique :
user@host> show class-of-service interface ge-6/0/0 Physical interface: ge-6/0/0, Index: 128 Queues supported: 8, Queues in use: 8 Scheduler map: <default>, Index: 2 Input scheduler map: <default>, Index: 3 Chassis scheduler map: <default-chassis>, Index: 4 Logical interface: ge-6/0/0.0, Index: 67 Object Name Type Index Scheduler-map sch-map1 Output 6998 Scheduler-map sch-map1 Input 6998 Classifier dot1p ieee8021p 4906 forwarding-class-map FCMAP1 Output 1221 Logical interface: ge-6/0/0.1, Index 68 Object Name Type Index Scheduler-map <default> Output 2 Scheduler-map <default> Input 3 Logical interface: ge-6/0/0.32767, Index 69 Object Name Type Index Scheduler-map <default> Output 2 Scheduler-map <default> Input 3
Gestion de la bande passante recyclée
Les routeurs ACX utilisent l’interface de recyclage pour boucler ou faire circuler le trafic de l’interface de sortie vers l’entrée pour un traitement supplémentaire. Ceci est nécessaire pour les applications qui nécessitent un traitement supplémentaire.
L’interface de recyclage est une interface canalisée interne dotée d’un modélisateur de sortie qui limite le débit du trafic sortant. Par défaut, la bande passante de l’interface recyclée est basée sur le surabonnement du châssis et la configuration FPC ou d’interface spécifique à la plate-forme.
Les applications qui utilisent le mécanisme de recyclage configurent des canaux ou des ports virtuels en fonction des besoins, qui à son tour passe par un façonneur d’application similaire au modèle de sortie sur l’interface de recyclage. L’interface de recyclage peut prendre en charge un maximum de 256 canaux ou ports logiques virtuels. Tous les filières de recyclage fonctionnent avec la même priorité. Le trafic recyclé est ensuite transféré à l’aide de l’emplacement de calendrier en fonction de la pondération qui lui est attribuée. D’autres types d’interfaces, comme l’interface NIF, transfèrent le trafic en occupant d’autres emplacements sur le calendrier proportionnellement à sa bande passante.
La figure 1 illustre le mécanisme de recyclage et ses composantes.
de recyclage
-
Sh1 – Recycler le façonneur d’interface
-
SA1 – Mise en forme de l’application #1 sur le canal de recyclage 1
-
SAn – Façonneur de #n d’application sur le canal de recyclage n (max 256)
-
B1 – Poids de l’emplacement de calendrier pour le trafic de l’interface de recyclage. Cela reflète la valeur de bande passante du calendrier allouée à l’interface de recyclage.
-
B2 – Pondération de l’emplacement de calendrier pour le trafic provenant d’interfaces autres que l’interface de recyclage. Par exemple, l’interface NIF.
Le mécanisme de recyclage a deux modes de fonctionnement :
-
Mode de bande passante recyclée par défaut
-
Mode de bande passante de recyclage configurable
Mode de bande passante recyclée par défaut
Comme son nom l’indique, le mode de bande passante recyclée par défaut est activé par défaut et la configuration utilisateur n’est pas nécessaire. Une partie définie de la bande passante totale du calendrier est allouée à l’interface de recyclage. Cette bande passante recyclée est garantie et donc stable en période de congestion du trafic. Les applications de recyclage partagent cette bande passante dans la mesure du possible, ce qui signifie qu’il n’y a pas de bande passante garantie par application.
Les avantages de la bande passante recyclée par défaut sont les suivants :
-
Utilisation efficace de la bande passante de recyclage. Dans le cas où aucune application de recyclage n’est en cours d’exécution, la bande passante inutilisée peut être partagée entre les applications en cours d’exécution à partir d’autres interfaces.
-
Utilisation efficace de la bande passante des puces. Si les autres interfaces autres que l’interface de recyclage ne transportent pas de trafic, la bande passante inutilisée peut être utilisée par les applications de recyclage.
Mode de bande passante de recyclage configurable
En configurant l’interface de recyclage en fonction des profils, la bande passante de l’application devient gérable. Vous pouvez garantir l’allocation de la bande passante de recyclage pour une application en la définissant dans un profil.
Avantages de la bande passante de recyclage configurable :
-
Allocation de bande passante garantie pour une application de recyclage définie.
-
Flexibilité pour modifier l’allocation de la bande passante, ce qui vous aide à hiérarchiser la bande passante des applications.
Exemple : Configuration de la bande passante recyclée
RÉSUMÉ Cet exemple montre comment gérer la bande passante de recyclage par application.
Aperçu
Les applications 1, 2, 3 et 4 sont des applications de recyclage qui utilisent l’interface de recyclage. Le tableau 1 présente nos besoins en bande passante. Dans ce cas, nous voulons une allocation garantie de 10 % de la bande passante de l’interface recyclée pour l’application 1 et de 20 % pour l’application 2. Les applications 3 et 4 ne sont pas prioritaires et aucune garantie n’est nécessaire.
| Recycler l’application | Valeur de la bande passante de recyclage requise en pourcentage |
|---|---|
| Champ d’application 1 | 10% |
| Champ d’application 2 | 20% |
| Champ d’application 3 | indéfini |
| Champ d’application 4 | indéfini |
Configurer la bande passante de l’interface de recyclage
set system packet-forwarding-options recycle-bandwidth profile profile1set system packet-forwarding-options recycle-bandwidth-profile profile1 application1 10 application2 20
Vérification
| Tâche de vérification | des commandes |
|---|---|
show system packet-forwarding-options recycle-bandwidth-profile |
À partir du mode opérationnel, exécutez la |
Vérification de la bande passante de recyclage par application
But
Vérification de l’allocation de bande passante de recyclage par application.
Action
user@router> show system packet-forwarding-options recycle-bandwidth-profile Recycle Interface details: Total Bandwidth : 300 Gbps/Core PFE : 0 Application-Name | Core | Bandwidth(Kbps) | Port | VoQ | Profile ----------------------------------------------------------------------------- application1 0 30000000 234 1336 profile1 application2 0 60000000 242 1400 profile1 application3 0 105000000 243 1408 profile1 application4 0 105000000 245 1424 profile1 PFE : 1 Application-Name | Core | Bandwidth(Kbps) | Port | VoQ | Profile ----------------------------------------------------------------------------- application1 0 30000000 234 2880 profile1 application2 0 60000000 242 2944 profile1 application3 0 105000000 243 2952 profile1 application4 0 105000000 245 2968 profile1
Signification
La sortie affiche l’allocation de bande passante de recyclage par application, comme configuré dans la section précédente.
| Application | Pourcentage configuré | Résultat |
|---|---|---|
| Application1 | 10 | 300 Gbit/s x 10 % = 30 Gbit/s |
| Application2 | 20 | 300 Gbit/s x 20 % = 60 Gbit/s |
| Application3 | non configuré | Bande passante inutilisée/nombre d’applications de recyclage non configurées. (300 x 70 %) / 2 = 105 Gbit/s |
| Application4 | non configuré | (300 x 70 %) / 2 = 105 Gbit/s |