0% ont trouvé ce document utile (0 vote)
109 vues18 pages

TPMPLS

GHB

Transféré par

abakaradammahamat
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
109 vues18 pages

TPMPLS

GHB

Transféré par

abakaradammahamat
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

Université CHEIKH-ANTA DIOP

Ecole Supérieure Polytechnique


Niveau : MASTER 1 SRT

Réalisé par :
• MAHAMAT ABAKAR ADAM HAGGAR
Sous la direction de :
• Mr ABDOU DIOP

2023-2024
TP_MPLS

Choisie :

Technologies utilisées
On a choisi pour ce travail les technologies suivantes :
• OSPF pour la communication intra-nuage.
• EIGRP en guise de protocole CE-PE.
• MP-BGP pour le VPN.

Précisions préalables
Ce schéma expose un exemple de topologie assez simple avec derrière chaque PE (Provider
Edge) pour chaque ClientA et ClientB, un routeur dédié.
Le but ici est de pouvoir permettre via un nuage MPLS (label-switching) de pouvoir faire
communiquer les sites des clients ensemble de façon totalement indépendante. Cela
sousentend ici que A_CE1 devra pouvoir avoir accès à A_CE2 mais pas à B_CE2 par
exemple (la réciproque est également vraie vous vous en doutez).
L’élément qui peut vous choquer en regardant ce schéma est l’absence de subnet séparé pour
les liens série CE (Customer Edge) du côté de PE1 et de PE2. Les interfaces d’A_CE1 et
B_CE1, par exemple, on a exactement la même adresse IP assignée sur leurs interfaces s1/0
et dans le même subnet, Rassurez-vous, c’est tout à fait normal. L’utilisation de table de
routage virtuelle pour chaque client (Virtual Routing and Forwarding ou VRF) nous permet

MAHAMAT ABAKAR ADAM HAGGAR 1


TP_MPLS

de distinguer les routes avec le concours d’autres paramètres notamment le RD (Route


Distinguisher).
Pourquoi les VPN MPLS?
Pour revenir à l’essentiel de la technologie, l’avantage de ce type de VPN MPLS est de
pouvoir faire du label-switching entre PE sans que les routeurs du milieu du nuage, les P,
n’aient à avoir connaissance des préfixes de destination dans leurs tables de routage
respectives. Cela nous permet de maintenir une architecture plus facilement et d’augmenter
également la fiabilité de celle-ci.
Enfin, de nos jours, c’est un sérieux concurrent pour les technologies plus anciennes de
couche 2 comme ATM ou Frame-Relay.

Tache 1 : Implémentation Méthodologie d’approche


1. Mise en place des VRF sur les PE

2. Configuration des interfaces

3. Mise en place du protocole intra-nuage

4. Mise en place du protocole CE-PE

5. Mise en place du protocole MP-BGP

6. Gestion de la redistribution respective des préfixes

NB : Méthodologie d’approche est facultative, l’accomplissement des différentes taches


demeure le plus important peu important la démarche.

Tache 2 : Tests et Vérifications

On se place sur la perspective d’A_CE1 qui a envie de contacter A_CE2 à travers le VPN
MPLS.

Regardons la table de routage de ce routeur : A_CE1#show ip route ; A_CE1#ping [Link]

Si vous êtes curieux, vous pouvez également regarder les labels bindings crées
automatiquement sur PE1 et/ou sur les autres routeurs du nuage MPLS : PE1 (config)#do sh
mpls ldp bind

NB : Commandes et informations nécessaires ci-dessous pour les configurations.

MAHAMAT ABAKAR ADAM HAGGAR 2


TP_MPLS

Mise en place des VRF sur les PE


Pour cette première étape, rien de compliqué quand vous connaissez la procédure !

PE1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
PE1(config)#ip vrf ClientA
PE1(config-vrf)#rd 1:1
PE1(config-vrf)#route import 1:1
PE1(config-vrf)#route export 1:1
PE1(config-vrf)#exit
PE1(config)#ip vrf ClientB

PE1(config-vrf)#rd 1:2
PE1(config-vrf)#route import 1:2
PE1(config-vrf)#route export 1:2
PE1(config-vrf)#exit
Pour détailler ce que nous faisons ici, nous créons deux tables de routage virtuelles(VRF)
pour chaque client. À l’intérieur de la configuration de la VRF, nous désignons de RD des
futures routes de cette VRF ainsi que le RT(Route Target) dans les deux sens(import et
export).
Cette étape est bien entendu à répéter sur PE2 qui accueillera exactement la même
configuration.

• PE1

MAHAMAT ABAKAR ADAM HAGGAR 3


TP_MPLS

• PE2

MAHAMAT ABAKAR ADAM HAGGAR 4


TP_MPLS

Configuration des interfaces


