SUR CETTE PAGE
Redondance d’ancrage Présentation des interfaces logiques d’abonné Pseudowire
Configuration d’un périphérique d’interface logique d’abonné pseudowire
Modification du point d’ancrage d’un périphérique d’interface logique d’abonné pseudowire
Configuration de l’interface logique de transport pour une interface logique d’abonné Pseudowire
Configuration de l’interface logique de service pour une interface logique d’abonné pseudowire
Configuration de l’équilibrage de charge Prise en charge du trafic abonné
Interfaces logiques d’abonné MPLS Pseudowire
Présentation des interfaces logiques d’abonné Pseudowire
La gestion des abonnés prend en charge la création d’interfaces abonnés sur des pseudo-fils MPLS point à point. La fonctionnalité d’interface d’abonné pseudowire permet aux fournisseurs de services d’étendre un domaine MPLS du réseau d’agrégation d’accès à la périphérie de service, où la gestion des abonnés est effectuée. Les fournisseurs de services peuvent tirer parti des fonctionnalités MPLS telles que le basculement, le réacheminement et le provisionnement uniforme d’étiquettes MPLS, tout en utilisant un seul pseudowire pour desservir un grand nombre d’abonnés DHCP et PPPoE dans le réseau de service.
Les interfaces logiques d’abonné Pseudowire sont prises en charge uniquement sur les concentrateurs de ports modulaires (MPC) avec des cartes d’interface modulaires (MIC) Ethernet. La terminaison PPPoE et L2TP n’est pas prise en charge lorsque l’encapsulation VPLS et l’authentification DHCP sont utilisées pour l’interface logique de transport. Toutefois, l’encapsulation VPLS permet de gérer les abonnés haut débit de couche 2 en gros. Une interface VLAN dynamique est créée avec l’encapsulation VPLS sur un routeur wholesale, qui effectue la commutation d’étiquette VLAN pour terminer les abonnés PPPoE/DHCP sur le réseau du détaillant. Pour plus d’informations, reportez-vous à la section Gestion des abonnés haut débit de niveau 2 : topologie de gros et éléments de configuration.
Le pseudowire est un tunnel qui est soit un VPN de couche 2 basé sur MPLS, soit un circuit de couche 2. Le tunnel pseudowire achemine le trafic encapsulé Ethernet depuis un nœud d’accès (par exemple, un DSLAM ou un autre équipement d’agrégation) vers le routeur MX Series qui héberge les services de gestion des abonnés. La terminaison du tunnel pseudowire sur le routeur MX Series est similaire à une terminaison Ethernet physique et correspond au point auquel les fonctions de gestion des abonnés sont exécutées. Un fournisseur de services peut configurer plusieurs pseudowires par DSLAM, puis fournir la prise en charge d’un grand nombre d’abonnés sur un pseudowire spécifique.
La figure 1 illustre un réseau MPLS qui prend en charge la gestion des abonnés.
À l’extrémité du nœud d’accès du pseudofil, le trafic abonné peut être préparé dans le pseudofil de différentes manières, limité uniquement par le nombre et les types d’interfaces qui peuvent être empilées sur le pseudofil. Vous spécifiez un point d’ancrage, qui identifie l’interface de tunnel logique qui termine le tunnel pseudowire au niveau du nœud d’accès.
de la gestion des abonnés
La figure 2 montre la pile de protocoles d’une interface logique d’abonné pseudowire. Le pseudowire est un équipement virtuel qui est empilé au-dessus du point d’ancrage du tunnel logique sur l’interface physique (l’IFD) et prend en charge un protocole de couche 2 orienté circuit (VPN de couche 2 ou circuit de couche 2). Le protocole de couche 2 fournit les interfaces logiques de transport et de service et prend en charge la famille de protocoles (IPv4, IPv6 ou PPPoE).
À partir de la version 18.3R1 de Junos OS, sur les routeurs MX Series dotés d’interfaces MPC et MIC, la prise en charge de l’interface de service d’abonné pseudowire sur des tunnels logiques redondants est introduite dans les VPN de couche 3 et les VPN multicast draft-rosen. Auparavant, les VPN de couche 3 prenaient en charge les services d’abonnés pseudowire uniquement sur des interfaces de tunnel logiques, et ces interfaces utilisaient des protocoles de routage unicast. comme OSPF ou BGP. Avec cette prise en charge, vous pouvez provisionner un protocole de routage multicast, PIM (Protocol Independent Multicast), sur les interfaces d’abonnés pseudowire, qui est terminé sur l’instance de routage VRF (Virtual Routing and Forwarding). En outre, le nombre de mises à l’échelle des périphériques d’interface logique pseudowire augmente afin d’offrir une prise en charge supplémentaire de la résilience des interfaces abonné pseudowire sur les interfaces de tunnel logique redondantes.
Lorsqu’une interface de service d’abonné pseudowire est ancrée à un tunnel logique redondant dont l’interface membre (ou FPC) n’existe pas, l’interface du tunnel tombe en panne. Dans ce cas, les interfaces pseudowire (physiques et logiques) doivent également être inactives, mais l’état de l’interface logique de l’abonné pseudowire reste actif, bien que les services de circuit de couche 2, tels que la commande ping vers un périphérique CE (Customer Edge) à partir du côté service de l’interface de service d’abonné pseudowire, ne soient pas disponibles.
Cela est dû au fait que le côté transport de l’interface logique de l’abonné pseudowire reste actif, ce qui entraîne le fonctionnement des services.
La configuration pseudowire est transparente pour les applications de gestion des abonnés et n’a aucun impact sur les charges utiles de paquets utilisées pour la gestion des abonnés. Les applications abonnées telles que DHCP et PPPoE peuvent être empilées sur la couche 2 de la même manière qu’elles le sont sur une interface physique.
À partir de la version 16.1R1 de Junos OS, family inet et family inet6 sont pris en charge du côté des services d’une interface logique MPLS pseudowire abonnée ainsi que non-abonnée.
À partir de la version 16.1R1 de Junos OS, IPFIX en ligne est pris en charge côté services d’une interface logique d’abonné MPLS pseudowire.
À partir de Junos OS version 15.1R3 et 16.1R1 et versions ultérieures, l’encapsulation CCC est prise en charge côté transport d’une interface logique d’abonné MPLS pseudowire.
Avant Junos OS version 19.1R1, les seuls types d’encapsulation pris en charge sur les interfaces d’abonnés pseudowire comprenaient :
Interfaces logiques de transport : encapsulation CCC (Circuit Cross-Connect Connect).
Service logical interfaces:
Encapsulation VPLS Ethernet
Encapsulation de pont VLAN
Encapsulation VLAN VPLS
À partir de la version 19.1R1 de Junos OS, des encapsulations supplémentaires sont ajoutées aux interfaces logiques de transport et de service d’abonné pseudowire. L’interface logique de transport prend en charge l’encapsulation VPLS Ethernet et permet la terminaison de l’interface sur l’instance l2backhaul-vpn de routage. L’interface logique de service prend en charge l’encapsulation CCC (Circuit Cross-Connect) et permet la terminaison de l’interface sur des circuits de couche 2 commutés localement.
Avec la prise en charge de types d’encapsulation supplémentaires, vous pouvez bénéficier du démultiplexage d’un l2backhaul VPN dans plusieurs services VPN, tels que le circuit de couche 2 et le VPN de couche 3. Étant donné que les interfaces d’abonnés pseudowire sont ancrées sur des tunnels logiques redondants, cette amélioration fournit également une redondance de carte de ligne.
À partir de Junos OS version 15.1R3 et 16.1R1 et versions ultérieures, la protection contre le déni de service distribué (DDoS) est prise en charge côté services d’une interface logique d’abonné MPLS pseudowire.
À partir de Junos OS version 15.1R3 et 16.1R1 et versions ultérieures, Policer et Filter sont pris en charge du côté des services d’une interface logique d’abonné MPLS pseudowire.
À partir de Junos OS version 15.1R3 et 16.1R1 et versions ultérieures, des statistiques de transmission précises sur l’interface logique sont prises en charge du côté des services d’une interface logique d’abonné MPLS pseudowire.
À partir de Junos OS version 17.3R1 et versions ultérieures, la prise en charge de la redondance des points d’ancrage dynamiques est assurée pour l’interface logique de l’abonné pseudowire par l’interface de tunnel logique redondante (RLT) sous-jacente en mode de sauvegarde active. Cette redondance protège l’accès et la liaison principale contre la défaillance du PFE (moteur de transfert de paquets) d’ancrage.
Redondance d’ancrage Présentation des interfaces logiques d’abonné Pseudowire
Dans les déploiements de pseudowire MPLS qui utilisent des interfaces logiques d’abonnés pseudowire, la défaillance du moteur de transfert de paquets hébergeant le tunnel logique qui ancre ces interfaces logiques entraîne une perte de trafic et une perte de session d’abonné.
Le moteur de transfert de paquets ne s’appuie pas sur le plan de contrôle pour détecter les défaillances. Au lieu de cela, il utilise un mécanisme de détection de vivacité, avec un algorithme sous-jacent basé sur les pulsations, pour détecter la défaillance d’autres moteurs de transfert de paquets dans le système. La défaillance d’un moteur de transfert de paquets indique également la défaillance du tunnel logique hébergé, ce qui entraîne à terme la perte de session. Pour éviter cette perte de session, un point d’ancrage redondant est nécessaire vers lequel la session peut être déplacée sans perdre de trafic.
À partir de la version 17.3 de Junos OS, les interfaces logiques d’abonnés pseudowire peuvent être instanciées sur une interface de tunnel logique redondante (RLT) sous-jacente en mode de sauvegarde active. Cela s’ajoute à l’installation de pseudowires sur une seule interface de tunnel logique. L’avantage le plus notable de l’implémentation de l’interface logique d’abonné pseudowire par rapport aux interfaces de tunnel logique redondantes est de fournir une redondance du chemin de transfert sous-jacent.
Avant la version 18.3R1 de Junos OS, vous pouviez spécifier un maximum de 2 048 périphériques d’interface de tunnel logique redondants d’abonnés pseudowire pour un routeur MX Series. À partir de la version 18.3R1 de Junos OS, sur les routeurs MX Series dotés d’interfaces MPC et MIC, le nombre de périphériques d’interface logique redondants pseudowire est passé à 7 000 équipements pour fournir une prise en charge supplémentaire de la résilience.
Junos OS version 17.3 prend également en charge une infrastructure agrégée améliorée pour un moteur de transfert de paquets afin d’assurer la redondance des points d’ancrage. Une infrastructure agrégée améliorée nécessite au moins une interface logique de contrôle qui doit être créée sur une interface de tunnel logique redondante. Les interfaces logiques de transport et de services créées pour l’interface logique de l’abonné pseudowire sont empilées sur l’interface logique de contrôle sous-jacente du tunnel logique redondant. Ce modèle d’empilage est utilisé pour les interfaces logiques d’abonnés pseudowire redondantes et non redondantes.
Les événements suivants doivent déclencher la suppression de l’interface physique d’un groupe redondant :
-
Défaillance matérielle sur le concentrateur PIC modulaire (MPC) ou la carte d’interfaces modulaires (MIC).
-
Défaillance MPC due à un plantage du micro-noyau.
-
MPC ou MIC mis hors ligne sur le plan administratif.
-
Panne de courant sur un MPC ou un MIC.
La Figure 3 fournit des détails sur l’empilement d’une interface logique d’abonné pseudowire sur une interface de tunnel logique redondante.
de tunnel logique redondante
Le service statique ifl n’est pas empilé sur le transport ifl lorsque RLT est utilisé.
Par défaut, la protection des liens pour les interfaces de tunnel redondantes est réactive. En cas de défaillance de la liaison active, le trafic est acheminé via la liaison de secours. Lorsque le lien actif est rétabli, le trafic est automatiquement redirigé vers le lien actif. Cela entraîne des pertes de trafic et des sessions d’abonnés.
Pour éviter les pertes de trafic et de session, vous pouvez configurer une protection de liaison non réversible pour les interfaces de tunnel redondantes à l’aide de l’instruction set interfaces rltX logical-tunnel-options link-protection non-revertivede configuration . Avec cette configuration, lorsque la liaison active est rétablie, le trafic n’est pas redirigé vers la liaison active et continue d’être transféré sur la liaison de secours. Par conséquent, il n’y a pas de perte de trafic ou de perte de session d’abonné. Vous pouvez également basculer manuellement le trafic du lien de sauvegarde vers le lien actif à l’aide de la request interface (revert | switchover) interface-name commande.
La commutation manuelle du trafic entraîne des pertes de trafic.
-
Une interface logique de contrôle est créée implicitement sur une interface de tunnel redondante avec la configuration de l’interface logique de l’abonné pseudowire et aucune configuration supplémentaire n’est donc nécessaire.
-
Une interface de tunnel logique redondante autorise 32 interfaces physiques de tunnel logique membres. Toutefois, une interface logique d’abonné pseudowire hébergée sur l’interface de tunnel logique redondante limite le nombre d’interfaces physiques de tunnel logique à deux.
Vous ne pouvez pas désactiver l’interface de tunnel logique redondant (rlt) sous-jacente ou l’interface de tunnel logique (lt) sous-jacente lorsqu’un pseudowire est ancré sur cette interface. Si vous souhaitez désactiver l’interface sous-jacente, vous devez d’abord désactiver le pseudofil.
À partir de la version 18.4R1 de Junos OS, la prise en charge de la distribution en ligne de sessions BFD (Bidirectional Forwarding Detection) à saut unique est étendue aux abonnés pseudowire sur des interfaces de tunnel logiques redondantes. Pour les interfaces pseudowire subscriber over logical tunnel, les interfaces sont ancrées sur un seul concentrateur PIC flexible (FPC). Par conséquent, la distribution en ligne des sessions BFD à saut unique est prise en charge par défaut. Avec les interfaces logiques redondantes pseudo-filaires, les interfaces de tunnel logique des membres peuvent être hébergées sur différentes cartes de ligne. Étant donné que l’adresse de distribution n’est pas disponible pour les interfaces logiques redondantes, la distribution des sessions BFD à saut unique était gérée de manière centralisée avant la version 18.4R1 de Junos OS.
Grâce à la prise en charge de la distribution en ligne de sessions BFD à saut unique sur des interfaces logiques redondantes pseudofilaires, il existe un avantage d’évolutivité allant jusqu’à 2 000 sessions BFD à un saut à un intervalle d’une seconde, et une amélioration du temps de détection améliorant les performances des sessions.
L’opération BFD pour l’abonné pseudowire sur des interfaces logiques redondantes est la suivante :
-
Lorsqu’une nouvelle session BFD est ajoutée, elle peut être ancrée sur un FPC actif ou de secours.
-
Lorsque l’un des FPC échoue ou redémarre, toutes les sessions hébergées sur ce FPC tombent en panne et un réancrage est déclenché pour la prochaine adresse de distribution disponible. Les sessions BFD sont réactivées une fois les sessions installées sur l’autre FPC et l’échange de paquets BFD est démarré.
Toutefois, il est également possible que les sessions sur le FPC de sauvegarde ne s’arrêtent pas en cas d’échec du FPC actif en fonction de l’heure de détection BFD configurée, car l’état de transfert du nouveau FPC actif peut prendre un certain temps à être programmé.
-
En cas de défaillance du FPC actif, toutes les sessions BFD sont ancrées sur le FPC de secours. De même, en cas de défaillance du FPC de sauvegarde, toutes les sessions BFD sont ancrées sur le FPC actif.
-
Le réancrage de session BFD n’est pas déclenché lorsque le FPC actif est à nouveau en ligne.
-
Lorsque le comportement non précédent est activé, lorsque le FPC précédemment actif est à nouveau en ligne, les sessions ne sont pas censées s’interrompre. Avec le comportement de retour par défaut, il est possible que l’état de transfert doive être mis à jour et, en fonction de la configuration de l’heure de détection, la session peut ou non vaciller.
Pour la distribution en ligne de sessions BFD à saut unique sur un abonné pseudowire via des interfaces de tunnel logiques, tenez compte des éléments suivants :
-
Sur le FPC de type MPC 7e, avec l’activation de l’instance de routage 7000, il faut environ six minutes pour que les sessions 7000 BGP s’établissent sur les interfaces d’abonnés pseudowire ancrées sur des interfaces de tunnel logique redondantes.
-
Un nouveau message d’erreur du journal système -
JTASK_SCHED_SLIP- est enregistré lors du routage actif ininterrompu (NSR). Il s’agit d’un comportement attendu de NSR à grande échelle qui peut être ignoré en toute sécurité, sauf s’il existe d’autres problèmes, tels que des problèmes de session, qui nécessitent que des mesures soient prises.
À partir de la version 21.4R1 de Junos OS, nous avons introduit la prise en charge CoS d'un BNG sur l'interface abonné sur pseudowire sur une interface RLT (active-active redundant logical tunnel) pour les applications abonnés telles que DHCP et PPPoE. Cette propriété CoS est obtenue en fournissant les nœuds de planification pour les liaisons de tunnel logique. Pour les interfaces dynamiques, les ensembles d’interfaces, les interfaces sous-jacentes statiques et les interfaces sous-jacentes dynamiques sur RLT, CoS alloue des nœuds de planification pour chaque liaison du RLT, qui comporte plusieurs liaisons de tunnel logique en mode actif-actif. Dans le cas d’interfaces ciblées et d’ensembles d’interfaces ciblés, qui ont des liens principaux et de secours, CoS alloue des noeuds de planification sur les liens principaux et de secours afin d’optimiser l’utilisation des noeuds de planification. Le trafic pour les interfaces ciblées par l’abonné sera distribué à toutes les liaisons LT primaires lorsque le CoS est appliqué au niveau de l’abonné. De plus, le trafic provenant d’un abonné donné est toujours traité par le même moteur de transfert de paquets.
La Figure 4 fournit les détails des interfaces parent et enfant utilisées pour la hiérarchie du planificateur à quatre niveaux pour l’accès des abonnés. L’IFL PPPoE dynamique et l’IFL-set dynamique sont des nœuds enfants. Le noeud svlan dynamique IFL-set et le noeud uifl dynamique ou statique sont des noeuds parents.
des abonnés
Lorsque vous activez le ciblage dans un nœud, vous devez activer le ciblage pour tous les nœuds enfants pour que CoS fonctionne correctement. Pour activer les noeuds enfants, configurez le profil dynamique au niveau . [edit interfaces ps1 auto-configure stacked-vlan-ranges dynamic-profile] Créez un profil dynamique en configurant des interfaces et des ensembles d’interfaces ciblés dynamiques à l’adresse [modifier les profils dynamiques].
Voici un exemple de configuration de profil dynamique :
dvlanProf {
interfaces {
"$junos-interface-ifd-name" {
unit "$junos-interface-unit" {
demux-source [ inet inet6 ];
no-traps;
proxy-arp;
vlan-tags outer "$junos-stacked-vlan-id" inner "$junos-vlan-id";
targeted-distribution;
family inet {
unnumbered-address lo0.0 preferred-source-address 100.0.0.1;
}
family inet6 {
unnumbered-address lo0.0 preferred-source-address 1000:0::1;
}
family pppoe {
duplicate-protection;
dynamic-profile pppoeClientSvlanSetVar;
}
}
}
}
}
pppoeClientSvlanSetVar {
interfaces {
interface-set "$junos-svlan-interface-set-name" {
targeted-distribution;
interface pp0 {
unit "$junos-interface-unit";
}
}
pp0 {
unit "$junos-interface-unit" {
actual-transit-statistics;
ppp-options {
pap;
}
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
targeted-distribution;
keepalives interval 30;
family inet {
unnumbered-address "$junos-loopback-interface";
}
}
}
}
}
De plus, vous devez configurer les services enhanced-ip réseau au niveau de la [edit chassis] hiérarchie, car cette fonctionnalité ne fonctionne qu’en mode IP amélioré.
Le mode de liaison multiple actif-actif avec ciblage utilise les algorithmes de ciblage de l’interface RLT pour répartir les clients entre les différents membres RLT (paires de jambes primaires/secondaires). Le ciblage peut être appliqué aux abonnés dynamiques et aux ensembles d’interfaces dynamiques. L’algorithme de ciblage passe en revue la liste des pseudo-IFL associés à la paire de liens membres et sélectionne le premier pseudo-IFL qui a une capacité suffisante en fonction du fichier .rebalance-subscriber-granularity
Lorsque le ciblage est activé, une pondération de ciblage par défaut est attribuée à l’abonné en fonction du type de client. L’algorithme de ciblage utilise le poids d’allocation dans le processus de sélection du pseudo-IFL et le poids de débit de l’IFL est le poids compté par rapport au pseudo-IFL attribué. Pour tous les objets, à l’exception de l’IFLset, l’allocation et le poids de débit sont les mêmes et vous pouvez les modifier via le profil client. Dans le cas de l’IFLset, seul l’attribut de pondération de l’allocation peut être modifié via le profil du client, et la pondération de débit de l’IFLset est fixée à une valeur de 0.
| Client Type |
Pondération de l’allocation |
Poids débiteur |
|---|---|---|
| Dvlan |
1 |
1 |
| IpDemux |
1 |
1 |
| PPP |
1 |
1 |
| IFLset |
32 |
0 |
PWHT pour les équipements ACX
Pour les équipements ACX utilisant le mode BNG CUPS pour la gestion des abonnés, PWHT termine le contrôle MPLS pseudowire et transfère les paquets de données vers leur destination à l’aide du protocole IP standard.
Les fonctions Pseudowire et PWHT (pseudowire headend termination) sur les équipements ACX qui prennent en charge cette fonctionnalité nécessitent que l’équipement fonctionne en mode BNG CUPS. En mode CUPS, le plan de contrôle est exécuté à partir d’un cloud centralisé, tandis que le plan utilisateur s’exécute sur l’appareil. Toutes les fonctionnalités pseudowire et PWHT sont à votre disposition en mode BNG CUPS. Consultez le guide de l’utilisateur BNG CUPS pour plus de détails sur la configuration de votre appareil en mode CUPS.
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.
Le PWHT est utilisé pour terminer le contrôle des pseudowire MPLS au niveau du routeur Provider Edge du fournisseur de services. À la sortie du pseudofil, les informations de contrôle (messages de signalisation PPPoE ou DHCP) sont transmises au plan de contrôle centralisé, tandis que les données ordinaires sont transmises à leur destination sous forme de paquets IP standard.
Pour configurer PWHT sur votre équipement ACX, celui-ci doit d’abord être configuré pour le mode CUPS. Pour plus d’informations, reportez-vous aux sections Configuration du contrôleur BNG CUPS et Configuration des plans utilisateur BNG .
La configuration PWHT s’effectue dans le plan utilisateur (votre équipement) plutôt que dans le plan de contrôle (cloud). Cela est dû au fait que les interfaces de tunnel logique (lt) et de pseudowire (ps) doivent être créées à l’intérieur du plan utilisateur dans Junos OS Evolved. Les commandes pour configurer vos interfaces lt et ps sont les mêmes que dans Junos OS ; cependant, les équipements ACX nécessitent les numéros d’emplacement et de cœur de l’ancre PWHT dans la configuration. Les équipements ACX nécessitent également que vous configuriez manuellement votre réservation de bande passante.
Contrairement à Junos OS, les interfaces LT sont créées en fonction du numéro FPC ou FEB, du numéro PFE, du numéro de cœur et du canal sélectionnés lors de la commande de configuration. Cet emplacement n’est pas basé sur la bande passante. Dans les exemples suivants, l’IFD LT serait lt-0/0/0:0. Si une autre interface LT était requise dans ce même emplacement, elle se trouverait sur un canal différent, par exemple, lt-0/0/0:1.
Voici un exemple de configuration pour un équipement ACX basé sur FEB.
chassis {
feb 0 {
pfe 0 {
core 0 {
channel 0 {
tunnel-services {
bandwidth 10g;
}
}
}
}
}
}
Voici un exemple de configuration pour un équipement ACX basé sur FPC.
chassis {
fpc 0 {
pfe 0 {
core 0 {
channel 0 {
tunnel-services {
bandwidth 10g;
}
}
}
}
}
}
Voici un exemple de configuration d’interface pseudowire (ps).
interfaces {
ps1 {
anchor-point {
lt-0/0/0:0 {
}
flexible-vlan-tagging;
auto-configure {
stacked-vlan-ranges {
dynamic-profile svlan-prof {
accept [dhcp-v4 dchp-v6 pppoe];
ranges {
any,any;
}
}
}
}
set interfaces ps1 unit 0 encapsulation ethernet-ccc
}
}
Voir aussi
Configuration de PWHT pour les équipements ACX
Comment configurer PWHT sur des périphériques ACX en mode BNG CUPS.
Les équipements ACX qui prennent en charge les fonctionnalités PWHT doivent être en mode CUPS. Reportez-vous au guide de l’utilisateur BNG CUPS pour configurer votre appareil en mode CUPS.
Pour configurer votre interface lt et la bande passante réservée totale, procédez comme suit.
Configuration d’une interface logique d’abonné pseudowire
Une interface logique d’abonné pseudowire termine un tunnel pseudowire MPLS entre un nœud d’accès et le routeur MX Series qui héberge la gestion des abonnés, et vous permet d’exécuter des services de gestion des abonnés à l’interface.
Pour créer une interface logique d’abonné pseudowire :
Configuration du nombre maximal de périphériques d’interface logique pseudowire pris en charge sur le routeur
Vous devez définir le nombre maximal de périphériques d’interface logique pseudowire (tunnels pseudowire) que le routeur peut utiliser pour les interfaces logiques d’abonné. La définition du nombre maximal définit également les noms d’interface pour les interfaces pseudo-filaires. Lorsque vous configurez les interfaces par la suite, vous devez spécifier les noms d’interface compris entre ps0 et ps(device-count - 1).
Par exemple, si vous définissez le nombre maximal de périphériques sur 5, vous ne pouvez configurer que les interfaces ps0, ps1, ps2, ps3 et ps4.
Avant Junos OS version 17.2R1, vous pouviez spécifier un maximum de 2048 périphériques d’interface logique pseudowire pour un routeur MX Series. À partir de la version 17.2R1 de Junos OS, sur les routeurs MX Series dotés d’interfaces MPC et MIC, le nombre de dispositifs d’interface logique pseudowire est passé à 7 000 pour fournir une prise en charge supplémentaire de la résilience.
De même, avant Junos OS version 18.3R1, vous pouviez spécifier un maximum de 2 048 périphériques d’interface de tunnel logique redondant (rlt) d’abonné pseudowire pour un routeur MX Series. À partir de la version 18.3R1 de Junos OS, sur les routeurs MX Series dotés d’interfaces MPC et MIC, le nombre de périphériques d’interface logique redondants pseudowire est passé à 7 000 équipements pour fournir une prise en charge supplémentaire de la résilience.
À partir de Junos OS version 20.4R1, sur les routeurs MX2010 et MX2020 équipés de la carte de ligne MX2K-MPC9E ou MX2K-MPC11E, vous pouvez spécifier jusqu’à 18 000 périphériques d’interface logique pseudofilaire.
Le PFE hébergeant un maximum de périphériques d’interface logique pseudowire offre la flexibilité de configuration nécessaire pour les cas particuliers pouvant survenir dans des scénarios de périphérie d’entreprise. Toutefois, vous pouvez dépasser les ressources PFE disponibles lorsque vous configurez des services supplémentaires sur les ports des périphériques d’interface logique pseudowire. Pour prendre en charge une configuration à l’échelle, veillez à renseigner le nombre approprié de PFE pour le châssis et à répartir les périphériques d’interface logique pseudowire entre les PFE de manière à ce qu’aucun PFE ne soit submergé par la charge de pointe prévue. Lors de la planification réseau de votre déploiement, vous devez tenir compte de la combinaison exacte de la distribution des périphériques d’interface logique pseudowire et des services associés aux périphériques.
Un périphérique d’interface logique pseudowire configuré consomme des ressources provenant de pools partagés, même lorsque le périphérique n’a pas d’interfaces logiques d’abonné actives. Pour économiser les ressources, ne déployez pas un nombre excessif de périphériques pseudofilaires que vous n’avez pas l’intention d’utiliser.
Pour configurer le nombre de périphériques d’interface logique pseudowire que vous souhaitez que le routeur prenne en charge :
Configuration d’un périphérique d’interface logique d’abonné pseudowire
Pour configurer un périphérique d’interface logique pseudowire que le routeur utilise pour les interfaces logiques abonnés, vous spécifiez le tunnel logique qui traite la terminaison pseudowire. Vous pouvez également utiliser des tunnels logiques redondants pour assurer la redondance des tunnels logiques des membres. Vous pouvez configurer d’autres paramètres facultatifs pour le périphérique d’interface, tels que la méthode de balisage VLAN, la MTU et la prise en charge ARP gratuite.
Vous devez créer un tunnel logique pour le périphérique d’interface logique pseudowire. Si vous utilisez des tunnels logiques redondants, vous devez créer le tunnel redondant.
Pour configurer l’interface d’abonné pseudowire :
Modification du point d’ancrage d’un périphérique d’interface logique d’abonné pseudowire
Vous ne pouvez pas modifier dynamiquement un point d’ancrage au-dessus duquel sont superposés des périphériques pseudowire actifs. Vous devez valider certaines modifications avant de déplacer le point d’ancrage. Par exemple, vous pouvez déplacer le point d’ancrage d’un tunnel logique à un autre, d’un tunnel logique à un tunnel logique redondant et d’un tunnel logique redondant à un tunnel logique.
Pour déplacer le point d’ancrage entre les interfaces de tunnel logique :
Pour déplacer le point d’ancrage d’une interface de tunnel logique vers une interface de tunnel logique redondante :
Désactivez les pseudowires empilés et validez. Cela peut nécessiter de faire tomber tous les abonnés utilisant les pseudo-câbles.
[edit interfaces] user@host# deactivate psnumber user@host# commit
Ajoutez la nouvelle interface de tunnel logique redondante et validez.
Créez le tunnel et définissez le nombre maximal d’appareils autorisés.
[edit chassis] user@host# set redundancy-group interface-type redundant-logical-tunnel device-count count
Liez chaque tunnel logique membre au tunnel logique redondant.
Note:Les tunnels logiques redondants exigent que les membres soient en mode de sauvegarde active. Le tunnel logique de sauvegarde doit se trouver sur un FPC différent de celui du tunnel logique actif. Par exemple, si le tunnel actif se trouve sur FPC 3, le tunnel de secours doit se trouver sur un autre FPC, tel que FPC 4.
[edit interfaces rltnumber] user@host# set redundancy-group member-interface lt-fpc/pic/port active user@host# set redundancy-group member-interface lt-fpc/pic/port backup
Validez vos modifications.
[edit interfaces rltnumber] user@host# commit
Remplacez l’ancre sur le pseudowire désactivé par la nouvelle interface de tunnel logique redondante et validez.
[edit interfaces] user@host# set psnumber anchor-point rltnumber user@host# commit
Réactivez les pseudowires empilés et validez.
[edit interfaces] user@host# activate psnumber user@host# commit
Pour déplacer le point d’ancrage d’une interface de tunnel logique redondante vers une interface de tunnel logique membre du tunnel logique redondant :
Désactivez les pseudo-fils empilés ; Cela peut nécessiter de faire tomber tous les abonnés utilisant les pseudo-câbles. Supprimez l’interface de tunnel logique redondante et validez vos modifications.
[edit interfaces] user@host# deactivate psnumber user@host# delete rltnumber user@host# commit
Remplacez l’ancre sur le pseudowire désactivé par la nouvelle interface de tunnel logique et validez.
[edit interfaces] user@host# set psnumber anchor-point lt-fpc/pic/port user@host# commit
Réactivez les pseudowires empilés et validez.
[edit interfaces] user@host# activate psnumber user@host# commit
Configuration de l’interface logique de transport pour une interface logique d’abonné Pseudowire
Cette rubrique décrit comment configurer une interface logique de transport pseudofilaire. Un équipement pseudowire ne peut avoir qu’une seule interface logique de transport.
Un équipement logique pseudowire et ses interfaces logiques pseudowire associées dépendent de l’état du périphérique d’interface de transport logique sous-jacent, qui est soit le circuit VPN de couche 2, soit le circuit de couche 2.
Nous vous recommandons d’utiliser unit 0 pour représenter l’interface logique de transport pour le périphérique pseudofilaire. Les nombres d’unités non nuls représentent les interfaces logiques de service utilisées pour les interfaces d’abonnés pseudofilaires.
Pour configurer une interface logique de transport pseudowire :
Configuration de la signalisation de circuit de couche 2 pour les interfaces logiques d’abonnés pseudowire
Cette rubrique décrit les étapes de configuration de la signalisation de circuit de couche 2 utilisée pour la prise en charge de l’interface logique de l’abonné pseudofilaire. Vous pouvez également utiliser la signalisation VPN de couche 2 pour les interfaces logiques des abonnés pseudofilaires. Les deux méthodes s’excluent mutuellement ; Vous ne pouvez utiliser qu’une seule méthode pour un pseudowire particulier.
Pour configurer la signalisation de circuit de couche 2 pour les interfaces pseudofilaires :
Pour plus d’informations sur les circuits de couche 2, reportez-vous à la section Configuration des interfaces pour les circuits de couche 2.
Configuration de la signalisation VPN de couche 2 pour les interfaces logiques de l’abonné Pseudowire
Cette rubrique décrit les étapes de configuration de la signalisation VPN de couche 2 utilisée pour la prise en charge de l’interface logique de l’abonné pseudofilaire. Vous pouvez également utiliser la signalisation de circuit de couche 2 pour les interfaces logiques des abonnés pseudofilaires. Les deux méthodes s’excluent mutuellement ; Vous ne pouvez utiliser qu’une seule méthode sur un pseudofil particulier.
Pour configurer la signalisation VPN de couche 2 pour les interfaces pseudofilaires :
Configuration de l’interface logique de service pour une interface logique d’abonné pseudowire
Cette rubrique décrit comment configurer une interface logique de service pseudofilaire. Les interfaces logiques de service représentent les circuits de connexion des interfaces logiques pseudofilaires.
Comme décrit dans la présentation des interfaces logiques d’abonné Pseudowire, vous pouvez choisir de configurer une interface logique de service avec une interface logique d’abonné supérieur, en fonction des besoins de l’entreprise. Dans une configuration de périphérie haut débit, l’interface logique de l’abonné le plus élevé est le point de démarcation pour les abonnés. Toutefois, dans une configuration de périphérie d’entreprise, l’interface logique du service est le point de démarcation pour les abonnés professionnels et sert également d’interface logique d’abonné, de sorte qu’aucune interface logique d’abonné n’est configurée explicitement.
Les nombres d’unités non nuls représentent les interfaces logiques de service utilisées pour les interfaces d’abonnés pseudofilaires. Permet unit 0 de représenter l’interface logique de transport pour le périphérique pseudofilaire.
Pour configurer une interface logique de service pseudowire :
Configuration d’un PWHT avec prise en charge de type VC 11
Vous pouvez configurer une interface PWHT (Pseudowire Headend Termination) sur un routeur Service PE et configurer ethernet-tcc l’encapsulation sur l’interface logique de transport PS (Pseudowire Subscriber).
Lorsque vous utilisez cette fonctionnalité, le routeur Service PE n’a pas besoin de prendre en charge le trafic encapsulé TDM/SONET/SDH provenant des clients côté accès. Le pseudowire point à point IP, qui est un FEC 128 (circuit virtuel (VC) de type 11) signalé par LDP, connecte le routeur PE de service au périphérique d’accès connecté au routeur CE. Vous configurez le pseudowire pour qu’il se termine en une instance VPN de couche 3 ou en une table IP globale.
Cette fonctionnalité prend en charge les charges utiles IPv4 et IPv6, ainsi que le trafic unicast et multicast.
Le routeur Service PE utilise la médiation ARP pour résoudre les adresses de couche 2 lorsque différents protocoles de résolution sont utilisés à chaque extrémité d’un circuit. Pour le routeur PE de service, le routeur CE d’accès apparaît comme s’il était connecté localement. Cette médiation ARP est assurée par le proxy ARP sur les adresses IPv4 et par le protocole NDP (Neighbor Discovery Protocol) sur les adresses IPv6. Le routeur PE du service crée une entrée ARP locale qui correspond à l'adresse IPv4 du routeur CE d'accès ou ajoute l'adresse IPv6 du routeur CE d'accès à la table voisine.
Avant de configurer les interfaces et le l2circuit protocole pour le PWHT avec prise en charge du type VC 11 :
- Configurez la session LDP cible pour le circuit de couche 2. Reportez-vous à la section Configuration de LDP pour les circuits de couche 2 .
- Configurez le VPN de couche 3. Reportez-vous à la section Présentation de la configuration des VPN de couche 3.
Lorsque vous activez family tcc et encapsulation ethernet-tcc sur une interface PS, notez les contraintes suivantes sur la configuration :
- Prise en charge d’un seul pseudowire IP par interface physique PS
- Pas de support pour un mot de contrôle ; pour BFD sur l’interface PS ; ou pour une configuration de veille active, de veille ou entièrement active sur le pseudowire IP
Pour configurer PWHT sur le routeur Service PE avec terminaison dans une instance VPN de couche 3 :
Configuration de l’équilibrage de charge Prise en charge du trafic abonné
Configurez le RLT avec les liaisons LT du routeur en mode actif-actif. Les applications RLT peuvent être améliorées pour inclure les liens de membres enfants LT en tant que propriété agrégée.
À partir de la version 21.4R1 de Junos OS, nous assurons l’équilibrage de charge pour les sessions d’abonnés sur l’interface PS sur plusieurs liaisons membres enfants LT du RLT en même temps. La propriété d’équilibrage de charge de l’interface RLT permet de disperser et d’équilibrer la charge du trafic d’abonnés sur l’interface PS sur différents PIC et cartes de ligne.
Pour l’interface RLT, prend en charge la redondance du point d’ancrage PS pour améliorer le mode LAG. Utilisez l’option enhanced-ip ou l’option enhanced-ethernet au niveau hiérarchique [modifier les services réseau du châssis] lors de la configuration de l’IFD PS ancré sur RLT.
Le hachage calculé est utilisé pour sélectionner un chemin ECMP et l’équilibrage de charge. Vous pouvez configurer l’équilibrage de charge pour le trafic IPv4 sur des pseudo-fils Ethernet de couche 2. Vous pouvez également configurer l’équilibrage de charge pour les pseudowires Ethernet en fonction des informations IP.
Limitations
-
La prise en charge de l’équilibrage de charge BNG sur la fonction d’interface d’abonné pseudowire (PS) est prise en charge uniquement pour toutes les cartes de ligne basées sur trio prenant en charge le modèle d’accès BBE sur les routeurs MX Series.
-
Vous ne pouvez pas modifier le point d’ancrage PS à moins de désactiver l’interface physique PS.
-
Une interruption temporaire du trafic peut se produire lors de l’ajout ou de la suppression d’un membre RLT. L’ajout ou la suppression d’un comportement de lien de membre RLT est similaire à celui de n’importe quelle autre interface d’agrégation.
-
Les statistiques d’entrée pour chaque membre LT ne sont pas disponibles. Cependant, des statistiques agrégées sur l’IFL ou l’IFD de SP sont disponibles pour les deux directions.
-
Le mode actif-actif RLT n’est pris en charge que pour les services d’abonnés.
Les éléments ci-dessous ne sont pas pris en charge pour la prise en charge actuelle de l’équilibrage de charge sur PS sur RLT sur plusieurs liaisons LT enfants actives
-
Prise en charge de l’interface PS sur RLT sur les cartes de ligne MX240, MX480 et MX960.
-
Prise en charge par CoS de l’interface de contrôle hiérarchique pour les liaisons membres en mode actif-actif
-
Prise en charge Ethernet agrégée CoS pour le trafic abonné sur l’interface Pseudowire Service (PS)
-
Service L2 Prise en charge de l’IFL et de la périphérie d’entreprise (L3) pour le mode actif-actif lien membre
-
Prise en charge de l’interface PS sur non redondant
-
Prise en charge Hiérarchique CoS de la redondance des points d’ancrage des interfaces logiques d’abonnés pseudowire
Pour configurer la prise en charge de l’équilibrage de charge pour le trafic abonné :
Voir aussi
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.
ethernet-tcc encapsulation sur l’interface. Le pseudowire est de type VC 11.
l2backhaul-vpn de routage. La terminaison PPPoE et L2TP n’est pas prise en charge lorsque l’encapsulation VPLS est utilisée pour l’interface logique de transport. L’interface logique de service prend en charge l’encapsulation CCC (Circuit Cross-Connect) et permet la terminaison de l’interface sur des circuits de couche 2 commutés localement.
family inet et
family inet6 sont pris en charge du côté des services d’une interface logique MPLS pseudowire abonnée ainsi que non-abonnée.