Diplome D'Ingenieur de Conception: 8 Promotion

REPUBLIQUE DU BENIN
********
UNIVERSITE D’ABOMEY-CALAVI (UAC)
********
ECOLE POLYTECHNIQUE D’ABOMEY-CALAVI (EPAC)
********
DEPARTEMENT DE GENIE INFORMATIQUE ET TELECOMMUNICATIONS (GIT)
********
OPTION : RESEAUX INFORMATIQUES ET INTERNET (RII)
MEMOIRE DE FIN DE FORMATION

POUR L’OBTENTION DU
DIPLOME D’INGENIEUR DE CONCEPTION
THEME :
IMPLEMENTATION DE VPLS DANS LE CENTRE DE

DONNEES DE BJNet et INTERCONNEXION DES
SITES DE BJNet
Réalisé par : Valerie Zita Alida Murielle de Dieu ASSOGBA WOUNON

Soutenu le 17 décembre 2015 devant le jury composé de :
Président : Dr. Michel DOSSOU Maître-Assistant CAMES

Membres : Dr. Thierry Oscar EDOH Enseignant à l’EPAC
Lieutenant Bidossessi R. ALAHASSA, Ir. Enseignant à l’EPAC
(Maître de mémoire)
Dr. Théophile ABALLO Enseignant à l’EPAC
Année Académique : 2014-2015

8ième Promotion
Sommaire
Sommaire i
Dédicace iii
Remerciements iv
Liste des tableaux vi
Table des figures vii
Liste des sigles et abbréviations ix
Résumé xiv
Abstract xv
Introduction 1
I Synthèse bibliographique 5
1 Etude de l’existant 6
2 La technologie VPLS 10
II Approche méthodologique 41
3 Choix de la méthode de déploiement de VPLS 42
4 Méthodologie d’implémentation de BGP-VPLS 54
i
SOMMAIRE
III Résultats et Discussion 70

5 Résultats de l’implémentation de BGP-VPLS et Discussion 71
Conclusion et Perspectives 81
Références bibliographiques 83
Annexe 87
Summary 92
Table des matières 103
Réalisé par Valerie ASSOGBA WOUNON ii

Dédicace
A
Ma mère Clotilde T. GUIDI
Reçois l’expression de ma profonde gratitude, amour et affection pour la

patience et pour tout ce que tu as consenti pour moi et dont je te suis à jamais
reconnaissante.
Mon père Irénée K. ASSOGBA WOUNON
Ma soeur Nadège ASSOGBA WOUNON
Et à tous ceux qui me sont chers.
iii
Remerciements
Je remercie Dieu Tout-Puissant pour son Amour, le courage qu’Il m’a tou-
jours apporté durant ma formation et qui m’a permis de réaliser ce travail.
Je remercie tous ceux qui ont de près ou de loin participé à la réalisation de
ce travail. J’adresse mes remerciements particuliers :
? Au Professeur Félicien AVLESSI, Directeur de l’Ecole Polytechnique

d’Abomey-Calavi, et à son adjoint le Professeur Clément BONOU ;
? Au Professeur Marc Kokou ASSOGBA, chef du département de Génie

Informatique et Télécommunications et à tous les enseignants dudit dépar-
tement ;
? A mon maître de mémoire, Lieutenant Bidossessi R. ALAHASSA, qui a

accepté encadrer ce travail et qui m’a soutenue pour son aboutissement ;
? A l’ensemble du corps enseignant de l’EPAC ;
? Au docteur Michel DOSSOU, pour les conseils qu’il m’a prodigués ;
? Au directeur de l’Agence Béninoise des Technologies de l’Information et

de la Communication, Damien MAGNON qui m’a admise en stage dans sa
structure ;
? Au Commandant Farell FOLLY pour toute l’aide qu’il m’a apportée dans
ce travail et pour avoir accepté être mon tuteur ;
? Au docteur Victorin CHEGNIMONHAN, à Prosper TONATO, pour m’avoir

aidée à corriger mon mémoire.
iv
Remerciements
? A Isaac TOVIESSI, à M. BAKARY, à Marius ESSE, à Eric TOVIESSI, à

M. René ACAKPO, au Dr KONON, à M. Mathias HOUNGBO, pour s’être
rendus disponibles lors de mes recherches.
? A mes tantes particulièrement Bibiane GUIDI, oncles, cousins particulière-

ment Félicité GUIDI, nièces et neveux Alvinie, Ismène, Havnette.
? à tous les amis de ma promotion particulièrement ceux du Génie Informa-

tique et Télécommunications (GIT) et du Génie Electrique (GE) pour les
bons moments passés ensemble.
Réalisé par Valerie ASSOGBA WOUNON v

Liste des tableaux
2.1 Comparaison des technologies de couche 2 étendant un LAN . . . . 39
3.1 Comparaison des solutions VPLS . . . . . . . . . . . . . . . . . . . 46
4.1 Outils de base utilisés . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.2 Plan d’adressage utilisé pour la figure 4.1 . . . . . . . . . . . . . . . 58
4.3 Plan d’adressage utilisé pour la figure 4.7 . . . . . . . . . . . . . . . 66
5.1 Plan d’addressage des différents équipements . . . . . . . . . . . . . 73

5.2 Tools used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
vi
Table des figures
1.1 Architecture du centre de données de BJnet . . . . . . . . . . . . . . 9
2.1 Classification des VPNs . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Terminologie L2VPN . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Modèle de référence VPWS . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Modèle de Référence de VPLS . . . . . . . . . . . . . . . . . . . . 16
2.5 FEC 129 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 Encapsulation VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1 BGP NLRI pour VPLS . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1 Architecture utilisés pour la mise en place du réseau MPLS . . . . . 57

4.2 Configuration de l’interface virtuelle . . . . . . . . . . . . . . . . . 60
4.3 Vérification de la configuration du protocole OSPF . . . . . . . . . . 61
4.4 Vérification du fonctionnement LDP MPLS . . . . . . . . . . . . . . 62
4.5 Configuration des sessions IBGP . . . . . . . . . . . . . . . . . . . 63
4.6 Instance VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.7 Architecture utilisée pour l’interconnexion de 3 sites . . . . . . . . . 65
4.8 Configuration de VPLS sur un PE participant à plusieurs domaines
VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.1 Architecture physique utilisée pour l’implémentation de VPLS . . . . 72

5.2 Test sur PE1 de l’établissement du maillage des PWs VPLS . . . . . 74
5.3 Echange des messages Update entre PE1 et PE3 . . . . . . . . . . . 75
5.4 Test de l’implémentation de VPLS : CE_A1 . . . . . . . . . . . . . 76
5.5 Test de l’implémentation de VPLS : CE_A2 . . . . . . . . . . . . . 77
vii
Table des figures
5.6 Test de l’implémentation de VPLS : CE_B2 . . . . . . . . . . . . . . 78

5.7 Architecture used for VPLS implementation . . . . . . . . . . . . . 98
5.8 Test of VPLS implementation : CE_A1 . . . . . . . . . . . . . . . . 101
5.9 Test of VPLS implementation : CE_A2 . . . . . . . . . . . . . . . . 101
Réalisé par Valerie ASSOGBA WOUNON viii

Liste des sigles et
abbréviations
A
AC : Attachment Circuit
AFI : Address Family Identifier
AGI : Address Group Identifier
AS : Autonomous System
ATM : Asynchronous Transfer Mode
BGP : Border Gateway Protocol
CE : Customer Edge
DECnet : Digital Equipment Corporation networks
ix
LISTE DES SIGLES ET ABBRÉVIATIONS
EBGP : External Border Gateway Protocol

EoMPLS : Ethernet over MPLS
FEC : Forwarding Equivalency Class

FIB : Forwarding Information Base
FR : Frame Relay
GRE : Generic Routing Encapsulation
HA : High Availability
H-VPLS : Hierarchical VPLS
IBGP : Interior Border Gateway Protocol

IETF : Internet Engineering Task Force
IP : Internet Protocol
IPLS : IP-Only LAN Service
IPSec : IP security
IPX : Internetwork Packet Exchange
ISP : Internet Service Provider
Réalisé par Valerie ASSOGBA WOUNON x

L2 : Layer 2
L2TP : Layer 2 Tunneling Protocol
L2VPN : Layer 2 Virtual Private Network
L3 : Layer 3
L3VPN : Layer 3 Virtual Private Network
LAN : Local Area Network
LB : Label Base
LDP : Label Distribution Protocol
LER : Label Edge Router
LSP : Label Switched Path
LSR : Label Switching Router
MAN : Metropolitan Area Network

MAC : Media Access Control
MPLS : MultiProtocol Label Switching
MTU : Maximum Transfer Unit
n-PE : network-PE
NLRI : Network Layer Reachability Information
NREN : National Research and Education Network
OSI : Open System Interconnection

OSPF : Open Shortest Path First
Réalisé par Valerie ASSOGBA WOUNON xi

P : Provider
PBB : Provider Backbone Bridging
PDU : Protocol Data Unit
PE : Provider Edge
PHP : Penultimate Hop Popping
PPP : Point-to-Point Protocol
PSN : Packet Switched Network
PW : Pseudo Wire
QoS : Quality of Service

R
RD : Route Distinguisher
RerBénin : Réseau de l’Education et de la Recherche du Bénin
RFC : Request For Comment
RIP : Routing Information Protocol
RSVP-TE : Resource -Reservation Protocol-Traffic Extension
RT : Route Target
RTF : Route Target Filtering
SAII : Source Attachment Individual Identifier

SAFI : Subsequent Address Family Identifier
STP : Spanning Tree Protocol
Réalisé par Valerie ASSOGBA WOUNON xii

TAII : Target Attachment Individual Identifier

TCP : Transport Control Protocol
TE : Traffic Engineering
TLV : Type, Length, Value
ToS : Type of Service
u-PE : User-PE
VBO : VE Block Offset

VBS : VE Block Size
VE : VPLS Edge
VC : Virtual Circuit
VLAN : Virtual LAN
VPLS : Virtual Private LAN Service
VPN : Virtual Private Network
VPWS : Virtual Private Wire Service
VSI : Virtual Switch Interface
VRF : Virtual Routing and Forwarding
WAN : Wide Area Network

WACREN : West and Central African Research and Education Network
Réalisé par Valerie ASSOGBA WOUNON xiii

Résumé
BJNet est un réseau WAN (Wide Area Network) qui offre plusieurs services
à ses clients, dont les services de couche 2. La fourniture des services de couche
2 tels que la vidéo conférence, le VoIP, la téléphonie, le clustering (dans le
cas d’un centre de données pour permettre l’augmentation de la puissance de
traitement et l’augmentation de la disponibilité, lorsque le centre de données est
réparti sur plusieurs sites, par exemple le centre de données de BJNet) à travers
un réseau nécessite une connectivité de couche 2 entre les équipements de ce
réseau. Plusieurs technologies tels que VPLS (Virtual Private LAN Service),
Ethernet QinQ, EoMPLS (Ethernet over Multiprotocol Label Switching), etc
permettent de fournir une connectivité de couche 2 à travers plusieurs sites.
VPLS est la meilleure solution pour offrir ce service. VPLS fournit un service
Ethernet multipoint à multipoint. C’est une technique permettant d’étendre un
LAN (Local Area Network) sur plusieurs sites, à travers un réseau cœur MPLS.
Ce mémoire a décrit le concept de VPLS, ses avantages par rapport aux autres
technologies permettant d’étendre un LAN et le type de topologie VPLS à
implémenter dans le réseau BJNet. Une analyse a été effectuée pour choisir la
méthode de déploiement de VPLS la plus adéquate pour le réseau BJNet. La
méthode BGP basé sur VPLS a été choisie parce qu’elle a l’avantage d’être
la méthode la plus évolutive et flexible. Cette méthode de déploiement a été
implémentée en tenant compte de différents scénari pouvant se présenter dans le
réseau BJNet.
Mot-clés : MPLS, VPLS, BGP, Ethernet, VPN.
xiv
Abstract
BJNet is a WAN (Wide Area Network) which offers several services to
its customers as layer 2 services. The provision of Layer 2 services such as
video conferencing, VoIP, telephony, clustering (in the case of a data center
to allow the increase in processing power and increasing the availability when
the data center is distributed over multiple sites, for example, data center of
BJNet) through a network requires a layer 2 connectivity between devices in
the network. Several technologies such as VPLS (Service Virtual Private LAN),
Ethernet QinQ, EoMPLS (Ethernet over Multiprotocol Label Switching), etc.
are used to provide layer 2 connectivity across multiple sites. VPLS is the best
solution to offer this service. VPLS provides a multipoint-to-multipoint Ethernet
service. This is a technique to extend a LAN (Local Area Network) at several
sites through a backbone MPLS network. This memoir describes the concept of
VPLS, its advantages over other technologies for extending a LAN and type of
VPLS topology to implement in the BJNet network. An analysis was performed
to select the most appropriate VPLS deployment method for BJNet network.
This deployment method has been implemented taking into account different
scenarios that may arise in the BJNet network.
Key-words : MPLS, VPLS, BGP, Ethernet, VPN.
xv
Introduction
Ethernet est la technologie LAN (Local Area Network) la plus largement
déployée dans les réseaux actuels. Ces dernières années, les standards Ethernet
ont évolué de manière très significative, d’une part en ce qui concerne le débit
géré par cette technologie, avec une croissance impressionnante de 10 Mb/s à
100 Gb/s, et d’autre part par les améliorations du protocole pour étendre l’usage
d’Ethernet au contexte de réseau longue distance : MAN (Metropolitan Area
Network) ou WAN (Wide Area Network)(Uzé J-M, 2003). Aussi avec l’évolution
du monde économique, plusieurs structures couvrent de plus en plus de plus
grandes distances pour fournir des services de qualité à une vaste clientèle de
base. Ces structures recherchent donc des moyens, fiables et sécurisés, qui leur
permettraient d’échanger des données avec des sites distants.
Les fournisseurs de services à l’origine remplissaient ce besoin en fournis-

sant des lignes dédiées. Mais ces dernières avaient des conséquences significa-
tives telles que : les coûts de mise en place et de location des lignes, ainsi que
des coûts matériels. Plusieurs autres technologies (ATM, Frame Relay, MPLS)
utilisant la technique de commutation de paquets sont apparues. Mais, aucune de
ces techniques ne satisfait pleinement les besoins des entreprises sur-cités.
Virtual Private LAN Service est une technologie de réseau qui permet de
mettre en connexion plusieurs LANs individuels, à travers un réseau de paquets
commutés, apparaissant et fonctionnant comme dans un simple LAN (Anderson
L. et Rosen E., 2006). Elle supporte une communication multipoint à multipoint
et s’est avérée être une meilleure solution pour les fournisseurs de services.
Plusieurs structures et fournisseurs de services adoptent cette solution (HUAWEI,
2012).
1
Introduction
Le réseau BJNet est un réseau WAN étendu sur tout le territoire béninois qui
doit fournir un certain nombre de services à ses clients, dont des services de
couche 2 (modèle OSI). Aussi, le centre de données de BJNet est géographique-
ment réparti sur deux sites. Compte tenu du cluster mis en place dans le centre de
données pour la disponibilité, et de certaines applications (migration de machines
virtuelles, etc), les deux sites doivent être interconnectés par une connectivité
de couche 2, c’est-à-dire considérés comme étant dans un même réseau LAN ;
d’où la nécessité d’implémenter VPLS. De plus, avec VPLS, BJNet pourra
satisfaire ses clients manisfestant le désir d’interconnecter leur infrastructure
par une connectivité de couche 2. L’avantage qu’offre VPLS de favoriser une
grande flexibilité permettra à BJNet d’offrir des services de couche 2 à certaines
structures ou organisations comme le RerBenin (Réseau de l’Education et de la
Recherche du Bénin) et leur permettre de s’assurer de la gestion technique tels
que le routage, la sécurité et administrative de leur réseau. Il est souhaité pour
BJNet une implémentation de VPLS basée sur une architecture et des protocoles
favorisant l’évolutivité du réseau.
L’objectif de ce mémoire est d’implémenter VPLS dans le réseau BJNet pour
la fourniture de services de couche 2.
Notre travail se décline en trois parties. La première partie sera consacrée
à l’étude de l’existant et à la généralité sur VPLS. Dans la partie suivante, il
s’agira de choisir la méthode d’implémentation de VPLS adaptée pour BJNet,
de présenter les outils utilisés, et de définir ensuite la méthodologie à suivre pour
implémenter VPLS. La dernière partie concernera l’implémentation effective
de VPLS avec le protocole de signalisation et d’auto-découverte BGP et la
présentation des différents tests effectués.
Contexte, justification et problématique

BJNet est un réseau d’infrastructures permettant l’interconnexion de toutes
les structures de l’administration publique. En outre, le réseau peut fournir
plusieurs services dont l’accès à Internet à toute structure exploitant ses infra-
structures. Ce réseau est national ; ses infrastructures sont donc présentes dans
tous les départements et couvrent une bonne partie des communes du Bénin.
Pour la centralisation de ses données, BJNet dispose d’un centre de données. Ce

centre de données est réparti sur deux sites distants l’un à l’Université d’Abomey-
Réalisé par Valerie ASSOGBA WOUNON 2

Introduction
Calavi (UAC) et l’autre au Camp guézo. BJNet désire offrir un certain nombre
de services à ses clients. Il est donc mis en place un cluster pour permettre une
bonne disponibilité des services du centre de données. Les Clusters définissent
une collection de machine (serveurs) qui opèrent comme s’ils étaient une seule
machine. Le but principal de haute disponibilité (HA) des clusters est de fournir
un accès ininterrompu aux données, même si un serveur perd la connectivité
réseau ou de stockage, ou échoue complètement, ou si l’application en cours
d’exécution sur le serveur échoue. L’une des exigences du cluster est que les
noeuds du cluster soient interconnectés par un réseau privé c’est-à-dire qu’ils
soient dans un même réseau Ethernet (Gandotra Indu et al, 2011). VPLS constitue
l’une des solutions qui permettent d’interconnecter plusieurs sites distants comme
s’ils étaient dans le même réseau LAN.
BJNet, en tant que fournisseur de services doit fournir la possibilité aux struc-
tures, comme le RerBénin, qu’il interconnecte, d’interconnecter leurs différents
sites, d’établir et de gérer leur politique de routage et de sécurité. Le RerBénin
est un réseau de recherche ou un NREN 1 (National Research and Education
Network) visant à interconnecter toutes les universités publiques et privées du
Bénin, il a plusieurs objectifs : l’amélioration de la qualité de la formation et
de la recherche, la démocratisation de l’accès à l’information, et un meilleur
partage du savoir, la mutualisation des ressources pédagogiques et de recherche,
la gouvernance numérique par le développement des e-services et la mobilité des
étudiants, professeurs et personnels administratifs. RerBenin fait partie de réseau
NREN plus grand comme WACREN (West And Central African Research and
Education Network), un réseau NREN sur le plan africain. Ce réseau peut être
considéré comme un WAN avec des protocoles de routage bien précis. L’infra-
structure physique de BJNet peut servir au RerBenin pour l’interconnexion des
universités. Mais BJNet doit pouvoir laisser la possibilité au RerBenin de gérer
sa politique de routage et de sécurité. Cette possibilité sera effective si BJNet
utilise VPLS pour ses interconnexions.
1. Un NREN est un réseau dédié à soutenir les besoins des communautés de recherche et d’éducation dans un
pays.

Introduction
Objectifs
L’objectif principal de ce projet est d’implémenter VPLS dans le centre de
données de BJNet et dans le réseau BJNet. De façon spécifique, il s’agit de :
• faire une étude pour justifier le choix de l’implémentation de la topologie

VPLS dans le réseau BJNet ;
• choisir selon les contraintes spécifiques au contexte d’étude, l’architecture

et les protocoles les plus idoines pour l’implémentation de VPLS dans le
réseau BJNet ;
• définir selon les contraintes matérielle et technique, les outils et la technique

