SUR CETTE PAGE
Configuration du routage entre les routeurs PE et CE dans les VPN de couche 3
Configuration d’un ID de domaine OSPF pour un VPN de couche 3
Configuration des sessions EBGP multi-sauts entre les routeurs PE et CE dans les VPN de couche 3
Configuration d’une topologie VPN de couche 3 basée sur les applications
Configuration du routage entre les routeurs PE et CE
Cette rubrique fournit des informations sur la configuration du routage sur les routeurs PE et CE \ dans un VPN de couche 3.
Configuration du routage entre les routeurs PE et CE dans les VPN de couche 3
Pour que le routeur PE puisse distribuer des routes liées au VPN vers et depuis les routeurs CE connectés, vous devez configurer le routage dans l’instance de routage VPN. Vous pouvez configurer un protocole de routage (BGP, OSPF ou RIP) ou un routage statique. Pour la connexion à chaque routeur CE, vous ne pouvez configurer qu’un seul type de routage.
Les sections suivantes expliquent comment configurer le routage VPN entre les routeurs PE et CE :
- Configuration de BGP entre les routeurs PE et CE
- Configuration d’OSPF entre les routeurs PE et CE
- Configuration des liens fictifs OSPF pour les VPN de couche 3
- Configuration d’un ID de domaine OSPF
- Configuration du protocole RIP entre les routeurs PE et CE
- Configuration des routes statiques entre les routeurs PE et CE
Configuration de BGP entre les routeurs PE et CE
Pour configurer BGP en tant que protocole de routage entre les routeurs PE et CE, incluez l’instruction bgp suivante :
bgp {
group group-name {
peer-as as-number;
neighbor ip-address;
}
}
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Note:Le
[edit logical-systems]niveau hiérarchique ne s’applique pas aux routeurs ACX Series.Veuillez tenir compte des limitations suivantes concernant la configuration de BGP pour les instances de routage :
Dans une instance de routage VRF, ne configurez pas le numéro du système autonome local (AS) à l’aide d’un numéro AS déjà utilisé par un pair BGP distant dans une instance de routage VRF distincte. Cela crée une boucle système autonome dans laquelle toutes les routes reçues de cet homologue pair BGP distant sont masquées.
Vous configurez le numéro AS local à l’aide de l’instruction
autonomous-systemau niveau de la[edit routing-instances routing-instance-name routing-options]hiérarchie ou de l’instructionlocal-asà l’un des niveaux hiérarchiques suivants :[edit routing-instances routing-instance-name protocols bgp][edit routing-instances routing-instance-name protocols bgp group group-name][edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]
Vous configurez le numéro AS d’un pair BGP à l’aide de l’instruction
peer-asau niveau de la[edit routing-instances routing-instance-name protocols bgp group group-name]hiérarchie.
Configuration d’OSPF entre les routeurs PE et CE
Vous pouvez configurer OSPF (version 2 ou version 3) pour distribuer les routes liées au VPN entre les routeurs PE et CE.
Les sections suivantes décrivent comment configurer OSPF en tant que protocole de routage entre les routeurs PE et CE :
- Configuration d’OSPF version 2 entre les routeurs PE et CE
- Configuration d’OSPF version 3 entre les routeurs PE et CE
Configuration d’OSPF version 2 entre les routeurs PE et CE
Pour configurer OSPF version 2 en tant que protocole de routage entre un routeur PE et CE, incluez l’instruction ospf suivante :
ospf {
area area {
interface interface-name;
}
}
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Note:Le
[edit logical-systems]niveau hiérarchique ne s’applique pas aux routeurs ACX Series.
Configuration d’OSPF version 3 entre les routeurs PE et CE
Pour configurer OSPF version 3 en tant que protocole de routage entre un routeur PE et CE, incluez l’instruction ospf3 suivante :
ospf3 {
area area {
interface interface-name;
}
}
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Note:Le
[edit logical-systems]niveau hiérarchique ne s’applique pas aux routeurs ACX Series.
Configuration des liens fictifs OSPF pour les VPN de couche 3
Lorsque vous configurez OSPF entre les routeurs PE et CE d’un VPN de couche 3, vous pouvez également configurer des liaisons fictives OSPF pour compenser les problèmes liés aux liaisons intra-zone OSPF.
Les sections suivantes décrivent les liens fictifs OSPF et expliquent comment les configurer :
- Vue d’ensemble des liens OSPF Sham
- Configuration des liens fictifs OSPF
- Exemple de liens fictifs OSPF
Vue d’ensemble des liens OSPF Sham
La figure 1 illustre le moment où vous pouvez configurer un lien fictif OSPF. Les routeurs CE1 et CE2 sont situés dans la même zone OSPF. Ces routeurs CE sont reliés entre eux par un VPN de couche 3 sur les routeurs PE1 et PE2. De plus, les routeurs CE1 et CE2 sont connectés par une liaison intra-zone utilisée comme liaison de secours.
OSPF traite la liaison via le VPN de couche 3 comme une liaison interzone. Par défaut, OSPF préfère les liens intra-zone aux liens inter-zones, de sorte qu’OSPF sélectionne le lien intra-zone de secours comme chemin actif. Ceci n’est pas acceptable dans les configurations où la liaison intra-zone n’est pas le chemin principal attendu pour le trafic entre les routeurs CE.
Une liaison fictive OSPF est également une liaison intra-zone, sauf qu’elle est configurée entre les routeurs PE, comme illustré à la Figure 1. Vous pouvez configurer la métrique de la liaison fictive pour vous assurer que le chemin d’accès sur le VPN de couche 3 est préféré à un chemin de secours sur une liaison intra-zone reliant les routeurs CE.
Sham OSPF
Vous devez configurer un lien fictif OSPF dans les circonstances suivantes :
-
Deux routeurs CE sont reliés entre eux par un VPN de couche 3.
-
Ces routeurs CE se trouvent dans la même zone OSPF.
-
Une liaison intra-zone est configurée entre les deux routeurs CE.
S’il n’existe pas de liaison intra-zone entre les routeurs CE, vous n’avez pas besoin de configurer une liaison fictive OSPF.
Pour plus d’informations sur les liaisons fictives OSPF, reportez-vous au projet de draft-ietf-l3vpn-ospf-2547-01.txt Internet, OSPF as the PE/CE Protocol in BGP/VPN MPLS.
Configuration des liens fictifs OSPF
Le lien fictif est un lien intra-zone point à point non numéroté et est annoncé au moyen d’une annonce d’état de lien (LSA) de type 1. Les liens fictifs sont valides uniquement pour les instances de routage et OSPF version 2.
Chaque liaison fictive est identifiée par une combinaison de l’adresse du point d’extrémité de la liaison fictive locale et distante et de la zone OSPF à laquelle elle appartient. Les liens fictifs doivent être configurés manuellement. Vous configurez le lien fictif entre deux routeurs PE, qui se trouvent tous deux dans la même instance de routage VRF.
Vous devez spécifier l’adresse du point de terminaison local de la liaison fictive. Cette adresse est utilisée comme source pour les paquets de liaison fictive et est également utilisée par le routeur PE distant comme point de terminaison distant de liaison fictive.
L’adresse locale du lien fictif OSPF doit être spécifiée avec une adresse de bouclage pour le VPN local. Le routage vers cette adresse doit être propagé par BGP. Spécifiez l’adresse du point de terminaison local à l’aide de l’option local de l’instruction sham-link :
sham-link { local address; }
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
[modifier les protocoles d’instances routing-instance-name de routage OSPF]
[modifier les protocoles d’instances routing-instance-name de routage des systèmes logical-system-name logiques OSPF]
L’adresse distante du lien fictif OSPF doit être spécifiée avec une adresse de bouclage pour le VPN distant. Le routage vers cette adresse doit être propagé par BGP. Pour spécifier l’adresse du point de terminaison distant, incluez l’instruction sham-link-remote :
sham-link-remote address <metric number>;
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
[modifier la zone area-idospf des protocoles d’instances routing-instance-name de routage]
[modifier la zone ospf des area-idinstances routing-instance-name de routage des systèmes logical-system-name logiques ]
Si vous le souhaitez, vous pouvez inclure l’option de mesure pour définir une valeur de mesure pour le point de terminaison distant. La valeur de la métrique spécifie le coût d’utilisation du lien. Les itinéraires avec des métriques de chemin total inférieures sont préférés à ceux avec des métriques de chemin plus élevées.
Vous pouvez configurer une valeur comprise entre 1 et 65 535. La valeur par défaut est 1.
Exemple de liens fictifs OSPF
Cet exemple montre comment activer des liaisons fictives OSPF sur un routeur PE.
Voici la configuration de l’interface de bouclage sur le routeur PE. L’adresse configurée correspond au point de terminaison local de la liaison fictive OSPF :
[edit]
interfaces {
lo0 {
unit 1 {
family inet {
address 10.1.1.1/32;
}
}
}
}
Voici la configuration de l’instance de routage sur le routeur PE, y compris la configuration de la liaison fictive OSPF. L’instruction locale sham-link est configurée avec l’adresse de l’interface de bouclage locale :
[edit]
routing-instances {
example-sham-links {
instance-type vrf;
interface e1-1/0/2.0;
interface lo0.1;
route-distinguisher 3:4;
vrf-import vpn-red-import;
vrf-export vpn-red-export;
protocols {
ospf {
sham-link local 10.1.1.1;
area 0.0.0.0 {
sham-link-remote 10.2.2.2 metric 1;
interface e1-1/0/2.0 metric 1;
}
}
}
}
}
Configuration d’un ID de domaine OSPF
Pour la plupart des configurations OSPF impliquant des VPN de couche 3, vous n’avez pas besoin de configurer un ID de domaine OSPF. Toutefois, pour un VPN de couche 3 connectant plusieurs domaines OSPF, la configuration d’ID de domaine OSPF peut vous aider à contrôler la traduction LSA (pour les LSA de type 3 et de type 5) entre les domaines OSPF et les chemins de porte dérobée. Chaque table de routage et de transfert VPN (VRF) d’un routeur PE associée à une instance OSPF est configurée avec le même ID de domaine OSPF. L’ID de domaine OSPF par défaut est la valeur null 0.0.0.0. Comme le montre le tableau 1, une route avec un ID de domaine nul est traitée différemment d’une route sans ID de domaine.
Route reçue |
ID de domaine de la route reçue |
ID de domaine sur le routeur de réception |
Route redistribuée et annoncée en tant que |
|---|---|---|---|
Itinéraire de type 3 |
A.B.C.D |
A.B.C.D |
Type 3 LSA |
Itinéraire de type 3 |
A.B.C.D |
E.F.G.H |
Type 5 LSA |
Itinéraire de type 3 |
0.0.0.0 |
0.0.0.0 |
Type 3 LSA |
Itinéraire de type 3 |
Zéro |
0.0.0.0 |
Type 3 LSA |
Itinéraire de type 3 |
Zéro |
Zéro |
Type 3 LSA |
Itinéraire de type 3 |
0.0.0.0 |
Zéro |
Type 3 LSA |
Itinéraire de type 3 |
A.B.C.D |
Zéro |
Type 5 LSA |
Itinéraire de type 3 |
Zéro |
A.B.C.D |
Type 3 LSA |
Itinéraire de type 5 |
Sans objet |
Sans objet |
Type 5 LSA |
Vous pouvez configurer un ID de domaine OSPF pour les versions 2 et 3 d’OSPF. La seule différence dans la configuration est que vous incluez des instructions au niveau de la hiérarchie [edit routing-instances routing-instance-name protocols ospf] pour OSPF version 2 et au niveau hiérarchique [edit routing-instances routing-instance-name protocols ospf3] pour OSPF version 3. Les descriptions de configuration qui suivent présentent uniquement l’instruction OSPF version 2. Toutefois, les sous-déclarations sont également valables pour OSPF version 3.
Pour configurer un ID de domaine OSPF, incluez l’instruction domain-id :
domain-id domain-Id;
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
[modifier les protocoles d’instances routing-instance-name de routage OSPF]
[modifier les protocoles d’instances routing-instance-name de routage des systèmes logical-system-name logiques OSPF]
Vous pouvez définir une balise VPN pour les routes externes OSPF générées par le routeur PE afin d’éviter la boucle. Par défaut, cette balise est calculée automatiquement et ne nécessite aucune configuration. Toutefois, vous pouvez configurer explicitement la balise VPN de domaine pour les LSA de type 5 en incluant l’instruction domain-vpn-tag :
no-domain-vpn-tag number;
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
[modifier les protocoles d’instances routing-instance-name de routage OSPF]
[modifier les protocoles d’instances routing-instance-name de routage des systèmes logical-system-name logiques OSPF]
La plage est comprise entre 1 et 4 294 967 295 (232 – 1). Si vous définissez manuellement des balises VPN, vous devez définir la même valeur pour tous les routeurs PE du VPN.
Pour obtenir un exemple de ce type de configuration, consultez Configuration d’un ID de domaine OSPF pour un VPN de couche 3.
VPN de couche 3 et ID de domaine OSPF en étoile
Le comportement par défaut d’un ID de domaine OSPF entraîne des problèmes pour les VPN de couche 3 en étoile configurés avec OSPF entre le routeur PE du hub et le routeur CE du hub lorsque les routes ne sont pas agrégées. Une configuration en étoile dispose d’un routeur PE de moyeu avec des liens directs vers un routeur CE de moyeu. Le routeur Hub PE reçoit les mises à jour BGP de couche 3 des autres routeurs Spoke PE distants, et celles-ci sont importées dans l’instance de routage spoke. À partir de l’instance de routage spoke, les LSA OSPF proviennent et sont envoyés au routeur CE du concentrateur.
En règle générale, le routeur CE du hub agrège ces routes, puis renvoie ces LSA nouvellement créés au routeur PE du hub. Le routeur PE du hub exporte les mises à jour BGP vers les routeurs PE spoke distants contenant les préfixes agrégés. Toutefois, s’il existe des LSA récapitulatifs de type 3 non agrégés ou des LSA externes, deux problèmes se posent en ce qui concerne la façon dont le routeur PE du hub émet et envoie les LSA au routeur CE du hub, et la façon dont le routeur PE du hub traite les LSA reçus du routeur CE du hub :
Par défaut, le bit DN est défini sur tous les LSA émis par le routeur hub PE dans l’instance de routage spoke. De plus, la balise de routage VPN est définie sur tous les LSA d’origine externe. La définition du bit DN et de la balise de routage VPN permet d’éviter les boucles de routage. Pour les LSA récapitulatifs de type 3, les boucles de routage ne posent pas de problème, car le routeur CE du concentrateur, en tant que routeur de bordure de zone (ABR), réinitie les LSA avec le bit DN effacé et les renvoie au routeur PE du concentrateur. Toutefois, le routeur CE du hub ne réémet pas de LSA externes, car ils ont une portée d’inondation AS.
Vous pouvez créer les LSA externes (avant de les envoyer au routeur CE du hub) avec le bit DN effacé et la balise de routage VPN définie sur 0 en modifiant la configuration de l’instance de routage du routeur PE du hub. Pour effacer le bit DN et définir la balise de routage VPN sur zéro sur les LSA externes provenant d’un routeur PE, configurez 0 pour l’instruction domain-vpn-tag au niveau de la hiérarchie [edit routing-instances routing-instance-name protocols ospf]. Vous devez inclure cette configuration dans l’instance de routage sur le routeur PE du hub face au routeur CE du hub où les LSA sont envoyés. Lorsque le routeur CE du hub reçoit des LSA externes du routeur PE du hub et les renvoie ensuite au routeur PE du hub, le routeur PE du hub peut utiliser les LSA dans son calcul de routage OSPF.
Lorsque les LSA inondés par le routeur CE du hub arrivent à l’instance de routage du routeur PE du hub, le routeur PE du hub, agissant en tant qu’ABR, ne prend pas en compte ces LSA dans ses calculs de routage OSPF, même si les LSA n’ont pas les bits DN définis et que les LSA externes n’ont pas de balise de routage VPN définie. Les LSA sont supposés provenir d’une zone de dorsale disjointe.
Vous pouvez modifier la configuration de l’instance de routage du routeur PE pour que le routeur PE agisse en tant que non-ABR en incluant l’instruction disable au niveau de la hiérarchie [edit routing-instances routing-instance-name protocols ospf domain-id]. Vous apportez cette modification de configuration au routeur PE du hub qui reçoit les LSA du routeur CE du hub.
En apportant cette modification de configuration, l’instance de routage du routeur PE agit comme un non-ABR. Le routeur PE considère alors les LSA arrivant du routeur CE du hub comme s’ils provenaient d’une zone contiguë non dorsale.
Configuration du protocole RIP entre les routeurs PE et CE
Pour un VPN de couche 3, vous pouvez configurer RIP sur le routeur PE pour apprendre les routes du routeur CE ou pour propager les routes du routeur PE au routeur CE. Les routes RIP apprises à partir de voisins configurés à n’importe quel [edit routing-instances] niveau hiérarchique sont ajoutées à la table de l’instance de inet routage (instance_name.inet.0).
Pour configurer RIP en tant que protocole de routage entre le PE et le routeur CE, incluez l’instruction rip suivante :
rip {
group group-name {
export policy-names;
neighbor interface-name;
}
}
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Note:Le
[edit logical-systems]niveau hiérarchique ne s’applique pas aux routeurs ACX Series.
Par défaut, RIP n’annonce pas les itinéraires qu’il reçoit. Pour annoncer des routes d’un routeur PE vers un routeur CE, vous devez configurer une stratégie d’exportation sur le routeur PE pour RIP. Pour plus d’informations sur la définition des stratégies RIP, consultez Stratégie d’importation RIP.
Pour spécifier une stratégie d’exportation pour RIP, incluez l’instruction export suivante :
export [ policy-names ];
Vous pouvez inclure cette instruction pour RIP aux niveaux hiérarchiques suivants :
[edit routing-instances routing-instance-name protocols rip group group-name][edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name]Note:Le
[edit logical-systems]niveau hiérarchique ne s’applique pas aux routeurs ACX Series.
Pour installer des routes apprises à partir d’une instance de routage RIP dans plusieurs tables de routage, incluez les rib-group instructions et group :
rib-group inet group-name;
group group-name {
neighbor interface-name;
}
Vous pouvez inclure ces instructions aux niveaux hiérarchiques suivants :
[edit protocols rip][edit routing-instances routing-instance-name protocols rip][edit logical-systems logical-system-name protocols rip][edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip]
Le [edit logical-systems] niveau hiérarchique ne s’applique pas aux routeurs ACX Series.
Pour configurer un groupe de tables de routage, incluez l’instruction rib-groups suivante :
rib-groups group-name;
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
[edit routing-options][edit logical-systems logical-system-name routing-options]
Le [edit logical-systems] niveau hiérarchique ne s’applique pas aux routeurs ACX Series.
Pour ajouter une table de routage à un groupe de tables de routage, incluez l’instruction import-rib . Le premier nom de la table de routage spécifié sous l’instruction import-rib doit être le nom de la table de routage que vous configurez. Pour plus d’informations sur la configuration des tables de routage et des groupes de tables de routage, reportez-vous à la section Bibliothèque de protocoles de routage Junos OS.
import-rib [ group-names ];
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
[edit routing-options rib-groups group-name][edit logical-systems logical-system-name routing-options rib-groups group-name]
Le [edit logical-systems] niveau hiérarchique ne s’applique pas aux routeurs ACX Series.
Les instances RIP ne sont prises en charge que pour les types d’instances VRF. Vous pouvez configurer plusieurs instances de RIP pour la prise en charge VPN uniquement. Vous pouvez utiliser le protocole RIP dans l’environnement CE-PE (customer edge-provider edge) pour apprendre les routes du routeur CE et pour propager les routes d’instance du routeur PE dans le routeur CE.
Les routes RIP apprises des voisins configurés sous n’importe quelle hiérarchie d’instance sont ajoutées à la table de routage de l’instance. instance-name.inet.0
RIP ne prend pas en charge les groupes de tables de routage ; par conséquent, il ne peut pas importer de routes dans plusieurs tables comme le fait le protocole OSPF ou OSPFv3.
Configuration des routes statiques entre les routeurs PE et CE
Vous pouvez configurer des routes statiques (non modifiables) entre les routeurs PE et CE d’une instance de routage VPN. Pour configurer une route statique pour un VPN, vous devez la configurer dans la configuration de l’instance de routage VPN au niveau de la [edit routing-instances routing-instance-name routing-options] hiérarchie.
Pour configurer une route statique entre les routeurs PE et CE, incluez l’instruction static suivante :
static {
route destination-prefix {
next-hop [ next-hops ];
static-options;
}
}
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
[edit routing-instances routing-instance-name routing-options][edit logical-systems logical-system-name routing-instances routing-instance-name routing-options]
Le [edit logical-systems] niveau hiérarchique ne s’applique pas aux routeurs ACX Series.
Pour plus d’informations sur la configuration des protocoles de routage et des routes statiques, reportez-vous à la section Bibliothèque de protocoles de routage Junos OS.
Configuration d’un ID de domaine OSPF pour un VPN de couche 3
Cet exemple illustre comment configurer un ID de domaine OSPF pour un VPN en utilisant OSPF comme protocole de routage entre les routeurs PE et CE. Les routes provenant d’un domaine OSPF ont besoin d’un ID de domaine OSPF lorsqu’elles sont distribuées dans BGP en tant que routes VPN-IPv4 dans des VPN comportant plusieurs domaines OSPF. Dans un VPN connectant plusieurs domaines OSPF, les routes d’un domaine peuvent chevaucher les routes d’un autre.
L’ID de domaine configuré dans une instance de routage identifie le domaine OSPF et est utilisé pour identifier l’origine de la route. L’ID de domaine configuré sur une stratégie de communauté est utilisé pour définir les routes exportées.
Pour plus d’informations sur les ID de domaine OSPF et les VPN de couche 3, consultez Configuration du routage entre les routeurs PE et CE dans les VPN de couche 3.
La figure 2 illustre la topologie de configuration de cet exemple. Seule la configuration du routeur PE1 est fournie. La configuration du routeur PE2 peut être similaire à celle du routeur PE1. Il n’y a pas d’exigences de configuration particulières pour les routeurs CE.
de domaine OSPF
Pour plus d’informations sur la configuration, consultez les sections suivantes :
- Configuration des interfaces sur le routeur PE1
- Configuration des options de routage sur le routeur PE1
- Configuration des protocoles sur le routeur PE1
- Configuration des options de stratégie sur le routeur PE1
- Configuration de l’instance de routage sur le routeur PE1
- Récapitulatif de la configuration du routeur PE1
Configuration des interfaces sur le routeur PE1
Vous devez configurer deux interfaces pour le routeur PE1 : l’interface pour le trafic vers le so-0/0/0 routeur CE1 (San Francisco) et l’interface pour le so-0/0/1 trafic vers un routeur P dans le réseau du fournisseur de services.
Configurez les interfaces pour le routeur PE1 :
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.19.1.2/30;
}
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.19.2.1/30;
}
family mpls;
}
}
}
Configuration des options de routage sur le routeur PE1
Au niveau de la [edit routing-options] hiérarchie, vous devez configurer les router-id instructions and autonomous-system . L’instruction router-id identifie le routeur PE1.
Configurez les options de routage pour le routeur PE1 :
[edit]
routing-options {
router-id 10.255.14.216;
autonomous-system 65069;
}
Configuration des protocoles sur le routeur PE1
Sur le routeur PE1, vous devez configurer MPLS, BGP, OSPF et LDP au niveau de la [edit protocols] hiérarchie :
[edit]
protocols {
mpls {
interface so-0/0/1.0;
}
bgp {
group San-Francisco-Chicago {
type internal;
preference 10;
local-address 10.255.14.216;
family inet-vpn {
unicast;
}
neighbor 10.255.14.224;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/1.0;
}
}
ldp {
interface so-0/0/1.0;
}
}
Configuration des options de stratégie sur le routeur PE1
Sur le routeur PE1, vous devez configurer les stratégies au niveau de la [edit policy-options] hiérarchie. Ces stratégies garantissent que les routeurs CE du VPN de couche 3 échangent les informations de routage. Dans cet exemple, le routeur CE1 à San Francisco échange des informations de routage avec le routeur CE2 à Chicago.
Configurez les options de stratégie sur le routeur PE1 :
[edit]
policy-options {
policy-statement vpn-import-VPN-A {
term term1 {
from {
protocol bgp;
community import-target-VPN-A;
}
then accept;
}
term term2 {
then reject;
}
}
policy-statement vpn-export-VPN-A {
term term1 {
from protocol ospf;
then {
community add export-target-VPN-A;
accept;
}
}
term term2 {
then reject;
}
}
community export-target-VPN-A members [target:10.255.14.216:11 domain-id:192.0.2.1:0];
community import-target-VPN-A members target:10.255.14.224:31;
}
Configuration de l’instance de routage sur le routeur PE1
Vous devez configurer une instance de routage VPN de couche 3 sur le routeur PE1. Pour indiquer que l’instance de routage est destinée à un VPN de couche 3, ajoutez l’instruction instance-type vrf au niveau de la [edit routing-instance routing-instance-name] hiérarchie.
L’instruction domain-id est configurée au niveau de la [edit routing-instances routing-options protocols ospf] hiérarchie. Comme illustré sur la Figure 2, l’instance de routage sur le routeur PE2 doit partager le même ID de domaine que l’instance de routage correspondante sur le routeur PE1 afin que les routes du routeur CE1 vers le routeur CE2 et vice versa soient distribuées en tant que LSA de type 3. Si vous configurez des ID de domaine OSPF différents dans les instances de routage pour les routeurs PE1 et PE2, les routes de chaque routeur CE seront distribuées en tant que LSA de type 5.
Configurez l’instance de routage sur le routeur PE1 :
[edit]
routing-instances {
VPN-A-San-Francisco-Chicago {
instance-type vrf;
interface so-0/0/0.0;
route-distinguisher 10.255.14.216:11;
vrf-import vpn-import-VPN-A;
vrf-export vpn-export-VPN-A;
routing-options {
router-id 10.255.14.216;
}
protocols {
ospf {
domain-id 192.0.2.1;
export vpn-import-VPN-A;
area 0.0.0.0 {
interface so-0/0/0.0;
}
}
}
}
}
Récapitulatif de la configuration du routeur PE1
Configurer les interfaces
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.19.1.2/30;
}
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.19.2.1/30;
}
family mpls;
}
}
}
Configurer les options de routage
routing-options {
router-id 10.255.14.216;
autonomous-system 65069;
}
Configurer les protocoles
protocols {
mpls {
interface so-0/0/1.0;
}
bgp {
group San-Francisco-Chicago {
type internal;
preference 10;
local-address 10.255.14.216;
family inet-vpn {
unicast;
}
neighbor 10.255.14.224;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/1.0;
}
}
ldp {
interface so-0/0/1.0;
}
}
Configurer la stratégie VPN
policy-options {
policy-statement vpn-import-VPN-A {
term term1 {
from {
protocol bgp;
community import-target-VPN-A;
}
then accept;
}
term term2 {
then reject;
}
}
policy-statement vpn-export-VPN-A {
term term1 {
from protocol ospf;
then {
community add export-target-VPN-A;
accept;
}
}
term term2 {
then reject;
}
}
community export-target-VPN-A members [ target:10.255.14.216:11 domain-id:192.0.2.1:0 ];
community import-target-VPN-A members target:10.255.14.224:31;
}
Instance de routage pour VPN de couche 3
routing-instances {
VPN-A-San-Francisco-Chicago {
instance-type vrf;
interface so-0/0/0.0;
route-distinguisher 10.255.14.216:11;
vrf-import vpn-import-VPN-A;
vrf-export vpn-export-VPN-A;
routing-options {
router-id 10.255.14.216;
}
protocols {
ospf {
domain-id 192.0.2.1;
export vpn-import-VPN-A;
area 0.0.0.0 {
interface so-0/0/0.0;
}
}
}
}
}
Vue d’ensemble des liens fictifs OSPFv2OSPFv2 Sham Links
Vous pouvez créer un lien intra-zone ou un lien fictif entre deux périphériques de routage Provider Edge (PE) afin que la dorsale VPN soit préférée à la liaison de porte dérobée. Un lien de porte dérobée est un lien de secours qui connecte les périphériques CE (Customer Edge) au cas où le réseau dorsal VPN ne serait pas disponible. Lorsqu’une telle liaison de secours est disponible et que les périphériques CE se trouvent dans la même zone OSPF, le comportement par défaut est de préférer cette liaison de sauvegarde à la dorsale VPN. En effet, la liaison de secours est considérée comme une liaison intra-zone, tandis que la dorsale VPN est toujours considérée comme une liaison interzone. Les liens intra-zone sont toujours préférés aux liens inter-zones.
La liaison simulée est une liaison intra-zone point à point non numérotée entre des dispositifs PE. Lorsque le réseau dorsal VPN dispose d’une liaison intra-zone fictive, cette liaison fictive peut être préférée à la liaison de secours si la métrique OSPF de la liaison de secours est inférieure à celle de la liaison de secours.
Le lien fictif est annoncé à l’aide d’annonces d’état de lien (LSA) de type 1. Les liens fictifs sont valides uniquement pour les instances de routage et OSPFv2.
Chaque liaison fictive est identifiée par la combinaison d’une adresse de point de terminaison locale et d’une adresse de point de terminaison distante. La figure 3 montre un lien fictif OSPFv2. Les routeurs CE1 et CE2 sont situés dans la même zone OSPFv2. Ces périphériques de routage CE sont reliés entre eux par un VPN de couche 3 sur les routeurs PE1 et PE2. De plus, les routeurs CE1 et CE2 sont connectés par une liaison intra-zone utilisée comme liaison de secours.
Sham OSPFv2
OSPFv2 traite la liaison via le VPN de couche 3 comme une liaison interzone. Par défaut, OSPFv2 préfère les liens intra-zone aux liens inter-zone, de sorte qu’OSPFv2 sélectionne le lien intra-zone de secours comme chemin actif. Ceci n’est pas acceptable dans une configuration où la liaison intra-zone n’est pas le chemin principal attendu pour le trafic entre les périphériques de routage CE. Vous pouvez configurer la métrique de la liaison fictive pour vous assurer que le chemin sur le VPN de couche 3 est préféré à un chemin de secours sur une liaison intra-zone reliant les périphériques de routage CE.
Pour le point de terminaison distant, vous pouvez configurer l’interface OSPFv2 en tant que circuit de demande, configurer l’authentification IPsec (vous configurez l’authentification IPsec réelle séparément) et définir la valeur de la métrique.
Vous devez configurer un lien fictif OSPFv2 dans les circonstances suivantes :
Deux appareils de routage CE sont reliés entre eux par un VPN de couche 3.
Ces périphériques de routage CE se trouvent dans la même zone OSPFv2.
Une liaison intra-zone est configurée entre les deux appareils de routage CE.
S’il n’existe pas de liaison intra-zone entre les périphériques de routage CE, vous n’avez pas besoin de configurer une liaison fictive OSPFv2.
Dans Junos OS version 9.6 et ultérieure, un lien fictif OSPFv2 est installé dans la table de routage en tant que route masquée. En outre, une route BGP n’est pas exportée vers OSPFv2 si un lien fictif OSPF correspondant est disponible.
Dans Junos OS version 16.1 et ultérieure, les liaisons fictives OSPF sont prises en charge sur les instances par défaut. Le coût du lien fictif est défini dynamiquement sur la métrique aigp de la route BGP si aucune métrique n’est configurée sur le lien fictif par l’utilisateur. Si la métrique aigp n’est pas présente dans la route BGP, le coût de la liaison fictive est par défaut de 1.
Exemple : Configuration des liens fictifs OSPFv2
Cet exemple montre comment activer des liens fictifs OSPFv2 sur un périphérique de routage PE.
Exigences
Aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise avant de configurer cet exemple.
Aperçu
Le lien fictif est un lien intra-zone point à point non numéroté et est annoncé au moyen d’une annonce d’état de lien (LSA) de type 1. Les liens fictifs sont valides uniquement pour les instances de routage et OSPFv2.
Chaque liaison fictive est identifiée par une combinaison de l’adresse de point de terminaison locale et d’une adresse de point de terminaison distante et de la zone OSPFv2 à laquelle elle appartient. Vous configurez manuellement le lien fictif entre deux périphériques PE, qui se trouvent tous deux dans la même instance de routage VRF (VPN routing and forwarding), et vous spécifiez l’adresse du point d’extrémité local du lien fictif. Cette adresse est utilisée comme source pour les paquets de liaison fictive et est également utilisée par le périphérique de routage PE distant comme point de terminaison distant de liaison fictive. Vous pouvez également inclure l’option facultative metric permettant de définir une valeur de mesure pour le point de terminaison distant. La valeur de la métrique spécifie le coût d’utilisation du lien. Les itinéraires avec des métriques de chemin total inférieures sont préférés à ceux avec des métriques de chemin plus élevées.
Pour activer les liens fictifs OSPFv2 sur un périphérique de routage PE :
Configurez une interface de bouclage supplémentaire sur le périphérique de routage PE.
Configurez l’instance de routage VRF qui prend en charge les VPN de couche 3 sur le périphérique de routage PE et associez le lien fictif à une zone OSPF existante. La configuration de liaison fictive OSPFv2 est également incluse dans l’instance de routage. Vous configurez l’adresse de point de terminaison locale du lien fictif, qui est l’adresse de bouclage du VPN local, et l’adresse de point de terminaison distante, qui est l’adresse de bouclage du VPN distant. Dans cet exemple, l’instance de routage VRF est nommée en rouge.
La figure 4 montre un lien fictif OSPFv2.
Topologie
de lien fictif OSPFv2
Les appareils de la figure représentent les fonctions suivantes :
CE1 et CE2 sont les appareils de périphérie client.
PE1 et PE2 sont les équipements de périphérie du fournisseur.
P est l’appareil du fournisseur.
La configuration rapide de l’interface de ligne de commande affiche la configuration de tous les périphériques de la Figure 4. La section Procédure étape par étape décrit les étapes sur l’appareil PE1.
Configuration
Procédure
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie.
CE1
set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.1/30 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.17/30 set interfaces lo0 unit 0 family inet address 192.0.2.1/24 set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 metric 100 set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct then accept set routing-options router-id 192.0.2.1 set routing-options autonomous-system 1
PE1
set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.2/30 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.1.1.5/30 set interfaces fe-1/2/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.0.2.2/24 set interfaces lo0 unit 1 family inet address 198.51.100.2/24 set protocols mpls interface fe-1/2/1.0 set protocols bgp group toR4 type internal set protocols bgp group toR4 local-address 192.0.2.2 set protocols bgp group toR4 family inet-vpn unicast set protocols bgp group toR4 neighbor 192.0.2.4 set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface fe-1/2/1.0 set protocols ldp interface lo0.0 set policy-options policy-statement bgp-to-ospf term 1 from protocol bgp set policy-options policy-statement bgp-to-ospf term 1 then accept set policy-options policy-statement bgp-to-ospf term 2 then reject set routing-instances red instance-type vrf set routing-instances red interface fe-1/2/0.0 set routing-instances red interface lo0.1 set routing-instances red route-distinguisher 2:1 set routing-instances red vrf-target target:2:1 set routing-instances red protocols ospf export bgp-to-ospf set routing-instances red protocols ospf sham-link local 198.51.100.2 set routing-instances red protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.4 metric 10 set routing-instances red protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set routing-instances red protocols ospf area 0.0.0.0 interface lo0.1 set routing-options router-id 192.0.2.2 set routing-options autonomous-system 2
P
set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.6/30 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.1.1.9/30 set interfaces fe-1/2/1 unit 0 family mpls set interfaces lo0 unit 3 family inet address 192.0.2.3/24 set protocols mpls interface all set protocols ospf area 0.0.0.0 interface lo0.3 passive set protocols ospf area 0.0.0.0 interface all set protocols ldp interface all set routing-options router-id 192.0.2.3
PE2
set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.10/30 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.1.1.13/30 set interfaces fe-1/2/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.0.2.4/32 set interfaces lo0 unit 1 family inet address 198.51.100.4/32 set protocols mpls interface fe-1/2/0.0 set protocols bgp group toR2 type internal set protocols bgp group toR2 local-address 192.0.2.4 set protocols bgp group toR2 family inet-vpn unicast set protocols bgp group toR2 neighbor 192.0.2.2 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set protocols ldp interface fe-1/2/0.0 set protocols ldp interface lo0.0 set policy-options policy-statement bgp-to-ospf term 1 from protocol bgp set policy-options policy-statement bgp-to-ospf term 1 then accept set policy-options policy-statement bgp-to-ospf term 2 then reject set routing-instances red instance-type vrf set routing-instances red interface fe-1/2/1.0 set routing-instances red interface lo0.1 set routing-instances red route-distinguisher 2:1 set routing-instances red vrf-target target:2:1 set routing-instances red protocols ospf export bgp-to-ospf set routing-instances red protocols ospf sham-link local 198.51.100.4 set routing-instances red protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.2 metric 10 set routing-instances red protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set routing-instances red protocols ospf area 0.0.0.0 interface lo0.1 set routing-options router-id 192.0.2.4 set routing-options autonomous-system 2
CE2
set interfaces fe-1/2/0 unit 14 family inet address 10.1.1.14/30 set interfaces fe-1/2/0 unit 14 family mpls set interfaces fe-1/2/0 unit 18 family inet address 10.0.0.18/30 set interfaces lo0 unit 5 family inet address 192.0.2.5/24 set protocols ospf area 0.0.0.0 interface fe-1/2/0.14 set protocols ospf area 0.0.0.0 interface lo0.5 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.18 set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct then accept set routing-options router-id 192.0.2.5 set routing-options autonomous-system 3
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans la CLI, reportez-vous au Guide de l’utilisateur Modification de la configuration de Junos OS dans CLI.
Pour configurer des liens fictifs OSPFv2 sur chaque périphérique PE :
-
Configurez les interfaces, y compris les deux interfaces de bouclage.
[edit interfaces] user@PE1# set fe-1/2/0 unit 0 family inet address 10.1.1.2/30 user@PE1# set fe-1/2/0 unit 0 family mpls user@PE1# set fe-1/2/1 unit 0 family inet address 10.1.1.5/30 user@PE1# set fe-1/2/1 unit 0 family mpls user@PE1# set lo0 unit 0 family inet address 192.0.2.2/24 user@PE1# set lo0 unit 1 family inet address 198.51.100.2/24
-
Configurez MPLS sur l’interface centrale.
[edit protocols mpls] user@PE1# set interface fe-1/2/1.0
-
Configurez le BGP interne (IBGP).
[edit ] user@PE1# set protocols bgp group toR4 type internal user@PE1# set protocols bgp group toR4 local-address 192.0.2.2 user@PE1# set protocols bgp group toR4 family inet-vpn unicast user@PE1# set protocols bgp group toR4 neighbor 192.0.2.4
-
Configurez OSPF sur l’interface orientée vers le cur et sur l’interface de bouclage utilisée dans l’instance principale.
[edit protocols ospf area 0.0.0.0] user@PE1# set interface fe-1/2/1.0 user@PE1# set interface lo0.0 passive
-
Configurez LDP ou RSVP sur l’interface principale et sur l’interface de bouclage utilisée dans l’instance principale.
[edit protocols ldp] user@PE1# set interface fe-1/2/1.0 user@PE1# set interface lo0.0
-
Configurez une stratégie de routage à utiliser dans l’instance de routage.
[edit policy-options policy-statement bgp-to-ospf] user@PE1# set term 1 from protocol bgp user@PE1# set term 1 then accept user@PE1# set term 2 then reject
-
Configurez l’instance de routage.
[edit routing-instances red] user@PE1# set instance-type vrf user@PE1# set interface fe-1/2/0.0 user@PE1# set route-distinguisher 2:1 user@PE1# set vrf-target target:2:1 user@PE1# set protocols ospf export bgp-to-ospf user@PE1# set protocols ospf area 0.0.0.0 interface fe-1/2/0.0
-
Configurez le lien fictif OSPFv2.
Incluez l’interface de bouclage supplémentaire dans l’instance de routage et également dans la configuration OSPF.
Notez que la métrique de l’interface sham-link est définie sur 10. Sur la liaison OSPF de sauvegarde de l’appareil CE1, la métrique est définie sur 100. Le lien fictif devient alors le lien préféré.
[edit routing-instances red] user@PE1# set interface lo0.1 user@PE1# set protocols ospf sham-link local 198.51.100.2 user@PE1# set protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.4 metric 10 user@PE1# set protocols ospf area 0.0.0.0 interface lo0.1
-
Configurez le numéro du système autonome (AS) et l’ID du routeur.
[edit routing-options] user@PE1# set router-id 192.0.2.2 user@PE1# set autonomous-system 2
-
Si vous avez terminé de configurer l’appareil, validez la configuration.
[edit] user@R1# commit
Résultats
Confirmez votre configuration en entrant les commandes et show interfaces . show routing-instances Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
Sortie pour PE1 :
user@PE1# show interfaces
fe-1/2/0 {
unit 0{
family inet {
address 10.1.1.2/30;
}
family mpls;
}
}
fe-1/2/1 {
unit 0 {
family inet {
address 10.1.1.5/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.0.2.2/24;
}
}
unit 1 {
family inet {
address 198.51.100.2/24;
}
}
}
user@PE1# show protocols
mpls {
interface fe-1/2/1.0;
}
bgp {
group toR4 {
type internal;
local-address 192.0.2.2;
family inet-vpn {
unicast;
}
neighbor 192.0.2.4;
}
}
ospf {
area 0.0.0.0 {
interface fe-1/2/1.0;
interface lo0.0 {
passive;
}
}
}
ldp {
interface fe-1/2/1.0;
interface lo0.0;
}
user@PE1# show policy-options
policy-statement bgp-to-ospf {
term 1 {
from protocol bgp;
then accept;
}
term 2 {
then reject;
}
}
user@PE1# show routing-instances
red {
instance-type vrf;
interface fe-1/2/0.0;
interface lo0.1;
route-distinguisher 2:1;
vrf-target target:2:1;
protocols {
ospf {
export bgp-to-ospf;
sham-link local 198.51.100.2;
area 0.0.0.0 {
sham-link-remote 198.51.100.4 metric 10;
interface fe-1/2/0.0;
interface lo0.1;
}
}
}
}
user@PE1# show routing-options router-id 192.0.2.2; autonomous-system 2;
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification des interfaces Sham Link
- Vérification des terminaux locaux et distants du lien Sham
- Vérification des adjacences de liens fictifs
- Vérification de l’annonce de l’état du lien
- Vérification de la sélection du tracé
Vérification des interfaces Sham Link
But
Vérifiez l’interface de liaison fictive. Le lien fictif est traité comme une interface dans OSPFv2, le nom étant affiché sous la forme shamlink.<unique identifier>, où l’identificateur unique est un nombre. Par exemple, shamlink.0. Le lien fictif apparaît sous la forme d’une interface point à point.
Action
À partir du mode opérationnel, entrez la show ospf interface instance instance-name commande.
user@PE1> show ospf interface instance red Interface State Area DR ID BDR ID Nbrs lo0.1 DR 0.0.0.0 198.51.100.2 0.0.0.0 0 fe-1/2/0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1 shamlink.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Vérification des terminaux locaux et distants du lien Sham
But
Vérifiez les terminaux locaux et distants de la liaison fictive. La MTU de l’interface de liaison fictive est toujours égale à zéro.
Action
À partir du mode opérationnel, entrez la show ospf interface instance instance-name detail commande.
user@PE1> show ospf interface shamlink.0 instance red Interface State Area DR ID BDR ID Nbrs shamlink.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1 Type: P2P, Address: 0.0.0.0, Mask: 0.0.0.0, MTU: 0, Cost: 10 Local: 198.51.100.2, Remote: 198.51.100.4 Adj count: 1 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None, No eligible backup Topology default (ID 0) -> Cost: 10
Vérification des adjacences de liens fictifs
But
Vérifiez les contiguïtés entre les liens fictifs configurés.
Action
À partir du mode opérationnel, entrez la show ospf neighbor instance instance-name commande.
user@PE1> show ospf neighbor instance red Address Interface State ID Pri Dead 10.1.1.1 fe-1/2/0.0 Full 192.0.2.1 128 35 198.51.100.4 shamlink.0 Full 198.51.100.4 0 31
Vérification de l’annonce de l’état du lien
But
Vérifiez que le LSA de routeur généré par l’instance comporte la contiguïté de liaison fictive en tant que liaison point à point non numérotée. Les données de lien pour les liens fictifs sont un nombre allant de 0x80010000 à 0x8001ffff.
Action
À partir du mode opérationnel, entrez la show ospf database instance instance-name commande.
user@PE1> show ospf database instance red
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 192.0.2.1 192.0.2.1 0x80000009 1803 0x22 0x6ec7 72
Router 192.0.2.5 192.0.2.5 0x80000007 70 0x22 0x2746 72
Router *198.51.100.2 198.51.100.2 0x80000006 55 0x22 0xda6b 60
Router 198.51.100.4 198.51.100.4 0x80000005 63 0x22 0xb19 60
Network 10.0.0.18 192.0.2.5 0x80000002 70 0x22 0x9a71 32
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 198.51.100.2 198.51.100.4 0x80000002 72 0xa2 0x343 36
Extern *198.51.100.4 198.51.100.2 0x80000002 71 0xa2 0xe263 36
Vérification de la sélection du tracé
But
Vérifiez que le chemin d’accès VPN de couche 3 est utilisé à la place du chemin de sauvegarde.
Action
En mode opérationnel, entrez la traceroute commande de l’appareil CE1 vers l’appareil CE2.
user@CE1> traceroute 192.0.2.5
traceroute to 192.0.2.5 (192.0.2.5), 30 hops max, 40 byte packets
1 10.1.1.2 (10.1.1.2) 1.930 ms 1.664 ms 1.643 ms
2 * * *
3 10.1.1.10 (10.1.1.10) 2.485 ms 1.435 ms 1.422 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 192.0.2.5 (192.0.2.5) 1.347 ms 1.362 ms 1.329 ms
Signification
L’opération traceroute indique que le VPN de couche 3 est le chemin préféré. Si vous supprimiez le lien fictif ou si vous deviez modifier la métrique OSPF pour préférer ce chemin de sauvegarde, le traceroute indiquerait que le chemin de sauvegarde est préféré.
Configuration des sessions EBGP multi-sauts entre les routeurs PE et CE dans les VPN de couche 3
Vous pouvez configurer une session multi-sauts EBGP ou IBGP entre les routeurs PE et CE d’un VPN de couche 3. Cela vous permet d’avoir un ou plusieurs routeurs entre les routeurs PE et CE. L’utilisation d’IBGP entre des routeurs PE et CE ne nécessite pas la configuration d’instructions supplémentaires. Toutefois, l’utilisation d’EBGP entre les routeurs PE et CE nécessite la configuration de l’instruction multihop .
Pour configurer une session BGP externe à sauts multiples pour la connexion entre les routeurs PE et CE, incluez l’instruction multihop sur le routeur PE. Pour éviter les boucles de routage, vous devez configurer une valeur de durée de vie (TTL) pour la session à sauts multiples :
multihop ttl-value;
Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez configurer cette instruction, reportez-vous à la section récapitulative de cette instruction.
Configuration d’une topologie VPN LDP-over-RSVP
Cet exemple montre comment configurer une topologie VPN dans laquelle les paquets LDP sont tunnelisés via un LSP RSVP. Cette configuration se compose des composants suivants (voir Figure 5) :
Un VPN (VPN-A)
Deux routeurs PE
LDP en tant que protocole de signalisation entre les routeurs PE et leurs routeurs P adjacents
Un LSP RSVP entre deux des routeurs P sur lesquels LDP est tunnelisé
VPN LDP sur RSVP
Les étapes suivantes décrivent comment cette topologie est établie et comment les paquets sont envoyés du routeur CE CE2 au routeur CE CE1 :
Les routeurs P P1 et P3 établissent des LSP RSVP entre eux et installent leurs adresses de bouclage dans leurs tables de routage inet.3.
Le routeur PE1 établit une session LDP avec le routeur P1 sur l’interface
so-1/0/0.0.Le routeur P1 établit une session LDP avec l’adresse de bouclage du routeur P3, qui est accessible à l’aide du LSP RSVP.
Le routeur P1 envoie ses liaisons d’étiquettes, qui incluent une étiquette pour atteindre le routeur PE1, au routeur P3. Ces liaisons d’étiquettes permettent au routeur P3 de diriger les paquets LDP vers le routeur PE1.
Le routeur P3 établit une session LDP avec le routeur PE2 sur l’interface
so0-0/0/0.0et établit une session LDP avec l’adresse de bouclage du routeur P1.Le routeur P3 envoie ses liaisons d’étiquettes, qui incluent une étiquette pour atteindre le routeur PE2, au routeur P1. Ces liaisons d’étiquettes permettent au routeur P1 de diriger les paquets LDP vers l’adresse de bouclage du routeur PE2.
Les routeurs PE1 et PE2 établissent des sessions IBGP entre eux.
Lorsque le routeur PE1 annonce au routeur PE2 les routes qu’il a apprises du routeur CE1, il inclut son étiquette VPN. (Le routeur PE crée l’étiquette VPN et la lie à l’interface entre les routeurs PE et CE.) De même, lorsque le routeur PE2 annonce des routes qu’il a apprises du routeur CE2, il envoie son étiquette VPN au routeur PE1.
Lorsque le routeur PE2 veut transférer un paquet au routeur CE1, il envoie deux étiquettes sur la pile d’étiquettes du paquet : d’abord l’étiquette VPN qui est liée à l’interface entre le routeur PE1 et le routeur CE1, puis l’étiquette LDP utilisée pour atteindre le routeur PE1. Ensuite, il transfère les paquets au routeur P3 via l’interface so-0/0/1.0.
Lorsque le routeur P3 reçoit les paquets du routeur PE2, il permute l’étiquette LDP qui se trouve en haut de la pile (selon sa base de données LDP) et pousse également une étiquette RSVP sur le dessus de la pile afin que le paquet puisse maintenant être commuté par le LSP RSVP. À ce stade, il y a trois étiquettes sur la pile : l’étiquette interne (en bas) est l’étiquette VPN, le milieu est l’étiquette LDP et l’étiquette externe (en haut) est l’étiquette RSVP.
Le routeur P2 reçoit le paquet et le transfère au routeur P1 en permutant l’étiquette RSVP. Dans cette topologie, étant donné que le routeur P2 est l’avant-dernier bond du LSP, il affiche l’étiquette RSVP et transfère le paquet via l’interface
so-1/1/0.0au routeur P1. À ce stade, il y a deux étiquettes sur la pile : l’étiquette interne est l’étiquette VPN et l’étiquette externe est l’étiquette LDP.Lorsque le routeur P1 reçoit le paquet, il retire l’étiquette externe (l’étiquette LDP) et transfère le paquet au routeur PE1 à l’aide de l’interface
so-1/0/0.0. Dans cette topologie, le routeur PE1 est le routeur LDP de sortie, de sorte que le routeur P1 affiche l’étiquette LDP au lieu de l’échanger avec une autre étiquette. À ce stade, il n’y a qu’une seule étiquette sur la pile, l’étiquette VPN.Lorsque le routeur PE1 reçoit le paquet, il affiche l’étiquette VPN et transfère le paquet sous forme de paquet IPv4 au routeur CE1 via l’interface
ge-1/1/0.0.
Un ensemble similaire d’opérations se produit pour les paquets envoyés à partir du routeur CE1 qui sont destinés au routeur CE2.
La liste suivante explique comment, pour les paquets envoyés du routeur CE2 au routeur CE1, les étiquettes LDP, RSVP et VPN sont annoncées par les différents routeurs. Ces étapes comprennent des exemples de valeurs d’étiquette (illustrées à la Figure 6).
Étiquettes LDP
Le routeur PE1 annonce l’étiquette LDP 3 pour lui-même au routeur P1.
Le routeur P1 annonce le label LDP 100 001 pour le routeur PE1 vers le routeur P3.
Le routeur P3 annonce le label LDP 100 002 pour le routeur PE1 vers le routeur PE2.
Étiquettes RSVP
Le routeur P1 annonce l’étiquette RSVP 3 au routeur P2.
Le routeur P2 annonce l’étiquette RSVP 100 003 au routeur P3.
Étiquette VPN
Le routeur PE1 annonce l’étiquette VPN 100 004 au routeur PE2 pour le routage du routeur CE1 au routeur CE2.
Pour un paquet envoyé de l’hôte B de la Figure 6 à l’hôte A, les en-têtes et les étiquettes du paquet changent au fur et à mesure que le paquet se déplace vers sa destination :
Le paquet qui provient de l’hôte B a une adresse source B et une adresse de destination A dans son en-tête.
Le routeur CE2 ajoute au paquet un prochain saut d’interface
so-1/0/0.Le routeur PE2 remplace le tronçon suivant de l’interface
so-1/0/0par un saut suivant de PE1. Il ajoute également deux étiquettes pour atteindre le routeur PE1, d’abord l’étiquette VPN (100 004), puis l’étiquette LDP (100 002). L’étiquette VPN est donc l’étiquette interne (inférieure) de la pile, et l’étiquette LDP est l’étiquette externe.Le routeur P3 remplace l’étiquette LDP ajoutée par le routeur PE2 (100 002) et la remplace par son étiquette LDP pour atteindre le routeur PE1 (100 001). Il ajoute également l’étiquette RSVP lorsque vous atteignez le routeur P2 (100 003).
Le routeur P2 supprime l’étiquette RSVP (100 003), car il s’agit de l’avant-dernier saut du LSP MPLS.
Le routeur P1 enlève l’étiquette LDP (100 001) car il s’agit de l’avant-dernier routeur LDP. Il remplace également le saut suivant de PE1 par l’interface du saut suivant,
so-1/0/0.Le routeur PE1 supprime l’étiquette VPN (100 004). Il remplace également l’interface next-hop de
so-1/0/0et la remplace par son interface next-hop,ge-1/1/0.Le routeur CE1 supprime l’interface de saut suivant de , et l’en-tête du
ge-1/1/0paquet ne contient plus qu’une adresse source B et une adresse de destination A.
La dernière section de cet exemple consolide les instructions nécessaires pour configurer la fonctionnalité VPN sur chacun des routeurs Service P illustrés à la Figure 5.
Dans cet exemple, un numéro AS privé est utilisé pour le séparateur de route et la cible de route. Ce nombre n’est utilisé qu’à titre indicatif. Lorsque vous configurez des VPN, vous devez utiliser un numéro AS attribué.
Les sections suivantes expliquent comment configurer la fonctionnalité VPN sur les routeurs PE et P. Les routeurs CE n’ont aucune information sur le VPN, vous les configurez donc normalement.
- Activation d’un IGP sur les routeurs PE et P
- Activation de LDP sur les routeurs PE et P
- Activation de RSVP et MPLS sur le routeur P
- Configuration du tunnel MPLS LSP entre les routeurs P
- Configuration d’IBGP sur les routeurs PE
- Configuration des instances de routage pour les VPN sur les routeurs PE
- Configuration d’une stratégie VPN sur les routeurs PE
- Résumé de la configuration VPN LDP-over-RSVP par routeur
Activation d’un IGP sur les routeurs PE et P
Pour permettre aux routeurs PE et P d’échanger des informations de routage entre eux, vous devez configurer un IGP sur tous ces routeurs ou configurer des routes statiques. Vous configurez l’IGP sur l’instance principale du processus de protocole de routage (rpd) (c’est-à-dire au niveau de la [edit protocols] hiérarchie), et non dans l’instance de routage VPN (c’est-à-dire pas au niveau de la [edit routing-instances] hiérarchie).
Vous configurez l’IGP de manière standard. Cet exemple de configuration n’inclut pas cette partie de la configuration.
Activation de LDP sur les routeurs PE et P
Dans cet exemple de configuration, le LDP est le protocole de signalisation entre les routeurs PE. Pour que le VPN fonctionne, vous devez configurer LDP sur les deux routeurs PE et sur les routeurs P qui sont connectés aux routeurs PE. Vous devez configurer LDP uniquement sur les interfaces situées au cœur du réseau du fournisseur de services. c’est-à-dire entre les routeurs PE et P et entre les routeurs P. Vous n’avez pas besoin de configurer LDP sur l’interface entre les routeurs PE et CE.
Dans cet exemple de configuration, vous configurez LDP sur les interfaces de bouclage des routeurs P, car il s’agit des interfaces sur lesquelles le LSP MPLS est configuré.
Sur les routeurs PE, vous devez également configurer family inet lors de la configuration de l’interface logique.
Sur le routeur PE1, configurez LDP :
[edit protocols]
ldp {
interface so-1/0/0.0;
}
[edit interfaces]
so-1/0/0 {
unit 0 {
family mpls;
}
}
Sur le routeur PE2, configurez LDP :
[edit protocols]
ldp {
interface so-0/0/0.0;
}
[edit interfaces]
so-0/0/1 {
unit 0 {
family mpls;
}
}
Sur le routeur P1, configurez LDP :
[edit protocols]
ldp {
interface so-1/0/0.0;
interface lo0;
}
Sur le routeur P3, configurez LDP :
[edit protocols]
ldp {
interface lo0;
interface so-0/0/0.0;
}
Sur le routeur P2, bien que vous n’ayez pas besoin de configurer LDP, vous pouvez éventuellement le configurer pour fournir un chemin LDP de secours au cas où le LSP RSVP deviendrait non opérationnel :
[edit protocols]
ldp {
interface so-1/1/0.0;
interface at-2/0/0.0;
}
Activation de RSVP et MPLS sur le routeur P
Sur le routeur P P2, vous devez configurer RSVP et MPLS car ce routeur existe sur le chemin MPLS LSP entre les routeurs P P1 et P3 :
[edit]
protocols {
rsvp {
interface so-1/1/0.0;
interface at-2/0/0.0;
}
mpls {
interface so-1/1/0.0;
interface at-2/0/0.0;
}
}
Configuration du tunnel MPLS LSP entre les routeurs P
Dans cet exemple de configuration, LDP est tunnelisé via un LSP RSVP. Par conséquent, en plus de configurer RSVP, vous devez activer la prise en charge des aspects techniques du trafic dans un IGP et créer un LSP MPLS pour tunneliser le trafic LDP.
Sur le routeur P1, activez RSVP et configurez une extrémité du tunnel MPLS LSP. Dans cet exemple, la prise en charge des aspects techniques du trafic est activée pour OSPF et vous configurez MPLS sur les interfaces du LSP et du routeur PE1. Dans l’instruction to , vous spécifiez l’adresse de bouclage du routeur P3.
[edit]
protocols {
rsvp {
interface so-1/0/1.0;
}
mpls {
label-switched-path P1-to-P3 {
to 10.255.100.1;
ldp-tunneling;
}
interface so-1/0/0.0;
interface so-1/0/1.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-1/0/0.0;
interface so-1/0/1.0;
}
}
}
Sur le routeur P3, activez RSVP et configurez l’autre extrémité du tunnel MPLS LSP. Là encore, la prise en charge des aspects techniques du trafic est activée pour OSPF et vous configurez MPLS sur les interfaces du LSP et du routeur PE2. Dans l’instruction to , vous spécifiez l’adresse de bouclage du routeur P1.
[edit]
protocols {
rsvp {
interface at-2/0/1.0;
}
mpls {
label-switched-path P3-to-P1 {
to 10.255.2.2;
ldp-tunneling;
}
interface at-2/0/1.0;
interface so-0/0/0.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface at-2/0/1.0;
interface so-0/0/0.0;
}
}
}
Configuration d’IBGP sur les routeurs PE
Sur les routeurs PE, configurez une session IBGP avec les propriétés suivantes :
Famille de VPN : pour indiquer que la session IBGP est destinée au VPN, incluez l’instruction
family inet-vpn.Loopback address (Adresse de bouclage) : incluez l’instruction
local-addressspécifiant l’adresse de bouclage du routeur PE local. La session IBGP pour les VPN passe par l’adresse de bouclage. Vous devez également configurer l’interfacelo0au niveau de la[edit interfaces]hiérarchie. L’exemple n’inclut pas cette partie de la configuration du routeur.Neighbor address (Adresse voisine) : incluez l’instruction
neighborspécifiant l’adresse IP du routeur PE voisin, qui est son adresse de bouclage (lo0).
Sur le routeur PE1, configurez IBGP :
[edit]
protocols {
bgp {
group PE1-to-PE2 {
type internal;
local-address 10.255.1.1;
family inet-vpn {
unicast;
}
neighbor 10.255.200.2;
}
}
}
Sur le routeur PE2, configurez IBGP :
[edit]
protocols {
bgp {
group PE2-to-PE1 {
type internal;
local-address 10.255.200.2;
family inet-vpn {
unicast;
}
neighbor 10.255.1.1;
}
}
}
Configuration des instances de routage pour les VPN sur les routeurs PE
Les deux routeurs PE prennent en charge VPN-A, vous devez donc configurer une instance de routage sur chaque routeur pour le VPN, dans laquelle vous définissez les éléments suivants :
Route distinguisher, qui doit être unique pour chaque instance de routage sur le routeur PE. Il est utilisé pour distinguer les adresses d’un VPN de celles d’un autre VPN.
Type d’instance de
vrf, qui crée la table VRF sur le routeur PE.Interfaces connectées aux routeurs CE.
Les stratégies d’importation et d’exportation VRF, qui doivent être les mêmes sur chaque routeur PE qui dessert le même VPN. À moins que la stratégie d’importation ne contienne qu’une
then rejectdéclaration, elle doit inclure une référence à une communauté. Sinon, lorsque vous tentez de valider la configuration, celle-ci échoue.Note:Dans cet exemple, un numéro AS privé est utilisé pour le distingueur d’itinéraire. Ce nombre n’est utilisé qu’à titre indicatif. Lorsque vous configurez des VPN, vous devez utiliser un numéro AS attribué.
Le routage entre les routeurs PE et CE, qui est nécessaire pour que le routeur PE distribue les routes VPN vers et depuis les routeurs CE connectés. Vous pouvez configurer un protocole de routage (BGP, OSPF ou RIP) ou un routage statique.
Sur le routeur PE1, configurez l’instance de routage suivante pour VPN-A. Dans cet exemple, le routeur PE1 utilise le protocole RIP pour distribuer les routes vers et depuis le routeur CE auquel il est connecté.
[edit]
routing-instance {
VPN-A {
instance-type vrf;
interface ge-1/0/0.0;
route-distinguisher 65535:0;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
protocols {
rip {
group PE1-to-CE1 {
neighbor ge-1/0/0.0;
}
}
}
}
}
Sur le routeur PE2, configurez l’instance de routage suivante pour VPN-A. Dans cet exemple, le routeur PE2 utilise OSPF pour distribuer les routes vers et depuis le routeur CE auquel il est connecté.
[edit]
routing-instance {
VPN-A {
instance-type vrf;
interface so-1/2/0.0;
route-distinguisher 65535:1;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
protocols {
ospf {
area 0.0.0.0 {
interface so-1/2/0.0;
}
}
}
}
}
Configuration d’une stratégie VPN sur les routeurs PE
Vous devez configurer les stratégies d’importation et d’exportation de VPN sur chacun des routeurs PE afin qu’ils installent les routes appropriées dans leurs tables VRF, qu’ils utilisent pour transférer les paquets au sein d’un VPN. Pour VPN-A, la table VRF est VPN-A.inet.0.
Dans la stratégie VPN, vous configurez également les communautés cibles VPN.
Dans cet exemple, un numéro AS privé est utilisé pour la cible de route. Ce nombre n’est utilisé qu’à titre indicatif. Lorsque vous configurez des VPN, vous devez utiliser un numéro AS attribué.
Sur le routeur PE1, configurez les stratégies d’importation et d’exportation VPN suivantes :
Les qualificateurs de stratégie affichés dans cet exemple sont uniquement ceux qui sont nécessaires au fonctionnement du VPN. Vous pouvez configurer des qualificateurs supplémentaires, si nécessaire, pour toutes les stratégies que vous configurez.
[edit]
policy-options {
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement VPN-A-export {
term a {
from protocol rip;
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
community VPN-A members target:65535:00;
}
Sur le routeur PE2, configurez les stratégies d’importation et d’exportation VPN suivantes :
[edit]
policy-options {
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement VPN-A-export {
term a {
from protocol ospf;
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
community VPN-A members target:65535:00;
}
Pour appliquer les stratégies VPN sur les routeurs, incluez les vrf-export instructions et vrf-import lorsque vous configurez l’instance de routage sur les routeurs PE. Les stratégies d’importation et d’exportation VRF gèrent la distribution de routes sur la session IBGP s’exécutant entre les routeurs PE.
Résumé de la configuration VPN LDP-over-RSVP par routeur
Routeur PE1
Instance de routage pour VPN-A
routing-instance {
VPN-A {
instance-type vrf;
interface ge-1/0/0.0;
route-distinguisher 65535:0;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
}
}
Protocole de routage d’instance
protocols {
rip {
group PE1-to-CE1 {
neighbor ge-1/0/0.0;
}
}
}
Interfaces
interfaces {
so-1/0/0 {
unit 0 {
family mpls;
}
}
ge-1/0/0 {
unit 0;
}
}
Instance de protocole principale
protocols {
}
Activer LDP
ldp {
interface so-1/0/0.0;
}
Activer MPLS
mpls {
interface so-1/0/0.0;
interface ge-1/0/0.0;
}
Configurer IBGP
bgp {
group PE1-to-PE2 {
type internal;
local-address 10.255.1.1;
family inet-vpn {
unicast;
}
neighbor 10.255.100.1;
}
}
Configurer la stratégie VPN
policy-options {
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement VPN-A-export {
term a {
from protocol rip;
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
community VPN-A members target:65535:00;
}
Routeur P1
Instance de protocole principale
protocols {
}
Activer RSVP
rsvp {
interface so-1/0/1.0;
}
Activer LDP
ldp {
interface so-1/0/0.0;
interface lo0.0;
}
Activer MPLS
mpls {
label-switched-path P1-to-P3 {
to 10.255.100.1;
ldp-tunneling;
}
interface so-1/0/0.0;
interface so-1/0/1.0;
}
Configurer OSPF pour la prise en charge des aspects techniques du trafic
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-1/0/0.0;
interface so-1/0/1.0;
}
}
Routeur P2
Instance de protocole principale
protocols {
}
Activer RSVP
rsvp {
interface so-1/1/0.0;
interface at-2/0/0.0;
}
Activer MPLS
mpls {
interface so-1/1/0.0;
interface at-2/0/0.0;
}
Routeur P3
Instance de protocole principale
protocols {
}
Activer RSVP
rsvp {
interface at-2/0/1.0;
}
Activer LDP
ldp {
interface so-0/0/0.0;
interface lo0.0;
}
Activer MPLS
mpls {
label-switched-path P3-to-P1 {
to 10.255.2.2;
ldp-tunneling;
}
interface at-2/0/1.0;
interface so-0/0/0.0;
}
Configurer OSPF pour la prise en charge des aspects techniques du trafic
ospf {
traffic-engineering;
area 0.0.0.0 {
interface at-2/0/1.0;
interface at-2/0/1.0;
}
}
Routeur PE2
Instance de routage pour VPN-A
routing-instance {
VPN-A {
instance-type vrf;
interface so-1/2/0.0;
route-distinguisher 65535:1;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
}
}
Protocole de routage d’instance
protocols {
ospf {
area 0.0.0.0 {
interface so-1/2/0.0;
}
}
}
Interfaces
interfaces {
so-0/0/0 {
unit 0 {
family mpls;
}
}
so-1/2/0 {
unit 0;
}
}
Instance de protocole principale
protocols {
}
Activer LDP
ldp {
interface so-0/0/0.0;
}
Activer MPLS
mpls {
interface so-0/0/0.0;
interface so-1/2/0.0;
}
Configurer IBGP
bgp {
group PE2-to-PE1 {
type internal;
local-address 10.255.200.2;
family inet-vpn {
unicast;
}
neighbor 10.255.1.1;
}
}
Configurer la stratégie VPN
policy-options {
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement VPN-A-export {
term a {
from protocol ospf;
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
community VPN-A members target:65535:01;
}
Configuration d’une topologie VPN de couche 3 basée sur les applications
Cet exemple illustre un mécanisme basé sur l’application pour transférer le trafic vers un VPN de couche 3. En règle générale, une ou plusieurs interfaces sont associées ou liées à un VPN en les incluant dans la configuration de l’instance de routage VPN. En liant l’interface au VPN, la table VRF du VPN est utilisée pour prendre des décisions de transfert pour tout trafic entrant sur cette interface. La liaison de l’interface inclut également les routes locales de l’interface dans la table VRF, ce qui fournit une résolution de saut suivant pour les routes VRF.
Dans cet exemple, un filtre de pare-feu est utilisé pour définir quel trafic entrant sur une interface est transféré au moyen de la table de routage standard, inet.0, et quel trafic entrant est transféré au moyen de la table VRF. Vous pouvez développer cet exemple de manière à ce que le trafic entrant sur une interface puisse être redirigé vers un ou plusieurs VPN. Par exemple, vous pouvez définir une configuration pour prendre en charge un VPN qui transfère le trafic en fonction de l’adresse source, qui transfère le trafic HTTP (Hypertext Transfer Protocol) ou qui transfère uniquement les médias en streaming.
Pour que cette configuration fonctionne, les conditions suivantes doivent être remplies :
Les interfaces qui utilisent le transfert basé sur les filtres ne doivent pas être liées au VPN.
Le routage statique doit être utilisé comme moyen de routage.
Vous devez définir un groupe de tables de routage d’interface partagé entre inet.0 et les tables VRF pour fournir des routes locales à la table VRF.
Cet exemple se compose de deux hôtes clients (client D et client E) qui se trouvent dans deux VPN différents et qui souhaitent envoyer du trafic à la fois dans le VPN et vers Internet. Les chemins sont définis comme suit :
Le client A envoie le trafic au client E via le VPN A avec un chemin de retour qui utilise également le VPN A (à l’aide de la table VRF du VPN).
Le client B envoie le trafic au client D via le VPN B avec un chemin de retour qui utilise le routage standard basé sur la destination (à l’aide de la table de routage inet.0).
Les clients B et C envoient du trafic vers Internet en utilisant le routage standard (à l’aide de la table de routage inet.0), avec un chemin de retour qui utilise également le routage standard.
Cet exemple montre qu’il existe une grande variété d’options pour configurer une topologie VPN de couche 3 basée sur l’application. Cette flexibilité s’applique à de nombreuses implémentations réseau qui nécessitent que le trafic spécifique soit transféré dans un environnement de routage contraint.
Cet exemple de configuration affiche uniquement les parties de la configuration pour le transfert, les instances de routage et la stratégie basés sur les filtres. Il n’illustre pas comment configurer un VPN de couche 3.
La Figure 7 illustre la topologie de réseau utilisée dans cet exemple.
Configuration sur le routeur A
Sur le routeur A, vous configurez l’interface avec les clients A, B et C. La configuration évalue le trafic entrant pour déterminer s’il doit être transféré au moyen d’un VPN ou d’un routage standard basé sur la destination.
Tout d’abord, appliquez un filtre entrant et configurez l’interface :
[edit]
interfaces {
fe-1/1/0 {
unit 0 {
family inet {
filter {
input fbf-vrf;
}
address 192.168.1.1/24;
}
}
}
}
Étant donné que les interfaces qui utilisent le transfert basé sur les filtres ne doivent pas être liées à un VPN, vous devez configurer une autre méthode pour fournir des routes de saut suivant à la table VRF. Pour ce faire, définissez un groupe de tables de routage d’interface et partagez ce groupe entre toutes les tables de routage :
[edit]
routing-options {
interface-routes {
rib-group inet if-rib;
}
rib-groups {
if-rib {
import-rib [ inet.0 vpn-A.inet.0 vpn-B.inet.0 ];
}
}
}
Vous appliquez le filtre suivant au trafic entrant sur l’interface fe-1/1/0.0. Le premier terme fait correspondre le trafic du client A et le transmet à l’instance de routage du VPN A. Le second terme correspond au trafic du client B qui est destiné au client D et le transmet à l’instance de routage pour le VPN B. Le troisième terme correspond à tous les autres trafics, qui sont acheminés normalement au moyen d’un transfert basé sur la destination selon les routes de l’inet.0.
[edit firewall family family-name]
filter fbf-vrf {
term vpnA {
from {
source-address {
192.168.1.1/32;
}
}
then {
routing-instance vpn-A;
}
}
term vpnB {
from {
source-address {
192.168.1.2/32;
}
destination-address {
192.168.3.0/24;
}
}
then routing-instance vpn-B;
}
}
term internet {
then accept;
}
Vous configurez ensuite les instances de routage pour le VPN A et le VPN B. Notez que ces instructions incluent toutes les instructions requises pour définir un VPN de couche 3, à l’exception de l’instruction interface .
[edit]
routing-instances {
vpn-A {
instance-type vrf;
route-distinguisher 172.21.10.63:100;
vrf-import vpn-A-import;
vrf-export vpn-A-export;
}
vpn-B {
instance-type vrf;
route-distinguisher 172.21.10.63:200;
vrf-import vpn-B-import;
vrf-export vpn-B-export;
}
}
Configuration sur le routeur E
Sur le routeur E, configurez un itinéraire par défaut pour accéder à Internet. Vous devez injecter cette route dans le maillage IBGP local pour fournir un point de sortie du réseau.
[edit]
routing-options {
static {
route 0.0.0.0/0 next-hop so-2/2/2.0 discard
}
}
Configurez l’interface sur le client E afin que tout le trafic entrant sur l’interface fe-1/1/1.0 qui correspond à la stratégie VPN soit transféré via le VPN A :
[edit]
routing-instances {
vpn-A {
interface fe-1/1/1.0
instance-type vrf;
route-distinguisher 172.21.10.62:100;
vrf-import vpn-A-import;
vrf-export vpn-A-export;
routing-options {
static {
route 192.168.2.0/24 next-hop fe-1/1/1.0;
}
}
}
}
Configuration sur le routeur F
Encore une fois, étant donné que les interfaces qui utilisent le transfert basé sur les filtres ne doivent pas être liées à un VPN, vous configurez une autre méthode pour fournir des routes de saut suivant à la table VRF en définissant un groupe de tables de routage d’interface et en partageant ce groupe entre toutes les tables de routage. Pour fournir une route de retour aux clients pour un routage inet.0 normal, vous définissez une route statique à inclure dans inet.0 et redistribuez la route statique dans BGP :
[edit]
routing-options {
interface-routes {
rib-group inet if-rib;
}
rib-groups {
if-rib {
import-rib [ inet.0 vpn-B.inet.0 ];
}
}
}
Pour diriger le trafic du VPN B vers le client D, vous devez configurer l’instance de routage du VPN B sur le routeur F. Tout le trafic entrant du client D sur l’interface so-3/3/3.0 est transféré normalement au moyen de l’adresse de destination basée sur les routes dans inet.0.
[edit]
routing-instances {
vpn-B {
instance-type vrf;
route-distinguisher 172.21.10.64:200;
vrf-import vpn-B-import;
vrf-export vpn-B-export;
routing-options {
static {
route 192.168.3.0/24 next-hop so-3/3/3.0;
}
}
}
}