MP BGP

4.
4 – Multiprotocol BGP (MP-BGP)

Le protocole MP-BGP est une extension du protocole BGP 4, et permettant d’échanger des routes
Multicast et des routes VPNv4. MP-BGP adopte une terminologie similaire à BGP concernant le
peering :
 MP- BGP : peering entre routeurs d’un même AS ;

 MP-eBGP : peering entre routeurs situés dans 2 AS différents.
4.4.1 – Notion de RD (Route Distinguisher)
Des sites appartenant à des VPN isolés ayant la possibilité d’utiliser des plans d’adressage
recouvrants, les routes échangées entre PE doivent être rendues uniques au niveau des updates
BGP. Pour cela, un identifiant appelé RD (Route Distinguisher), codé sur 64 bits, est accolé à
chaque subnet IPv4 d’une VRF donnée. Le RD s’écrit sous la forme « ASN:nn » ou « IP-Address:nn
». Dans les exemples de configuration fournis avec ce document, le paramètre ASN a été fixé
arbitrairement à 100, et « nn » choisi en fonction de la VRF, quel que soit le routeur. Il est
toutefois conseillé de choisir un RD unique par routeur et par VRF. Une route VPNv4, formé d’un RD
et d’un préfixe IPv4, s’écrit ainsi sous la forme RD:Subnet/Masque. Exemple :
100:1:100.10.5.5/32. Lors de la création d’une VRF sur un PE, un RD doit être configuré. Les
routes apprises soit localement (routes statiques, Loopback sur le PE), soit par les CE rattachés au
PE seront ainsi exportées dans les updates MP-BGP avec ce RD. Les RD affectés aux différentes
VRF existantes sur un PE peuvent être consultés au moyen de la commande Cisco « show ip vrf » :
L10-R4# sh ip vrf
Name Default RD Interfaces
BLUE 100:1 Loopback1
GREEN 100:3 Serial0/0
Loopback3
RED 100:2 Loopback2
On constate que les interfaces connectées aux VRF sont également listées par cette commande.
4.4.2 – Notion de RT (Route Target)
Le RD permet de garantir l’unicité des routes VPNv4 échangées entre PE, mais ne définit pas la
manière dont les routes vont être insérées dans les VRF des routeurs Cisco PE. L’import et l’export
de routes sont gérés grâce à une communauté étendue BGP (extended community) appelée RT
(Route Target). Les RT ne sont rien de plus que des sortes de filtres appliqués sur les routes
VPNv4. Chaque VRF définie sur un PE est configurée pour exporter ses routes suivant un certain
nombre de RT. Une route VPN exportée avec un RT donné sera ajoutée dans les VRF des autres PE
important ce RT. Par exemple, si la route VPN 2000:1:192.168.1.0/24 est exportée par un routeur
PE avec comme liste de RT 2000:500 et 2000:501, tous les autres routeurs PE ayant une ou
plusieurs VRF important au minimum un de ces deux RT ajouteront cette route dans leurs VRF
concernées.
La configuration simple pour un VPN consiste à appliquer la règle :
 RT_import = RT_export = RT_VPN

(Avec RT_VPN choisi comme identifiant spécifique au VPN).
Sur la figure ci-dessus, les 3 sites rouges appartiennent au même VPN. Pour échanger les routes
entre tous les sites, chaque PE importe et exporte le RT 500:1000.
Le schéma suivant indique la marche à suivre pour créer une topologie de type « hub and spoke »
:
Dans ce exemple, le site vert est un site central (par ex. pour l’administration des différents VPN).
Chacun des 3 sites, appartenant à un VPN différent (Rouge, Violet et Bleu) importe les routes du
site central (RT 500:1001). Réciproquement, le site central importe les routes de tous les sites
clients (RT 500:1000). Bien que le site central ait accès à tous les sites clients, ceux-ci ne peuvent
se voir entre eux. En effet, aucune relation de RT n’est définie entre les sites clients (aucun site
n’importe ou n’exporte de route vers un autre).
Naturellement, comme le site vert « voit » les 3 sites clients, le plan d’adressage de ces sites doit
être compatible (c’est-à-dire non recouvrant) au niveau des routes échangées pour garantir
l’unicité des routes vis-à-vis du site central.
4.4.3 – Configuration d’une VRF
Les VRF sont configurées sur les routeurs Cisco PE avec les paramètres suivants :
 Nom de VRF (case-sensitive) ;

 RD (Route Distinguisher) ;
 RT exportés ;
 RT importés ;
 Filtres sur l’import et l’export des routes (optionnel).