pour une bonne implémentation de VPLS ;
• implémenter et tester VPLS dans le réseau BJNet et fournir une procédure

d’implémentation de VPLS.

Première partie
Synthèse bibliographique
5
Chapitre 1
Etude de l’existant
Le terme BJNet désigne un réseau informatique en cours de déploiement au
Bénin. Son but est d’interconnecter tous les services publics et les organismes
d’enseignement supérieur et de recherche du Bénin par l’intermédiaire d’une
plateforme susceptible de fournir des services d’interconnexion basés sur IP.
Dans ce chapitre, nous présentons le réseau BJNet en général, ses objectifs
et le centre de données du réseau.
1.1 Présentation de BJNet

BJNet est un projet de l’Etat béninois, initié dans le cadre de la coopération
entre l’Université Catholique de Louvain (UCL) de la Belgique et l’Université
d’Abomey-Calavi (UAC) du Bénin. Ce projet a été initié par deux éminents
professeurs que sont : le Professeur Marc LOBELLE, Colonel de Réserve de
l’Armée des Transmissions dans l’Armée Belge et Professeur à l’Université
Catholique de Louvain et coordonnateur du projet en Belgique et le Profes-
seur Norbert HOUNKONNOU, Président de la Chaire Internationale Physique
Mathématique et Application (CIPMA) et coordonnateur du projet au Bénin.
Dans son modèle de déploiement, BJNet base le cœur du réseau sur les tron-
çons de fibre optique de Bénin Télécoms S.A., qui, met à la disposition de
BJNet, une paire de fibre noire que BJNet se charge d’alimenter avec ses propres
équipements. Au regard du budget et tenant compte de la faisabilité dans les
délais impartis, BJNet interconnecte certaines structures avec des fibres ac-
quises sur fonds propre. Ainsi, la Faculté des Sciences de la Santé, le campus
6
CHAPITRE 1. ETUDE DE L’EXISTANT
d’Abomey-Calavi, le Ministère de la Défense Nationale et le campus du Camp

Guézo sont entièrement interconnectés en fibre optique. Les autres entités sont
interconnectées par faisceaux hertziens.
Ce réseau est national et s’étend sur toute l’étendue du territoire béninois ; les
structures à interconnecter étant présentes dans tous les départements du Bénin.
Le projet BJNet est d’un grand intérêt, surtout pour l’enseignement. Car il
apporte une solution au problème d’insuffisance d’enseignants et de ressources
didactiques dans les centres universitaires. En effet, parmi la vingtaine de centres
universitaires répartis sur le territoire, aucun centre ne dispose réellement du
nombre requis d’enseignants et de supports pédagogiques. Le campus universi-
taire d’Abomey-Calavi et celui de Parakou ont les plus grands nombres d’ensei-
gnants et de supports pédagogiques. BJNet, grâce à l’interconnexion envisagée,
permettra à ces autres centres universitaires de bénéficier de la mutualisation
desdites ressources. Ainsi, les applications qui seront développées, comme la
plate-forme d’apprentissage à distance, permettront de juguler largement le défi-
cit d’enseignants. De plus, ce réseau permettra d’améliorer la coopération entre
les universités.
Le réseau BJNet comporte essentiellement des routeurs Mikrotik. Mikrotik est

une marque de fabricants matériel de réseaux informatiques. Les performances,
la versatilité, la stabilité et surtout le coût (entre 10 et 50 fois moins cher que la
concurrence (Cisco, Juniper) pour des services équivalents) font des solutions
Mikrotik, un choix avantageux pour BJNet.
1.2 Objectifs de BJNet

Les objectifs du réseau BJNet sont de doter le Bénin d’un réseau informatique
performant, basé sur les protocoles de l’Internet, interconnectant en toute sécurité
entre eux et avec l’internet :
• les sites universitaires et de recherche publics du Bénin ;
• les sites d’organismes du secteur public.

Le réseau doit permettre à chaque classe d’utilisateurs (On entend par « classe
d’utilisateurs », l’ensemble des sites d’une administration ; par exemple l’En-
seignement Supérieur, le ministère de la Défense...etc.) d’établir sa politique de
sécurité. Cette dernière définira :
• les autres sites du réseau avec lesquels chaque site de cette administration
peut communiquer ;
• les utilisateurs de ce sous-réseau (au moyen de VLAN) ;
• les trafics à chiffrer ;
• Les serveurs accessibles au grand public ;
• d’autres aspects qu’il appartiendra à chaque classe d’utilisateurs de préciser

dans sa politique de sécurité, et à BJNet d’implémenter.
Le réseau BJNet offrira un accès facile et sécurisé à des logiciels libres, no-
tamment au profit des universitaires. Ces derniers bénéficieront d’autres facilités
comme l’accès au réseau universitaire international Eduroam.
1.3 Centre de données de BJNet

Pour la centralisation des données qu’il gère, le réseau BJNet dispose d’un
centre de données. Pour garantir une bonne disponibilité des services, le centre
de données de BJNet est réparti sur deux sites, disposant chacun d’un serveur
physique. Le cluster ainsi mis en place permet de mettre en œuvre deux fonc-
tionnalités :
• augmentation de la puissance de traitement : les requêtes des clients ne

seront pas toutes traitées par la même machine ;
• augmentation de la disponibilité : les inconvénients liés aux pannes seront

minimisés par la redondance des machines entre elles.
Les services seront donc déployés à l’identique sur les deux sites, et fonction-
neront en primaire sur l’un et en secondaire sur l’autre.

Un travail de mémoire dont le thème est intitulé « Conception d’un environne-

ment virtuel pour le déploiement d’un centre de données : cas de BJNet» a été
abordé par Joris FAGBEMIRO (2014) pour mettre en place et définir l’architec-
ture du centre de données. L’architecture du centre de données se présente en
général comme suit (figure 1.1) :
Le réseau BJNet dispose d’un réseau coeur MPLS (MultiProtocol Label
Switching).
F IGURE 1.1: Architecture physique du centre de données BJNet

Chapitre 2
La technologie VPLS
Virtual Private LAN Service (VPLS), encore connu sous le nom de Trans-
parent LAN Service ou de Virtual Private Switched Network service, est un
VPN (Virtual Private Network) de niveau 2 multipoint à multipoint basé sur
la technologie Ethernet (Kompella K. et Rekhter Y., 2007). VPLS assure un
service Ethernet multipoint-à-multipoint pouvant être indifféremment délivré au
niveau d’une infrastructure métropolitaine ou sur des réseaux longue distance, et
apporte une connectivité entre plusieurs sites comme si ces sites étaient reliés
par un même LAN Ethernet.
Dans ce chapitre, nous présentons plus succintement la technologie VPLS, en

exposant une généralité sur la famille L2VPN, les cas d’utilisation de VPLS, les
caractéristiques et les différents aspects du VPLS tels que les protocoles utilisés
pour mettre en place VPLS, les architectures et les options de déploiement de
VPLS.
2.1 Virtual Private Network

Un VPN (Virtual Private Network) est un terme générique. Il utilise une
infrastructure partagée publique de télécommunications, telle que Internet, pour
fournir un accès sécurisé à un ensemble de sites clients qui sont séparés des
autres réseaux clients. Il existe deux types de VPN : les L2VPNs et les L3VPNs.
Un VPN de niveau 2 (L2VPN) est un VPN, où l’interconnexion de clients est

fondée sur le niveau trame (couche 2 du modèle OSI). Il permet ainsi d’acheminer
10
CHAPITRE 2. LA TECHNOLOGIE VPLS
entre des sites appartenant au même VPN, des trames clientes, au-dessus d’une
infrastructure de réseau privé ou public.
Un VPN de niveau 3 (L3VPN) est un VPN, où l’interconnexion de clients est

fondée sur le niveau réseau (couche 3 du modèle OSI).
La figure 2.1 présente une classification des VPNs. Nous nous interesserons
dans la suite qu’au L2VPN.
F IGURE 2.1: Classification des VPNs (Jeff APCAR, 2006)
2.1.1 L2VPN
Un L2VPN fournit une connectivité de couche 2 de bout en bout, à travers
un réseau coeur IP/MPLS (Muhammad W. S. et Paresh S., 2006). Il peut être
Ethernet, Frame Relay, ATM, PPP, etc. Les trames de la couche 2 (généralement
Ethernet) sont transportées d’un site à un autre. Dans un cas plus général, L2VPN
est similaire à un câble reliant deux commutateurs dans des bâtiments séparés.
Les tunnels L2 VPNs sont conceptuellement plus simples que les L3 VPNs, et
s’ils sont correctement mis en œuvre, ils peuvent être complètement transparents
aux applications.
Il existe fondamentalement deux différents types de service VPN de la couche

2 (Figure 2.1) qu’un fournisseur de services pourrait offrir à un client : Virtual

Private Wire Service (VPWS) et Virtual Private LAN Service (VPLS)(Anderson

L. et Rosen E., 2006). Il y a aussi la possibilité d’offrir le service IP-only LAN-
like Service (IPLS). C’est une approche qui fonctionne de la même façon que
VPLS mais il supporte uniquement le trafic IP. Sa spécification est décrite par
SHAH H. et ROSEN E. dans la RFC7436 (Himanshu Shah et al, 2006). Les
dispositifs CEs sont des routeurs, mais les PEs acheminent les paquets IP en se
basant sur les adresses MAC et non sur les adresses IP.
Les architectures sont décrites dans la RFC4664 (Framework for Layer 2

Virtual Private Network) de Anderson L. et Rosen E.
2.1.1.1 Terminologie et Composants fonctionnels du L2VPN

Tous les types de L2VPN doivent transporter des trames à travers le réseau
cœur reliant les Providers Edge (PEs). Dans tous les types L2VPN, un PE (PE1)
reçoit une trame d’un CE (CE1), puis transporte la trame à un PE (PE2), qui
transporte alors la trame à un CE (CE2). Dans ce paragraphe, nous présentons
la terminologie des L2VPN et les composants fonctionnels qui sont nécessaires
pour le transport de trame de couche 2 dans tout type de service L2VPN.
Provider Edge (PE)

Il s’agit des routeurs de périphérie du réseau cœur. Ils sont situés en entrée
du réseau (PE ingress) et en sortie du réseau (PE egress).
Customer Edge (CE)

Il s’agit de l’équipement du client. C’est soit un routeur, soit un pont, soit un
commutateur, soit directement un hôte.
Attachment Circuit (AC)

L’AC permet de connecter le CE du réseau client au PE du réseau du four-
nisseur. Le CE peut être un routeur , un switch, un hôte, dont le client a besoin
pour être rattaché au VPN. Le circuit d’attachement peut être soit un circuit
physique, soit un circuit logique. Exemple de circuit d’attachement : Frame Re-
lay DLCI, ATM VPI/VCI, Ethernet port, Ethernet VLAN, ATM, connexion PPP...

Pseudowire
Un pseudowire est une émulation de connectivité point à point sur un réseau
PSN (Packet Switched Network) ou réseau à commutation de paquets permettant
l’interconnexion de deux nœuds quelles que soient leurs technologies de niveau 2.
Un pseudowire est établi de routeur PE à routeur PE et est utilisé pour transporter
une trame entre ces PEs. La mise en place et le maintien des PWs est un rôle
qui revient aux PEs. L’état d’information d’un PW particulier est maintenu par
les deux PEs qui représentent ses extrémités, et non par d’autres PEs, ou par
d’autres routeurs dans le réseau cœur.
Forwarders (Transmetteurs)
Le "forwarder" fonctionne comme une table de transfert VPLS. Une fois que
le PE reçoit le paquet d’un AC, le forwarder sélectionne un PW pour la transmis-
sion du paquet. Les différents types de L2VPN ont différents types de forwarders.
Tunnels
Un PW est transporté dans un tunnel de PE1 à PE2. Nous supposons qu’un
nombre arbitraire de PWs peut être transporté dans un seul tunnel ; la seule
exigence est que les PWs se terminent tous à PE2.
Tous les PWs dans le tunnel peuvent ne pas provenir de PE1 ; les tunnels
peuvent être des tunnels multipoint-à-point. Tous les PWs entre la même paire
de PEs voyagent dans le même tunnel. Mais une trame voyageant à travers un tel
tunnel arrive à PE2, PE2 doit être en mesure de l’associer à un PW particulier.
Une variété de différentes technologies de tunneling peut être utilisée pour
les tunnels PE-PE. Comme spécifié dans la RFC4664 (Anderson L. et Rosen
E., 2006), ce qui est vraiment nécessaire est que les technologies de tunneling
permettent le bon démultiplexage des PWs contenues. Les tunnels pourraient
être des LSP MPLS, des tunnels L2TP, des tunnels IPsec, des tunnels MPLS-in-
IP, MPLS-in- GRE, etc. En général, la technologie de tunneling nécessitera
l’utilisation d’une encapsulation qui contient un champ démultiplexeur, où le
champ démultiplexeur est utilisé pour identifier un PW particulier.
Packet Switched Network Tunnel (PSN tunnel)

Un tunnel, sur un réseau à commutation de paquets, qui relie des routeurs
PE.

La figure 2.2 illustre la terminologie utilisée en L2VPN et la structuration

fonctionnelle de celui-ci.
F IGURE 2.2: Terminologie L2VPN ( David JACQUET, 2009)
2.1.1.2 Modèles L2VPN
Modèle de VPWS
VPWS (Virtual Private Wire Service) est une technologie qui permet d’émuler
des connexions point à point sur un réseau de commutation de paquets. Elle
donne la possibilité d’interconnecter deux noeuds, quelle que soit la technologie
de niveau 2 utilisée (Ethernet, ATM, Frame Relay, etc).
Les dispositifs PE fournissent une interconnexion logique de telle sorte qu’une

paire de dispositifs CE semble être reliée par un simple circuit logique de couche
2. Les PEs agissent comme des commutateurs de couche 2. Les circuits de
couche 2 sont ensuite mappés sur des tunnels dans le réseau du fournisseurs de
services. Ces tunnels peuvent soit être spécifiques à un VPWS particulier, ou
être partagés entre plusieurs services.
Le trafic du client est encapsulé en gardant l’entête de la couche 2. Ceci est
possible grâce aux PWs. Si par exemple les réseaux locaux d’un client utilisent

F IGURE 2.3: Modèle de référence VPWS
la technologie Ethernet, un PW Ethernet permettra de transporter les PDUs

Ethernet/802.3 sur un réseau MPLS.

Modèle de VPLS
Comme spécifié ci-dessus, VPLS s’appuie sur Ethernet pour fournir un
service multipoint simple. Le réseau de l’opérateur IP/MPLS est vu comme un
commutateur Ethernet auquel sont connectés les différents sites. Les sites distants
sont connectés comme s’ils appartiennent au même réseau local Ethernet.
La figure suivante (figure 2.4) illustre le modèle de référence de VPLS.
F IGURE 2.4: Modèle de Référence de VPLS
Chaque routeur PE du réseau IP/MPLS doit intégrer les fonctionnalités VPLS.

Un domaine VPLS est constitué de plusieurs routeurs PEs. Chaque PE participant
à un domaine VPLS doit activer une instance VPLS participant à ce domaine.
Une instance VPLS est appelée Virtual Switch Instance (VSI) parce qu’elle
simule le fonctionnement d’un commutateur.
Les PEs doivent supporter certaines fonctionnalités. Ils ont besoin d’inonder
les autres PEs, participants dans un domaine VPLS, des trames d’adresses MAC
inconnues (flooding), d’enregistrer les adresses MAC (l’auto-apprentissage des
adresses MAC), etc. Ainsi, pour éviter des problèmes d’évolutivité, VPLS doit
être capable de gérer un très grand nombre d’adresses MAC.
Un équipement CE est relié à un routeur PE, situé dans le réseau de l’opérateur.

Il doit apprendre les adresses MAC provenant des commutateurs et des routeurs
connectés, et doit établir ou terminer les tunnels de données dans l’infrastructure
MPLS.

Le service est transparent pour le client. Il peut envoyer tout type de trafic
sans avoir recours à l’opérateur. Une fois la connexion entre les PEs est établie,
l’instance VPLS d’un PE est prête à recevoir des trames Ethernet d’un site client,
et peut commuter ces trames sur le LSP (Label Switched Path) approprié en
fonction de l’adresse MAC destination. Cela est possible, car VPLS permet au
routeur PE d’agir comme un commutateur Ethernet avec une table d’adresses
MAC par instance VPLS. En d’autres termes, l’instance VPLS sur le routeur
PE dispose d’une table MAC alimentée par apprentissage des adresses MAC
sources, lorsque les trames Ethernet entrent par des ports physiques ou logiques
spécifiques, exactement de la même façon qu’avec un commutateur Ethernet
traditionnel.
Une fois que la trame Ethernet arrive par un port d’entrée connectant le
client, l’adresse MAC destination est comparée dans la table MAC et la trame
est transmise sans altération (si, bien sûr, l’adresse MAC correspondante se
trouve dans la table MAC) à l’intérieur du LSP qui va la délivrer au PE adéquat
connectant le site distant visé. Si l’adresse MAC n’est pas connue, la trame
Ethernet est répliquée et transmise à tous les ports logiques associés à cette
instance VPLS, excepté le port d’entrée par lequel la trame est arrivée. Une fois
que le PE reçoit en retour une trame de la machine qui détient cette adresse
MAC, la table MAC est mise à jour dans le PE. Les adresses MAC n’ayant pas
été utilisées après un certain temps sont automatiquement éliminées de la table,
exactement comme sur un commutateur Ethernet.
2.1.1.3 Avantages du L2VPN
Nous définissons un Layer 2 VPN comme une situation où un fournisseur

de services fournit un réseau de couche 2 au client. Pour autant que le client est
concerné, ils ont (par exemple) des circuits Ethernet connectant les différents
sites ; chaque CE est configuré avec un port par lequel communiquer avec d’autres
CEs. Au sein du réseau du fournisseur de services, cependant, les paquets de
couche 2 sont transportés à l’intérieur des tunnels. Le fournisseur de services ne
participe pas à la couche 3 du réseau du client, en particulier dans le routage ; ce
qui entraîne de nombreux avantages au fournisseur de service dans son ensemble
et aux routeurs PEs en particulier.

Nous présenterons sur quelques points les avantages du L2VPN.
Dimensionnement
Le dimensionnement des services L2VPN est beaucoup plus simple que
celui des L3VPN. Chaque routeur PE a seulement besoin de connaître les autres
routeurs PEs afin d’établir avec eux les circuits virtuels pour construire le réseau
privé virtuel désiré.
Déploiement
Les services L2VPN utilisent des équipements PEs simples. Les opérateurs
qui n’ont pas implémenté BGP ou qui n’ont pas l’intention de déployer BGP
pour offrir les services des réseaux virtuels privés à leurs clients opteront pour la
solution L2VPN.
Gestion et maintenance
La gestion des L2VPNs est beaucoup plus simple que celle des L3VPNs.
L’opérateur ne gère pas les routes des clients. Ces derniers doivent gérer la distri-
bution de leurs routes et échanger le trafic avec les autres équipements CEs. Étant
donné que l’utilisation du protocole BGP n’est pas indispensable, la gestion et le
dépannage (troubleshooting) ne seront pas des opérations compliquées. Même
si les opérateurs utilisent le protocole BGP pour effectuer la signalisation, la
gestion des L2VPNs requiert simplement la manipulation des circuits viruels. De
plus, pour chaque routeur PE, les ingénieurs s’occupent seulement d’une seule
table de routage.
Type de traffic transporté

Les services L2VPN offrent le transport de tout trafic de niveau 3 : IPv4, IPv6,
IPX, DECNet, etc. En utilisant les services L2VPN, les compagnies, qui utilisent
des protocoles différents de IP, ont moins de restrictions. D’autre part, plusieurs
organisations ont déjà commencé à migrer vers IPv6. Pour continuer à offrir la
connectivité à ces organisations, l’utilisation des services L3VPN nécessitera
d’apporter des modifications au standard actuel. Par contre les services L2VPN
continueront à leur offrir la connexion même si le réseau de l’opérateur n’as pas
été mis à jour pour supporter IPv6.

