Migrer de FEC128 LDP-VPLS vers EVPN Présentation
Pour les fournisseurs de services disposant de réseaux VPLS (Virtual Private LAN Service) et de réseaux Ethernet VPN (EVPN), il est nécessaire d’interconnecter ces réseaux. Avant l’introduction de la fonctionnalité Migration transparente de LDP-VPLS vers EVPN, une interface de tunnel logique sur le point d’interconnexion des instances de routage VPLS et EVPN était utilisée à cette fin. Dans ce cas, les équipements PE de chaque réseau n’avaient pas connaissance des équipements PE de l’autre réseau technologique.
Avec l’introduction de la fonctionnalité Migration transparente de LDP-VPLS vers EVPN, une solution est introduite pour permettre une migration par étapes de FEC128 LDP-VPLS vers EVPN site par site pour chaque instance de routage VPN. Dans cette solution, les équipements PE exécutant EVPN et VPLS pour la même instance de routage VPN et les mêmes segments en monohoming peuvent coexister. Pendant la migration, l’impact sur le transfert de trafic d’appareil à appareil CE pour les clients concernés est minime (CE).
Consultez l’entrée Migration transparente de LDP-VPLS vers EVPN dans l’explorateur de fonctionnalités pour plus d’informations sur la plate-forme et la prise en charge de Junos OS.
Les sections suivantes décrivent la migration de LDP-VPLS vers EVPN :
Présentation et avantages technologiques
Le service VPLS (Virtual Private LAN Service est un VPN de couche 2 point à multipoint basé sur Ethernet. Cette technologie vous permet de connecter des réseaux locaux de datacenters géographiquement dispersés les uns aux autres sur une dorsale MPLS tout en maintenant une connectivité de couche 2. Les fonctionnalités de haute disponibilité définies dans les normes VPLS (telles que le double homing LER) et les fonctionnalités d’autodécouverte topologique utilisant la signalisation BGP rendent VPLS évolutif et facile à déployer. Étant donné que VPLS utilise MPLS comme son cœur, il fournit une faible variation de latence et des temps de convergence faibles statistiquement liés au sein du réseau MPLS.
Ethernet VPN (EVPN), quant à lui, est une solution VPN combinée de couche 2 et de couche 3 qui est plus évolutive, résiliente et efficace que les technologies actuelles. Il offre plusieurs avantages, notamment une plus grande efficacité, fiabilité, évolutivité, mobilité des machines virtuelles et contrôle des stratégies pour les fournisseurs de services et les entreprises.
Bien que VPLS soit une technologie VPN de couche 2 largement déployée, les réseaux des fournisseurs de services migrent vers EVPN en raison des avantages d’évolutivité et de la facilité de déploiement. Voici quelques-uns des avantages d’EVPN :
-
Le trafic du plan de contrôle est distribué avec BGP et le trafic de diffusion et de multicast est envoyé à l’aide d’une arborescence de multicast partagée ou avec une réplication entrante.
-
L’apprentissage du plan de contrôle est utilisé pour les adresses MAC et IP à la place de l’apprentissage du plan de données. adresse MAC apprentissage nécessite le flooding de trames unicast et ARP inconnues, alors que l’apprentissage des adresses IP ne nécessite aucun flooding.
-
Le réflecteur de route permet de réduire un maillage complet de sessions BGP entre équipements PE à une seule session BGP entre un équipement PE et le réflecteur de route.
-
La découverte automatique avec BGP est utilisée pour découvrir les équipements PE participant à un VPN donné, les équipements PE participant à un groupe de redondance donné, les types d’encapsulation de tunnel, le type de tunnel multicast et les membres de multicast.
-
Un multihébergement entièrement actif est utilisé. Ainsi, un équipement CE donné peut avoir plusieurs liaisons vers plusieurs équipements PE, et le trafic traversant vers et depuis cet équipement CE utilise pleinement toutes ces liaisons (segment Ethernet).
-
Lorsqu’une liaison entre un équipement CE et un équipement PE tombe en panne, les équipements PE de cette instance EVPN (EVI) sont avertis de la défaillance par le retrait d’une seule route EVPN. Cela permet aux responsables PE de supprimer le périphérique PE qui se retire en tant que saut suivant pour chaque adresse MAC associée à la liaison défaillante (retrait en masse).
Migration FEC128 LDP-VPLS vers EVPN
Certains fournisseurs de services souhaitent préserver leurs investissements dans les VPLS. D’où la nécessité de connecter les anciens réseaux VPLS aux nouveaux réseaux qui exécutent EVPN. À cette fin, des interfaces de tunnel logique sur le point d’interconnexion des instances de routage VPLS et EVPN ont été utilisées. Cependant, tous les autres dispositifs PE appartenaient soit au réseau VPLS, soit au réseau EVPN et n’étaient pas au courant de l’autre technologie.
À partir de la version 17.3 de Junos OS, EVPN peut être introduit dans un réseau VPLS existant de manière progressive, avec un impact minimal sur les services VPLS. Sur un équipement VPLS PE, certains clients peuvent passer à EVPN, tandis que d’autres clients continuent d’utiliser des pseudowires VPLS. D’autres équipements PE peuvent être entièrement VPLS et commuter les clients sur d’autres équipements PE vers EVPN. Cette solution prend en charge la migration transparente vers Internet (expire en janvier 2018), (PBB-)EVPN Intégration transparente avec (PBB-)VPLS.
La migration transparente de FEC128 LDP-VPLS vers la solution EVPN prend en charge les fonctionnalités suivantes :
-
Permettre une migration progressive vers EVPN site par site par instance VPN. Par exemple, les nouveaux sites EVPN doivent être provisionnés sur des appareils EVPN PE.
-
Permettre la coexistence d’équipements PE exécutant à la fois EVPN et VPLS pour la même instance VPN et les mêmes segments en monohoming.
Dans le cadre de la migration de LDP-VPLS vers EVPN, l’équipement PE sur lequel certains clients ont été migrés vers EVPN tandis que d’autres clients sont servis à l’aide de VPLS est appelé un équipement super PE. Lorsque les appareils super PE découvrent d’autres équipements super PE au sein d’une instance de routage, ils utilisent le transfert EVPN pour communiquer avec d’autres équipements super PE et les pseudowires VPLS vers les équipements PE exécutant VPLS. L’équipement PE sans prise en charge d’EVPN et exécutant uniquement VPLS pour tous les clients est appelé équipement PE VPLS.
L’équipement CE connecté à un super PE peut atteindre les équipements CE connectés à des équipements PE EVPN uniquement ou à des équipements PE VPLS uniquement, mais les équipements CE connectés à des équipements PE EVPN uniquement ne peuvent pas atteindre les équipements CE connectés à des équipements PE VPLS uniquement.
Étant donné que la migration de LDP-VPLS vers EVPN est prise en charge pour chaque instance de routage, et si l’instance de routage dessert plusieurs clients sur un équipement PE, toutes sont migrées ensemble. L’EVPN est responsable de la configuration du transfert de données entre les équipements PE mis à niveau vers EVPN, tandis que VPLS continue de configurer le transfert de données vers les équipements PE qui exécutent VPLS. Il ne devrait y avoir aucun impact pour les clients qui utilisent encore le pseudowire VPLS sur tous les appareils PE.
Les fonctionnalités suivantes ne sont pas prises en charge lors de la migration de LDP-VPLS vers EVPN :
-
Migration du VPLS FEC129 vers EVPN.
-
Migration de BGP-VPLS vers EVPN.
-
Migration du commutateur virtuel VPLS vers le commutateur virtuel EVPN.
-
Migration de l’instance de routage VPLS vers le commutateur virtuel EVPN.
-
Migration de l’instance de routage VPLS ou PBB-VPLS vers PBB-EVPN.
-
Migration transparente d’EVPN vers VPLS.
-
Amélioration d’EVPN pour prendre en charge l’ensemble des outils ou des instructions et commandes pris en charge par VPLS.
-
Multihébergement actif-actif et actif-veille. La migration vers EVPN n’est prise en charge que sur les déploiements en monohoming.
-
La gestion entièrement active sur les équipements EVPN et VPLS PE ne fonctionne pas, car la fonctionnalité de multihébergement entièrement actif n’est pas prise en charge sur VPLS.
-
Connexion d’équipements PE EVPN uniquement à des équipements PE VPLS uniquement via des équipements super PE.
-
IPv6, les systèmes logiques, la prise en charge multichâssis et SNMP, car ils ne sont actuellement pas pris en charge sur EVPN.
Exemple de configuration pour la migration de LDP-VPLS vers EVPN
Les sections suivantes fournissent un exemple de configuration requis pour effectuer la migration de LDP-VPLS vers EVPN.
LDP-VPLS Configuration
Voici une configuration statique typique d’instance de routage LDP-VPLS :
user@host# show routing-instance foo
instance-type vpls;
vlan-id 100; (not needed for VLAN bundle service)
interface ge-2/0/0.590;
interface ae500.590;
routing-interface irb.0;
forwarding-options {
family vpls {
filter {
input UNKNOWN-UNICAST;
}
}
}
protocols {
vpls {
control-word;
encapsulation-type ethernet-vlan;
enable-mac-move-action;
mac-table-size {
100000;
packet-action drop;
}
mac-table-aging-time ;
interface-mac-limit {
100000;
packet-action drop;
}
no-tunnel-services; (use label-switched interfaces)
vpls-id 245015;
mtu 1552;
ignore-mtu-mismatch;
mac-flush {
any-spoke;
}
no-vlan-id-validate;
neighbor 192.168.252.64 {
psn-tunnel-endpoint 10.0.0.31;
pseudowire-status-tlv;
revert-time 60;
backup-neighbor 192.168.252.65 {
psn-tunnel-endpoint 10.0.0.32;
hot-standby;
}
}
mesh-group Spoke { (access label-switched interface toward spoke)
local-switching;
neighbor 192.168.252.66 {
psn-tunnel-endpoint 10.0.0.41;
pseudowire-status-tlv;
}
neighbor 192.168.252.67 {
psn-tunnel-endpoint 10.0.0.42;
pseudowire-status-tlv;
}
}
connectivity-type permanent;
}
user@host# show interfaces ge-2/0/0.590
encapsulation vlan-vpls;
vlan-id 590;
output-vlan-map {
swap;
tag-protocol-id 0x8100;
inner-vlan-id 590;
}
family vpls {
filter {
input-list [ listA ];
output-list listB;
}
}
EVPN Migration Configuration
Pour effectuer la migration FEC128 LDP-VPLS vers EVPN, procédez comme suit :
-
Sur le moteur de routage de secours, chargez Junos OS version 17.3R1.
-
Effectuer une mise à niveau logicielle en service (ISSU) pour acquérir le rôle principal. Assurez-vous que l’ISSU unifié VPLS n’a aucun impact sur le transfert VPLS.
-
Identifier les instances de routage (clients) qui doivent être migrées vers EVPN.
-
Activez EVPN dans une seule instance de routage.
-
Remplacez le type d’instance de routage par
evpn, et incluez l’instructionevpnau niveau de la[edit routing-instances routing-intance-name protocols]hiérarchie, et incluez également l’instructionvplsdans la même hiérarchie pour prendre en charge les commandes VPLS.Par exemple :
[edit routing-instances routing-instance-name] instance-type evpn; interface ge-2/0/0.590; interface ae500.590; routing-interface irb.0; route-distinguisher 10.1.1.1:50; (add for LDP-VPLS) vrf-target target:100:100; (add for LDP-VPLS) forwarding-options { family vpls { filter { input UNKNOWN-UNICAST; } } } protocols { vpls { (supports all existing VPLS commands) }
-
-
Activez la signalisation EVPN de la famille dans BGP.
Par exemple :
protocols { bgp { local-as 64512; group 2mx { type internal; local-address 10.81.1.1; family evpn { signaling; } neighbor 10.81.2.2; neighbor 10.81.9.9; } }
Une fois la configuration de la migration EVPN validée, le processus de protocole de routage et le processus d’apprentissage d’adresse de couche 2 commencent à construire l’état EVPN pour refléter les interfaces, les domaines de pont, les pairs et les routes. Les adresses MAC apprises localement sont synchronisées par le processus d’apprentissage d’adresse de couche 2 de instance.vpls.0 avec le processus de protocole de routage. Lorsqu’un MAC local expire dans instance.vpls.0, le processus de protocole de routage est informé par le processus d’apprentissage d’adresse de couche 2.
Lorsqu’un pair EVPN est appris, le processus de protocole de routage envoie un nouveau message au processus d’apprentissage d’adresse de couche 2 pour supprimer l’interface à commutation d’étiquette ou l’interface logique de tunnel virtuel du pair du groupe de maillage VE et désactive l’apprentissage MAC sur celui-ci. Le saut suivant de messagerie instantanée EVPN est ensuite ajouté au groupe de maillage VE. Le comportement EVPN dans le processus du protocole de routage consistant à apprendre les adresses MAC sur BGP et à informer le processus d’apprentissage des adresses de couche 2 du saut suivant MPLS est conservé.
Les instructions et les commandes VPLS continuent de s’appliquer aux pseudowires VPLS entre les périphériques PE et les adresses MAC apprises sur eux. Les instructions et commandes EVPN s’appliquent aux équipements PE exécutant EVPN.
Revenir à VPLS
Si la migration EVPN rencontre des problèmes, vous pouvez revenir à VPLS jusqu’à ce que le problème soit compris. L’instance de routage passe d’un super PE à un PE VPLS de manière non catastrophique en activant la configuration suivante :
[edit routing-instances routing-instance-name] user@host# set instance-type vpls user@host# delete protocols evpn user@host# delete route-distinguisher (if running LDP-VPLS) user@host# delete vrf-target (if running LDP-VPLS)
Lors de l’annulation de la migration EVPN vers VPLS, voici ce qui se produit :
-
Les informations d’état EVPN sont supprimées.
-
Il existe un déclencheur pour le retrait des routes du plan de contrôle EVPN.
-
Le processus de protocole de routage envoie un nouveau message au processus d’apprentissage d’adresse de couche 2 avec l’interface à commutation d’étiquette ou l’interface logique de tunnel virtuel pour l’instance de routage et l’homologue.
-
L’interface à commutation d’étiquette ou de tunnel virtuel ajoute le nouveau message au groupe flood et l’apprentissage MAC est activé.
-
Le saut suivant de messagerie instantanée de sortie est supprimé par le processus des protocoles de routage, ce qui incite le processus d’apprentissage d’adresse de couche 2 à le supprimer du groupe flood.
-
Les adresses MAC distantes sont réapprises via l’interface à commutation d’étiquette ou l’interface logique de tunnel virtuel.
Migration de LDP-VPLS vers EVPN et autres fonctionnalités
Le Tableau 1 décrit les fonctionnalités de certaines fonctionnalités connexes, telles que le multihébergement et le routage et pontage intégrés (IRB) avec la migration de LDP-VPLS vers EVPN.
| Fonctionnalité |
Fonctionnalités prises en charge dans la migration EVPN |
|---|---|
| Migration MAC |
Les déplacements MAC sont pris en charge entre les équipements PE VPLS uniquement et les équipements super PE. Lorsqu’une adresse MAC passe d’un périphérique PE VPLS uniquement à un équipement super PE, elle est apprise via BGP, et le processus du protocole de routage informe le processus d’apprentissage d’adresse de couche 2 du saut suivant EVPN à mettre à jour dans la table de routage foo.vpls.0. Lorsqu’une adresse MAC passe d’un super équipement PE à un équipement PE VPLS uniquement, elle est apprise dans le moteur de transfert de paquets sur l’interface à commutation d’étiquettes ou l’interface de tunnel virtuel. Le processus d’apprentissage d’adresse de couche 3 le met à jour vers VPLS ou l’interface à commutation d’étiquette next hop. Lorsque la route de type 2 est retirée par EVPN BGP, l’adresse MAC n’est pas supprimée de la table de transfert, il n’y a donc pas de perte de données. La table MAC de transfert est partagée par VPLS et EVPN. Certains attributs, tels que |
| CISR |
Aucun changement n’est nécessaire à la CISR. Sur un appareil super PE, EVPN remplit les routes hôtes /32 apprises sur les routes MAC+IP de type 2 à partir d’homologues EVPN dans un routage et un transfert virtuels de couche 3, tandis que le transfert VPLS IRB à l’aide de routes de sous-réseau fonctionne sur les sites exécutant encore VPLS. |
| VPLS hiérarchique |
Dans un réseau H-VPLS avec des équipements PE en étoile, lorsque l’équipement PE central est migré vers EVPN, les adresses MAC locales apprises via l’interface de tunnel virtuel ou d’étiquette d’accès doivent être annoncées à BGP, afin que les autres équipements PE EVPN uniquement ou super PE puissent les atteindre. Tenez compte des éléments suivants lors de la migration d’un réseau H-VPLS vers EVPN :
|
| Configuration ESI |
L’identifiant de segment Ethernet (ESI) est configuré au niveau de l’interface physique ou du port. |