Le paramétrage d’une VRF « TEST » (avec un RD de 500:1000), exportant ses routes avec les RT
500:1 et 500:2 et important les routes avec les RT 500:1 et 500:3, serait le suivant :
ip vrf TEST
rd 500:1000
route-target export 500:1
route-target export 500:2
route-target import 500:1
route-target import 500:3
4.4.4 – Updates MP-BGP
En plus du RD et des RT, les updates MP-BGP contiennent d’autres informations, telles que le Site
d’Origine (SOO), l’adresse IP du PE annonçant la route (PE nexthop) et le label VPN affecté par ce
PE.
4.4.5 – Configuration MP-BGP d’un PE
La configuration d’un routeur Cisco PE pour échanger des routes VPNv4 se présente sous la forme
suivante :
router bgp 10
no synchronization
bgp log-neighbor-changes
neighbor 10.10.1.1 remote-as 10
neighbor 10.10.1.1 update-source Loopback0
no neighbor 10.10.1.1 activate
no auto-summary
address-family vpnv4
neighbor 10.10.1.1 activate
neighbor 10.10.1.1 send-community extended
no auto-summary
exit-address-family
On remarque la présence d’une section supplémentaire par rapport à une configuration BGP
traditionnelle, introduite par la commande Cisco « address-family vpnv4 ». Cette partie de la
configuration BGP contient tous les voisins tournant MP-BGP. Pour pouvoir ajouter un voisin dans la
configuration VPNv4, ce voisin doit être préalablement déclaré dans la configuration globale de BGP
(commande Cisco « remote- s » et autres). Pour éviter qu’un voisin ne soit actif à la fois pour BGP
et MP-BGP, la ligne « no neighbor <neighbor> activate » doit être insérée globalement.
Naturellement, il est tout à fait possible pour un routeur d’être actif pour BGP et MP-BGP
simultanément. Par exemple, le BGP traditionnel servira à propager les routes Internet aux
routeurs PE, tandis que MP-BGP servira à la propagation des routes VPN.
Pour propager les Route-Target (RT), qui définissent l’appartenance aux VPN et qui sont des
communautés étendues BGP, la ligne « neighbor <neighbor> sendcommunity extended » doit être
utilisée.
Dans le réseau de démonstration MPLS/VPN, le routeur Cisco L10-R1 fait office de Route Reflector
BGP. Sa configuration Cisco est la suivante :
router bgp 10
no synchronization
no bgp default route-target filter
bgp cluster-id 10
neighbor iBGP peer-group
no neighbor iBGP activate
neighbor iBGP remote-as 10
neighbor iBGP update-source Loopback0
neighbor iBGP soft-reconfiguration inbound