Evolutivité des PEs

Dans les VPNs de couche 2, chaque PE a seulement besoin de maintenir une
petite partie de l’information de chaque CE dans chaque VPN et de garder une
seule route à chaque site dans chaque VPN. Cela signifie que la transmission de
l’information de base et la routage de l’information de base évoluent bien avec
le nombre de sites et le nombre de VPN. En outre, les propriétés d’évolutivité
sont indépendantes de la clientèle.
Ceci est contraire avec les VPNs de couche 3, dans laquelle chaque CE dans
un VPN peut avoir un nombre quelconque de routes qui doivent être transportés
par le fournisseur de service. Deux problèmes se posent donc. Premièrement,
l’information stocké au niveau de chaque PE et le nombre de routes installées
par le PE pour un CE dans un VPN peut être illimitée, ce qui signifie dans la
pratique qu’un PE doit limiter lui-même les installations des routes associés aux
VPNs dont il est membre. Deuxièmement, un CE peut envoyer un grand nombre
de routes à son PE, ce qui signifie que le PE doit lui-même encore se protéger de
cela. Ainsi, le fournisseur de service doit imposer des limites sur le nombre de
routes acceptées à partir d’un CE ; celui-ci, à son tour, exige au routeur PE de
s’assurer de ce contrôle.
Routage multidiffusion
Le support de la multidiffusion IP sur les VPNs de couche 3 basés sur MPLS
n’est pas encore documenté. Dans le cas du VPN de couche 2, les routeurs
CEs effectuent directement le routage multicast d’origine. Le réseau cœur du
SP fournit juste les canaux pour relier les routeurs CEs ; si les routeurs CEs
exécutent le multicast IP ou l’unicast IP ou un autre protocole de réseau, cela est
sans rapport avec les routeurs du SP.
2.2 Généralité sur VPLS

2.2.1 Origine
A l’origine, pour satisfaire la demande des entreprises d’interconnecter leurs
différents sites sur de grandes distances, tout en assurant une bonne qualité de
service, des lignes dédiées étaient utilisées. Mais les lignes dédiées ne permet-

taient pas d’interconnecter un grand nombre de sites. De plus, le déploiement de

ces réseaux est difficile à effectuer et le coût est élevé.
Avec l’émergence du mode de transfert asynchrone (Asynchronous Transfert

Mode (ATM)) et du Frame Relay, les fournisseurs de services se sont tournés
vers eux pour fournir des circuits virtuels. Ainsi, avec ces nouvelles méthodes,
les entreprises pouraient établir leur propres réseaux de couche 3 pour IP ou le
trafic IPX basé sur des circuits virtuels. Cependant, les liens virtuels sont des
liens point à point de couche 2, qui rendent les réseaux difficiles à configurer et
à entretenir, surtout quand un nouveau site est déployé.
Plus tard, après le déploiement des réseaux IP presque partout dans le monde,
les fournisseurs de services ont commencé à penser à la façon de fournir des
services de réseaux privés à faible coût, en utilisant les réseaux IP existants.
La technologie MPLS (Multi-Protocol Label Switching) VPN a été développée
pour répondre à cette demande (HUAWEI, 2012). Cette technologie est facile
à configurer et permet aux fournisseurs de service de changer facilement les
paramètres de QoS.
La technologie MPLS VPN se répartit en deux catégories : MPLS L3VPN

et MPLS L2VPN. Les services MPLS L3VPN exigent que les fournisseurs de
services gèrent les routes internes sur les réseaux d’utilisateurs. La technologie
MPLS L2VPN (VLL - Virtual Leased Line) fournit des services point à point
VPN de couche 2 sur les réseaux publics. Les liens virtuels VLL permettent aux
sites de communiquer comme s’ils étaient directement reliés par un lien, mais
VLL prend uniquement en charge l’échange point à point.
Virtual Private LAN Service est basé sur la technologie VLL, mais permet
une connectivité multipoint à multipoint.
2.2.2 Définition
VPLS est un service VPN de couche 2. Toutefois, dans le cas de VPLS,
les clients dans le VPN sont reliés par un réseau local Ethernet multipoint,
contrairement aux autres VPNs couche 2, qui offrent une connexion point à
point. VPLS fournit un service Ethernet qui peut s’étendre sur une ou plusieurs
régions métropolitaines, fournissant la connectivité entre plusieurs sites comme

si ces sites avaient été connectés au même réseau local Ethernet. VPLS utilise
l’infrastructure d’un réseau commuté (par exemple IP/MPLS) pour servir de pont
entre les réseaux LAN (Ethernet, Frame Relay,...) et fournit des services basés
sur la couche 2 (Ethernet). VPLS permet le transport des trafics Ethernet 802.3,
VLAN 802.1q, et VLAN-in-VLAN (Q-in-Q) à travers plusieurs sites appartenant
au même domaine broadcast de couche 2. Un LAN est donc émulé et permet de
délivrer un domaine broadcast permettant les fonctionnalités de niveau 2 comme
l’apprentissage et le transfert de trame basés sur les adresses MAC.
Du point de vue du service client, tous les sites qui appartiennent au même
VPLS se voient comme appartenant au même LAN. L’application destinée à
l’utilisateur final peut être divisée en deux catégories suivantes :
• la connectivité entre les routeurs du client : application de routage LAN
• la connectivité entre les commutateurs Ethernet du client : application de

commutation LAN
La technologie des LANs traite des trames broadcast, multicast et unicast à

destination inconnue, la technologie MPLS ne permettant pas nativement de
remplir ce service, de nouvelles extensions sont définies avec l’apparition de
nouvelles fonctions sur le routeur PE VPLS : apprentissage des adresses MAC,
inondation (incluant la fonction de réplication) et « MAC aging » (David Jacquet,
2009).
Dans VPLS, deux principales méthodes différentes et non compatibles existent

pour réaliser le plan de contrôle VPLS : LDP et BGP. Toutes deux permettent
d’établir, de supprimer et de maintenir les pseudowires reliant les tables d’adresses
MAC par client (VSI).
Pour régler les problèmes d’évolutivité (en termes de signalisation à mettre

en œuvre sur les routeurs VPLS), des architectures permettent de simplifier ces
aspects comme l’auto-découverte par BGP ou H-VPLS.
De plus, des mécanismes améliorent le fonctionnement de VPLS sur plusieurs

points (comme la résilience, la supervision ou la sécurité ) et des techniques
permettent l’utilisation de VPLS dans des contextes d’inter domaines ou d’inter
AS.

2.2.3 Cas d’utilisation de VPLS

VPLS permet aux opérateurs de service de fournir plusieurs types de services
de couche 2 à travers un WAN. Plusieurs domaines VPLS peuvent exister sur une
même infrastructure physique permettant la convergence de plusieurs services
comme la vidéo, le VoIP, la télévision diffusée, etc dans un domaine et d’autres
solutions réseaux tels que la mise en place d’un cluster dans un centre de données,
etc.
2.3 Protocoles et Architectures de VPLS

2.3.1 Plan de contrôle de VPLS
Le plan de contrôle de VPLS est constitué de deux fonctions principales :
la découverte (découverte automatique) et la signalisation (établissement et
destruction des Pseudowires qui constituent VPLS). Le plan de contrôle permet
de mettre en place le service VPLS.
2.3.1.1 Découverte automatique

La découverte réfère au processus qui permet d’identifier tous les PEs qui
sont dans une instance VPLS donnée. Un PE peut soit être configuré avec
l’identité de tous les autres PEs dans un VPLS donné ou peut utiliser un protocole
pour retrouver tous les autres PEs. La dernière option est appelée découverte
automatique. La découverte automatique permet aux opérateurs de déployer
VPLS à une grande échelle.
A part le fait que la découverte soit automatique ou non, on peut trouver deux
types de mécanismes de découverte. Les mécanismes "distribués" qui résident
dans les périphériques réseau et les mécanismes "centralisés" que les équipe-
ments réseau interrogent pour connaître les associations VPN. Les mécanismes
"distribués" tel que BGP nécessitent que sur chaque périphérique réseau, une
association VPLS soit configurée, laquelle association sera annoncée par le mé-
canisme de découverte aux autres périphériques. Les mécanismes "centralisés"
tels que DNS (Dynamic Name Service), RADIUS, exigent que les équipements
réseaux questionnent les serveurs centralisés pour avoir connaissance des asso-
ciations VPLS.

Les mécanismes "distribués" sont les plus utilisés et souhaités.

Chacun de ces mécanismes présente des avantages et des inconvénients. Nous
nous interesserons dans la suite seulement à BGP et au méthode statique.
Le fonctionnement du mécanisme DNS, comme mécanisme de découverte de

VPLS est défini dans le draft draft-heinanen-dns-l2tp-vpls-01.txt (Juha Heinanen,
2004) et le fonctionnement de RADIUS, comme mécanisme de découverte de
VPLS est défini dans le draft draft-heinanen-radius-pe-discovery-04.txt (Heina-
nen Juha, 2003).
Configuration statique
La configuration statique ou configuration manuelle nécessite que chaque
PE associé à une instance VPLS soit configuré comme un pair. Cette solution
ne permet pas l’évolutivité, puisqu’une configuration manuelle est nécessaire
à chaque fois qu’une instance VPLS ou un nouveau PE est ajoutée, modifiée
ou supprimée. Pour chaque instance VPLS présente dans un PE, l’opérateur
doit configurer le nouveau PE avec les adresses de tous les PEs faisant partie du
même domaine VPLS. Cette configuration manuelle est souvent source d’erreur.
Cependant, comme les paires sont configurées manuellement, la sécurité et la
flexibilité pour signaler les attributs supplémentaires tels que les profils de bande
passante de la solution, sont assez robustes ; car les informations ne sont pas
reçues automatiquement.
Configuration BGP
BGP exige qu’un PE associé à un VPLS particulier soit configuré selon un
processus BGP. BGP annonce alors l’appartenance à un VPLS en utilisant les
NRLIs (Network Layer Reachability Information) décrits dans les RFC4761 et
4364, qui fournit un mécanisme évolutif pour la distribution de l’appartenance
à un VPLS. Cependant, comme BGP est essentiellement un mécanisme de
diffusion, par défaut, la sécurité de la solution peut être très faible à moins, que
des mécanismes spécifiques tels que les filtres soient mis en oeuvre.
2.3.1.2 Signalisation
Une fois la découverte effectuée, chaque paire de PEs dans un VPLS doit
être capable d’établir (de détruire) des pseudowires et lier un pseudowires à un

VSI particulier. Ce processus est appelé la signalisation. La signalisation est

également utilisée pour transmettre certaines caractéristiques des Pseudowires,
qu’un PE met en place pour un VPLS donné.
Chaque routeur PE doit pouvoir maintenir plusieurs VSI (une par domaine
VPLS) qui contiennent seulement les adresses MAC d’un client. Les VSI de
chaque routeur PE sont reliées par des pseudowires pour que chacune apprennent
les adresses MAC clientes stockées par les autres VSI. Les VSI sont aussi reliés
aux circuits d’attachement (pour relier les sites clients donc les adresses MAC
apprises localement).
Dans l’IETF, deux soluions ont été décrites pour la signalisation des PWs
entre les PEs : une qui décrit l’utilisation de BGP (Border Gateway Protocol)
décrit dans la RFC4761 proposée par Kireeti Kompella et Rekhter Y., comme
protocoles de signalisation et l’autre qui décrit LDP (Label Distribution Protocol)
décrit dans la RFC4762 proposée par Marc Lasserre et Vach Kompella.
Processus d’établissement des pseudowires

Les pseudowires peuvent être point à point, multipoint à point ou point à
multipoint. Les PWs multipoint à point peuvent être utilisés seulement quand
le PE recevant la trame n’a pas besoin de déduire, du PW par lequel la trame a
été reçue, l’identité de l’AC d’entrée de la trame. Les PWs point à multipoint
peuvent être utilisés quand les trames ont besoin d’être multi-diffusées.
Le pseudowire peut être établi sur un tunnel MPLS (tunnel LSP) ou un tunnel
GRE ou un tunnel IPSec. Pour établir un PW, il faut effectuer les configurations
suivantes (comme exemple PEa établi un PW avec PEb) :
• établir un tunnel MPLS ou GRE entre PEa et la paire PEb ;
• déterminer l’adresse de la paire PEb. Si la paire PEb est dans le même VSI
que PEa, il faut spécifier l’adresse de la paire PEb manuellement ou laisser
le protocole de signalisation trouver la paire PE automatiquement ;
• utiliser comme protocole de signalisation LDP ou BGP pour attribuer les

labels et annoncer les labels attribués à la paire de PEb.

LDP (Label Distribution Protocol)

La RFC4762 décrit l’utilisation de LDP comme protocle de signalisation de
VPLS. Un maillage complet (full mesh) des sessions LDP est utilisé pour établir
le maillage des PWs. L’exigence d’un maillage complet de PWs entraine la mise
en place d’un grand nombre de sessions LDP ciblées. En outre, il existe une
topologie qui permet de minimiser la taille du maillage complet, la topologie
H-VPLS que nous présenterons dans la suite. Une fois qu’une session LDP est
formée entre deux PEs, tous les PWs entre ces deux PEs sont signalés à travers
cette session.
Dans la RFC4447, deux types de FECs 1 (Forwarding Equivalence Class) sont

décrits pour l’échange des informations du plan de contrôle : la FEC 128 (le PW
ID FEC Element) et la FEC 129 (le Generalized PW ID FEC Element). La FEC
128 nécessite une configuration synchrone des deux extrémités (sur les PEs) et
donc le même identifiant PW (PW ID) est configuré entre les deux PEs dans
chaque direction. Quant à la FEC 129, elle permet une configuration unique sur
chaque extrémité. La FEC 128 est historiquement la première implémentée (car
la seule normalisée initialement), son rôle reste restreint car elle ne permet que
les annonces et le maintien des labels PW. La FEC 129 (normalisée un peu plus
tard) supprime la contrainte d’avoir le même identifiant PW à chaque extrémité
et elle permet une configuration automatique des pseudowires ; ce procédé est
détaillé dans la RFC6074 (Rosen E. et al, 2011).
Les informations échangées par LDP nécessaire pour établir un pseudowire
sont :
• définition du PW = couple <adresses loopback ; identifiant du PW > ;
• le type de pseudowire (Ethernet, Ethernet VLAN) ;
• le label PW qui sera utilisé par le plan de transfert du PE qui le recevra.
La FEC 129 (0x81) est structurée comme suit et illustrée dans la figure 2.5 :
• le bit de contrôle (C) : Ce bit est utilisé pour signaler l’utilisation du mot de
contrôle ;
1. Une FEC (Forwarding Equivalent Class) est un ensemble de paquets à router de façon unique (par exemple
ayant la même destination).

• le type de PW : valeur qui représente le type de pseudowire, dans notre cas

soit Ethernet, soit Ethernet VLAN ;
• la taille de l’information dans le PW ;
• l’identifiant d’attachement de groupe (AGI- Address Group Identifier) :

c’est l’identifiant du VPLS ;
• l’identifiant source et distant d’attachement individuel (respectivement

SAII (Source Attachment Individual Identifier) et TAII(Target Attachment
Individual Identifier)) : ces valeurs sont nulles car dans un VPLS, les
pseudowires se terminent dans les tables de MAC adresses. Ces valeurs
sont utilisées par VPWS ou pour de futurs développements.
F IGURE 2.5: FEC 129
Les paramètres d’interface (figure 2.5) :
• le sous TLV de paramètre d’interface (qui est optionnel) permet d’échan-

ger des paramètres spécifiques comme par exemple la MTU du circuit
d’attachement ;
• MTU : le MTU (Maximum Transmission Unit) du VPLS doit être le même

sur tous PWs dans le maillage ;
• VLAN ID demandé : Si le type de PW est le mode Ethernet, ce paramètre

peut être utilisé pour signaler l’insertion VLAN ID approprié.
Il peut être utile de pouvoir supprimer une adresse MAC dans une VSI de
manière dynamique pour accélérer la convergence. Le PE concerné le réalise
grâce à l’envoi d’un message T-LDP withdraw avec la liste des adresses MAC

à supprimer à tous les PEs distants appartenant au VPLS. Un nouveau TLV est
créé pour introduire un TLV de liste MAC, qui est optionnel. La procédure à
suivre lorsqu’un TLV de liste MAC est reçu est de supprimer l’association entre
l’adresse MAC et l’attachement circuit ou le pseudowire associé.
BGP (Border Gateway Protocol)

Comme décrit dans la RFC4761, le plan de contrôle BGP de VPLS dispose
des foncions de l’auto-découverte et de la signalisation. La solution MP-BGP
(Multiprotocol BGP) utilise des messages update pour envoyer aux autres PE les
informations VPLS. Un ensemble de NLRI est envoyé dans chaque paquet update
BGP. Un NLRI est un ensemble de préfixes ayant les mêmes attributs. BGP basé
sur VPLS utilise les NLRIs pour que les routeurs PEs échangent les informations
VPLS (le VPLS ID, les sites ID, les labels utilisés, le type d’encapsulation, la
présence du mot de contrôle, le besoin ou non de séquencement, la MTU...).
L’utilisation du protocole MP-BGP présente l’avantage de pouvoir utiliser les
fonctionnalités liées à ce protocole tels que :
• les mécanismes d’auto-découverte et de pré-provisionnement (qui per-

mettent de préparer à l’avance et de manière dynamique, l’ajout de nou-
veaux sites) ;
• l’utilisation des Routes Reflector pour améliorer l’évolutivité (le RR doit

être compatible VPLS).
Une fois que la découverte est réalisée, chaque paire de routeurs PE va établir
un pseudowire par l’échange de labels PW grâce au protocole MP-BGP. Pour
cela, un nouveau NLRI est défini : L2VPN AFI = 25 et VPLS SAFI = 65. Ce
NLRI contient les informations à échanger entre les routeurs PE :
• l’identifiant du VPLS ;
• l’identifiant du PE source ;
• le type d’encapsulation (pour VPLS égal à 19) ;
• un drapeau de contrôle (utilisation du mot de contrôle, séquencement) ;
• le label à utiliser.

2.3.2 Plan de données de VPLS

Le plan de données consiste à décrire la façon dont le trafic client est ache-
miné par les routeurs. Il conviendra de savoir comment les trames clientes sont
encapsulées pour être transmises par les routeurs PE et P jusqu’à leur destination.
Il comprend plusieurs fonctions à savoir : l’encapsulation et la transmission des
paquets. Nous allons décrire comment ce trafic est acheminé d’un bout à l’autre
du réseau MPLS.
Encapsulation
Ici nous présenterons brièvement comment les trames clientes sont encap-
sulées pour être transmises par les routeurs PE et P jusqu’à leur destination.
L’encapsulation des paquets VPLS est décrit dans la RFC4448, et cette section
se base sur elle. Trois couches sont utilisés pour l’encapsulation des PWs :
• le tunnel d’encapsulation : le label au niveau de cette couche est le label

du tunnel PSN dont le nombre peut varier entre 0 et plusieurs. Ces labels
sont appris localement (de voisin à voisin) par chaque routeur P adjacent.
Ce sont donc ces routeurs qui se transmettent les informations de proche
en proche. Ce label indique comment joindre le routeur PE de destination
ou PE de sortie de la trame cliente, c’est-à-dire le dernier routeur du réseau
MPLS avant que la trame cliente ne soit restituée.
• pseudowire démultiplexeur (label PW ou VC 2 label) : les labels PW doivent

être échangés entre les routeurs PEs. Ce label permet au PE de destination
(le dernier avant le client) de savoir vers quel circuit d’attachement (donc
vers quelle interface ou sous-interface) la trame cliente doit être transmise.
• le mot de contrôle : Le mot de contrôle (4 octets) est spécifique à l’encapsu-