Outre la configuration des IPs, vous devez également effectuer plusieurs actions pour
préparer le terrain :

• Sur toutes les interfaces des PE directement reliées sur des CE, vous devez assigner à
l’interface locale du PE une VRF.

• Sur les interfaces concernées par le label-switching MPLS, vous devez activer le
protocole d’échange de label LDP(Label Distribution Protocol).
Assignation d’une VRF sur un port de routeur

Pour cela, rien de plus simple également, suivez plutôt l’exemple suivant sur PE1:
PE1(config)#int s1/0
PE1(config-if)#ip vrf forwarding ClientA
PE1(config-if)#ip add [Link] [Link]
PE1(config-if)#no sh
PE1(config)#int s1/1
PE1(config-if)#ip vrf forwarding ClientB
PE1(config-if)#ip add [Link] [Link]
PE1(config-if)#no sh
Avec cette commande ip vrf forwarding, j’affecte l’interface à la VRF choisie
uniquement. L’opération à répéter également sur PE2 en adaptant les adresses IPs bien
entendu !

MAHAMAT ABAKAR ADAM HAGGAR 5


TP_MPLS

Activation du LDP sur les interfaces concernées


On active ici uniquement le LDP sur les interfaces qui auront à faire du label-switching
(généralement les interfaces qui sont dans le nuage MPLS).

Pour ce faire également, la procédure est très simple. On prend l’exemple de PE1:

PE1(config)#int s1/2
PE1(config-if)#mpls ip

MAHAMAT ABAKAR ADAM HAGGAR 6


TP_MPLS

Cette procédure sera à répéter sur plusieurs ports (P1, P2 et PE2) qui sont dans le nuage
MPLS.

MAHAMAT ABAKAR ADAM HAGGAR 7


TP_MPLS

Mise en place du protocole intra-nuage

Dans cette section, nous allons juste activer OSPF dans le nuage pour garantir la
communication intra-nuage des routers P et PE.
Sur les PE(PE1 et PE2), la configuration est la suivante :
PE1(config-if)#router ospf 1

MAHAMAT ABAKAR ADAM HAGGAR 8


TP_MPLS

PE1(config-router)# network [Link] [Link] area 0


PE1(config-router)# network [Link] [Link] area 0
PE1(config-router)# exit
La première instruction « network » nous servira pour annoncer les réseaux de loopback des
PEs respectifs pour MP-BGP. La deuxième instruction annoncera dans le nuage les réseaux
directement connectés et formera des relations de voisinages avec ses voisins connectés.

Sur les P(P1 et P2), la configuration est la suivante :

MAHAMAT ABAKAR ADAM HAGGAR 9


TP_MPLS

P1(config-if)#router ospf 1
P1(config-router)# network [Link] [Link] area 0
P1(config-router)# exit

MAHAMAT ABAKAR ADAM HAGGAR 10


TP_MPLS

Ici, on ne fait que participer les interfaces comprises dans la range [Link]/24 étant donné
que ces P n’ont pas d’interfaces de loopback.

Si tout va bien à ce moment-là, PE1 devrait pouvoir pinger l’interface loopback 0 de PE2 sans
problèmes :

PE1#ping [Link]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to [Link], timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/16/28 ms
Mise en place du protocole CE-PE
Dans un premier temps, la configuration dédiée aux CE est très simple, du fait que le CE n’a
aucune notion de MPLS, il va juste établir une adjacence avec le PE auquel il est relié et
partager ses routes avec celui-ci.

Cette configuration sera à appliquer sur tous les CE en ne changeant aucune instruction :

A_CE1(config)#router eigrp 1
A_CE1(config-router)#network [Link]
A_CE1(config-router)#no auto-summary

MAHAMAT ABAKAR ADAM HAGGAR 11


TP_MPLS

MAHAMAT ABAKAR ADAM HAGGAR 12


TP_MPLS

Passons maintenant à la configuration du PE, un peu plus complexe. Nous allons dans le PE
configurer une instance d’EIGRP par VRF. Ces commandes s’appliqueront sur PE1 et PE2
sans aucun changement :

PE1(config)#router eigrp 1
PE1(config-router)#address-family ipv4 vrf ClientA
PE1(config-router-af)#network [Link]
PE1(config-router-af)#no auto-summary
PE1(config-router-af)#autonomous-system 1
PE1(config-router-af)#exit
PE1(config-router)#address-family ipv4 vrf ClientB
PE1(config-router-af)#network [Link]
PE1(config-router-af)#no auto-summary
PE1(config-router-af)#autonomous-system 1
PE1(config-router-af)#exit
*Jan 1 [Link].267: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 1: Neighbor [Link]
(Serial1/0) is up: new adjacency
*Jan 1 [Link].439: %DUAL-5-NBRCHANGE: IP-EIGRP(2) 1: Neighbor [Link]
(Serial1/1) is up: new adjacency
Remarquez en gras que deux adjacences se sont formées entre le PE et la CE concernée par la
VRF sur laquelle nous avons activé EIGRP.

