Trafic IPv4 sur VPN de couche 3
Comprendre la distribution de routes IPv4 dans un VPN de couche 3
Au sein d’un VPN, la distribution des routes VPN-IPv4 se fait entre les routeurs PE et CE et entre les routeurs PE (voir figure 1).
Cette section aborde les sujets suivants :
- Distribution des routes des routeurs CE vers PE
- Distribution des routes entre les routeurs PE
- Distribution des routes des routeurs PE vers CE
Distribution des routes des routeurs CE vers PE
Un routeur CE annonce ses routes vers le routeur PE directement connecté. Les routes annoncées sont au format IPv4. Le routeur PE place les routes dans la table VRF pour le VPN. Dans Junos OS, il s’agit de la routing-instance-nametable de routage .inet.0, où routing-instance-name est le nom configuré du VPN.
La connexion entre les routeurs CE et PE peut être une connexion à distance (connexion WAN) ou directe (telle qu’une connexion Frame Relay ou Ethernet).
Les routeurs CE peuvent communiquer avec les routeurs PE à l’aide de l’une des options suivantes :
OSPF
RIP
BGP
Route statique
La figure 2 illustre comment les routes sont distribuées des routeurs CE aux routeurs PE. Le routeur PE1 est connecté à deux routeurs CE dans des VPN différents. Par conséquent, il crée deux tables VRF, une pour chaque VPN. Les routeurs CE annoncent des routes IPv4. Le routeur PE installe ces routes dans deux tables VRF différentes, une pour chaque VPN. De même, le routeur PE2 crée deux tables VRF dans lesquelles des routes sont installées à partir des deux routeurs CE directement connectés. Le routeur PE3 crée une table VRF car elle est directement connectée à un seul VPN.
PE
Distribution des routes entre les routeurs PE
Lorsqu’un routeur PE reçoit des routes annoncées d’un routeur CE directement connecté, il les vérifie par rapport à la stratégie d’exportation VRF pour ce VPN. S’il correspond, le routage est converti au format VPN-IPv4, c’est-à-dire que le distingueur de route de 8 octets est prépendé au préfixe VPN de 4 octets pour former une adresse VPN-IPv4 de 12 octets. La route est ensuite étiquetée avec une communauté de routage cible. Le routeur PE annonce le routage au format VPN-IPv4 aux routeurs PE distants pour une utilisation par les stratégies d’importation VRF. Les routes sont distribuées à l’aide de sessions IBGP, configurées dans le réseau central du fournisseur. Si le routage ne correspond pas, il n’est pas exporté vers d’autres routeurs PE, mais peut toujours être utilisé localement pour le routage, par exemple si deux routeurs CE dans le même VPN sont directement connectés au même routeur PE.
Le routeur PE distant place le routage dans sa table bgp.l3vpn.0 si le routage passe la stratégie d’importation sur la session IBGP entre les routeurs PE. En même temps, il vérifie le routage par rapport à la stratégie d’importation VRF pour le VPN. S’il correspond, le routeur est retiré de la route et placé dans la table VRF (la routing-instance-nametable .inet.0) au format IPv4.
La figure 3 illustre comment le routeur PE1 distribue les routes vers les autres routeurs PE du réseau central du fournisseur. Les routeurs PE2 et PE3 ont chacun des stratégies d’importation VRF qu’ils utilisent pour déterminer s’ils acceptent les routes reçues sur les sessions IBGP et les installent dans leurs tables VRF.
PE
Lorsqu’un routeur PE reçoit des routes annoncées d’un routeur CE directement connecté (routeur PE1 en figure 3), il utilise la procédure suivante pour examiner le routage, le convertir en route VPN et le distribuer aux routeurs PE distants :
Le routeur PE vérifie la route reçue à l’aide de la stratégie d’exportation VRF pour ce VPN.
Si le routage reçu correspond à la stratégie d’exportation, le routage est traité comme suit :
Le routage est converti au format VPN-IPv4, c’est-à-dire que le distingueur de route de 8 octets est prépendé au préfixe VPN de 4 octets pour former l’adresse VPN-IPv4 de 12 octets.
Une communauté cible de routage est ajoutée au routage.
Le routeur PE annonce la route au format VPN-IPv4 aux routeurs PE distants. Les routes sont distribuées à l’aide de sessions IBGP, configurées dans le réseau central du fournisseur.
Si le routage ne correspond pas à la stratégie d’exportation, il n’est pas exporté vers les routeurs PE distants, mais peut toujours être utilisé localement pour le routage, par exemple si deux routeurs CE dans le même VPN sont directement connectés au même routeur PE.
Lorsque le routeur PE distant reçoit des routes annoncées par un autre routeur PE (routeurs PE2 et PE3 en figure 3), il utilise la procédure suivante pour traiter le routage :
Si le routage est accepté par la politique d’importation de la session IBGP entre les routeurs PE, le routeur PE distant place le routage dans sa table bgp.l3vpn.0.
Le routeur PE distant vérifie la communauté cible de routage du routage par rapport à la stratégie d’importation VRF pour le VPN.
S’il correspond, le routeur est retiré de la route et placé dans la table VRF (la routing-instance-nametable .inet.0) au format IPv4.
Distribution des routes des routeurs PE vers CE
Le routeur PE distant annonce les routes de ses tables VRF au format IPv4 vers ses routeurs CE directement connectés.
Les routeurs PE peuvent communiquer avec les routeurs CE à l’aide de l’un des protocoles de routage suivants :
OSPF
RIP
BGP
Route statique
La figure 4 illustre comment les trois routeurs PE annoncent leurs routes vers leurs routeurs CE connectés.
CE
Comprendre les adresses VPN-IPv4 et les distinctions de route
Étant donné que les VPN de couche 3 connectent des réseaux privés ( qui peuvent utiliser des adresses publiques ou privées, comme défini dans la RFC 1918 (Allocation d’adresses pour Les Internets privés) - sur l’infrastructure Internet publique, lorsque les réseaux privés utilisent des adresses privées, les adresses peuvent se chevaucher avec les adresses d’un autre réseau privé.
La figure 5 illustre comment les adresses privées de différents réseaux privés peuvent se chevaucher. Ici, les sites des VPN A et VPN B utilisent les espaces d’adressage 10.1.0.0/16, 10.2.0.0/16 et 10.3.0.0/16 pour leurs réseaux privés.
Pour éviter les chevauchements d’adresses privées, vous pouvez configurer les équipements réseau pour qu’ils utilisent des adresses publiques au lieu d’adresses privées. Cependant, il s’agit d’une entreprise vaste et complexe. La solution fournie dans la RFC 4364 utilise les numéros de réseau privé existants pour créer une nouvelle adresse sans ambiguïté. La nouvelle adresse fait partie de la famille d’adresses VPN-IPv4, c’est-à-dire une famille d’adresses BGP ajoutée en tant qu’extension au protocole BGP. Dans les adresses VPN-IPv4, une valeur qui identifie le VPN, appelée « routage distinguer », est précédée de l’adresse IPv4 privée, fournissant une adresse qui identifie de manière unique une adresse IPv4 privée.
Seuls les routeurs PE doivent prendre en charge l’extension de l’adresse VPN-IPv4 à BGP. Lorsqu’un routeur PE entrant reçoit une route IPv4 d’un équipement au sein d’un VPN, il la convertit en route VPN-IPv4 en ajoutant le préfixe de routage à la route. Les adresses VPN-IPv4 ne sont utilisées que pour les routes échangées entre les routeurs PE. Lorsqu’un routeur PE sortant reçoit un routage VPN-IPv4, il convertit le routage VPN-IPv4 en route IPv4 en supprimant le routeur de routage avant d’annoncer le routage vers ses routeurs CE connectés.
Les adresses VPN-IPv4 ont le format suivant :
Le distinctionur de route est une valeur de 6 octets que vous pouvez spécifier dans l’un des formats suivants :
as-number:number, oùas-numberest un numéro AS (une valeur de 2 octets) etnumberune valeur de 4 octets. Le numéro d’AS peut être compris entre 1 et 65 535. Nous vous recommandons d’utiliser un numéro AS non privé attribué par l’Autorité des numéros internet (IANA), de préférence propre au fournisseur d’accès Internet (FAI) ou au client.ip-address:number, oùip-addressest une adresse IP (une valeur de 4 octets) etnumberune valeur de 2 octets. L’adresse IP peut être n’importe quelle adresse unicast unique au niveau mondial. Nous vous recommandons d’utiliser l’adresse que vous configurez dans l’instructionrouter-id, qui est une adresse non privée dans la plage de préfixes attribuée.
Adresse IPv4 : adresse 4 octets d’un équipement dans le VPN.
La figure 5 illustre comment le numéro AS peut être utilisé dans le distinctionur de route. Supposons que le VPN A soit dans l’AS 65535 et que VPN B soit dans l’AS 666 (ces deux numéros AS appartiennent au FAI), et supposons que le commutateur de routage pour le site 2 dans VPN A est 65535:02 et que le commutateur de routage pour le site 2 dans VPN B est 666:02. Lorsque le routeur PE2 reçoit un routage du routeur CE dans VPN A, il le convertit de son adresse IP 10.2.0.0 à une adresse VPN-IPv4 de 65535:02:10.2.0.0. Lorsque le routeur PE reçoit un routage du VPN B, qui utilise le même espace d’adressage que le VPN A, il le convertit en une adresse VPN-IPv4 de 666:02:10.2.0.0.
Si l’adresse IP est utilisée dans le système de distinction de route, supposons que l’adresse IP du routeur PE2 soit 172.168.0.1. Lorsque le routeur PE reçoit un routage du VPN A, il le convertit en une adresse VPN-IPv4 de 172.168.0.1:0:10.2.0.0/16, et il convertit un routage du VPN B en 172.168.0.0:1:10.2.0.0/16.
Les routeurs PE ne sont utilisés que parmi les routeurs PE vers les adresses IPv4 de différents VPN. Le routeur PE entrant crée un distinction de route et convertit les routes IPv4 reçues des routeurs CE en adresses VPN-IPv4. Les routeurs PE sortants convertissent les routes VPN-IPv4 en routes IPv4 avant de les annoncer au routeur CE.
Les adresses VPN-IPv4 étant un type d’adresse BGP, vous devez configurer des sessions IBGP entre des paires de routeurs PE afin que les routeurs PE puissent distribuer des routes VPN-IPv4 au sein du réseau central du fournisseur. (Tous les routeurs PE sont supposés être dans le même AS.)
Vous définissez des communautés BGP pour restreindre la distribution des routes entre les routeurs PE. Définir des communautés BGP ne permet pas en soi de distinguer les adresses IPv4.
La figure 6 illustre comment le routeur PE1 ajoute le routeur 10458:22:10.1/16 aux routes reçues du routeur CE sur le site 1 dans VPN A et transfère ces routes aux deux autres routeurs PE. De même, le routeur PE1 ajoute le routeur 10458:23:10.2/16 aux routes reçues par le routeur CE sur le site 1 du VPN B et transfère ces routes aux autres routeurs PE .
Configuration du transfert de paquets IPv4 pour les VPN de couche 3
Vous pouvez configurer le routeur pour prendre en charge le transfert de paquets pour le trafic IPv4 dans les VPN de couche 2 et de couche 3. Le transfert de paquets est géré de l’une des manières suivantes, en fonction du type de service d’assistance configuré :
Service BOOTP : les clients envoient des requêtes BOOTP (Bootstrap Protocol) via le routeur configuré avec le service BOOTP à un serveur dans l’instance de routage spécifiée. Le serveur reconnaît l’adresse du client et envoie une réponse au routeur configuré avec le service BOOTP. Ce routeur transfère la réponse à l’adresse client correcte dans l’instance de routage spécifiée.
Autres services : les clients envoient des requêtes via le routeur configuré avec le service à un serveur dans l’instance de routage spécifiée. Le serveur reconnaît l’adresse du client et envoie une réponse à l’adresse client correcte dans l’instance de routage spécifiée.
Pour activer le transfert de paquets pour les VPN, incluez la helpers déclaration :
helpers {
service {
description description-of-service;
server {
address address {
routing-instance routing-instance-names;
}
}
interface interface-name {
description description-of-interface;
no-listen;
server {
address address {
routing-instance routing-instance-names;
}
}
}
}
}
Vous pouvez inclure cette déclaration aux niveaux hiérarchiques suivants :
[edit forwarding-options][edit logical-systems logical-system-name forwarding-options][edit routing-instances routing-instance-name forwarding-options]Note:Vous pouvez activer le transfert de paquets pour plusieurs VPN. Toutefois, le client et le serveur doivent être dans le même VPN. Toutes les plates-formes de routage Juniper Networks dont le transfert de paquets est activé le long du chemin entre le client et le serveur doivent également résider dans le même VPN.
L’adresse et l’instance de routage constituent ensemble un serveur unique. Cela a des implications pour les routeurs configurés avec le service BOOTP, qui peuvent accepter plusieurs serveurs.
Par exemple, un service BOOTP peut être configuré comme suit :
[edit forwarding-options helpers bootp] server address 10.2.3.4 routing-instance [instance-A instance-B];
Même si les adresses sont identiques, les instances de routage sont différentes. Un paquet entrant pour le service BOOTP sur instance-A est transféré dans 10.2.3.4 l’instance de instance-A routage, tandis qu’un paquet entrant instance-B est transféré dans l’instance de instance-B routage. Les autres services n’acceptent qu’un seul serveur. Cette configuration ne s’applique donc pas dans ces cas.
Exemple : configurer un VPN de couche 3 basé sur MPLS
Cet exemple montre comment configurer et valider un VPN de couche 3 basé sur MPLS sur des routeurs ou des commutateurs exécutant Junos OS. L’exemple basé sur IPv4 utilise EBGP comme protocole de routage entre les équipements de périphérie du fournisseur et du client.
Notre équipe de test de contenu a validé et mis à jour cet exemple.
Vous pouvez déployer un réseau privé virtuel (VPN) de couche 3 basé sur MPLS à l’aide de routeurs et de commutateurs exécutant Junos OS pour interconnecter les sites des clients avec une connectivité de couche 3. Bien que le routage statique soit pris en charge, les VPN de couche 3 ont généralement des équipements clients qui échangent des informations de routage avec le réseau du fournisseur et nécessitent la prise en charge des protocoles IP, c’est-à-dire IPv4 et/ou IPv6.
Cela contraste avec un VPN de couche 2, où les équipements du client peuvent ne pas être basés sur des protocoles IP et où le routage, le cas échéant, se produit entre les équipements de périphérie client (CE). Contrairement à un VPN de couche 3 où l’équipement CE interagit (pair) avec l’équipement de périphérie du fournisseur, dans un VPN de couche 2, le trafic client passe de manière transparente par le cœur du fournisseur avec tous les protocoles de routage exécutés de bout en bout entre les équipements CE.
Les VPN basés sur MPLS nécessitent une fonctionnalité MPLS de base sur le réseau du fournisseur. Une fois que le MPLS de base est opérationnel, vous pouvez configurer des VPN qui utilisent des chemins de commutation d’étiquettes (LSP) pour le transport sur le cœur du fournisseur.
L’ajout de services VPN n’affecte pas les opérations de commutation MPLS de base sur le réseau du fournisseur. En fait, les équipements du fournisseur (P) n’ont besoin que d’une configuration MPLS de base, car ils ne sont pas conscients du VPN. L’état VPN est maintenu uniquement sur les équipements de périphérie du fournisseur (PE). C’est l’une des principales raisons pour lesquelles les VPN basés sur MPLS évoluent si bien.
- Exigences
- Présentation et topologie
- Configurations rapides
- Configurer l’équipement PE1 local pour un VPN de couche 3 basé sur MPLS
- Configurer l’équipement PE2 (Remote PE2) pour un VPN de couche 3 basé sur MPLS
- Vérification
Exigences
Cet exemple utilise les composants logiciels et matériels suivants :
Junos OS version 12.3 ou ultérieure pour les équipements de routage et de commutation
Revalidé sur Junos OS version 20.3R1
Deux équipements pe (Provider Edge)
Un équipement fournisseur (P)
Deux équipements de périphérie client (CE)
L’exemple se concentre sur l’ajout d’un VPN de couche 3 à une base MPLS préexistante. Une configuration MPLS de base est fournie au cas où votre réseau n’aurait pas déjà déployé MPLS.
Pour prendre en charge les VPN basés sur MPLS, la base de référence MPLS sous-jacente doit fournir les fonctionnalités suivantes :
Interfaces de bouclage et de cœur opérationnelles avec la prise en charge de la famille MPLS
Un protocole de passerelle interne comme OSPF ou IS-IS pour assurer l’accessibilité entre les adresses de bouclage des équipements du fournisseur (P et PE)
Un protocole de signalisation MPLS tel que LDP ou RSVP pour signaler les LSP
LSP établis entre les adresses de bouclage des équipements PE
Les LSP sont nécessaires entre chaque paire d’équipements PE qui participent à un VPN donné. C’est une bonne idée de créer des LSP entre tous les équipements PE pour répondre à la croissance future du VPN. Vous configurez les LSP au niveau de la [edit protocols mpls] hiérarchie. Contrairement à une configuration MPLS pour une connexion de circuit croisé (CCC), vous n’avez pas besoin d’associer manuellement le LSP à l’interface client (edge) de l’équipement PE. Au lieu de cela, les VPN de couche 3 utilisent la signalisation BGP pour annoncer l’accessibilité du site. Cette signalisation BGP automatise le mappage des sites VPN distants vers les sauts suivants de transfert LSP. Cela signifie qu’avec un VPN de couche 3, le mappage explicite d’un LSP vers l’interface de périphérie d’un équipement PE n’est pas nécessaire.
Présentation et topologie
Les VPN de couche 3 permettent aux clients de tirer parti de l’expertise technique du fournisseur de services pour garantir un routage efficace de site à site. L’équipement de périphérie client (CE) utilise généralement un protocole de routage, tel que BGP ou OSPF, pour échanger des routes avec l’équipement de périphérie du fournisseur de services (PE). Le routage statique est pris en charge pour les VPN de couche 3, mais un protocole de routage dynamique est généralement préféré.
La définition d’un VPN implique uniquement des modifications aux équipements PE locaux et distants. Aucune configuration supplémentaire n’est nécessaire sur les équipements du fournisseur (à condition qu’ils disposent déjà d’une base MPLS de base), car ces équipements ne fournissent que des fonctions de commutation MPLS de base. Les équipements CE n’utilisent pas MPLS et n’ont besoin que d’une interface de base et d’une configuration de protocole de routage pour pouvoir interagir avec les équipements PE.
Dans un VPN de couche 3, vous configurez les équipements CE pour qu’ils appairent l’équipement PE local. Cela contraste avec un VPN de couche 2, où les équipements CE s’appairent comme s’ils se trouvaient sur une liaison partagée, bien qu’ils soient connectés via un cœur de fournisseur basé sur MPLS.
Une fois qu’une base MPLS est en place, vous devez configurer les fonctionnalités suivantes sur les équipements PE pour établir votre VPN de couche 3 basé sur MPLS :
Un groupe BGP avec
family inet-vpn unicastassistanceInstance de routage avec le type
vrfd’instance et une définition de protocole de routage compatible avec l’équipement CE attachéInterfaces client sur les équipements PE configurés avec
family inetune adresse IPv4 qui place l’interface sur le même sous-réseau que l’équipement CE connecté. Si vous le souhaitez, l’encapsulation VLAN et un ID VLAN correspondant peuvent également être configurés.
Pour une connectivité de bout en bout adéquate, l’équipement CE doit être configuré avec un sous-réseau IP compatible et des paramètres de protocole de routage pour prendre en charge l’appairage avec l’équipement PE.
La figure 7 illustre la topologie utilisée dans cet exemple. La figure détaille les noms d’interface, l’adressage IP et les protocoles de routage utilisés dans les réseaux des fournisseurs et des clients. Il met également en évidence la relation d’appairage entre les équipements CE et PE. Dans cet exemple, vous vous attendez à ce que chaque équipement CE forme une session d’appairage EBGP vers l’équipement PE local. Notez que le réseau du fournisseur et les deux sites clients disposent d’un numéro de système autonome pour prendre en charge les opérations BGP. Dans cet exemple, la stratégie de routage est appliquée aux équipements CE pour qu’ils annoncent les routes directes pour leurs interfaces de contact avec le fournisseur et de bouclage.
de routage PE-CE
Configurations rapides
Utilisez les configurations de cette section pour mettre rapidement votre VPN de couche 3 basé sur MPLS. Les configurations comprennent une base MPLS fonctionnelle pour prendre en charge votre VPN de couche 3. Cet exemple se concentre sur les aspects VPN de la configuration. Reportez-vous aux liens suivants pour plus d’informations sur la fonctionnalité MPLS de base utilisée dans cet exemple :
Configuration rapide cli
Les configurations des équipements omettent l’interface de gestion, les routes statiques, la journalisation du système, les services système et les informations de connexion utilisateur. Ces parties de la configuration varient selon l’emplacement et ne sont pas directement liées aux fonctionnalités MPLS ou VPN.
Modifiez les commandes suivantes pour les spécificités de votre environnement et collez-les dans la fenêtre de terminal ce local (CE1) lorsque vous êtes en mode configuration dans la [edit] hiérarchie :
La configuration complète de l’équipement CE1.
set system host-name ce1 set interfaces xe-0/0/0:0 description "Link from CE1 to PE1 for L3vpn" set interfaces xe-0/0/0:0 unit 0 family inet address 172.16.1.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.1/32 set routing-options router-id 172.16.255.1 set routing-options autonomous-system 65410 set protocols bgp group PE1 type external set protocols bgp group PE1 export adv_direct set protocols bgp group PE1 peer-as 65412 set protocols bgp group PE1 neighbor 172.16.1.2 set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then accept
Configuration complète de l’équipement PE1.
set system host-name pe1 set interfaces xe-0/0/0:0 description "Link from PE1 to CE1 for L3vpn" set interfaces xe-0/0/0:0 unit 0 family inet address 172.16.1.2/30 set interfaces xe-0/0/0:1 description "Link from PE1 to p-router" set interfaces xe-0/0/0:1 mtu 4000 set interfaces xe-0/0/0:1 unit 0 family inet address 10.1.23.1/24 set interfaces xe-0/0/0:1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set routing-instances CE1_L3vpn protocols bgp group CE1 type external set routing-instances CE1_L3vpn protocols bgp group CE1 peer-as 65410 set routing-instances CE1_L3vpn protocols bgp group CE1 neighbor 172.16.1.1 set routing-instances CE1_L3vpn instance-type vrf set routing-instances CE1_L3vpn interface xe-0/0/0:0.0 set routing-instances CE1_L3vpn route-distinguisher 192.168.0.1:12 set routing-instances CE1_L3vpn vrf-target target:65412:12 set routing-options router-id 192.168.0.1 set routing-options autonomous-system 65412 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.1 set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.3 set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.3 set protocols mpls interface xe-0/0/0:1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface xe-0/0/0:1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface xe-0/0/0:1.0
Configuration complète de l’équipement P.
set system host-name p set interfaces xe-0/0/0:0 description "Link from p-router to PE1" set interfaces xe-0/0/0:0 mtu 4000 set interfaces xe-0/0/0:0 unit 0 family inet address 10.1.23.2/24 set interfaces xe-0/0/0:0 unit 0 family mpls set interfaces xe-0/0/0:1 description "Link from p-router to PE2" set interfaces xe-0/0/0:1 mtu 4000 set interfaces xe-0/0/0:1 unit 0 family inet address 10.1.34.1/24 set interfaces xe-0/0/0:1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set protocols mpls interface xe-0/0/0:0.0 set protocols mpls interface xe-0/0/0:1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface xe-0/0/0:0.0 set protocols ospf area 0.0.0.0 interface xe-0/0/0:1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface xe-0/0/0:0.0 set protocols rsvp interface xe-0/0/0:1.0
La configuration complète de l’équipement PE2.
set system host-name pe2 set interfaces xe-0/0/0:1 description "Link from PE2 to CE2 for L3vpn" set interfaces xe-0/0/0:1 unit 0 family inet address 172.16.2.2/30 set interfaces xe-0/0/0:0 description "Link from PE2 to p-router" set interfaces xe-0/0/0:0 mtu 4000 set interfaces xe-0/0/0:0 unit 0 family inet address 10.1.34.2/24 set interfaces xe-0/0/0:0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.3/32 set routing-instances CE2_L3vpn protocols bgp group CE2 type external set routing-instances CE2_L3vpn protocols bgp group CE2 peer-as 65420 set routing-instances CE2_L3vpn protocols bgp group CE2 neighbor 172.16.2.1 set routing-instances CE2_L3vpn instance-type vrf set routing-instances CE2_L3vpn interface xe-0/0/0:1.0 set routing-instances CE2_L3vpn route-distinguisher 192.168.0.3:12 set routing-instances CE2_L3vpn vrf-target target:65412:12 set routing-options router-id 192.168.0.3 set routing-options autonomous-system 65412 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.3 set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.1 set protocols mpls label-switched-path lsp_to_pe1 to 192.168.0.1 set protocols mpls interface xe-0/0/0:0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface xe-0/0/0:0.0 set protocols rsvp interface lo0.0 set protocols rsvp interface xe-0/0/0:0.0
La configuration complète de l’équipement CE2.
set system host-name ce2 set interfaces xe-0/0/0:0 description "Link from CE2 to PE2 for L3vpn" set interfaces xe-0/0/0:0 unit 0 family inet address 172.16.2.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.2/32 set routing-options router-id 172.16.255.2 set routing-options autonomous-system 65420 set protocols bgp group PE2 type external set protocols bgp group PE2 export adv_direct set protocols bgp group PE2 peer-as 65412 set protocols bgp group PE2 neighbor 172.16.2.2 set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then accept
Assurez-vous de valider les modifications de configuration sur tous les équipements lorsque vous êtes satisfait de votre travail. Félicitations pour votre nouveau VPN de couche 3 basé sur MPLS ! Reportez-vous à la section Vérification pour connaître les étapes nécessaires pour confirmer que votre VPN de couche 3 fonctionne comme prévu.
Configurer l’équipement PE1 local pour un VPN de couche 3 basé sur MPLS
Cette section décrit les étapes nécessaires pour configurer l’équipement PE1 pour cet exemple. L’accent est mis sur les équipements PE, car c’est là que se trouve la configuration VPN. Reportez-vous à la section Configurations rapides pour les configurations des équipements CE et P utilisées dans cet exemple.
Configurez la base de référence MPLS (si nécessaire)
Avant de configurer un VPN de couche 3, assurez-vous que l’équipement PE dispose d’une base MPLS. Si vous disposez déjà d’une base MPLS, vous pouvez passer à la procédure étape par étape pour ajouter le VPN de couche 3 aux équipements PE.
Configurez le nom d’hôte.
[edit] user@pe1# set system host-name pe1
Configurez les interfaces centrales et de bouclage :
[edit] user@pe1# set interfaces xe-0/0/0:1 description "Link from PE1 to P-router" [edit] user@pe1# set interfaces xe-0/0/0:1 mtu 4000 [edit] user@pe1# set interfaces xe-0/0/0:1 unit 0 family inet address 10.1.23.1/24 [edit] user@pe1# set interfaces xe-0/0/0:1 unit 0 family mpls [edit] user@pe1# set interfaces lo0 unit 0 family inet address 192.168.0.1/32
Meilleures pratiques :Alors qu’un VPN de couche 3 peut effectuer une fragmentation au niveau du PE entrant, sa meilleure pratique pour concevoir le réseau afin que le CE puisse envoyer une trame de taille maximale sans avoir besoin de fragmentation. Pour éviter toute fragmentation, le réseau du fournisseur doit prendre en charge la plus grande trame que les équipements CE peuvent générer après l’ajout des étiquettes MPLS et VRF (Virtual Routing and Forwarding) par l’équipement PE. Cet exemple montre comment laisser les équipements CE à l’unité de transmission maximale (MTU) de 1 500 octets par défaut, tandis que le cœur du fournisseur est configuré pour prendre en charge un MTU de 4 000 octets. Cela garantit que les équipements CE ne peuvent pas dépasser la MTU du réseau du fournisseur, même avec la charge d’encapsulation MPLS et VRF.
Configurez les protocoles :
Note:L’ingénierie du trafic est prise en charge pour les LSP signalés par RSVP, mais elle n’est pas nécessaire pour la commutation MPLS de base ou le déploiement VPN. La référence MPLS fournie utilise le RSVP pour signaler les LSP et permet l’ingénierie du trafic pour OSPF. Toutefois, aucune contrainte de chemin n’est configurée, vous vous attendez donc à ce que les LSP soient acheminés sur le chemin le plus court du protocole de passerelle intérieure.
[edit] user@pe1# set protocols ospf area 0.0.0.0 interface lo0.0 passive [edit] user@pe1# set protocols ospf area 0.0.0.0 interface xe-0/0/0:1.0 [edit] user@pe1# set protocols ospf traffic-engineering [edit] user@pe1# set protocols mpls interface xe-0/0/0:1.0 [edit] user@pe1# set protocols rsvp interface lo0.0 [edit] user@pe1# set protocols rsvp interface xe-0/0/0:1.0
Définissez le LSP à l’adresse de bouclage de l’équipement PE distant :
[edit] user@pe1# set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.3
La base MPLS est désormais configurée sur l’équipement PE1. Continuez à configurer le VPN de couche 3.
Procédure
Procédure étape par étape
Suivez ces étapes pour configurer l’équipement PE1 pour un VPN de couche 3.
Configurez l’interface client :
Pointe:Vous pouvez configurer un VPN de couche 2 basé sur MPLS et un VPN de couche 3 basé sur MPLS sur le même équipement PE. Toutefois, vous ne pouvez pas configurer la même interface de périphérie client pour prendre en charge à la fois un VPN de couche 2 et un VPN de couche 3.
[edit interfaces] user@pe1# set xe-0/0/0:0 description "Link from PE1 to CE1 for L3vpn" [edit] user@pe1# set xe-0/0/0:0 unit 0 family inet address 172.16.1.2/30
Configurez un groupe BGP pour l’appairage entre les équipements PE locaux et distants. Utilisez l’adresse de bouclage de l’équipement PE comme adresse locale et activez la famille d’adresses pour prendre en charge l’échange
inet-vpn unicastde routes VPN de couche 3. Une stratégie de routage pour BGP n’est pas nécessaire sur les équipements PE dans cet exemple. Par défaut, les équipements PE revertissent en IBGP les routes qu’ils apprennent sur leur appairage EBGP vers l’équipement CE.[edit protocols bgp] user@pe1# set group ibgp local-address 192.168.0.1 [edit protocols bgp] user@pe1# set group ibgp family inet-vpn unicast
Pointe:Vous pouvez spécifier d’autres familles d’adresses si la session IBGP PE à PE doit prendre en charge l’échange de routes non VPN, par exemple des routes IPv4 ou IPv6 régulières utilisant les
inetouinet6les familles, respectivement.Configurez le type de groupe BGP en tant qu’interne.
[edit protocols bgp] user@pe1# set group ibgp type internal
Configurez l’adresse de bouclage de l’équipement PE distant en tant que voisin BGP.
[edit protocols bgp] user@pe1# set group ibgp neighbor 192.168.0.3
Configurez l’ID du routeur pour qu’il corresponde à son adresse de bouclage et définissez le numéro de système autonome BGP nécessaire pour l’appairage BGP.
[edit routing-options] user@pe1# set router-id 192.168.0.1 [edit routing-options] user@pe1# set autonomous-system 65412
Configurez l’instance de routage. Spécifiez un nom d’instance de CE1_L3vpn, et configurez un
instance-typedevrf.[edit routing-instances] user@pe1# set CE1_L3vpn instance-type vrf
Configurez l’interface client de l’équipement PE pour qu’elle appartienne à l’instance de routage.
[edit routing-instances] user@pe1# set CE1_L3vpn interface xe-0/0/0:0.0
Configurez le dissociateur de route de l’instance de routage. Ce paramètre permet de distinguer les routes envoyées d’une VRF particulière sur un équipement PE particulier. Il doit être unique pour chaque instance de routage sur chaque équipement PE.
[edit routing-instances] user@pe1# set CE1_L3vpn route-distinguisher 192.168.0.1:12
Configurez la cible de routage de table VRF (Virtual Routing and Forwarding) de l’instance. L’instruction
vrf-targetajoute la balise de communauté spécifiée à toutes les routes annoncées tout en correspondant automatiquement à la même valeur pour l’importation de route. Pour un échange de routage approprié, il est nécessaire de configurer des cibles de routage correspondantes sur les équipements PE qui partagent un VPN donné.[edit routing-instances] user@pe1# set CE1_L3vpn vrf-target target:65142:12
Note:Vous pouvez créer des stratégies plus complexes en configurant explicitement les stratégies d’importation et d’exportation VRF à l’aide des options d’importation et d’exportation. Voir vrf-import et vrf-export pour plus de détails.
Configurez l’instance de routage pour prendre en charge l’appairage EBGP vers l’équipement CE1. L’appairage d’interface direct vers l’extrémité CE1 de la liaison VRF est utilisé, et le numéro de système autonome de CE1 est correctement spécifié avec le
peer-asparamètre.[edit routing-instances] user@pe1# set CE1_L3vpn protocols bgp group CE1 type external [edit routing-instances] user@pe1# set CE1_L3vpn protocols bgp group CE1 peer-as 65410 [edit routing-instances] user@pe1# set CE1_L3vpn protocols bgp group CE1 neighbor 172.16.1.1
Validez vos modifications sur l’équipement PE1 et revenez en mode opérationnel CLI.
[edit] user@pe1# commit and-quit
Résultats
Affichez les résultats de la configuration sur l’équipement PE1. Le résultat reflète uniquement la configuration fonctionnelle ajoutée dans cet exemple.
user@pe1> show configuration
interfaces {
xe-0/0/0:0 {
description "Link from PE1 to CE1 for L3vpn";
unit 0 {
family inet {
}
}
unit 0 {
family inet {
address 10.1.23.1/24;
}
family mpls;
}
ge-0/0/1 {
description "Link from PE1 to P-router";
mtu 4000;
unit 0 {
family inet {
address 10.1.23.1/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
}
routing-instances {
CE1_L3vpn {
protocols {
bgp {
group CE1 {
type external;
peer-as 65410;
neighbor 172.16.1.1;
}
}
}
instance-type vrf;
interface xe-0/0/0:0.0;
route-distinguisher 192.168.0.1:12;
vrf-target target:65412:12;
}
}
routing-options {
router-id 192.168.0.1;
autonomous-system 65412;
}
protocols {
bgp {
group ibgp {
type internal;
local-address 192.168.0.1;
family inet-vpn {
unicast;
}
neighbor 192.168.0.3;
}
}
mpls {
label-switched-path lsp_to_pe2 {
to 192.168.0.3;
}
interface xe-0/0/0:1.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface xe-0/0/0:1.0;
}
}
rsvp {
interface lo0.0;
interface xe-0/0/0:1.0;
}
}
Configurer l’équipement PE2 (Remote PE2) pour un VPN de couche 3 basé sur MPLS
Cette section décrit les étapes nécessaires pour configurer l’équipement PE1 pour cet exemple. L’accent est mis sur les équipements PE, car c’est là que se trouve la configuration VPN. Reportez-vous à la section Configurations rapides pour les configurations des équipements CE et P utilisées dans cet exemple.
Configurez la base de référence MPLS (si nécessaire)
Avant de configurer un VPN de couche 3, assurez-vous que l’équipement PE dispose d’une base MPLS. Si vous disposez déjà d’une base MPLS, vous pouvez passer à la procédure étape par étape pour ajouter le VPN de couche 3 aux équipements PE.
Configurez le nom d’hôte.
[edit] user@pe2# set system host-name pe2
Configurez les interfaces centrales et de bouclage :
[edit] user@pe2# set interfaces xe-0/0/0:0 description "Link from PE2 to P-router" [edit] user@pe2# set interfaces xe-0/0/0:0 mtu 4000 [edit] user@pe2# set interfaces xe-0/0/0:0 unit 0 family inet address 10.1.34.2/24 [edit] user@pe2# set interfaces xe-0/0/0:0 unit 0 family mpls [edit] user@pe2# set interfaces lo0 unit 0 family inet address 192.168.0.3/32
Meilleures pratiques :Alors qu’un VPN de couche 3 peut effectuer une fragmentation au niveau du PE entrant, sa meilleure pratique pour concevoir le réseau afin que le CE puisse envoyer une trame de taille maximale sans avoir besoin de fragmentation. Pour éviter toute fragmentation, le réseau du fournisseur doit prendre en charge la plus grande trame que les équipements CE peuvent générer après l’ajout des étiquettes MPLS et VRF (Virtual Routing and Forwarding) par l’équipement PE. Cet exemple montre comment laisser les équipements CE à l’unité de transmission maximale (MTU) de 1 500 octets par défaut, tandis que le cœur du fournisseur est configuré pour prendre en charge un MTU de 4 000 octets. Cela garantit que les équipements CE ne peuvent pas dépasser la MTU du réseau du fournisseur, même avec la charge d’encapsulation MPLS et VRF.
Configurez les protocoles :
Note:L’ingénierie du trafic est prise en charge pour les LSP signalés par RSVP, mais elle n’est pas nécessaire pour la commutation MPLS de base ou le déploiement VPN. La référence MPLS fournie utilise le RSVP pour signaler les LSP et permet l’ingénierie du trafic pour OSPF. Toutefois, aucune contrainte de chemin n’est configurée, vous vous attendez donc à ce que les LSP soient acheminés sur le chemin le plus court du protocole de passerelle intérieure.
[edit] user@pe2# set protocols ospf area 0.0.0.0 interface lo0.0 passive [edit] user@pe2# set protocols ospf area 0.0.0.0 interface xe-0/0/0:0.0 [edit] user@pe2# set protocols ospf traffic-engineering [edit] user@pe2# set protocols mpls interface xe-0/0/0:0.0 [edit] user@pe2# set protocols rsvp interface lo0.0 [edit] user@pe2# set protocols rsvp interface xe-0/0/0:0.0
Définissez le LSP à l’adresse de bouclage de l’équipement PE distant :
[edit] user@pe2# set protocols mpls label-switched-path lsp_to_pe1 to 192.168.0.1
La base MPLS est désormais configurée sur l’équipement PE1. Continuez à configurer le VPN de couche 3.
Procédure
Procédure étape par étape
Suivez ces étapes pour configurer l’équipement PE2 pour un VPN de couche 3.
Configurez l’interface client :
Pointe:Vous pouvez configurer un VPN de couche 2 basé sur MPLS et un VPN de couche 3 basé sur MPLS sur le même équipement PE. Toutefois, vous ne pouvez pas configurer la même interface de périphérie client pour prendre en charge à la fois un VPN de couche 2 et un VPN de couche 3.
[edit interfaces] user@pe2# set xe-0/0/0:1 description "Link from PE2 to CE2 for L3vpn" [edit] user@pe2# set xe-0/0/0:1 unit 0 family inet address 172.16.2.2/30
Configurez un groupe BGP pour l’appairage entre les équipements PE locaux et distants. Utilisez l’adresse de bouclage de l’équipement PE comme adresse locale et activez la famille d’adresses pour prendre en charge l’échange
inet-vpn unicastde routes VPN de couche 3.[edit protocols bgp] user@pe1# set group ibgp local-address 192.168.0.1 [edit protocols bgp] user@pe1# set group ibgp family inet-vpn unicast
Pointe:Vous pouvez spécifier d’autres familles d’adresses si la session IBGP PE à PE doit prendre en charge l’échange de routes non VPN, par exemple des routes IPv4 ou IPv6 régulières utilisant les
inetouinet6les familles, respectivement.Configurez le type de groupe BGP en tant qu’interne.
[edit protocols bgp] user@pe2# set group ibgp type internal
Configurez l’adresse de bouclage de l’équipement PE1 en tant que voisin BGP.
[edit protocols bgp] user@pe2# set group ibgp neighbor 192.168.0.1
Configurez l’ID du routeur pour qu’il corresponde à son adresse de bouclage et définissez le numéro du système autonome BGP.
[edit routing-options] user@pe2# set routing-options router-id 192.168.0.3 [edit routing-options] user@pe2# set autonomous-system 65412
Configurez l’instance de routage. Spécifiez un nom d’instance de CE2_L3vpn, avec un de
instance-typevrf.[edit routing-instances] user@pe2# set CE2_L3vpn instance-type vrf
Configurez l’interface client de l’équipement PE pour qu’elle appartienne à l’instance de routage.
[edit routing-instances] user@pe2# set CE2_L3vpn interface xe-0/0/0:1.0
Configurez le dissociateur de route de l’instance de routage. Ce paramètre permet de distinguer les routes envoyées d’une VRF particulière sur un équipement PE particulier. Il doit être unique pour chaque instance de routage sur chaque équipement PE.
[edit routing-instances] user@pe2# set CE2_L3vpn route-distinguisher 192.168.0.3:12
Configurez la cible de routage de table VRF (Virtual Routing and Forwarding) de l’instance. L’instruction
vrf-targetajoute la balise de communauté spécifiée à toutes les routes annoncées tout en correspondant automatiquement à la même valeur pour l’importation de route. Pour un échange de routage approprié, il est nécessaire de configurer des cibles de routage correspondantes sur les équipements PE qui partagent un VPN donné.[edit routing-instances] user@pe2# set CE2_L3vpn vrf-target target:65412:12
Note:Vous pouvez créer des stratégies plus complexes en configurant explicitement les stratégies d’importation et d’exportation VRF à l’aide des options d’importation et d’exportation. Voir vrf-import et vrf-export pour plus de détails.
Configurez l’instance de routage pour prendre en charge l’appairage EBGP vers l’équipement CE2. L’appairage d’interface direct vers l’extrémité CE2 de la liaison VRF est utilisé, et le numéro de système autonome de CE2 est correctement spécifié avec le
peer-asparamètre.[edit routing-instances] user@pe2# set CE2_L3vpn protocols bgp group CE2 type external [edit routing-instances] user@pe2# set CE2_L3vpn protocols bgp group CE2 peer-as 65420 [edit routing-instances] user@pe2# set CE2_L3vpn protocols bgp group CE2 neighbor 172.16.2.1
Validez vos modifications sur l’équipement PE2 et revenez en mode opérationnel CLI.
[edit] user@pe2# commit and-quit
Résultats
Affichez les résultats de la configuration sur l’équipement PE2. Le résultat reflète uniquement la configuration fonctionnelle ajoutée dans cet exemple.
user@pe2> show configuration
interfaces {
xe-0/0/0:0 {
description "Link from PE2 to p-router";
mtu 4000;
unit 0 {
family inet {
address 10.1.34.2/24;
}
family mpls;
}
}
xe-0/0/0:1 {
description "Link from PE2 to CE2 for L3vpn";
unit 0 {
family inet {
address 172.16.2.2/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.3/32;
}
}
}
}
routing-instances {
CE2_L3vpn {
protocols {
bgp {
group CE2 {
type external;
peer-as 65420;
neighbor 172.16.2.1;
}
}
}
instance-type vrf;
interface xe-0/0/0:1.0;
route-distinguisher 192.168.0.3:12;
vrf-target target:65412:12;
}
}
routing-options {
router-id 192.168.0.3;
autonomous-system 65412;
}
protocols {
bgp {
group ibgp {
type internal;
local-address 192.168.0.3;
family inet-vpn {
unicast;
}
neighbor 192.168.0.1;
}
}
mpls {
label-switched-path lsp_to_pe1 {
to 192.168.0.1;
}
interface xe-0/0/0:0.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface xe-0/0/0:0.0;
}
}
rsvp {
interface lo0.0;
interface xe-0/0/0:0.0;
}
}
Vérification
Effectuez ces tâches pour vérifier que le VPN de couche 3 basé sur MPLS fonctionne correctement :
- Vérifier les adjacenances OSPF du fournisseur et l’échange de routes
- Vérifier les paramètres de l’interface MPLS et RSVP
- Vérifier les LSP signalés par RSVP
- Vérifier l’état de la session BGP
- Vérifier les routes VPN de couche 3 dans la table de routage
- Ping sur l’équipement PE distant à l’aide de la connexion VPN de couche 3
- Vérifier le fonctionnement de bout en bout des équipements CE sur le VPN de couche 3
Vérifier les adjacenances OSPF du fournisseur et l’échange de routes
But
Vérifiez que le protocole OSPF fonctionne correctement sur le réseau du fournisseur en vérifiant l’état d’adjacence et les routes apprises OSPF vers les adresses de bouclage des équipements du fournisseur distant. Un bon fonctionnement IGP est essentiel pour la mise en place réussie des LSP MPLS.
Action
user@pe1> show ospf neighbor Address Interface State ID Pri Dead 10.1.23.2 xe-0/0/0:1.0 Full 192.168.0.2 128 37
user@pe1> show route protocol ospf | match 192.168 192.168.0.2/32 *[OSPF/10] 1w1d 23:59:43, metric 1 192.168.0.3/32 *[OSPF/10] 1w1d 23:59:38, metric 2
Sens
La sortie montre que l’équipement PE1 a établi une adjacence OSPF envers l’équipement P (192.168.0.2). Il montre également que les adresses de bouclage P et PE distantes (192.168.0.2) et (192.168.0.3) sont correctement apprises via OSPF au niveau de l’équipement PE local.
Vérifier les paramètres de l’interface MPLS et RSVP
But
Vérifiez que les protocoles RSVP et MPLS sont configurés pour fonctionner sur l’interface centrale de l’équipement PE. Cette étape vérifie également qu’elle family mpls est correctement configurée au niveau de l’unité de l’interface centrale de l’équipement PE.
Action
user@pe1> show mpls interface Interface State Administrative groups (x: extended) xe-0/0/0:1.0 Up <none>
user@pe1> show rsvp interface
RSVP interface: 2 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
lo0.0 Up 0 100% 0bps 0bps 0bps 0bps
xe-0/0/0:1.0 Up 1 100% 10Gbps 10Gbps 0bps 0bps
Sens
Le résultat montre que MPLS et RSVP sont correctement configurés sur les interfaces centrales et de bouclage de l’équipement PE local.
Vérifier les LSP signalés par RSVP
But
Vérifiez que les LSP signalés par RSVP et les LSP sortants sont correctement établis entre les adresses de bouclage de l’équipement PE.
Action
user@pe1> show rsvp session Ingress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 192.168.0.3 192.168.0.1 Up 0 1 FF - 17 lsp_to_pe2 Total 1 displayed, Up 1, Down 0 Egress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 192.168.0.1 192.168.0.3 Up 0 1 FF 3 - lsp_to_pe1 Total 1 displayed, Up 1, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0
Sens
Le résultat montre que les sessions RSVP entrantes et sortantes sont correctement établies entre les équipements PE. Un établissement LSP réussi indique que la base MPLS est opérationnelle.
Vérifier l’état de la session BGP
But
Vérifiez que la session IBGP entre les équipements PE est correctement établie avec la prise en charge des informations d’accessibilité de la couche réseau VPN de couche 3 (NLRI). Au cours de cette étape, vous confirmez également que la session EBGP de PE à CE est bien établie et correctement configurée pour échanger des routes IPv4.
Action
user@pe1> show bgp summary
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
0 0 0 0 0 0
bgp.l3vpn.0
2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.1 65410 26038 25938 0 0 1w1d 3:12:32 Establ
CE1_L3vpn.inet.0: 1/2/2/0
192.168.0.3 65412 19 17 0 0 6:18 Establ
CE1_L3vpn.inet.0: 2/2/2/0
bgp.l3vpn.0: 2/2/2/0
Sens
Le résultat indique que la session IBGP à l’équipement PE distant (192.168.0.3) a été correctement établie (Establ), et à travers le Up/Dwn champ, la durée de la session est dans l’état actuel (6:18). Le flaps champ confirme qu’aucune transition d’état n’a eu lieu (0), indiquant que la session est stable. Notez également que les routes VPN de couche 3 (NLRI) ont été apprises à partir du PE distant, comme le montre la présence d’une bgp.l3vpn.0 table.
L’affichage confirme également que la session EBGP sur l’équipement CE1 local (172.16.1.1) est établie et que des routes IPv4 ont été reçues de l’équipement CE1 et installées dans l’instance de routage des équipements CE1 (CE1_L3vpn.inet.0)
Cette sortie confirme que l’appairage BGP entre les équipements PE et l’équipement CE fonctionne correctement pour prendre en charge votre VPN de couche 3.
Vérifier les routes VPN de couche 3 dans la table de routage
But
Vérifiez que la table de routage de l’équipement PE1 est remplie de routes VPN de couche 3 annoncées par le PE distant. Ces routes permettent de transférer le trafic vers l’équipement CE distant.
Action
user@pe1> show route table bgp.l3vpn.0
bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.3:12:172.16.2.0/30
*[BGP/170] 00:22:45, localpref 100, from 192.168.0.3
AS path: I, validation-state: unverified
> to 10.1.23.2 via xe-0/0/0:1.0, label-switched-path lsp_to_pe2
192.168.0.3:12:172.16.255.2/32
*[BGP/170] 00:22:43, localpref 100, from 192.168.0.3
AS path: 65420 I, validation-state: unverified
> to 10.1.23.2 via xe-0/0/0:1.0, label-switched-path lsp_to_pe2
user@pe1> show route table CE1_L3vpn.inet.0
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.0/30 *[Direct/0] 1w1d 03:29:44
> via xe-0/0/0:0.0
[BGP/170] 1w1d 03:29:41, localpref 100
AS path: 65410 I, validation-state: unverified
> to 172.16.1.1 via xe-0/0/0:0.0
172.16.1.2/32 *[Local/0] 1w1d 03:29:44
Local via xe-0/0/0:0.0
172.16.2.0/30 *[BGP/170] 00:23:28, localpref 100, from 192.168.0.3
AS path: I, validation-state: unverified
> to 10.1.23.2 via xe-0/0/0:1.0, label-switched-path lsp_to_pe2
172.16.255.1/32 *[BGP/170] 1w1d 03:29:41, localpref 100
AS path: 65410 I, validation-state: unverified
> to 172.16.1.1 via xe-0/0/0:0.0
172.16.255.2/32 *[BGP/170] 00:23:26, localpref 100, from 192.168.0.3
AS path: 65420 I, validation-state: unverified
> to 10.1.23.2 via xe-0/0/0:1.0, label-switched-path lsp_to_pe2
Sens
La show route table bgp.l3vpn.0 commande affiche les routes VPN de couche 3 qui ont été reçues de l’équipement PE distant. La show route table CE1_L3vpn.inet.0 commande répertorie tous les routes qui ont été importées dans l’instance de CE1_L3vpn routage. Ces entrées représentent les routes apprises de l’appairage EBGP local vers l’équipement CE1, en plus des routes reçues de l’équipement PE2 distant avec une cible de routage correspondante.
Les deux tables indiquent que les routes VPN de couche 3 distantes sont correctement associées au lsp_to_pe2 LSP en tant que saut suivant de transfert. Les sorties confirment que l’équipement PE local a appris les routes associées à la localisation CE2 distante de l’équipement PE2. Il montre également que le PE local transfère le trafic VPN de couche 3 vers l’équipement PE2 distant à l’aide du transport MPLS sur le réseau du fournisseur.
Ping sur l’équipement PE distant à l’aide de la connexion VPN de couche 3
But
Vérifiez la connectivité VPN de couche 3 entre les équipements PE locaux et distants à l’aide de ping. Cette commande vérifie le routage VPN de couche 3 et le transfert MPLS entre les équipements PE.
Action
user@pe1> ping routing-instance CE1_L3vpn 172.16.2.2 source 172.16.1.2 count 2 PING 172.16.2.2 (172.16.2.2): 56 data bytes 64 bytes from 172.16.2.2: icmp_seq=0 ttl=61 time=128.235 ms 64 bytes from 172.16.2.2: icmp_seq=1 ttl=61 time=87.597 ms --- 172.16.2.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 87.597/107.916/128.235/20.319 m
Sens
La sortie confirme que les plans de contrôle et de transfert VPN de couche 3 fonctionnent correctement entre les équipements PE.
Vérifier le fonctionnement de bout en bout des équipements CE sur le VPN de couche 3
But
Vérifiez la connectivité VPN de couche 3 entre les équipements CE. Cette étape confirme que les équipements CE disposent d’interfaces opérationnelles et sont correctement configurés pour la connectivité de couche 3 basée sur EBGP. Pour ce faire, il vérifie que l’équipement CE1 local a bien appris les routes de l’équipement CE distant et qu’il est en mesure de passer le trafic de bout en bout entre leurs adresses de bouclage.
Action
user@ce1> show route protocol bgp
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.2.0/30 *[BGP/170] 00:40:50, localpref 100
AS path: 65412 I, validation-state: unverified
> to 172.16.1.2 via xe-0/0/0:0.0
172.16.255.2/32 *[BGP/170] 00:40:49, localpref 100
AS path: 65412 65420 I, validation-state: unverified
> to 172.16.1.2 via xe-0/0/0:0.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
user@ce1> ping 172.16.255.2 source 172.16.255.1 size 1472 do-not-fragment count 2 PING 172.16.255.2 (172.16.255.2): 1472 data bytes 1480 bytes from 172.16.255.2: icmp_seq=0 ttl=61 time=79.245 ms 1480 bytes from 172.16.255.2: icmp_seq=1 ttl=61 time=89.125 ms --- 172.16.255.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 79.245/84.185/89.125/4.940 ms
Sens
La sortie montre que la connectivité VPN de couche 3 fonctionne correctement entre les équipements CE. L’équipement CE local a appris l’interface VRF et les routes de bouclage de l’équipement CE distant via BGP. Le ping est généré vers l’adresse de bouclage de l’équipement CE distant et est extrait de l’adresse de bouclage de l’équipement CE local à l’aide de l’argument source 172.16.255.1 . L’ajout des do-not-fragment commutateurs et size 1472 confirme que les équipements CE sont capables de passer des paquets IP de 1 500 octets sans évoquer la fragmentation de l’équipement PE local.
L’argument size 1472 ajouté à la ping commande génère 1 472 octets de données d’écho. 8 octets supplémentaires d’ICMP (Internet Control Message Protocol) et 20 octets d’en-tête IP sont ajoutés pour porter la taille totale de la charge utile à 1 500 octets. L’ajout du do-not-fragment commutateur garantit que les équipements CE et PE locaux ne peuvent pas effectuer de fragmentation. Cette méthode ping confirme que la fragmentation n’est pas nécessaire lors de l’échange de trames Ethernet standard de 1 500 octets de longueur maximale entre les équipements CE.
Ces résultats confirment que le VPN de couche 3 basé sur MPLS fonctionne correctement.