lation L2VPN. En Ethernet il est optionnel, mais il peut être utilisé pour
d’autres applications avancées.
Le transfert d’une trame cliente dans un réseau VPLS se fait en deux étapes
(que l’adresse MAC destination soit connue ou non dans la VSI)(Martini L.
et al, 2006 RFC4448). Le PE d’entrée envoie la trame au PE destination. Le
PE destination envoie cette trame vers le client. Les labels MPLS sont utilisés
2. Virtual Circuit

pour effectuer cet acheminement via des tunnels LSP : un pour atteindre le PE
destination (tunnel label ici label MPLS), l’autre pour le choix du site client
connecté au PE destination (label PW). Les trames clientes Ethernet arrivant sur
l’interface d’entrée du PE sont donc encapsulées de la manière suivante :
• ajout d’un mot de contrôle (optionnel en Ethernet) ;
• en-tête MPLS correspondant au label du pseudowire ;
• en-tête MPLS correspondant au label du tunnel PSN (label MPLS).
Seuls les routeurs PE VPLS (donc en bordure du réseau MPLS) connaissent

les adresses MAC qui sont stockées dans leur VSI. Les équipements P n’ont pas
connaissance du trafic qu’ils commutent : ils se basent uniquement sur le label
PSN pour acheminer le paquet vers le PE de sortie (en utilisant le tunnel PSN).
Ce dernier, grâce au pseudowire label va pouvoir transférer le paquet vers la
bonne interface. La figure 2.6 illustre le processus d’encapsulation des paquets
de VPLS.
F IGURE 2.6: Encapsulation VPLS (David JACQUET, 2009)

Transmission des paquets VPLS

Les paquets VPLS sont classés comme appartenant à une instance VPLS et
associés à une table d’acheminement basé sur l’interface sur laquelle le paquet
est reçu. Les paquets sont transmis selon l’instance et basé sur l’adresse MAC de
destination. Le premier mappage est déterminé par la configuration (K. Kompella
et Y. Rekhter, 2007).
Apprentissage des adresses MAC

Le réseau cœur sert de pont virtuel (un par VPLS donc un par client ou
service). Chaque routeur PE (les équipements situés en extrémité du réseau
MPLS) maintient une FIB (Forwarding Information Base) d’adresses MAC par
VPLS, qui est appelé VSI.
Cette VSI associe une adresse MAC de destination avec une interface. Cette
interface peut être :
• soit virtuelle : donc associée à un pseudowire (pour atteindre un site relié à

un routeur PE distant) ;
• soit logique ou locale : donc associée au site client connecté localement.
L’apprentissage des adresses MAC dans les VSIs des équipements PEs est
basé sur les trames client. L’alimentation et la mise à jour de ces tables sont
réalisées de manière dynamique. Lorsqu’un PE reçoit un paquet provenant d’un
site client, il va parcourir sa VSI pour savoir si l’adresse MAC destination est
connue. S’il la connaît, il va alors l’envoyer vers l’interface correspondante. S’il
ne la connaît pas, il doit faire appel au mécanisme d’apprentissage MAC.
Apprentissage qualifiés et non qualifiés

Le type d’apprentissage est déterminé par la clé qu’elle utilise. Lorsque la
clé de l’apprentissage est une adresse MAC on parle de «l’apprentissage non
qualifié ». Dans le cas où la clé d’apprentissage comprend l’étiquette VLAN on
parle de «l’apprentissage qualifié».
Dans le cas des VPLS, l’apprentissage se fait dans le contexte d’une instance
VPLS, ce qui correspond typiquement à un client. Si le client utilise des éti-
quettes VLAN, on peut faire les mêmes distinctions de l’apprentissage qualifié

et non qualifié. Si la clé de l’apprentissage au sein d’un VPLS est simplement

l’adresse MAC, alors ce VPLS opère sous l’apprentissage non qualifié. Si la clé
de l’apprentissage est (étiquette VLAN du client + adresse MAC), alors ce VPLS
opère sous l’apprentissage qualifié.
Choisir entre l’apprentissage qualifié et non qualifié implique plusieurs facteurs,

le plus important est de savoir si on veut un seul domaine de diffusion générale
(non qualifié) ou d’un domaine de diffusion par VLAN (qualifié). Ce dernier fait
des inondations et de la diffusion plus efficace, mais nécessite de plus grandes
tables MAC.
Inondations des adresses MAC

L’un des attributs du service Ethernet est que les trames envoyées à des
adresses de diffusion et à des adresses MAC inconnues sont inondées (envoyées)
vers tous les ports. Pour accomplir cette inondation dans le réseau du fournisseur
de service, toutes les trames unicast, broadcast et multicast de destination incon-
nue sont inondées sur les PWs correspondants à tous les nœuds PE participants
dans le VPLS, ainsi qu’à tous les ACs.
Lorsqu’un PE reçoit ainsi une trame, il va lui aussi parcourir sa VSI et si

l’adresse MAC destination n’est toujours pas connue, il inondera ses sites clients
(appartenant à ce VPLS) par l’intermédiaire de ses circuits d’attachement. De
cette manière, la trame cliente Ethernet arrivera forcément à destination.
Split Horizon
Quand un PE capable d’inondations (nommons PEx) reçoit une trame Ether-
net de diffusion, ou avec une adresse MAC de destination inconnue, il doit
inonder la trame. Si la trame est arrivée d’un CE qui lui est connecté, PEx doit
envoyer une copie de la trame à tous les autres CEs dans le même domaine
VPLS, ainsi qu’à tous les autres PEs participant au VPLS. Si, d’autre part, la
trame est arrivée d’un autre PE (nommons PEy), PEx doit envoyer une copie du
paquet seulement aux CEs attachés. PEx ne doit pas envoyer la trame à d’autres
PEs, puisque PEy l’aurait déjà fait. Cette notion a été appelée transmission "split
horizon" et est une conséquence du maillage logique des PEs dans VPLS.

Les règles de transmission Split horizon sont appliquées aux paquets de diffu-
sion et de multidiffusion, ainsi que des paquets à une adresse MAC inconnue.
Age d’une association d’adresse MAC (MAC Aging)

Les PEs VPLS doivent avoir un mécanisme de durée de vie pour suppri-
mer une adresse MAC associée à un port logique. Ceci est nécessaire afin que
l’adresse MAC puisse être apprise de nouveau si elle «se déplace» d’un port
logique à un autre port logique, soit parce que la station à laquelle cette adresse
MAC appartient vraiment est supprimée ou en raison d’un changement de topo-
logie dans le LAN qui cause le fait que cette adresse MAC arrive sur un nouveau
port. En outre, le vieillissement ou durée de vie réduit la taille d’une table MAC
VPLS pour seulement les adresses MAC actives, au lieu de toutes les adresses
MAC dans ce VPLS.
L’«âge» d’une source adresse MAC S sur un port logique P est le temps depuis
lequel il a été vu la dernière fois, en tant que adresse MAC source sur le port
P. Si l’âge dépasse le temps de vieillissement T, S doit être supprimé de la FIB.
Cela signifie bien sûr que chaque fois que S est considéré comme une adresse
MAC source sur le port P, l’âge de S est réinitialisée.
2.3.3 Architecture VPLS

Les documents actuels du groupe de travail VPLS décrivent deux archi-
tectures de base, une architecture plate non hiérarchique et une architecture
hiérarchique. D’autres architectures sont également implémenter tels que la
connectivié Hub&Spoke et l’architecture PBB 3 VPLS (Provider Backbone Brid-
ging), qui se basent sur les mêmes concepts que H-VPLS. Le PBB VPLS est
décrit dans la RFC7080.
2.3.3.1 Architecture Plate

Cette architecture est décrite dans la RFC4762. Cette architecture convient
pour les simples et petites implémentations. Un maillage complet des sessions
LDP est nécessaire. Pour n routeurs n-PEs il faut n(n-1)/2 PWs. C’est une
3. PBB fournit des solutions extrêmement évolutives pour les services de transport Ethernet. PBB est introduit
dans le service Virtual Private LAN Service (VPLS) pour améliorer l’évolutivité des solutions VPLS.

architecture qui ne favorise pas une évolutivité et une évolutivité hiérarchique.

La signalisation et la replication des paquets sont surchargées.
2.3.3.2 HVPLS
Pour remédier aux limitations d’évolutivité (en terme de d’agrandissement
du réseau) au sein de l’architecture VPLS plat, les RFCs 4761 et 7361 ont
décrit le concept de l’architecture d’un VPLS hiérarchique (H-VPLS) . H-VPLS
décrit une architecture qui utilise une architecture de commutation distribuée
qui est constituée de domaines de bords interconnectés au moyen d’un noyau
MPLS. Cette architecture hiérarchique permet la plus grande flexibilité en termes
d’options de déploiement et l’économie du réseau. Elle réduit la complexité
logique du maillage complet et la complexité des configurations.
H-VPLS introduit les notions de routeurs u-PE (User facing Provider Edge)
et n-PE (Network Provider Edge). Les routeurs u-PEs sont des routeurs PEs face
à l’utilisateur, tandis que les routeurs n-PEs sont des routeurs PEs face au réseau.
La hiérarchie offre les avantages d’une signalisation plus basse dans le réseau
coeur MPLS et une plus basse réplication de paquets sur les routeurs n-PE. Les
routeurs u-PE jouent un rôle d’agrégation (assemblage) et font de la réplication
de paquets et l’apprentissage des adresses MAC.
Les PWs du noyau VPLS (hub) sont complétés avec les PWs d’accès (spoke)
pour former un H-VPLS à deux niveaux. Pour chaque service VPLS, un seul
spoke-PW est configuré entre les équipements u-PE et n-PE. Contrairement
aux traditionnels PWs qui se terminent sur un port physique ou logique, un
spoke-PW se termine sur un VSI sur u-PE et n-PE. Les u-PEs et n-PEs traitent
chaque connexion spoke comme un AC d’un service VPLS. Le label PW est
utilisé pour associer le trafic du spoke-PW à une instance VPLS. Le spoke-PW
est traité comme un port virtuel, et le n-PE commute donc le trafic client entre le
spoke-PW, le hub-PW et les ACs lorsqu’il apprend une adresse MAC. Il n’y a pas
de « split-horizon » entre les spoke-PWs ni entre un spoke-PW et un hub-PW ;
par contre, un « split-horizon » s’effectue entre les hub-PWs pour éviter les
boucles ou l’utilisation d’un STP 4 (Spanning Tree Protocol). L’apprentissage
MAC complet peut être désactivé sur les u-PEs . Ainsi seul le n-PE aura la
4. STP est un protocole qui permet de faire la prévention des boucles

connaissance de toutes les adresses MAC de tous les CEs appartenant au VPLS,
alors que les u-PEs n’auront que la connaissance des adresses MAC apprises
localement via leur propre AC.
2.4 Fonction avancées

2.4.1 Inter AS et Inter domaine
Que faire si deux sites d’un VPLS sont connectés à différents systèmes
autonomes (par exemple, parce que les sites sont reliés à différents SP) ?
Les routeurs reliant les AS sont appelés « routeur de bordure d’AS » (ASBR).
C’est le point névralgique.
Plusieurs solutions existent en L2VPN en faisant un parallèle avec la termi-
nologie des solutions L3VPN :
• Méthode a : Connections VPLS à VPLS par les ASBRs ;
• Méthode b : Redistribution EBGP des informations VPLS entre les ASBRs ;
• Méthode c : Redistribution EBGP Multi-hop des informations VPLS entre

les ASes.
Les trois solutions sont classées selon leur évolutivité. La méthode c est la plus
évolutive. Ces solutions sont décrites dans les RFC4761 et RFC4364.
2.4.2 Sécurité
Un service VPLS est vulnérable à certains problèmes de sécurité qui pré-
sentent des risques pour les réseaux des clients et des fournisseurs. La plupart des
questions de sécurité peuvent être évitées grâce à la mise en œuvre de dispositifs
de protection appropriés. Deux aspects doivent être pris en compte pour assurer
la sécurité dans VPLS : sécuriser le plan de contrôle et protéger les chemins de
transmission.
Contrairement à VPWS, VPLS peut rencontrer des problèmes de sécurité liés

au fait que le plan de données est basé sur les adresses MAC clientes. Ainsi,
un risque de conflit d’adresses MAC est toujours possible. Une adresse est
considérée comme unique, excepté en cas d’intrusion malveillante où il faut
pouvoir la refuser et ne pas l’enregistrer dans la VSI VPLS.

Dans certaines architectures VPLS, la communication entre clients directement

par le même routeur PE peut être prohibée. En effet, il est possible de désactiver
la communication utilisateur-utilisateur par la création d’un « split-horizon »
entre les circuits d’attachement de la VSI, et un « split-horizon » entre les
pseudowires spokes.
Quelques fonctions, plus ou moins classiques dans le domaine Ethernet, liées

notamment aux adresses MAC, peuvent être appliquées au VPLS pour apporter
un minimum de sécurité aux tables MAC. Ces fonctions sont :
• âge d’une association MAC (MAC aging) ;
• limitation de la taille des VSIs ;
• la fonction MAC anti-moving ;
• limitation des flux de diffusion ;
• filtrage.
Comme nous l’avions dit la section 2.3.2, la fonction MAC Aging permettra de
désengorger les VSIs des adresses MAC plus vielles qui n’ont pas été utilisées.
Ainsi, la taille des VSIs construites par l’apprentissage MAC n’augmente plus
indéfiniment.
Une autre solution permettant de mieux gérer la taille des VSIs sur les routeurs
PE est de limiter le nombre d’adresse MAC par client (VPLS), donc pour chaque
VSI. Chaque client a donc une table d’adresse MAC déterminée sur chaque
routeur PE (elle est ensuite mise à jour par des délais ou par apprentissage).
Le MAC anti-moving (interdiction d’avoir des duplications d’adresses MAC

dans une même VSI) est une fonction qui suit la règle suivante : lorsqu’une
adresse MAC est apprise par un port, alors elle ne doit pas être autorisée à être
apprise par un autre port, que celui-ci soit physique (circuit d’attachement) ou
virtuel (pseudowire).

La limitation des flux de diffusion (soit en nombre de trame, soit en termes de

bande passante) permet d’éviter la saturation d’un lien par l’effet croissant du
trafic (diffusion provenant de l’inondation VPLS ou bien une diffusion cliente).
En effet, des trames broadcast partant d’un routeur PE à destination d’autres
routeurs PE appartenant au même VPLS, peuvent emprunter le même lien
physique (P-P) et donc saturer ce lien. La définition d’un certain seuil sur le PE
d’origine de ces flux peut donc permettre de limiter cet effet.
L’application de filtres sur les trames peut soit supprimer les trames incrimi-
nées, soit limiter le débit. Ce filtre peut être fait sur différents critères selon les
besoins.
2.4.3 Multi-hébergement
Lors de la fourniture des services aux entreprises il est souvent demandé
au fournisseur de service de mettre en place une connectivité redondante entre
un ou plusieurs sites c’est-à-dire le connecter à plusieurs PEs peut être même
dans différents ASes. Ce phénomène est appelé Multi-hébergement (ou Multi-
homing). Dans le cas d’un service VPLS, le fournisseur de services doit veiller à
ce que cet accès redondant multi-homed fournisse une topologie sans boucle pour
protéger à la fois le réseau du client et l’infrastructure du réseau du fournisseur de
services. La spécification VPLS multi-homing détaillée dans le draft-ietf-l2vpn-
vpls-multihoming (Kothari B.et al, 2014), fournit une solution multi-homing
basée sur BGP qui est applicable à la fois sur les technologies BGP-VPLS et
LDP-VPLS, et dans le cas de LDP-VPLS peut être utilisé sans l’utilisation de la
solution BGP-AD (BGP Auto-Discovery)
2.4.4 Découplage ou non des PEs

Pour déployer un réseau supportant VPLS, le SP doit décider des fonctions
que supportent le dispositif VPLS le plus proche du client. Ce dispositif appelé
VE (VPLS Edge) peut être soit un PE ou un u-PE encore appelé L2PE ou MTU.
Le cas par défaut dans les configurations, est que le VE est le PE. Cependant
plusieurs raisons peuvent amener à prendre le VE comme le u-PE c’est-à-dire
l’équipement qui dispose des fonctions de la couche 2 tel que l’apprentissage
des adresses MAC et l’inondation, et de quelques fonctions de la couche 3 telles
que la communication avec le PE auquel il est relié, mais ne peut pas faire à part

entière la découverte et la signalisation de PE à PE. Dans le cas où le VE est le

u-PE, il est alors relié à un PE qui occupe toutes les autres fonctions de la couche
3 un peu comme dans l’architecture H-VPLS entre les routeurs u-PEs et n-PEs.
Comme les deux cas sont bénéfiques, certains préfèrent mélanger et associer
les deux méthodes. Quelle que soit la méthode choisie, les mécanismes de
signalisation et de découverte se font de la même manière. Comment ils font
l’apprentissage et la transmission dépend de si oui ou non il y a un u-PE ;
toutefois, ceci est locale, et n’est pas signalée.
2.5 Avantages de l’utilisation de VPLS

2.5.1 Technologies permettant d’interconnecter
plusieurs sites
Plusieurs technologies permettent d’étendre un réseau Ethernet ou un VLAN
à plusieurs sites.
Ethernet QinQ
Dans la technologie Ethernet QinQ, une étiquette (tag) VLAN supplémen-
taire est ajoutée à la trame Ethernet. Cette trame étiquetée supplémentaire passe à
travers le cœur du réseau. A destination, l’étiquette VLAN original est récupérée
et la trame Ethernet est transmise à un VLAN local. Ethernet QinQ nécessite les
techniques sans boucle de couche 2 telles que Spanning Tree Protocol (STP), et
par conséquent le temps de convergence peut varier. En général, QinQ est une
solution moins évolutive que VPLS.
Ethernet pseudowire over MPLS (EoMPLS)

L’utilisation d’un réseau EoMPLS étends un VLAN sur deux sites via un
lien point à point dans chaque direction. Il utilise MPLS et peut fournir une
convergence rapide et un QoS (Quality of Service) utilisant une ingénierie de
trafic. Parce qu’un pseudowire nécessite une connexion point à point, il nécessite
également un maillage complet de pseudowires à travers tous les sites. Pour finir,
EoMPLS est une solution à une forte demande de ressources, ce qui ne permet
donc pas de le déployer à une grande échelle.

Virtual private LAN service (VPLS)

VPLS à travers MPLS utilise la capacité dans le cœur pour étendre les VLANs
de un ou plusieurs sites. Les fonctionnalités de haute disponibilité définis dans
les normes VPLS (tel que PE multi-homing) et les fonctions d’une topologie
auto-découverte utilisant le protocole de signalisation BGP fait de VPLS une
technologie évolutive et facile à déployer. Parce que VPLS utilise MPLS comme
son cœur, il fournit une faible variation de latence et statistiquement un faible
temps de convergence au sein du réseau MPLS. Il supporte aussi la QoS en
utilisant les capacités d’ingénierie de trafic du réseau MPLS.
Le tableau 2.1 compare ces technologies, montrant leurs avantages et leurs

inconvénients sur certains plans tels que l’évolutivité, la convergence, la variation
de latence, le coût de déploiement et la facilité dans la fourniture des services.

TABLE 2.1: Comparaison des technologies de couche 2 étendant un LAN
Ethernet QinQ EoMPLS VPLS

Extensibilité Faible - Réseau Faible - Nécessite Elevée - Réseau
cœur de couche 2 un maillage de coeur partagé,
étendu connexion point connexion point
à point entre les à multipoint
sites
Convergence Elevé - Conver- Moyen - Conver- Faible - Réseau
gence couche 2 à gence couche 2 coeur MPLS
travers le coeur avec plusieurs
couches
Latence Elevée - Trans- Faible - Transmis- Faible - Transmis-
mission couche 2 sion à travers les sion à travers les
à travers le coeur liens LSP liens LSP
Variation de la- Elevée - Trans- Faible - Transmis- Faible - Transmis-
tence mission couche 2 sion à travers les sion à travers les
à travers le coeur liens LSP liens LSP
Coût Faible - Partage Faible - Partage Faible - Partage
de l’infrastruc- de l’infrastruc- de l’infrastruc-
ture du coeur ture du coeur ture du coeur
Fourniture des Complexe - Complexe - Simple - Partage
services Réseau coeur de Nécessite un de l’infrastruc-
couche 2 maillage de ture du coeur,
connexion point mécanisme
à point de découverte
automatique
2.5.2 Avantages de VPLS

