SUR CETTE PAGE
Présentation des interfaces logiques d’abonnés pseudowire de la redondance d’ancrage
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 des signaux VPN de couche 2 pour les interfaces logiques d’abonnés pseudowire
Configuration de l’interface logique de service pour une interface logique d’abonné pseudowire
Configuration de la prise en charge de l’équilibrage de charge pour le trafic des abonnés
Interfaces logiques d’abonnés pseudowire MPLS
Présentation des interfaces logiques des abonnés Pseudowire
La gestion des abonnés prend en charge la création d’interfaces d’abonné sur des pseudowires MPLS point à point. La capacité d’interface d’abonné pseudowire permet aux fournisseurs de services d’étendre un domaine MPLS du réseau d’accès-agrégation à la périphérie du 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 des é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 sur les concentrateurs de ports modulaires (MPC) avec cartes d’interface modulaires Ethernet (MIC) uniquement. 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. Cependant, la fonctionnalité de gestion des abonnés haut débit de couche 2 en gros est prise en charge avec l’encapsulation VPLS. Une interface VLAN dynamique est créée avec encapsulation VPLS sur un routeur grossiste, qui effectue la commutation de balises VLAN pour résilier les abonnés PPPoE/DHCP sur le réseau du détaillant. Pour plus de détails, consultez Gestion des abonnés haut débit Éléments de topologie et de configuration de gros de couche 2.
Le pseudowire est un tunnel qui est soit un VPN de couche 2 basé sur le MPLS, soit un circuit de couche 2. Le tunnel pseudowire transporte le trafic encapsulé Ethernet depuis un nœud d’accès (par exemple, un DSLAM ou un autre périphérique 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 pour chaque DSLAM, puis prendre en charge un grand nombre d’abonnés sur un pseudowire spécifique.
La figure 1 montre un réseau MPLS qui prend en charge la gestion des abonnés.
À l’extrémité du nœud d’accès du pseudowire, le trafic des abonnés peut être acheminé vers le pseudowire de diverses manières, limitées uniquement par le nombre et les types d’interfaces qui peuvent être empilées sur le pseudowire. Vous spécifiez un point d’ancrage qui identifie l’interface tunnel logique qui termine le pseudowire tunnel 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 logique du tunnel sur l’interface physique (l’IFD) et qui 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 avec 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 de multicast draft-rosen. Auparavant, les VPN de couche 3 prenaient en charge les services d’abonné pseudowire sur des interfaces de tunnel logique uniquement, 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 de multicast, Protocol Independent Multicast (PIM), sur les interfaces d’abonné pseudowire, qui se termine sur l’instance de routage VRF (Virtual Routing and Forwarding). En outre, le nombre de mises à l’échelle des équipements d’interface logique pseudowire augmente et offre une prise en charge supplémentaire de la résilience des interfaces d’abonné pseudowire sur les interfaces de tunnel logique redondantes.
Lorsqu’une interface de service d’abonné pseudowire est ancrée dans un tunnel logique redondant dont l’interface membre (ou FPC) n’existe pas, l’interface de tunnel est désactivée. Dans de tels cas, les interfaces pseudowire (physiques et logiques) doivent également être désactivées, mais l’état de l’interface logique de l’abonné pseudowire reste actif, bien que les services de circuit de couche 2, tels que ping vers un périphérique de périphérie client (CE) du côté service de l’interface de service d’abonné pseudowire, ne soient pas disponibles.
En effet, le côté transport de l’interface logique de l’abonné pseudowire reste actif, ce qui entraîne la disponibilité des services.
de protocoles d’interface d’abonné pseudowire
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 d’abonné telles que DHCP et PPPoE peuvent être empilées sur la couche 2 de la même manière qu’elles sont empilées sur une interface physique.
À partir de Junos OS version 16.1R1, family inet et family inet6 sont pris en charge du côté des services d’un abonné pseudowire MPLS ainsi que d’une interface logique non abonné.
À partir de Junos OS version 16.1R1, le correctif IPFIX en ligne est pris en charge du côté des services d’une interface logique d’abonné pseudowire MPLS.
À partir des versions 15.1R3 et 16.1R1 de Junos OS et des versions ultérieures, l’encapsulation CCC est prise en charge du côté transport d’une interface logique d’abonné pseudowire MPLS.
Avant la version 19.1R1 de Junos OS, le seul type d’encapsulation pris en charge sur les interfaces d’abonné pseudowire était :
-
Interfaces logiques de transport : encapsulation CCC (Circuit Cross Connect).
-
Service logical interfaces:
-
Encapsulation VPLS Ethernet
-
Encapsulation de pont VLAN
-
Encapsulation VPLS VLAN
-
À partir de la version 19.1R1 de Junos OS, des encapsulations supplémentaires sont ajoutées aux interfaces logiques de transport et de service de l’abonné pseudowire. L’interface logique de transport prend en charge l’encapsulation VPLS Ethernet et permet de terminer l’interface sur l’instance l2backhaul-vpn de routage. L’interface logique de service prend en charge circuit encapsulation CCC (cross connect) et permet de terminer 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 en plusieurs services VPN, tels que le circuit de couche 2 et le VPN de couche 3. Étant donné que les interfaces d’abonné pseudowire sont ancrées sur des tunnels logiques redondants, cette amélioration fournit également une redondance de carte de ligne.
À partir des versions 15.1R3 et 16.1R1 de Junos OS et des versions ultérieures, la protection contre le déni de service distribué (DDoS) est prise en charge du côté des services d’une interface logique d’abonné pseudowire MPLS.
À partir des versions Junos OS 15.1R3 et 16.1R1 et ultérieures, Policer et Filter sont pris en charge du côté des services d’une interface pseudowire abonné logique MPLS.
À partir des versions 15.1R3 et 16.1R1 de Junos OS 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é pseudowire MPLS.
À partir de la version 17.3R1 de Junos OS et versions ultérieures, la prise en charge de la redondance de point d’ancrage dynamique est fournie pour l’interface logique d’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 orientée vers le cœur contre la défaillance du PFE d’ancrage (moteur de transfert de paquets).
Présentation des interfaces logiques d’abonnés pseudowire de la redondance d’ancrage
Dans les déploiements de pseudowire MPLS qui utilisent des interfaces logiques d’abonné 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, par conséquent, une perte de session d’abonné.
Le moteur de transfert de paquets ne s’appuie pas sur le plan de contrôle pour la détection des défaillances ; à la place, il utilise un mécanisme de détection de la vivacité, avec un algorithme sous-jacent basé sur les battements de cœur, pour détecter la défaillance des autres moteurs de transfert de paquets du 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 une perte de session. Pour éviter cette perte de session, vous devez disposer d’un point d’ancrage redondant vers lequel la session peut être déplacée sans perte de trafic.
Les interfaces logiques d’abonné pseudowire peuvent être instanciées sur une interface de tunnel logique redondant (RLT) sous-jacente en mode actif-actif ou actif-secours. 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 sur les interfaces RLT est de fournir une redondance du chemin de transfert sous-jacent. Cela permet au système d’attirer de nouveaux abonnés et de maintenir les abonnés existants opérationnels même si une interface membre du RLT tombe en panne en raison de la désactivation d’un PFE. Les abonnés resteront actifs tant qu’il y aura au moins une liaison de membre RLT sur un PFE actif.
Avant la version 18.3R1 de Junos OS, vous pouviez spécifier un maximum de 2048 équipements d’interface de tunnel logique redondants d’abonné pseudowire pour un routeur MX Series. À partir de la version 18.3R1 de Junos OS, sur les routeurs MX Series avec interfaces MPC et MIC, le nombre d’équipements d’interface logique redondants pseudowire est passé à 7 000 pour fournir un support supplémentaire en matière de résilience.
La version 17.3 de Junos OS prend également en charge une infrastructure agrégée améliorée pour un moteur de transfert de paquets fournissant une redondance de point 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 de sous-couche du tunnel logique redondant. Ce modèle d’empilage est utilisé pour les interfaces logiques d’abonné 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 micronoyau.
-
MPC ou MIC mis hors ligne administrativement.
-
Panne de courant sur une MPC ou une MIC.
La figure 3 fournit les détails de l’empilement d’interfaces logiques d’abonné pseudowire sur une interface de tunnel logique redondante.
de tunnel logique redondante
L’ifl de service statique n’est pas empilé sur l’ifl de transport lorsque RLT est utilisé.
Par défaut, la protection des liens pour les interfaces de tunnel redondantes est réversible. En cas de défaillance de la liaison active, le trafic est acheminé via la liaison de secours. Lorsque la liaison active est rétablie, le trafic est automatiquement réacheminé vers la liaison active. Cela entraîne une perte de trafic et de session d’abonnés.
Pour surmonter les pertes de trafic et de session, vous pouvez configurer la protection des liens non réversibles 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 session d’abonné. Vous pouvez également basculer manuellement le trafic de la liaison de secours vers la liaison active à l’aide de la request interface (revert | switchover) interface-name commande.
La commutation manuelle du trafic entraîne une perte 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 d’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. 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 pseudowire.
À partir de la version 18.4R1 de Junos OS, la prise en charge de la distribution en ligne des sessions de détection de transfert bidirectionnelle (BFD) à saut unique est étendue aux abonnés pseudowire sur des interfaces de tunnel logique redondantes. Pour l’abonné pseudowire sur des interfaces de tunnel logique, 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 pseudowire, les interfaces de tunnel logiques membres peuvent être hébergées sur différentes cartes de ligne. L’adresse de distribution n’étant 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.
Avec la prise en charge de la distribution en ligne de sessions BFD à saut unique sur des interfaces logiques redondantes pseudowire, il existe un avantage d’évolutivité allant jusqu’à 2000 sessions BFD à saut unique à 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 le réancrage est déclenché pour la prochaine adresse de distribution disponible. Les sessions BFD sont relancées après l’installation des sessions sur l’autre FPC et le démarrage de l’échange de paquets BFD.
Cependant, il est également possible que les sessions sur le FPC de secours ne s’arrêtent pas en cas d’échec du FPC actif, en fonction du temps de détection BFD configuré, car l’état de transfert du nouveau FPC actif peut prendre un certain temps à être programmé.
-
Lorsque le FPC actif échoue, toutes les sessions BFD sont ancrées sur le FPC de secours. De même, si le FPC de sauvegarde échoue, toutes les sessions BFD sont ancrées sur le FPC actif.
-
Le réancrage de la session BFD n’est pas déclenché lorsque le FPC actif est à nouveau en ligne.
-
Lorsque le comportement non réversible est activé, lorsque le FPC précédemment actif est à nouveau en ligne, les sessions ne sont pas censées s’arrêter. Avec le comportement de réversion par défaut, il est possible que l’état de transfert doive être mis à jour et, selon la configuration de l’heure de détection, la session vacille ou non.
Prenez en considération les éléments suivants avec la prise en charge de la distribution en ligne de sessions BFD à saut unique sur un abonné pseudowire sur des interfaces de tunnel logique :
-
Sur le FPC MPC 7e de type 7e, avec l’activation de l’instance de routage 7000, il faut environ six minutes pour que les 7000 sessions BGP soient établies sur les interfaces d’abonné pseudowire ancrées sur des interfaces de tunnel logique redondantes.
-
Un nouveau message d’erreur dans le journal système -
JTASK_SCHED_SLIP- est enregistré pendant le routage actif ininterrompu (NSR). Il s’agit d’un comportement attendu d’une NSR à grande échelle et qui peut être ignoré en toute sécurité, sauf en cas d’autres problèmes, tels que des battements de session, qui nécessitent des mesures.
À partir de Junos OS version 21.4R1, nous avons introduit CoS prise en charge d'un BNG sur abonné-interface sur pseudowire via une interface RLT (Redundant Logical tunnel) active-active pour les applications abonné telles que DHCP et PPPoE. Cette propriété CoS est obtenue en fournissant les nœuds de planification pour les liaisons de tunnel logiques. Pour les interfaces dynamiques, les ensembles d’interfaces, les interfaces sous-jacentes statiques et les interfaces sous-jacentes dynamiques sur RLT, le 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ées, qui ont des liaisons principales et secondaires, le CoS alloue des nœuds de planification sur les liaisons principales et secondaires pour optimiser l’utilisation des nœuds de planification. Le trafic des interfaces ciblées sur les abonnés sera distribué à toutes les liaisons LT primaires lorsque le CoS est appliqué au niveau de l’abonné. En outre, le trafic d’un abonné donné est toujours traité par le même moteur de transfert de paquets.
La figure 4 fournit le détail 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 svlan dynamique, l’IFL-set et le nœud uifl dynamique ou statique sont des nœuds parents.
abonné
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 nœuds enfants, configurez le profil dynamique au niveau du [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 dans le [edit dynamic-profiles].
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";
}
}
}
}
}
En outre, 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 du RLT (paires de jambes primaires/secondaires). Le ciblage peut être appliqué pour des abonnés dynamiques et des ensembles d’interfaces dynamiques. L’algorithme de ciblage passe en revue la liste des pseudo-IFL associées à la paire de liens membres et sélectionne la première pseudo-IFL qui a une capacité suffisante en fonction de la configuration rebalance-subscriber-granularity.
Lorsque le ciblage est activé, un poids de ciblage par défaut est attribué à l’abonné en fonction du type de client. L’algorithme de ciblage utilise le poids d’allocation dans le processus de sélection des pseudo-IFL et le poids débiteur de l’IFL est le poids compté par rapport à la pseudo IFL attribuée. Pour tous les objets à l’exception de l’IFLset, l’allocation et le 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 d’affectation peut être modifié via le profil 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 de débit |
|---|---|---|
| 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 pseudowire MPLS et transmet les paquets de données à leur destination à l’aide du protocole IP standard.
Les fonctionnalités pseudowire et PWHT (terminaison de tête de réseau pseudowire) des équipements ACX qui prennent en charge cette fonctionnalité nécessitent que l’équipement soit exécuté 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 disponibles 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 la plate-forme et de la version pour des fonctionnalités spécifiques.
PWHT est utilisé pour mettre fin au contrôle pseudowire MPLS au niveau du routeur Provider Edge. À la sortie du pseudowire, les informations de contrôle (messages de signalisation PPPoE ou DHCP) sont transmises au plan de contrôle centralisé, tandis que les données normales sont transmises à leur destination sous forme de paquets IP standard.
Pour configurer le PWHT sur votre appareil ACX, celui-ci doit d’abord être configuré pour le mode CUPS. Veuillez consulter Configuration du contrôleur BNG CUPS et Configuration des plans utilisateur BNG pour plus d’informations.
La configuration PWHT s’effectue dans le plan utilisateur (votre appareil) plutôt que dans le plan de contrôle (cloud). En effet, les interfaces de tunnel logique (lt) et 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é lors de la commande de configuration. Cet emplacement n’est pas basé sur la bande passante. Dans les exemples suivants, le LT IFD serait lt-0/0/0:0. Si une autre interface LT était nécessaire dans ce même emplacement, elle serait 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 du PWHT pour les équipements ACX
Comment configurer PWHT sur les appareils ACX en mode BNG CUPS.
Les équipements ACX prenant 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 totale réservée, procédez comme suit.
Configuration d’une interface logique d’abonné pseudowire
Une interface logique pseudowire d’abonné 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 au niveau de 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 pseudowire. Lorsque vous configurez ensuite les interfaces, vous devez spécifier les noms d’interface dans la plage comprise entre ps0 et ps(device-count - 1).
Par exemple, si vous définissez le nombre maximal d’appareils sur 5, vous ne pouvez configurer que les interfaces ps0, ps1, ps2, ps3 et ps4.
Avant la version 17.2R1 de Junos OS, vous pouviez spécifier un maximum de 2048 équipements d’interface logique pseudowire pour un routeur MX Series. À partir de la version 17.2R1 de Junos OS, sur les routeurs MX Series avec interfaces MPC et MIC, le nombre de mises à l’échelle des équipements d’interface logique pseudowire est passé à 7 000 pour fournir un support supplémentaire en matière de résilience.
De même, avant Junos OS version 18.3R1, vous pouviez spécifier un maximum de 2048 périphériques d’interface pseudowire abonné rlt redon tunnel dants pour un routeur MX Series. À partir de la version 18.3R1 de Junos OS, sur les routeurs MX Series avec interfaces MPC et MIC, le nombre d’équipements d’interface logique redondants pseudowire est passé à 7 000 pour fournir un support supplémentaire en matière de résilience.
À partir de la version 20.4R1 de Junos OS, sur les routeurs MX2010 et MX2020 avec la carte de ligne MX2K-MPC9E ou MX2K-MPC11E, vous pouvez spécifier jusqu’à 18 000 équipements d’interface logique pseudowire.
Le PFE hébergeant le maximum de périphériques d’interface logique pseudowire offre la flexibilité de configuration nécessaire pour les cas particuliers susceptibles de se produire 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 mise à 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. Dans le cadre de la planification du réseau pour votre déploiement particulier, vous devez tenir compte de la combinaison exacte de la distribution des équipements de l’interface logique pseudowire et des services associés aux appareils.
Un périphérique d’interface logique pseudowire configuré consomme les ressources des pools partagés même lorsqu’il n’a pas d’interfaces logiques d’abonné actives. Pour économiser les ressources, ne déployez pas un nombre excessif de périphériques pseudowire 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 d’abonné, 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 membres. Vous pouvez configurer des paramètres facultatifs supplémentaires pour le périphérique d’interface, tels que la méthode de balisage VLAN, le 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’équipement d’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 sur lequel sont empilés des périphériques pseudowire actifs. Vous devez valider certaines modifications avant de déplacer le point d’ancrage. Par exemple, le déplacement du point d’ancrage d’un tunnel logique à un autre tunnel logique, 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 l’arrêt de tout abonné utilisant les pseudowires.
[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.
Remarque :Les tunnels logiques redondants nécessitent que les membres soient en mode de sauvegarde active. Le tunnel logique de secours doit se trouver sur un FPC différent du tunnel logique actif. Par exemple, si le tunnel actif se trouve sur le FPC 3, le tunnel de secours doit se trouver sur un autre FPC, tel que le 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 du 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 l’arrêt des abonnés utilisant les pseudowires. 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 du 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 pseudowire. Un périphérique 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 de l’interface de transport logique sous-jacente, qui est soit le VPN de couche 2, soit l’circuit de couche 2.
Nous vous recommandons de l’utiliser unit 0 pour représenter l’interface logique de transport du périphérique pseudowire. Les numéros d’unité non nuls représentent les interfaces logiques de service utilisées pour les interfaces d’abonné pseudowire.
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 d’abonné pseudowire. Vous pouvez également utiliser la signalisation VPN de couche 2 pour les interfaces logiques d’abonné pseudowire. 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 pseudowire :
Pour plus d’informations sur les circuits de couche 2, voir Configuration des interfaces pour les circuits de couche 2.
Configuration des signaux VPN de couche 2 pour les interfaces logiques d’abonnés 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 d’abonné pseudowire. Vous pouvez également utiliser la signalisation de circuit de couche 2 pour les interfaces logiques d’abonné pseudowire. Les deux méthodes s’excluent mutuellement ; vous ne pouvez utiliser qu’une seule méthode sur un pseudowire particulier.
Pour configurer la signalisation VPN de couche 2 pour les interfaces pseudowire :
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 pseudowire. Les interfaces logiques de service représentent les circuits de connexion des interfaces logiques pseudowire.
Comme décrit dans la présentation des interfaces logiques d’abonnés pseudowire, vous pouvez choisir de configurer une interface logique de service avec une interface logique d’abonné plus élevée, en fonction des besoins de l’entreprise. Dans une configuration de périphérie haut débit, l’interface logique abonné supérieure est le point de démarcation pour les abonnés. Toutefois, dans une configuration de périphérie d’entreprise, l’interface logique de 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 explicitement configurée.
Les numéros d’unité non nuls représentent les interfaces logiques de service utilisées pour les interfaces d’abonné pseudowire. Permet unit 0 de représenter l’interface logique de transport du périphérique pseudowire.
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 Termin) sur un routeur PE de service et configurer ethernet-tcc l’encapsulation sur l’interface logique de transport des abonnés pseudowire (PS).
Lorsque vous utilisez cette fonctionnalité, le routeur PE de service 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 basé sur IP (c’est-à-dire un FEC 128 (type de circuit virtuel (VC) de type 11) à signalisation LDP) connecte le routeur PE de service à l’équipement d’accès connecté au routeur CE. Vous configurez le pseudowire pour qu’il se termine en une instance VPN de couche 3 ou une table IP globale.
La fonctionnalité prend en charge les charges utiles IPv4 et IPv6, ainsi que le trafic unicast et multicast.
Le routeur PE de service utilise la médiation ARP pour résoudre les adresses de couche 2 lorsque différents protocoles de résolution sont utilisés aux deux extrémités d’un circuit. Pour le routeur PE de service, le routeur d’accès CE apparaît comme s’il était connecté localement. Cette médiation ARP est assurée par l’ARP proxy sur les adresses IPv4 et par le protocole NDP (Neighbor Discovery Protocol) sur les adresses IPv6. Le routeur PE de 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 de type VC 11 :
- Configurez la session LDP cible pour le circuit de couche 2. Reportez-vous à la section Configuration LDP pour les circuits de couche 2 .
- Configurez le VPN de couche 3. Voir Introduction à la configuration des VPN de couche 3.
Lorsque vous activez family tcc et encapsulation ethernet-tcc sur une interface PS, notez les contraintes de configuration suivantes :
- 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 active-standby, hot-standby, ou tout actif sur le pseudowire IP
Pour configurer PWHT sur le routeur PE de service avec terminaison dans une instance VPN de couche 3 :
Configuration de la prise en charge de l’équilibrage de charge pour le trafic des abonnés
Configurez le RLT avec les liaisons LT du routeur en mode actif-actif. Les applications RLT peuvent être améliorées pour inclure des liens membres enfants LT en tant que propriété agrégée.
À partir de la version 21.4R1 de Junos OS, nous prenons en charge l’équilibrage de charge pour les sessions d’abonnés sur l’interface PS sur plusieurs liens membres enfants LT du RLT simultanément. La propriété d’équilibrage de charge de l’interface RLT permet de disperser et d’équilibrer la charge du trafic des abonnés sur l’interface PS sur différents PIC et cartes de ligne.
Pour l’interface RLT, prend en charge la redondance des points d’ancrage PS pour améliorer le mode LAG. Utilisez l’option enhanced-ip ou l’option enhanced-ethernet au niveau de la hiérarchie [edit chassis network-services] lors de la configuration de PS IFD 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 pseudowires Ethernet de couche 2. Vous pouvez également configurer l’équilibrage de charge pour les pseudowires Ethernet en fonction des informations IP.
Limites
-
La prise en charge de l’équilibrage de charge BNG sur la fonctionnalité 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 sauf si vous désactivez l’interface physique PS.
-
Une interruption temporaire du trafic peut se produire lorsque vous ajoutez ou supprimez un membre RLT. L’ajout ou la suppression du comportement des liens des membres RLT est similaire à tout autre comportement d’interface agrégé.
-
Les statistiques entrantes pour chaque membre LT ne sont pas disponibles. Cependant, des statistiques agrégées PS IFL ou IFD sont disponibles pour les deux directions.
-
Le mode RLT actif-actif est pris en charge uniquement pour les services aux abonnés.
Les éléments suivants 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 CoS de l’interface de contrôle hiérarchique pour les liens membres en mode actif-actif
-
Prise en charge Ethernet agrégé CoS du trafic des abonnés sur l’interface PS (Pseudowire Service)
-
Prise en charge de l’IFL de service L2 et de la périphérie d’entreprise (L3) pour liaison membre en mode actif-actif
-
Prise en charge des interfaces PS sur les interfaces non redondantes
-
Prise en charge hiérarchique du CoS pour la redondance des points d’ancrage des interfaces logiques d’abonné pseudowire
Pour configurer la prise en charge de l’équilibrage de charge pour le trafic des abonnés :
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 VC de type 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 circuit encapsulation CCC (cross connect) et permet de terminer 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’un abonné pseudowire MPLS ainsi que d’une interface logique non abonné.