SUR CETTE PAGE
Redondance d’ancrage Vue d’ensemble 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 la signalisation VPN de couche 2 pour les interfaces logiques d’abonné 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é MPLS Pseudowire
Présentation des interfaces logiques d’abonné Pseudowire
La gestion des abonnés prend en charge la création d’interfaces d’abonnés sur des pseudofils MPLS point à point. L’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 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 services.
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. Toutefois, la fonctionnalité de vente en gros de couche 2 de gestion des abonnés haut débit est prise en charge avec l’encapsulation VPLS. Une interface VLAN dynamique est créée avec l’encapsulation VPLS sur un routeur grossiste, qui effectue la commutation de balise VLAN pour mettre fin aux abonnés PPPoE/DHCP sur le réseau du détaillant. Pour plus d’informations, reportez-vous à Broadband Subscriber Management Layer 2 Wholesale Topology and Configuration Elements.
Le pseudofil est un tunnel qui est soit un circuit VPN de couche 2 basé sur MPLS, soit un circuit de couche 2. Le tunnel pseudowire transporte le trafic encapsulé Ethernet d’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 où les fonctions de gestion des abonnés sont exécutées. Un fournisseur de services peut configurer plusieurs pseudowires par 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 pseudofil, le trafic d’abonnés peut être préparé dans 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 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 pour une interface logique d’abonné pseudowire. Le pseudofil est un dispositif virtuel empilé au-dessus du point d’ancrage du tunnel logique sur l’interface physique (l’IFD) et qui prend en charge un protocole de couche 2 orienté circuit (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 Junos OS version 18.3R1, 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 à courant d’eau. Auparavant, les VPN de couche 3 prenaient en charge les services d’abonnés pseudowire via des interfaces de tunnel logique uniquement, et ces interfaces utilisaient des protocoles de routage unicast, tels que OSPF ou BGP. Grâce à cette prise en charge, vous pouvez provisionner un protocole de routage multicast, PIM (Protocol Independent Multicast), sur les interfaces d’abonné pseudowire, qui se termine sur l’instance de routage VRF (Virtual Routing and Forwarding). En outre, il y a une augmentation du nombre de mise à l’échelle des périphériques d’interface logique pseudowire qui fournit une prise en charge de résilience supplémentaire pour les interfaces d’abonné pseudowire sur les interfaces de tunnel logique redondantes.
Lorsqu’une interface de service abonné pseudowire est ancrée à un tunnel logique redondant dont l’interface membre (ou FPC) n’existe pas, l’interface de tunnel tombe en panne. Dans de tels cas, les interfaces pseudowire (physiques et logiques) doivent également être arrêtées, mais l’état de l’interface logique pseudowire de l’abonné 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 abonné pseudowire, ne soient pas disponibles.
En effet, le côté transport de l’interface logique de l’abonné pseudowire reste actif, ce qui rend les services opérationnels.
de protocoles Pseudowire Subscriber Interface
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 de l’interface logique non-abonné.
À partir de Junos OS version 16.1R1, IPFIX intégré est pris en charge côté services de l’interface logique d’abonné MPLS pseudowire.
À partir des versions 15.1R3 et 16.1R1 de Junos OS, l’encapsulation CCC est prise en charge du côté transport d’une interface logique d’abonné MPLS pseudowire.
Avant Junos OS version 19.1R1, le seul type d’encapsulation pris en charge sur les interfaces d’abonné pseudowire incluait :
Interfaces logiques de transport : encapsulation CCC (Circuit Cross-connect).
Service logical interfaces:
Encapsulation Ethernet VPLS
encapsulation de pont VLAN
Encapsulation VLAN VPLS
À partir de Junos OS version 19.1R1, des encapsulations supplémentaires sont ajoutées aux interfaces logiques de transport et de service des abonnés 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 l’encapsulation CCC (circuit cross-connect) et permet de terminer l’interface sur des circuits de couche 2 à commutation locale.
Avec la prise en charge de types d’encapsulation supplémentaires, vous pouvez bénéficier du démux 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é pseudowire sont ancrées sur des tunnels logiques redondants, cette amélioration fournit également une redondance des cartes de ligne.
À partir des versions 15.1R3 et 16.1R1 de Junos OS, la protection contre le déni de service distribué (DDoS) est prise en charge côté services de l’interface logique d’abonné MPLS pseudowire.
À partir de Junos OS versions 15.1R3 et 16.1R1 et ultérieures, Policer et Filter sont pris en charge côté services de l’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 côté services d’une interface logique d’abonné MPLS pseudowire.
À partir de Junos OS version 17.3R1 et versions ultérieures, la prise en charge dynamique de la redondance des points d’ancrage est fournie 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 orientée vers le cœur contre les défaillances du PFE (Packet Forwarding Engine) d’ancrage.
Redondance d’ancrage Vue d’ensemble des interfaces logiques d’abonné pseudowire
Dans les déploiements MPLS pseudowire 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 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 ; au lieu de cela, il utilise un mécanisme de détection de l’activité, avec un algorithme sous-jacent basé sur les pulsations, pour détecter la défaillance des autres moteurs de transfert de paquets dans le système. L’échec d’un moteur de transfert de paquets indique également la défaillance du tunnel logique hébergé, ce qui entraîne finalement une 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 Junos OS version 17.3, des interfaces logiques d’abonné pseudowire peuvent être instanciées sur une interface de tunnel logique redondant (rlt) sous-jacente en mode de sauvegarde active. Cela s’ajoute à l’installation de pseudofils sur une seule interface de tunnel logique. L’avantage le plus notable de l’implémentation de l’interface logique de l’abonné pseudowire par rapport aux interfaces de tunnel logique redondantes est de fournir la redondance du chemin de transfert sous-jacent.
Avant Junos OS version 18.3R1, vous pouviez spécifier un maximum de 2048 périphériques d’interface de tunnel logique redondants pour abonnés pseudowire pour un routeur MX Series. À partir de Junos OS version 18.3R1, sur les routeurs MX Series dotés d’interfaces MPC et MIC, les nombres de mise à l’échelle des périphériques d’interface logique redondants pseudowire sont passés à 7000 é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 de fournir 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 sous-jacente pour le 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’interface modulaire (MIC).
-
Échec MPC dû à un crash du micronoyau.
-
MPC ou MIC mis hors ligne administrativement.
-
Panne de courant sur un MPC ou un 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
Le service statique ifl n’est pas empilé sur le transport ifl lorsque RLT est utilisé.
Par défaut, la protection de liaison pour les interfaces de tunnel redondantes est réversive. 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 une perte de trafic et une perte de session d’abonnés.
Pour surmonter la perte de trafic et de session, vous pouvez configurer la protection des liens non réversifs 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 du lien de secours vers le lien actif à 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 d’interface logique de l’abonné pseudowire et aucune configuration supplémentaire n’est donc nécessaire.
-
Une interface de tunnel logique redondante permet des interfaces physiques de tunnel logique à 32 membres. Cependant, 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 Junos OS version 18.4R1, la prise en charge de la distribution en ligne de sessions BFD (Bidirectional Forwarding Detection) à saut unique est étendue aux abonnés pseudowire via des interfaces de tunnel logique redondantes. Pour l’abonné pseudowire sur les 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 logique 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 fonctionnait en mode centralisé avant Junos OS version 18.4R1.
Grâce à la prise en charge de la distribution en ligne de sessions BFD à saut unique sur des interfaces logiques redondantes pseudowire, il y a un avantage d’échelle 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 les interfaces logiques redondantes est la suivante :
-
Lorsqu’une nouvelle session BFD est ajoutée, elle peut être ancrée sur un FPC actif ou secondaire.
-
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 reviennent après l’installation des sessions 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 tombent pas en panne lorsque le FPC actif échoue 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 sauvegarde. De même, si le FPC de sauvegarde échoue, 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 réversif est activé, lorsque le FPC précédemment actif est à nouveau en ligne, les sessions ne devraient pas tomber en panne. Avec le comportement réversif 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 s’échouer.
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 via des interfaces de tunnel logique :
-
Sur FPC 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é pseudowire ancrées sur des interfaces de tunnel logique redondantes.
-
Un nouveau message d’erreur du journal système -
JTASK_SCHED_SLIPest enregistré pendant le routage actif non-stop (NSR). Il s’agit d’un comportement attendu de NSR à grande échelle qui peut être ignoré en toute sécurité, sauf si d’autres problèmes, tels que des rabats de session, nécessitent une action.
À partir de Junos OS version 21.4R1, nous avons introduit la prise en charge CoS d'un BNG sur l'interface abonné sur pseudowire via une interface de tunnel logique redondant (RLT) actif-actif 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 jeux 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 de jeux d’interfaces ciblés, qui ont des liens principaux et de secours, CoS alloue des nœuds de planification sur les liens principal et de secours afin d’optimiser l’utilisation des nœuds de planification. Le trafic des interfaces cibles des abonnés sera distribué à toutes les liaisons LT principales lorsque le CoS sera appliqué au niveau de l’abonné. En outre, 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 parente 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 jeu IFL svlan dynamique et le nœud uifl dynamique ou statique sont des nœuds 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 nœuds enfants, configurez le profil dynamique au niveau du [edit interfaces ps1 auto-configure stacked-vlan-ranges dynamic-profile]fichier . Créez un profil dynamique en configurant des interfaces et des jeux d’interfaces ciblés dynamiques au [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é aux abonnés dynamiques et aux ensembles d’interfaces dynamiques. L’algorithme de ciblage parcourt la liste des pseudo IFL associés à la paire de liens membres et sélectionne le premier pseudo IFL disposant d’une capacité suffisante en fonction de la configuration rebalance-subscriber-granularity.
Lorsque le ciblage est activé, l’abonné se voit attribuer une pondération de ciblage par défaut en fonction du type de client. L’algorithme de ciblage utilise le poids d’allocation dans le processus de sélection pseudo IFL et le poids débiteur d’IFL est le poids compté par rapport au pseudo IFL attribué. Pour tous les objets à l’exception de l’IFLset, l’allocation et l’épaisseur 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 poids d’allocation peut être modifié via le profil client, et l’pondération débitrice de l’IFLset est fixée à 0.
| Client Type |
Pondération de l’allocation |
Poids débiteur |
|---|---|---|
| Dvlan |
1 |
1 |
| IpDemux |
1 |
1 |
| PPP |
1 |
1 |
| IFLset |
32 |
0 |
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 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 des interfaces pseudofilaires. Lorsque vous configurez ensuite les interfaces, 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 pouvez configurer uniquement 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 Junos OS version 17.2R1, sur les routeurs MX Series dotés d’interfaces MPC et MIC, les nombres de mise à l’échelle des périphériques d’interface logique pseudowire sont passés à 7000 équipements 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 2048 périphériques d’interface de tunnel logique redondant (rlt) pseudowire pour un routeur MX Series. À partir de Junos OS version 18.3R1, sur les routeurs MX Series dotés d’interfaces MPC et MIC, les nombres de mise à l’échelle des périphériques d’interface logique redondants pseudowire sont passés à 7000 é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’à 18000 périphériques d’interface logique pseudofilaires.
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 qui peuvent survenir pour les 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 à remplir le nombre approprié de PFE pour le châssis et à distribuer les périphériques d’interface logique pseudowire sur les PFE de manière à garantir qu’aucun PFE n’est submergé par la charge de pointe prévue. Dans le cadre de la planification du réseau pour votre déploiement particulier, vous devez prendre en compte 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 de pools partagés même s’il n’a pas d’interfaces logiques d’abonné actives. Pour économiser les ressources, ne déployez pas un nombre excessif d’appareils pseudowire que vous n’avez pas l’intention d’utiliser.
Pour configurer le nombre de périphériques d’interface logique pseudowire que le routeur doit prendre 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é, 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, 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 le périphérique d’interface 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 des périphériques pseudowire actifs sont empilés. 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 de faire tomber tous les abonnés 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 de périphériques 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 nécessitent 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 est sur FPC 3, alors le tunnel de sauvegarde doit être sur un FPC différent, 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
Changez l’ancre sur le pseudowire désactivé pour la nouvelle interface de tunnel logique redondante et validez.
[edit interfaces] user@host# set psnumber anchor-point rltnumber user@host# commit
Réactivez les pseudofils 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ésactiver les pseudofils empilés ; Cela peut nécessiter de faire tomber tous les 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
Changez l’ancre sur le pseudowire désactivé pour 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 pseudofils 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 périphérique pseudowire ne peut avoir qu’une seule interface logique de transport.
Un périphérique 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 le circuit VPN de couche 2 ou de couche 2.
Nous vous recommandons d’utiliser unit 0 pour représenter l’interface logique de transport pour le 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é 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é 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 pseudofils :
Pour plus d’informations sur les circuits de couche 2, consultez Configuration des interfaces pour les circuits de couche 2.
Configuration de la signalisation VPN de couche 2 pour les interfaces logiques d’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é 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 pseudofilaires.
Comme décrit dans Vue d’ensemble des interfaces logiques d’abonné Pseudowire, vous pouvez choisir de configurer ou non une interface logique de service avec une interface logique d’abonné supérieure, en fonction des besoins de l’entreprise. Dans une configuration de périphérie haut débit, l’interface logique de l’abonné supérieur sert de point de démarcation pour les abonnés. Toutefois, dans une configuration de périphérie d’activité, 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 pseudofilaire.
Pour configurer une interface logique de service pseudowire :
Configuration d’un PWHT avec prise en charge de type VC 11
RÉSUMÉ Vous pouvez configurer une interface PWHT (pseudowire headend termination) sur un routeur PE de service et configurer ethernet-tcc l’encapsulation sur l’interface logique de transport pseudowire subscriber (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 de clients côté accès. Le pseudofil point à point basé sur 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 une table IP globale.
Cette fonctionnalité prend en charge les charges utiles IPv4 et IPv6 ainsi que le trafic unicast et multicast.
Le routeur PE du service 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 fournie par ARP proxy sur les adresses IPv4 et par 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 protocole pour le l2circuit 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 à Introduction à 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
- Aucun support pour un mot de contrôle ; pour BFD sur l’interface PS ; ou pour une configuration de secours actif, de secours à chaud ou entièrement active 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 liens LT du routeur en mode actif-actif. Les applications RLT peuvent être améliorées pour inclure des liens de membres enfants LT en tant que propriété agrégée.
À partir de Junos OS version 21.4R1, nous assurons la prise en charge de l’équilibrage de charge pour les sessions d’abonnés sur l’interface PS sur plusieurs liaisons LT membres enfants du RLT en même temps. La propriété d’équilibrage de charge de l’interface RLT permet de disperser le trafic des abonnés sur l’interface PS et d’équilibrer la charge sur différents PIC et cartes de ligne.
L’interface For RLT prend en charge la redondance du point d’ancrage PS pour améliorer le mode LAG. Utilisez l’option ou l’option enhanced-ip enhanced-ethernet au niveau hiérarchique [modifier les services réseau-châssis] 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 pseudofils Ethernet de couche 2. Vous pouvez également configurer l’équilibrage de charge pour les pseudofils Ethernet en fonction des informations IP.
Limitations
-
La prise en charge de l’équilibrage de charge BNG sur la fonctionnalité d’interface d’abonné pseudowire (PS) n’est prise en charge que pour toutes les cartes de ligne 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.
-
Des perturbations transitoires du trafic peuvent se produire lorsque vous ajoutez ou supprimez un membre RLT. L’ajout ou la suppression d’un comportement de lien membre RLT est similaire à tout autre comportement d’interface agrégée.
-
Les statistiques d’entrée pour chaque membre LT ne sont pas disponibles. Toutefois, des statistiques agrégées de SP IFL ou IFD sont disponibles pour les deux directions.
-
Le mode actif-actif RLT n’est pris en charge que pour les services 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 over RLT sur plusieurs liaisons LT enfants actives
-
Prise en charge de l’interface PS over RLT sur les cartes de ligne MX240, MX480 et MX960.
-
Prise en charge par CoS de l’interface de police 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 de service pseudowire (PS)
-
Prise en charge IFL de service L2 et de la périphérie professionnelle (L3) pour le lien membre en mode actif-actif
-
Prise en charge de l’interface PS non redondante
-
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 abonné :
Voir aussi
ethernet-tcc encapsulation sur l’interface. Le pseudofil 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 de terminer l’interface sur des circuits de couche 2 à commutation locale.
family inet et
family inet6 sont pris en charge du côté des services d’un abonné pseudowire MPLS ainsi que de l’interface logique non-abonné.