VPLS combine les avantages d’Ethernet et de MPLS et fournit également
toutes les fonctions d’un réseau local traditionnel. Il peut connecter des réseaux
Ethernet géographiquement dispersés à travers les réseaux IP / MPLS de sorte
que les réseaux Ethernet puisse fonctionner comme un seul réseau local. Le

réseau pont transmet des trames basées sur les adresses MAC ou adresses MAC
et des étiquettes VLAN. Dans le cas le plus simple, tous les sites reliés au PEs
appartiennent à une seule instance VPLS, et chaque CE a besoin de communiquer
avec les autres CEs de l’instance VPLS. Pour les CEs, le réseau cœur MPLS,
fonctionne tout comme un pont Ethernet.
VPLS fournit les avantages suivants :
• VPLS utilise les interfaces Ethernet du côté de l’utilisateur, le support rapide

et la flexibilité de déploiement de service rapide et flexible à la frontière
entre le LAN et le WAN.
• Avec VPLS, les utilisateurs contrôlent et maintiennent des politiques de

routage sur les réseaux d’utilisateurs. Cela simplifie la gestion du réseau du
fournisseur de services.
• Tous les CEs d’un VSI appartiennent au même sous-réseau, ce qui simplifie
la planification d’adresse IP.
• Le service VPLS est invisible pour les utilisateurs, et il ne participe pas à

l’adressage IP et au routage.

Deuxième partie
Approche méthodologique
41
Chapitre 3
Choix de la méthode de
déploiement de VPLS
Dans les chapitres précédents, nous avons présenté le réseau BJNet et l’état de
l’art sur VPLS, technologie qui permet d’interconnecter plusieurs sites distants
à travers un réseau MPLS. Il s’agit dans ce chapitre de faire une analyse des
différentes méthodes de déploiement de VPLS, de choisir à partir de cette analyse
la méthode de déploiement de VPLS la plus évolutive et la plus adéquate pour
BJNet ; et de présenter cette méthode.
3.1 Analyse des différentes méthodes de

déploiement de VPLS
Il y a essentiellement deux méthodes de déploiement VPLS c’est à dire
protocole de plan de contrôle : VPLS basé sur LDP et VPLS basé sur BGP. Dans
cette section, nous allons comparer sur les aspects d’évolutivité des mécanismes
de signalisation et de découverte automatique ces méthodes pour choisir la plus
adéquate pour l’implémentation de VPLS dans le réseau BJNet.
3.1.1 Gestion de la connectivité entre les PEs

Pour mettre en place un domaine VPLS, tous les PEs participant au même
domaine VPLS doivent pouvoir échanger entre eux des informations pour l’éta-
blissement des Pseudowires. Comme le nombre de PEs dans un réseau WAN
42
CHAPITRE 3. CHOIX DE LA MÉTHODE DE DÉPLOIEMENT DE VPLS
évolue compte tenu de la demande, il serait essentiel de rendre évolutif le méca-

nisme de signalisation.
Pour la signalisation LDP-VPLS, les échanges d’informations VPLS pour

l’établissement des PWs sont accomplies par la mise en place d’un maillage
complet de sessions LDP ciblées entre chaque pair de routeurs PE qui ont en
commun un domaine VPLS. Comme la taille du réseau VPLS s’accroît, le
nombre de sessions LDP ciblées évolue de façon exponentiel de l’ordre de O
(n2), où n est le nombre de routeurs PE dans le réseau. Bien que cela puissse
être évité avec H-VPLS, le coût de l’approvisionnement et de l’exploitation de
nouveaux PEs (n-PEs et u-PEs) est une complexité supplémentaire à prendre en
compte.
Le maintien de toutes ces sessions LDP crée une charge supplémentaire sur le
plan de contrôle des routeurs PEs dans le réseau VPLS.
Contrairement à LDP, l’échange des informations VPLS pour la signalisation

avec BGP-VPLS ne nécessite pas un maillage complet des sessions entre tous
les routeurs PEs. A la place, le protocole du plan de contrôle BGP-VPLS, y
compris sa composante de signalisation, peut utiliser la hiérarchie avec les RRs
(utilisation des RRs). Chaque routeur BGP établit ainsi une session BGP avec un
ou plusieurs RRs. L’utilisation des RRs permet également de rendre plus simple
la tâche lors de l’ajout ou de la suppression d’un routeur PE puisque seul le
peering BGP avec le RR a besoin d’être changé.
Les RRs de BGP-VPLS peuvent être placés n’importe où dans le réseau i.e
qu’ils n’ont pas besoin d’être sur le chemin de donnée du domaine VPLS qui les
utilisent. Ceci permet une flexibilité dans le déploiement (l’ajout) de nouveau
RR en cas de besoin pour une plus grande évolutivité.
3.1.2 Fourniture du service VPLS

Dans un déploiement de réseau à grande échelle, l’approche de découverte
automatique est particulièrement efficace.
LDP-VPLS n’a pas de mécanisme de découverte automatique. Ainsi, la si-

gnalisation LDP repose soit sur la configuration manuelle pour identifier tous

les routeurs PE auxquels sont reliés les sites des clients ou sur l’utilisation de
BGP pour la découverte automatique. Dans un déploiement de réseau à grande
échelle, la tâche qu’incombe la configuration manuelle est opérationnelement
inefficace et sujet à l’erreur humaine. En outre, tout ajout ou suppression d’un
site client VPLS nécessite un changement de configuration, non seulement sur
le routeur PE sur lequel le site est ajouté ou duquel il est retiré, mais aussi sur
tous les PEs participants au domaine VPLS de ce client. L’utilisation de BGP
pour la découverte automatique de VPLS et LDP pour la signalisation ajoute
une complexité à la solution, tant du point de vue protocole que du point de vue
opérationnel et dépannage. Lorsque BGP est utilisé comme mécanisme de dé-
couverte automatique avec LDP comme mécanisme de signalisation, en plus des
sessions supplémentaires établies pour la découverte automatique des membres
du domaine VPLS, il est toujours nécessaire de configurer les sessions LDP
pour la signalisation des PWs, indépendamment du fait que les sessions LDP
soient manuellement ou automatiquement établies. Dans ce cas un fournisseur
de service doit déployer et maintenir les deux mécanismes BGP et LDP pour
offrir les services VPLS.
Contrairement BGP-VPLS supporte un mécanisme de découverte automatique

de tous les PEs auxquels sont reliés les sites du client ; le mécanisme de signa-
lisation repose sur cette fonction de découverte automatique. Chaque ajout ou
suppression d’un site client d’un domaine VPLS nécessite que la configuration
change seulement sur le routeur PE auquel le site est ajouté ou duquel il est
supprimé. La découverte automatique fournit pas BGP élimine la nécessité de
faire des changements au niveau des autres PEs dans le domaine VPLS du client.
3.1.3 Echange de l’état d’information des

Pseudowires
Sur LDP-VPLS et BGP-VPLS, pour chaque client VPLS, les messages de
signalisation sont échangés entre chaque paire de routeurs PE pour la création
du maillage complet des PWs. La quantité des informations de signalisation
que chaque PE a besoin de maintenir et d’échanger avec d’autres routeurs PEs
augmente à mesure que le VPLS se développe (en terme d’ajout de sites client),
à la fois en terme du nombre de clients VPLS et du nombre de routeurs PEs pour
chaque domaine VPLS.

Un message de signalisation LDP-VPLS permet d’établir un seul PW avec

un autre routeur PE. Contrairement, un message de signalisation BGP-VPLS
permet d’établir plusieurs PWs avec plusieurs routeurs PEs. Par conséquent,
dans un large réseau VPLS, BGP-VPLS nécessite beaucoup moins de messages
de signalisation que LDP-VPLS pour établir un maillage complet de PWs entre
les routeurs PEs. Avoir moins de message de signalisation réduit la surchage du
plan de contrôle sur les PEs.
3.1.4 Comparaison entre LDP-VPLS et BGP-VPLS

De nos analyses nous pouvons conclure que le mécanisme de signalisation du
protocole du plan de contrôle BGP-VPLS fournit une évolutivité supérieure par
rapport au mécanisme de signalisation avec LDP-VPLS. De plus, BGP-VPLS
supporte la découverte automatique et l’utilisation des RRs, qui offrent tous les
deux une automatisation dans le déploiement de services évolutifs, réduisant
ainsi les coûts de mise en place et d’exploitation des ces services.
Le tableau 3.1 résume la comparaison faite entre les deux protocoles du plan
de contrôle VPLS.

TABLE 3.1: Comparaison des solutions VPLS
Caractéristiques LDP-VPLS BGP-VPLS

Nécessité d’un Réduite seulement avec Résolue avec l’utilisation
maillage complet l’utilisation de H-VPLS, des réflecteurs de route
entre les PEs mais au détriment du chan-
gement et de surcharge sup-
plémentaire au niveau du
plan de contrôle
Configurations Seulement simplifiées avec Largement simplifiées avec
lors de l’ajout ou l’utilisation de H-VPLS l’utilisation des réflecteurs
de la suppression de route
des PEs
Configurations Manuelles Automatisées par le méca-
lors de l’ajout ou nisme de découverte auto-
du changement matique de VPLS
de sites clients
Surchage de la si- Augmente en fonction du Minimal parce que chaque
gnalisation nombre total de Pseudo- message de signalisation
wires dans le réseau peut être utilisé pour établir
plusieurs Pseudowires
Justification du choix BGP-VPLS
Pour simplement fournir les services VPLS, la découverte automatique basé sur
BGP pourrait devenir un élément obligatoire. Après toute cette analyse, le choix
de BGP-VPLS est justifié pour BJNet. Ce dernier est un grand réseau à l’étendu
d’un WAN et en tant que fournisseur de service désire offrir un certains nombres
de services dont DNS (Domain Name service), Service Mail, des services VPLS,
etc .
Pour le déploiement de VPLS, il est souhaité de mettre en place la méthode la

plus évolutive de VPLS pour le réseau BJNet compte tenu des demandes futures
des clients qui pourraient accroître.

3.2 Présentation de quelques fonctions de

VPLS basé sur BGP
L’utilisation de MP-BGP a l’avantage de permettre aux équipements PE d’être
simultanément utilisés pour VPLS et les IP VPNs. Ces deux services sont
indépendants et l’information échangée pour chaque type de service est gar-
dée séparée puisque le NLRI utilisé pour l’échange des informations est diffé-
rent : Address Family Identifier (AFI) et Subsequent Address Family Identifiers
(SAFI).
3.2.1 Terminologie BGP

Plusieurs termes sont utilisés pour définir les différents paramètres avec BGP :
IBGP
Le terme IBGP (Internal BGP) refère à l’ensemble des protocoles et des
procédures utilisées quand il y a une connexion BGP entre deux locuteurs BGP
dans le même système autonome.
EBGP
Le terme EBGP (External BGP) refère à l’ensemble des protocoles et des
procédures utilisées quand il y a une connexion BGP entre deux locuteurs BGP
dans différents systèmes autonomes.
NLRI
Un NLRI (Network Layer Reachability Information) est un ensemble de
préfixes ayant les mêmes caractéristiques (attributs).
BGP Next Hop

L’attribut BGP Next Hop est l’adresse IP du prochain saut qui va être utilisé
pour atteindre une certaine destination. Pour EBGP, le prochain saut est toujours
l’adresse IP du voisin spécifié dans la commande voisine.
AFI et SAFI
L’Address Family Identifier en combinaison avec le Subsequent Address
Family Identifier identifient l’ensemble des protocoles de couche réseau au-

quel l’adresse portée dans le champ Next Hop doit appartenir, la manière dont
l’adresse du prochain saut est codée, et la sémantique du NLRI qui suit.
Route Distinguisher
Un Route Distinguisher (RD) différencie une famille d’adresse IPv4 d’un
autre. Si deux domaines VPLS utilisent le même préfixe d’adresses IPv4, les
PEs traduisent celles-ci en préfixes d’adresses uniques VPN-IPv4. Cela garantit
que si la même adresse est utilisée dans deux différents VPLS, il est possible
d’installer deux routes totalement différentes à cette adresse, un pour chaque
VPN.
3.2.2 Découverte automatique

Le mécanisme de découverte automatique que nous allons décrire ici, est
basé sur celui décrit dans les RFC 4761 et 4364. Ce mécanisme utilise les
communautés étendues de BGP pour identifier les membres d’un VPLS, en
particulier, les Route Target (RT).
Pour identifier un VPLS, le PE doit connaitre son RT ; ceci parce que le RT

est l’identifiant d’un VPLS donné. Un PE annonce qu’il appartient à un VPLS
donné (VPLS-x) en annotant ses NLRIs pour VPLS-x avec le RT, et agit sur ce
en acceptant les NLRIs des autres PEs qui ont le même RT. Le PE annonce qu’il
ne participe plus dans l’instance VPLS en retirant tous les NLRIs qu’il avait
annoncé avec le RT de ce VPLS.
3.2.3 Signalisation
La signalisation concerne l’établissement des PWs par l’échange de démulti-
plexeur ou label PW, ou leur suppression. Une fois que les sessions iBGP sont
établies, les messages BGP Update sont échangés entre les PEs. Les messages
BGP Update sont utilisés pour envoyer les démultiplexeurs aux PEs distants.
Cette technique réduit la charge du plan de contrôle aussi bien sur le PE original
(le PE qui envoie le message) que sur le RR qui peut être impliqué dans la
distribution des Updates aux autres PEs.
Pour échanger les démultiplexeurs entre les PEs, les valeurs VE-ID, VE Block
Offset, VE Block Size, et Label Base sont utilisées. Pendant l’établissement

d’un PW entre deux PEs, un label MPLS est échangé, qui est le démultiplexeur
ici et qui permet d’identifier le trafic de ce PW donné parmi le nombre de PW
qui pourraient être transporté dans un seul tunnel. Pour un service VPLS le
démultiplexeur doit fournir les informations qui suivent :
• identifier l’instance VPLS spécifique à laquelle appartient le paquet pour la
transmission du paquet ;
• identifier le PE entrant (ingress) dans le but de l’apprentissage d’adresse

MAC.
Pour faciliter l’apprentissage des adresses le démultiplexeur doit être unique

pour un PE entrant donné. Pour y parvenir le plan de contrôle BGP-VPLS utilise
le concept de bloc de label défini par le label base (LB), le VE Block Size (VBS)
et le VE Block Offset (VBO). Le bloc de label est un ensemble contigu de labels
LB+VBO,LB+VBO+1, ..., LB+VBO+VBS-1. A tous les PEs dans une instance
VPLS donnée sont assignés un unique VE ID (VPLS Edge ID) qui constitue une
partie de leur configuration. Un PE-x souhaitant envoyer un message Update,
envoie les mêmes informations du bloc de label à tous les autres PEs de l’instance
VPLS. Lorsqu’un PE annonce ses NLRIs aux autres PEs de l’instance VPLS
avec un bloc de label commun, chaque PE récepteur déduit le label destiné pour
la transmission en ajoutant son unique VE ID au label base. L’utilisation de cette
approche assure que chaque PE récepteur dérive un démultipleur unique qui peut
être utilisé pour le PE faisant l’annonce pour la transmission et l’apprentissage
MAC dans la bonne instance VPLS.
Le PE annoncant un NLRI peut annoncer plusieurs NLRIs, chacun avec un

différent VBO et bloc de label qui définit l’ensemble de VE IDs, ou l’ensemble
des VEs distants, qui devrait utiliser ce bloc.
Supposons que PE1 fait partie d’un VPLS donné et envoie le NLRI avec le
VE ID V, le VE Block Offset “VBO”, le VE Block Size “VBS”, et le label base
“LB”. Si PE2 fait partie du même VPLS (déterminer par le RT) et a un VE ID W,
il exécute les étapes suivantes pour calculer le label à utiliser :
• Premièrement, PE2 vérifie si VE ID W fait partie de l’ensemble VE distant
de PE1. Si VBO <= W < VBO + VBS, W fait partie de l’ensemble VE
distant de PE1. Si ce n’est pas le cas, PE2 ignore le message.

• Si PE2 fait partie de l’ensemble VE distant de PE1, il met en place un PW

à PE1 où le label demultiplexeur pour envoyer le trafic de PE2 à PE1 est
calculé en faisant (LB + W - VBO).
• PE2 vérifie si V fait partie d’un ensemble VE distant que PE2 a annoncé.
Sinon PE2 fait une nouvelle annonce.
• PE2 met en place un PW de PE1 où le label démultipleur par lequel PE2

devrait espérer le trafic venant de PE1 est calculé comme suit : (LB’ +
V - VBO’), où LB’ et VBO’ sont les paramètres avec lesquels PE2 a fait
l’annonce.
Ces étapes sont décrites dans la RFC4761.
A titre d’exemple, supposons que PE25 annonce un message Update contenant

le NLRI suivant :
RD :64496 :600, VE-ID=25, VBO=25, VBS=8, LB=131056
RD :64496 :600, VE-ID=25, VBO=17, VBS=8, LB=131015
Si PE24 avec le VE ID=24 est dans le même VPLS (déterminé par le RT),
PE24 doit premièrement déterminer s’il fait partie de l’ensemble VE distant de
PE25 en identifiant le NLRI pour lequel VBO <= 24 < VBO + VBS. Ceci est le
NLRI avec le label base 131015. PE24 ainsi doit configurer le PW avec le label
démultiplexeur calculé comme suit : 131015 (LB) + 24 (VE-ID) – 17 (VBO) =
131022.
Dans le cas de suppression de PW, si un PE (PEa ) retire un NLRI du VPLS

V que PEb utilisait, alors PEb doit supprimer ses extrémités de PW entre PEa et
PEb .
BGP VPLS NLRI

Un NLRI BGP VPLS contient les informations suivantes : un VE ID, un
VE Block Offset, un VE block size, et un label base. Le nouveau AFI (Address
Family Identifier) est le L2VPN AFI (25), et le nouveau SAFI (Subsequent
Address Family Identifier) est le VPLS SAFI (65).

F IGURE 3.1: BGP NLRI pour VPLS
Un PE participant dans un VPLS doit au moins avoir un VE ID. Si le PE est le

VE (VPLS Edge), il a typiquement un VE ID. Si le PE est connecté à plusieurs
u-PEs, il a un VE ID distinct pour chaque u-PE. Il peut additionnellement avoir
un VE ID pour lui même, s’il agit comme un VE pour ce VPLS. Les VE IDs
sont assignés aux VEs par l’administrateur réseau. Un VE ID devrait appartenir
seulement à un et un seul VE à moins que le CE qui lui est relié est multi-hébergé.
3.2.4 Fonctionnement BGP-VPLS

Pour créer une nouvelle instance VPLS, VPLSnew, l’administrateur du réseau
doit choisir un RT pour VPLSnew, RTnew. RTnew sera utilisé par tous les PEs
qui servent VPLSnew. Pour configurer un PE donné, PE1, à faire partie de
VPLSnew, l’administrateur de réseau a seulement à choisir VE ID V pour PE1.
Si PE1 est connecté à des u-PEs (découplage), il peut être configuré avec plus
d’un VE ID. PE1 peut également être configuré avec un Route Distinguisher
(RD), RDnew. Sinon, PE1 génère un unique RD pour VPLSnew. PE1 génère
alors un bloc de label initial et un ensemble VE distant pour V, défini par VE
Block Offset VBO, VE block size VBS, et label base LB.
PE1 crée alors VPLS BGP NLRI avec RD RDnew, VE ID V, VE Block Offset
VBO, VE block size VBS et label base LB. A cela, il attache un Layer 2 Info
extended community 1 et un RT, RTnew. Il définit le BGP Next Hop pour cette
NLRI comme lui même et annonce ce NLRI à ces pairs. Le protocole de couche
1. La spécification de BGP-VPLS introduit également un nouveau attribut BGP Extended Community “Layer-2
Information Extended Community” dans le but de signaler les informations de contrôle sur les PWs à mettre en
place pour un VPLS donné