no auto-summary
address-family vpnv4
neighbor iBGP activate
neighbor iBGP route-reflector-client
neighbor iBGP send-community extended
neighbor 10.10.2.2 peer-group iBGP
no auto-summary
exit-address-family
Afin de faciliter l’ajout de nouveaux voisins, la notion de « peer-group » a été utilisée. Un peer
group est défini par un nom, et il est possible de fixer certaines propriétés pour ce groupe : AS
distant (remote-as), interface source pour les updates (update-source), etc. Chaque voisin est
ensuite ajouté dans ce groupe avec un commande Cisco du type: « neighbor 10.10.5.5 peer-group
iBGP ». Dans cet exemple, toutes les commandes appliquées au groupe « iBGP » le seront pour le
voisin 10.10.5.5.
4.4.6 – Vérification du fonctionnement de MP-BGP
Plusieurs commandes existent pour s’assurer du bon fonctionnement de BGP sur les routeurs. Par
exemple, pour connaître toutes les routes apprises par MP-BGP sur un routeur Cisco donné, la
commande Cisco « show ip bgp vpnv4 all » peut être utilisée :
L10-R4# sh ip bgp vpnv4 all
BGP table version is 129, local router ID is 10.10.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:1 (default for vrf BLUE)
*> 100.10.4.4/32 0.0.0.0 0 32768 ?
*>i100.10.5.5/32 10.10.5.5 0 100 0 ?
Route Distinguisher: 100:2 (default for vrf RED)
*> 100.10.4.4/32 0.0.0.0 0 32768 ?
*>i100.10.5.5/32 10.10.5.5 0 100 0 ?
*>i100.10.7.7/32 10.10.5.5 0 100 0 102 i
*>i100.10.57.0/24 10.10.5.5 0 100 0 ?

*>i100.10.171.0/24 10.10.5.5 0 100 0 102 i
*>i100.10.172.0/24 10.10.5.5 0 100 0 102 i
Route Distinguisher: 100:3 (default for vrf GREEN)
*>i100.10.3.3/32 10.10.3.3 0 100 0 ?
*> 100.10.4.4/32 0.0.0.0 0 32768 ?
*>i100.10.5.5/32 10.10.5.5 0 100 0 ?
*> 100.10.6.6/32 100.10.46.6 1 32768 ?
*> 100.10.46.0/24 0.0.0.0 0 32768 ?
*> 100.10.46.6/32 0.0.0.0 0 32768 ?
*> 100.10.161.0/24 100.10.46.6 1 32768 ?
*> 100.10.162.0/24 100.10.46.6 1 32768 ?
Route Distinguisher: 100:2000
*>i100.10.3.3/32 10.10.3.3 0 100 0 ?
Si l’on souhaite se restreindre à une VRF donnée, la commande Cisco « show ip bgp vpnv4 vrf
<vrf> » peut être employée :
L10-R4# sh ip bgp vpnv4 vrf RED
BGP table version is 129, local router ID is 10.10.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:2 (default for vrf RED)
*> 100.10.4.4/32 0.0.0.0 0 32768 ?
*>i100.10.5.5/32 10.10.5.5 0 100 0 ?
*>i100.10.7.7/32 10.10.5.5 0 100 0 102 i
*>i100.10.57.0/24 10.10.5.5 0 100 0 ?
*>i100.10.171.0/24 10.10.5.5 0 100 0 102 i
*>i100.10.172.0/24 10.10.5.5 0 100 0 102 i
Les labels fournis dans les updates MP-BGP peuvent être affichés au moyen de la commande Cisco
« sh ip bgp vpnv4 [vrf <vrf> | all] tags » :
L10-R4# sh ip bgp vpnv4 vrf RED tags
Network Next Hop In tag/Out tag
Route Distinguisher: 100:2 (RED)
100.10.4.4/32 0.0.0.0 28/aggregate(RED)
100.10.5.5/32 10.10.5.5 notag/26

100.10.7.7/32 10.10.5.5 notag/29
100.10.57.0/24 10.10.5.5 notag/28
100.10.171.0/24 10.10.5.5 notag/33
100.10.172.0/24 10.10.5.5 notag/34
4.5 – Echange des routes avec les CE

Les CE sont des routeurs Cisco clients traditionnels, n’ayant aucune connaissance de MPLS ou des
VRF. Les CE doivent donc échanger leurs routes IP avec leur PE au moyen de protocoles de
routages classiques. Les protocoles supportés par IOS sont eBGP (external BGP), RIPv2 et OSPF.
Les deux paragraphes suivants donnent des exemples de configuration avec eBGP et RIPv2. Dans
le réseau de démonstration, eBGP est utilisé entre L10-R5 et L10-R7, tandis que RIPv2 est utilisé
entre L10-R4 et L10-R6. Le routeur Cisco L10-R7 a été placé dans le VPN « RED », et le routeur
Cisco L10-R6 dans le VPN « GREEN ».
4.5.1 – Configuration eBGP

