Présentation du réseau d’accès abonné haut débit
Présentation du réseau d’accès abonné
Un environnement d’accès d’abonné peut inclure divers composants, notamment des technologies d’accès d’abonné et des protocoles d’authentification.
Les technologies d’accès pour les 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 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.
abonné
Cette fonctionnalité nécessite une licence. Pour en savoir plus sur les licences d’accès abonné, consultez Vue d’ensemble des licences d’accès abonné. Veuillez vous référer au Guide des licences de Juniper pour obtenir des informations générales sur la gestion des licences. Pour plus de détails, reportez-vous aux fiches techniques des produits chez MX Series Routers ou contactez votre équipe de compte Juniper ou votre partenaire Juniper.
L2-BSA (Layer 2 Bitstream Access) vous permet de fournir des services d’accès à haut débit de couche 2, ce qui permet aux fournisseurs de services réseau (NSP) de réaliser une vente en gros efficace du trafic des abonnés. Cette fonctionnalité prend en charge la création et le transfert de VLAN dynamiques via des interfaces pseudowire VPLS ou à connexion directe.
Les mécanismes L2-BSA en ligne et hors bande utilisent des messages ANCP pour la gestion dynamique des VLAN. L’autorisation basée sur RADIUS pour les processus de vente en gros d’abonnés et la gestion des flux de paquets garantissent une livraison précise et efficace du trafic.
La couche L2-BSA en ligne utilise des VLAN à détection automatique, où les paquets sont initialement exclus du moteur de routage pour une autorisation facultative et la création de VLAN dynamiques. Cela garantit un traitement efficace et une implication minimale du moteur de routage une fois que le VLAN est opérationnel. À l’inverse, la technologie L2-BSA hors bande étend le mécanisme VLAN à détection automatique à l’aide de messages ANCP pour la détection et la création de VLAN, fournissant des déclencheurs hors bande pour une gestion dynamique qui améliore l’évolutivité et la flexibilité de vos services réseau.
Le processus de vente en gros abonné utilise une autorisation d’accès abonné basée sur le RADIUS, créant dynamiquement des VLAN et les mappant à des interfaces centrales en fonction de la répartition pondérée de la charge. Ce processus garantit une livraison précise et efficace du trafic des abonnés, avec des mécanismes de flux de paquets détaillés, y compris l’échange de balises VLAN et la mise à jour de la table de transfert d’adresses MAC. Ces fonctionnalités facilitent le maintien d’une qualité de service élevée grâce à des mesures de sécurité réseau qui atténuent les attaques DoS, garantissant ainsi une prestation de services stable et continue.
Service d’accès au flux binaire de couche 2 (L2-BSA) sur les cartes de ligne nouvelle génération (MX304-LMIC16 sur MX304, MPC10E-10C et MPC10E-15C sur MX960, MX10004, MX10008 et MX10016)
Prise en charge du service d’accès au flux binaire de couche 2 (L2-BSA) sur les cartes de ligne AFT, MX304-LMIC16 sur MX304 et dans les équipements MX Series avec les cartes d’interface MPC Trio, MPC10E-10C et MPC10E-15C sur MX960, MX10004, MX10008 et MX10016 qui comprend la prise en charge de :
- L2-BSA en ligne.
- Hors bande L2-BSA.
- Augmentation des abonnés L2BSA.
- Réduction des abonnés L2BSA.
- Flux de paquets en amont.
- Flux de paquets en aval.
- Les fournisseurs de services peuvent désormais fournir une prise en charge de VDSL2 à une vitesse DSL de 100 Mbit/s avec un service d’accès au flux binaire de couche 2 (L2-BSA) pour les partenaires NSP (fournisseurs de services réseau).
Présentation des nœuds d’accès multiservices
Un nœud d’accès multiservice est un terme plus large qui fait référence à un groupe d’appareils d’agrégation couramment utilisés. Ces dispositifs comprennent les multiplexeurs d’accès de ligne d’abonné numérique (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 MSAN modernes prennent souvent en charge toutes ces connexions, ainsi que des connexions pour des circuits supplémentaires tels que le service téléphonique ordinaire (appelé POTS) ou le signal numérique 1 (DS1 ou T1).
La fonction principale d’un nœud d’accès multiservice est d’agréger le trafic provenant de plusieurs abonnés. Au niveau physique, le MSAN convertit également le trafic de la technologie du dernier kilomètre (par exemple, ADSL) en Ethernet pour le livrer aux abonnés.
Vous pouvez catégoriser 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 (bien qu’il ne fonctionne généralement pas) avec quelques améliorations pertinentes. Ces MSAN utilisent la commutation Ethernet (ou ATM) pour transférer le trafic. Le MSAN transfère tout abonné trafic en amont vers un routeur de périphérie qui agit comme un point de contrôle centralisé et empêche toute communication directe abonné-abonné. L’agrégation de liens Ethernet (LAG) fournit la résilience dans 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 canaux IPTV.
-
Layer–3 aware MSAN: ce MSAN sensible IP peut interpréter les demandes IGMP et y répondre en répliquant localement un flux de multicast et en le transmettant à tout abonné qui en fait la demande. Il est important de reconnaître la couche 3 lorsque vous prenez en charge le trafic IPTV pour effectuer des changements de canal (parfois appelés zaps de canal). Les MSAN statiques compatibles IP reçoivent toujours toutes les chaînes de télévision multicast. Ils n’ont pas la capacité de demander que des canaux spécifiques soient transmis au DSLAM. Toutefois, les DSLAM dynamiques orientés IP peuvent demander au 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 des fonctionnalités 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, améliorant ainsi la résilience du réseau. Toutefois, pour atteindre ce niveau de résilience, vous devez affecter 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 :
de MSAN
Options d’agrégation Ethernet MSAN
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 |
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 principal (l’équipement 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 de services haut débit. S’il existe un central intermédiaire, le trafic de plusieurs MSAN peut être combiné sur une connexion unique à l’aide du multiplexage par répartition par onde (WDM). Vous pouvez également connecter le MSAN à un routeur de services vidéo. Toutefois, cette méthode de connexion nécessite que vous utilisiez un 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 à 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 d’abonnés multiedge.
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 du 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 aux services routeur (services haut débit routeur ou services vidéo routeur en option).
Lorsque vous utilisez la méthode de connexion du commutateur d’agrégation Ethernet, gardez à l’esprit les points suivants :
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 de MSAN à faible vitesse (par exemple, 1 Gbit/s) vers une connexion à plus grande vitesse 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 des scénarios de couche 2, reportez-vous au Guide de l’utilisateur de 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 central (COT) en tête de réseau. Le COT se connecte alors directement aux services routeur (services haut débit routeur ou services vidéo routeur).
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 des scénarios de couche 2, reportez-vous au Guide de l’utilisateur de mise en réseau Ethernet pour les routeurs MX Series.
Présentation de la détection automatique de pseudowire LDP
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, une extrémité d’un pseudowire se termine en tant que circuit de couche 2 sur un nœud d’accès, et l’autre extrémité se termine 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 de 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 pseudowires à 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 du point de terminaison pseudowire, y compris le circuit de couche 2.
- Contexte de la terminaison d’entrée Pseudowire
- Approche de détection automatique par pseudowire
- Exemple de configuration
Contexte de la terminaison d’entrée Pseudowire
Dans un réseau d’accès haut débit ou de périphérie d’entreprise compatible MPLS transparent, les pseudowires Ethernet sont couramment utilisés comme interfaces virtuelles pour connecter les nœuds d’accès aux nœuds de service. Chaque pseudowire achemine le trafic bidirectionnel d’un ou 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. L’établissement du pseudowire est généralement initié par le nœud d’accès, en fonction 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 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 est qu’il y ait un pseudowire par port client (S-VLAN) et que tous les abonnés ou clients partageant un S-VLAN commun sur ce port soient 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é jusqu’au nœud de service. Les abonnés ou clients individuels peuvent être distingués par un C-VLAN, ou par un en-tête de couche 2 tel que DHCP et PPP, qui sera transporté sous forme de pseudowire jusqu’au nœud de service. Sur le nœud de service, le pseudowire est terminé. Les abonnés ou clients individuels sont ensuite démultiplexés et modélisés en tant qu’interfaces d’abonné haut débit, interfaces de périphérie d’entreprise (par exemple, PPPoE), interfaces Ethernet ou interfaces IP. Des interfaces Ethernet et IP peuvent être attachées à des instances de service, telles que les instances VPLS et VPN de couche 3.
Dans Junos OS, la terminaison entrante 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 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 un 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 active la signalisation pseudowire vers le nœud d’accès, et l’interface logique ps.0 joue le rôle d’interface orientée client pour le pseudowire. De plus, 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é/client 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 à des instances VPN de couche 2 ou 3.
Notez que le but du moteur de transfert de paquets d’ancre 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 multiplexeur ou le 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 pseudowire, des interfaces logiques du service pseudowire, des circuits de couche 2 et des VPN de couche 2 pour la terminaison entrante 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 en provisionnant et en déprovisionnant la terminaison entrante pseudowire sur les nœuds de service.
Approche de détection automatique par pseudowire
Dans l’approche de détection automatique par pseudofil, un nœud de service utilise le message de mappage d’étiquette 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 pseudowire, d’une interface logique de service pseudowire ou d’un circuit de couche 2. De même, il utilise l’étiquette LDP retirer le message 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 l’autodétection pseudowire, 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 service pour redondance ou équilibrage de charge, cela fournit également aux nœuds d’accès un modèle de sélection et de connexion pour l’établissement du service. Le flux de contrôle de base de l’autodétection par pseudowire est illustré à la figure 3
automatique par pseudowire
La procédure de contrôle de base de l’autodétection pseudowire est la suivante :
L’équipement sur le site client (CPE) 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 pseudowire au nœud de service par le biais d’un message de mappage d’étiquette 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 ou logique d’un service pseudowire.
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 de service pseudowire sélectionnée. Le nœud de service crée une configuration de circuit de couche 2, les informations pseudowire et l’interface physique ou logique du service 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’étiquette LDP. Le pseudowire apparaît dans les deux sens.
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 existent déjà 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 des services de couche 2 sur pseudowire
L’interface logique de service pseudowire prend en charge l’interface logique de transport (psn.0) du 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 LAN privé virtuel (VPLS). Il existe un circuit de couche 2 ou le VPN de couche 2 à travers 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 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 de l’équipement 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 permet également d’activer des fonctionnalités d’entrée de couche 2 telles que l’apprentissage MAC, les manipulations de VLAN et la recherche MAC de destination sur le service pseudowire sur les interfaces logiques de service.
Lorsque le trafic est en 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 comme MAC source sur le service pseudowire sur les interfaces logiques de service. À partir de la version 17.1R1 de Junos OS, les interfaces de tunnel logique pseudowire prennent en charge les VPLS Ethernet, les ponts Ethernet, les VPLS VLAN et l’encapsulation de pont VLAN sur les sauts suivants 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 de 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 équipements de périphérie de service sur le domaine d’accès MPLS.
Avec 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 le MPLS
- Trafic de la périphérie de services au LAN client
- Pseudowire Service Interfaces
- Exemple de configuration
Trafic du LAN client vers le MPLS
Les instances VPLS-x et VPLS-y sont configurées sur le côté central MPLS de l’équipement de périphérie de services (PE A). Un circuit de couche 2 ou un VPN de couche 2 est configuré entre l’équipement d’agrégation Ethernet (EAD 1) et l’équipement 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 au niveau de 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 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 le PE A (sur un circuit de couche 2 ou un VPN de couche 2) avec n’importe quel ID de VLAN, le trafic sort par ps0.0. En fonction de l’ID de VLAN dans le trafic, l’interface logique du service pseudowire sur le service est sélectionnée. Par exemple, si l’ID VLAN est m, le trafic entrera dans ps0.x et si l’ID VLAN est n, le trafic entrera dans ps0.y.
logique de service
Lorsque le trafic entre dans le service pseudowire sur l’interface logique de 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 sur 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 du côté de l’entrée en tant que liste de fonctionnalités de la famille de ponts d’entrée des services 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 multicast 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 nouveau 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 au 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 du 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 du côté de l’entrée. Le trafic est ensuite envoyé au moteur de transfert de paquets sur lequel l’interface tunnel logique de l’interface physique du service pseudowire est ancrée dans une fabric. Lorsque ce jeton est lancé, il prend en charge les encapsulations VLAN VPLS, VLAN Bridge, Ethernet VPLS et Ethernet Bridge. Le saut suivant de l’encapsulation pointe vers la liste des fonctionnalités d’interface logique de sortie du service pseudowire sur l’interface logique de service afin d’exécuter toutes les fonctionnalités de sortie de couche 2 et d’envoyer le paquet à l’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 de service vu après la recherche MAC de destination pour le MAC appris sur le service pseudowire sur l’interface logique de service doit pointer vers le saut suivant associé au côté accès du service pseudowire sur le service, l’interface logique.
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é à l’équipement 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 du côté entrée et sortant du périphérique de périphérie de service est inconnu ou s’il s’agit d’un multicast ou d’une diffusion, le trafic doit être inondé. Cela nécessite qu’un équipement de périphérie client floode le saut suivant pour inclure le service pseudowire sur l’interface logique de 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 d’abonné sur une interface logique est basé sur l’ID de VLAN disponible.
Le transfert de trafic d’un service pseudowire d’abonné sur une interface logique vers un service pseudowire de transport sur une interface logique est basé sur l’ID 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 sur une interface trunk pour mettre fin à 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 VRF VRF VPN de couche 3 utilisant également 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 équipement 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 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 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 haut débit
Il existe actuellement quatre principales options de fourniture de services de réseau haut débit. Ces options sont les suivantes :
Ligne d’abonné numérique
La ligne d’abonné numérique (DSL) est la technologie haut débit 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 des versions de ligne d’abonné numérique asymétrique (ADSL, ADSL2 et ADSL2+). Ces variantes de la LAN offrent principalement un service haut débit résidentiel 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 High bit Rate Digital Subscriber Line (HDSL) et Symmetric Digital Subscriber Line (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. Active Ethernet ne fournit pas de canal séparé pour le service vocal existant, un équipement VoIP (ou TDM-vers-VoIP) est donc nécessaire. De plus, l’envoi Ethernet à pleine vitesse (10 ou 100 Mbit/s) nécessite une alimentation importante, ce qui nécessite une distribution sur 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 d’Active Ethernet apparaissent généralement dans des zones densément peuplées.
Réseaux optiques passifs
Les réseaux optiques passifs (PON), comme Active Ethernet, utilisent des câbles à fibre optique pour fournir des services sur site. Cette option de livraison offre des vitesses supérieures à celles de l’ADSL, mais inférieures à celles d’Active Ethernet. Bien que le PON offre une vitesse plus élevée à chaque abonné, il nécessite un investissement plus élevé en câble et en connectivité.
L’un des principaux avantages des PON est qu’ils ne nécessitent aucun équipement alimenté en dehors du siège social. Chaque fibre quittant le siège social est divisée à l’aide d’un répartiteur optique non alimenté. La fibre divisée suit ensuite une connexion point à point pour chaque abonné.
Les technologies PON se répartissent en trois grandes catégories :
PON ATM (APON), PON à large bande (BPON) et PON compatible Gigabit (GPON) : normes PON qui utilisent les différentes options de livraison suivantes :
APON : première norme de réseau optique passif, principalement utilisée pour les applications professionnelles.
BPON : basé sur APON, le BPON ajoute le multiplexage par répartition d’ondes (WDM), une allocation dynamique et plus élevée de la bande passante en amont et une interface de gestion standard pour activer les réseaux mixtes.
GPON : GPON est basé sur BPON mais prend en charge des débits plus élevés, une sécurité amélioré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 capacités similaires à GPON, BPON et APON, mais utilise des normes Ethernet. Ces normes sont définies par l’IEEE. Le PON Gigabit Ethernet (GEPON) est la version la plus rapide.
PON multiplexage par répartition d’ondes (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 un terminateur 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 haut débit via leur réseau hybride fibre-coaxial (HFC). Le réseau HFC combine fibre optique et câble coaxial pour fournir le service directement au client. Les services quittent le siège social (CO) à l’aide d’un câble à fibre optique. Le service est ensuite converti à l’extérieur du central en un arbre de câbles coaxiaux à l’aide d’une série de nœuds optiques et, si nécessaire, par un amplificateur de radiofréquence (RF) principal. 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 (STMC) à la tête de ligne ou à l’installation principale de l’OSM qui reçoit les signaux de télévision pour le traitement et la distribution. Le trafic haut débit est acheminé selon la norme DOCSIS (Data over Cable Service Interface Specification) définie par CableLabs et de nombreuses entreprises participantes.
Livraison haut débit et FTTx
De nombreuses implémentations utilisent un câblage en cuivre existant pour fournir le 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 « fiber to the x » (FTTx) décrit la distance parcourue par le câblage en fibre optique dans le réseau avant qu’un passage au câblage en cuivre n’ait lieu. Le PON et Active Ethernet peuvent tous deux utiliser la partie fibre optique du réseau, tandis que le 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’utilisation accrue de la fibre 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’au site (FTTP), fibre jusqu’au domicile (FTTH), fibre jusqu’à l’entreprise (FTTB) : la fibre s’étend jusqu’à l’abonné. Le PON est le plus souvent utilisé pour l’accès résidentiel, bien qu’Active Ethernet puisse être utilisé efficacement dans des 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 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 dans un siège 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 de 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 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 jusqu’au bâtiment (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 jusqu’au bâtiment (CTTB) DSL collé
À partir de la version 18.2R1 de Junos OS, 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 l’implémentation ANCP (Access Node Data Control Protocol) pour gérer la configuration réseau pour les clients résidentiels qui utilisent un PON comme technologie d’accès haut débit à la fois pour CuTTB et FTTB. 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 LAN sont fournis pour appuyer l’ajustement du débit de la ligne d’accès pour les nouvelles technologies d’accès.
Un nouveau VSA RADIUS, Inner-Tag-Protocol-Id 26-211, est introduit pour récupérer la valeur interne de l’identifiant de protocole de balise VLAN pour les abonnés L2BSA afin de permettre la gestion 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 des mappages inner-tag-protocol-id VLAN en fonction de RADIUS ou d’une valeur par défaut prédéfinie fournie dans la configuration.
- Avantages des déploiements DSLAM en cascade sur les canaux DSL liés
- Hiérarchie du planificateur à 4 niveaux
- Cas d’usage des déploiements DSLAM en cascade sur des canaux DSL liés
- DSL collé pour CuTTB (Copper-To-The-Building)
- PON hybride + G.fast
- Fonctionnalités prises en charge
Avantages des déploiements DSLAM en cascade sur les canaux DSL liés
Cette fonctionnalité est utile pour prendre en charge les déploiements de réseaux d’accès dans lesquels plusieurs abonnés partagent la même ligne d’accès agliée par un nœud intermédiaire entre le nœud d’accès et les passerelles de routage d’origine. Un autre avantage est la conservation des nœuds CoS de couche 2. En général, un nœud fictif de couche 2 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 la hiérarchie de planificateur QoS à 4 niveaux et prend en charge de manière minimale l’accès résidentiel et L2BSA sur des déploiements de réseaux d’accès cuivre (CTTB) ou fibre optique jusqu’au bâtiment. 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 (ensemble d’interfaces logiques, ensemble d’abonnés partageant une ligne d’accès donnée, agrégé 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, les accès résidentiels et L2BSA ne nécessitent qu’une hiérarchie de planificateur à 4 niveaux. L’accès des abonnés professionnels n’est actuellement pas pris en charge. Par conséquent, une hiérarchie de planificateur à 4 niveaux est suffisante pour les services CuTTB et PON ciblant un immeuble d’appartements.
Cas d’usage des déploiements DSLAM en cascade sur des canaux DSL liés
Le protocole DSL collé pour le cuivre jusqu’au bâtiment (CuTTB) introduit un nœud intermédiaire DPU-C (Distribution Point Unit-Copper) 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ées peuvent être de type réseau optique passif (PON) ou de lignes cuivre DSL liées. Des exemples de nœuds intermédiaires sont répertoriés ci-dessous :
-
DPU-C : DSL collé pour le cuivre jusqu’au bâtiment (CTTB)
-
ONU - PON (Fiber-to-the-Building (FTTB)
-
PON hybride et G.Fast
DSL collé pour CuTTB (Copper-To-The-Building)
liés
Sur la Figure 6, chaque DPU-C dispose d’une session ANCP pour signaler les paramètres de ligne d’accès de chaque abonné connecté au nœud. Le MSAN organise également une session ANCP pour signaler au DPU-C les paramètres de la ligne d’accès DSL liée. Tous les abonnés connectés au DPU-C sont donc soumis au débit en aval de la ligne d’accès DSL, 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 pour le ste d’interface correspondant 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 consiste en un hybride d’accès DSL sous douane et d’accès conventionnel sans douane. 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 des proxys pour tous les nœuds PON natifs en aval. Les abonnés DSL G.fast sont connectés à un nœud intermédiaire, qui a une connexion PON à l’ONU intermédiaire devant l’OLT.
Un réseau d’accès hybride connecte des 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 branche PON. La mise en forme est requise à la fois au niveau de l’abonné et au niveau de la branche 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 de la ligne d’accès des abonnés correspondants. Cependant, il n’est toujours pas possible de distinguer un nœud intermédiaire d’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 les iflsets dynamiques.
-
Préservation de l’indépendance PPP0E-IA et ANCP par configuration CLI pour les abonnés résidentiels.
-
Nouveau VSA Juniper, ERX-Inner-Vlan-Tag-Protocol-Id (4874-26-211) est pris en charge pour sourcer la valeur de l’identifiant de protocole de balise VLAN interne pour les abonnés L2BSA à titre d’optimisation afin de conserver deux profils dynamiques distincts, un pour TPID - 0x88a8 et un pour 0x8100, et d’obtenir la valeur souhaitée en renvoyant 4874-26-174 (Client-Profile-Name) dans l’accès-accept.
-
Les valeurs de type supplémentaires suivantes pour le type DSL TLV 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 lié
-
(11) VDSL2 sous douane
-
(12) G, collé rapidement
-
(13) VDSL2 Annexe Q sous douane
-
Détection des identifiants de ligne de backhaul et génération automatique d’ensembles 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. Comme 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 du monde entier. Le personnage 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 la version 18.4R1 de Junos OS, 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 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 dans le message ANCP Port Up ou les balises PPPoE PADR IA. Si la chaîne TLV commence par le # caractère, la chaîne est un identifiant 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 à ce PON.
La partie de la chaîne qui suit 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 à l’aide de ce nœud intermédiaire. Cet ensemble d’interfaces est appelé jeu d’interfaces parent. 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 ensembles 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 jeu 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 du jeu d’interfaces) devient TEST-DPU-C-100.
La TLV (0x02) de boucle d’accès (Access-Loop-Remote-ID) est également analysée pour le # caractère, mais la chaîne résultante n’est pas utilisée dans la version actuelle.
La détection de nœud intermédiaire n’est prise en charge que pour les hiérarchies de planificateur à 4 niveaux, de sorte que l’accès métier 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. Voici trois choses à noter :
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 du 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, $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 plateforme 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.