réseau associé avec l’adresse réseau du Next Hop pour la combinaison <AFI
=L2VPN AFI, SAFI = VPLS SAFI> est IP .
Si PE1 entend d’un autre PE, par exemple soit PE2, l’annonce BGP VPLS
avec RTnew et VE ID Z, alors PE1 sait par la découverte automatique que PE2
est un membre du même VPLS que lui. PE1 doit alors mettre en place sa part du
PW VPLS entre PE1 et PE2. De même PE2 aura découvert que PE1 est dans le
même VPLS, et PE2 doit également mettre en place sa part du PW VPLS. Ainsi,
la signalisation et la configuration du PW sont également réalisées avec le même
message Update.
Si la configuration de PE1 est modifiée pour supprimer VE ID V de VPLSnew,

PE1 retire alors toutes ses annonces pour VPLSnew qui contiennent VE ID V.
Si tous les liens de PE1 à ses CEs dans VPLSnew ne fonctionnent plus alors
soit PE1 retire tous ces NLRIs pour VPLSnew ou laisse les autres PEs dans le
VPLSnew savoir que PE1 n’est plus connecté à ses CEs.
3.3 BGP VPLS hiérarchique

Le but de hiérarchiser BGP VPLS est de dessiner à l’échelle le plan de
contrôle de VPLS en utilisant BGP. La hiérarchie :
• évite la nécessité de faire un maillage complet entre les locuteurs BGP

(BGP speaker) ;
• limite les messages BGP VPLS passant aux locuteurs interessés plutôt qu’à
tous les locuteurs BGP ;
• simplifie l’ajout et la suppression de locuteurs BGP.
La technique basique pour la hiérarchie est l’utilisation des RRs (Bates T. et

al, 2006) qui aide à atteindre les objectifs cités ci-dessus.
L’utilisation des RRs ne présente aucune exigence par rapport à l’état du plan
de données et par rapport à la transmission du plan de données, et ne modifie
pas le chemin de transmission du trafic VPLS. Contrairement à la technique de
H-VPLS qui par contre surchage le plan de contrôle.

On peut définir plusieurs ensembles de RRs, par exemple, un ensemble pour

gérer VPLS, un autre pour gérer les IP VPN, et un autre pour le routage Internet.
Un autre partionnement pourrait être d’avoir un sous-ensemble de VPLSs et IP
VPN géré par un ensemble de RRs, et un autre sous-ensemble de VPLSs et IP
VPN géré par un autre ensemble de RR. Dans ce cas, il va faloir filtrer le RT.
L’utilisation de la Route Target Filtering (RTF) peut simplifier la tâche.

Chapitre 4
Méthodologie
d’implémentation de
BGP-VPLS
Dans ce chapitre nous présentons la méthodologie que nous avons suivi pour
l’implémentation de BGP basé sur VPLS et exposons les différents outils qui
nous ont permis de réaliser l’implémentation.
4.1 Les outils de base

4.1.1 Mikrotik RouterOS
L’infrastructure réseautique de BJNet est constituée essentiellement d’équi-
pements Mikrotik. Mikrotik est une solution qui fournit plusieurs services à
moindre coût. Les routeurs Mikrotik du réseau BJNet supportent l’implémenta-
tion de VPLS et donnent une ouverture sur les options de déploiement de VPLS
telles que l’utilisation des Routes Reflector, le découplage, etc.
Pour des raisons de disponibilité de matériels nous avons effectué nos tests sur
des topologies constituées de routeurs virtuels. Ainsi, nous avons utilisé l’OS de
Mikrotik, RouterOS, qui est le même OS implémenté sur les routeurs physiques.
Il permet donc d’avoir les mêmes fonctionnalités sur les routeurs physiques que
sur les routeurs virtuels avec toutes les caractéristiques nécessaires telles que le
54
CHAPITRE 4. MÉTHODOLOGIE D’IMPLÉMENTATION DE BGP-VPLS
routage, la gestion de bande passante, MPLS, VPN, QoS, la sécurité, etc. Nous
avons utilisé la version 6.32 de l’OS.
4.1.2 GNS3
GNS3 (Graphic Network Emulator) est un simulateur open source qui fonc-
tionne sur Windows et sous Linux. GNS3 est un simulateur graphique de réseau
qui permet de créer des topologies complexes de réseaux et permet d’en établir
des simulations 1 . Nous l’avons choisi parce qu’il simule plusieurs équipements
réseaux des différentes marques telles que Cisco, Juniper et Mikrotik.
En plus de la possibilité de faire fonctionner Mikrotik sur GNS3, elle intègre

Wireshark un logiciel d’analyse de protocole réseaux qui permet d’analyser les
paquets échangés entre deux noeuds et de voir l’information contenue dans ces
paquets. Nous l’avons utilisé pour analyser les différents protocoles échangés
entre les routeurs lors de nos tests.
4.1.3 Qemu
Qemu (Quick EMUlator) est une solution d’émulation et de virtualisation
comme VirtualBox et VMWare. C’est un logiciel générique et Open Source. Il
émule tout type de système. Qemu permet d’exécuter un système d’exploitation
complet comme une autre tâche sur l’ordinateur. Il peut être très utile pour
essayer différents systèmes d’exploitation, des tests de logiciels, et l’exécution
d’applications qui ne seront pas exécutées sur la plate-forme native de l’ordina-
teur. Qemu est le meilleur émulateur pour faire fonctionner RouterOS Mikrotik
et le mettre sur GNS3 (Rofiq Fozi, 2013).
Nous avons choisi Qemu pour sa grande souplesse par rapport à VirtualBox
et à VMWare. Avec Qemu il nous a été possible de faire fonctionner notre
grand nombre de routeurs (passant de 7 à 10), nous n’avons pas été confronté au
problème de ressources. Chaque ajout d’un routeur Mikrotik-Qemu sur GNS3
n’a consommé qu’en mémoire RAM et n’a pas consommé de ressources du
processeur. Pour nos tests nous avons utilisé la version 0.11.0 sous Windows et
la version 0.14.1 sous Linux.
1. http ://linuxfr.org/news/gns3-nouveau-simulateur-r%C3%A9seau-graphique, consulté le 29 octobre 2015

TABLE 4.1: Outils de base utilisés
Outils Version Observation

Mikrotik Route- 6.32 Mikrotik RouterOS, est l’OS
rOS des routeurs Mikrotik. Avec
ce système on peut avoir les
mêmes fonctions sur les rou-
teurs virtuels que sur les rou-
teurs physiques.
Qemu 0.14.1 Qemu est un logiciel d’ému-
lation et de virtualisation
comme VirtualBox et VM-
Ware, mais qui consomme
moins de ressouces que les
deux autres logiciels.
GNS3 1.3.10 GNS3 est un simulateur qui
permet de créer et de simuler
des topologies complexes sur
un ordinateur.

4.2 Implémentation de BGP-VPLS pour

l’interconnexion de deux sites (cas du
centre de données)
4.2.1 Matériels utilisés
Les configurations et les tests de validation pour l’interconnexion de deux
sites ont été effectués sur l’architecture suivante :
F IGURE 4.1: Architecture physique utilisée pour la mise en place du réseau

MPLS

TABLE 4.2: Plan d’adressage utilisé pour la figure 4.1
Routeur du client
CE_1 192.168.20.1/28
CE_2 192.168.20.2/28
Routeur P (Provider) du réseau coeur
P1 Adresse loopback(lo) :
10.10.10.101/32
ether1 : 10.10.47.1/28
ether2 : 10.10.47.33/28
ether3 : 10.10.47.49/28
P2 lo : 10.10.10.102/32
ether1 : 10.10.47.2/28
ether2 : 10.10.47.17/28
ether3 : 10.10.47.65/28
P3 lo : 10.10.10.103/32
ether1 : 10.10.47.18/28
ether2 : 10.10.47.34/28
Routeur PE (Provider Edge)
PE1 lo : 10.10.10.104/32
ether2 : 10.10.47.50/28
PE2 lo : 10.10.10.105/32
ether2 : 10.10.47.66/28

4.2.2 Implémenter MPLS dans le backbone

La configuration de la transmission de MPLS est la première étape de la mise
en place du backbone MPLS du fournisseur de service.
Ici, nous montrons les différentes configurations préliminaires pour mettre en

place MPLS dans le backbone. Pour mettre en place MPLS, il faut configurer sur
les routeurs du cœur une interface virtuelle (interface loopback) qui sera utilisée
par LDP pour établir des sessions. Ceci parce que :
• il n’y a qu’une seule session LDP entre chaque pairs de routeurs, peu
importe le nombre de liens qui les connectent, l’adresse IP de l’interface vir-
tuelle assure que la session LDP ne soit pas affecter par l’état de l’interface
ou les changements d’adresse ;
• l’utilisation de l’adresse de l’interface virtuelle comme adresse de transport

de LDP assure un comportement adéquat de penultimate hop popping
(PHP) 2 lorsque plusieurs étiquettes sont jointes au paquet comme dans le
cas de VPLS.
Nous avons configuré les adresses des interfaces virtuelles comme suit
(exemple sur le routeur PE1 figure 4.2) :
2. Le procédé PHP s’observe dans les réseaux MPLS et se définit par le fait d’enlever l’étiquette (label LDP
MPLS) d’un saut avant sa destination.

F IGURE 4.2: Configuration de l’interface virtuelle
Routage classique
Comme LDP distribue des étiquettes pour les routes actives, il est essentiel
de configurer correctement le routage IP. LDP par défaut distribue des étiquettes
pour les routes IGP actives. Comme protocole de routage IGP, nous avons choisi
OSPF pour ses nombreux avantages : rapidité de convergence, routage à état de
liens, etc. Nous l’avons configuré sur tous les routeurs. La figure suivante (figure
4.3) montre les routes pour atteindre chaque routeur du réseau MPLS. On y voit
toutes les routes sur le routeur PE1 et aussi qu’il arrive à faire un ping vers le
routeur P2 qui ne lui est pas directement connecté.

F IGURE 4.3: Vérification de la configuration du protocole OSPF
Configuration de LDP
Dans le but de distribuer des labels pour les routes, nous avons besoin
d’activer LDP. Toutes les interfaces du domaine MPLS ont besoin d’être ajoutées
au protocole LDP. Nous avons effectué la configuration de MPLS LDP sur les
routeurs du réseau MPLS (exemple pris sur le routeur P3 sur la figure 4.4).
Les adresses de transport qui définissent le chemin à suivre, sont les adresses
de l’interface virtuelle. LDP est activé sur les interfaces qui relient les routeurs.
Il n’est pas activé sur les interfaces qui relient les réseaux des clients. Après que
les sessions LDP sont établies, on remarque que sur P3 il y a deux voisins LDP :
P1 et P2.

F IGURE 4.4: Vérification fonctionnement LDP MPLS
4.2.3 Configuration de VPLS

Le plan de contrôle est assuré par le protocole BGP. Nous utilisons la même
architecture (figure 4.1) que dans la session ci-dessus. Les deux PEs se situent
dans le même AS.
Configuration des sessions IBGP pour la signalisation VPLS

On parle ici de session IBGP parce que tous les sites connectés aux PEs sont
dans un seul AS. Pour commencer, il faut que l’instance BGP soit configurée
sur les routeurs. On peut également utiliser l’instance par défaut comme dans le
cas de OSPF. Ici, nous avons gardé les instances par défaut sur les PEs. Ensuite,
nous avons établi un peering entre les deux PEs. Nous avons pris PE1 comme
Route Reflector. Pour l’illustrer nous prenons l’exemple du routeur PE1 (figure
4.5). Il est possible de prendre un routeur qui n’est pas connecté à un site comme
RR.

F IGURE 4.5: Configuration des sessions IBGP
Configuration BGP pour la signalisation VPLS

Les PWs VPLS signalés avec BGP sont créés dynamiquement lorsque les
bons BGP NLRIs sont reçus. Ainsi, on n’a plus besoin de configurer d’interface
VPLS puisque lorsque les PWs sont signalés, les interfaces VPLS sont créés en
même temps prouvant que les PWs sont créés. Néanmoins, pour livrer de façon
transparente les paquets provenant du segment Ethernet à travers VPLS, un AC
doit être configuré. Nous avons choisi de configurer un pontage qui va relier les
sites. Un pont est créé sur chaque PE pour chaque site.
Ici, sur chacun des PEs nous avons créé un pont nommé "datacenter" en y
associant le port Ethernet sur lequel le CE leur est connecté. Pour cela le CE et
le PE doivent être connectés.
Ensuite, on a configuré l’instance VPLS au niveau des routeurs. La configura-

tion de l’instance VPLS permet au routeur de faire l’annonce du BGP NLRI qui
annonce qu’un routeur particulier appartient à un VPLS donné. Dès la réception
de cette annonce, les autres membres du même VPLS savent qu’ils doivent établir
le PW VPLS avec ce routeur. Nous avons connecté à PE1 et à PE2 les routeurs

CEs du client respectivement CE1 et CE2. Ensuite, nous avons configuré le pont
et l’instance VPLS sur chacun des PEs (exemple sur le routeur PE2 figure 4.6).
F IGURE 4.6: Instance VPLS
Une fois que les interfaces VPLS sont créées alors les PW sont établis. Et
ainsi, il suffit de donner une adresse du même sous-réseau à chaque CE pour les
faire communiquer.


l’interconnexion de trois sites
Pour cerner réellement l’utilité du RR, nous avons rajouté un troisième PE
(PE3 connecté à P3). PE3 est connecté à P3 et permet de relier un site CE4 à
l’instance VPLS qu’on a eu à créer. L’architecture utilisée est la suivante :
F IGURE 4.7: Architecture physique utilisée pour l’interconnexion de 3 sites

TABLE 4.3: Plan d’adressage utilisé pour la figure 4.7
Routeur du client
CE_1 192.168.20.1/28
CE_3 192.168.20.3/28
CE_4 192.168.20.4/28
Routeur P (Provider) du réseau coeur
P1 Adresse loopback(lo) :
10.10.10.101/32
ether1 : 10.10.47.1/28
ether2 : 10.10.47.33/28
ether3 : 10.10.47.49/28
P2 lo : 10.10.10.102/32
ether1 : 10.10.47.2/28
ether2 : 10.10.47.17/28
ether3 : 10.10.47.65/28
P3 lo : 10.10.10.103/32
ether1 : 10.10.47.18/28
ether2 : 10.10.47.34/28
ether3 : 10.10.47.81/28
Routeur PE (Provider Edge)
PE1 lo : 10.10.10.104/32
ether2 : 10.10.47.50/28
PE2 lo : 10.10.10.105/32
ether2 : 10.10.47.66/28
PE3 lo : 10.10.10.106/32
ether2 : 10.10.47.82/28

Nous avons effectué les configurations comme sur PE2. Pour l’établissement
des sessions BGP avec les autres PEs, nous avons juste établi une session BGP
entre PE1 et PE3. PE1 étant le RR, PE2 a immédiatement identifié PE3 et établi
un PW avec lui. Une fois CE4 ajouté à l’instance VPLS par le biais de PE3, CE4
et CE1 s’échangent des informations ; mais CE4 n’arrive pas à échanger avec
CE3. Lorsque PE2 reçoit une information de PE3 de la part de CE4, il ne le
transmet pas à CE3, l’information n’est pas transmis à CE4 bien que PE2 et PE3
se soient échangés les messages Updates, établis le PW et ayant l’interface sur
laquelle est connectée chacun de leur CE au pont "datacenter". Pour remédier
à celà, nous avons analysé le trafic et cherché les protocoles qui étaient activés
sur les ports connectés au pont. Nous avons remarqué que sur les routeurs le
protocole (R)/STP (Spanning Tree Protocol) est activé par défaut sur le pont qui
relie les sites clients.
Pour empêcher le fait que des boucles se fassent continuellement conséquence

du maillage complet de PW, il faut activer sur le pont un protocole d’évitement
de boucle. On a donc trois options pour faire cela :
• Utiliser la fonction de l’horizon de pont qui permet de configurer les ports

du pont avec la configuration horizon de sorte que le paquet reçu sur le port
avec X comme la valeur de l’horizon ne soit pas transmis ou inondé à un
port avec la même valeur d’horizon X. Ainsi, en cas de maillage complet
de PWs VPLS, chaque routeur doit être configuré avec la même valeur
d’horizon pour les PWs VPLS qui servent des sites dans le même pont.
• Utiliser un pont par-feu pour s’assurer que le trafic n’est pas bouclé. Ce qui
implique la configuration du par-feu rendant le pontage moins efficient.
• Activer le protocole (R)/STP pour éviter le bouclage. Cette approche a un

inconvenient. Le protocol (R)/STP désactiverait la transmission par l’un des
tunnels et le garderait pour des fins de sauvegarde. Ce chemin de trafic entre
deux segments aurait à passer par deux tunnels, faisant de la configuration
une configuration inefficace.
Le mieux est donc de choisir la première approche. Pour cela nous avons donc
désactivé le protocole (R)/STP au niveau du pont sur chaque routeur PE. Par la
suite, les 3 CEs ont échangés des informations entre eux.


plusieurs clients
Les différentes configurations effectuées ci-dessus sont faites pour inter-
connecter les sites d’un même client. Nous avons implémenté ici VPLS pour
interconnecter les sites de plusieurs clients (client A et B). Nous avons utilisé
l’architecture de la figure 4.1. Au routeur PE1, sont respectivement connectés
sur les ports Ethernet 1 et 3 de PE1 les routeurs CE_A1 du client A et CE_B1 du
client B et au routeur PE2 sont connectés respectivement sur les ports Ethernet 1
et 3 les routeurs CE_A2 du client A et CE_B2 du client B.
Durant l’étape de configuration de BGP pour la signalisation des PWs VPLS,

un pont est créé sur chaque PE pour chaque client. Ainsi, sur chaque PE nous
avons configuré le pont "A" pour le client A et le pont "B"pour le client B. Aussi,
lors de la création de l’instance VPLS, deux différentes instances VPLS sont
créées au niveau de chaque PE. Pour illustrer, nous prenons l’exemple de PE1
(figure 4.8)
F IGURE 4.8: Configuration de VPLS sur un PE participant à plusieurs domaines

VPLS

Les paramètres export-route-targets et import-route-targets permettent de

spécifier le domaine VPLS auquel appartient l’instance VPLS configurée.

Troisième partie
Résultats et Discussion
70
Chapitre 5
Résultats de
l’implémentation de
BGP-VPLS et Discussion
Le but de ce travail est d’implémenter VPLS dans le réseau BJNet. Pour
réaliser les différents tests nous avons défini une architecture tenant compte de
différents scénari pouvant s’observer dans le réseau BJNet. Dans ce chapitre
nous présentons les résultats des tests effectués sur cette architecture (figure 5.1).
Nous faisons également une discussion par rapport aux résultats obtenus.
5.1 Matériels utilisés pour l’implémentation

de BGP-VPLS
Les tests de validation pour l’implémentation de VPLS ont été effectués avec
les équipements suivants :
• Deux routeurs P (P1 et P2) situés dans le backbone du réseau fournisseur
et qui se connectent par interface à d’autres routeurs au sein de ce même
backbone ou à des routeurs en bordure.
• Trois routeurs PEs : PE1, PE2 et PE3 contrôlés par le fournisseur de services
et situés en bordure du réseau fournisseur.
• Cinq routeurs CEs : les routeurs CE_A1, CE_A2 et CE_A3 font partie
du réseau du client A et les routeurs CE_B1 et CE_B2 appartiennent au
71
CHAPITRE 5. RÉSULTATS DE L’IMPLÉMENTATION DE BGP-VPLS ET DISCUSSION
clientB.
F IGURE 5.1: Architecture physique utilisée pour l’implémentation de VPLS