La configuration BGP de L10-R5 (routeur PE) pour la VRF « RED » est listée ci-dessous :
router bgp 10
[...]
address-family ipv4 vrf RED
redistribute connected
neighbor 100.10.57.7 activate
no auto-summary
no synchronization
exit-address-family
[...]
L’interface reliant L10-R5 et L10-R7 étant paramétrée comme suit (sur L10-R5) :
interface Serial0/0.1 point-to-point
description Vers L10-R7
bandwidth 125
ip vrf forwarding RED
ip address 100.10.57.5 255.255.255.0
frame-relay interface-dlci 100
Chaque voisin devant être actif en eBGP dans une VRF donné doit donc être configuré dans la
section « address-family ipv4 vrf <vrf> » correspondante. A titre indicatif, la configuration BGP de
L10-R7 est fournie ci-dessous :
router bgp 102
network 100.10.7.7 mask 255.255.255.255
network 100.10.171.0 mask 255.255.255.0
network 100.10.172.0 mask 255.255.255.0
On constate donc que la configuration du routeur CE est tout à fait classique, sans présence de VRF
ou de toute autre notion de VPN.
4.5.2 – Configuration RIPv2
La configuration Cisco RIPv2 avec un routeur CE suit le même principe qu’une configuration eBGP,
mais les routes apprises par RIP doivent être réinjectées dans MP-BGP et réciproquement :
router rip
version 2
address-family ipv4 vrf GREEN
version 2
redistribute bgp 10 metric 1
network 100.0.0.0
no auto-summary
exit-address-family
[...]
router bgp 10
[...]
address-family ipv4 vrf GREEN
redistribute connected
redistribute rip
no auto-summary
no synchronization
exit-address-family
[...]
L’interface reliant L10-R4 et L10-R6 est paramétrée de la manière suivante (sur L10-R4) :
interface Serial0/0
description Vers L10-R6
bandwidth 125
ip vrf forwarding GREEN
ip address 100.10.46.4 255.255.255.0
encapsulation ppp
no fair-queue
clockrate 125000
end
4.6 – Transmission des paquets IP

La transmission des paquets IP provenant des CE sur le backbone MPLS emploie la notion de label
stacking. Pour atteindre un site donné, le PE source encapsule deux labels : le premier sert à
atteindre le PE de destination, tandis que le second détermine l’interface de sortie sur le PE, à
laquelle est reliée le CE. Le second label est appris grâce aux updates MP-BGP. Les tables CEF des
routeurs peuvent être consultées pour déterminer les labels utilisées. Par exemple, supposons que
l’on souhaite connaître les tags employés pour atteindre l’adresse de Loopback 100.10.5.5
configurée sur le routeur Cisco L10-R5, et placée dans la VRF « RED ». La consultation de la table
de routage de la VRF « RED » sur L10-R4 montre que le next-hop est bien L10-R5 (10.10.5.5) :
L10-R4# sh ip route vrf RED
Gateway of last resort is not set
100.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
B 100.10.57.0/24 [200/0] via 10.10.5.5, 00:01:45
B 100.10.7.7/32 [200/0] via 10.10.5.5, 00:01:46
B 100.10.5.5/32 [200/0] via 10.10.5.5, 00:01:46
C 100.10.4.4/32 is directly connected, Loopback2
B 100.10.172.0/24 [200/0] via 10.10.5.5, 00:01:46
B 100.10.171.0/24 [200/0] via 10.10.5.5, 00:01:46
Le label utilisé pour atteindre L10-R5 est déterminé grâce à la table CEF globale du routeur :
L10-R4# sh ip cef 10.10.5.5
10.10.5.5/32, version 41, cached adjacency to Serial0/1
0 packets, 0 bytes
tag information set
local tag: 17
fast tag rewrite with Se0/1, point2point, tags imposed: {27}
via 10.10.24.2, Serial0/1, 7 dependencies
next hop 10.10.24.2, Serial0/1
valid cached adjacency
tag rewrite with Se0/1, point2point, tags imposed: {27}
L10-R4 imposera donc le label 27 pour atteindre L10-R5, le prochain saut étant le routeur Cisco
L10-R2 (10.10.24.2). Le deuxième label (dit label VPN), servant à sélectionner l’interface de sortie
sur L10-R5, peut être déterminé grâce à la table CEF de la VRF « RED », indépendante de la table
CEF globale :
L10-R4# sh ip cef vrf RED 100.10.5.5
0 packets, 0 bytes
tag information set
local tag: VPN-route-head

