Vue d’ensemble du réseau d’accès haut débit pour les abonnés
Présentation du réseau d’accès abonné
Un environnement d’accès abonné peut inclure divers composants, notamment des technologies d’accès abonné et des protocoles d’authentification.
Les technologies d’accès des abonnés comprennent :
Serveur DHCP (Dynamic Host Configuration Protocol)
Serveur DHCP local
Serveur DHCP externe
Protocole PPP (Point-to-Point)
Les protocoles d’authentification des abonnés incluent le serveur RADIUS.
La figure 1 montre un exemple de réseau d’accès de base pour les abonnés.
de réseau d’accès abonné
Cette fonctionnalité nécessite une licence. Pour en savoir plus sur les licences d’accès aux abonnés, consultez Vue d’ensemble des licences d’accès aux abonnés. Reportez-vous au Guide des licences Juniper pour obtenir des informations générales sur la gestion des licences. Reportez-vous aux fiches techniques des routeurs MX Series pour plus de détails, ou contactez votre équipe de compte Juniper ou votre partenaire Juniper.
Présentation du nœud d’accès multiservice
Un nœud d’accès multiservice est un terme plus large qui désigne un groupe de dispositifs d’agrégation couramment utilisés. Ces dispositifs comprennent les multiplexeurs d’accès aux lignes d’abonnés numériques (DSLAM) utilisés dans les réseaux xDSL, la terminaison de ligne optique (OLT) pour les réseaux PON/FTTx et les commutateurs Ethernet pour les connexions Ethernet actives. Les réseaux MSAN modernes prennent souvent en charge toutes ces connexions, tout en fournissant des connexions pour des circuits supplémentaires tels que l’ancien service téléphonique ordinaire (appelé POTS) ou le signal numérique 1 (DS1 ou T1).
La fonction déterminante d’un nœud d’accès multiservice est d’agréger le trafic de plusieurs abonnés. Au niveau physique, le MSAN convertit également le trafic de la technologie du dernier kilomètre (par exemple, l’ADSL) en Ethernet pour le livrer aux abonnés.
Vous pouvez classer les MSAN en trois types en fonction de la façon dont ils transfèrent le trafic sur le réseau :
Layer–2 MSAN—Ce type de MSAN est essentiellement un commutateur de couche 2 (mais généralement pas un commutateur entièrement fonctionnel) avec quelques améliorations pertinentes. Ces réseaux MSAN utilisent une commutation Ethernet (ou ATM) pour transférer le trafic. Le MSAN transfère tout le trafic abonné en amont vers un routeur de périphérie qui sert de point de contrôle centralisé et empêche la communication directe abonné à abonné. L’agrégation de liens Ethernet (LAG) assure la résilience de ce type de réseau.
Les DSLAM de couche 2 ne peuvent pas interpréter IGMP, ils ne peuvent donc pas répliquer sélectivement les chaînes IPTV.
Layer–3 aware MSAN—Ce réseau MSAN compatible IP peut interpréter les requêtes IGMP et y répondre en répliquant localement un flux multicast et en le transférant à tout abonné qui en fait la demande. La sensibilisation à la couche 3 est importante lorsque le trafic IPTV doit effectuer des changements de canal (parfois appelés zaps de canal). Les réseaux MSAN statiques compatibles IP reçoivent toujours toutes les chaînes de télévision multicast. Ils n’ont pas la possibilité de demander que des canaux spécifiques soient transmis au DSLAM. Cependant, les DSLAM dynamiques compatibles IP peuvent informer le réseau de commencer (ou d’interrompre) l’envoi de canaux individuels vers le DSLAM. La configuration du proxy IGMP ou de l’espionnage IGMP sur le DSLAM accomplit cette fonction.
Layer–3 MSAN—Ces réseaux MSAN utilisent la fonctionnalité de routage IP plutôt que des technologies de couche 2 pour transférer le trafic. L’avantage de cette méthode de transfert est la possibilité de prendre en charge plusieurs liaisons en amont vers différents routeurs en amont et d’améliorer la résilience du réseau. Toutefois, pour atteindre ce niveau de résilience, vous devez affecter un sous-réseau IP distinct à chaque réseau MSAN, ce qui ajoute un niveau de complexité qui peut être plus difficile à maintenir ou à gérer.
Pour choisir un type de MSAN, reportez-vous à la Figure 2 :
MSAN
Options d’agrégation MSAN Ethernet
Chaque MSAN peut se connecter directement à un routeur de périphérie (routeur de services haut débit ou routeur de services vidéo), ou un périphérique intermédiaire (par exemple, un commutateur Ethernet) peut agréger le trafic MSAN avant d’être envoyé au routeur de services. Le tableau 1 énumère les méthodes d’agrégation MSAN possibles et les conditions dans lesquelles elles sont utilisées.
Méthode |
En cas d’utilisation |
|---|---|
Connexion directe |
Chaque MSAN se connecte directement au routeur de services haut débit et au routeur de services vidéo en option. |
Connexion au commutateur d’agrégation Ethernet |
Chaque MSAN se connecte directement à un commutateur Ethernet intermédiaire. Le commutateur, à son tour, se connecte au routeur de services haut débit ou au routeur de services vidéo en option. |
Connexion Ethernet d’agrégation en anneau |
Chaque MSAN se connecte à une topologie en anneau de MSAN. Le MSAN en tête de réseau (l’appareil le plus proche du routeur de périphérie en amont) se connecte au routeur de services haut débit. |
Vous pouvez utiliser différentes méthodes d’agrégation dans différentes parties du réseau. Vous pouvez également créer plusieurs couches d’agrégation du trafic au sein du réseau. Par exemple, un MSAN peut se connecter à un terminal de bureau central (COT), qui à son tour se connecte à un commutateur d’agrégation Ethernet, ou vous pouvez créer plusieurs niveaux de commutateurs d’agrégation Ethernet avant de vous connecter au routeur de périphérie.
Connexion directe
Dans la méthode de connexion directe, chaque MSAN dispose d’une connexion point à point au routeur des services haut débit. S’il existe un bureau central intermédiaire, le trafic de plusieurs réseaux MSAN peut être combiné sur une seule connexion à l’aide du multiplexage par répartition en onde (WDM). Vous pouvez également connecter le MSAN à un routeur de services vidéo. Toutefois, cette méthode de connexion nécessite l’utilisation d’un réseau MSAN de couche 3 capable de déterminer le lien à utiliser lors du transfert de trafic.
Lorsque vous utilisez la méthode de connexion directe, gardez les points suivants à l’esprit :
Nous recommandons cette approche lorsque cela est possible pour simplifier la gestion du réseau.
Étant donné que plusieurs MSAN sont utilisés pour se connecter au routeur de services et que les MSAN de couche 3 nécessitent généralement un coût d’équipement plus élevé, cette méthode est rarement utilisée dans un modèle de gestion des abonnés multi-périphérie.
La connexion directe est généralement utilisée lorsque la plupart des liaisons MSAN sont utilisées à moins de 33 % et qu’il est peu utile de combiner le trafic de plusieurs MSAN.
Connexion au commutateur d’agrégation Ethernet
Un commutateur d’agrégation Ethernet regroupe le trafic de plusieurs réseaux MSAN en aval en une seule connexion au routeur de services (routeur de services haut débit ou routeur de services vidéo en option).
Lorsque vous utilisez la méthode de connexion du commutateur d’agrégation Ethernet, gardez les points suivants à l’esprit :
L’agrégation Ethernet est généralement utilisée lorsque la plupart des liaisons MSAN sont utilisées à plus de 33 % ou pour agréger le trafic des réseaux MSAN à faible vitesse (par exemple, 1 Gbit/s) vers une connexion plus rapide au routeur de services (par exemple, 10 Gbit/s).
Vous pouvez utiliser un routeur MX Series comme commutateur d’agrégation Ethernet. Pour plus d’informations sur la configuration du routeur MX Series dans les scénarios de couche 2, reportez-vous au Guide de l’utilisateur du réseau Ethernet pour les routeurs MX Series.
Connexion d’agrégation en anneau
Dans une topologie en anneau, le MSAN distant qui se connecte aux abonnés est appelé terminal distant (RT). Cet appareil peut être situé dans l’installation extérieure (OSP) ou dans un bureau central distant (CO). Le trafic traverse l’anneau jusqu’à ce qu’il atteigne le terminal du bureau central (COT) en tête de l’anneau. Le COT se connecte ensuite directement au routeur de services (routeur de services haut débit ou routeur de services vidéo).
Le RT et le COT doivent prendre en charge le même protocole de résilience en anneau.
Vous pouvez utiliser un routeur MX Series dans une topologie d’agrégation en anneau Ethernet. Pour plus d’informations sur la configuration du routeur MX Series dans les scénarios de couche 2, reportez-vous au Guide de l’utilisateur du réseau Ethernet pour les routeurs MX Series.
Présentation de la détection automatique LDP Pseudowire
Un pseudowire est un lien virtuel utilisé pour transporter un service de couche 2 sur un réseau de périphérie ou d’accès MPLS. Dans un réseau de périphérie haut débit ou de périphérie d’entreprise typique, une extrémité d’un pseudofil se termine en tant que circuit de couche 2 sur un nœud d’accès, et l’autre extrémité en tant que circuit de couche 2 sur un nœud de service qui sert de nœud d’agrégation ou de réseau central MPLS. Traditionnellement, les deux points de terminaison sont provisionnés manuellement via la configuration. La détection automatique pseudowire LDP introduit un nouveau modèle de provisionnement qui permet de provisionner et de déprovisionner automatiquement les points de terminaison pseudowire sur les nœuds de service en fonction des messages de signalisation LDP. Ce modèle peut faciliter le provisionnement de pseudofils à grande échelle. Un nœud d’accès utilise LDP pour signaler à la fois l’identité pseudowire et les attributs à un nœud de service. L’identité est authentifiée par un serveur RADIUS, puis utilisée avec les attributs signalés par LDP et les attributs transmis par le serveur RADIUS pour créer la configuration de point de terminaison pseudowire, y compris le circuit de couche 2.
- Pseudowire Entering Termination Background (en anglais)
- Approche de détection automatique de pseudofils
- Exemple de configuration
Pseudowire Entering Termination Background (en anglais)
Dans un accès haut débit MPLS transparent ou un réseau de périphérie d’entreprise, les pseudofils Ethernet sont couramment utilisés comme interfaces virtuelles pour connecter des nœuds d’accès aux nœuds de service. Chaque pseudowire transporte le trafic bidirectionnel d’un ou de plusieurs abonnés haut débit ou clients de périphérie d’entreprise entre un nœud d’accès et une paire de nœuds de service. La mise en place du pseudowire est généralement initiée par le nœud d’accès, sur la base d’une configuration statique ou de la détection dynamique d’un nouvel abonné haut débit ou d’un client de périphérie d’entreprise arrivant sur un port orienté client sur le nœud d’accès.
Idéalement, le nœud d’accès doit créer un pseudowire par port client, où tous les abonnés ou clients hébergés par le port sont mappés au pseudowire. L’alternative est où il y a un pseudowire par port client (S-VLAN), et tous les abonnés ou clients partageant un S-VLAN commun sur le port sont mappés au pseudowire. Dans les deux cas, le pseudofil est signalé en mode brut.
Le S-VLAN, s’il n’est pas utilisé pour délimiter le service sur le nœud de service ou combiné avec le C-VLAN pour distinguer les abonnés ou les clients, sera supprimé avant que le trafic ne soit encapsulé dans une charge utile pseudowire et transporté vers le nœud de service. Les abonnés individuels ou les clients peuvent être distingués par C-VLAN, ou un en-tête de couche 2 tel que DHCP et PPP, qui sera transporté en charge utile pseudowire vers le nœud de service. Sur le nœud de service, le pseudowire est terminé. Les abonnés individuels ou les clients sont ensuite démultiplexés et modélisés en tant qu’interfaces abonnés haut débit, interfaces de périphérie professionnelle (PPPoE, par exemple), interfaces Ethernet ou interfaces IP. Des interfaces Ethernet et IP peuvent être connectées à des instances de service, telles que des instances VPLS et VPN de couche 3.
Dans Junos OS, la terminaison d’entrée pseudowire sur les nœuds de service est prise en charge par l’utilisation d’interfaces physiques et logiques de service pseudowire. Cette approche est considérée comme supérieure en termes d’évolutivité à l’ancienne approche basée sur l’interface de tunnel logique, en raison de sa capacité à multiplexer et démultiplexer les abonnés ou les clients sur un seul pseudofil. Pour chaque pseudowire, une interface physique de service pseudowire est créée sur un moteur de transfert de paquets sélectionné, appelé moteur de transfert de paquets d’ancrage. En plus de cette interface physique de service pseudowire, une interface logique ps.0 (interface logique de transport) est créée, et un circuit de couche 2 ou VPN de couche 2 est créé pour héberger l’interface logique ps.0 en tant qu’interface de connexion.
Le circuit de couche 2 ou VPN de couche 2 permet une signalisation pseudowire vers le nœud d’accès, et l’interface logique ps.0 joue le rôle d’interface orientée périphérie client pour le pseudowire. En outre, une ou plusieurs interfaces logiques ps.n (également appelées interfaces logiques de service, où n>0) peuvent être créées sur l’interface physique du service pseudowire pour modéliser les flux abonnés/clients individuels en tant qu’interfaces logiques. Ces interfaces peuvent ensuite être connectées aux services haut débit et de périphérie professionnelle souhaités ou à des instances VPN de couche 2 ou 3.
Notez que le but du moteur de transfert de paquets d’ancrage est de désigner le moteur de transfert de paquets pour traiter le trafic bidirectionnel du pseudofil, y compris l’encapsulation, la décapsulation, le mux ou le démultiplexage VLAN, la QoS, le contrôle, la mise en forme et bien d’autres.
Pour Junos OS version 16.2 et antérieure, la création et la suppression des interfaces physiques du service pseudofilaire, des interfaces logiques de service pseudowire, des circuits de couche 2 et des VPN de couche 2 pour la terminaison d’entrée pseudowire reposent sur une configuration statique. Cette option n’est pas considérée comme la meilleure du point de vue de l’évolutivité, de l’efficacité et de la flexibilité, en particulier dans un réseau où chaque nœud de service peut potentiellement héberger un grand nombre de pseudowires. L’objectif est d’aider les fournisseurs de services à sortir de la configuration statique pour provisionner et déprovisionner la terminaison d’entrée pseudowire sur les nœuds de service.
Approche de détection automatique de pseudofils
Dans l’approche de détection automatique pseudofilaire, un nœud de service utilise le message de mappage d’étiquettes LDP reçu d’un nœud d’accès comme déclencheur pour générer dynamiquement la configuration d’une interface physique de service pseudofilaire, d’une interface logique de service pseudowire et d’un circuit de couche 2. De même, il utilise le message de retrait d’étiquette LDP reçu du nœud d’accès et l’événement LDP session down comme déclencheurs pour supprimer la configuration générée. Dans la détection automatique pseudofilaire, on suppose que les nœuds d’accès sont les initiateurs de la signalisation pseudowire et que les nœuds de service sont les cibles. Dans un réseau où un service peut être hébergé par plusieurs nœuds de services pour la redondance ou l’équilibrage de charge, les nœuds d’accès bénéficient également d’un modèle de sélection et de connexion pour l’établissement des services. Le flux de commande de base de la détection automatique pseudowire est illustré à la Figure 3
automatique Pseudowire
La procédure de base du flux de commande de pseudowire à détection automatique est la suivante :
L’équipement CPE (Customer Premises Equipment) est mis en ligne et envoie une trame Ethernet avec C-VLAN à la terminaison de ligne optique (OLT). OLT ajoute un S-VLAN à la trame et envoie la trame au nœud d’accès. Le nœud d’accès vérifie auprès du serveur RADIUS d’autoriser les VLAN.
Le serveur RADIUS envoie une acceptation d’accès au nœud d’accès. Le nœud d’accès crée un circuit de couche 2 et signale un pseudofil au nœud de service par le biais d’un message de mappage d’étiquettes LDP.
Le nœud de service accepte le message de mappage d’étiquettes et envoie une demande d’accès avec des informations pseudowire au serveur RADIUS pour autorisation et sélection d’une interface physique de service pseudowire ou d’une interface logique.
Le serveur RADIUS envoie une acceptation d’accès au nœud de service avec une chaîne de service spécifiant l’interface physique ou logique du service pseudowire sélectionné. Le nœud de service crée une configuration de circuit de couche 2, les informations pseudowire et l’interface physique ou l’interface logique du service pseudowire. Le nœud de service signale le pseudowire vers le nœud d’accès via un message de mappage d’étiquettes LDP. Le pseudofil apparaît de manière bidirectionnelle.
Exemple de configuration
La configuration suivante marque explicitement le circuit de couche 2 comme généré par la détection automatique. L’interface physique du service pseudowire et la configuration de l’interface logique du service pseudowire sont facultatives selon qu’elles préexistent ou non.
Routeur 0
[edit]
protocols {
Layer 2 circuit {
neighbor 192.0.2.2 {
interface ps0.0 {
virtual-circuit-id 100;
control-word;
mtu 9100;
auto-sensed;
}
}
}
}
Vue d’ensemble de l’interface de service des services de couche 2 sur Pseudowire
L’interface logique du service pseudowire prend en charge l’interface logique de transport (psn.0) côté accès MPLS et les interfaces logiques de service (psn.1 à psn.n) du côté central MPLS du réseau de gestion des abonnés.
Le service pseudowire sur les interfaces logiques de service psn.1 à psn.n est configuré en tant qu’interfaces de couche 2 dans le domaine de pont ou dans une instance de service de réseau local privé virtuel (VPLS). Il existe un circuit de couche 2 ou le VPN de couche 2 sur un accès MLPS entre un périphérique d’agrégation Ethernet et un périphérique de périphérie de service, le service pseudowire sur l’interface logique de transport psn.0 étant l’interface de terminaison du circuit de couche 2 ou le VPN de couche 2 sur le périphérique de périphérie de service.
Junos OS prend en charge le service pseudowire sur les interfaces logiques de service psn.1 à psn.n dans le domaine de pont ou l’instance VPLS, qui reçoit le trafic sortant du service pseudowire sur l’interface logique de transport de l’équipement périphérique de service. Il active également les fonctionnalités d’entrée de couche 2 telles que l’apprentissage MAC, les manipulations VLAN et la recherche MAC de destination sur le service pseudowire sur les interfaces logiques de service.
Lorsque le trafic est dans le sens inverse, le MAC de destination entre dans le domaine de couche 2 au niveau de l’équipement périphérique de service, qui est appris en tant que MAC source sur le service pseudowire sur les interfaces logiques de service. À partir de Junos OS version 17.1R1, les interfaces de tunnel logique pseudowire prennent en charge Ethernet VPLS, Ethernet bridge, VLAN VPLS et VLAN bridge encapsulation suivant sauts pour quitter le trafic de couche 2. À partir de Junos OS version 18.4R1, la prise en charge des services de couche 2 avec les interfaces logiques de service pseudowire est étendue aux interfaces de service pseudowire ancrées sur des interfaces de tunnel logique redondantes. Ces services de couche 2 sont pris en charge uniquement sur le service pseudowire sur les interfaces logiques de service (psn.1 à psn.n) et non sur l’interface logique de transport (psn.0). Les fonctionnalités de sortie de couche 2 telles que les manipulations VLAN et autres sont activées sur les interfaces de service pseudowire. Le trafic envoyé par les interfaces entre dans le service pseudowire sur les interfaces logiques de transport, qui est l’interface de circuit de couche 2 entre l’agrégation Ethernet et les périphériques de périphérie de service sur le domaine d’accès MPLS.
Pour Junos OS version 16.2 et antérieure, les encapsulations ou les fonctionnalités de couche 2 ne pouvaient pas être configurées sur un service pseudowire sur des interfaces logiques de service.
- Trafic du LAN client vers MPLS
- Trafic de la périphérie de service vers le LAN client
- Pseudowire Service Interfaces
- Exemple de configuration
Trafic du LAN client vers MPLS
Les instances VPLS-x et VPLS-y sont configurées côté cœur MPLS de l’équipement de périphérie de service (PE A). Un circuit de couche 2 ou VPN de couche 2 est configuré entre le périphérique d’agrégation Ethernet (EAD 1) et le périphérique de périphérie de service. ps0.0 (interface logique de transport) est l’interface locale dans le circuit de couche 2 ou le VPN de couche 2 chez PE A. Junos OS prend en charge le service pseudowire sur l’interface logique de service ps0.x (x>0) dans l’instance VPLS VPLS-x (ID VLAN dans VPLS-x = m) et le service pseudowire sur l’interface logique de service ps0.y(y>0) dans l’instance VPLS VPLS-y (ID VLAN dans VPLS-y = n).
Sur la Figure 4, lorsque le trafic provient d’EAD 1 vers PE A (sur un circuit de couche 2 ou un VPN de couche 2) avec n’importe quel ID de VLAN, le trafic sort via ps0.0. En fonction de l’ID VLAN dans le trafic, le service pseudowire sur l’interface logique du service est sélectionné. Par exemple, si l’ID VLAN est m, le trafic entrera ps0.x et si l’ID VLAN est n, le trafic entrera ps0.y.
service
Lorsque le trafic entre dans le service pseudowire sur l’interface logique du service ps0.n, où n>0, les étapes suivantes sont effectuées.
L’apprentissage MAC source doit avoir lieu sur le service pseudowire de couche 2 de l’interface logique du service. Le moteur de transfert de paquets source pour ce MAC est le moteur de transfert de paquets de l’interface de tunnel logique sur laquelle le service pseudowire est ancré dans une instance VPLS ou un domaine de pont dans le périphérique PE A.
La recherche MAC de destination est effectuée côté entrée sous la forme d’une liste de fonctionnalités de famille de ponts d’entrée de services pseudowire sur les interfaces logiques de service.
Si la recherche MAC de destination réussit, le trafic est envoyé en monocast ; sinon, le MAC de destination, le MAC de diffusion et le MAC multicast sont inondés.
Si la recherche MAC de destination échoue pour le trafic provenant d’un service pseudowire sur une interface logique de service, la commande est envoyée au moteur de routage et à l’autre moteur de transfert de paquets dans le domaine de
mlp querypont ou l’instance VPLS.
Si un nouveau MAC est appris sur un service pseudowire sur une interface logique de service, la commande est envoyée au moteur de routage et à l’autre moteur de transfert de paquets dans le domaine de
mlp addpont ou l’instance VPLS.
Trafic de la périphérie de service vers le LAN client
Lorsque le trafic pénètre dans l’instance VPLS ou le domaine de pont au niveau de l’équipement de périphérie du service et si le MAC de destination du trafic est appris sur un service pseudowire sur une interface logique de service, le jeton associé à cette interface logique de service pseudowire est défini côté entrée. Le trafic est ensuite envoyé au moteur de transfert de paquets sur lequel l’interface de tunnel logique de l’interface physique du service pseudowire est ancrée dans une structure. Lorsque ce jeton est lancé, il prend en charge les encapsulations VPLS VLAN, pont VLAN, VPLS Ethernet et pont Ethernet. Le saut suivant d’encapsulation pointe vers la liste des fonctionnalités de l’interface logique de sortie du service pseudowire sur l’interface logique du service pour exécuter toutes les fonctionnalités de sortie de couche 2 et envoyer le paquet vers le côté entrée du service pseudowire sur l’interface logique de transport ps0.0.
Si la requête MAC atteint le moteur de transfert de paquets sur lequel le service pseudowire est ancré, le moteur de transfert de paquets envoie la réponse uniquement lorsque le MAC appris sur le service pseudowire sur l’interface logique du service est présent. Le jeton de couche 2 associé au service pseudowire sur l’interface logique du service vu après la recherche MAC de destination pour le MAC appris sur l’interface logique du service pseudowire sur le service doit pointer vers le saut suivant associé au côté accès du service pseudowire sur l’interface logique du service de service.
Le service pseudowire sur l’interface logique de transport est l’interface locale ps0.0 du circuit de couche 2 ou du VPN de couche 2 entre la périphérie de service et les périphériques d’agrégation Ethernet. Le trafic est envoyé au périphérique d’agrégation Ethernet via le circuit de couche 2 ou le VPN de couche 2 sur le domaine d’accès MPLS.
Si le trafic MAC de destination provenant des côtés d’entrée et de sortie de l’équipement de périphérie de service est inconnu, multicast ou broadcast, le trafic doit être inondé. Cela nécessite qu’un prochain saut d’inondation d’équipement de périphérie client inclue le service pseudowire sur l’interface logique du service, qui agit comme une interface logique d’accès pour l’instance VPLS ou le domaine de pont.
Pseudowire Service Interfaces
Les fonctionnalités suivantes sont prises en charge sur les interfaces de service pseudowire :
Une interface de service pseudowire est hébergée sur une interface de tunnel logique (lt-x/y/z). Le trafic d’un service pseudowire de transport sur une interface logique vers un service pseudowire abonné sur une interface logique est basé sur l’ID VLAN disponible.
Le transfert du trafic d’un service pseudowire abonné sur une interface logique vers un service pseudowire de transport sur une interface logique est basé sur l’ID de canal via une adresse IP de bouclage disponible.
Le service Pseudowire sur les interfaces logiques de service est pris en charge sur l’instance de routage VRF (Virtual Routing and Forwarding).
-
Service d’abonné pseudowire (ps) sur une interface trunk pour terminer l’instance de circuit de couche 2 dans un commutateur virtuel compatible VPLS. Le même circuit de couche 2 peut également être terminé dans l’instance de routage de type d’instance VPLS avec différentes interfaces logiques de service et dans l’instance de routage VRF VPN de couche 3 à l’aide d’une autre interface logique de service.
Exemple de configuration
Les exemples de configuration suivants montrent un service pseudowire sur une interface logique de transport sur un circuit de couche 2, un service pseudowire sur des interfaces logiques de service dans un domaine de pont et une instance VPLS dans un périphérique de périphérie de service, et un service pseudowire sur une interface de service trunk dans une instance VPLS :
Service pseudowire sur une interface logique de service dans un domaine de pont sur le routeur 0
[edit]
interfaces {
ps0 {
unit 0 {
encapsulation ethernet-ccc;
}
unit 1 {
encapsulation vlan-bridge;
vlan-id 1;
}
unit 2 {
encapsulation vlan-bridge;
vlan-id 2;
}
}
ge-0/0/0 {
unit 1 {
encapsulation vlan-bridge;
vlan-id 1;
}
unit 2 {
encapsulation vlan-bridge;
vlan-id 2;
}
}
ge-2/0/6 {
unit 0 {
family inet {
address 10.11.2.1/24;
}
family mpls;
}
}
}
protocols {
mpls {
label-switched-path to_192.0.2.2 {
to 192.0.2.2;
}
}
bgp {
group RR {
type internal;
local-address 192.0.3.3;
}
}
l2-circuit {
neighbor 192.0.2.2 {
interface ps0.0 {
virtual-circuit-id 100;
}
}
}
}
bridge-domains {
bd1 {
domain-type bridge;
vlan-id 1;
interface ps0.1;
interface ge-0/0/0.1;
}
bd2 {
domain-type bridge;
vlan-id 2;
interface ps0.2;
interface ge-0/0/0.2;
}
}
Service pseudowire sur une interface logique de service dans une instance VPLS sur le routeur 0
[edit]
interfaces {
ps0 {
unit 0 {
encapsulation ethernet-ccc;
}
unit 1 {
encapsulation vlan-vpls;
vlan-id 1;
family vpls;
}
unit 2 {
encapsulation vlan-vpls;
vlan-id 2;
family vpls;
}
}
ge-0/0/0 {
unit 1 {
encapsulation vlan-vpls;
vlan-id 1;
family vpls;
}
unit 2 {
encapsulation vlan-vpls;
vlan-id 2;
family vpls;
}
}
ge-2/0/6 {
unit 0 {
family inet {
address 10.11.2.1/24;
}
family mpls;
}
}
}
protocols {
mpls {
label-switched-path to_192.0.2.2 {
to 192.0.2.2;
}
}
bgp {
group RR {
type internal;
local-address 192.0.3.3;
}
}
l2-circuit {
neighbor 192.0.2.2 {
interface ps0.0 {
virtual-circuit-id 100;
}
}
}
}
routing-instances {
vpls-1 {
instance-type vpls;
vlan-id 1;
interface ps0.1;
interface ge-0/0/0.1;
}
vpls-2 {
instance-type vpls;
vlan-id 2;
interface ps0.2;
interface ge-0/0/0.2;
}
}
Service pseudowire sur une interface de service trunk dans une instance VPLS sur le routeur 0
[edit]
interfaces {
ps0 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
encapsulation ethernet-ccc;
}
unit 1 {
family bridge {
interface-mode trunk;
vlan-id 1;
}
}
ge-0/0/0 {
unit 1 {
encapsulation vlan-bridge;
vlan-id 1;
family bridge;
}
}
}
routing-instances {
vpls-1 {
instance-type virtual-switch;
protocols {
vpls {
site PE3 {
interface ps0.1;
site-identifier 1;
}
}
}
bridge-domains {
bd1 {
vlan-id 1;
}
}
interface ps0.1;
route-distinguisher 65001:1;
vrf-target target:1:1;
}
}
Service pseudowire sur une interface logique de service dans un circuit de couche 2 sur le routeur 0
[edit]
interfaces {
ps0 {
unit 0 {
encapsulation ethernet-ccc;
}
unit 1 {
encapsulation vlan-ccc;
vlan-id 1;
}
unit 2 {
encapsulation vlan-ccc;
vlan-id 2;
}
}
ge-0/0/0 {
unit 1 {
encapsulation vlan-vpls;
vlan-id 1;
family vpls;
}
unit 2 {
encapsulation vlan-vpls;
vlan-id 2;
family vpls;
}
}
ge-2/0/6 {
unit 0 {
family inet {
address 10.11.2.1/24;
}
family mpls;
}
}
}
protocols {
mpls {
label-switched-path to_192.0.2.2 {
to 192.0.2.2;
}
}
bgp {
group RR {
type internal;
local-address 192.0.3.3;
}
}
l2-circuit {
neighbor 192.0.2.2 {
interface ps0.0 {
virtual-circuit-id 100;
}
}
neighbor 10.10.10.10 {
interface ps0.1 {
virtual-circuit-id 1;
}
}
neighbor 10.11.11.11 {
interface ps0.2 {
virtual-circuit-id 2;
}
}
}
}
Options de prestation de services d’accès à large bande
Il existe actuellement quatre options principales de fourniture de services de réseau à large bande. Ces options sont les suivantes :
Ligne d’abonné numérique
La ligne d’abonné numérique (DSL) est la technologie à large bande la plus largement déployée dans le monde. Cette option de livraison utilise les lignes téléphoniques existantes pour envoyer des informations à large bande sur une fréquence différente de celle utilisée pour le service vocal existant. De nombreuses générations de DSL sont utilisées pour le service résidentiel, y compris la ligne d’abonné numérique à très haut débit 2 (VDSL2) et les versions de la ligne d’abonné numérique asymétrique (ADSL, ADSL2 et ADSL2+). Ces variantes de la LAN offrent principalement un service résidentiel à large bande asymétrique où différentes vitesses en amont et en aval sont mises en œuvre. (VDSL2 prend également en charge le fonctionnement symétrique.) D’autres variantes DSL, telles que la ligne d’abonné numérique à haut débit (HDSL) et la ligne d’abonné numérique symétrique (SDSL), offrent des vitesses symétriques et sont généralement utilisées dans les applications commerciales.
La tête de réseau d’un système DSL est le multiplexeur d’accès DSLAM (Digital Subscriber Line Access Multiplexer). Le dispositif de démarcation chez le client est un modem DSL. Les modèles de services DSL sont définis par le Broadband Forum (anciennement appelé DSL Forum).
Ethernet actif
Active Ethernet utilise la technologie Ethernet traditionnelle pour fournir un service haut débit sur un réseau à fibre optique. Active Ethernet ne fournissant pas de canal séparé pour le service vocal existant, de sorte qu’un équipement VoIP (ou TDM à VoIP) est nécessaire. En outre, l’envoi d’Ethernet pleine vitesse (10 ou 100 Mbit/s) nécessite une puissance importante, nécessitant une distribution vers des commutateurs Ethernet et des répéteurs optiques situés dans des armoires situées à l’extérieur du siège social. En raison de ces restrictions, les premiers déploiements Active Ethernet apparaissent généralement dans les zones densément peuplées.
Réseau optique passif
Les réseaux optiques passifs (PON), comme Active Ethernet, utilisent un câble à fibre optique pour fournir des services sur place. Cette option de distribution offre des vitesses plus élevées que DSL mais des vitesses inférieures à Active Ethernet. Bien que le PON offre un débit plus élevé à chaque abonné, il nécessite un investissement plus important dans le câble et la connectivité.
L’un des principaux avantages du PON est qu’il ne nécessite aucun équipement motorisé en dehors du bureau central. Chaque fibre quittant le siège est divisée à l’aide d’un répartiteur optique non alimenté. La fibre scindée suit ensuite une connexion point à point à chaque abonné.
Les technologies PON se répartissent en trois catégories générales :
ATM PON (APON), Broadband PON (BPON) et Gigabit-able PON (GPON) : normes PON qui utilisent les différentes options de distribution suivantes :
APON : la première norme de réseau optique passif est principalement utilisée pour les applications métiers.
BPON : basé sur APON, BPON ajoute le multiplexage par répartition par ondes (WDM), une allocation de bande passante dynamique et supérieure en amont, ainsi qu’une interface de gestion standard pour activer les réseaux de fournisseurs mixtes.
GPON : GPON est basé sur BPON mais prend en charge des débits plus élevés, une sécurité renforcée et un choix du protocole de couche 2 à utiliser (ATM, modèle d’équipement générique [GEM] ou Ethernet).
Ethernet PON (EPON) : fournit des fonctionnalités similaires à GPON, BPON et APON, mais utilise les normes Ethernet. Ces normes sont définies par l’IEEE. Gigabit Ethernet PON (GEPON) est la version la plus rapide.
PON multiplexage par répartition d’onde (WDM-PON) : PON non standard qui, comme son nom l’indique, fournit une longueur d’onde distincte à chaque abonné.
La tête de réseau d’un système PON est une terminaison de ligne optique (OLT). Le dispositif de démarcation dans les locaux du client est une terminaison de réseau optique (ONT). L’ONT fournit des ports côté abonné pour connecter Ethernet (RJ-45), des fils téléphoniques (RJ-11) ou des câbles coaxiaux (connecteur F).
fibre hybride coaxiale
Les opérateurs multi-systèmes (MSO, également appelés opérateurs de télévision par câble) offrent un service haut débit via leur réseau hybride fibre coaxial (HFC). Le réseau HFC combine la fibre optique et le câble coaxial pour fournir un service directement au client. Les services quittent le bureau central (CO) à l’aide d’un câble à fibre optique. Le service est ensuite converti à l’extérieur du CO en un arbre de câbles coaxiaux à l’aide d’une série de nœuds optiques et, si nécessaire, d’un amplificateur de radiofréquence (RF) trunk. Les câbles coaxiaux se connectent ensuite à plusieurs abonnés. Le dispositif de démarcation est un modem câble ou un décodeur, qui communique avec un système de terminaison par modem câble (CMTS) à la tête de réseau MSO ou à l’installation principale qui reçoit les signaux de télévision pour le traitement et la distribution. Le trafic haut débit est acheminé à l’aide de la norme DOCIS (Data Over Cable Service Interface Specification) définie par CableLabs et de nombreuses entreprises contributrices.
Fourniture haut débit et FTTx
De nombreuses implémentations utilisent le câblage en cuivre existant pour fournir un signal aux locaux, mais la connectivité par câble à fibre optique se rapproche de l’abonné. La plupart des réseaux utilisent une combinaison de câbles en cuivre et en fibre optique. Le terme fibre jusqu’au x (FTTx) décrit la distance à parcourir dans le réseau avant qu’un câblage en cuivre ne soit commuté. Le PON et l’Ethernet actif peuvent tous deux utiliser une partie fibre optique du réseau, tandis que xDSL est généralement utilisé sur la partie cuivre. Cela signifie qu’un seul brin de fibre optique peut prendre en charge plusieurs abonnés à base de cuivre.
L’utilisation croissante de la fibre optique dans le réseau augmente les coûts, mais augmente également la vitesse d’accès au réseau pour chaque abonné.
Les termes suivants sont utilisés pour décrire le point de terminaison d’un câble à fibre optique dans un réseau :
Fibre jusqu’aux locaux (FTTP), fibre jusqu’au domicile (FTTH), fibre jusqu’à l’entreprise (FTTB) : la fibre s’étend jusqu’à l’abonné. Le PON est le plus courant pour l’accès résidentiel, bien qu’Ethernet actif puisse être utilisé efficacement dans les zones denses telles que les complexes d’appartements. L’Ethernet actif est plus courant pour fournir des services aux entreprises.
Fibre jusqu’au trottoir (FTTC) : la fibre s’étend sur la majeure partie du trajet (généralement 500 pieds/150 mètres ou moins) jusqu’à l’abonné. Le cuivre existant est utilisé pour la distance restante jusqu’à l’abonné.
Fibre jusqu’au nœud/voisinage (FTTN) : la fibre s’étend jusqu’à quelques milliers de mètres de l’abonné et est convertie en xDSL pour la distance restante jusqu’à l’abonné.
Fiber to the Exchange (FTTE) : implémentation xDSL typique basée sur un bureau central, dans laquelle la fibre est utilisée pour acheminer le trafic vers le siège et xDSL est utilisée sur la boucle locale existante.
Comprendre la prise en charge par BNG des déploiements DSLAM en cascade sur des canaux DSL liés
Junos OS prend en charge la configuration et la maintenance des lignes d’accès entre les nœuds d’accès et leurs abonnés ANCP à l’aide du multiplexeur d’accès DSL comme technologie d’accès haut débit pour le cuivre-to-the-Building (CuTTB) et la fibre jusqu’au bâtiment (FTTB). Lorsque plusieurs abonnés partagent la même ligne d’accès, celle-ci peut être de l’un des types suivants :
PON, fibre jusqu’au bâtiment (FTTB)
Cuivre DSL collé au bâtiment (CTTB)
À partir de Junos OS version 18.2R1, les technologies d’accès au réseau optique passif (PON) sont prises en charge avec quatre niveaux de hiérarchie de planificateur de qualité de service (QoS) pour les abonnés résidentiels dans un déploiement BBE. Cette fonctionnalité étend la mise en œuvre du protocole ANCP (Access Node Control Protocol) pour gérer la configuration du réseau pour les clients résidentiels qui utilisent le PON comme technologie d’accès haut débit pour CuTTB et FTTB. ANCP utilise un profil de contrôle du trafic contrôlé statiquement sur le jeu d’interfaces pour la mise en forme au niveau de l’abonné au niveau du nœud intermédiaire auquel les abonnés sont connectés. De nouveaux types de LAN sont fournis pour appuyer le rajustement du débit des lignes d’accès pour les nouvelles technologies d’accès.
Un nouveau RADIUS VSA, Inner-Tag-Protocol-Id 26-211, est introduit pour récupérer la valeur interne VLAN Tag Protocol Identifier pour les abonnés L2BSA afin de permettre de maintenir un profil dynamique au lieu de deux profils dynamiques distincts. Une nouvelle variable $junos-inner-vlan-tag-protocol-id de profil dynamique Junos OS permet de définir une carte VLAN par RADIUS ou une valeur par défaut prédéfinie inner-tag-protocol-id fournie dans la configuration.
- Avantages des déploiements DSLAM en cascade par rapport aux canaux DSL liés
- Hiérarchie du planificateur à 4 niveaux
- Cas d’utilisation de déploiements DSLAM en cascade sur des canaux DSL liés
- DSL collé pour cuivre jusqu’au bâtiment (CuTTB)
- PON hybride + G.fast
- Fonctionnalités prises en charge
Avantages des déploiements DSLAM en cascade par rapport aux canaux DSL liés
Cette fonctionnalité est utile pour prendre en charge les déploiements de réseaux d’accès où plusieurs abonnés partagent la même ligne d’accès agglomérée par un nœud intermédiaire entre le nœud d’accès et les passerelles de routage domestiques. Un autre avantage est de conserver les nœuds CoS de couche 2. Généralement, un nœud factice de couche 2 est créé pour chaque ménage résidentiel, ce qui pourrait épuiser les ressources CoS de couche 2. Par conséquent, les modèles de réseau utilisant des modèles d’accès DSL, G.Fast et PON collés peuvent conserver les nœuds CoS de couche 2.
Hiérarchie du planificateur à 4 niveaux
Junos OS prend en charge une hiérarchie de planificateurs QoS à 4 niveaux, prenant en charge de manière minimale l’accès résidentiel et L2BSA via des déploiements de réseau d’accès Copper-to-the-Building (CTTB) ou Fiber-to-the-Building. Les niveaux de hiérarchie du planificateur QoS suivants sont pris en charge :
Port de niveau 1 (interface physique ou AE)
Ligne d’accès de niveau 2 (jeu d’interfaces logiques, représente un ensemble d’abonnés partageant une ligne d’accès donnée agrégée par un nœud intermédiaire)
Sessions d’abonnés de niveau 3
Files d’attente de niveau 4 (services)
du planificateur
Sur la figure 5, l’accès résidentiel et L2BSA ne nécessite qu’une hiérarchie de planificateur à 4 niveaux. L’accès des abonnés professionnels n’est actuellement pas pris en charge et, par conséquent, une hiérarchie de planificateurs à 4 niveaux est suffisante pour les services CuTTB et PON ciblant un immeuble d’appartements.
Cas d’utilisation de déploiements DSLAM en cascade sur des canaux DSL liés
Le DSL collé pour le cuivre au bâtiment (CuTTB) introduit une unité de point de distribution de nœud intermédiaire-cuivre (DPU-C) entre le multiplexeur d’accès DSL (DSLAM) et un groupe d’abonnés chez le client. Les modèles de déploiement de lignes d’accès partagé peuvent être de type réseau optique passif (PON) ou lignes de cuivre DSL collées. Des exemples de nœuds intermédiaires sont répertoriés ci-dessous :
DPU-C - DSL collé pour Copper-To-The-Building (CTTB)
ONU - PON (Fiber-to-the-Building (FTTB))
PON hybride et G.Fast
DSL collé pour cuivre jusqu’au bâtiment (CuTTB)
cautionné
Sur la Figure 6, chaque DPU-C dispose d’une session ANCP pour signaler les paramètres de ligne d’accès des abonnés individuels connectés au nœud. Le MSAN dispose également d’une session ANCP pour signaler les paramètres de la ligne d’accès DSL liée au DPU-C. Tous les abonnés connectés au DPU-C sont ainsi soumis au débit de la ligne d’accès DSL en aval, les abonnés DPU-C sont regroupés dans un ensemble d’interfaces. Vous pouvez ajuster les vitesses indiquées dans ce Port-Up et appliquer au nœud CoS l’interface correspondante ste en conservant la sémantique du profil de contrôle de réglage CoS utilisé pour les lignes d’abonnés individuelles. Le modèle d’accès se compose d’un hybride d’accès DSL lié et d’accès non lié conventionnel. Les sessions ANCP DPU-C et MSAN (Multi Service Access Node) sont totalement indépendantes et les balises PPPoE-IA ne reflètent que les attributs rapportés dans la session ANCP dPU-C
PON hybride + G.fast
Sur la Figure 7, l’OLT dispose d’une session ANCP avec le BNG et des proxys pour tous les nœuds PON natifs en aval. Les abonnés G.fast DSL sont connectés à un nœud intermédiaire, qui dispose d’une connexion PON à l’ONU intermédiaire devant l’OLT.
Un réseau d’accès hybride connecte les lignes d’abonnés DSL en utilisant à la fois un accès PON et des nœuds G.fast avec un nœud intermédiaire entre l’OLT et les passerelles domestiques (HG). Les entreprises et les résidences sont connectées au nœud intermédiaire, qui est la feuille PON. La mise en forme est nécessaire à la fois au niveau de l’abonné et au niveau de la feuille PON. Les abonnés G.fast sont associés à l’ONU intermédiaire comme un abonné PON natif. Les nouvelles TLV de type DSL sont prises en charge par l’AN et leurs valeurs sont indiquées dans le port ANCP de la ligne d’accès abonné correspondante. Cependant, il n’est toujours pas possible de faire la distinction entre un nœud intermédiaire et une connexion conventionnelle pour une session PPPoE donnée.
Fonctionnalités prises en charge
Prise en charge de la mise en forme du trafic basée sur ANCP sur des iflsets dynamiques.
Préservation de l’indépendance PPP0E-IA et ANCP par configuration CLI pour les abonnés résidentiels.
Le nouveau VSA Juniper, ERX-Inner-Vlan-Tag-Protocol-Id (4874-26-211) est pris en charge pour sourcer la valeur interne VLAN Tag Protocol Identifier pour les abonnés L2BSA afin d’optimiser le maintien de deux profils dynamiques distincts, l’un pour TPID - 0x88a8 et l’autre pour 0x8100, et de rechercher la valeur souhaitée en renvoyant 26-4874-174 (Client-rofile-Name) dans l’Access-Accept.
Les valeurs de type supplémentaires suivantes pour le type TLV DSL sont prises en charge. Tous les abonnés incluent ces TLV de type DSL dans les balises PPPoE IA des messages PPPoE PADR.
(8) G.fast
(9) VDSL2, annexe Q
(10) SDSL cautionné
(11) VDSL2 collé
(12) G,liaison rapide
(13) Annexe Q du VDSL2 sous douane
Détection d’identificateurs de ligne de liaison et génération automatique de jeux d’interfaces de nœuds intermédiaires
Avant de commencer, vous devez confirmer que vos nœuds d’accès ou IA existants n’insèrent pas déjà des chaînes commençant par le # caractère. Étant donné qu’il s’agit d’une configuration au niveau du système, l’analyse s’applique à tous les nœuds d’accès ANCP et IA PPPoE dans le monde. Le caractère de début # n’est pas configurable. L’analyse est désactivée par défaut au cas où certains fournisseurs utiliseraient ce caractère à d’autres fins.
À partir de Junos OS version 18.4R1, vous pouvez configurer le routeur pour détecter un nœud intermédiaire logique dans un réseau d’accès. Le nœud identifie les abonnés connectés au même média partagé, tel qu’une arborescence PON ou une ligne de cuivre collée qui se connecte à un DPU-C pour CuTTB. Lorsque vous configurez cette détection, le routeur analyse l’attribut ANCP Access-Aggregation-Circuit-ID-ASCII (TLV 0x03) reçu dans le message ANCP Port Up ou PPPoE PADR IA. Si la chaîne TLV commence par le caractère, la chaîne est un identificateur de ligne de liaison unique sur le # réseau pour identifier la ligne DSL liée ou l’arborescence PON. La même chaîne est signalée dans le TLV ou l’IA pour tous les abonnés connectés à ce DPU-C ou PON.
La partie de la chaîne après le caractère représente le # nœud intermédiaire logique. Il est utilisé comme nom de l’ensemble d’interfaces dynamiques défini pour le nœud CoS de niveau 2 qui regroupe les abonnés à l’aide de ce nœud intermédiaire. Ce jeu d’interfaces est appelé jeu d’interfaces parent. Chaque interface logique PPPoE ou VLAN (L2BSA) avec la même valeur pour le 0x03 TLV est membre de cet ensemble d’interfaces.
La valeur TLV doit correspondre aux exigences pour la dénomination du jeu d’interfaces ; Il peut inclure des caractères alphanumériques et les caractères spéciaux suivants :
# % / = + - : ; @ . _
Cette partie de la chaîne définit également la valeur de la variable prédéfinie nom-ensemble-interface-$junos-agrégation dans le profil dynamique. Cette valeur est utilisée comme nom d’un jeu d’interfaces CoS de niveau 2 qui regroupe les abonnés partageant cette chaîne. Il remplace la variable prédéfinie par défaut, qui utilise la valeur $junos-phy-ifd-interface-set-name comme nom du jeu d’interfaces.
Par exemple, si la valeur de la chaîne TLV est #TEST-DPU-C-100, la valeur de la variable prédéfinie (et par conséquent le nom du jeu d’interfaces) devient TEST-DPU-C-100.
L’Access-Loop-Remote-ID (TLV (0x02) est analysée de la même manière pour le # caractère, mais la chaîne résultante n’est pas utilisée dans la version actuelle.
La détection de nœuds intermédiaires n’étant prise en charge que pour les hiérarchies de planificateurs à 4 niveaux, l’accès professionnel est limité aux MPC d’accès DSL conventionnels.
Pour activer l’analyse de la technologie TLV ACCESS-AGGREGATION-CIRCUIT-ID-ASCII et définir le nom du jeu d’interfaces :
L’exemple de configuration suivant montre un profil dynamique pour les abonnés L2BSA. Trois choses à noter ici sont les suivantes :
La valeur par défaut $junos-phy-ifd-interface-set-name est définie pour la variable prédéfinie nom-ensemble-interface-$junos-agrégation-interface.
Le nom du jeu d’interfaces est configuré pour être la valeur de $junos-aggregation-interface-set-name.
La configuration du planificateur CoS spécifie une interface nommée avec la valeur $junos-aggregation-interface-set-name.
Lorsque hierarchical-access-network-detection est configuré pour les lignes d’accès, le nom du jeu d’interfaces du planificateur de niveau 2 est déterminé comme suit :
Lorsque la 0x03 TLV commence par
#, alors nom_ensemble-d’interfaces-$junos agrégation est le reste de la chaîne, à l’exclusion du fichier initial#.Lorsque la 0x03 TLV commence par un autre caractère, alors $junos-aggregation-interface-set-name est la valeur de $junos-phy-ifd-interface-set-name.
[edit dynamic-profiles L2BSA-subscriber]
predefined-variable-defaults {
aggregation-interface-set-name phy-ifd-interface-set-name;
cos-shaping-rate 1g;
cos-scheduler-map schedmap_L2BSA;
inner-vlan-tag-protocol-id 0x88a8;
}
routing-instances {
"$junos-routing-instance" {
interface "$junos-interface-name";
}
}
interfaces {
interface-set $junos-aggregation-interface-set-name {
interface "$junos-interface-ifd-name" {
unit "$junos-interface-unit";
}
}
"$junos-interface-ifd-name" {
unit "$junos-interface-unit" {
encapsulation vlan-vpls;
no-traps;
vlan-id "$junos-vlan-id";
input-vlan-map {
swap-push;
inner-tag-protocol-id "$junos-inner-vlan-tag-protocol-id"
vlan-id "$junos-vlan-map-id";
inner-vlan-id "$junos-inner-vlan-map-id";
}
output-vlan-map {
pop-swap;
inner-tag-protocol-id 0x8100;
}
family vpls;
}
}
}
class-of-service {
traffic-control-profiles {
L2BSAShaper {
scheduler-map "$junos-cos-scheduler-map";
shaping-rate "$junos-cos-shaping-rate" burst-size 17k;
overhead-accounting frame-mode cell-mode-bytes 6;
}
L2iflsetShaper {
shaping-rate 1G burst-size 17k;
}
}
interfaces {
"$junos-interface-ifd-name" {
unit "$junos-interface-unit" {
output-traffic-control-profile L2BSAShaper;
classifiers {
ieee-802.1 L2BSA vlan-tag outer;
}
rewrite-rules {
ieee-802.1 L2BSA vlan-tag outer;
}
}
}
interface-set "$junos-aggregation-interface-set-name" {
output-traffic-control-profile L2iflsetShaper;
}
}
}