Le tableau 5.1 présente le plan d’addressage des différents équipements.
TABLE 5.1: Plan d’addressage des différents équipements
Nom de l’équipement Adresses IP et interfaces

CE_A1 ether1 : 192.168.20.1/28
CE_A2 ether1 : 192.168.20.2/28
CE_A3 ether1 : 192.168.20.3/28
CE_B1 ether1 : 192.168.30.1/28
CE_B2 ether1 : 192.168.30.2/28
P1 loopback : 10.10.10.1/32
ether1 : 10.11.10.1/28
ether2 : 10.11.10.18/28
P2 loopback : 10.10.10.2/32
ether1 : 10.11.10.2/28
ether2 : 10.11.10.33/28
ether1 : 10.11.10.49/28
PE1 loopback : 10.10.10.3/32
ether3 : 10.11.10.17/28
PE2 loopback : 10.10.10.43/32
ether3 : 10.11.10.34/28
PE3 loopback : 10.10.10.53/32
ether2 : 10.11.10.50/28

5.2 Résultats de l’implémentation de

BGP-VPLS
Notre implémentation a été soumise à divers tests. Dans nos configurations
nous avons pris le routeur PE3 comme RR. Nous avons implémenté deux do-
maines VPLS sur la même infastructure physique.
5.2.1 Test de l’établissement du maillage des

pseudowires VPLS dynamiquement créés
Sur chacun des PEs, les pseudowires sont dynamiquement créés. L’établisse-
ment dynamique des PWs a été verifié avec la commande /interface vpls print.
Comme exemple prenons le routeur PE1 (figure 5.2) :
F IGURE 5.2: Test sur PE1 de l’établissement du maillage des PWs VPLS

On constate sur la figure qu’on a trois interfaces VPLS BGP dynamiquement

créées et qui fonctionnent ; ce qui se justifie par l’ensemble RBD figurant devant
chaque interface. Aussi, nous constatons que PE1 a établi pour le domaine VPLS
bgp-vpls1 (nom de l’instance VPLS du client B sur PE1 ) deux pseudowires,
un vers PE2 et l’autre vers PE3 ; et pour le domaine VPLS bgp-vpls1 (nom de
l’instance VPLS du client A sur PE1).
5.2.2 Test sur l’échange des messages BGP Update

Nous avons effectué un test sur les routeurs pour vérifier que les messages
Update ont été échangés et les informations qu’ils comportent. Pour preuve nous
prenons le routeur PE1 (figure 5.3) :
F IGURE 5.3: Echange des messages Update : PE1 et PE3

La commande /interface vpls monitor permet d’obtenir l’état d’information

de l’interface d’un PW (extrémité du pseudowire). Sur la figure 5.3, nous voyons
l’état d’information de l’interface du PW établi de PE1 vers PE3 pour le domaine
VPLS du client A. Cette figure montre que la route IGP vers l’adresse virtuelle
de PE3 (10.10.10.5/32) est la route utilisée par PE1 pour atteindre l’adresse
virtuelle de PE3, son voisin BGP (l’adresse vers laquelle il a établit une session
BGP qui permet la mise en place de ce PW). Les labels attachés au paquet VPLS
sont 25 et 17 où 25 est le label assigné par le routeur P1 (10.11.10.18) à la route
10.10.10.5/32 et 17 le label reçu dans le message Update.
5.2.3 Test sur le fonctionnement des domaines VPLS

implémenté
Une fois que les domaines VPLS sont mis en place les routeurs CEs des
client de chaque client s’échange des informations comme s’ils étaient reliés par
un simple pont. Ainsi, des tests ont été faits sur chaque CE de chaque domaine
VPLS pour justifier que l’implémentation fonctionne.
Pour le domaine VPLS du client A, nous avons :
F IGURE 5.4: Test de l’implémentation de VPLS : CE_A1

Nous pouvons constater que les pings de CE_A1 vers CE_A2 et vers CE_A3
passe (figure 5.4).
F IGURE 5.5: Test de l’implémentation de VPLS : CE_A2

Egalement, CE_A2 arrive à joindre les autres routeurs de son domaine :

CE_A1 et CE_A3 (figure 5.5).
Si les routeurs CE_A1 et CE_A2 arrive à joindre respectivement CE_A2 et
CE_A3 ; CE_A1 et CE_A3 alors les routeurs du client A arrive à communiquer
entre eux et nous pouvons donc déduire que le LAN émulé fonctionne. Pour le
client B, nous avons :
F IGURE 5.6: Test de l’implémentation de VPLS : CE_B2

Nous constatons sur le schéma (figure 5.6) que le premier ping (de CE_B2
vers CE_B1) fonctionne ce qui permet de conclure que le domaine VPLS mis
en place pour le client B fonctionne également. Le second ping de CE_B2 est
vers le routeur CE_A2 et nous constatons que la communication ne passe pas,
ce qui est normale puisque les routeurs CE_B2 et CE_A1 sont dans deux VPLS
différents, donc sur deux "LAN" différents.
Des différents tests effectués, nous pouvons conclure que notre implémen-
tation fonctionne et qu’elle répond aux exigences sur le plan évolutivité et
connectivité de couche 2 du réseau BJNet.
5.3 Discussion
La problématique de ce thème est d’offrir des services de couche 2 sur
une infrastructure de couche 3 : cas pratique l’implémentation de VPLS pour
l’interconnexion des sites de BJNet. Le choix de VPLS, une solution de couche
2 pour l’interconnexion des sites de BJNet permet d’étendre le domaine de
diffusion (domaine de broadcast) de couche 2 ce qui favorise ainsi la flexiblité
dans l’emplacement physique des sites pour l’optimisation de l’espace et de la
capacité. En combinant l’effet coût-efficacité de Ethernet avec la livraison du
service, l’ingénierie de trafic, l’évolutivité et la fiabilité de MPLS, VPLS s’est
avéré être un moyen efficace et peu coûteux pour fournir des services multipoint
de couche 2. Il permet particulièrement de fournir à travers un WAN plusieurs
services tels que la vidéo, le VoIP, etc. Avec VPLS, on bénéficie ainsi d’une
agilité améliorée dans la gestion des problèmes informatiques tels que le routage,
la sécurité, etc ; d’une efficacité améliorée ; d’un faible coût et d’une faible
latence.
L’utilisation du protocole BGP pour assurer le plan de contrôle de VPLS

augmente les nombreux avantages qu’apportent VPLS. Il permet une grande
évolutivité et la possibilité d’offrir en même temps que VPLS des services
IP VPN sur la même infrastructure sans altérer ou mélanger ou confondre les
trafics (trafic VPLS et trafic IP VPN) permettant ainsi la réduction du nombre
d’équipements à utiliser.
Bien que l’architecture sur laquelle nous avons effectué nos tests ne corres-
ponde pas effectivement à l’architecture de BJNet, elle présente les différents

scénari qui pourraient se présenter dans le réseau BJNet. Les résultats de nos
tests ont été concluants. Notre méthodologie d’implémentation a permis de faire
communiquer plusieurs sites et d’interconnecter des sites de différents clients
avec les mêmes PEs sans altérer ni interférer le trafic ou les paquets.
L’une des difficultés auquelle nous avons été confrontée au cours de ce travail,
a été d’implémenter VPLS pour l’interconnexion de plus de deux sites avec les
routeurs Mikrotik. La documentation fournie par Mikrotik pour l’implémentation
de BGP-VPLS ne permettant pas de faire communiquer plus de deux sites, nous
avons mené des analyses sur le fonctionnement des différents protocoles (BGP,
LDP-MPLS, ARP) entrant en ligne de compte dans la transmission des paquets.
Ainsi, ces analyses nous ont permis de constacter qu’en plus de la caractéristique
split horizon qui permet d’éviter les boucles dans le trafic, le protocole STP est
également activé ; ce qui empêche le déroulement normale de la fonction de
transmission. Ayant tenu compte de ces analyses et à travers les résultas de nos
différents tests, nous pouvons conclure que notre méthode d’implémentation de
VPLS fonctionne et qu’elle permet de faire communiquer plus de trois sites.
Cependant, nous avons identifié quelques aspects qui pourraient être approfon-
dis.
En premier, BJNet est un réseau WAN réparti sur plusieurs AS et nos travaux
permettent d’implémenter VPLS dans un AS. Les options les plus évolutives et
efficaces d’implémentation de VPLS multi-AS nécessitent que la transmission
MPLS soit effectuée entre le lien qui relie les AS. Une étude pourrait donc être
menée sur le MPLS inter-AS avec les routeurs Mikrotik pour permettre à BJNet
d’avoir la possibilité de fournir le service VPLS pour les clients qui ont leurs
sites répartis dans différents AS.
Ensuite, nos études nous ont permis de constacter que plusieurs autres options
de déploiement de VPLS tels que le multi-hébergement (multi-homing) et le
découplage prévu par la norme ne sont pas encore effectivement implémentable
avec les routeurs mikrotik.
Enfin, BJNet étant un réseau national, il est nécessaire d’assurer une grande
sécurité pour la transmission des informations. Une étude pourrait donc être faite
sur la sécurité avec le protocole BGP et choisir la solution la plus adéquate pour
renforcer cette sécurité.

Conclusion et
Perspectives
Virtual Private LAN Service basé sur BGP est la solution la plus évolutive
qui permet d’étendre un LAN sur plusieurs sites distants à travers un réseau
cœur MPLS. L’infrastructure WAN du réseau BJNet a besoin d’une telle solution
pour permettre à BJNet d’offrir à ses clients une connectivité de couche 2. Aussi,
l’utilisation de VPLS permettrait à certains clients de BJNet comme le RerBenin
la possibilité d’utiliser l’infrastructure physique du réseau BJNet pour mettre
en place leur réseau et leur permettre de gérer sur les plans administratif et
technique ce réseau. De plus, le centre de données de BJNet manifeste également
le besoin d’interconnecter ses deux sites par une connection L2 puisqu’il est
réparti sur deux sites distants ; cette connection permettrait la mise en place
d’un cluster pour permettre d’offrir une certaine disponibilité et la fourniture de
certaines applications comme la migration de machine virtuelle. Notre travail a
été de présenter la technologie VPLS, d’exposer ses avantages et de procéder
au choix de la méthode de déploiement de VPLS la plus adéquate pour BJNet,
d’implémenter VPLS sur une architecture tenant compte de différents scénari
pouvant s’observer dans le réseau BJNet. Nous avons choisi la méthode de
déploiement BGP basé sur VPLS qui est la méthode la plus évolutive de VPLS
et qui permet également l’augmentation de la flexibilité dans le réseau. Nous
avons été confrontée à quelques difficultés lors de l’implémentation de VPLS
dû à l’infrastructure de BJNet constituée d’équipements Mikrotik. En effet,
Mikrotik a implémenté la technologie VPLS mais la mise en place de VPLS pour
l’interconnexion de plus de deux sites ne fonctionne pas. Nous avons surmonté
ce problème en étudiant les différentes informations contenues dans les paquets
81
échangés entre les routeurs. Nous avons ainsi constaté que sur les routeurs qu’en
plus du processus de prévention de boucle split horizon, le protocole Spanning
Tree Protocol, également un processus de prévention de boucle, était activé .
Nous avons choisi le processus split horizon pour empêcher que se produisent
des boucles dans le transfert des paquets et désactivé le protocole STP sur les
routeurs. Split horizon a été choisi en raison de son avantage par rapport aux
autres protocoles d’évitement de boucle. Les résultats que nous avons obtenu
nous ont permis de prouver que par nos choix, nous avons définis la topologie la
plus évolutive, la plus fiable et la plus flexible de BGP-VPLS.
En perspectives, nous proposons d’étudier la question de la sécurité qu’offre

BGP et faire une étude pour comparer les différentes solutions de sécurité
qui accompagnent VPLS et choisir la plus adéquate pour BJNet. Une autre
perspective est l’étude et l’implémentation des options de déploiement d’inter-
AS et de multi-hébergement de VPLS pour le réseau BJNet.

Références
bibliographiques
1. Anderson L. et Rosen E., 2006. Framework for Layer 2 Virtual Private

Networks (L2VPNs). RFC4664.
2. Bates T., Chen E. et ChandraR., 2006. BGP Route Reflection : An Alterna-

tive to Full Mesh Internal BGP (IBGP). RFC4456.
3. David JACQUET, 2009. VPLS (Virtual Private LAN Service) : Emulation

d’un LAN Ethernet par un réseau IP/MPLS. https :
www.technique-ingenieur.fr.
4. Dutta P., Balus F., Stokes O., Calvignac G. et Fedyk D. , 2014. LDP
Extensions for Optimized MAC Address Withdrawal in a Hierarchical
Virtual Private LAN Service (H-VPLS). RFC7361
5. Gandotra Indu, Abrol Pawanesh, Gupta Pooja, Uppal Rohit et Singh San-
deep, 2011. “Cloud Computing Over Cluster, Grid Computing : a Compa-
rative Analysis”, Journal of Grid and Distributed Computing, pp-01-04.
6. Himanshu Shah et al, 2006. IP-Only LAN Service (IPLS). RFC7436.
7. HUAWEI TECHNOLOGIES CO., LTD, VPLS Technology White Paper,

Issue 01, 2012-10-30.
8. Jeff APCAR, 2006. An introduction to VPLS. Cisco.
83
9. Joris Dagbégnon FAGBEMIRO, 2014. Conception d’un environnement

virtuel pour le déploiement d’un centre de données : cas de BJNet, Mé-
moire d’ingénieur de conception, Ecole Polytechnique d’Abomey-Calavi
de l’Université d’Abomey-Calavi.
10. Juha Heinanen, 2004. DNS/L2TP Based VPLS : <draft-heinanen-dns-l2tp-

vpls-01.txt>.
11. Juha Heinanen, 2003. Using Radius for PE-Based VPN Discovery : <draft-
heinanen-radius-pe-discovery-04.txt>.
12. Kompella K. et Rekhter Y., 2007. Virtual Private LAN Service (VPLS)
Using BGP for Auto-Discovery and Signaling. RFC4761.
13. Kothari B., Kompella K., Henderickx W., Balus F., Uttaro J., Palislamovic
S. et Lin W., 2014. BGP based Multi-homing in Virtual Private LAN
Service.draft-ietf-l2vpn-vpls-multihoming-07.txt.
14. LASSERRE M. et KOMPELLA V., 2007. Virtual Private LAN Service

(VPLS) Using Label Distribution Protocol (LDP) Signaling. RFC4762.
15. Martini L., Rosen E., El-Aawar N. et G. Heron, 2006. Encapsulation Me-
thods for Transport of Ethernet over MPLS Networks. RFC4448.
16. Martini L., Rosen E., El-Aawar N., Smith T. et Heron G., 2006. Pseudo-
wire Setup and Maintenance Using the Label Distribution Protocol (LDP).
RFC4447.
17. Muhammad W. et Paresh S., 2006. L2VPN Tutorial :Path to Convergence.

Cisco.
18. Rofiq Fauzi, 2013. Mikrotik Network Simulator.
19. Rosen E., Davie B., Radoaca V. et W. Luo, 2011. Provisioning, Auto-
Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs).
RFC6074.
20. Rosen E. et Rekhter Y., 2006. BGP/MPLS IP Virtual Private Networks

(VPNs). RFC4364.

21. Sajassi A., Salam S., Bitar N. et Balus F., 2013. Virtual Private LAN Service
(VPLS) Interoperability with Provider Backbone Bridges. RFC7080.
22. UZE J-M, 2003. VPLS : Virtual Private LAN Service,

http :.2003.jres.org/actes/paper134.pdf.
23. Virtual Private LAN Service Architectures and Operation, Cisco.
24. Mehul Mehta et Amit Shukla, 2008. Deployment Strategies : Scale and Ex-
tend VPLS with LDP-BGP VPLS Interworking. http ://www.eetimes.com
consulté le 19 octobre 2015.
25. PepelnjakI. et Guichard J., 2001. MPLS AND VPN ARCHITECTURES :

Cisco Press.

Annexe
86
Les configurations effectuées sur les

différents routeurs du backbone pour
l’implémentation de VPLS
Configurations sur PE1
/interface bridge
add name=A protocol-mode=none
add name=B protocol-mode=none
add name=lo
/routing ospf instance
set [ find default=yes ] redistribute-connected=as-type-1
/interface bridge port
add bridge=A interface=ether1
add bridge=B interface=ether2
/interface vpls bgp-vpls
add bridge=A bridge-horizon=1 export-route-targets=1 :1 import-route-targets=1 :1
name=bgp-vpls1 route-distinguisher=1 :1 site-id=1
add bridge=B bridge-horizon=1 export-route-targets=2 :2 import-route-targets=2 :2
/ip address
add address=10.10.10.3 interface=lo network=10.10.10.3
add address=10.11.10.17/28 interface=ether3 network=10.11.10.16
/mpls ldp
set enabled=yes lsr-id=10.10.10.3 transport-address=10.10.10.3
/mpls ldp interface
add interface=ether3
/routing bgp peer
add address-families=l2vpn name=PE3 remote-address=10.10.10.5 remote-as=65530
update-source=lo
/routing ospf network
add area=backbone network=10.11.10.16/28
/system identity
set name=PE1


/interface bridge
add name=lo
add bridge=B interface=ether2
add bridge=B bridge-horizon=1 export-route-targets=2 :2 import-route-targets=2 :2
/ip address
/mpls ldp
/mpls ldp interface
/routing bgp peer
update-source=lo
/system identity
set name=PE2

/interface bridge
add name=lo


/ip address
/mpls ldp
/mpls ldp interface
/routing bgp peer
route-reflect=yes update-source=lo
route-reflect=yes update-source=lo
/system identity
set name=PE3
Configurations sur P1
/interface bridge
add name=lo
/ip address
/mpls ldp

/mpls ldp interface

/system identity
set name=P1
Configurations sur P2
/interface bridge
add name=lo
/ip address
/mpls ldp
/mpls ldp interface
/system identity
set name=P2

Summary
91
Topic
VPLS implementation on BJNet to offer Layer 2 services
92
Introduction
Ethernet is a LAN technology (Local Area Network), the most widely de-
ployed in existing networks. In recent years Ethernet standards have evolved
very significantly, on the one hand as regards the flow rate managed by this
technology, with an impressive growth of 10 Mb / s to 100 Gb / s, and on the
other hand by protocol enhancements to extend the use of Ethernet in the WAN
environment : MAN (Metropolitan Area Network) or WAN (Wide Area Net-
work) (Uze JM, 2003). Also with the changing economic world, many structures
cover increasingly larger distances to provide quality services to a wide customer
base. These structures therefore looking for ways, reliable and secure, which
would allow them to exchange data with remote sites.
Originally, service providers filled this need by providing leased lines, but
leased lines have significant disadvantages such as : the costs of setting up and
lease lines, and material costs (installation and maintenance routers). Several
other technologies (ATM, Frame Relay, MPLS) using packet switching technique
have appeared. But none of these technology not fully satisfied business needs.
Virtual Private LAN Service is a network technology that connects toge-
ther several individual LANs across a packet-switched network, appearing and
functioning as a single LAN (Anderson L. and E. Rosen, 2006). It supports a
multipoint-to-multipoint communication and proved to be a better solution for
service providers. Several structures and service providers adopt this solution.
BJNet is a national-wide network for Benin country that must provide a
number of services to its clients including layer 2 services (OSI). Also, BJNet
data center is geographically distributed over two locations. Both should be
connected to be considered in a single LAN given the cluster set up and some
applications (migration of virtual machines, etc.), hence the need to implement
VPLS. BJNet wants an MPLS-based implementation architecture and protocols
favoring network scalability.
Given the cluster set up in the data center and to the availability of certain
applications (migration of virtual machines, etc.), two sites must be intercon-
nected by a layer 2 connectivity that is considered to be in a same LAN hence
the need to implement VPLS. And with MPLS BJNet can satisfy its customers
expressing the desire to interconnect their infrastructure with a layer of connec-
tivity 2. The advantage VPLS promote flexibility allow BJNet deliver Layer 2
93
Summary
services to some structure or organization as RerBenin (network of Education

and Research of Benin) and enable them to ensure the technical management
such as routing, security and administration of their network. It is desired for BJ-
Net a VPLS-based implementation architecture and protocols to allow network
scalability.
The aim of this memoir is to implement VPLS in the BJNet VPLS network
to offer of the OSI layer 2 services.
1 Project overview
1.1 Context, justification and problematic