fast tag rewrite with Se0/1, point2point, tags imposed: {27 26}
via 10.10.5.5, 0 dependencies, recursive
next hop 10.10.24.2, Serial0/1 via 10.10.5.5/32
tag rewrite with Se0/1, point2point, tags imposed: {27 26}
Le label VPN est donc 26. Pour joindre l’adresse IP 100.10.5.5 de la VRF « RED », le routeur Cisco
L10-R4 imposera donc la pile de label { 27 26 }. Sur le backbone MPLS, la commutation se fera
uniquement en fonction du premier label, comme le montre le résultat de la commande Cisco
traceroute :
L10-R4# trace vrf RED 100.10.5.5
1 10.10.24.2 [MPLS: Labels 27/26 Exp 0] 72 msec 72 msec 68 msec
3 100.10.57.5 28 msec * 28 msec
On remarque que seul le premier label a été modifié, le label VPN ayant été conservé intact
pendant tout le cheminement sur le backbone. La copie d’écran suivante montre quel aurait été le
résultat de la commande Cisco traceroute pour atteindre l’adresse de Loopback 10.10.5.5 (adresse
globale) à partir de L10-R4 :
L10-R4# trace 10.10.5.5
1 10.10.24.2 [MPLS: Label 27 Exp 0] 68 msec 68 msec 64 msec
3 10.10.35.5 28 msec * 24 msec
Il apparaît clairement que la présence du label VPN n’a pas d’effet sur les routeurs P du backbone :
ceux-ci switchent les paquets entre routeurs PE et n’ont aucune information sur les labels VPN.
Rappelons que les labels VPN, appris par MP-BGP, peuvent être affichés au moyen de la commande
Cisco « show ip bgp vpnv4 vrf <vrf> tags » :
L10-R4# sh ip bgp vpnv4 vrf RED tags
Network Next Hop In tag/Out tag
Route Distinguisher: 100:2 (RED)
100.10.4.4/32 0.0.0.0 28/aggregate(RED)
100.10.5.5/32 10.10.5.5 notag/26
100.10.7.7/32 10.10.5.5 notag/30
100.10.57.0/24 10.10.5.5 notag/28
100.10.171.0/24 10.10.5.5 notag/31

100.10.172.0/24 10.10.5.5 notag/32
On retrouve bien le label 26 pour atteindre le subnet 100.10.5.5/32 sur le routeur Cisco L10-R5. Si
l’on effectue un traceroute vers l’adresse 100.10.7.7, appartenant à L10-R7, on obtient le résultat
suivant :
L10-R4# trace vrf RED 100.10.7.7
Type escape sequence to abort.
Tracing the route to 100.10.7.7
4 100.10.57.7 36 msec * 36 msec
On constate la présence du Penultimate Hop Popping, entre les routeurs L10-R3 (10.10.24.3) et
L10-R5. (100.10.57.5). En effet, L10-R3 a retiré le premier label 23, servant à atteindre L10-R5.
Ce fonctionnement est confirmé en consultant la table TFIB de L10-R3 :
L10-R3# sh tag for
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Untagged 10.10.13.1/32 0 Se0/1 point2point
20 Pop tag 10.10.1.1/32 1693 Se0/1 point2point
22 20 10.10.4.4/32 3020 Se1/0 point2point
Pop tag 10.10.12.0/24 0 Se0/1 point2point
29 Aggregate 100.10.3.3/32[V] 0
L10-R3# sh ip cef 10.10.5.5
0 packets, 0 bytes
tag information set
local tag: 23
via 10.10.35.5, Serial0/0, 0 dependencies

