SUR CETTE PAGE
Configuration du routage entre les routeurs PE et CE dans des VPN de couche 3
Configuration d’un ID de domaine OSPF pour un VPN de couche 3
Configuration de sessions multihop EBGP entre les routeurs PE et CE dans des 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 des VPN de couche 3
Pour que le routeur PE distribue des routes vpn vers et depuis les routeurs CE connectés, vous devez configurer le routage au sein de l’instance de routage VPN. Vous pouvez configurer un protocole de routage (BGP, OSPF ou RIP) ou configurer 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 de liaisons OSPF sham pour les VPN de couche 3
- Configuration d’un ID de domaine OSPF
- Configuration 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’énoncé bgp :
bgp {
group group-name {
peer-as as-number;
neighbor ip-address;
}
}
Vous pouvez inclure cette déclaration 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 prendre en compte les 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 homologue BGP distant dans une instance de routage VRF distincte. Cela crée une boucle système autonome où tous les routes reçues de cet homologue BGP distant sont masquées.
Vous configurez le numéro AS local en utilisant soit l’instruction
autonomous-systemau niveau de la[edit routing-instances routing-instance-name routing-options]hiérarchie, soit 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 pour 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 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 comme protocole de routage entre un routeur PE et CE, incluez la ospf déclaration :
ospf {
area area {
interface interface-name;
}
}
Vous pouvez inclure cette déclaration 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 comme protocole de routage entre un routeur PE et CE, incluez la ospf3 déclaration :
ospf3 {
area area {
interface interface-name;
}
}
Vous pouvez inclure cette déclaration 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 de liaisons OSPF sham 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 OSPF factices pour compenser les problèmes liés aux liaisons OSPF intra-zone.
Les sections suivantes décrivent les liaisons OSPF factices et comment les configurer :
Présentation d’OSPF Sham Links
La figure 1 illustre le moment où vous pouvez configurer une liaison OSPF factice. Les routeurs CE1 et CE2 sont situés dans la même zone OSPF. Ces routeurs CE sont reliés par un VPN de couche 3 sur le routeur PE1 et le routeur PE2. En outre, les routeurs CE1 et CE2 sont connectés par une liaison intra-zone utilisée comme sauvegarde.
OSPF traite la liaison via le VPN de couche 3 comme une liaison intera. Par défaut, OSPF préfère les liaisons intra-zone aux liaisons inter-zones, de sorte qu’OSPF sélectionne la liaison intra-zone de sauvegarde comme chemin actif. Cela 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 OSPF factice est également une liaison intra-zone, sauf qu’elle est configurée entre les routeurs PE comme illustré en figure 1. Vous pouvez configurer la métrique du lien factice 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 routeurs CE.
Vous devez configurer une liaison OSPF factice dans les circonstances suivantes :
Deux routeurs CE sont reliés 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’y a pas de liaison intra-zone entre les routeurs CE, vous n’avez pas besoin de configurer une liaison OSPF factice.
Pour plus d’informations sur les liens factices OSPF, consultez le projet Internet draft-ietf-l3vpn-ospf-2547-01.txt, OSPF en tant que protocole PE/CE dans les VPN BGP/MPLS.
Configuration des liaisons OSPF Sham
Le lien factice est un lien intra-zone point à point non numéroté et est annoncé au moyen d’une publicité d’état de lien de type 1 (LSA). Les liens factices ne sont valables que pour les instances de routage et OSPF version 2.
Chaque liaison factice est identifiée par une combinaison de l’adresse de fin de la liaison locale et distante et de la zone OSPF à laquelle elle appartient. Les liaisons factices doivent être configurées manuellement. Vous configurez la liaison factice entre deux routeurs PE, qui sont tous deux dans la même instance de routage VRF.
Vous devez spécifier l’adresse du point d’extrémité local de la liaison factice. Cette adresse est utilisée comme source pour les paquets de liaison factices et est également utilisée par le routeur PE distant comme point d’extrémité de liaison factice.
L’adresse locale de la liaison OSPF doit être spécifiée avec une adresse de bouclage pour le VPN local. Le chemin vers cette adresse doit être propagé par BGP. Spécifiez l’adresse du point de fin local à l’aide de l’option locale de l’énoncé de liaison factice :
sham-link { local address; }
Vous pouvez inclure cette déclaration aux niveaux hiérarchiques suivants :
[modifier les protocoles de routage-instances routing-instance-name ospf]
[modifier les protocoles de routage des instances routing-instance-name des systèmes logical-system-name logiques ospf]
L’adresse distante de la liaison OSPF doit être spécifiée avec une adresse de bouclage pour le VPN distant. Le chemin vers cette adresse doit être propagé par BGP. Pour spécifier l’adresse du point d’accès distant, incluez l’instruction sham-link-remote :
sham-link-remote address <metric number>;
Vous pouvez inclure cette déclaration aux niveaux hiérarchiques suivants :
[modifier les protocoles de routage-instances routing-instance-name zone area-idospf ]
[modifier les protocoles de routage des instances routing-instance-name des systèmes logical-system-name logiques area-id]
Vous pouvez éventuellement inclure l’option métrique pour définir une valeur métrique pour le point de fin à distance. La valeur métrique spécifie le coût d’utilisation de la liaison. Les routes avec des mesures de chemin total inférieures sont préférées à celles avec des mesures de chemin plus élevées.
Vous pouvez configurer une valeur de 1 à 65 535. La valeur par défaut est 1.
Exemple de liaisons OSPF Sham
Cet exemple montre comment activer des liaisons OSPF factices sur un routeur PE.
Voici la configuration de l’interface de bouclage sur le routeur PE. L’adresse configurée est pour le point d’extrémité local de la liaison simulacre 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 factice OSPF. L’instruction locale sim-link est configurée avec l’adresse de l’interface de bouclage local :
[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 qui connecte plusieurs domaines OSPF, la configuration des ADRESSES 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 d’arrière-porte. 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, un routage avec un ID de domaine nul est géré différemment d’un routage sans ID de domaine.
Routage reçu |
ID de domaine de la route reçue |
ID de domaine sur le routeur de réception |
Routage redistribué et annoncé en tant que |
|---|---|---|---|
Route de type 3 |
A.B.C.D. |
A.B.C.D. |
Type 3 LSA |
Route de type 3 |
A.B.C.D. |
E.F.G.H |
Type 5 LSA |
Route de type 3 |
0.0.0.0 |
0.0.0.0 |
Type 3 LSA |
Route de type 3 |
Null |
0.0.0.0 |
Type 3 LSA |
Route de type 3 |
Null |
Null |
Type 3 LSA |
Route de type 3 |
0.0.0.0 |
Null |
Type 3 LSA |
Route de type 3 |
A.B.C.D. |
Null |
Type 5 LSA |
Route de type 3 |
Null |
A.B.C.D. |
Type 3 LSA |
Route 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 [modifier les protocoles de routage-instances routing-instance-name ospf] pour OSPF version 2 et au niveau de la hiérarchie [modifier les protocoles de routage-instances routing-instance-name ospf3] pour OSPF version 3. Les descriptions de configuration suivantes présentent uniquement l’instruction OSPF version 2. Cependant, les sous-états 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 déclaration aux niveaux hiérarchiques suivants :
[modifier les protocoles de routage-instances routing-instance-name ospf]
[modifier les protocoles de routage des instances routing-instance-name 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 toute boucle. Par défaut, cette balise est automatiquement calculée 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 déclaration aux niveaux hiérarchiques suivants :
[modifier les protocoles de routage-instances routing-instance-name ospf]
[modifier les protocoles de routage des instances routing-instance-name des systèmes logical-system-name logiques ospf]
La gamme est de 1 à 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 configuration de ce type, voir Configuration d’un ID de domaine OSPF pour un VPN de couche 3.
VPN de couche 3 en étoile et iDs de domaine OSPF
Le comportement par défaut d’un ID de domaine OSPF cause certains 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 HUB PE avec des liaisons directes vers un routeur CE hub. Le routeur PE du hub reçoit les mises à jour BGP de couche 3 des autres routeurs PE en étoile, qui sont importées dans l’instance de routage en étoile. À partir de l’instance de routage en étoile, les LSA OSPF sont créés et envoyés au routeur CE du hub.
Le routeur CE hub agrège généralement 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 en étoile distants contenant les préfixes agrégés. Toutefois, s’il existe des LSA de type 3 non-agrégées ou des LSA externes, deux problèmes surviennent en ce qui concerne la façon dont le routeur PE hub provient et envoie des LSA au routeur CE du hub, et comment le routeur PE du hub traite les LSA reçus du routeur CE du hub :
Par défaut, tous les LSA créés par le routeur HUB PE dans l’instance de routage en étoile ont l’ensemble de bits DN. En outre, tous les LSA d’origine externe ont l’ensemble de balises de routage VPN. Ces paramètres permettent d’éviter les boucles de routage. Pour les LSA récapitulatifs de type 3, les boucles de routage ne sont pas un problème, car le routeur CE du hub, en tant que routeur de bordure de zone (ABR), réorigine les LSA avec le bit DN clair et les renvoie au routeur PE du hub. Toutefois, le routeur CE du hub ne réoriente pas les 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 DN bit clear et la balise de routage VPN définie sur 0 en modifiant la configuration de l’instance de routage du routeur PE. 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, puis les transfère au routeur PE du hub, le routeur PE du hub peut utiliser les LSA dans le calcul de son routage OSPF.
Lorsque les LSA inondés par le routeur CE arrivent à l’instance de routage du routeur PE du hub, le routeur PE du hub, agissant comme un ABR, ne prend pas en compte ces LSA dans ses calculs de routage OSPF, même si les LSA n’ont pas le DN bits défini et que les LSA externes n’ont pas d’ensemble de balises de routage VPN. On suppose que les LSA proviennent d’une zone dorsal disjointe.
Vous pouvez modifier la configuration de l’instance de routage du routeur PE pour que le routeur PE agisse comme un 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 ce changement de configuration, l’instance de routage du routeur PE agit comme une instance non-ABR. Le routeur PE considère ensuite les LSA arrivant du routeur CE du hub comme s’ils venaient d’une zone contiguë non backbone.
Configuration 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 auprès 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 la rip déclaration :
rip {
group group-name {
export policy-names;
neighbor interface-name;
}
}
Vous pouvez inclure cette déclaration 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 routes qu’il reçoit. Pour annoncer les routes d’un routeur PE à 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 de stratégies pour rip, consultez la politique d’importation RIP.
Pour spécifier une stratégie d’exportation pour RIP, incluez l’énoncé export :
export [ policy-names ];
Vous pouvez inclure cette déclaration 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’énoncé rib-groups :
rib-groups group-name;
Vous pouvez inclure cette déclaration 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é dans 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, consultez la bibliothèque de protocoles de routage Junos OS.
import-rib [ group-names ];
Vous pouvez inclure cette déclaration 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 RIP dans l’environnement de périphérie du fournisseur de périphérie (CE-PE) client 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 auprès des voisins configurés dans n’importe quelle hiérarchie d’instances 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 protocole OSPF ou OSPFv3.
Configuration des routes statiques entre les routeurs PE et CE
Vous pouvez configurer des routes statiques (non inchangées) entre les routeurs PE et CE d’une instance de routage VPN. Pour configurer un routage statique pour un VPN, vous devez le 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 un routage statique entre les routeurs PE et CE, incluez l’énoncé static :
static {
route destination-prefix {
next-hop [ next-hops ];
static-options;
}
}
Vous pouvez inclure cette déclaration 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, consultez la 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 à partir 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 avec plusieurs domaines OSPF. Dans un VPN qui connecte plusieurs domaines OSPF, les routes d’un domaine peuvent se chevaucher avec 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 du routage. L’ID de domaine configuré sur une stratégie de communauté est utilisé pour définir des routes exportées.
Pour plus d’informations sur les identifiants de domaine OSPF et les VPN de couche 3, voir 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ésumé 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 so-0/0/0 trafic vers le 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 du 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 et 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 hiérarchique [edit protocols] :
[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 des 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 des 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 concerne 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 le montre 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 au routeur CE2 et vice-versa soient distribuées en tant que LSA de type 3. Si vous configurez différents IDENTIFIANTs de domaine OSPF dans les instances de routage du routeur PE1 et du routeur 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ésumé 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;
}
}
}
}
}
Présentation des liens factices OSPFv2
Vous pouvez créer une liaison intra-zone ou une liaison factice entre deux équipements de routage de périphérie du fournisseur (PE) afin que la dorsale VPN soit préférée à la liaison arrière. Une liaison d’arrière-porte est une liaison de secours qui connecte les équipements de périphérie du client (CE) au cas où la dorsale VPN n’est pas disponible. Lorsqu’une telle liaison de sauvegarde est disponible et que les équipements 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 sauvegarde est considérée comme une liaison intra-zone, tandis que la dorsale VPN est toujours considérée comme une liaison intera. Les liaisons intra-zone sont toujours préférées aux liaisons inter-zones.
La liaison factice est une liaison intra-zone point à point non numérotée entre les équipements PE. Lorsque le réseau dorsal VPN dispose d’une liaison intra-zone factice, cette liaison factice peut être préférée à la liaison de sauvegarde si la liaison factice a une métrique OSPF inférieure à la liaison de sauvegarde.
Le lien factice est annoncé à l’aide de publicités d’état de lien de type 1 (LSA). Les liens factices ne sont valables que pour les instances de routage et OSPFv2.
Chaque lien factice est identifié par la combinaison d’une adresse de point de terminaison locale et d’une adresse de terminal distante. La figure 3 montre une liaison factice OSPFv2. Les routeurs CE1 et CE2 sont situés dans la même zone OSPFv2. Ces équipements de routage de périphérie client (CE) sont reliés entre eux par un VPN de couche 3 sur le routeur PE1 et le routeur PE2. En outre, les routeurs CE1 et CE2 sont connectés par une liaison intra-zone utilisée comme sauvegarde.
OSPFv2 traite la liaison via le VPN de couche 3 comme une liaison inter-zones. Par défaut, OSPFv2 préfère les liaisons intra-zone aux liaisons inter-zones, de sorte qu’OSPFv2 sélectionne la liaison intra-zone de sauvegarde comme chemin actif. Cette situation n’est pas acceptable dans une configuration où la liaison intra-zone n’est pas le chemin principal attendu pour le trafic entre les équipements de routage CE. Vous pouvez configurer la métrique de la liaison factice 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 équipements 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 métrique.
Vous devez configurer une liaison OSPFv2 dans les circonstances suivantes :
Deux équipements de routage CE sont reliés entre eux par un VPN de couche 3.
Ces équipements de routage CE se trouvent dans la même zone OSPFv2.
Une liaison intra-zone est configurée entre les deux équipements de routage CE.
S’il n’y a pas de liaison intra-zone entre les équipements de routage CE, vous n’avez pas besoin de configurer une liaison factice OSPFv2.
Dans junos OS version 9.6 et versions ultérieures, une liaison OSPFv2 est installée dans la table de routage en tant que route cachée. En outre, un routage BGP n’est pas exporté vers OSPFv2 si une liaison OSPF correspondante est disponible.
Dans Junos OS version 16.1 et versions ultérieures, les liaisons simulacres OSPF sont prises en charge sur les instances par défaut. Le coût de la liaison factice est défini dynamiquement sur la métrique aigp du routage BGP si aucune métrique n’est configurée sur la liaison factice par l’utilisateur. Si la métrique aigp n’est pas présente dans le routage BGP, alors le coût de la liaison factice est par défaut de 1.
Exemple : configuration de liaisons sham OSPFv2
Cet exemple montre comment activer des liaisons factices OSPFv2 sur un équipement de routage PE.
Exigences
Aucune configuration spéciale au-delà de l’initialisation de l’équipement n’est nécessaire avant de configurer cet exemple.
Aperçu
Le lien factice est un lien intra-zone point à point non numéroté et est annoncé au moyen d’une publicité d’état de lien de type 1 (LSA). Les liens factices ne sont valables que pour les instances de routage et OSPFv2.
Chaque liaison factice est identifiée par une combinaison de l’adresse de point de terminaison locale et d’une adresse de terminal distante et de la zone OSPFv2 à laquelle elle appartient. Vous configurez manuellement la liaison factice entre deux équipements PE, tous deux au sein de la même instance de routage et de transfert VPN (VRF), et vous spécifiez l’adresse du point d’extrémité local de la liaison factice. Cette adresse est utilisée comme source pour les paquets de liaison factices et est également utilisée par l’équipement de routage PE distant comme point d’extrémité de liaison factice. Vous pouvez également inclure l’option optionnelle metric permettant de définir une valeur métrique pour le point d’extrémité distant. La valeur métrique spécifie le coût d’utilisation de la liaison. Les routes avec des mesures de chemin total inférieures sont préférées à celles avec des mesures de chemin plus élevées.
Pour activer les liaisons factices OSPFv2 sur un équipement de routage PE :
Configurez une interface de bouclage supplémentaire sur l’équipement de routage PE.
Configurez l’instance de routage VRF qui prend en charge les VPN de couche 3 sur l’équipement de routage PE, et associez la liaison factice à une zone OSPF existante. La configuration de liaison factice OSPFv2 est également incluse dans l’instance de routage. Vous configurez l’adresse du point de terminaison local de la liaison factice, qui est l’adresse de bouclage du VPN local, et l’adresse du point de terminaison distant, qui est l’adresse de bouclage du VPN distant. Dans cet exemple, l’instance de routage VRF est nommée rouge.
La figure 4 montre une liaison factice OSPFv2.
Topologie
de liaison SHAM OSPFv2
Les équipements de la figure représentent les fonctions suivantes :
Les CE1 et CE2 sont les équipements de périphérie du client.
LES PE1 et PE2 sont les équipements de périphérie du fournisseur.
P est l’équipement du fournisseur.
La configuration rapide cli montre la configuration de tous les équipements en figure 4. La section Procédure étape par étape décrit les étapes sur l’équipement PE1.
Configuration
Procédure
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI 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
Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Modification de la configuration de Junos OS dans le Guide de l’utilisateur CLI.
Pour configurer des liaisons simulacres OSPFv2 sur chaque équipement PE :
-
Configurez les interfaces, y compris 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 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 centrale 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 centrale 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 factice OSPFv2.
Incluez l’interface de bouclage supplémentaire dans l’instance de routage et également dans la configuration OSPF.
Notez que la métrique sur l’interface de liaison factice est définie à 10. Sur la liaison OSPF de sauvegarde de l’équipement CE1, la métrique est définie sur 100. Cela fait que le lien factice est 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 fini de configurer l’équipement, validez la configuration.
[edit] user@R1# commit
Résultats
Confirmez votre configuration en entrant les show interfaces show routing-instances commandes. 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 de liaison factices
- Vérification des terminaux locaux et distants de la liaison factice
- Vérifier les adjacenances de liaison factices
- Vérification de l’annonce d’état de lien
- Vérification de la sélection des chemins
Vérification des interfaces de liaison factices
But
Vérifiez l’interface de liaison factice. La liaison factice est traitée comme une interface dans OSPFv2, avec le nom affiché comme shamlink.<unique identifier>, où l’identifiant unique est un nombre. Par exemple, shamlink.0. Le lien factice apparaît sous la forme d’une interface point à point.
Action
Depuis le mode opérationnel, saisissez 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 de la liaison factice
But
Vérifiez les terminaux locaux et distants de la liaison factice. Le MTU pour l’interface de liaison factice est toujours zéro.
Action
Depuis le mode opérationnel, saisissez 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érifier les adjacenances de liaison factices
But
Vérifiez les adjacenances entre les liaisons factices configurées.
Action
Depuis le mode opérationnel, saisissez 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 d’état de lien
But
Vérifiez que le routeur LSA à l’origine de l’instance porte l’adjacence de liaison factice comme une liaison point à point non numérotée. Les données de liaison pour les liens factices sont un nombre allant de 0x80010000 à 0x8001ffff.
Action
Depuis le mode opérationnel, saisissez 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 des chemins
But
Vérifiez que le chemin VPN de couche 3 est utilisé à la place du chemin de sauvegarde.
Action
Depuis le mode opérationnel, saisissez la traceroute commande de l’équipement CE1 à l’équipement 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
Sens
L’opération traceroute montre que le VPN de couche 3 est le chemin préféré. Si vous supprimiez le lien factice ou si vous deviez modifier la métrique OSPF pour préférer ce chemin de sauvegarde, le chemin de trace indiquerait que le chemin de sauvegarde est préféré.
Configuration de sessions multihop EBGP entre les routeurs PE et CE dans des VPN de couche 3
Vous pouvez configurer une session multihop 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 les routeurs PE et CE ne nécessite pas de configuration d’instructions supplémentaires. Cependant, l’utilisation d’EBGP entre les routeurs PE et CE nécessite la configuration de l’instruction multihop .
Pour configurer une session multihop BGP externe pour la connexion entre les routeurs PE et CE, incluez l’énoncé multihop sur le routeur PE. Pour éviter les boucles de routage, vous devez configurer une valeur TTL (time-to-live) pour la session multihop :
multihop ttl-value;
Pour obtenir la liste des niveaux hiérarchiques sur lesquels vous pouvez configurer cette déclaration, consultez la section résumée de cette déclaration.
Configuration d’une topologie VPN LDP-over-RSVP
Cet exemple montre comment configurer une topologie VPN dans laquelle les paquets LDP sont tunnelés sur un LSP RSVP. Cette configuration se compose des composants suivants (voir figure 5) :
Un SEUL VPN (VPN-A)
Deux routeurs PE
LDP comme protocole de signalisation entre les routeurs PE et leurs routeurs P adjacents
Un LSP RSVP entre deux routeurs P sur lesquels le LDP est tunnelisé
VPN LDP-over-RSVP
Les étapes suivantes décrivent comment cette topologie est établie et comment les paquets sont envoyés du routeur CE CE2 au routeur CE1 :
Les routeurs P1 et P3 établissent les LSP RSVP entre eux et installent leurs adresses de bouclage dans leurs tables de routage inet.3.
Le routeur PE 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, accessible à l’aide du LSP RSVP.
Le routeur P1 envoie ses liaisons d’étiquettes, y compris 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, y compris 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 elles.
Lorsque le routeur PE1 annonce aux routes PE2 qu’il a apprises du routeur CE1, il inclut son label VPN. (Le routeur PE crée le label VPN et le 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 label VPN au routeur PE1.
Lorsque le routeur PE2 souhaite transférer un paquet vers le routeur CE1, il pousse deux labels sur la pile de labels du paquet : d’abord le label VPN lié à l’interface entre le routeur PE1 et le routeur CE1, puis le label LDP utilisé pour atteindre le routeur PE1. Ensuite, il transfère les paquets vers le routeur P3 sur l’interface so-0/0/1.0.
Lorsque le routeur P3 reçoit les paquets du routeur PE2, il permute le label LDP qui se trouve au-dessus de la pile (selon sa base de données LDP) et pousse également un label RSVP sur le sommet de la pile afin que le paquet puisse désormais être commuté par le LSP RSVP. À ce stade, il y a trois labels sur la pile : le label interne (en bas) est le label VPN, le milieu est le label LDP et l’extérieur (en haut) est le label RSVP.
Le routeur P2 reçoit le paquet et le bascule vers le routeur P1 en permutant le label RSVP. Dans cette topologie, comme le routeur P2 est l’avant-dernier routeur du LSP, il pop le label RSVP et transfère le paquet sur l’interface
so-1/1/0.0vers le routeur P1. À ce stade, il y a deux étiquettes sur la pile : le label interne est le label VPN et l’étiquette externe est le label LDP.Lorsque le routeur P1 reçoit le paquet, il pop le label externe (le label 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 sortant, de sorte que le routeur P1 pop le label LDP au lieu de l’échanger avec un autre label. À ce stade, il n’y a qu’un seul label sur la pile, le label VPN.Lorsque le routeur PE1 reçoit le paquet, il pop le label VPN et transfère le paquet en tant que paquet IPv4 vers le routeur CE1 sur l’interface
ge-1/1/0.0.
Un ensemble d’opérations similaire se produit pour les paquets envoyés par le 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 labels LDP, RSVP et VPN sont annoncés par les différents routeurs. Ces étapes comprennent des exemples de valeurs d’étiquettes (illustrés en figure 6).
Étiquettes LDP
Le routeur PE1 annonce le label 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 le label RSVP 3 au routeur P2.
Le routeur P2 annonce le label RSVP 100 003 au routeur P3.
Label VPN
Le routeur PE1 annonce le label VPN 100 004 vers le 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 à 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 permute le saut suivant de l’interface
so-1/0/0et le remplace par un saut suivant de PE1. Il ajoute également deux labels pour atteindre le routeur PE1, d’abord le label VPN (100 004), puis le label LDP (100 002). Le label VPN est donc le label interne (inférieur) sur la pile, et le label LDP est le label externe.Le routeur P3 permute le label LDP ajouté par le routeur PE2 (100 002) et le remplace par son label LDP pour atteindre le routeur PE1 (100 001). Il ajoute également le label RSVP pour atteindre le routeur P2 (100 003).
Le routeur P2 retire le label RSVP (100 003) car il s’agit de l’avant-dernier saut du LSP MPLS.
Le routeur P1 retire le label LDP (100 001) car il s’agit de l’avant-dernier routeur LDP. Il permute également le saut suivant de PE1 et le remplace par l’interface du saut suivant,
so-1/0/0.Le routeur PE1 supprime le label VPN (100 004). Il permute également l’interface du saut suivant et la
so-1/0/0remplace par son interface de saut suivant,ge-1/1/0.Le routeur CE1 supprime l’interface du saut suivant de
ge-1/1/0, et l’en-tête du paquet ne contient plus qu’une adresse source B et une adresse de destination A.
La dernière section de cet exemple consolide les déclarations nécessaires pour configurer la fonctionnalité VPN sur chacun des routeurs de service P illustrés en figure 5.
Dans cet exemple, un numéro AS privé est utilisé pour le distinctionur de route et la cible de routage. Ce numéro n’est utilisé qu’à titre d’illustration. Lorsque vous configurez des VPN, vous devez utiliser un numéro AS assigné.
Les sections suivantes expliquent comment configurer la fonctionnalité VPN sur les routeurs PE et P. Les routeurs CE ne disposent pas d’informations 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 LSP MPLS entre les routeurs P
- Configuration d’IBGP sur les routeurs PE
- Configuration des instances de routage pour les VPN sur les routeurs PE
- Configuration de la stratégie VPN sur les routeurs PE
- Configuration VPN LDP-over-RSVP Résumé 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 vous devez 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 connectés aux routeurs PE. Vous devez configurer LDP uniquement sur les interfaces du 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 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, même si vous n’avez pas besoin de configurer le LDP, vous pouvez éventuellement le configurer pour fournir un chemin LDP de secours au cas où le LSP RSVP ne fonctionnerait pas :
[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 P2, vous devez configurer RSVP et MPLS car ce routeur existe sur le chemin LSP MPLS entre les routeurs 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 LSP MPLS entre les routeurs P
Dans cet exemple de configuration, le LDP est tunnelisé sur un LSP RSVP. Par conséquent, en plus de configurer RSVP, vous devez activer la prise en charge de l’ingénierie du trafic dans un IGP, et vous devez créer un LSP MPLS pour tunneliser le trafic LDP.
Sur le routeur P1, activez RSVP et configurez une extrémité du tunnel LSP MPLS. Dans cet exemple, l’assistance technique 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 LSP MPLS. Là encore, l’assistance technique 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 VPN : pour indiquer que la session IBGP est pour le VPN, incluez l’instruction
family inet-vpn.Adresse de bouclage : incluez l’instruction
local-addressen spécifiant l’adresse de bouclage du routeur PE local. La session IBGP pour 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.Adresse voisine : incluez l’instruction
neighboren spé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 serviceNT VPN-A, vous devez donc configurer une instance de routage sur chaque routeur pour le VPN dans lequel vous définissez les éléments suivants :
Routeur de distinction, qui doit être unique pour chaque instance de routage sur le routeur PE. Il permet de 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 politique d’importation ne contienne qu’une
then rejectdéclaration, elle doit inclure une référence à une communauté. Sinon, lorsque vous essayez de valider la configuration, la validation échoue.Note:Dans cet exemple, un numéro AS privé est utilisé pour distinguer les routes. Ce numéro n’est utilisé qu’à titre d’illustration. Lorsque vous configurez des VPN, vous devez utiliser un numéro AS assigné.
Routage entre les routeurs PE et CE, requis pour que le routeur PE distribue des routes VPN vers et depuis les routeurs CE connectés. Vous pouvez configurer un protocole de routage (BGP, OSPF ou RIP) ou configurer un routage statique.
Sur le routeur PE1, configurez l’instance de routage suivante pour VPN-A. Dans cet exemple, le routeur PE1 utilise RIP pour distribuer des 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 des 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 de la stratégie VPN sur les routeurs PE
Vous devez configurer des stratégies d’importation et d’exportation 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 routage. Ce numéro n’est utilisé qu’à titre d’illustration. Lorsque vous configurez des VPN, vous devez utiliser un numéro AS assigné.
Sur le routeur PE1, configurez les stratégies d’importation et d’exportation VPN suivantes :
Les qualificatifs de stratégie illustrés dans cet exemple ne sont que ceux nécessaires au fonctionnement du VPN. Vous pouvez configurer des qualificatifs supplémentaires, selon les besoins, 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 déclarations 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 du routage sur l’ensemble de la session IBGP exécutée entre les routeurs PE.
Configuration VPN LDP-over-RSVP Résumé 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 l’assistance technique 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 l’assistance technique 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 les applications 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 permet de 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, qui fournit la résolution du 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 sorte 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 (Hypertexte Transfer Protocol) ou qui transfère uniquement le contenu multimédia en streaming.
Pour que cette configuration fonctionne, les conditions suivantes doivent être vraies :
Les interfaces qui utilisent le transfert basé sur des 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 veulent envoyer du trafic à la fois dans le VPN et vers Internet. Les chemins sont définis comme suit :
Le client A envoie du trafic vers le client E sur VPN A avec un chemin de retour qui utilise également VPN A (à l’aide de la table VRF du VPN).
Le client B envoie du trafic au client D sur VPN B avec un chemin de retour qui utilise un 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 à l’aide d’un routage standard (à l’aide de la table de routage inet.0), avec un chemin de retour qui utilise également le routage standard.
Cet exemple illustre qu’il existe une grande variété d’options pour configurer une topologie VPN de couche 3 basée sur les applications. Cette flexibilité s’est appliquée à de nombreuses implémentations réseau qui nécessitent un trafic spécifique pour être transféré dans un environnement de routage contraint.
Cet exemple de configuration affiche uniquement les parties de la configuration pour le transfert basé sur les filtres, les instances de routage et la stratégie. Il n’illustre pas comment configurer un VPN de couche 3.
La figure 7 illustre la topologie du réseau utilisée dans cet exemple.
Configuration sur le routeur A
Sur le routeur A, vous configurez l’interface pour les clients A, B et C. La configuration évalue le trafic entrant afin de 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, vous 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 des filtres ne doivent pas être liées à un VPN, vous devez configurer une autre méthode pour fournir des routes au saut suivant vers la table VRF. Pour ce faire, vous 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 correspond au trafic du client A et le transfère à l’instance de routage pour VPN A. Le deuxième terme correspond au trafic du client B qui est destiné au client D et le transfère à l’instance de routage pour VPN B. Le troisième terme correspond à tous les autres trafics, qui sont normalement transférés au moyen d’un transfert basé sur la destination en fonction des routes dans 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 VPN A et VPN B. Notez que ces déclarations comprennent toutes les déclarations 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 atteindre Internet. Vous devez injecter ce routage 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 vers le client E afin que tout le trafic entrant sur l’interface fe-1/1/1.0 qui corresponde à la stratégie VPN soit transféré sur 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
Comme les interfaces qui utilisent le transfert basé sur des filtres ne doivent pas être liées à un VPN, vous configurez une autre méthode pour fournir des routes à 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 un routage vers les clients pour le routage inet.0 normal, vous définissez un routage statique à inclure dans inet.0 et redistribuez le routage 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 configurez 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 normalement transféré 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;
}
}
}
}