VPN en étoile
Configuration des topologies VPN en étoile : une interface unique
Utilisez une configuration à interface unique pour annoncer un itinéraire par défaut à partir d’un ou plusieurs hubs.
La figure 1 illustre une application réseau en étoile VPN de couche 3 dans laquelle il n’existe qu’une seule interface entre le hub CE (CE1) et le hub PE (PE1). Il s’agit de la méthode recommandée pour configurer des topologies en étoile.
Dans cette configuration, un itinéraire par défaut est annoncé entre le hub et les rayons. Si des routes CE à rayons plus spécifiques doivent être échangées entre des routeurs à rayons CE, deux interfaces sont nécessaires entre le concentrateur CE et le concentrateur PE. Reportez-vous à la section Configuration de topologies VPN en étoile : deux interfaces pour obtenir un exemple à deux interfaces.
Dans cet exemple de configuration, la distribution du chemin des rayons est la suivante :
-
Spoke CE2 annonce ses routes vers Spoke PE2.
-
Spoke PE2 installe les routes de CE2 dans sa table de routage et de transfert VPN (VRF).
-
Spoke PE2 vérifie sa stratégie d’exportation VRF, ajoute la communauté de routes cibles et annonce les routes vers le hub PE1.
-
Hub PE1 vérifie sa stratégie d’importation VRF et installe les routes qui correspondent à la stratégie d’importation dans la table bgp.l3vpn.0.
-
Le hub PE1 installe les routes de la table bgp.l3vpn.0 dans la table VRF du hub.
-
Le hub PE1 annonce les routes de la table VRF du hub vers le hub CE1.
Dans cet exemple de configuration, la distribution de route par défaut est la suivante :
-
Le hub CE1 annonce une route par défaut vers le hub PE1.
-
Le hub PE1 installe la route par défaut dans la table VRF du hub.
-
Hub PE1 vérifie sa stratégie d’exportation VRF, ajoute la communauté cible de route et annonce la route par défaut vers les spoke PE2 et PE3.
-
Les spoke PE2 et PE3 vérifient leur politique d’importation VRF et installent la route par défaut dans la table bgp.l3vpn.0.
-
Les spoke PE2 et PE3 installent les routes de la table bgp.l3vpn.0 dans leurs tables spoke VRF.
-
Les rayons PE2 et PE3 annoncent le routage par défaut de la table VRF des rayons vers les rayons CE2 et CE3.
Les sections suivantes décrivent comment configurer une topologie en étoile avec une interface en fonction de la topologie illustrée à la figure 1 :
- Configuration du Hub CE1
- Configuration du Hub PE1
- Configuration du routeur P
- Configuration de Spoke PE2
- Configuration de Spoke PE3
- Configuration de Spoke CE2
- Configuration de Spoke CE3
- Activation des fonctionnalités de sortie sur le routeur Hub PE
Configuration du Hub CE1
Configurez le hub CE1 comme suit :
[edit routing-options]
static {
route 0.0.0.0/0 discard;
}
autonomous-system 100;
[edit protocols]
bgp {
group hub {
type external;
export default;
peer-as 200;
neighbor 10.49.4.1;
}
}
[edit policy-options]
policy-statement default {
term 1 {
from {
protocol static;
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term 2 {
then reject;
}
}
Configuration du Hub PE1
Configurez le hub PE1 comme suit :
[edit]
routing-instances {
hub {
instance-type vrf;
interface t3-0/0/0;
route-distinguisher 10.255.14.176:2;
vrf-target {
import target:200:100;
export target:200:101;
}
protocols {
bgp {
group hub {
type external;
peer-as 100;
as-override;
neighbor 10.49.4.2;
}
}
}
}
}
Configuration du routeur P
Configurez le routeur P comme suit :
[edit]
interfaces {
t3-0/1/1 {
unit 0 {
family inet {
address 10.49.2.1/30;
}
family mpls;
}
}
t3-0/1/3 {
unit 0 {
family inet {
address 10.49.0.2/30;
}
family mpls;
}
}
t1-0/2/0 {
unit 0 {
family inet {
address 10.49.1.2/30;
}
family mpls;
}
}
}
[edit]
protocols {
ospf {
area 0.0.0.0 {
interface t3-0/1/3.0;
interface t1-0/2/0.0;
interface t3-0/1/1.0;
interface lo0.0 {
passive;
}
}
}
ldp {
interface t3-0/1/1.0;
interface t3-0/1/3.0;
interface t1-0/2/0.0;
}
}
Configuration de Spoke PE2
Configurez le rayon PE2 comme suit :
[edit]
interfaces {
t3-0/0/0 {
unit 0 {
family inet {
address 10.49.0.1/30;
}
family mpls;
}
}
t1-0/1/2 {
unit 0 {
family inet {
address 10.49.3.1/30;
}
}
}
}
[edit protocols]
bgp {
group ibgp {
type internal;
local-address 10.255.14.182;
peer-as 200;
neighbor 10.255.14.176 {
family inet-vpn {
unicast;
}
}
}
}
ospf {
area 0.0.0.0 {
interface t3-0/0/0.0;
interface lo0.0 {
passive;
}
}
}
ldp {
interface t3-0/0/0.0;
}
[edit]
routing-instances {
spoke {
instance-type vrf;
interface t1-0/1/2.0;
route-distinguisher 10.255.14.182:20;
vrf-target {
import target:200:101;
export target:200:100;
}
protocols {
bgp {
group spoke {
type external;
peer-as 100;
as-override;
neighbor 10.49.3.2;
}
}
}
}
}
Configuration de Spoke PE3
Configurez les rayons PE3 comme suit :
[edit]
interfaces {
t3-0/0/0 {
unit 0 {
family inet {
address 10.49.6.1/30;
}
}
}
t3-0/0/1 {
unit 0 {
family inet {
address 10.49.2.2/30;
}
family mpls;
}
}
}
[edit protocols}
bgp {
group ibgp {
type internal;
local-address 10.255.14.178;
peer-as 200;
neighbor 10.255.14.176 {
family inet-vpn {
unicast;
}
}
}
}
ospf {
area 0.0.0.0 {
interface t3-0/0/1.0;
interface lo0.0 {
passive;
}
}
}
ldp {
interface t3-0/0/1.0;
}
[edit]
routing-instances {
spoke {
instance-type vrf;
interface t3-0/0/0.0;
route-distinguisher 10.255.14.178:30;
vrf-target {
import target:200:101;
export target:200:100;
}
protocols {
bgp {
group spoke {
type external;
peer-as 100;
as-override;
neighbor 10.49.6.2;
}
}
}
}
}
Configuration de Spoke CE2
Configurez le rayon CE2 comme suit :
[edit routing-options]
autonomous-system 100;
{edit protocols]
bgp {
group spoke {
type external;
export loopback;
peer-as 200;
neighbor 10.49.3.1;
}
}
Configuration de Spoke CE3
Configurez le rayon CE3 comme suit :
[edit routing-options]
autonomous-system 100;
[edit protocols]
bgp {
group spoke {
type external;
export loopback;
peer-as 200;
neighbor 10.49.6.1;
}
}
Dans cet exemple de configuration, le transfert de trafic est le suivant entre le spoke CE2 et le hub CE1 :
-
Le spoke CE2 transfère le trafic à l’aide de l’itinéraire par défaut appris du spoke PE2 via BGP.
0.0.0.0/0 *[BGP/170] 02:24:15, localpref 100 AS path: 200 200 I > to 10.49.3.1 via t1-3/0/1.0 -
Spoke PE2 effectue une recherche de route dans la table spoke VRF et transfère le trafic au hub PE1 (via le routeur P - PE2 envoie deux étiquettes) en utilisant la route par défaut apprise via BGP.
0.0.0.0/0 *[BGP/170] 01:35:45, localpref 100, from 10.255.14.176 AS path: 100 I > via t3-0/0/1.0, Push 100336, Push 100224(top) -
Le hub PE1 effectue une recherche de route dans la table mpls.0 pour l’étiquette
100336VPN .100336 *[VPN/170] 01:37:03 > to 10.49.4.2 via t3-0/0/0.0, Pop -
Le hub PE1 transfère le trafic de l’interface
t3-0/0/0.0vers le hub CE1.
Dans cet exemple de configuration, le transfert de trafic est le suivant entre le hub CE1 et le spoke CE2 :
-
Le hub CE1 transfère le trafic au hub PE1 en utilisant la route apprise via BGP.
10.49.10.250/32 *[BGP/170] 02:28:46, localpref 100 AS path: 200 200 I > to 10.49.4.1 via t3-3/1/0.0 -
Le hub PE1 effectue une recherche d’itinéraire dans la table VRF du hub et transfère le trafic vers le spoke PE2 (via le routeur P : PE1 envoie deux étiquettes).
10.49.10.250/32 *[BGP/170] 01:41:05, localpref 100, from 10.255.14.182 AS path: 100 I > via t1-0/1/0.0, Push 100352, Push 100208(top) -
Spoke PE2 effectue une recherche de route dans la table mpls.0 pour l’étiquette
100352VPN .100352 *[VPN/170] 02:31:39 > to 10.49.3.2 via t1-0/1/2.0, Pop -
Le spoke PE2 transfère le trafic de l’interface
t1-0/1/2.0vers le spoke CE2.
Dans cet exemple de configuration, le transfert de trafic est le suivant entre le spoke CE2 et le spoke CE3 :
-
Le spoke CE2 transfère le trafic à l’aide de l’itinéraire par défaut appris du spoke PE2 via BGP.
0.0.0.0/0 *[BGP/170] 02:24:15, localpref 100 AS path: 200 200 I > to 10.49.3.1 via t1-3/0/1.0 -
Le spoke PE2 effectue une recherche de route dans la table spoke VRF et transfère le trafic au hub PE1 (via le routeur P - PE2 envoie deux étiquettes) en utilisant l’itinéraire par défaut appris via BGP.
0.0.0.0/0 *[BGP/170] 01:35:45, localpref 100, from 10.255.14.176 AS path: 100 I > via t3-0/0/1.0, Push 100336, Push 100224(top) -
Le hub PE1 effectue une recherche de route dans la table mpls.0 pour l’étiquette
100336VPN .100336 *[VPN/170] 01:37:03 > to 10.49.4.2 via t3-0/0/0.0, Pop -
Le hub PE1 transfère le trafic sortant de l’interface
t3-0/0/0.0vers le hub CE1. -
Le hub CE1 transfère le trafic au hub PE1 à l’aide du routeur appris via BGP.
10.49.10.253/32 *[BGP/170] 02:40:03, localpref 100 AS path: 200 200 I > to 10.49.4.1 via t3-3/1/0.0 -
Le hub PE1 effectue une recherche de route dans la table VRF du hub et transfère le trafic vers le spoke PE3 (via le routeur P : PE1 envoie deux étiquettes).
10.49.10.253/32 *[BGP/170] 01:41:05, localpref 100, from 10.255.14.178 AS path: 100 I > via t1-0/1/0.0, Push 100128, Push 100192(top) -
Spoke PE3 effectue une recherche de route dans la table mpls.0 pour l’étiquette
100128VPN.100128 *[VPN/170] 02:41:30 > to 10.49.6.2 via t3-0/0/0.0, Pop -
Le spoke PE3 transfère le trafic de l’interface
t3-0/0/0.0vers le spoke CE3.
Si des fonctionnalités de sortie sont requises sur le hub PE et nécessitent une recherche de transfert IP sur la table de routage VRF du hub, reportez-vous à la section Activation des fonctionnalités de sortie sur le routeur Hub PE.
Activation des fonctionnalités de sortie sur le routeur Hub PE
Cet exemple est fourni conjointement avec Configuration des topologies VPN en étoile : une interface. Cet exemple utilise également la topologie illustrée à la Figure 1.
Si des fonctionnalités de sortie sont requises sur le hub PE qui nécessitent une recherche de transfert IP sur la table de routage VRF du hub, la configuration détaillée dans Configuration des topologies VPN en étoile : une interface ne fonctionnera pas. L’application de l’instruction sur l’instance de routage du hub force le vrf-table-label transfert du trafic d’un PE spoke distant vers le PE du hub et force l’exécution d’une recherche IP. Étant donné que des routes de rayon spécifiques se trouvent dans la table VRF du hub, le trafic sera transféré vers un PE spoke sans passer par le CE du hub.
Le hub PE annonce la route par défaut comme suit, à l’aide de l’étiquette VPN 1028 :
hub.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
* 0.0.0.0/0 (1 entry, 1 announced)
BGP group ibgp type Internal
Route Distinguisher: 10.255.14.176:2
VPN Label: 1028
Nexthop: Self
Localpref: 100
AS path: 100 I
Communities: target:200:101
Le trafic entrant est transféré à l’aide de l’étiquette VPN 1028. La table mpls.0 indique qu’une recherche IP dans la table hub.inet.0 est requise :
1028 *[VPN/0] 00:00:27
to table hub.inet.0, Pop
Toutefois, la table VRF hub.inet.0 contient des routes de rayon spécifiques :
10.49.10.250/32 *[BGP/170] 00:00:05, localpref 100, from 10.255.14.182
AS path: 100 I
> via t1-0/1/0.0, Push 100352, Push 100208(top)
10.49.10.253/32 *[BGP/170] 00:00:05, localpref 100, from 10.255.14.178
AS path: 100 I
> via t1-0/1/0.0, Push 100128, Push 100192(top)
De ce fait, le trafic est transféré directement aux PE spoke sans passer par le CE du hub. Pour éviter cela, vous devez configurer une instance de routage secondaire pour le trafic en aval dans le hub PE1.
Configuration du Hub PE1
Configurez le hub PE1 comme suit :
[edit]
routing-instances {
hub {
instance-type vrf;
interface t3-0/0/0.0;
route-distinguisher 10.255.14.176:2;
vrf-target {
import target:200:100;
export target:200:101;
}
no-vrf-advertise;
routing-options {
auto-export;
}
protocols {
bgp {
group hub {
type external;
peer-as 100;
as-override;
neighbor 10.49.4.2;
}
}
}
}
hub-downstream {
instance-type vrf;
route-guisher 10.255.14.176:3;
vrf-target target:200:101;
vrf-table-label;
routing-options {
auto-export;
}
}
}
Lorsque l’instruction no-vrf-advertise est utilisée au niveau de la [edit routing-instances hub] hiérarchie, aucun groupe de tables de routage ni aucune stratégie d’exportation VRF n’est requis. L’instruction no-vrf-advertise configure l’EP du hub pour qu’il n’annonce pas les routes VPN à partir de l’instance hubde routage principale. Ces routes sont annoncées à la place à partir de l’instance hub_downstreamde routage secondaire. Pour plus d’informations sur l’instruction, reportez-vous à la no-vrf-advertise bibliothèque de protocoles de routage Junos OS.
L’instruction auto-export au niveau de la [edit routing-instances hub-downstream routing-options] hiérarchie identifie les routes exportées de l’instance du hub vers l’instance du hub en aval en examinant les cibles de route définies pour chaque instance de routage. Pour plus d’informations sur l’utilisation de l’instruction, reportez-vous à la auto-export bibliothèque de protocoles de routage Junos OS. Pour plus d’exemples de stratégie d’exportation, reportez-vous à la section Configuration de VPN superposés à l’aide de l’exportation automatique.
Avec cette configuration sur le PE du hub, le trafic CE en étoile passe par le CE du hub et permet d’activer les fonctionnalités de sortie (telles que le filtrage) sur le PE du hub.
Dans cet exemple de configuration, le transfert de trafic est le suivant entre le spoke CE2 et le spoke CE3 :
-
Le spoke CE2 transfère le trafic à l’aide de l’itinéraire par défaut appris du spoke PE2 via BGP.
0.0.0.0/0 *[BGP/170] 02:24:15, localpref 100 AS path: 200 200 I > to 10.49.3.1 via t1-3/0/1.0 -
Le spoke PE2 effectue une recherche de route dans la table spoke VRF et transfère le trafic au hub PE1 (via le routeur P - PE2 envoie deux étiquettes) en utilisant l’itinéraire par défaut appris via BGP.
spoke.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[BGP/170] 00:00:09, localpref 100, from 10.255.14.176 AS path: 100 I > via t3-0/0/0.0, Push 1029, Push 100224(top) -
Le hub PE1 effectue une recherche de route dans la table mpls.0 pour l’étiquette
1029VPN .mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1029 *[VPN/0] 00:11:49 to table hub_downstream.inet.0, PopL’étiquette
1029VPN est annoncée pour les raisons suivantes :-
L’instruction
vrf-table-labelest appliquée au niveau de la[edit routing-instances hub_downsteam]hiérarchie dans la configuration PE1 du hub. -
L’instruction
no-vrf-advertiseest appliquée au niveau de la[edit routing-instances hub]hiérarchie, demandant au routeur d’annoncer la route à partir de la table secondaire.
Par conséquent, les recherches d’adresses IP sont effectuées dans la table hub_downstream.inet.0, et non dans la table hub.inet.0.
Émettez la
show route advertising-protocolcommande sur le PE du hub à un PE spoke pour vérifier l’annonce de l’étiquette1029VPN :user@host> show route advertising-protocol hub_downstream.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) * 0.0.0.0/0 (1 entry, 1 announced) BGP group ibgp type Internal Route Distinguisher: 10.255.14.176:3 VPN Label: 1029 Nexthop: Self Localpref: 100 AS path: 100 I Communities: target:200:101 -
-
Le hub PE1 effectue une recherche IP dans la
hub_downstream.inet.0table et transfère l’interfacet3-0/0/0.0de sortie du trafic au hub CE1.hub_downstream.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 0.0.0.0/0 (1 entry, 1 announced) *BGP Preference: 170/-101 Next-hop reference count: 4 Source: 10.49.4.2 Next hop: 10.49.4.2 via t3-0/0/0.0, selected State: <Secondary Active Ext> Peer AS: 100 Age: 3:03 Task: BGP_100.10.49.4.2+1707 Announcement bits (2): 0-KRT 2-BGP.0.0.0.0+179 AS path: 100 I Communities: target:200:101 Localpref: 100 Router ID: 10.49.10.251 Primary Routing Table hub.inet.0Le table de routage principal est
hub.inet.0, ce qui indique que cet itinéraire a été exporté de la tablehub.inet.0vers cette table hub_downstream.inet.0 à la suite de l’instructionno-vrf-advertiseau niveau de la[edit routing-instances hub]hiérarchie et de l’instructionauto-exportau niveau de la[edit routing-instances hub-downstream routing-options]hiérarchie dans la configuration PE1 du hub. -
Le hub CE1 transfère le trafic au hub PE1 à l’aide du routeur appris via BGP.
10.49.10.253/32 *[BGP/170] 02:40:03, localpref 100 AS path: 200 200 I > to 10.49.4.1 via t3-3/1/0.0 -
Le hub PE1 effectue une recherche de route dans la table VRF du hub et transfère le trafic vers le spoke PE3 (via le routeur P : PE1 envoie deux étiquettes).
10.49.10.253/32 *[BGP/170] 01:41:05, localpref 100, from 10.255.14.178 AS path: 100 I > via t1-0/1/0.0, Push 100128, Push 100192(top) -
Spoke PE3 effectue une recherche de route dans la table mpls.0 pour l’étiquette
100128VPN .100128 *[VPN/170] 02:41:30 > to 10.49.6.2 via t3-0/0/0.0, Pop -
Le spoke PE3 transfère l’interface
t3-0/0/0.0de sortie du trafic vers le spoke CE3.
Configuration des topologies VPN en étoile : deux interfaces
Utilisez une configuration à deux interfaces pour propager les routes d’un rayon à l’autre.
L’exemple de cette section configure une topologie en étoile avec deux interfaces à l’aide des composants suivants (voir Figure 2) :
-
Routeur PE à un concentrateur (routeur D).
-
Un routeur CE central connecté au routeur PE du concentrateur. Pour que cette topologie VPN en étoile fonctionne correctement, deux interfaces doivent connecter le routeur PE du hub au routeur CE du hub, et chaque interface doit avoir sa propre table VRF sur le routeur PE :
-
La première interface (ici, l’interface ge-0/0/0.0) est utilisée pour annoncer les routes des rayons vers le routeur CE de la centrale. La table VRF associée à cette interface contient les routes annoncées par les routeurs spoke PE vers le routeur CE du concentrateur.
-
La deuxième interface (ici, l’interface ge-0/0/1.0) est utilisée pour recevoir les annonces de route du hub CE qui sont destinées aux routeurs en étoile. La table VRF associée à cette interface contient les routes annoncées par le routeur CE du hub vers les routeurs spoke PE. Dans cet exemple, deux interfaces physiques distinctes sont utilisées. Cela fonctionnerait également si vous deviez configurer deux interfaces logiques distinctes partageant la même interface physique entre le routeur PE de la centrale et le routeur CE de la centrale.
-
-
Routeurs PE à deux branches (routeur E et routeur F).
-
Routeurs CE à deux rayons (CE1 et CE2), un connecté à chaque routeur PE à rayons.
-
LDP comme protocole de signalisation.
Dans cette configuration, la distribution de routes à partir du routeur spoke CE CE1 se déroule comme suit :
-
Le routeur à rayons CE1 annonce ses routes vers le routeur à rayons PE E.
-
Le routeur E installe les routes de CE1 dans sa table VRF.
-
Après avoir vérifié sa stratégie d’exportation VRF, le routeur E ajoute la communauté cible spoke aux routes du routeur CE1 qui a passé la stratégie et les annonce au routeur PE du hub, le routeur D.
-
Le routeur D vérifie la stratégie d’importation VRF associée à l’interface ge-0/0/0.0 et place toutes les routes des routeurs spoke PE qui correspondent à la stratégie dans sa table de routage bgp.l3vpn. (Tous les itinéraires qui ne correspondent pas sont ignorés.)
-
Le routeur D vérifie sa stratégie d’importation VRF associée à l’interface ge-0/0/0.0 et installe toutes les routes correspondantes dans sa table VRF à rayons. Les routes sont installées avec la communauté cible en étoile.
-
Le routeur D annonce les routes vers le hub CE via l’interface ge-0/0/0.
-
Le routeur CE du hub annonce les routes de retour vers le routeur PE du hub D via la deuxième interface du routeur du hub, l’interface ge-0/0/1.
-
Le routeur PE du hub installe les routes apprises du routeur CE du hub dans sa table VRF du hub, qui est associée à l’interface ge-0/0/1.
-
Le routeur PE du hub vérifie la stratégie d’exportation VRF associée à l’interface ge-0/0/1.0 et annonce toutes les routes qui correspondent à tous les rayons après l’ajout de la communauté cible du hub.
La Figure 3 illustre la façon dont les routes sont distribuées entre ce routeur à rayons et le routeur CE à rayons, le routeur CE2. Le même chemin est suivi si vous émettez une traceroute commande du routeur CE1 au routeur CE2.
La dernière section de cet exemple, Configuration VPN en étoile résumée par routeur, consolide les instructions nécessaires pour configurer la fonctionnalité VPN pour chacun des routeurs de fournisseur de services illustrés à la Figure 2.
à rayons
Les sections suivantes expliquent comment configurer la fonctionnalité VPN pour une topologie en étoile sur les routeurs PE en étoile. Les routeurs CE n’ont aucune information sur le VPN, vous devez donc les configurer normalement.
- Activation d’un IGP sur les routeurs PE en étoile
- Configuration de LDP sur les routeurs PE en étoile
- Configuration d’IBGP sur les routeurs PE
- Configuration des instances de routage VPN sur les routeurs PE en étoile
- Configuration d’une stratégie VPN sur les routeurs PE
- Configuration VPN en étoile résumée par routeur
Activation d’un IGP sur les routeurs PE en étoile
Pour permettre aux routeurs PE en étoile d’échanger des informations de routage, 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 au sein de l’instance de routage (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.
Dans la distribution des routes dans une topologie en étoile, si le protocole utilisé entre les routeurs CE et PE sur le site du hub est BGP, le routeur CE du hub annonce toutes les routes reçues du routeur PE du hub et des routeurs spoke vers le routeur PE du hub et tous les routeurs spoke. Cela signifie que les routeurs PE en étoile reçoivent des routes contenant leur numéro AS. Normalement, lorsqu’une route contient ces informations, cela indique qu’une boucle de routage s’est produite et que le routeur rejette les routes. Toutefois, pour que la configuration VPN fonctionne, le routeur hub PE et les routeurs spoke doivent accepter ces routes. Pour ce faire, incluez l’option loops lors de la configuration de l’AS au niveau de la [edit routing-options] hiérarchie sur le routeur hub PE et tous les routeurs spoke. Pour cet exemple de configuration, vous spécifiez la valeur 1. Vous pouvez spécifier un nombre compris entre 0 et 10.
[edit routing-options] autonomous-system as-number loops 1;
Configuration de LDP sur les routeurs PE en étoile
Configurez LDP sur les interfaces entre les routeurs PE en étoile qui participent au VPN.
Sur le routeur PE du hub D, configurez LDP :
[edit protocols]
ldp {
interface so-1/0/0.0;
interface t3-1/1/0.0;
}
Sur le routeur Spoke PE Router E, configurez LDP :
[edit protocols]
ldp {
interface fe-0/1/2.0;
}
Sur le routeur Spoke PE Routeur F, configurer LDP :
[edit protocols]
ldp {
interface fe-1/0/0.0;
}
Configuration d’IBGP sur les routeurs PE
Sur les routeurs PE en étoile, configurez une session IBGP avec les propriétés suivantes :
-
Famille VPN : pour indiquer que la session IBGP est destinée au VPN, incluez l’instruction
family inet-vpn. -
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
neighbor. Sur le routeur central, spécifiez l’adresse IP de chaque routeur PE à rayons, et sur le routeur à rayons, spécifiez l’adresse du routeur PE du concentrateur.
Pour le routeur central, vous configurez une session IBGP avec chaque rayon, et pour chaque routeur à rayons, vous configurez une session IBGP avec le concentrateur. Il n’y a pas de sessions IBGP entre les deux routeurs spoke.
Sur le routeur central D, configurez IBGP. La première neighbor instruction configure une session IBGP sur le routeur spoke E, et la seconde configure une session sur le routeur spoke F.
[edit protocols]
bgp {
group Hub-to-Spokes {
type internal;
local-address 10.255.14.174;
family inet-vpn {
unicast;
}
neighbor 10.255.14.180;
neighbor 10.255.14.182;
}
}
Sur le routeur spoke E, configurez une session IBGP sur le routeur du hub :
[edit protocols]
bgp {
group Spoke-E-to-Hub {
type internal;
local-address 10.255.14.180;
neighbor 10.255.14.174 {
family inet-vpn {
unicast;
}
}
}
}
Sur le routeur spoke F, configurez une session IBGP sur le routeur du hub :
[edit protocols]
bgp {
group Spoke-F-to-Hub {
type internal;
local-address 10.255.14.182;
neighbor 10.255.14.174 {
family inet-vpn {
unicast;
}
}
}
}
Configuration des instances de routage VPN sur les routeurs PE en étoile
Pour que le routeur PE du hub puisse faire la distinction entre les paquets entrants et sortants des routeurs PE spoke, vous devez le configurer avec deux instances de routage :
-
Une instance de routage (dans cet exemple, ) est associée à l’interface qui transporte les paquets du routeur PE du hub vers le routeur CE du hub (dans cet exemple,
Spokes-to-Hub-CEl’interfacege-0/0/0.0). Sa table VRF contient les routes annoncées par les routeurs spoke PE et le routeur PE du hub vers le routeur CE du hub. -
La deuxième instance de routage (dans cet exemple, ) est associée à l’interface qui transporte les paquets du routeur CE du hub vers le routeur PE du hub (dans cet exemple,
Hub-CE-to-Spokesl’interfacege-0/0/1.0). Sa table VRF contient les routes annoncées entre le routeur CE du hub et les routeurs PE en étoile.
Sur chaque routeur à rayons, vous devez configurer une instance de routage.
Vous devez définir les éléments suivants dans l’instance de routage :
-
Route distinguisher, qui 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 qui font partie du VPN et qui connectent les routeurs PE à leurs routeurs CE.
-
Stratégies d’importation et d’exportation VRF. Les deux politiques d’importation doivent faire référence à une communauté. Dans le cas contraire, lorsque vous tentez de valider la configuration, celle-ci échoue. (L’exception à cette règle est si la stratégie d’importation ne contient qu’une
then rejectinstruction.) Dans la stratégie d’exportation VRF, les routeurs Spoke PE rattachent la communauté cible Spoke Target. -
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.
Pour une topologie en étoile, vous devez configurer des stratégies différentes dans chaque instance de routage sur le routeur hub CE. Pour l’instance de routage associée à l’interface qui transporte les paquets du routeur PE du hub vers le routeur CE du hub (dans cet exemple, Spokes-to-Hub-CE), la stratégie d’importation doit accepter toutes les routes reçues sur la session IBGP entre les routeurs PE en étoile, et la stratégie d’exportation doit rejeter toutes les routes reçues du routeur CE du hub. Pour l’instance de routage associée à l’interface qui transporte les paquets du routeur CE du concentrateur vers le routeur PE du concentrateur (dans cet exemple, Hub-CE-to-Spokes), la stratégie d’importation doit rejeter toutes les routes reçues des routeurs PE spoke et la stratégie d’exportation doit être exportée vers tous les routeurs spoke.
Sur le routeur hub PE D, configurez les instances de routage suivantes. Le routeur D utilise OSPF pour distribuer les routes vers et depuis le routeur CE central.
[edit]
routing-instance {
Spokes-to-Hub-CE {
instance-type vrf;
interface ge-0/0/0.0;
route-distinguisher 10.255.1.174:65535;
vrf-import spoke;
vrf-export null;
protocols {
ospf {
domain-id disable;
export redistribute-vpn;
domain-vpn-tag 0;
area 0.0.0.0 {
interface ge-0/0/0;
}
}
}
}
Hub-CE-to-Spokes {
instance-type vrf;
interface ge-0/0/1.0;
route-distinguisher 10.255.1.174:65534;
vrf-import null;
vrf-export hub;
protocols {
ospf {
export redistribute-vpn;
area 0.0.0.0 {
interface ge-0/0/1.0;
}
}
}
}
}
Sur le routeur Spoke PE Router, configurez les instances de routage suivantes. Le routeur E utilise OSPF pour distribuer les routes vers et depuis le routeur CE à rayons CE1.
[edit]
routing-instance {
Spoke-E-to-Hub {
instance-type vrf;
interface fe-0/1/0.0;
route-distinguisher 10.255.14.80:65035;
vrf-import hub;
vrf-export spoke;
protocols {
ospf {
export redistribute-vpn;
area 0.0.0.0 {
interface fe-0/1/0.0;
}
}
}
}
}
Sur le routeur Spoke PE Router, configurez les instances de routage suivantes. Le routeur F utilise OSPF pour distribuer les routes vers et depuis le routeur CE à rayons CE2.
[edit]
routing-instance {
Spoke-F-to-Hub {
instance-type vrf;
interface fe-1/0/1.0;
route-distinguisher 10.255.14.182:65135;
vrf-import hub;
vrf-export spoke;
protocols {
ospf {
export redistribute-vpn;
area 0.0.0.0 {
interface fe-1/0/1.0;
}
}
}
}
}
Configuration d’une stratégie VPN sur les routeurs PE
Vous devez configurer des stratégies d’importation et d’exportation de VPN sur chacun des routeurs PE en étoile afin qu’ils installent les routes appropriées dans les tables VRF, qu’ils utilisent pour transférer les paquets au sein de chaque VPN.
Sur les routeurs spoke, vous définissez des stratégies d’échange de routes avec le routeur central.
Sur le routeur central, vous définissez des stratégies pour accepter les routes des routeurs PE spoke et les distribuer au routeur CE central, et vice versa. Le routeur PE du hub dispose de deux tables VRF :
-
Table VRF spoke-to-hub : gère les routes reçues des routeurs spoke et annonce ces routes au routeur CE du hub. Pour cette table VRF, la stratégie d’importation doit vérifier que le nom de la cible spoke est présent et que la route a été reçue de la session IBGP entre le hub PE et les routeurs spoke PE. Cette table VRF ne doit exporter aucune route, donc sa politique d’exportation doit tout rejeter.
-
Table VRF hub-to-spoke : gère les routes reçues du routeur CE du hub et les annonce aux routeurs spoke. Pour cette table VRF, la stratégie d’exportation doit ajouter la communauté cible du hub. Cette table VRF ne doit importer aucune route, donc sa politique d’importation doit tout rejeter.
Dans la stratégie VPN, vous configurez également les communautés cibles VPN.
Sur le routeur hub PE D, configurez les stratégies suivantes pour qu’elles s’appliquent aux tables VRF :
-
spoke: accepte les routes reçues de la session IBGP entre celle-ci et les routeurs spoke PE qui contiennent la ciblespokede communauté , et rejette toutes les autres routes. -
hub: ajoute le hub cible de la communauté à toutes les routes reçues d’OSPF (c’est-à-dire de la session entre celui-ci et le routeur CE du hub). Il rejette toutes les autres routes. -
null: rejette tous les routages. -
redistribute-vpn: redistribue les routes OSPF aux voisins au sein de l’instance de routage.[edit] policy-options { policy-statement spoke { term a { from { protocol bgp; community spoke; } then accept; } term b { then reject; } } policy-statement hub { term a { from protocol ospf; then { community add hub; accept; } } term b { then reject; } } policy-statement null { then reject; } policy-statement redistribute-vpn { term a { from protocol bgp; then accept; } term b { then reject; } } community hub members target:65535:1; community spoke members target:65535:2; }
Pour appliquer les stratégies VRF sur le routeur D, incluez les vrf-export instructions et vrf-import lorsque vous configurez les instances de routage :
[edit]
routing-instance {
Spokes-to-Hub-CE {
vrf-import spoke;
vrf-export null;
}
Hub-CE-to-Spokes {
vrf-import null;
vrf-export hub;
}
}
Sur les routeurs E et F, configurez les stratégies suivantes pour qu’elles s’appliquent aux tables VRF :
-
hub: accepte les routes reçues de la session IBGP entre celle-ci et les routeurs PE du hub qui contiennent la ciblehubde communauté , et rejette toutes les autres routes. -
spoke: ajoute le spoke cible de la communauté à toutes les routes reçues d’OSPF (c’est-à-dire de la session entre celui-ci et le routeur CE du hub), rejette toutes les autres routes. -
redistribute-vpn: redistribue les routes OSPF aux voisins au sein de l’instance de routage.
Sur les routeurs E et F, configurez les stratégies d’importation et d’exportation VPN suivantes :
[edit]
policy-options {
policy-statement hub {
term a {
from {
protocol bgp;
community hub;
}
then accept;
}
term b {
then reject;
}
}
policy-statement spoke {
term a {
from protocol ospf;
then {
community add spoke;
accept;
}
}
term b {
then reject;
}
}
policy-statement redistribute-vpn {
term a {
from protocol bgp;
then accept;
}
term b {
then reject;
}
}
community hub members target:65535:1;
community spoke members target 65535:2;
}
Pour appliquer les stratégies VRF aux routeurs spoke, incluez les vrf-export instructions et vrf-import lorsque vous configurez les instances de routage :
[edit]
routing-instance {
Spoke-E-to-Hub {
vrf-import hub;
vrf-export spoke;
}
}
[edit]
routing-instance {
Spoke-F-to-Hub {
vrf-import hub;
vrf-export spoke;
}
}
Configuration VPN en étoile résumée par routeur
Routeur D (routeur Hub PE)
Instance de routage pour la distribution de routes en étoile vers Hub CE
Spokes-to-Hub-CE {
instance-type vrf;
interface fe-0/0/0.0;
route-distinguisher 10.255.1.174:65535;
vrf-import spoke;
vrf-export null;
}
Protocole de routage d’instance
protocols {
ospf {
domain-id disable;
domain-vpn-tag 0;
export redistribute-vpn;
area 0.0.0.0 {
interface ge-0/0/0.0;
}
}
}
Instance de routage pour la distribution de routes CE de concentrateur aux rayons
Hub-CE-to-Spokes {
instance-type vrf;
interface ge-0/0/1.0;
route-distinguisher 10.255.1.174:65534;
vrf-import null;
vrf-export hub;
}
Instances de routage Protocoles de routage
protocols {
ospf {
export redistribute-vpn;
area 0.0.0.0 {
interface ge-0/0/1.0;
}
}
}
Options de routage (instance principale)
routing-options {
autonomous-system 1 loops 1;
}
Protocoles (instance principale)
protocols {
}
Activer LDP
ldp {
interface so-1/0/0.0;
interface t3-1/1/0.0;
}
Configurer IBGP
bgp {
group Hub-to-Spokes {
type internal;
local-address 10.255.14.174;
family inet-vpn {
unicast;
}
neighbor 10.255.14.180;
neighbor 10.255.14.182;
}
}
Configurer la stratégie VPN
policy-options {
policy-statement spoke {
term a {
from {
protocol bgp;
community spoke;
}
then accept;
}
term b {
then reject;
}
}
policy-statement hub {
term a {
from protocol ospf;
then {
community add hub;
accept;
}
}
term b {
then reject;
}
}
policy-statement null {
then reject;
}
policy-statement redistribute-vpn {
term a {
from protocol bgp;
then accept;
}
term b {
then reject;
}
}
community hub members target:65535:1;
community spoke members target:65535:2;
}
Routeur E (routeur PE à rayons)
Instance de routage
routing-instance {
Spoke-E-to-Hub {
instance-type vrf;
interface fe-0/1/0.0;
route-distinguisher 10.255.14.80:65035;
vrf-import hub;
vrf-export spoke;
}
}
Protocole de routage d’instance
protocols {
ospf {
export redistribute-vpn;
area 0.0.0.0 {
interface fe-0/1/0.0;
}
}
}
Options de routage (instance principale)
routing-options {
autonomous-system 1 loops 1;
}
Protocoles (instance principale)
protocols {
}
Activer LDP
ldp {
interface fe-0/1/2.0;
}
Configurer IBGP
bgp {
group Spoke-E-to-Hub {
type internal;
local-address 10.255.14.180;
neighbor 10.255.14.174 {
family inet-vpn {
unicast;
}
}
}
}
Configurer la stratégie VPN
policy-options {
policy-statement hub {
term a {
from {
protocol bgp;
community hub;
}
then accept;
}
term b {
then reject;
}
}
policy-statement spoke {
term a {
from protocol ospf;
then {
community add spoke;
accept;
}
}
term b {
then reject;
}
}
policy-statement redistribute-vpn {
term a {
from protocol bgp;
then accept;
}
term b {
then reject;
}
}
community hub members target:65535:1;
community spoke members target:65535:2;
}
Routeur F (routeur Spoke PE)
Instance de routage
routing-instance {
Spoke-F-to-Hub {
instance-type vrf;
interface fe-1/0/1.0;
route-distinguisher 10.255.14.182:65135;
vrf-import hub;
vrf-export spoke;
}
}
Protocole de routage d’instance
protocols {
ospf {
export redistribute-vpn;
area 0.0.0.0 {
interface fe-1/0/1.0;
}
}
}
Options de routage (instance principale)
routing-options {
autonomous-system 1 loops 1;
}
Protocoles (instance principale)
protocols {
}
Activer LDP
ldp {
interface fe-1/0/0.0;
}
Configurer IBGP
bgp {
group Spoke-F-to-Hub {
type internal;
local-address 10.255.14.182;
neighbor 10.255.14.174 {
family inet-vpn {
unicast;
}
}
}
}
Configurer la stratégie VPN
policy-options {
policy-statement hub {
term a {
from {
protocol bgp;
community hub;
}
then accept;
}
term b {
then reject;
}
}
policy-statement spoke {
term a {
from protocol ospf;
then {
community add spoke;
accept;
}
}
term b {
then reject;
}
}
policy-statement redistribute-vpn {
term a {
from {
protocol bgp;
}
then accept;
}
term b {
then reject;
}
}
community hub members target:65535:1;
community spoke members target:65535:2;
}