BJNet is an infrastructure network enabling the interconnection of all struc-
tures of public administration. In addition, the network can provide many services
including Internet access to all its infrastructure facilities operator. This network
is national ; its infrastructures are therefore present in all departments and cover
much of the towns of Benin.
For centralizing data, BJNet has a data center. This data center is distributed
over two locations one at the University of Abomey (UAC) and the other at
Camp Guezo. BJNet wishes to offer a number of services to these clients. It is
therefore implemented a cluster to ensure good service availability in the data
center. Clusters define a collection of machines (servers) that operate as if they
were a single machine. The main goal of high availability (HA) cluster is to
provide uninterrupted access to data, even if a server loses network connectivity
or storage, or completely fails, or if the application running on the server fails
. One of cluster’s the requirements is that the cluster nodes in the cluster is
interconnected by a private network ie they are in the same Ethernet network
(Gandotra Indu et al., 2011). VPLS is one of the solutions that interconnect
several remote sites as if they were in the same LAN.
Moreover, BJNet as a service provider must provide the ability to structures
it interconnects, to interconnect their sites, to establish and manage their routing
and security policy. RerBenin is a research network or NREN (National Research
and Education Network) to interconnect all public and private universities of
Benin, it has several objectives : improving the quality of training and research,
democratization access to information and sharing of knowledge, the sharing of
educational resources and research, digital governance through the development

Summary
of e-services and the mobility of students, teachers and administrative staff.

ReRBenin is part of the largest network NREN as WACREN (West And Central
African Research and Education Network), a NREN network on the african plan.
This network can be considered as a WAN with specific routing protocols. The
BJNet physical infrastructure can be used to ReRBenin to interconnect universi-
ties. But BJNet must allow ReRBenin the possibility to manage his routing and
security policy.This possibility will be effective if BJNet VPLS uses for these
interconnections.
2 Virtual Private LAN Service
2.1 Overview
VPLS is a Layer 2 multipoint VPN that emulates LAN service across a WAN.
VPLS enables service providers to interconnect several customer sites (each
being a LAN segment) over a packet-switched network, effectively making all
the customer LAN segments behave as one single LAN. A service provider’s
network appears as an Ethernet bridge to the service provider’s customers using
VPLS. With VPLS, no routing interaction occurs between the customer and
service providers, and the customer can run any type of Layer 3 protocols
between sites. The IETF Layer2 VPN Working Group has two VPLS standards :
RFC 4761 and RFC 4762. Though they are almost identical approaches with
respect to the VPLS forwarding plane, they are very different approaches to the
VPLS control plane.
2.2 VPLS Control Plane

The VPLS control plane has two primary functions : autodiscovery and
signaling.
• Discovery refers to the process of finding all the PE routers that participate
in a given VPLS instance. A PE router can be configured with the identities
of all other PE routers in a given VPLS instance, or the PE router can use a
protocol to automatically discover the other PE routers. This latter method
is called autodiscovery.
newline

Summary
• After discovery occurs, each pair of PE routers in a VPLS must be able to

establish and tear down pseudowires to each other. This process is known
as signaling. Signaling is also used to transmit certain characteristics of the
pseudowire that a PE router sets up for a given VPLS.
BGP-VPLS Control Plane
The BGP-VPLS control plane defines a means for a PE router to know which
remote PE routers are members of a given VPLS (autodiscovery), and for a PE
router to know the pseudowire label expected by a given remote PE router for a
given VPLS (signaling). The BGP NLRI contains enough information to provide
the autodiscovery and signaling functions simultaneously.
As in the BGP scheme for Layer 2 and Layer 3 VPNs, on each PE router
a route target is configured for each VPLS. The route target is the same for a
particular VPLS across all PE routers and is used to identify the VPLS to which
an incoming BGP message pertains.
LDP-VPLS Control Plane

The LDP signaling scheme for VPLS is similar to the LDP scheme for point-
to-point Layer 2 connections. LDP is used for signaling the pseudowires that are
used to interconnect the VPLS instances of a given customer on the PE routers.
In the absence of an autodiscovery mechanism, the identities of all the remote
PE routers that are part of a VPLS instance must be configured manually on each
PE router.
2.2 VPLS Data Plane

The data plan is to describe how the client traffic is routed by routers. It will
be necessary to know how clients are encapsulated frames to be transmitted by
the PE and P routers to their destination. It includes several functions including :
encapsulation and forwarding packets. In our case, so we will describe how this
traffic is routed from one end to the other of the MPLS network.
The encapsulation of VPLS packets is described by RFC4448. It defines how
to carry Layer 2 frames over point-to-point pseudowires. Client Ethernet frames
arriving on the input interface of PE are encapsulated as follows :
• Adding a control word (optional Ethernet) ;
• Header MPLS corresponding to the pseudowire label ;

Summary
• Header MPLS corresponding to the tunnel label.
VPLS packets are classified as belonging to a given service instance and

associated forwarding table based on the interface over which the packet is
received. Packets are forwarded in the context of the service instance based on the
destination MAC address. The former mapping is determined by configuration.
Several other functions are used to define the data plane which are : MAC
Address Learning, Flooding, Loop avoidance, MAC Address Aging.
3 Methodology
3.1 VPLS method of deployment choice

BGP based VPLS control plane is chosen for the implementation of VPLS
because it the most scalable solution.
BGP based autodiscovery and signaling of VPLS tunnels can help to avoid
complexity of configuration at the expense of running BGP protocol between
VPLS routers. The use of a Route-Reflector allow to avoid a full mesh of all the
PEs and to have a better scaling and flexibility.
3.2 Tools
Table 5.1 provides information on the tools used. Thus, we find not only the
version of the tools but also the work that arise.

Summary
TABLE 5.2: Tools used
Tools Version Comments

Mikrotik Route- 6.32 Mikrotik routers OS ,
rOS chosen to allow the use
of virtual routers
Qemu 0.14.1 Qemu is an emulation
and virtualization solu-
tion like VirtualBox and
VMWare
GNS3 1.3.10 GNS3 is a simulator for
creating complex topolo-
gies on a computer and
simulate
3.2 VPLS implementation

We used this architecture for implementing VPLS :
F IGURE 5.7: Architecture used for VPLS implementation

Summary
MPLS Switching configuration

For implement VPLS, we have at first config MPLS switching. To implement
MPLS, it must be configured on core routers a loopback interface to be used
by LDP to establish sessions. We config the loopback address to all PEs like as
show on PE1 :
/interface bridge add name=lo

/ip address add address=10.10.10.3/32 interface=lo
LDP by default distributes labels for active IGP routes. As IGP routing
protocol, we have chosen OSPF. We configure OSPF on all routers. For example
take P1 :
/routing ospf instance set 0 redistribute-connected=as-type-1

Now we can configure LDP for allow dynamic distribution of MPLS label.
LDP has been configured on all PEs which are in the backbone MPLS. For
example on P2 we maked :
/mpls ldp set enabled=yes lsr-id=10.10.10.2 transport-address=10.10.10.2

/mpls ldp interface
VPLS configuration
The control plane protocol is BGP. The rest of configuration is done on the
PE routers. We configure IBGP session on the all PEs. We chose PE3 for route
reflector. Then, one peer is established with in PE3 and PE1 and another peer is
established owith in PE3 et PE2. On the PE3 we proceeded as follows :

Summary
/routing bgp peer add remote-address=10.10.10.3 remote-as=65530 update-

source=lo name=PE1 route-reflect=yes address-families=l2vpn
/routing bgp peer add remote-address=10.10.10.4 remote-as=65530 update-
source=lo name=PE2 route-reflect=yes address-families=l2vpn
On the other PEs the configurations of IBGP session have been the same
except that on PE1 and PE2 the parameter route-reflect=no because they are not
RR.
We are then configured BGP signalisation on the PEs. To deliver seamlessly
packets from the Ethernet segment across VPLS, a AC must be configured. We
have chosen to configure a bridge that will connect sites. A bridge is created
on each PE for each site. As there are two customers on PE1 and PE2, we have
configured two bridges (A and B) on them and one bridge on PE3. On PE2 me
have done :
/interface bridge add name=A protocol-mode=none

/interface bridge add name=B protocol-mode=none
/interface bridge port add bridge=A interface=ether1
/interface bridge port add bridge=B interface=ether2
We configure VPLS instance on the router. The configuration of VPLS ins-

tance allows the router to make the announcement that the BGP NLRI announce
that a particular router belongs to such VPLS. Upon receipt of this announce-
ment, other members of the same VPLS know they must establish PW VPLS
with this router. Sur PE1, we have proceeded like that :
/interface vpls bgp-vpls add bridge=A bridge-horizon=1

export-route-targets=1 :1 import-route-targets=1 :1 route-distinguisher=1 :1
site-id=1
/interface vpls bgp-vpls add bridge=B bridge-horizon=1
export-route-targets=2 :2 import-route-targets=2 :2 route-distinguisher=2 :2
site-id=1
3 Results
We performed multiple tests on our implementation.

Summary
F IGURE 5.8: Test of VPLS implementation : CE_A1
We can see that CE_A1 ping CE_A2 et CE_A3 .
F IGURE 5.9: Test of VPLS implementation : CE_A2
We see here that CE_A2 ping CE_A1 et CE_A3. We can conclude that
our implementation is fonctionnel and allow scalability and flexibility on one
network. We can also say that unlike other methods of implementation method
allows to extend a LAN over VPLS with two sites.

Summary
Conclusion and perspectives

Virtual Private LAN Service based on BGP is the most scalable solution
that can extend a LAN across multiple remote sites through a core MPLS
network. The infrastructure BJNet WAN network needs such a solution to allow
BJNet to offer its customers a connectivity layer 2. Also, the use of VPLS
allow some BJNet’s customers as RerBenin the possibility of use the physical
infrastructure of BJNet network to set up their network and allow them to manage
on administrative and technical network. The ReRBénin is a research network to
interconnect all public and private universities of Benin, it has several objectives
including improving the quality of training and research, the democratization
of access to information and better sharing of knowledge. In addition, the data
center of BJNet also reflected the need to interconnect both locations by an L2
connection since it is spread over two sites ; this connection would allow the
establishment of a cluster to allow to provide some availability and provision of
certain applications such as the migration of virtual machine. Our work was to
present the VPLS technology, to expose its advantages and proceed to the choice
of the most appropriate VPLS deployment method BJNet, implement a VPLS
architecture taking into account different scenarios that can be observed in BJNet
the network. We chose the BGP deployment method based on VPLS which is
the most scalable method VPLS and which also allows increased flexibility in
the network. We faced some difficulties during the implementation of VPLS
due to infrastructure BJNet consist of Mikrotik equipment. Indeed, Mikrotik
implemented the VPLS but the establishment of VPLS for interconnecting more
than two sites do not operate. We have overcome this problem by studying the
various information contained in the packets exchanged between routers. We
have found that on the routers in addition to the loop avoidance process split
horizon was enabled the Spanning Tree Protocol which is also an avoidance loop
process. We chose the process split horizon to prevent loops occur in the transfer
of packets and off STP on the routers. Split horizon was chosen because of its
advantage over other loop avoidance protocols. The results we got allowed us to
prove that our choices we have defined the most scalable topology, most reliable
and most flexible of BGP-VPLS.

Table des matières
Sommaire i
Dédicace iii
Remerciements iv
Liste des tableaux vi
Table des figures vii
Liste des sigles et abbréviations ix
Résumé xiv
Abstract xv
Introduction 1
I Synthèse bibliographique 5
1 Etude de l’existant 6
1.1 Présentation de BJNet . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Objectifs de BJNet . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Centre de données de BJNet . . . . . . . . . . . . . . . . . . . . 8
2 La technologie VPLS 10
2.1 Virtual Private Network . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 L2VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
103
TABLE DES MATIÈRES
2.2 Généralité sur VPLS . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.1 Origine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.3 Cas d’utilisation de VPLS . . . . . . . . . . . . . . . . . . 22
2.3 Protocoles et Architectures de VPLS . . . . . . . . . . . . . . . . 22
2.3.1 Plan de contrôle de VPLS . . . . . . . . . . . . . . . . . . 22
2.3.2 Plan de données de VPLS . . . . . . . . . . . . . . . . . . 28
2.3.3 Architecture VPLS . . . . . . . . . . . . . . . . . . . . . . 32
2.4 Fonction avancées . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.1 Inter AS et Inter domaine . . . . . . . . . . . . . . . . . . 34
2.4.2 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.3 Multi-hébergement . . . . . . . . . . . . . . . . . . . . . . 36
2.4.4 Découplage ou non des PEs . . . . . . . . . . . . . . . . . 36
2.5 Avantages de l’utilisation de VPLS . . . . . . . . . . . . . . . . . 37
2.5.1 Technologies permettant d’interconnecter plusieurs sites . . 37
2.5.2 Avantages de VPLS . . . . . . . . . . . . . . . . . . . . . 39
II Approche méthodologique 41
3 Choix de la méthode de déploiement de VPLS 42
3.1 Analyse des différentes méthodes de déploiement de VPLS . . . . 42
3.1.1 Gestion de la connectivité entre les PEs . . . . . . . . . . . 42
3.1.2 Fourniture du service VPLS . . . . . . . . . . . . . . . . . 43
3.1.3 Echange de l’état d’information des Pseudowires . . . . . . 44
3.1.4 Comparaison entre LDP-VPLS et BGP-VPLS . . . . . . . 45
3.2 Présentation de quelques fonctions de VPLS basé sur BGP . . . . 47
3.2.1 Terminologie BGP . . . . . . . . . . . . . . . . . . . . . . 47
3.2.2 Découverte automatique . . . . . . . . . . . . . . . . . . . 48
3.2.3 Signalisation . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.4 Fonctionnement BGP-VPLS . . . . . . . . . . . . . . . . . 51
3.3 BGP VPLS hiérarchique . . . . . . . . . . . . . . . . . . . . . . 52
4 Méthodologie d’implémentation de BGP-VPLS 54

4.1 Les outils de base . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.1.1 Mikrotik RouterOS . . . . . . . . . . . . . . . . . . . . . 54
4.1.2 GNS3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

TABLE DES MATIÈRES
4.1.3 Qemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2 Implémentation de BGP-VPLS pour l’interconnexion de deux
sites (cas du centre de données) . . . . . . . . . . . . . . . . . . . 57
4.2.1 Matériels utilisés . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.2 Implémenter MPLS dans le backbone . . . . . . . . . . . . 59
4.2.3 Configuration de VPLS . . . . . . . . . . . . . . . . . . . 62
4.3 Implémentation de BGP-VPLS pour l’interconnexion de trois sites 65
4.4 Implémentation de BGP-VPLS pour plusieurs clients . . . . . . . 68
III Résultats et Discussion 70

5 Résultats de l’implémentation de BGP-VPLS et Discussion 71
5.1 Matériels utilisés pour l’implémentation de BGP-VPLS . . . . . . 71
5.2 Résultats de l’implémentation de BGP-VPLS . . . . . . . . . . . 74
5.2.1 Test de l’établissement du maillage des pseudowires VPLS
dynamiquement créés . . . . . . . . . . . . . . . . . . . . 74
5.2.2 Test sur l’échange des messages BGP Update . . . . . . . . 75
5.2.3 Test sur le fonctionnement des domaines VPLS implémenté 76
5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Conclusion et Perspectives 81
Références bibliographiques 83
Annexe 87
Summary 92
Table des matières 103

Diplome D'Ingenieur de Conception: 8 Promotion

Transféré par

Droits d'auteur :

Formats disponibles

Diplome D'Ingenieur de Conception: 8 Promotion

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

Diplome D'Ingenieur de Conception: 8 Promotion

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE DU BENIN

MEMOIRE DE FIN DE FORMATION

DIPLOME D’INGENIEUR DE CONCEPTION

IMPLEMENTATION DE VPLS DANS LE CENTRE DE

Réalisé par : Valerie Zita Alida Murielle de Dieu ASSOGBA WOUNON

Président : Dr. Michel DOSSOU Maître-Assistant CAMES

Année Académique : 2014-2015

Liste des tableaux vi

Table des figures vii

Liste des sigles et abbréviations ix

4 Méthodologie d’implémentation de BGP-VPLS 54

III Résultats et Discussion 70

Réalisé par Valerie ASSOGBA WOUNON ii

Ma mère Clotilde T. GUIDI

Reçois l’expression de ma profonde gratitude, amour et affection pour la

Mon père Irénée K. ASSOGBA WOUNON

Ma soeur Nadège ASSOGBA WOUNON

Et à tous ceux qui me sont chers.

? Au Professeur Félicien AVLESSI, Directeur de l’Ecole Polytechnique

? Au Professeur Marc Kokou ASSOGBA, chef du département de Génie

? A mon maître de mémoire, Lieutenant Bidossessi R. ALAHASSA, qui a

? A l’ensemble du corps enseignant de l’EPAC ;

? Au docteur Michel DOSSOU, pour les conseils qu’il m’a prodigués ;

? Au directeur de l’Agence Béninoise des Technologies de l’Information et

? Au docteur Victorin CHEGNIMONHAN, à Prosper TONATO, pour m’avoir

? A Isaac TOVIESSI, à M. BAKARY, à Marius ESSE, à Eric TOVIESSI, à

? A mes tantes particulièrement Bibiane GUIDI, oncles, cousins particulière-

? à tous les amis de ma promotion particulièrement ceux du Génie Informa-

Réalisé par Valerie ASSOGBA WOUNON v

2.1 Comparaison des technologies de couche 2 étendant un LAN . . . . 39

3.1 Comparaison des solutions VPLS . . . . . . . . . . . . . . . . . . . 46

4.1 Outils de base utilisés . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.1 Plan d’addressage des différents équipements . . . . . . . . . . . . . 73

1.1 Architecture du centre de données de BJnet . . . . . . . . . . . . . . 9

2.1 Classification des VPNs . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 BGP NLRI pour VPLS . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1 Architecture utilisés pour la mise en place du réseau MPLS . . . . . 57

5.1 Architecture physique utilisée pour l’implémentation de VPLS . . . . 72

5.6 Test de l’implémentation de VPLS : CE_B2 . . . . . . . . . . . . . . 78

Réalisé par Valerie ASSOGBA WOUNON viii

BGP : Border Gateway Protocol

DECnet : Digital Equipment Corporation networks

EBGP : External Border Gateway Protocol

FEC : Forwarding Equivalency Class

GRE : Generic Routing Encapsulation

IBGP : Interior Border Gateway Protocol

Réalisé par Valerie ASSOGBA WOUNON x

MAN : Metropolitan Area Network

OSI : Open System Interconnection

Réalisé par Valerie ASSOGBA WOUNON xi

QoS : Quality of Service

SAII : Source Attachment Individual Identifier

Réalisé par Valerie ASSOGBA WOUNON xii

TAII : Target Attachment Individual Identifier

VBO : VE Block Offset

WAN : Wide Area Network

Réalisé par Valerie ASSOGBA WOUNON xiii

Mot-clés : MPLS, VPLS, BGP, Ethernet, VPN.

Key-words : MPLS, VPLS, BGP, Ethernet, VPN.

Provider Edge (PE)

Customer Edge (CE)

Attachment Circuit (AC)

Packet Switched Network Tunnel (PSN tunnel)

Type de traffic transporté

Evolutivité des PEs