Gestion améliorée des abonnés Interfaces logiques d’abonnés ou ensembles d’interfaces sur des 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 jeu d’interfaces pour désigner un réseau domestique, il peut être nécessaire de configurer le réseau d’origine et le nœud d’accès (tel qu’un multiplexeur d’accès de ligne d’abonné numérique, ou DSLAM) dans une hiérarchie de planificateur. Cette méthode de planificateur hiérarchique est nécessaire dans les VLAN ACI (agent circuit identifier), car une interface domestique ou ACI est toujours définie dans de telles topologies. Vous pouvez maintenant activer une interface logique de gestion des abonnés améliorée, telle qu’une interface logique 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 périphérique virtuel qui est empilé au-dessus du point d’ancrage logique du tunnel. 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 de la [edit interfaces “$junos-interface-ifd-name” hierarchical-scheduler] ou de la [edit interfaces lt-device hierarchical-scheduler] hiérarchie. 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 planificateur hiérarchique 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 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 se trouver sur la couche 2 et l’interface logique PPPoE peut être sur la couche 3. Vous pouvez également configurer les interfaces PPP ou IP demux de cette manière pour la couche 3. De même, vous pouvez configurer des interfaces logiques de couche 2 qui servent d’interfaces sous-jacentes pour les ensembles d’interfaces logiques, tels que les ensembles d’interfaces PPPoE ACI ou les ensembles d’interfaces IP démux, où toutes les interfaces logiques membres de l’ensemble d’interfaces contiennent la même interface logique sous-jacente à la couche 2. Vous pouvez configurer les interfaces logiques de la couche 2 dans un profil dynamique ou dans une configuration CoS statique.

Le profil dynamique CoS la configuration des interfaces logiques sous-jacentes sont pris en charge, car deux strophes d’interface avec des TCP dans un profil dynamique sont considérées comme valides. Pour les interfaces logiques sous-jacentes dynamiques, vous pouvez les 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, elle doit être spécifiée 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 une CoS statique, car les CoS statiques et les CoS dynamiques ne sont pas pris en charge sur la même interface logique.

Le reparenting 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 au-dessus de l’interface logique sous-jacente et en ajoutant le nœud de planification. Ce mouvement peut se produire lorsque le CoS de l’interface logique sous-jacente ou de l’ensemble d’interfaces sous-jacent est configuré plus tard que l’interface logique client (IP demux ou PPPoE).

Le reparentage n’est pas pris en charge pour les interfaces logiques de gestion des abonnés améliorées dans un planificateur hiérarchique CoS qui inclut des interfaces logiques de gestion des abonnés améliorées sur une colonne purement dynamique et des interfaces logiques de gestion des abonnés améliorées sur une colonne partiellement statique. Ce qui suit décrit des environnements réseau réels dans lesquels une reparentalité peut être nécessaire et 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 d’interface dans un environnement où la gestion améliorée des abonnés est activée. Une erreur de commit se produit lorsque vous tentez cette modification de la configuration CoS. Cet échec de validation n’est pas un problème dans les réseaux clients, car les réseaux sont 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 la configuration sous-jacente pour être cohérent : soit tous les profils contiennent une configuration CoS sous-jacente, soit aucun d’entre eux ne contient CoS configuration. 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 que CoS est appliqué ultérieurement à l’aide d’un profil de service : dans un tel scénario, il est nécessaire que vous spécifiiez toujours 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 de démultiplexage statiques ou dynamiques, PPPoE ou PPP sur des interfaces logiques Ethernet agrégées ne sont pas prises en charge.

Prenons un scénario dans lequel trois files d’attente d’abonné, à savoir la file d’attente d’abonné PPPoE 1, la file d’attente d’abonné PPPoE 2 et les files d’attente d’abonné DHCP, sont établies. Une interface Gigabit Ethernet, ge-1/0/0 est de niveau 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, abonné-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, abonné-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 appartenant à ppp-demux-iflset.

Prenons un autre scénario dans lequel trois files d’attente d’abonné, les files d’attente d’abonné PPPoE, les files d’attente d’abonné demux et les files d’attente d’abonné DHCP, sont établies. Une interface Gigabit Ethernet, ge-1/0/0 est de niveau 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. À 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 ge-1/0/0.Y ou demux0. Yge- 1/0/0.Y ou demux0.Y. Les profils de contrôle de 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. YY.