next hop 10.10.35.5, Serial0/0
tag rewrite with Se0/0, point2point, tags imposed: {}
Le schéma ci-dessous montre le trajet suivi par les paquets, de L10-R4 vers L10-R7 :
4.7 – Accès Internet

Le principe des VRF permet de concevoir aisément des routeurs virtuels, qui consultent leurs
différentes tables de routage en fonction de l’interface d’entrée des paquets. Ces tables sont
remplies avec les routes du VPN associé, et le backbone MPLS assure la transmission des paquets
entre les routeurs PE. Il se pose alors le problème de l’accès à Internet, situé par définition à
l’extérieur des différents VPN. De plus, les fournisseurs d’accès Internet disposant de plusieurs
points de sortie, il est important que les sites clients puissent utiliser le meilleur chemin vers
l’extérieur.
Différentes méthodes existent pour permettre un accès Internet. Les deux premières se situent
dans la catégorie « Sub-Optimized Routing », du fait qu’elles ne permettent pas de sélectionner le
meilleur chemin vers Internet. La dernière, nommée « Optimum Routing », permet de choisir le
chemin optimal, tout en étant la plus « propre » techniquement.
4.7.1 – Route par défaut statique (Static Default Route)
La première méthode (la plus ancienne) consiste à une utiliser une extension de la commande
Cisco « ip route » pour définir une route par défaut dans les VRF des routeurs PE, au moyen de la
commande Cisco :
ip route vrf GREEN 0.0.0.0 0.0.0.0 PE-Internet global
où PE-Internet est l’adresse globale du PE fournissant l’accès à Internet. Pour que le retour des
paquets puisse être effectif vers le CE concerné, les routes VPN du CE doivent être déclarées
globalement sur son PE de rattachement, et propagées au PE-Internet (IGP, iBGP, etc.). Par
exemple, si un réseau 120.2.1.0/24 est connecté à un CE 120.1.1.1 appartenant au VPN « GREEN
», le PE doit contenir les deux lignes suivantes :
ip route vrf GREEN 0.0.0.0 0.0.0.0 120.1.1.2 global
ip route 120.2.1.0 255.255.255.0 120.1.1.1
Dans cet exemple, on a supposé que PE-Internet a pour adresse 120.1.1.2.
Lorsque le PE recevra un paquet sur la VRF « GREEN », il effectuera un lookup dans la table de
routage de cette VRF. Si aucune entrée n’est trouvée pour la destination IP, la route par défaut
injectée au moyen de la commande Cisco « ip route » sera utilisée. Il est à noter que la table de
routage globale du routeur est examinée pour atteindre PEInternet, et que les paquets traversent
le backbone MPLS sans label VPN (seul le label de PE-Internet est accolé par le PE).
Naturellement, ce type de routage n’est pas optimal, car si plusieurs PE disposent d’un accès
Internet, seul le PE déclaré dans la route par défaut sera employé. De plus, cette méthode « casse
» la notion de VRF avec la déclaration des routes VPN de manière globale sur les PE. Enfin, tous les
PE doivent être configurés de cette manière, avec pour chacun la route par défaut et la mise en
place dans la table de routage globale des routes VPN.
4.7.2 – Route par défaut dynamique (Dynamic Default Route)
Une solution plus propre techniquement pour propager une route par défaut à tous les PE est
d’utiliser la notion de VPN avec une topologie « Hub and Spoke ». Sur le routeur PE-Internet, une
VRF particulière est configurée pour annoncer la route par défaut (apprise par un autre routeur,
généralement avec eBGP). Si l’on souhaite propager manuellement cette route à un certains sites
de différents VPN, il suffit d’employer la politique d’attribution des RT du schéma ci-dessous :
Chacun des sites clients reçoit la route par défaut provenant du site vert central grâce au RT
500:1001. Pour permettre le retour des paquets, chaque site doit exporter vers le site central ses
propres routes (RT 500:1000). Chaque PE doit donc être configuré avec ces RT pour permettre la
propagation de la route par défaut. Il est ainsi possible de ne propager la route par défaut qu’à
certains sites d’un même VPN (les VRF de ces sites devant traiter les RT du VPN « Internet »), en
configurant les PE adéquats et en ne changeant rien sur les autres :
Si l’on souhaite propager automatiquement la route par défaut à tous les sites d’un même VPN
sans avoir à modifier la configuration des différents PE, il suffit d’importer et d’exporter le RT de ce
VPN dans la VRF « Internet ». De cette manière, aucun changement dans la configuration des PE
rattachés à ces sites n’est nécessaire.
Internet

