Trafic IPv4 sur VPN de couche 3
Comprendre la distribution des routes IPv4 dans un VPN de couche 3
Au sein d’un VPN, la distribution des routes VPN-IPv4 s’effectue entre les routeurs PE et CE ainsi qu’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 au routeur PE directement connecté. Les routes annoncées sont au format IPv4. Le routeur PE place les routes dans la table VRF du VPN. Sous 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 (une connexion WAN) ou une connexion directe (telle qu’un relais de trames ou une connexion Ethernet).
Les routeurs CE peuvent communiquer avec les routeurs PE à l’aide de l’une des méthodes suivantes :
-
OSPF
-
DÉCHIRER
-
BGP
-
Route statique
La figure 2 illustre la distribution des routes entre les routeurs CE et les routeurs PE. Le routeur PE1 est connecté à deux routeurs CE qui se trouvent dans des VPN différents. Par conséquent, il crée deux tables VRF, une pour chaque VPN. Les routeurs CE annoncent les 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 les routes sont installées à partir des deux routeurs CE directement connectés. Le routeur PE3 crée une table VRF car il est directement connecté à un seul VPN.
PE
Distribution des routes entre les routeurs PE
Lorsqu’un routeur PE reçoit des routes annoncées à partir d’un routeur CE directement connecté, il vérifie la route reçue par rapport à la stratégie d’exportation VRF de ce VPN. S’il correspond, la route est convertie au format VPN-IPv4, c’est-à-dire que le séparateur de route de 8 octets est ajouté au préfixe VPN de 4 octets pour former une adresse VPN-IPv4 de 12 octets. L’itinéraire est ensuite balisé avec une communauté cible d’itinéraire. Le routeur PE annonce la route au format VPN-IPv4 vers les routeurs PE distants pour une utilisation par les stratégies d’importation VRF. Les routes sont distribuées à l’aide de sessions IBGP, qui sont configurées dans le réseau central du fournisseur. Si la route ne correspond pas, elle n’est pas exportée vers d’autres routeurs PE, mais peut toujours être utilisée 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 la route dans sa table bgp.l3vpn.0 si la route transmet la stratégie d’importation sur la session IBGP entre les routeurs PE. Dans le même temps, il vérifie l’itinéraire par rapport à la stratégie d’importation VRF pour le VPN. S’il correspond, le séparateur de route est supprimé de l’itinéraire et il est placé dans la table VRF (la routing-instance-nametable .inet.0) au format IPv4.
La figure 3 illustre la façon dont 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 doivent accepter les routes reçues sur les sessions IBGP et les installer dans leurs tables VRF.
PE
Lorsqu’un routeur PE reçoit des routes annoncées à partir d’un routeur CE directement connecté (routeur PE1 dans la 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 de ce VPN.
-
Si l’itinéraire reçu correspond à la stratégie d’exportation, l’itinéraire est traité comme suit :
-
La route est convertie au format VPN-IPv4, c’est-à-dire que le séparateur de route de 8 octets est ajouté au préfixe VPN de 4 octets pour former l’adresse VPN-IPv4 de 12 octets.
-
Une communauté cible d’itinéraire est ajoutée à l’itinéraire.
-
Le routeur PE annonce l’itinéraire au format VPN-IPv4 aux routeurs PE distants. Les routes sont distribuées à l’aide de sessions IBGP, qui sont configurées dans le réseau central du fournisseur.
-
-
Si l’itinéraire 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 à partir d’un autre routeur PE (routeurs PE2 et PE3 dans la Figure 3), il utilise la procédure suivante pour traiter le routage :
-
Si la route est acceptée par la stratégie d’importation de la session IBGP entre les routeurs PE, le routeur PE distant place la route dans sa table bgp.l3vpn.0.
-
Le routeur PE distant vérifie la communauté cible de l’itinéraire par rapport à la stratégie d’importation VRF du VPN.
-
S’il correspond, le séparateur de route est supprimé de l’itinéraire et il est 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 dans ses tables VRF, qui sont 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
-
DÉCHIRER
-
BGP
-
Route statique
La figure 4 illustre la façon dont les trois routeurs PE annoncent leurs routes à leurs routeurs CE connectés.
CE
Comprendre les adresses VPN-IPv4 et les facteurs de routage distinctifs
Étant donné que les VPN de couche 3 connectent des réseaux privés, qui peuvent utiliser des adresses publiques ou privées, telles que définies 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 du VPN A et du 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 le chevauchement d’adresses privées, vous pouvez configurer les périphériques réseau pour qu’ils utilisent des adresses publiques plutôt que des 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, qui est une famille d’adresses BGP ajoutée en tant qu’extension du protocole BGP. Dans les adresses VPN-IPv4, une valeur qui identifie le VPN, appelée séparateur de route, est préfixée à 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 d’adresse VPN-IPv4 vers BGP. Lorsqu’un routeur PE entrant reçoit une route IPv4 d’un périphérique dans un VPN, il la convertit en route VPN-IPv4 en ajoutant le préfixe de distinction de route à la route. Les adresses VPN-IPv4 sont utilisées uniquement pour les routes échangées entre les routeurs PE. Lorsqu’un routeur PE sortant reçoit une route VPN-IPv4, il reconvertit la route VPN-IPv4 en route IPv4 en supprimant le distingueur de route avant d’annoncer la route à ses routeurs CE connectés.
Les adresses VPN-IPv4 ont le format suivant :
-
Route distinguisher est une valeur de 6 octets que vous pouvez spécifier dans l’un des formats suivants :
-
as-number:number, oùas-numberest un nombre AS (une valeur de 2 octets) etnumberest une valeur de 4 octets. Le nombre AS peut être compris entre 1 et 65 535. Nous vous recommandons d’utiliser un numéro AS non privé attribué par l’Internet Assigned Numbers Authority (IANA), de préférence le numéro AS du fournisseur d’accès à Internet (FAI) ou celui du client. -
ip-address:number, oùip-addressest une adresse IP (une valeur de 4 octets) etnumberest une valeur de 2 octets. L’adresse IP peut être n’importe quelle adresse unicast unique au monde. Nous vous recommandons d’utiliser l’adresse que vous configurez dans l’instruction, qui est une adresse non privée dans larouter-idplage de préfixes qui vous a été attribuée.
-
-
Adresse IPv4 : adresse de 4 octets d’un périphérique dans le VPN.
La figure 5 illustre comment le numéro AS peut être utilisé dans le séparateur d’itinéraire. Supposons que le VPN A se trouve dans l’AS 65535 et le VPN B dans l’AS 666 (ces deux numéros AS appartiennent au FAI), et supposons que la distinction de route pour le site 2 dans le VPN A est 65535:02 et que la distinction de route pour le site 2 dans le VPN B est 666:02. Lorsque le routeur PE2 reçoit une route du routeur CE dans le VPN A, il la convertit de son adresse IP 10.2.0.0 en une adresse VPN-IPv4 de 65535:02:10.2.0.0. Lorsque le routeur PE reçoit une route du VPN B, qui utilise le même espace d’adressage que le VPN A, il la convertit en une adresse VPN-IPv4 de 666:02:10.2.0.0.
Si l’adresse IP est utilisée dans le séparateur de route, supposons que l’adresse IP du routeur PE2 soit 172.168.0.1. Lorsque le routeur PE reçoit une route du VPN A, il la convertit en une adresse VPN-IPv4 de 172.168.0.1:0:10.2.0.0/16, et il convertit une route du VPN B en 172.168.0.0:1:10.2.0.0/16.
Les séparateurs de route sont utilisés uniquement entre les routeurs PE vers des adresses IPv4 provenant de différents VPN. Le routeur PE entrant crée un séparateur de route et convertit les routes IPv4 reçues des routeurs CE en adresses VPN-IPv4. Les routeurs PE de sortie 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 les sessions IBGP entre les paires de routeurs PE afin que ces derniers puissent distribuer les routes VPN-IPv4 au sein du réseau central du fournisseur. (Tous les routeurs PE sont supposés se trouver dans le même AS.)
Vous définissez des communautés BGP pour contraindre la distribution des routes entre les routeurs PE. La définition des communautés BGP ne permet pas, en soi, de distinguer les adresses IPv4.
La Figure 6 illustre comment le routeur PE1 ajoute le distinguateur de route 10458:22:10.1/16 aux routes reçues du routeur CE sur le site 1 dans le VPN A et transmet ces routes aux deux autres routeurs PE. De même, le routeur PE1 ajoute le différenciateur de route 10458:23:10.2/16 aux routes reçues par le routeur CE sur le site 1 dans le VPN B et transmet ces routes aux autres routeurs PE.
Configuration du transfert de paquets IPv4 pour les VPN de couche 3
Vous pouvez configurer le routeur pour qu’il prenne en charge le transfert de paquets pour le trafic IPv4 dans les VPN de couches 2 et 3. Le transfert de paquets est géré de l’une des manières suivantes, selon le 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 de l’instance de routage spécifiée. Le serveur reconnaît l’adresse du client et renvoie 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 de l’instance de routage spécifiée. Le serveur reconnaît l’adresse du client et envoie une réponse à l’adresse correcte du client dans l’instance de routage spécifiée.
Pour activer le transfert de paquets pour les VPN, incluez l’instruction helpers suivante :
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 instruction 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 se trouver dans le même VPN. Toutes les plates-formes de routage Juniper Networks sur lesquelles 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 activé instance-A est transféré 10.2.3.4 dans l’instance de instance-A routage, tandis qu’un paquet entrant est instance-B transféré dans l’instance de instance-B routage. D’autres services ne peuvent accepter qu’un seul serveur, de sorte que cette configuration ne s’applique pas dans ces cas.
Exemple : Configurer un VPN de couche 3 basé sur MPLS de base
Cet exemple montre comment configurer et valider un VPN de couche 3 basé sur MPLS de base sur des routeurs ou des commutateurs exécutant Junos OS. L’exemple basé sur IPv4 utilise EBGP comme protocole de routage entre le fournisseur et les équipements de périphérie 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 permettent généralement aux appareils des clients d’échanger des informations de routage avec le réseau du fournisseur et nécessitent la prise en charge des protocoles IP, à savoir IPv4 et/ou IPv6.
Cela contraste avec un VPN de couche 2, où les équipements client peuvent ne pas être basés sur des protocoles IP et où le routage, le cas échéant, s’effectue entre les équipements de périphérie client (CE). Contrairement à un VPN de couche 3 où l’appareil CE interagit (pairs) 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, tous les protocoles de routage s’exécutant de bout en bout entre les équipements CE.
Les VPN basés sur MPLS nécessitent une fonctionnalité MPLS de base dans le réseau du fournisseur. Une fois le MPLS de base 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 dans le réseau du fournisseur. En fait, les appareils du fournisseur (P) ne nécessitent qu’une configuration MPLS de base, car ils ne sont pas compatibles VPN. L’état VPN est conservé uniquement sur les appareils PE (Provider Edge). C’est l’une des principales raisons pour lesquelles les VPN basés sur MPLS sont si performants.
- Exigences
- Vue d’ensemble et topologie
- Configurations rapides
- Configurer le périphérique PE local (PE1) pour un VPN de couche 3 basé sur MPLS
- Configurer le périphérique PE distant (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 appareils Provider Edge (PE)
Un appareil fournisseur (P)
Deux appareils CE (Customer Edge)
L’exemple montre comment ajouter un VPN de couche 3 à une ligne de base MPLS préexistante. Une configuration MPLS de base est fournie si votre réseau n’a pas déjà déployé MPLS.
Pour prendre en charge les VPN MPLS, la ligne de base MPLS sous-jacente doit fournir les fonctionnalités suivantes :
Interfaces orientées cœur et bouclage opérationnelles avec prise en charge de la famille MPLS
Un protocole de passerelle intérieure tel qu’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 dispositifs PE
Des LSP sont nécessaires entre chaque paire d’appareils PE qui participent à un VPN donné. C’est une bonne idée de créer des LSP entre tous les appareils PE pour s’adapter à la croissance future des VPN. Vous configurez les LSP au niveau de la [edit protocols mpls] hiérarchie. Contrairement à une configuration MPLS pour une connexion CCC (Circuit Cross-Connect), vous n’avez pas besoin d’associer manuellement le LSP à l’interface client (périphérie) 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 le transfert LSP des sauts suivants. Cela signifie qu’avec un VPN de couche 3, il n’est pas nécessaire de mapper explicitement un LSP à l’interface de périphérie d’un périphérique PE.
Vue d’ensemble et topologie
Les VPN de couche 3 permettent aux clients de tirer parti de l’expertise technique du fournisseur de services pour assurer un routage efficace sur site. L’équipement CE (Customer Edge) utilise généralement un protocole de routage, tel que BGP ou OSPF, pour échanger des routes avec l’équipement PE (Service Provider Edge). 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 sur les périphériques PE locaux et distants. Aucune configuration supplémentaire n’est nécessaire sur les appareils du fournisseur (en supposant qu’ils disposent déjà d’une base MPLS fonctionnelle), car ces appareils ne fournissent que des fonctions de commutation MPLS de base. Les appareils CE n’utilisent pas MPLS et ne nécessitent qu’une interface de base et une configuration de protocole de routage pour pouvoir interagir avec les équipements PE.
Dans un VPN de couche 3, vous configurez les périphériques CE pour qu’ils s’appairent avec le périphérique PE local. Cela contraste avec un VPN de couche 2, où les appareils CE s’appairent les uns aux autres comme s’ils étaient sur une liaison partagée, bien qu’ils soient connectés via un cœur de fournisseur basé sur MPLS.
Une fois qu’une référence MPLS est en place, vous devez configurer les fonctionnalités suivantes sur les périphériques PE pour établir votre VPN de couche 3 basé sur MPLS :
Un groupe BGP avec
family inet-vpn unicastsupportUne instance de routage avec un type
vrfd’instance et une définition de protocole de routage compatible avec le dispositif CE attachéLes interfaces côté client sur les équipements PE configurés avec
family inetainsi qu’une adresse IPv4 qui place l’interface sur le même sous-réseau que l’équipement CE connecté. Si vous le souhaitez, vous pouvez également configurer une encapsulation VLAN et un ID de VLAN correspondant.
Pour une connectivité de bout en bout correcte, le périphérique 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 le périphérique 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 du fournisseur et du client. 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 avec le périphérique PE local. Notez que le réseau du fournisseur et les deux sites clients ont un numéro de système autonome attribué pour prendre en charge le fonctionnement BGP. Dans cet exemple, une stratégie de routage est appliquée aux équipements CE pour qu’ils annoncent les routes directes pour leurs interfaces côté fournisseur et de bouclage.
de routage PE-CE
Configurations rapides
Utilisez les configurations de cette section pour mettre rapidement en service votre VPN de couche 3 basé sur MPLS. Les configurations incluent 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 de la CLI
Les configurations de l’équipement omettent l’interface de gestion, les routes statiques, la journalisation système, les services système et les informations de connexion de l’utilisateur. Ces parties de la configuration varient selon l’emplacement et ne sont pas directement liées à la fonctionnalité MPLS ou VPN.
Modifiez les commandes suivantes selon vos besoins pour les spécificités de votre environnement et collez-les dans la fenêtre de terminal de périphérique CE (CE1) locale lorsque vous êtes en mode de configuration au niveau de la [edit] hiérarchie :
La configuration complète de l’appareil 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
La configuration complète pour l’appareil 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
La configuration complète de l’appareil 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’appareil 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’appareil 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 appareils 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 le périphérique PE local (PE1) pour un VPN de couche 3 basé sur MPLS
Cette section décrit les étapes nécessaires à la configuration de l’équipement PE1 pour cet exemple. L’accent est mis sur les appareils PE, car c’est là que se trouve la configuration VPN. Reportez-vous à la section Configurations rapides pour connaître les configurations des appareils CE et P utilisées dans cet exemple.
Configurer la ligne de base MPLS (si nécessaire)
Avant de configurer un VPN de couche 3, assurez-vous que l’appareil PE dispose d’une ligne de base MPLS fonctionnelle. Si vous disposez déjà d’une base de référence MPLS, vous pouvez passer à la procédure étape par étape pour ajouter le VPN de couche 3 aux périphériques PE.
Configurez le nom d’hôte.
[edit] user@pe1# set system host-name pe1
Configurez les interfaces principale 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
Bonne pratique :Bien qu’un VPN de couche 3 puisse effectuer une fragmentation au niveau du PE d’entrée, il est recommandé de concevoir le réseau de manière à ce que le CE puisse envoyer une trame de taille maximale sans avoir besoin de fragmentation. Pour éviter la 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 le périphérique PE. Cet exemple laisse les périphériques CE à l’unité de transmission maximale (MTU) par défaut de 1500 octets lors de la configuration du cœur du fournisseur pour prendre en charge une MTU de 4000 octets. Cela garantit que les équipements CE ne peuvent pas dépasser la MTU dans le réseau du fournisseur, même avec la surcharge d'encapsulation MPLS et VRF.
Configurez les protocoles :
Note:L’ingénierie de trafic est prise en charge pour les LSP avec signal RSVP, mais n’est pas requise pour la commutation MPLS de base ou le déploiement de VPN. La ligne de base MPLS fournie utilise RSVP pour signaler les LSP et active l’ingénierie de trafic pour OSPF. Cependant, aucune contrainte de chemin n'est configurée, de sorte que vous vous attendez à ce que les LSP soient acheminés sur le chemin le plus court du protocole Interior Gateway.
[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 sur l'adresse de bouclage du périphérique PE distant :
[edit] user@pe1# set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.3
La ligne de base MPLS est maintenant configurée sur l’équipement PE1. Continuez à configurer le VPN de couche 3.
Procédure
Procédure étape par étape
Procédez comme suit pour configurer l’appareil PE1 pour un VPN de couche 3.
Configurez l’interface côté client :
Pourboire:Vous pouvez configurer un VPN de couche 2 basé sur MPLS et un VPN de couche 3 basé sur MPLS sur le même périphérique PE. Toutefois, vous ne pouvez pas configurer la même interface client en périphérie 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 du périphérique PE comme adresse locale et activez la famille d’adresses pour prendre en charge l’échange
inet-vpn unicastde routes VPN de couche 3. Dans cet exemple, une stratégie de routage pour BGP n’est pas nécessaire sur les équipements PE. Par défaut, les périphériques PE annoncent à nouveau dans IBGP les routes qu’ils apprennent via leur appairage EBGP avec le périphérique 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
Pourboire: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, comme les routes IPv4 ou IPv6 normales utilisant respectivement les
inetfamilles ouinet6.Configurez le type de groupe BGP comme interne.
[edit protocols bgp] user@pe1# set group ibgp type internal
Configurez l’adresse de bouclage du périphérique 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’appareil 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 séparateur de route de l’instance de routage. Ce paramètre est utilisé pour distinguer les routes envoyées à partir d’un VRF particulier sur un périphérique 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 à tous les itinéraires annoncés tout en faisant automatiquement correspondre la même valeur pour l’importation d’itinéraires. Pour un échange de routes correct, il est nécessaire de configurer des cibles de route correspondantes sur les appareils 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 des 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 avec l’équipement CE1. L’appairage direct de l’interface à 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 au mode opérationnel CLI.
[edit] user@pe1# commit and-quit
Résultats
Affichez les résultats de la configuration sur l’équipement PE1. La sortie 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 le périphérique PE distant (PE2) pour un VPN de couche 3 basé sur MPLS
Cette section décrit les étapes nécessaires à la configuration de l’équipement PE1 pour cet exemple. L’accent est mis sur les appareils PE, car c’est là que se trouve la configuration VPN. Reportez-vous à la section Configurations rapides pour connaître les configurations des appareils CE et P utilisées dans cet exemple.
Configurer la ligne de base MPLS (si nécessaire)
Avant de configurer un VPN de couche 3, assurez-vous que l’appareil PE dispose d’une ligne de base MPLS fonctionnelle. Si vous disposez déjà d’une base de référence MPLS, vous pouvez passer à la procédure étape par étape pour ajouter le VPN de couche 3 aux périphériques PE.
Configurez le nom d’hôte.
[edit] user@pe2# set system host-name pe2
Configurez les interfaces principale 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
Bonne pratique :Bien qu’un VPN de couche 3 puisse effectuer une fragmentation au niveau du PE d’entrée, il est recommandé de concevoir le réseau de manière à ce que le CE puisse envoyer une trame de taille maximale sans avoir besoin de fragmentation. Pour éviter la 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 le périphérique PE. Cet exemple laisse les périphériques CE à l’unité de transmission maximale (MTU) par défaut de 1500 octets lors de la configuration du cœur du fournisseur pour prendre en charge une MTU de 4000 octets. Cela garantit que les équipements CE ne peuvent pas dépasser la MTU dans le réseau du fournisseur, même avec la surcharge d'encapsulation MPLS et VRF.
Configurez les protocoles :
Note:L’ingénierie de trafic est prise en charge pour les LSP avec signal RSVP, mais n’est pas requise pour la commutation MPLS de base ou le déploiement de VPN. La ligne de base MPLS fournie utilise RSVP pour signaler les LSP et active l’ingénierie de trafic pour OSPF. Cependant, aucune contrainte de chemin n'est configurée, de sorte que vous vous attendez à ce que les LSP soient acheminés sur le chemin le plus court du protocole Interior Gateway.
[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 sur l'adresse de bouclage du périphérique PE distant :
[edit] user@pe2# set protocols mpls label-switched-path lsp_to_pe1 to 192.168.0.1
La ligne de base MPLS est maintenant configurée sur l’équipement PE1. Continuez à configurer le VPN de couche 3.
Procédure
Procédure étape par étape
Procédez comme suit pour configurer l’appareil PE2 pour un VPN de couche 3.
Configurez l’interface côté client :
Pourboire:Vous pouvez configurer un VPN de couche 2 basé sur MPLS et un VPN de couche 3 basé sur MPLS sur le même périphérique PE. Toutefois, vous ne pouvez pas configurer la même interface client en périphérie 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 du périphérique 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
Pourboire: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, comme les routes IPv4 ou IPv6 normales utilisant respectivement les
inetfamilles ouinet6.Configurez le type de groupe BGP comme interne.
[edit protocols bgp] user@pe2# set group ibgp type internal
Configurez l’adresse de bouclage du périphérique 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’occurrence de CE2_L3vpn, avec un
instance-typedevrf.[edit routing-instances] user@pe2# set CE2_L3vpn instance-type vrf
Configurez l’interface client de l’appareil 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 séparateur de route de l’instance de routage. Ce paramètre est utilisé pour distinguer les routes envoyées à partir d’un VRF particulier sur un périphérique 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 à tous les itinéraires annoncés tout en faisant automatiquement correspondre la même valeur pour l’importation d’itinéraires. Pour un échange de routes correct, il est nécessaire de configurer des cibles de route correspondantes sur les appareils 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 des 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 qu’elle prenne en charge l’appairage EBGP avec l’équipement CE2. L’appairage direct de l’interface à l’extrémité CE2 de la liaison VRF est utilisé, et le numéro du 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 au mode opérationnel CLI.
[edit] user@pe2# commit and-quit
Résultats
Affichez les résultats de la configuration sur l’équipement PE2. La sortie 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 les tâches suivantes pour vérifier que le VPN de couche 3 basé sur MPLS fonctionne correctement :
- Vérifier les proximités OSPF du fournisseur et l’échange de routes
- Vérifiez les paramètres de l’interface MPLS et RSVP
- Vérifier les LSP signalés RSVP
- Vérification de l’état d’une session BGP
- Vérifier les routes VPN de couche 3 dans la table de routage
- Envoyez une requête ping au périphérique PE distant à l’aide de la connexion VPN de couche 3
- Vérifiez le fonctionnement de bout en bout des équipements CE sur le VPN de couche 3
- Comportement du VPN MPLS de couche 3 spécifique à la plate-forme
Vérifier les proximités OSPF du fournisseur et l’échange de routes
But
Vérifiez que le protocole OSPF fonctionne correctement dans le réseau du fournisseur en vérifiant l’état d’adjacence et les routes OSPF apprises vers les adresses de bouclage des appareils du fournisseur distant. Le bon fonctionnement des IGP est essentiel à la réussite de l’établissement 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
Signification
La sortie montre que le périphérique PE1 a établi une adjacence OSPF par rapport au périphérique P (192.168.0.2). Il montre également que les adresses de bouclage P et () du périphérique PE distant (192.168.0.2) et (192.168.0.3) sont correctement apprises via OSPF au niveau du périphérique PE local.
Vérifiez 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 permet également de vérifier qu’il family mpls est correctement configuré 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
Signification
La sortie indique que MPLS et RSVP sont correctement configurés sur les interfaces principale et de bouclage de l’équipement PE local.
Vérifier les LSP signalés RSVP
But
Vérifiez que les LSP d’entrée et de sortie signalés RSVP 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
Signification
La sortie indique que les sessions RSVP d’entrée et de sortie sont correctement établies entre les appareils PE. La réussite de l’établissement d’un prestataire de services linguistiques indique que la base de référence MPLS est opérationnelle.
Vérification de l’état d’une session BGP
But
Vérifiez que la session IBGP entre les périphériques PE est correctement établie avec la prise en charge des informations d’accessibilité de la couche réseau (NLRI) VPN de couche 3. Au cours de cette étape, vous confirmez également que la session EBGP PE vers CE locale est é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
Signification
La sortie indique que la session IBGP vers le périphérique PE distant (192.168.0.3) a été correctement établie (Establ) et, via le Up/Dwn champ, depuis combien de temps la session est dans l’état actuel (6:18). Le flaps champ confirme qu’aucune transition d’état n’a eu lieu (0), ce qui indique 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’écran confirme également que la session EBGP vers le périphérique CE1 local (172.16.1.1) est établie et que des routes IPv4 ont été reçues du périphérique CE1 et installées dans l’instance de routage du périphérique CE1 (CE1_L3vpn.inet.0)
Cette sortie confirme que l’appairage BGP entre les périphériques PE et vers 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 sur l’équipement PE1 est remplie avec les routes VPN de couche 3 annoncées par le PE distant. Ces routes sont utilisées pour 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
Signification
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 itinéraires qui ont été importés dans l’instance de CE1_L3vpn routage. Ces entrées représentent les routes apprises de l’appairage EBGP local avec l’équipement CE1, en plus des routes reçues de l’équipement PE2 distant avec une cible de route correspondante.
Les deux tableaux montrent que les routes VPN de couche 3 distantes sont correctement associées au lsp_to_pe2 LSP en tant que prochain saut de transfert. Les sorties confirment que le périphérique PE local a appris les routes associées à l’emplacement CE2 distant à partir du périphérique 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.
Envoyez une requête ping au périphérique PE distant à l’aide de la connexion VPN de couche 3
But
Vérifiez la connectivité VPN de couche 3 entre les périphériques PE locaux et distants à l’aide de ping. Cette commande vérifie l’opération de routage VPN de couche 3 et de transfert MPLS entre les périphériques 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
Signification
La sortie confirme que les plans de contrôle et de transfert du VPN de couche 3 fonctionnent correctement entre les périphériques PE.
Vérifiez 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 périphériques CE. Cette étape confirme que les équipements CE disposent d’interfaces opérationnelles et qu’ils sont correctement configurés pour la connectivité de couche 3 basée sur EBGP. Pour ce faire, vérifiez que le périphérique CE1 local a appris les itinéraires du périphérique CE distant et que les périphériques CE sont capables de transmettre 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
Signification
La sortie montre que la connectivité basée sur le VPN de couche 3 fonctionne correctement entre les périphériques CE. Le périphérique CE local a appris l’interface VRF et les routes de bouclage du périphérique CE distant via BGP. Le ping est généré à l’adresse de bouclage du périphérique CE distant et provient de l’adresse de bouclage du périphérique 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 périphériques CE sont capables de transmettre des paquets IP de 1 500 octets sans provoquer de fragmentation dans le périphérique PE local.
L’argument size 1472 ajouté à la ping commande génère 1472 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 à 1500 octets. L’ajout du do-not-fragment commutateur garantit que les périphériques 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 longueur maximale de 1500 octets entre les périphériques CE.
Ces résultats confirment que le VPN de couche 3 basé sur MPLS fonctionne correctement.
Comportement du VPN MPLS de couche 3 spécifique à la plate-forme
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.
Utilisez le tableau suivant pour passer en revue les comportements spécifiques à votre plateforme.
| Plateforme |
Différence |
|---|---|
| Routeurs ACX série 7000 |
|