MAHAMAT ABAKAR ADAM HAGGAR 13


TP_MPLS

Remarquez enfin que l’on fait bien correspondre le numéro d’AS d’EIGRP configuré
sur chaque CE avec l’argument de la commande « autonomous-system » dans la
configuration du PE pour chaque VRF. Mise en place du protocole MP-BGP
Pour configurer la liaison vpnv4 entre les deux PE que l’on recherche à faire, il nous faut
configurer sur les deux routeurs, comme on le ferait en BGP, une relation de voisinage en
prenant comme référence les IPs de loopback paramétrées précédemment.

MAHAMAT ABAKAR ADAM HAGGAR 14


TP_MPLS

La configuration pour PE1 est la suivante :

PE1(config)#router bgp 1
PE1(config-router)#neighbor [Link] remote-as 1
PE1(config-router)#neighbor [Link] update-source Lo0
PE1(config-router)#address-family vpnv4
PE1(config-router-af)#neighbor [Link] activate
PE1(config-router-af)#neighbor [Link] send-community extended
PE1(config-router-af)#exit
PE1(config-router)#exit
On demande également à ce que l’IP source des paquets qui s’échangent entre les pairs BGP
soit bien celle de notre IP de loopback, c’est-à-dire [Link] pour PE1.

Enfin, on active le mécanisme vpnv4 de BGP en le configurant également de telle sorte à ce


que BGP utilise le champ « community » de ses updates pour pouvoir en faire un champ de
communauté étendue(qui servira lors de la négociation des capacités des voisins, pour les RT
également qui sont stockés dans ce champ).

La configuration pour PE2 est exactement la même en adaptant les IPs:

PE2(config)#router bgp 1
PE2(config-router)#neighbor [Link] remote-as 1

MAHAMAT ABAKAR ADAM HAGGAR 15


TP_MPLS

PE2(config-router)#neighbor [Link] upd


PE2(config-router)#neighbor [Link] update-source Lo0
PE2(config-router)#address-family vpnv4
PE2(config-router-af)#neighbor [Link] activate
PE2(config-router-af)#neighbor [Link] send-community extended
PE2(config-router-af)#exit
PE2(config-router)#exit
Vous voyez la relation de voisinage BGP être négociée avec succès avec notamment cette
ligne de log:

*Jan 1 [Link].595: %BGP-5-ADJCHANGE: neighbor [Link] Up a


Sixième étape – Gestion de la redistribution respective des préfixes
Avant de pouvoir tester le bon fonctionnement de notre VPN, il nous manque encore une
brique importante de notre architecture.

Il faut configurer les PE de telle sorte à ce que la redistribution des routes soit effective
mutuellement dans les deux sens entre BGP et EIGRP. L’avantage de ce type d’architecture
est la scalabilité.

Imaginez que le client rajoute une route sur son CE. Dans ce cas, la route est
automatiquement redistribuée dans BGP et les autres PE seront directement au courant de ce
nouveau préfixe sans aucune intervention de votre part! Vous imaginez également le temps de
convergence réduit dont vous allez bénéficier!

Redistribution EIGRP => BGP – configuration:


Dans cette section, on s’occupe de redistribuer les routes apprises par
EIGRP dans BGP. La configuration similaire est également à appliquer sur
PE2.
PE1(config)#router bgp 1
PE1(config-router)#address-family ipv4 vrf ClientA
PE1(config-router-af)#redistribute eigrp 1 metric 1
PE1(config-router-af)#exit
PE1(config-router)#address-family ipv4 vrf ClientB
PE1(config-router-af)#redistribute eigrp 1 metric 1
PE1(config-router-af)#exit

MAHAMAT ABAKAR ADAM HAGGAR 16


TP_MPLS

PE1(config-router)#exit
Redistribution BGP => EIGRP – configuration:
Dans cette section, on fait l’inverse. On s’occupe de redistribuer les routes apprises par BGP
dans EIGRP. La configuration similaire est également à appliquer sur PE2.

PE1(config)#router eigrp 1
PE1(config-router)#address-family ipv4 vrf ClientA
PE1(config-router-af)#redistribute bgp 1 metric 1024 1 255 1 1500
PE1(config-router-af)#exit
PE1(config-router)#address-family ipv4 vrf ClientB
PE1(config-router-af)#redistribute bgp 1 metric 1024 1 255 1 1500
PE1(config-router-af)#exit
PE1(config-router)#exit
Après cette « touche finale », le moment de vérité est arrivé, voyons voir ce qu’il se passe!

MAHAMAT ABAKAR ADAM HAGGAR 17

Vous aimerez peut-être aussi