MP BGP

Transféré par

Droits d'auteur :

Formats disponibles

MP BGP

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MP BGP

Transféré par

Droits d'auteur :

Formats disponibles

4.

4 – Multiprotocol BGP (MP-BGP)

 MP- BGP : peering entre routeurs d’un même AS ;

Name Default RD Interfaces

BLUE 100:1 Loopback1

GREEN 100:3 Serial0/0

RED 100:2 Loopback2

4.4.2 – Notion de RT (Route Target)

La configuration simple pour un VPN consiste à appliquer la règle :

 RT_import = RT_export = RT_VPN

4.4.3 – Configuration d’une VRF

 Nom de VRF (case-sensitive) ;

route-target export 500:1

route-target export 500:2

route-target import 500:1

route-target import 500:3

4.4.4 – Updates MP-BGP

4.4.5 – Configuration MP-BGP d’un PE

neighbor 10.10.1.1 remote-as 10

neighbor 10.10.1.1 update-source Loopback0

no neighbor 10.10.1.1 activate

neighbor 10.10.1.1 activate

neighbor 10.10.1.1 send-community extended

no bgp default route-target filter

neighbor iBGP peer-group

no neighbor iBGP activate

neighbor iBGP remote-as 10

neighbor iBGP update-source Loopback0

neighbor iBGP soft-reconfiguration inbound

neighbor iBGP activate

neighbor iBGP route-reflector-client

neighbor iBGP send-community extended

neighbor 10.10.2.2 peer-group iBGP

neighbor 10.10.3.3 peer-group iBGP

neighbor 10.10.4.4 peer-group iBGP

neighbor 10.10.5.5 peer-group iBGP

4.4.6 – Vérification du fonctionnement de MP-BGP

L10-R4# sh ip bgp vpnv4 all

BGP table version is 129, local router ID is 10.10.4.4

Status codes: s suppressed, d damped, h history, * valid, > best, i -

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 100:1 (default for vrf BLUE)

*> 100.10.4.4/32 0.0.0.0 0 32768 ?

*>i100.10.5.5/32 10.10.5.5 0 100 0 ?

Route Distinguisher: 100:2 (default for vrf RED)

*> 100.10.4.4/32 0.0.0.0 0 32768 ?

*>i100.10.5.5/32 10.10.5.5 0 100 0 ?

*>i100.10.7.7/32 10.10.5.5 0 100 0 102 i

*>i100.10.57.0/24 10.10.5.5 0 100 0 ?

*>i100.10.172.0/24 10.10.5.5 0 100 0 102 i

Route Distinguisher: 100:3 (default for vrf GREEN)

*>i100.10.3.3/32 10.10.3.3 0 100 0 ?

*> 100.10.4.4/32 0.0.0.0 0 32768 ?

*>i100.10.5.5/32 10.10.5.5 0 100 0 ?

*> 100.10.6.6/32 100.10.46.6 1 32768 ?

*> 100.10.46.0/24 0.0.0.0 0 32768 ?

*> 100.10.46.6/32 0.0.0.0 0 32768 ?

*> 100.10.161.0/24 100.10.46.6 1 32768 ?