Gestion améliorée des abonnés Interfaces logiques d’abonnés ou ensembles d’interfaces sur les interfaces logiques sous-jacentes pour une hiérarchie de planificateur CoS

Dans certains déploiements de serveur d’accès distant à large bande (B-RAS), lorsque vous utilisez un ensemble d’interfaces pour désigner un réseau domestique, il peut être nécessaire de configurer le réseau domestique et le nud d’accès (tel qu’un multiplexeur d’accès de ligne d’abonné numérique, ou DSLAM) dans une hiérarchie de planificateurs. Cette méthode de planificateur hiérarchique est nécessaire dans les VLAN ACI (Agent Circuit Identifier), car un home ou un ACI est toujours une interface définie dans de telles topologies. Vous pouvez désormais activer une interface logique de gestion des abonnés améliorée, telle qu’une interface logique de pseudowire MPLS, pour qu’elle fonctionne comme un nœud de couche 2 dans un planificateur hiérarchique CoS. Une interface logique d’abonné est considérée comme fonctionnant au niveau de la couche 2 uniquement si vous configurez une planification hiérarchique à trois niveaux sur le point d’ancrage du tunnel logique sur l’interface physique (l’IFD). Un pseudowire MPLS est un équipement virtuel qui est empilé au-dessus du point d’ancrage du tunnel logique. La hiérarchie implicite traite correctement la pile d’interfaces dans une telle configuration. Pour configurer la planification hiérarchique à trois niveaux, incluez l’option implicit- hierarchy au niveau ou [edit interfaces “$junos-interface-ifd-name” hierarchical-scheduler] hiérarchique [edit interfaces lt-device hierarchical-scheduler] . Si l’option n’est implicit-hierarchy pas définie sur le point d’ancrage du tunnel logique, les interfaces logiques se comportent normalement avec le mode hierarchical-scheduler configuré avec ou sans l’option hierarchical-scheduler maximum-hierarchy-levels sous l’instruction [edit interfaces interface-name hierarchical-scheduler] .

Dans ce cas, lorsque vous appliquez un profil de contrôle du trafic aux interfaces logiques de pseudowire et de service, elles résident toutes deux dans des nœuds de planificateur de niveau 3 et ne forment pas de hiérarchie de planification, ce qui n’est peut-être pas le comportement souhaitable. Les interfaces logiques d’abonné de couche 3 qui sont empilées sur les interfaces logiques sous-jacentes de couche 2 sont prises en charge si l’interface logique de couche 2 est une interface sous-jacente de l’interface de couche 3.

Par exemple, si une interface logique PPPoE contient une interface logique sous-jacente, ge-1/0/0.100, l’interface ge-1/0/0.100 peut être au niveau de la couche 2 et l’interface logique PPPoE peut être à la couche 3. Vous pouvez également configurer les interfaces PPP ou IP demux de cette manière au niveau de la couche 3. De même, vous pouvez configurer des interfaces logiques au niveau de la couche 2 qui servent d’interfaces sous-jacentes pour les jeux d’interfaces logiques, tels que les jeux d’interfaces PPPoE ACI ou les ensembles d’interfaces IP demux, où toutes les interfaces logiques membres du jeu d’interfaces contiennent la même interface logique sous-jacente au niveau de la couche 2. Vous pouvez configurer les interfaces logiques au niveau de la couche 2 dans un profil dynamique ou dans une configuration CoS statique.

La configuration CoS de profil dynamique pour les interfaces logiques sous-jacentes est prise en charge, car deux strophes d’interface avec TCP dans un profil dynamique sont considérées comme valides. Pour les interfaces logiques sous-jacentes dynamiques, vous pouvez configurer dans un profil différent du profil d’interface logique client ou dans le même profil que le profil client. Si l’interface logique sous-jacente est statique et que CoS est configuré dynamiquement dans un profil dynamique, il doit être spécifié dans le même profil que l’interface logique cliente. Toutefois, les CoS des interfaces logiques sous-jacentes doivent être configurées dans un profil dynamique ou dans un CoS statique, car les CoS statiques et les CoS dynamiques ne sont pas pris en charge sur la même interface logique.

Le reparentage est une technique qui désigne le déplacement du planificateur hiérarchique CoS d’un nœud à un autre, par exemple en déplaçant toutes les interfaces logiques empilées sur une interface logique sous-jacente au-dessus de l’interface physique de base pour qu’elles soient directement sur l’interface logique sous-jacente et en ajoutant le nœud de planification. Ce mouvement peut se produire lorsque la CoS de l’interface logique sous-jacente ou de l’ensemble d’interfaces sous-jacentes est configurée ultérieurement à l’interface logique du client (démultiplexage IP ou PPPoE).

Le reparentage n’est pas pris en charge pour les interfaces logiques de gestion améliorée des abonnés dans un planificateur hiérarchique CoS qui inclut des interfaces logiques de gestion améliorée des abonnés sur une colonne purement dynamique et des interfaces logiques de gestion améliorée des abonnés sur une colonne partiellement statique. Ce qui suit décrit des environnements réseau réels dans lesquels un reparentage peut être nécessaire, ainsi que les approches alternatives qui peuvent être adoptées dans de telles conditions :

