Understanding Hierarchical Schedulers

Les calendriers hiérarchiques comprennent des nodes et des files d’attente. Les files d’attente terminent la CLI hiérarchique. Les nodes peuvent être soit des root nodes, des nodes de feuille, soit des nodes internes (non-leaf). Les nodes internes sont des nodes dont les autres sont des « enfants » dans la hiérarchie. Par exemple, si une instruction est configurée avec une interface logique (comme l’unité 0) et une file d’attente, il s’agit d’un nœud interne au niveau interface-set interface-set 2 de la hiérarchie. Toutefois, s’il n’y a aucun profil de contrôle du trafic configuré sur les interfaces logiques, l’ensemble d’interfaces se trouve au niveau 3 de la hiérarchie.

Le tableau 1 montre comment la configuration d’un ensemble d’interfaces ou d’une interface logique affecte la terminologie des nodes de planning hiérarchique.

de planning hiérarchique

Tableau 1: Nodes

Nœud racine (niveau 1)	Nœud interne (niveau 2)	Nœud de feuille (niveau 3)	File d’attente (niveau 4)
Interface physique	Ensemble d’interfaces	Interfaces logiques	Une ou plusieurs files d’attente
Interface physique	–	Ensemble d’interfaces	Une ou plusieurs files d’attente
Interface physique	–	Interfaces logiques	Une ou plusieurs files d’attente

Lorsqu’elle est utilisée, le niveau de la hiérarchie se situe entre le niveau d’interface physique (niveau 1) et l’interface logique (niveau 3). Les files d’attente sont toujours de niveau 4 de la hiérarchie. Les scheduleurs tiennent les informations sur les files d’attente, le dernier niveau de la hiérarchie. Dans tous les cas, les propriétés du niveau 4 des scheduleurs hiérarchiques sont déterminées par la carte du planning.

Les scheduleurs hiérarchiques ajoutent CoS paramètres d’interface au niveau de jeu de la nouvelle interface de configuration. Ils utilisent des profils de contrôle du trafic pour définir des valeurs en fonction des paramètres tels que le taux de mise en forme (le taux d’information de pointe [SE]), le taux garanti (le taux d’informations sur les données engagées [CIR] sur ces interfaces) et les cartes du planning (les files d’attente et les ressources affectées au trafic).

Les paramètres CoS suivants dans les profils de contrôle du trafic à différents niveaux:

• Profil de contrôle du trafic au niveau des ports tcp-port-level1 ():

  • Un taux de mise en forme (RÉUSSITE) de 100 Mbits/s

  • Un temps de tampon de 100 Mbits/s

• Profil de contrôle du trafic au niveau de l’interface ( tcp-interface-level2 ):

  • Un taux de mise en forme (MBAL) de 60 Mbits/s

  • Un taux de garantie de 40 Mbits/s

• Profil de contrôle du trafic au niveau de l’interface logique tcp-unit-level3 ():

  • Un taux de mise en forme (RÉUSSITE) de 50 Mbits/s

  • Un taux de garantie de 30 Mbits/s

  • Une carte de planning appelée smap1 pour conserver diverses propriétés de file d’attente (niveau 4)

  • Un temps de tampon de 40 Mbits/s

Ici, les profils de contrôle du trafic ressemblent à ceci:

Une fois configurés, les profils de contrôle du trafic doivent être appliqués aux lieux appropriés dans la hiérarchie CoS interfaces.

Les ensembles d’interfaces peuvent être définis comme une liste d’interfaces logiques, par exemple, l’unité 100, l’unité 200, etc. Les fournisseurs de services peuvent utiliser ces instructions pour grouper des interfaces afin d’appliquer des paramètres de planification, tels que le taux de garantie et le taux de mise en forme, au trafic des groupes. Les jeux d’interfaces ne sont actuellement utilisés que par CoS, mais sont appliqués au niveau hiérarchique afin de pouvoir être disponibles [edit interfaces] pour d’autres services.

Tous les trafics en aval doivent être regroupés dans une interface avec l’énoncé au niveau de la hiérarchie interface-set de [edit class-of-service interfaces].

Remarque:

Les plages ne sont pas pris en charge. vous devez énumérer chaque interface logique séparément.

Même si l’ensemble d’interfaces est appliqué au niveau hiérarchique [edit interfaces], les paramètres CoS de l’ensemble d’interfaces sont définis au niveau hiérarchique des interfaces de [edit class of service], généralement avec output-traffic-control-profile profile-name l’énoncé.

Vous ne pouvez pas spécifier un ensemble d’interfaces qui mélange l’interface logique, le S-VLAN ou les balises extérieures VLAN de interface-set l’énoncé. Une interface logique ne peut appartenir qu’à un seul ensemble d’interfaces. Si vous tentez d’ajouter la même interface logique à différents ensembles d’interfaces, la validation échoue.

Cet exemple génère une erreur de validation:

Les membres d’un ensemble d’interfaces ne peuvent pas s’étendre à plusieurs interfaces physiques. Une seule interface physique est autorisée à apparaître dans un ensemble d’interfaces.

Cette configuration n’est pas prise en charge:

Vous pouvez configurer de nombreuses interfaces logiques sous une interface. Toutefois, seul un sous-ensemble d’entre eux peut être associé à un profil de contrôle du trafic. Par exemple, vous pouvez configurer trois interfaces logiques (unités) sur un même VLAN de service, mais appliquer un profil de contrôle du trafic spécifiant les meilleures efforts et les files d’attente vocales à une seule unité d’interface logique. Le trafic en provenance des deux interfaces logiques restantes est considéré comme restant.

La cartographie du planning, configurée à chaque interface (niveau 3), jeu d’interfaces (niveau 2) ou ports physiques (niveau 1), définit le comportement de la planification des paquets à différents niveaux. Vous pouvez grouper les interfaces logiques dans un ensemble d’interfaces et les configurer à l’aide de cartes de planning. Tous les paquets de sortie arrivant aux interfaces physiques ou logiques seront traités par le programmeur spécifique de l’interface. Si la carte du planning n’est pas configurée au niveau de l’interface, le paquet sera géré par le programmeur configuré au niveau de l’interface définie ou au niveau du port.