VPN en hub-and-spoke
Configuration des topologies VPN en hub-and-spoke: une seule interface
Utilisez une configuration d’interface unique pour mettre en avant un routeur par défaut à partir d’un hub ou de hubs.
La Figure 1 illustre une application en hub-and-spoke VPN de couche 3, où une seule interface existe entre le centre de CE (CE1) et le PE du hub (PE1). Il s’agit là de la façon recommandée de configurer les topologies en hub-and-spoke.
Dans cette configuration, un routeur par défaut est annoncé du hub aux rayons. Si des itinéraires de CE de rayons plus spécifiques doivent être échangés entre les routeurs CE de rayons, deux interfaces sont nécessaires entre le centre de CE et le pe de hub. Voir Configuring Hub-and-Spoke VPN Topologies: Deux interfaces pour un exemple à deux interfaces.
Dans cet exemple de configuration, la distribution de route en rayons est la suivante:
Spoke CE2 fait la publicité de ses routes pour le spoke PE2.
Le spoke PE2 installe des routes depuis ce2 vers sa table de routage et de routage de VPN (VRF).
Le spoke PE2 contrôle sa politique d’exportation VRF, ajoute la communauté de cibles de routes et annonce les routes vers le hub PE1.
Le concentrateur PE1 vérifie sa stratégie d’importation VRF et installe des routes qui correspondent à la stratégie d’importation dans le tableau bgp.l3vpn.0.
Le hub PE1 installe des routes depuis la table bgp.l3vpn.0 dans la table VRF du hub.
Le hub PE1 annonce les routes entre la table VRF du hub et le hub CE1.
Dans cet exemple de configuration, la distribution par défaut du routeur est la suivante:
Le hub CE1 annonce un routeur par défaut vers le hub PE1.
Le hub PE1 installe le routeur par défaut dans la table VRF du hub.
Le hub PE1 contrôle sa politique d’exportation VRF, ajoute la communauté de cibles de route et annonce la route par défaut à rayons PE2 et PE3.
Les rayons PE2 et PE3 vérifient leur stratégie d’importation VRF et installent le routeur par défaut dans le tableau bgp.l3vpn.0.
Spoke PE2 et PE3 installent les routes de la table bgp.l3vpn.0 dans leurs tables VRF en rayons.
Les rayons PE2 et PE3 annoncent le routeur par défaut de la table VRF en rayons CE2 et CE3.
Les sections suivantes décrivent comment configurer une topologie en hub-and-spoke avec une interface basée sur la topologie illustrée dans la figure 1:
- Configuration du hub CE1
- Configuration du hub PE1
- Configuration du routeur P
- Configuration du spoke PE2
- Configuration du spoke PE3
- Configuration de spoke CE2
- Configuration du spoke CE3
- Activation des fonctionnalités de sortie sur le routeur PE de hub
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 du spoke PE2
Configurez le spoke 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 du spoke PE3
Configurez le spoke 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 spoke 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 du spoke CE3
Configurez le spoke 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 trafic est transmis de la manière suivante entre les spokes CE2 et CE1:
Spoke CE2 fait avancer le trafic à l’aide de la route par défaut tirée du spoke PE2 à 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.0Spoke PE2 effectue une recherche de route dans la table VRF de rayons et route le trafic vers le hub PE2 (via le routeur P — PE2 pushe deux labels) à l’aide de la route par défaut acquise 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 fait une recherche de route dans la table mpls.0 pour le label
100336VPN.100336 *[VPN/170] 01:37:03 > to 10.49.4.2 via t3-0/0/0.0, PopLe hub PE1 fait sortir le trafic de l’interface
t3-0/0/0.0vers le hub CE1.
Dans cet exemple de configuration, le trafic est transmis de la manière suivante entre les hubs CE1 et CE2:
Le ce1 de plate-forme fait passer le trafic vers le hub PE1 à l’aide de la route 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.0Le hub PE1 fait une recherche de route dans la table VRF du hub et route le trafic vers le spoke PE2 (via le routeur P — PE1 pousse deux labels).
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 fait une recherche de route dans la table mpls.0 pour le label
100352VPN.100352 *[VPN/170] 02:31:39 > to 10.49.3.2 via t1-0/1/2.0, PopSpoke PE2 fait sortir le trafic de l’interface
t1-0/1/2.0en spoke CE2.
Dans cet exemple de configuration, le trafic est transmis de la manière suivante entre les rayons CE2 et CE3:
Spoke CE2 fait avancer le trafic à l’aide de la route par défaut tirée du spoke PE2 à 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.0Spoke PE2 fait une recherche de route dans la table VRF de rayons et route le trafic vers le concentrateur PE1 (via le routeur P — PE2 pushe deux labels) à l’aide de la route par défaut acquise 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 fait une recherche de route dans la table mpls.0 pour le label
100336VPN.100336 *[VPN/170] 01:37:03 > to 10.49.4.2 via t3-0/0/0.0, PopLe hub PE1 fait sortir le trafic de l’interface
t3-0/0/0.0vers le hub CE1.Le ce1 de hub fait passer le trafic vers le hub PE1 à l’aide du routeur 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.0Le hub PE1 fait une recherche de route dans la table VRF du hub et route le trafic vers le trafic SPOKE PE3 (via le routeur P — PE1 pousse deux labels).
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 fait 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, PopSpoke PE3 fait sortir le trafic de l’interface
t3-0/0/0.0en spoke CE3.
Si vous avez besoin de fonctionnalités de sortie sur le pe de hub nécessitant une recherche de forwarding IP sur la table de routage VRF du hub, consultez l’activation des fonctionnalités de sortie sur le routeur Hub PE.
Activation des fonctionnalités de sortie sur le routeur PE de hub
Cet exemple est fourni en conjonction avec Configuring Hub-and-Spoke VPN Topologies: Une interface. Cet exemple s’appuie également sur la topologie illustrée sur la Figure 1.
Si des fonctionnalités de sortie sont requises sur le pe de hub nécessitant une recherche de forwarding IP sur la table de routage VRF du hub, la configuration détaillée dans Configuring Hub-and-Spoke VPN Topologies: Une interface ne fonctionne pas. L’application de l’énoncé sur l’instance de routage du hub force le trafic provenant d’un PE distant à être transmis au PE du hub et contraint l’attaquant à effectuer une recherche vrf-table-label IP. Étant donné que des routes en rayons spécifiques se trouve dans la table VRF du hub, le trafic est transmis à un PE de rayons sans passer par CE.
Le concentrateur PE (Hub PE) annonce le routeur par défaut suivant, à l’aide du label 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 transmis via le label VPN 1028. Le tableau mpls.0 indique qu’une recherche IP est requise dans le hub.inet.0 de la table:
1028 *[VPN/0] 00:00:27
to table hub.inet.0, Pop
Toutefois, le hub VRF table Hub.inet.0 contient des routes en rayons 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)
C’est pour cette raison que le trafic est directement transmis aux PES en rayons sans passer par le concentrateur CE. 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 est utilisée au niveau hiérarchique, aucun groupe de tables de routage ou stratégies d’exportation no-vrf-advertise [edit routing-instances hub] VRF n’est nécessaire. Cet énoncé configure le pe hub pour ne pas promouvoir les routes VPN à partir no-vrf-advertise de l’instance de routage hub principale. Ces routes sont alors annoncées depuis l’instance de routage hub_downstream secondaire. Consultez Junos OS bibliothèque de protocoles de routage pour plus d’informations sur cet no-vrf-advertise énoncé.
L’énoncé au niveau de la hiérarchie identifie les routes exportées depuis l’instance de hub vers l’instance en aval du hub en regard des cibles de routage définies pour chaque instance de auto-export [edit routing-instances hub-downstream routing-options] routage. Consultez Junos OS bibliothèque de protocoles de routage pour plus d’informations sur l’utilisation de l’énoncé. auto-export Voir Configuring Overlapping VPNs Using Automatic Route Export pour plus d’exemples de stratégie d’exportation.
Grâce à cette configuration sur le pe de hub, le trafic CE de spoke-to-spoke passe par le CE de hub et permet d’activer des fonctionnalités de sortie (telles que le filtrage) sur le PE de hub.
Dans cet exemple de configuration, le trafic est transmis de la manière suivante entre les rayons CE2 et CE3:
Spoke CE2 fait avancer le trafic à l’aide de la route par défaut tirée du spoke PE2 à 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.0Spoke PE2 fait une recherche de route dans la table VRF de rayons et route le trafic vers le concentrateur PE1 (via le routeur P — PE2 pushe deux labels) à l’aide de la route par défaut acquise 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 fait une recherche de route dans la table mpls.0 pour le label
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, PopLe label VPN
1029est annoncé parce que:vrf-table-labelL’instruction est appliquée au niveau hiérarchique dans la configuration[edit routing-instances hub_downsteam]PE1 du hub.L’instruction est appliquée au niveau hiérarchique, pour demander au routeur de promouvoir le
no-vrf-advertise[edit routing-instances hub]routeur de la table secondaire.
Les recherches IP sont donc effectuées dans la table hub_downstream.inet.0 et non dans la table hub.inet.0.
Émettre la commande sur le pe de hub à
show route advertising-protocolun spoke PE pour vérifier la publicité d’étiquettes1029VPN: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:101Le hub PE1 effectue une recherche IP dans le tableau et route l’interface de sortie du trafic vers le
hub_downstream.inet.0t3-0/0/0.0centre 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 tableau principal du routage indique que cette route a été exportée du tableau vers ce
hub.inet.0hub.inet.0tableau hub_downstream.inet.0 à la suite de l’instruction au niveau de la hiérarchie et de l’instruction au niveau hiérarchique dans la configuration PE1 deno-vrf-advertise[edit routing-instances hub]auto-export[edit routing-instances hub-downstream routing-options]hub.Le ce1 de hub fait revenir le trafic vers le hub PE1 à l’aide du routeur 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.0Le hub PE1 effectue une recherche de route dans la table VRF du hub et route le trafic vers le pe3 à rayons (via le routeur P — PE1 pousse deux labels).
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, PopSpoke PE3 fait sortir le trafic de l’interface
t3-0/0/0.0en spoke CE3.
Configuration des topologies VPN en hub-and-spoke: deux interfaces
Utilisez une configuration à deux interfaces pour propager les routes du spoke à la rayons.
L’exemple de cette section configure une topologie en hub-and-spoke avec deux interfaces utilisant les composants suivants (voir Figure 2):
Un routeur PE de hub (routeur D).
Un routeur CE connecté au routeur PE de hub. Pour que cette topologie VPN en hub-and-spoke fonctionne correctement, deux interfaces doivent connecter le routeur PE de hub au routeur CE de hub; chaque interface doit avoir sa propre table VRF sur le routeur PE:
La première interface (ici interface ge-0/0/0.0) est utilisée pour annoncer les routes en rayons vers le routeur de CE hub. La table VRF associée à cette interface contient les routes annoncées par les routeurs PE de rayons vers le routeur de CE hub.
La deuxième interface (ici interface ge-0/0/1.0) est utilisée pour recevoir les annonces de route provenant des CE de hub à destination des routeurs en hub-and-spoke. La table VRF associée à cette interface contient les routes annoncées par le routeur CE routeur aux routeurs PE hub-spoke. Dans cet exemple, deux interfaces physiques distinctes sont utilisées. La configuration de deux interfaces logiques distinctes partageant la même interface physique entre le routeur PE de hub et le routeur de centre de données peut CE également fonctionner.
Deux routeurs PE en rayons (routeur E et Routeur F).
Deux routeurs CE (CE1 et CE2), un connecté à chaque routeur PE de rayons.
LDP comme protocole de signalisation.
Dans cette configuration, la distribution de route à CE routeur CE1 se produit comme suit:
Le routeur de rayons CE1 annonce ses routes pour le routeur PE spoke E.
Le routeur E installe les routes du CE1 dans sa table VRF.
Après vérification de sa stratégie d’exportation VRF, le routeur E ajoute la communauté cible de rayons aux routes du routeur CE1 qui a adopté la stratégie et les annonce au routeur PE de hub, 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 à partir de routeurs PE de rayons qui correspondent à la stratégie dans sa table de routage bgp.l3vpn. (Toutes les routes qui ne correspondent pas sont éliminées.)
Le routeur D contrôle sa stratégie d’importation VRF associée à l’interface ge-0/0/0.0 et installe tous les routes qui correspondent à sa table VRF de rayons. Les routes sont installées avec la communauté cible de rayons.
Le routeur D annonce les routes vers le concentrateur CE’interface ge-0/0/0.
Le routeur de CE hub annonce les routes vers le routeur PE de hub sur la deuxième interface vers le routeur de hub, interface ge-0/0/1.
Le routeur PE de hub installe les routes apprises depuis le routeur CE de hub dans sa table VRF de hub, associée à l’interface ge-0/0/1.
Le routeur PE de hub vérifie la stratégie d’exportation VRF associée à l’interface ge-0/0/1.0 et annonce tous les routes qui correspondent à tous les rayons après avoir ajouté la communauté cible du hub.
La Figure 3 illustre la manière dont les routes sont distribuées entre ce routeur de rayons et l’autre routeur CE-rayons, le routeur CE2. Le même chemin est suivi si vous émettre une commande traceroute du routeur CE1 au routeur CE2.
La dernière section de cet exemple, « Configuration des VPN en hub-and-spoke» résumée par routeur , consolide les instructions requises pour configurer les fonctionnalités VPN pour chacun des routeurs des fournisseurs de services illustrés dans la figure 2.
Les sections suivantes expliquent comment configurer la fonctionnalité VPN pour une topologie en hub-and-spoke sur les routeurs PE en hub-and-spoke. Les routeurs CE n’ont aucune information sur le VPN et vous les configurez normalement.
- Activation d’IGP sur les routeurs PE en hub-and-spoke
- Configuration de LDP sur les routeurs PE en hub-and-spoke
- Configuration d’IBGP sur les routeurs PE
- Configuration des instances de routage VPN sur les routeurs PE en hub-and-spoke
- Configuration des stratégies VPN sur les routeurs PE
- Configuration vpn en hub-and-spoke résumée par le routeur
Activation d’IGP sur les routeurs PE en hub-and-spoke
Pour permettre aux routeurs PE en hub-and-spoke d’échanger des informations de routage, vous devez configurer une IGP sur tous ces routeurs ou vous devez configurer des routes statiques. Vous configurez la IGP sur l’instance principale du processus de protocole de routage (rpd) (c’est-à-dire au niveau de la hiérarchie), et non dans l’instance de routage (c’est-à-dire pas au niveau [edit protocols] [edit routing-instances] hiérarchique).
Vous configurez les IGP de manière standard. Cet exemple de configuration n’inclut pas cette partie de la configuration.
Dans une topologie en hub-and-spoke, si le protocole utilisé entre les routeurs CE et PE du site du hub est BGP, le routeur CE de hub annonce toutes les routes reçues depuis le routeur PE de hub et les routeurs spoke vers le routeur PE de hub et tous les routeurs spoke. Cela signifie que les routeurs PE en hub-and-spoke reçoivent des routes contenant AS nombre de routes. Normalement, lorsqu’un route contient ces informations, elle 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 PE de hub et les routeurs de rayons doivent accepter ces routes. Pour cela, inclure l’option lors de la configuration du AS au niveau de la hiérarchie sur le routeur PE de hub et tous les loops [edit routing-options] routeurs spoke. Pour cette configuration d’exemple, spécifiez une valeur de 1. Vous pouvez spécifier un numéro de 0 à 10.
[edit routing-options] autonomous-system as-number loops 1;
Configuration de LDP sur les routeurs PE en hub-and-spoke
Configurez le LDP sur les interfaces entre les routeurs PE en hub-and-spoke qui participent au VPN.
Sur le routeur PE de hub D, configurer LDP:
[edit protocols]
ldp {
interface so-1/0/0.0;
interface t3-1/1/0.0;
}
Sur le routeur PE en rayons E, configurer LDP:
[edit protocols]
ldp {
interface fe-0/1/2.0;
}
Sur le routeur PE en rayons 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 hub-and-spoke, configurez une session IBGP avec les propriétés suivantes:
Famille VPN: pour indiquer que la session IBGP est pour le VPN, inclure
family inet-vpnl’instruction.Adresse de bouclure:
local-addressindiquez l’instruction, spécifiant l’adresse de bouclure du routeur PE local. La session IBGP pour VPN s’exécute via l’adresse loopback. Vous devez également configurerlo0l’interface au niveau de la[edit interfaces]hiérarchie. L’exemple n’inclut pas cette partie de la configuration du routeur.Adresse du voisin: inclure
neighborl’instruction. Sur le routeur de hub, spécifiez l’adresse IP de chaque routeur PE de rayons, et sur le routeur de rayons, précisez l’adresse du routeur PE de hub.
Pour le routeur de hub, vous configurez une session IBGP avec chaque spoke, et pour chaque routeur de rayons, vous configurez une session IBGP avec le hub. Il n’y a aucune session IBGP entre les deux routeurs en rayons.
Sur le routeur de hub D, configurez IBGP. La première instruction configure une session IBGP pour mettre en spoke le routeur E, et la seconde configure une session pour le neighbor routeur de rayons 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 en rayons E, configurez une session IBGP vers le routeur de 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 en rayons F, configurez une session IBGP sur le routeur de 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 hub-and-spoke
Pour que le routeur PE de hub soit capable de distinguer les paquets aller/venir des routeurs SPOKE PE, vous devez le configurer avec deux instances de routage:
Une seule instance de routage (dans cet exemple, ) est associée à l’interface qui transporte des paquets entre le routeur PE du hub et le routeur CE hub (dans cet
Spokes-to-Hub-CEexemple, l’interface).ge-0/0/0.0Sa table VRF contient les routes annoncées par les routeurs PE de rayons et le routeur PE de hub vers le routeur de CE hub.La deuxième instance de routage (dans cet exemple, ) est associée à l’interface qui transporte des paquets depuis le routeur CE de hub vers le routeur PE de hub (dans cet
Hub-CE-to-Spokesexemple, l’interface).ge-0/0/1.0Son tableau VRF contient les routes annoncées entre le routeur CE et les routeurs PE en hub-and-spoke.
Sur chaque routeur en rayons, vous devez configurer une instance de routage.
Vous devez définir les définitions suivantes dans l’instance de routage:
L’distinguisher de route est utilisé pour distinguer les adresses d’un VPN de celles d’un autre VPN.
Type
vrfd’instance , qui crée la table VRF du routeur PE.Des interfaces qui font partie du VPN et qui connectent les routeurs PE à CE routeurs virtuels.
Stratégies d’importation et d’exportation VRF. Les deux stratégies d’importation doivent inclure une référence à une communauté. Sinon, lorsque vous tentez de valider la configuration, la validation échoue. (L’exception à cette exception concerne la politique d’importation ne contient qu’un
then rejecténoncé.) Dans la politique d’exportation de la VRF, les routeurs PE en spokes fixent la communauté cible en rayons.Routage entre les routeurs PE et CE, qui est requis pour que le routeur PE distribue des routes vpn vers et en provenance des routeurs d’CE connectés. Vous pouvez configurer un protocole de routage (BGP, OSPF ou RIP) ou configurer le routage statique.
Pour une topologie en hub-and-spoke, vous devez configurer différentes stratégies dans chaque instance de routage sur le routeur de CE hub. Pour l’instance de routage associée à l’interface qui transporte des paquets entre le routeur PE de hub et le routeur CE de hub (dans cet exemple), la stratégie d’importation doit accepter toutes les routes reçues lors de la session IBGP entre les routeurs PE en hub-and-spoke, et la politique d’exportation doit refuser toutes les routes reçues depuis le routeur CE de Spokes-to-Hub-CE hub. Pour l’instance de routage associée à l’interface qui transporte des paquets entre le routeur CE de hub et le routeur PE de hub (dans cet exemple), la stratégie d’importation doit refuser toutes les routes reçues à partir des routeurs PE hub-and-spoke, et la stratégie d’exportation doit exporter vers tous les Hub-CE-to-Spokes routeurs hub-and-spoke.
Sur le routeur PE de hub D, configurez les instances de routage suivantes. Le routeur D utilise OSPF pour distribuer les routes vers et en provenance du routeur de CE hub.
[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 PE en rayons E, configurez les instances de routage suivantes. Le routeur E utilise des OSPF pour distribuer les routes vers et en provenance du routeur CE 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 PE en rayons F, configurez les instances de routage suivantes. Le routeur F utilise des OSPF pour distribuer les routes vers et en provenance du routeur CE 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 des stratégies VPN sur les routeurs PE
Vous devez configurer les stratégies d’importation et d’exportation de VPN sur chacun des routeurs PE en hub-and-spoke de manière à ce qu’ils installent les routes appropriées dans les tables VRF, qu’ils utilisent pour faire avancer les paquets dans chaque VPN.
Sur les routeurs en rayons, vous définissez des stratégies pour l’échange de routes avec le routeur de hub.
Sur le routeur de hub, vous définissez des stratégies pour accepter les routes à partir des routeurs SPOKE PE et les distribuer vers le routeur de centre de CE, et vice versa. Le routeur PE de hub dispose de deux tables VRF:
Table VRF de hub-to-hub: gère les routes reçues à partir de routeurs en rayons et annonce ces routes vers le routeur de CE hub. Pour ce tableau VRF, la politique d’importation doit vérifier que le nom de la cible en rayons est bien présent et que le routeur a bien été reçu lors de la session IBGP entre le PE de hub et les routeurs PE spoke. Ce tableau VRF ne doit pas exporter de routes; sa politique d’exportation doit donc tout refuser.
Table VRF en hub-to-spoke: gère les routes reçues depuis le routeur de centre de CE et les annonce sur les routeurs en rayons. Dans ce tableau de la réalité virtuelle, la stratégie d’exportation doit ajouter la communauté cible du hub. Ce tableau VRF ne doit pas importer de routes; sa politique d’importation doit donc tout refuser.
Dans la stratégie VPN, vous configurez également les communautés cibles VPN.
Sur le routeur PE de hub D, configurez les stratégies suivantes pour les appliquer aux tables VRF:
spoke— Accepte les routes reçues à partir de la session IBGP entre celle-ci et les routeurs PE de rayons qui contiennent la cible de la communauté et rejettespoketoutes les autres routes.hub— Ajoute le hub cible de la communauté à toutes les routes reçues de OSPF (c’est-à-dire de la session qui l’CE le routeur). Elle rejette toutes les autres routes.null— Rejette toutes les routes.redistribute-vpn— Redistribue les OSPF aux voisins 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, inclure les instructions et les instructions lors de la configuration des vrf-export vrf-import 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 le routeur PE en rayons E et Routeur F, configurez les stratégies suivantes pour les appliquer aux tables VRF:
hub— Accepte les routes reçues depuis la session IBGP entre celle-ci et les routeurs PE de hub qui contiennent la cible de la communauté et rejettehubtoutes les autres routes.spoke— L’objectif de la communauté s’explique par le fait que toutes les routes reçues de OSPF (c’est-à-dire de la session qui l’assure et du routeur CE hub) rejettent toutes les autres routes.redistribute-vpn— Redistribue les OSPF aux voisins de l’instance de routage.
Sur le routeur PE en rayons E et routeur 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 sur les routeurs en rayons, inclure les instructions et les instructions lors de la configuration des vrf-export vrf-import 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 hub-and-spoke résumée par le routeur
Routeur D (routeur PE de hub)
Instance de routage pour la distribution des routes en rayons vers les centres 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’instances
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 des CE routages vers les 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;
}
Protocoles de routage pour les instances 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 en spoke)
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’instances
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 PE en spoke)
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’instances
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;
}