Ajout ou suppression d’une configuration CoS statique à partir d’un ensemble IFL ou d’un IFL sous-jacent avec une interface logique de gestion des abonnés améliorée : dans un tel scénario, l’ajout ou la suppression de CoS statiques n’est pas pris en charge une fois qu’un abonné s’est connecté à la colonne de l’interface dans un environnement où la gestion améliorée des abonnés est activée. Une erreur de validation se produit lorsque vous tentez de modifier la configuration CoS. Cet échec de validation ne pose pas de problème dans les réseaux clients, car les réseaux ont été préalablement conçus, les nœuds de couche 2 spécifiés et le CoS est configuré bien avant que les clients ne soient connectés.

Deux profils dynamiques pour les interfaces logiques client sur un seul CVLAN (ou un VLAN ACI) avec une configuration CoS sous-jacente dans un profil client et pas dans l’autre profil : dans un tel scénario, vous pouvez gérer des profils dynamiques avec une configuration sous-jacente pour être cohérent : soit tous les profils contiennent une configuration CoS sous-jacente, soit aucun d’entre eux ne contient de configuration CoS. Un accusé de réception négatif est envoyé lorsqu’un abonné tente de se connecter si une configuration CoS différente est observée dans les profils client.

Un profil client pour un nœud interne (par exemple, un ensemble C-VLAN ou IFL) qui ne contient pas de CoS initialement et CoS est appliqué ultérieurement à l’aide d’un profil de service : dans un tel scénario, il est nécessaire de toujours spécifier la planification CoS dans le profil client si vous souhaitez réappliquer certains paramètres à l’aide d’un profil de service. Si cette méthode de configuration n’est pas adoptée, un accusé de réception négatif est envoyé lorsqu’un abonné tente de se connecter. Les interfaces démultiplexantes, PPPoE ou PPP statiques ou dynamiques sur des interfaces logiques Ethernet agrégées ne sont pas prises en charge.

Imaginons un scénario dans lequel trois files d’attente d’abonnés, à savoir la file d’attente d’abonnés PPPoE 1, la file d’attente d’abonnés PPPoE 2 et les files d’attente d’abonnés DHCP, sont établies. Une interface Gigabit Ethernet, ge-1/0/0 est au niveau de la couche 1. Deux nœuds d’interface de couche 2 sont empilés sur l’interface de base de couche 1. Les interfaces de couche 2 sont ge-1/0/0.x ou demux0.x et ge-1/0/0.y ou demux0.y. Les ensembles d’interfaces logiques, pppoe-iflset (pour le nœud d’accès) et demux-iflset (pour le réseau domestique), sont configurés au niveau de la couche 3 pour gérer respectivement deux ensembles de files d’attente d’abonnés PPPoE sur l’interface de couche 2, ge-1/0/0.x ou demux0.x. Un profil de contrôle du trafic, subscriber-tcp, est attaché à ces deux ensembles IFL de couche 3. ppp-demux-iflset (demux et pppoe) est l’interface définie sur l’interface de couche 2 de ge-1/0/0.y ou demux0.y. Un profil de contrôle du trafic, subscriber-tcp, est attaché à cet ensemble d’interfaces. ge-1/0/0.X ou demux0. X est l’UIFL de toutes les interfaces logiques qui appartiennent à pppoe-iflset et demux-iflset. Dans cette topologie, ge-1/0/0.Y ou demux0. Y est l’UIFL de toutes les interfaces logiques qui appartiennent à ppp-demux-iflset.

Prenons un autre scénario dans lequel trois files d’attente susbcriber, des files d’attente d’abonnés PPPoE, des files d’attente d’abonnés demux et des files d’attente d’abonnés DHCP, sont établies. Une interface Gigabit Ethernet, ge-1/0/0 est au niveau de la couche 1. Deux nœuds d’interface de couche 2 sont empilés sur l’interface de base de couche 1. Les interfaces de couche 2 sont ge-1/0/0.X ou demux0. X, et ge-1/0/0.Y ou demux0.Y. Au niveau de la couche 3, pp0. XX est configuré sur l’interface de couche 2 sous-jacente de ge-1/0/0.X ou demux0. X, demux0. ZZ est configuré sur l’interface de couche 2 sous-jacente de ge-1/0/0.X ou demux0. X, et pp0. YY est configuré sur l’interface de couche 2 sous-jacente de ge-1/0/0.Y ou demux0. Yge- 1/0/0.Y ou demux0.Y. Les profils de contrôle du trafic, subcriber-tcp, sont appliqués à pp0.xx pour les files d’attente d’abonnés PPPoE, à demux0.yy pour les files d’attente d’abonnés demux et à pp0.yy pour les files d’attente d’abonnés DHCP. Dans cette topologie, ge-1/0/0.X ou demux0. X est l’IFL sous-jacent pour pp0. XX et demux0. ZZ. ge-1/0/0.Y ou demux0. Y est l’IFL sous-jacent pour pp0. AA.