Présentation du réseau d’accès abonné haut débit
Vue d’ensemble 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 aux abonnés comprennent :
Serveur DHCP (Dynamic Host Configuration Protocol)
Serveur DHCP local
Serveur DHCP externe
Protocole PPP (Point-to-Point Protocol)
Les protocoles d’authentification de l’abonné incluent le serveur RADIUS.
La figure 1 montre un exemple de réseau d’accès abonné de base.
de réseau d’accès abonné
Cette fonctionnalité nécessite une licence. Pour en savoir plus sur les licences d’accès abonné, reportez-vous à la section Présentation des licences d’accès abonné. Reportez-vous au Guide des licences Juniper pour obtenir des informations générales sur la gestion des licences. Pour plus de détails, reportez-vous aux fiches techniques des routeurs MX Series ou contactez votre équipe de compte Juniper ou votre partenaire Juniper.
Présentation du nud d’accès multiservice
Un nud d’accès multiservice est un terme plus large qui fait référence à un groupe de périphériques d’agrégation couramment utilisés. Ces dispositifs comprennent les multiplexeurs numériques d’accès à la ligne d’abonné (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 le bon vieux service téléphonique (appelé POTS) ou le signal numérique 1 (DS1 ou T1).
La fonction principale d’un nud d’accès multiservice est d’agréger le trafic de plusieurs abonnés. Sur le plan physique, le MSAN convertit également le trafic de la technologie du dernier kilomètre (par exemple, l’ADSL) en Ethernet pour la livraison aux abonnés.
Vous pouvez classer les MSAN en trois types en fonction de la manière dont ils transfèrent le trafic sur le réseau :
Layer–2 MSAN—Ce type de MSAN est essentiellement un commutateur de couche 2 (bien qu’il ne soit généralement pas entièrement fonctionnel) avec quelques améliorations pertinentes. Ces MSAN utilisent la commutation Ethernet (ou ATM) pour transférer le trafic. Le MSAN transfère tout le trafic des abonnés en amont vers un routeur de périphérie qui fait office de point de contrôle centralisé et empêche toute communication directe d’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 l’IGMP, ils ne peuvent donc pas répliquer de manière sélective les canaux IPTV.
Layer–3 aware MSAN: ce MSAN orienté 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 prise en compte de la couche 3 est importante lors de la prise en charge du trafic IPTV pour 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 LAMSD. Cependant, les DSLAM dynamiques prenant en charge l’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 la surveillance IGMP sur le DSLAM accomplit cette fonction.
Layer–3 MSAN: ces MSAN utilisent la fonctionnalité de routage IP plutôt que les technologies de couche 2 pour transférer le trafic. L’avantage de cette méthode de transfert est qu’elle permet de prendre en charge plusieurs liaisons montantes reliées à différents routeurs en amont, ce qui améliore la résilience du réseau. Toutefois, pour atteindre ce niveau de résilience, vous devez attribuer un sous-réseau IP distinct à chaque 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 de l’envoyer au routeur de services. Le Tableau 1 répertorie les méthodes d’agrégation MSAN possibles et les conditions dans lesquelles elles sont utilisées.
Méthode |
Lorsqu’il est utilisé |
|---|---|
Connexion directe |
Chaque MSAN se connecte directement au routeur de services haut débit et au routeur de services vidéo en option. |
Connexion du 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 d’agrégation en anneau Ethernet |
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 avec le routeur de services haut débit. S’il existe un bureau central intermédiaire, le trafic de plusieurs MSAN peut être combiné sur une seule connexion à l’aide du multiplexage par répartition par ondes (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 MSAN de couche 3 capable de déterminer la liaison à utiliser lors du transfert de trafic.
Lorsque vous utilisez la méthode de connexion directe, gardez à l’esprit les points suivants :
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éries.
La connexion directe est généralement utilisée lorsque la plupart des liaisons MSAN sont utilisées à moins de 33 % et qu’il y a peu d’intérêt à combiner le trafic de plusieurs MSAN.
Connexion au commutateur d’agrégation Ethernet
Un commutateur d’agrégation Ethernet agrège 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 débit (par exemple, 1 Gbit/s) vers une connexion à plus haut débit vers le 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 d’utilisation de la mise en 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) à l’extrémité principale 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 d’utilisation de la mise en réseau Ethernet pour les routeurs MX Series.
Présentation de la détection automatique des pseudofils LDP
Un pseudowire est un lien virtuel utilisé pour transporter un service de couche 2 sur un réseau périphérique ou d’accès MPLS. Dans un réseau de périphérie haut débit ou d’entreprise classique, une extrémité d’un pseudowire est terminée en tant que circuit de couche 2 sur un nud d’accès, et l’autre extrémité est terminée en tant que circuit de couche 2 sur un nud de service qui sert de nud 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 des 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 nuds de service en fonction des messages de signalisation LDP. Ce modèle peut faciliter le provisionnement de pseudowires à grande échelle. Un nud d’accès utilise LDP pour signaler à la fois l’identité pseudowire et les attributs à un nud 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.
- Contexte de la terminaison d’entrée de pseudowire
- Approche de détection automatique des pseudo-fils
- Exemple de configuration
Contexte de la terminaison d’entrée de pseudowire
Dans un réseau d’accès haut débit ou de périphérie d’entreprise compatible MPLS sans faille, les pseudofils Ethernet sont couramment utilisés comme interfaces virtuelles pour connecter les nuds d’accès aux nuds de service. Chaque pseudowire transporte le trafic bidirectionnel d’un ou plusieurs abonnés haut débit ou clients de périphérie d’entreprise entre un nud d’accès et une paire de nuds de service. L’établissement du pseudowire est généralement initié par le nud d’accès, en fonction soit d’une configuration statique, soit d’une détection dynamique d’un nouvel abonné haut débit ou d’un client de périphérie d’entreprise arrivant sur un port client sur le nud d’accès.
Idéalement, le nœud d’accès devrait 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 consiste à établir 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 pseudowire 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 s’il n’est pas 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 ou les clients individuels peuvent être distingués par C-VLAN, ou par un en-tête de couche 2 tel que DHCP et PPP, qui sera transporté dans une charge utile pseudowire jusqu’au nud 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 interfaces d’abonné haut débit, en interfaces de périphérie d’entreprise (par exemple, PPPoE), en interfaces Ethernet ou en interfaces IP. Des interfaces Ethernet et IP peuvent également être attaché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 nuds de service est prise en charge via 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 une interface de tunnel logique, en raison de sa capacité à multiplexer et démultiplexer les abonnés ou les clients sur un seul pseudowire. 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. Au-dessus 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 liaison.
Le circuit de couche 2 ou le VPN de couche 2 active la signalisation pseudowire vers le nœud d’accès, et l’interface logique ps.0 joue le rôle d’interface de 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 des flux d’abonnés/clients individuels en tant qu’interfaces logiques. Ces interfaces peuvent ensuite être attachées aux services haut débit et de périphérie d’entreprise souhaités, ou aux instances VPN de couche 2 ou 3 souhaitées.
Notez que le but du moteur de transfert de paquets anchor est de désigner le moteur de transfert de paquets pour traiter le trafic bidirectionnel du pseudowire, y compris l’encapsulation, la décapsulation, le mux ou demux 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 pseudowire, des interfaces logiques du 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 nud 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 lors du provisionnement et du déprovisionnement de la terminaison d’entrée pseudowire sur les nœuds de service.
Approche de détection automatique des pseudo-fils
Dans l’approche de détection automatique des pseudofils, un nud de service utilise le message de mappage d’étiquettes LDP reçu d’un nud d’accès comme déclencheur pour générer dynamiquement la configuration d’une interface physique de service de pseudofil, d’une interface logique de service de pseudowire et d’un circuit de couche 2. De même, il utilise le message de retrait de l’étiquette LDP reçu du nœud d’accès et l’événement d’arrêt de session LDP comme déclencheurs pour supprimer la configuration générée. Dans la détection automatique des pseudo-fils, on suppose que les nœuds d’accès sont les initiateurs de la signalisation des pseudo-fils et que les nœuds de service sont les cibles. Dans un réseau où un service peut être hébergé par plusieurs nuds de service à des fins de redondance ou d’équilibrage de charge, les nuds d’accès disposent également d’un modèle de sélection et de connexion pour l’établissement de services. Le flux de contrôle de base de la détection automatique des pseudo-fils est illustré à la Figure 3
automatique des pseudofils
La procédure de flux de contrôle de base de la détection automatique de pseudowire est la suivante :
L’équipement sur le site client (CPE) se connecte et envoie une trame Ethernet avec C-VLAN à la terminaison de ligne optique (OLT). L’OLT ajoute le S-VLAN à la trame et l’envoie au nud d’accès. Le nœud d’accès vérifie auprès du serveur RADIUS s’il autorise les VLAN.
Le serveur RADIUS envoie un accord d’accès au nœud d’accès. Le noeud d’accès crée un circuit de couche 2 et signale un pseudowire au noeud 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 de pseudowire au serveur RADIUS pour autorisation et sélection d’une interface physique de service de 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 l’interface logique du service pseudowire sélectionnée. Le nœud de service crée une configuration de circuit de couche 2, les informations de pseudowire et l’interface physique ou logique du service de pseudowire. Le nœud de service signale le pseudowire vers le nœud d’accès par le biais d’un message de mappage d’étiquettes LDP. Le pseudowire s’active 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. La configuration de l’interface physique du service pseudowire et de l’interface logique du service pseudowire est facultative, 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;
}
}
}
}
Présentation 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) 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 VPLS (Virtual Private LAN Service). Il existe un circuit de couche 2 ou un VPN de couche 2 sur l’accès MLPS entre un périphérique d’agrégation Ethernet et un équipement de périphérie de service avec le service de pseudowire sur l’interface logique de transport psn.0 comme interface de terminaison du circuit de couche 2 ou le VPN de couche 2 au niveau du 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 au niveau de l’équipement de périphérie de service. Il active également des 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 du service.
Lorsque le trafic est dans le sens inverse, l’adresse MAC de destination entre dans le domaine de couche 2 au niveau de l’équipement de périphérie de service, qui est appris en tant qu’adresse MAC source sur le service de pseudowire sur les interfaces logiques de service. À compter de Junos OS version 17.1R1, les interfaces de tunnel logique pseudowire prennent en charge les sauts suivants d’encapsulation de pont Ethernet VPLS, VPLS VLAN et d’encapsulation de pont VLAN pour quitter le trafic de couche 2. À compter de Junos OS version 18.4R1, la prise en charge du service 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 de pseudowire sur les interfaces logiques de transport, qui constituent l’interface de circuit de couche 2 entre les équipements d’agrégation Ethernet et les équipements 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 fonctionnalités de couche 2 ne pouvaient pas être configurées sur le service pseudowire sur les interfaces logiques de service.
- Trafic du LAN client vers MPLS
- Trafic de la périphérie de services 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 du côté central MPLS de l’équipement de périphérie de services (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 à PE A. Junos OS prend en charge le service pseudowire sur l’interface logique de service ps0.x (x>0) dans l’instance VPLS-x (ID de VLAN dans VPLS-x = m) et le service de pseudowire sur l’interface logique de service ps0.y(y>0) dans l’instance VPLS-y (ID de 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 un ID de VLAN, le trafic se termine par ps0.0. En fonction de l’ID de VLAN dans le trafic, le service pseudowire sur l’interface logique du service est sélectionné. Par exemple, si l’ID de VLAN est m, le trafic entrera dans ps0.x et si l’ID de VLAN est n, le trafic entrera dans ps0.y.
logique du 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 se produire sur le service de pseudowire de couche 2 sur l’interface logique du service. Le moteur de transfert de paquets source pour cette adresse 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 en tant que liste de fonctionnalités de la famille de ponts en entrée des services de pseudowire sur les interfaces logiques de service.
Si la recherche MAC de destination réussit, le trafic est envoyé en tant qu’unicast ; sinon, l’adresse MAC de destination, l’adresse MAC de diffusion et l’adresse MAC de multidiffusion sont inondées.
Si la recherche MAC de destination échoue pour le trafic provenant d’un service pseudowire sur une interface logique de service, la
mlp querycommande est envoyée au moteur de routage et à l’autre moteur de transfert de paquets dans le domaine de pont ou l’instance VPLS.
Si un nouvel MAC est appris sur un service pseudowire sur une interface logique de service, la
mlp addcommande est envoyée au moteur de routage et à l’autre moteur de transfert de paquets dans le domaine de pont ou l’instance VPLS.
Trafic de la périphérie de services 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 de service et si l’adresse MAC de destination dans le trafic est apprise 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 VLAN VPLS, VLAN bridge, Ethernet VPLS et Ethernet bridge. 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 de pseudowire est ancré, le moteur de transfert de paquets envoie la réponse uniquement lorsque l’adresse MAC apprise sur le service de pseudowire sur l’interface logique du service est présente. Le jeton de couche 2 associé au service de pseudowire sur l’interface logique du service vu après la recherche MAC de destination pour l’adresse MAC apprise sur le service de pseudowire sur l’interface logique du service doit pointer vers le saut suivant associé au côté d’accès du service de pseudowire sur le service de pseudowire sur le service de l’interface logique.
Le service pseudowire sur l’interface logique de transport est l’interface locale ps0.0 du circuit de couche 2 ou 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 points d’entrée et de sortie de l’équipement de périphérie de service est inconnu, s’il s’agit d’une multidiffusion ou d’une diffusion, le trafic doit être inondé. Pour ce faire, un tronçon suivant de flooding d’équipements périphériques client doit inclure le service Pseudowire sur l’interface logique du service, qui fait office d’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 de pseudowire de transport sur une interface logique vers un service de pseudowire d’abonné sur une interface logique est basé sur l’ID de VLAN disponible.
Le transfert du trafic d’un service de pseudowire d’abonné sur une interface logique vers un service de 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 de pseudowire subscriber (ps) sur une interface trunk pour terminer une 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 instance VPLS avec différentes interfaces logiques de service et dans l’instance de routage de type instance VRF VPN de couche 3 utilisant également une autre interface logique de service.
Exemple de configuration
Les exemples de configuration suivants illustrent 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 équipement de périphérie de service, et un service pseudowire sur une interface de service trunk dans une instance VPLS :
Service de pseudowire sur une interface logique de service dans le 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 de 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 de 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 de 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 aujourd’hui quatre options principales pour fournir un service 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 de l’information à 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 ligne d’abonné numérique asymétrique (ADSL, ADSL2 et ADSL2+). Ces variantes de DSL 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 binaire (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 professionnelles.
La tête de réseau d’un système DSL est le multiplexeur d’accès à la ligne d’abonné numérique (DSLAM). Le dispositif de démarcation chez le client est un modem DSL. Les modèles de service 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. L’Ethernet actif ne fournit pas de canal séparé pour le service vocal existant, de sorte qu’un équipement VoIP (ou TDM-vers VoIP) est nécessaire. De plus, l’envoi d’Ethernet à pleine vitesse (10 ou 100 Mbit/s) nécessite une puissance importante, ce qui nécessite une distribution vers des commutateurs Ethernet et des répéteurs optiques situés dans des armoires à l’extérieur du bureau central. En raison de ces restrictions, les premiers déploiements Active Ethernet apparaissent généralement dans les zones densément peuplées.
Réseaux optiques passifs
Tout comme l’Active Ethernet, les réseaux optiques passifs (PON) utilisent des fibres optiques pour fournir des services sur site. Cette option de livraison offre des vitesses supérieures à celles de l’ADSL, mais des vitesses inférieures à celles de l’Ethernet actif. Bien qu’un 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 siège social. Chaque fibre sortant du bureau central est divisée à l’aide d’un répartiteur optique non alimenté. La fibre fractionnée suit ensuite une connexion point à point jusqu’à chaque abonné.
Les technologies PON se répartissent en trois grandes catégories :
ATM PON (APON), PON à large bande (BPON) et PON compatible gigabit (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 professionnelles.
BPON : basé sur APON, BPON ajoute le multiplexage par répartition d’ondes (WDM), une allocation dynamique et plus élevée de la bande passante en amont, ainsi qu’une interface de gestion standard pour permettre aux 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 le choix du protocole de couche 2 à utiliser (ATM, GEM [Generic Equipment Model] 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.
Wave Division Multiplexing PON (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 un terminateur de réseau optique (ONT). L’ONT fournit des ports côté abonné pour connecter des câbles Ethernet (RJ-45), téléphoniques (RJ-11) ou 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 à large bande par le biais de leur réseau hybride fibre-coaxial (HFC). Le réseau HFC combine la fibre optique et le câble coaxial pour fournir le service directement au client. Les services quittent le bureau central à l’aide d’un câble en fibre optique. Le service est ensuite converti à l’extérieur du CO en une arborescence de câbles coaxiaux à l’aide d’une série de nœuds optiques et, si nécessaire, par l’intermédiaire 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 de modem câble (CMTS) à la tête de réseau de l’OSM ou à l’installation principale qui reçoit les signaux de télévision pour traitement et distribution. Le trafic à large bande est acheminé à l’aide de la norme DOCSIS (Data Over Cable Service Service Interface Specification) définie par CableLabs et de nombreuses entreprises contributrices.
Distribution haut débit et FTTx
De nombreuses implémentations utilisent le câblage en cuivre existant pour fournir le signal aux locaux, mais la connectivité par câble à fibre optique se rapproche de plus en plus de l’abonné. La plupart des réseaux utilisent une combinaison de câbles en cuivre et en fibre optique. Le terme « fibre jusqu’à x » (FTTx) décrit la distance parcourue par le câblage en fibre optique avant de passer au câblage en cuivre. Le PON et l’Ethernet actif peuvent tous deux utiliser la 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 cuivre.
L’augmentation de l’utilisation de la fibre dans le réseau augmente les coûts, mais elle 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’aux entreprises (FTTB) : la fibre s’étend jusqu’à l’abonné. Le PON est le plus utilisé pour les accès résidentiels, bien que l’Ethernet actif puisse être utilisé efficacement dans les zones denses telles que les complexes d’appartements. L’Ethernet actif est plus utilisé pour fournir des services aux entreprises.
Fiber to the Curb (FTTC) : la fibre s’étend sur la majeure partie du chemin (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é.
Fiber to the Node/Neighborhood (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 au bureau central et le xDSL est utilisé sur la boucle locale existante.
Comprendre la prise en charge BNG pour les 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 nuds d’accès et leurs abonnés ANCP en utilisant le multiplexeur d’accès DSL comme technologie d’accès haut débit pour les protocoles CuTTB (cuivre-to-the-building) et FTTB (fiber-to-the-building). Lorsque plusieurs abonnés partagent la même ligne d’accès, celle-ci peut être de l’un des types suivants :
PON, Fiber-to-the-Building (FTTB)
Cuivre DSL collé au bâtiment (CTTB)
À compter de Junos OS version 18.2R1, les technologies d’accès aux réseaux optiques passifs (PON) sont prises en charge avec quatre niveaux de hiérarchie de planificateurs de qualité de service (QoS) pour les abonnés résidentiels dans un déploiement BBE. Cette fonctionnalité étend l’implémentation 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. L’ANCP utilise un profil de contrôle du trafic contrôlé statiquement sur l’ensemble 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 LIS sont fournis pour prendre en charge l’ajustement du débit de la ligne 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 le maintien d’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 des déploiements DSLAM en cascade sur des canaux DSL liés
- DSL collé pour le 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éseau 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 nud d’accès et les passerelles de routage d’origine. Un autre avantage est la conservation des nœuds CoS de couche 2. En règle générale, un nœud de couche 2 factice est créé pour chaque ménage résidentiel, ce qui peut é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 lié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 au minimum l’accès résidentiel et L2BSA sur les déploiements de réseaux d’accès Copper-to-the-Building (CTTB) ou Fiber-to-the-Building. Les niveaux hiérarchiques du planificateur QoS suivants sont pris en charge :
Port de niveau 1 (interface physique ou AE)
Ligne d’accès de niveau 2 (ensemble 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 planificateurs à 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 ciblés sur un immeuble d’habitation.
Cas d’utilisation des déploiements DSLAM en cascade sur des canaux DSL liés
Le DSL lié pour le cuivre au bâtiment (CuTTB) introduit un nœud intermédiaire d’unité de point de distribution cuivre (DPU-C) entre le multiplexeur d’accès DSL (DSLAM) et un cluster d’abonnés sur le site du client. Les modèles de déploiement de lignes d’accès partagé peuvent être de type réseau optique passif (PON) ou des lignes en cuivre DSL liées. Des exemples de noeuds intermédiaires sont répertoriés ci-dessous :
DPU-C - DSL lié pour le cuivre jusqu’au bâtiment (CTTB)
ONU - PON (Fibre jusqu’au bâtiment (FTTB))
PON hybride et G.Fast
DSL collé pour le cuivre jusqu’au bâtiment (CuTTB)
lié
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 raccordés au DPU-C sont donc soumis au débit descendant de la ligne d’accès DSL, les abonnés DPU-C étant regroupés dans un ensemble d’interfaces. Vous pouvez ajuster les vitesses indiquées dans ce Port-Up et les appliquer au nœud CoS pour l’interface correspondante en conservant la sémantique du profil de contrôle d’ajustement CoS utilisé pour les lignes d’abonné individuelles. Le modèle d’accès se compose d’un hybride d’accès DSL lié et d’accès conventionnel non lié. 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 signalé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 de proxys pour tous les nuds PON natifs en aval. Les abonnés G.fast DSL sont connectés à un noeud intermédiaire, qui dispose d’une connexion PON à l’ONU intermédiaire situé devant l’OLT.
Un réseau d’accès hybride connecte les lignes d’abonnés DSL à l’aide de nœuds d’accès PON et 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 du PON. Les abonnés G.fast sont associés à l’ONU intermédiaire comme un abonné PON natif. Les nouveaux TLV de type DSL sont pris en charge par l’AN et leurs valeurs sont indiquées dans le Port-Up ANCP pour 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 modélisation 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 de l’identifiant de protocole de balise VLAN pour les abonnés L2BSA afin de conserver deux profils dynamiques distincts, un pour TPID - 0x88a8 et un pour 0x8100, et de sourcer la valeur souhaitée en renvoyant 4874-26-174 (Client-Profile-Name) dans le champ Access-Accept.
Les valeurs de type supplémentaires suivantes pour le TLV de type DSL sont prises en charge. Tous les abonnés incluent ces TLV de type DSL dans les balises PPPoE PADR IA des messages PPPoE.
(8) G.rapide
(9) VDSL2 Annexe Q
(10) Cautionnement SDSL
(11) VDSL2 collé
(12) G, lié rapidement
(13) VDSL2 Annexe Q collé
Détection des identificateurs de ligne de backhaul et génération automatique d’ensembles d’interfaces de nuds intermédiaires
Avant de commencer, vous devez vérifier 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 aux IA PPPoE globalement. Le caractère principal # 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 qu’il détecte un nud intermédiaire logique dans un réseau d’accès. Le nœud identifie les abonnés qui sont connectés au même support partagé, tel qu’une arborescence PON ou une ligne en cuivre lié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) qui est reçu soit dans le message ANCP Port Up, soit dans les balises IA PPPoE PAMR. Si la chaîne TLV commence par le # caractère, il s’agit d’un identificateur de ligne de backhaul 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’interface dynamique définie pour le nœud CoS de niveau 2 qui regroupe les abonnés utilisant ce nœud intermédiaire. Cet ensemble d’interfaces est connu sous le nom d’ensemble d’interfaces parents. Chaque interface logique PPPoE ou VLAN (L2BSA) ayant la même valeur pour TLV 0x03 est membre de cet ensemble d’interfaces.
La valeur TLV doit correspondre aux exigences relatives à la dénomination des jeux 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 $junos-aggregation-interface-set-name dans le profil dynamique. Cette valeur est utilisée comme nom d’un ensemble d’interfaces CoS de niveau 2 qui regroupe les abonnés partageant cette chaîne. Il remplace la variable prédéfinie default, qui utilise la valeur de $junos-phy-ifd-interface-set-name comme nom de l’ensemble 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 de l’ensemble d’interfaces) devient TEST-DPU-C-100.
L’Access-Loop-Remote-ID (TLV (0x02) est analysé 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 des nœuds intermédiaires n’est prise en charge que pour les hiérarchies de planificateurs à 4 niveaux, de sorte que l’accès professionnel est limité aux MPC d’accès DSL conventionnels.
Pour activer l’analyse du TLV Access-Aggregation-Circuit-ID-ASCII et définir le nom de l’ensemble 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 $junos-aggregation-interface-set-name.
Le nom de l’ensemble 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 de l’ensemble d’interfaces de planificateur de niveau 2 est déterminé comme suit :
Lorsque TLV 0x03 commence par
#, alors $junos-aggregation-interface-set-name est le reste de la chaîne, à l’exclusion de l’initiale#.Lorsque TLV 0x03 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;
}
}
}
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plate-forme et la version que vous utilisez. Utilisez l’Explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.