Conception et mise en place d'une architecture VPN/MPLS avec gestion de la GOS. Cas de Matrix Télecoms.

Université de Maroua
****
Institut Supérieur du Sahel
****
Département d'Informatique et
des Télécommunications
****

The University of Maroua **** The Higher Institute of the Sahel **** Department of Computer Science and Telecommunications ****

INFORMATIQUE ET TELECOMMUNICATIONS

CONCEPTION ET MISE EN PLACE D'UNE
ARCHITECTURE VPN/MPLS AVEC GESTION DE LA
QOS : CAS DE MATRIX TELECOMS

Mémoire présenté et soutenu en vue de l'obtention du Diplôme d'INGENIEUR DE CONCEPTION EN RESEAU

Par
SOH TCHENDJOU GHISLAIN
Licence en Ingénierie de Télécommunications et Réseaux Mobiles
Matricule : 14A171S

Sous la direction de :

Dr. Olivier VIDEME BOSSOU
Chargé de Cours

Devant le jury composé de :

Président : Pr. MOTAPON Ousmanou Rapporteur : Dr. Olivier VIDEME BOSSOU

Examinateur : Pr. EMVUDU WONO Yves Sébastien

Invité : Ing. NTAMI NGUEMBOU Caleb

Année Académique 2015 / 2016

DEDICACE

A

LA FAMILLE TCHENDJOU

II

REMERCIEMENTS

Nous saisissons cette occasion qui nous est offerte à travers la rédaction de ce rapport du projet de fin d'étude pour manifester notre reconnaissance à l'égard de tous ceux qui de près ou de loin ont contribué à sa réalisation. Nous pensons ainsi :

> Au Président du Jury Pr. MOTAPON Ousmanou : pour avoir accepté de présider ce Jury.

> A l'examinateur Pr. EMVUDU WONO Yves Sébastien : pour avoir accepté d'évaluer ce travail.

> A mes encadreurs : académique Dr. Olivier VIDEME BOSSOU et professionnel Ing. NTAMI NGUEMBOU Caleb pour le soutien et les précieux conseils. > Au Directeur de l'ISS de MAROUA Pr. DANWE RAÏDANDI.

> Au corps enseignant et administratif de l'ISS pour l'effort fourni pour notre formation.

> A mess parents M. et Mme TCHENDJOU pour leur soutien.

> Au personnel de Matrix Télécoms Yaoundé, et en particulier à ceux de l'unité CSG pour l'accueil très chaleureux qu'ils m'ont réservés.

> A Carlos KAKAILE Responsable technique Matrix Télécoms Yaoundé pour ses encouragements et ses conseils qu'il nous a apporté durant notre stage.

> A toute ma famille pour tous les sacrifices, le soutien et l'amour dont j'ai bénéficié durant ma formation ; je pense à mes frères et soeurs Patrick, Gaëlle, Carine et Francis

> A mes amis : Rodrigue, Olivier, Stéphanie, Daniella, Borel, maxime, Wilfried, Suina, Fatime, Ibrahima, Moussa, Abdou, bridge.

> A tous mes camarades de Master INFOTEL 2015-2016

A tous ceux qui ne trouveront pas leurs noms ici, nous leurs sommes très reconnaissant pour le soutien apporté par chacun d'eux durant tout notre parcours.

III

TABLE DES MATIERES

DEDICACE i

REMERCIEMENTS ii

TABLE DES MATIERES iii

LISTE DES SIGLES ET ABREVIATION vi

GMPLS: Generalized Multi-Protocol Label Switching vi

RESUME ix

ABSTRACT x

LISTE DES TABLEAUX xi

LISTE DES FIGURES ET ILLUSTRATIONS xii

INTRODUCTION GENERALE 1

CHAPITRE I : CONTEXTE ET PROBLEMATIQUE 2

I.1. Présentation du lieu de stage (Matrix Télécoms) 2

I.1.1 Historique 2

I.1.2. Fiche signalétique 2

I.1.3. Plan de localisation 3

I.1.4. Organigramme 4

I.1.5. Services offerts 4

I.2. Contexte et problématique 5

I.3. Méthodologie 6

I.4. Objectifs 6

CHAPITRE II : GENERALITES SUR LE PROTOCOLE VPN/MPLS 8

II.1 Historique et Présentation du MPLS 8

II.1.1 Historique de MPLS 8

II.1.2 Présentation 8

II.2. Concept de base et Architecture MPLS 9

II.2.1 Concept de base 9

II.2.2 Architecture du Protocole MPLS 10

II.3 Présentation des Labels 11

II.3.1 Le Label dans les autres Réseaux étendus 12

iv

II.3.2 Le transport des labels 12

II.4 Commutation des labels 12

II.5 Méthode de distribution des labels et le protocole LDP [5] 14

II.5.1 La méthode Implicit Routing [5] 14

II.5.2 La méthode Explicit Routing [5] 14

II.5.3 Le protocole LDP 15

II.6 Protocole de signalisation 16

II.7 Mode de fonctionnement des VPNs [4] 16

II.7.1 Généralités [4] 16

II.7.2 Les types d'utilisation de VPN [4] 16

II.7.3 Protocoles utilisés pour le VPN [4] 17

II.8 Les Applications de la Technologie MPLS 17

II.8.1 Les VPN MPLS 17

II.8.2 La QOS 18

II.8.2.1 IntServ 19

II.8.2.2 DiffServ 19

II.8.3 Traffic Engineering 21

II.9 Evolutions du MPLS [6] 22

II.9.1 GMPLS [6] 22

II.9.2 VPLS [6] 22

Chapitre III : CHOIX ET IMPLEMENTATION DE LA SOLUTION VPN /MPLS 24

III.1 Cahier des charges 24

III.1.1. Présentation du Projet 24

III.1.2. Les Objectifs 24

III.2 L'architecture de Matrix Télécoms 25

III.2.1. Etude de l'architecture logique globale de Matrix Télécoms 25

III.2.2. Identification des POPs de Matrix Télécoms au sein de Yaoundé 25

III.3 Etude du matériel Cisco intégrant le MPLS 26

III.3.1 Choix du Matériel intégrant le MPLS 26

III.3.2. Solution Retenue 27

III.4 Le protocole de Routage 28

III.4.1 Choix du protocole de Routage au sein du Coeur du Réseau 28

III.4.2. Solution retenue 29

V

III.4.3. Le protocole de Routage externe 29

III.4.4 Choix du protocole pour implémenté le VPN 30

III.5 Implémentation de la solution VPN/MPLS 33

III.5.1. Présentation de la maquette de notre réalisation 33

III.5.2 Plan d'adressage 33

III.5.3 Configuration des interfaces 35

III.5.4. Le routage OSPF au sein du coeur du réseau MPLS 35

III .5.5 Mise en place des VRF sur les routeurs LERMatrix 1 et LERMatrix 2 35

III.5.6 Configuration du routage EIGRP 36

III.5.7 Activation du protocole MPLS sur les routeurs du coeur du Réseau 37

III.5.8 Mise en place du protocole MP-BGP 38

III.5.9. Gestion de la redistribution respective des préfixes sur les routeurs LER 39

III.5.10. Configuration du traffic Engineering sur les Routeurs du coeur du Réseau 40

III.5.11 Gestion de la QOS 43

III.5.11.5 Allocation de la bande passante 46

Chapitre IV : TEST DE FONCTIONNEMENT DE LA SOLUTION

IMPLEMENTEE 48

IV.1 Résultats concernant le MPLS 48

IV.1.1 Test du MPLS un routeur 48

IV.1.2 Test du MPLS à travers Wireshark 49

IV.1.3 Visualisation de la table de MPLS 49

IV.2 Test de Protocole de routage implémenté 50

IV.3 Vérification des labels 50

IV.4 Résultats concernant le MPLS Traffic Engineering 51

IV.5 Résultats concernant le VPN 53

IV.6 Résultats concernant QOS 54

CONCLUSION GENERALE ET PERSPECTIVES 55

Bibliographie 56

ANNEXES 58

vi

LISTE DES SIGLES ET ABREVIATION

AS : Autonomous System

ATM: Asynchronous Transfer Mode BGP: Border Gateway Protocol

CA: Chargé d'Affaire

CR-LDP: Constraint-based Routing Label Distribution Protocol

CSG & INFRA: Customer Service Group & Infrastructure DCE: Data Circuit Equipment

DG (ADG/DGA) : Direction général (Administrateur Directeur Général/Directeur Général Adjoint)

DiffServ: Differentiated Services

DMC : Direction Marketing et Commerciale DRH: Direction des ressources humaines

DS/SUY : Directeur Succursale Yaoundé

DSCP: Differentiated Services Code Point

DSD : Direction Succursale Douala

DSI : directeur des systèmes d'informations.

DSY : Direction Succursale Yaoundé

DT (DTA/ADT) : Direction Technique (Directeur Technique Adjoint/ Administrateur

Directeur Technique)

DT: Directeur technique

EGP: Exterior Gateway Protocol

EIGRP: Extended Interior Gateway Routing Protocol FAI : Fournisseur d'Accès à Internet

GMPLS: Generalized Multi-Protocol Label Switching HDLC: High-Level Data Link Control

IBM: International Business Machines

vii

ICCNET: International Computer Center Network

IETF: Internet Engineering Task Force

IGP: Interior Gateway Protocol

IOS: Internetwork Operating System

IP: Internet Protocol

IS-IS: Integrated Intermediate System to Intermediate System

L2VPN: Layer 2 Virtual Private Network

LAP B: Link Access Protocol

LDP: Label Distribution Protocol

LER: Label Edge Router

LFIB: Label Forwarding Information Base

LSP: Label switched path

LSR: Label switching Router

MPLS: Multi-Protocol Label Switching

MPLS-TE: Multi-Protocol Label Switching Traffic Engineering

NOC: Network Operating Center

OSPF: Open Shortest Path First PHP : Penultimate Hop Popping PDC : Palais de congres

VIII

QoS: Quality of Service

RFC: requests for comments

RSCRY : Responsable Clientèle et Recouvrement Yaoundé

RSVP-TE: Reservation Protocol - Traffic Engineering

RTP: Real-Time Transport Control Protocol

SIP: Session Initiation Protocol

TCP: Transmission Control Protocol

TDP: Tag Distribution Protocol

TE: Traffic Engineering

VCI: Virtual Channel Identifier

VoIP: Voice over Internet Protocol

VPLS: Virtual Private Local area network Services

VPN: Virtual Private Network

VRF: Virtual Routing and Forwarding

WAN: Wide Area Network

RESUME

Dans ce mémoire il est question de pouvoir identifier comment optimiser le processus de routage dans le réseau interne de Matrix Télécoms car avec le protocole IP les décisions de routage d'un paquet sont faite localement par chaque noeud et ce qui n'est pas optimal au sein de Matrix Télécoms. Il est question de pouvoir améliorer l'utilisation de la bande passante et une meilleure gestion de la QoS au sein du réseau coeur de Matrix Télécoms et enfin de leur proposer une façon d'apporter une amélioration sur le VPN qu'il fournisse. Les réseaux opérateurs comme Matrix Télécoms ont besoin de plus de certitude quant au routage du trafic. Nous avons opté pour le choix du protocole MPLS car il nous permet de combler tous les attentes énumérées plus haut par cette structure. Le MPLS dois nous permettre d'interconnecter tous les différents POP de Matrix Télécoms au sein de la ville de yaoundé. C'est ainsi que le MPLS nous a permis d'établir un chemin qui prend en compte l'utilisation actuelle du débit des liens afin d'optimiser la bande passante et éviter la congestion à travers le Traffic Engineering. MPLS nous a permis d'autoriser un flux à être acheminé en garantissant le respect de certaines contraintes à travers son protocole DiffServ implémenté qui est recommandé pour la gestion de la QoS au sein du réseau coeur. Ainsi grâce à MPLS nous avons pu intégrer une fonctionnalité de réaliser et mettre en place le VPN au sein de Matrix Télécoms. Nous avons donc implémenté une solution à travers une maquette pour pouvoir mettre en évidence ce protocole MPLS. Nous avons utilisé le logiciel de Simulation GNS3, les IOS des routeurs Cisco de version 7200 car c'est cette version qui intégre bien notre MPLS et des machines virtuelles notamment un serveur Debian où se trouve quelques services configurés notamment le SMTP, VOIP et FTP, enfin des machines Windows 7 et Windows XP pour des éventuels tests de connectivité entre les deux sites clients.

Nous pouvons dire que le but était de pouvoir mettre en place une architecture MPLS/VPN fonctionnelle et qui pourra intégrer un Traffic Engineering et une QOS fonctionnelle pour d'éventuelles démonstrations.

ix

Mots clés: MPLS, VPN, Traffic Engineering, QOS

X

ABSTRACT

This report is about identifying how to optimize the routing process in the internal network of Matrix Telecoms. An IP routing decision of a package is made locally by each node and this is not optimal in Matrix Telecom. It is also about how to improve the usage of bandwidth and a better management of QoS within Matrix telecoms network and to offer them a way to make an improvement on the VPN that it provides. Matrix Telecoms operators network need more certainty as to route traffic. We opted for the choice of MPLS because it allows us to meet all the expectations listed above with this structure. Thus MPLS enabled us to establish a route that takes into account the current use of links flow to enhance bandwidth and avoid congestion through Traffic Engineering. MPLS enabled us to allow a flow to be routed by ensuring compliance with certain constraints implemented through its DiffServ protocol which is recommended for QoS management with the core street-network. Through MPLS we could integrate a feature to realize and implement the VPN in Matrix Telecoms. So we enforced a solution through a model to put in evidence that MPLS. We used the simulation software GNS3, Cisco IOS routers 7200 version because it is the version that integrated well our MPLS. We also used virtual machines as Debian server where some services configured like SMTP, FTP and VOIP. At last we used Windows 7 and Windows XP computers for some connectivity tests between two customer sites.

We can say that the goal was to set up a functional architecture MPLS/VPN that can integrate a Traffic Engineering and a functional QoS for some foreseeable demonstrations.

Key words: MPLS, VPN, Traffic Engineering, QoS

xi

LISTE DES TABLEAUX

Tableau I.1 : Identification de Matrix Télécoms 2

Tableau II.1 : Concepts de base de MPLS 9

Tableau II.2 : Présentation des champs DSCP 20

Tableau III.1 : Description de quelques routeurs Cisco au niveau du MPLS 27

Tableau III.1 : Comparaison entre les différents protocoles de routage 28

Tableau III.2 : Besoins matériels du déploiement en virtuel 32

XII

LISTE DES FIGURES ET ILLUSTRATIONS

Figure I.1: Plan de localisation 3

Figure I.2 : Organigramme de Matrix Télécoms Yaoundé 4

Figure II.1 : La couche MPLS 9

Figure II.2 : Architecture logicielle MPLS 10

Figure II.3 : Format d'un label MPLS 11

Figure II.5: Arrivée d'un paquet IP sur l'Ingress node 13

Figure II.6: un label sur un LSR 13

Figure II.7 : retrait du label sur l'engress node 14

Figure II.8 : Le routage implicite 14

Figure II.9: routage explicite 15

Figure II.10 : schéma d'une VRF 18

Figure II.11 : Architecture du DSCP 20

Figure III.1 : Architecture logique globale de Matrix Télécoms 25

Figure III.2 : Présentation de l'architecture existante à Matrix Télécoms S.A 26

Figure III.3 : Routeur Cisco 7200 32

Figure III.4 : Maquette de déploiement 33

Tableau III.3 : plan d'adressage 34

Figure IV.1: Le protocole MPLS au sein des interfaces 48

Figure IV.2: Observation de MPLS sur une interface avec l'outil Wireshark 49

Figure IV. 3 : Vérification de la table de MPLS 50

Figure IV. 4 Visualisation des protocoles de routage au sein de notre coeur du réseau 50

Figure IV.5 : Table de label sur chaque interface 51

Figure IV.6 : vérification de l'activation de MPLS traffic Engineering 51

Figure IV.7 : observation de l'IP RSVP host receivers 52

XIII

Figure IV.8 : visualisation du traffic-eng tunnels 52

Figure IV.9 : observation du tunnel crée 53

Figure IV.10 : Le bgp vpnv4 pour le client1 53

Figure IV.11 : Le vrf détaillé du client 1 53

Figure IV.9 : La création de la class-map 54

Figure IV.10:création des access list 54

1

INTRODUCTION GENERALE

Au cours de ces dernières années, Internet a évolué et a inspiré le développement de nouvelles variétés d'applications [1]. Ces applications ont des besoins garantissant en termes de bande passante et de sécurité de service au sein des backbones [1]. En plus des données traditionnelles, Internet doit maintenant transporter voix et données multimédia. Les ressources nécessaires pour ces nouveaux services, en termes de débit et de bande passante, ont entraîné une transformation de l'infrastructure d'Internet [1]. Cette transformation du réseau d'une infrastructure par paquets à une infrastructure en cellules a introduit de l'incertitude dans un réseau jusque-là déterministe [1]. Le trafic continue sa progression géométrique à un rythme qui ne faiblit pas. L'augmentation du trafic et par conséquent du débit des circuits physiques ont posé un problème pour l'architecture classique d'un réseau IP. L'extension des tables de routage et le traitement des segments IP limitent la capacité des routeurs classiques. Aussi l'on a cherché à faire évoluer le routeur vers un commutateur dont l'ATM avait démontré l'intérêt du point de vue performance [1]. Ainsi Matrix Télécoms qui est un FAI a besoin d'accroître la vitesse du traitement des datagrammes dans l'ensemble des équipements intermédiaires, de son backbone pour une commutation rapide des paquets. MPLS a donc été mis en place pour résoudre un certain nombre de problèmes liés à l'accroissement de la taille des réseaux (nombre d'utilisateurs, largeur des bandes passantes, gestion de plusieurs protocoles). C'est dans ce contexte que nous avons eu comme projet de fin d'étude <<Conception et mise en place d'une architecture VPN/MPLS avec gestion de la QOS : cas de Matrix Télécoms >>.

Notre travail consistera dans un premier temps à présenter le contexte dans lequel s'inscrit notre projet ainsi que sa problématique. Nous présenterons par la suite au chapitre deux les généralités sur les réseaux VPN/MPLS. Au chapitre trois nous ferons une étude, un choix et une mise en place de la solution VPN/MPLS avec la gestion de la QOS cas de Matrix Télécoms et enfin au chapitre quatre nous présenterons les tests de fonctionnement du VPN/MPLS.

CHAPITRE I : CONTEXTE ET PROBLEMATIQUE

I.1. Présentation du lieu de stage (Matrix Télécoms)

I.1.1 Historique

MATRIX TELECOMS est l'une des entreprises du groupe ICCNET. Depuis sa création (ICCNET) en 1997, elle a suivi un parcours plein de rebondissements. En effet, son histoire débute en novembre 1997 lorsque l'International Computer Center Network (ICCNET) dont le métier est la fourniture d'accès Internet, avec à sa tête Clovis TCHOKONTE. Etablie à Yaoundé, ICCNET va exercer son activité en situation de quasi-monopole pendant neuf (9) ans environ. Au premier semestre 2006, les médias confirment l'entrée dans le secteur de deux concurrents de grande envergure, MTN et ORANGE, entreprises jusque-là spécialisées dans la distribution de services de téléphonie mobile. Fragilisée par l'arrivée de ces géants aux ressources imposantes, ICCNET va, en juillet 2006, fusionner avec deux autres fournisseurs d'accès à Internet désormais Douala One.Com et CREOLINK Communications. C'est la naissance de MATRIX Télécoms, avec à sa tête Clovis TCHOKONTE pour le compte cumulé de ICC NET et Douala One.Com, et Joseph MBOCK pour le compte de CREOLINK.

Société anonyme de droit camerounais au capital social de 950 000 000 FCFA, MATRIX Télécoms sera gérer tant bien que mal jusqu'au retrait de CREOLINK en janvier 2007, soit six mois après la fusion. Par la suite, Douala One.Com se retirera également en avril 2007, soit neuf mois après la fusion.

Apres le départ de ses uniques coactionnaires, Clovis TCHOKONTE, ancien Directeur de ICCNET, décide de conserver la dénomination MATRIX Télécoms, celle-ci permet d'exploiter certaines licences telles que : la VoIP, du VPN, la vidéoconférence, le service Internet et la télésurveillance. Evoluant à son rythme, MATRIX Télécoms verra ses activités se développer au point de se constituer aujourd'hui un capital social de 317 000 000 FCFA.

I.1.2. Fiche signalétique

2

Tableau I.1 : Identification de Matrix Télécoms

Raison social	MATRIX TELECOMS
Statut juridique	Société Anonyme
Capital	317 000 000 FCFA
Effectif	90 employés au 1^er mars 2006
Siège social	Immeuble MATRIX TELECOMS, Omnisports, route de Ngousso, Yaoundé
Contacts	BP : 4124 Yaoundé Tél : [phone] E-mail : [e-mail]
	Site web : www.matrixtelecoms.com
Succursale de Yaoundé	Immeuble Matrix Télécoms, omnisports, route de Ngousso
Succursale de Douala	Rond-point salle des fêtes d'Akwa
Centre des opérations techniques	Immeuble Rond-point salle des fêtes d'Akwa, Douala
Président Directeur Général	Clovis TCHOKONTE
Directeur Général Adjoint	NANA Durand
Pôles d'activité	ISP - Opérateur Virtuel de Télécommunications
Technologies utilisées	Wimax SRT, Vecima, Canopy, NANO Station, Mikrotik

I.1.3. Plan de localisation

3

Figure I.1: Plan de localisation

4

I.1.4. Organigramme

Figure I.2 : Organigramme de Matrix Télécoms Yaoundé [2] .

I.1.5. Services offerts

Matrix Télécoms met à la disposition de sa clientèle plusieurs services : ? Internet

MATRIX TELECOMS par ses droits de distributeur offre le service d'accès à Internet pour le grand public mais aussi les entreprises public et professionnels.

? TELEPHONIE SUR IP (VOIP)

C'est un service qui permet aux différents clients d'émettre des appels téléphoniques via le réseau Internet de manière transparente. Avec cette technologie nous pouvons constater une réduction des coûts de communication à plus de 70%. A cet effet, MATRIX TELECOMS met à la disposition de sa clientèle des passerelles VOIP qui rendent possible les appels à l'international à des prix très compétitifs, les appels sur les réseaux fixes et mobiles à coût réduit.

5

? RESEAUX PRIVES VIRTUELS (VPN)

Un VPN (Virtual Private Network ou RPV Réseau Privé Virtuel), au sens le plus large, consiste à établir un réseau logique entre deux points, en utilisant les ressources de réseaux physiques. Le VPN ici concerne les entreprises qui ont plusieurs sites dans une même ville ou dans des villes différentes, et désirants les relier de manière à échanger les données de façon sécurisée. Il permet aussi d'interconnecter toutes les agences afin de permettre un suivi centralisé et rapide des informations au siège.

? TELESURVEILLANCE

La télésurveillance consiste en la surveillance d'un lieu à distance, grâce à l'utilisation dans la majorité des cas de caméras de surveillance. Il existe différents types d'appareils permettant la télésurveillance : les capteurs de position et d'état qui détectent les mouvements ou un changement d'état, les capteurs de sons ou les capteurs d'images. Dans la majorité des cas, les signaux émis par les appareils de télésurveillance aboutissent tous à un centre de télésurveillance qui identifiera le risque et apportera une réponse adaptée.

? VIDEO-CONFERENCE

La vidéo-conférence est un moyen de communication de plus en plus utilisé par les entreprises aujourd'hui. De par son aspect pratique, la vidéoconférence intéresse les entreprises souhaitant communiquer à distance avec d'autres entreprises ou personnes en évitant de se déplacer. La vidéoconférence permet donc d'organiser des réunions de travail, des formations ou autres réunions à distance tout en donnant l'impression d'être tous présents dans la même salle. Une seule séance de vidéoconférence évite de multiples appels téléphoniques, emails, fax, envois de courriers ou pire encore des déplacements.

I.2. Contexte et problématique

Matrix Télécoms fournisseur d'accès internet et de multiples autres services informatiques, utilise une convergence totale vers le protocole IP pour pouvoir desservir sa clientèle. Ce dernier est limité à certain niveau, ainsi le protocole IP est un protocole de niveau 3 fonctionnant en mode non connecté. La décision de routage d'un paquet est faite localement par chaque noeud et imaginons le grand réseau de Matrix Télécoms cela n'entrainera pas la rapidité au niveau de la commutation des paquets.

6

De ce fait, l'émetteur d'un paquet ne pourra pas prévoir le chemin qui sera emprunté par ce dernier. Alors pour une optimisation de la QOS au niveau des clients de Matrix Télécoms, nous voyons quelques faiblesses pour le bon fonctionnement des services à travers le protocole IP au le sein du coeur du réseau de Matrix Télécoms.

De tout ce qui précède nous pouvons nous poser les questions suivantes :

· Comment optimiser le processus de routage dans le réseau interne de Matrix Télécoms ?

· Comment améliorer l'utilisation de la bande passante et une meilleure gestion de la QoS ?

· Comment apporter une amélioration sur le VPN fournit par Matrix Télécoms ?

De toutes ces questions ; il se dégage la problématique suivante : Comment dynamiser le routage dans le réseau coeur de Matrix Télécoms tout en permettant une meilleure gestion de la bande passante, de la QOS et une amélioration dans le service VPN en place.

I.3. Méthodologie

Il est important pour nous ici de définir succinctement les différentes étapes à

suivre pour atteindre les objectifs visés par notre travail.

1ère étape : Etude et choix des solutions VPN/MPLS

2ème étape : Mise en place de la solution VPN/MPLS choisie

3ème étape : Test de Fonctionnement de la solution implémentée

I.4. Objectifs

L'objectif visé dans ce travail est de :

· Concevoir une architecture qui va permettre de mettre en place le Protocole VPN/MPLS pour dynamiser le service VPN fourni ;

· Utiliser le protocole MPLS pour optimiser le routage au sein du réseau de Matrix Télécoms grâce à la commutation des labels ;

· Optimiser l'utilisation de la bande passante ;

· Assurer la gestion de la QoS grâce à la notion de classe de service et du Traffic Engineering au niveau du MPLS.

7

Dans ce chapitre, nous avons présenté dans un premier temps le lieu de déroulement de notre stage qui est Matrix Télécoms, ensuite le contexte dans lequel s'inscrit notre projet et ainsi que la problématique qui en découle au sein de ce projet. Pour pallier à ce probème il a été question pour nous de définir succinctement les objectifs visés et la méthodologie à mettre en oeuvre pour pouvoir les atteindre.

8

CHAPITRE II : GENERALITES SUR LE PROTOCOLE VPN/MPLS

Les fournisseurs d'accès veulent conserver leurs infrastructures existantes et ajouter de nouveaux services non supportés par la technologie existante. Le protocole IP possède donc pour les opérateurs des limites mais la technologie MPLS lève donc ces limites en apportant l'intelligence du routage, en apportant le VPN, en intégrant la QOS. Ainsi ceux cités seront plus haut seront détaillées..

II.1 Historique et Présentation du MPLS

II.1.1 Historique de MPLS

MPLS a été développé à partir de 1997 avec la création de l'IETF MPLS working group suite à la présentation faite par trois constructeurs : Cisco, IPsilon et IBM de leur technologie de commutation par label respectivement le Tag switching, IP switching et ARIS. Le premier document (draft-ietf-mpls-framework-01.txt) est publié le 2 Août 1989 et MPLS a été normalisé avec la RFC 3031 en janvier 2001. Un grand effort pour aboutir à une normalisation a été consenti par les différents acteurs, ce qui semble mener à une révolution des réseaux IP. [2]

II.1.2 Présentation

MPLS est une technique réseau dont le rôle principal est de combiner les concepts du routage IP de niveau 3 et les mécanismes de la commutation de niveau 2 telle que implémentée dans ATM ou Frame Relay. MPLS doit permettre d'améliorer le rapport performance/prix des équipements de routage, d'améliorer l'efficacité du routage (en particulier pour les grands réseaux) et d'enrichir les services de routage (les nouveaux services étant transparents pour les mécanismes de commutation de label, ils peuvent être déployés sans modification sur le coeur du réseau) [3] .

MPLS n'est en aucune façon restreint à une couche 2 spécifique et peut fonctionner sur tous les types de support permettant l'acheminement de paquets de niveau 3. On dit souvent que MPLS est un protocole de niveau 2,5.

9

Figure II.1 : La couche MPLS [5]

MPLS traite la commutation en mode connecté qui est basé sur les labels. Les tables de commutation étant calculées à partir d'informations provenant des protocoles de routage IP ainsi que de protocoles de contrôle. MPLS peut être considéré comme une interface apportant à IP le mode connecté et qui utilise les services de niveau 2 (PPP, Ethernet, ATM, Frame Relay, SDH ...).

II.2. Concept de base et Architecture MPLS

II.2.1 Concept de base

Avant de pouvoir travailler sur le MPLS nous devons maitriser ses termes : Tableau II.1 : Concepts de base de MPLS

Sigles		Définitions et explications	Label
MPLS utilise un identifiant qui est inséré entre la couche 2 et la couche 3 afin d'identifier le LSP auquel le paquet est attribué.		FEC: Forwarding Equivalence Class
Classe d'équivalence dans laquelle on trouve un ensemble de paquets IP transmit de la même manière et suivant le même chemin (LSP) au sein du réseau.		LFIB: Label Forwarding Information Base
C'est la table dans lequel on trouve les informations sur les commutations des labels (numéro des labels, interface d'entrée numéro de label interface de sortie).		LER : Label Edge Routeur
Routeur qui fait l'interface entre le réseau MPLS et l'extérieur .Il possède des interfaces connectées au réseau MPLS et des interfaces ip traditionnelles. IL existe deux catégories de.		LSR: Label Switch Router
Routeur du réseau MPLS qui fait office de commutateur de labels et est capable de transmettre les paquets en s'appuyant

		uniquement sur le mécanisme d'identification des labels et de la LFIB	LSP :
C'est un chemin établi au travers des LSR pour rejoindre les LER au sein d'un même réseau MPLS en fonction des tables FEC et LFIB.		PHP : Penultimate Hop Popping
C'est la technique d'optimisation qui évite au LER de sortie d'effectuer une double recherche dans la table de routage et dans le LFIB.		LDP: Label Distribution Protocol
C'est le protocole utilisé par le plan de contrôle afin d'échanger les labels (entre les routeurs adjacent) et de mettre à jour les différents tables de routage (FIB et LFIB).

Les ISP doivent constamment relever le défi de faire évoluer leur réseau afin de soutenir des taux de croissances extrêmement rapides tout en maintenant une infrastructure fiable pour les applications nécessitant de la QOS. MPLS a émergé comme étant la technologie à mettre en place sur le réseau internet parce qu'elle supporte le « Traffic engineering » qui permet de transporter de grand volume de trafic utilisateur le long de chemin prédéterminé LSP à travers le réseau du fournisseur de service.

II.2.2 Architecture du Protocole MPLS Cette architecture se présente comme suit :

10

Figure II.2 : Architecture logicielle MPLS [6]

? Le plan de contrôle est composé par l'ensemble des protocoles de signalisation et des protocoles de routage. Le plan de contrôle est responsable de la construction de la maintenance des tables d'acheminement (Forwarding Tables)

11

et de la communication inter-noeuds (LSR) afin de disséminer les informations concernant le routage.

· Le plan de donnée est responsable de transporter les paquets commutés à travers le réseau en se basant sur les Forwarding Tables. Il correspond à l'acheminement des données en accolant un " Shim header " aux paquets arrivant dans le domaine MPLS.

· Les protocoles de signalisation utilisés sont CR-LDP ou RSVP-TE si l'on prend en considération les problèmes de Traffic Engineering.

· Les protocoles de routage sont quant à eux OSPF-TE ou ISIS -TE. MPLS repose sur deux composants distincts pour prendre ses décisions:

? Le plan de contrôle : échange des informations de routage (IGP) et des labels (LDP) afin de maintenir la LFIB.

? Le plan de données : permet de transmettre les paquets en fonction des labels et de la LFIB.

II.3 Présentation des Labels

MPLS utilise un label de 32 bits inséré entre les en-têtes des couches 2 et 3. Il est possible d'avoir plusieurs labels par exemple dans les cas suivants :

· MPLS/VPN : un deuxième label peut être utilisé pour identifier le concentrateur VPN à utiliser.

· 3 labels ou plus peuvent être utilisé dans le cas d'un couplage entre MPLS TE et MPLS/VPN.

Ainsi le format des labels MPLS se présente comme suit :

Figure II.3 : Format d'un label MPLS [6]

· LABEL (20bits) : identifiant du label

· EXP (3bits) : Expérimental Field, utilisé pour définir les classes de services

12

? S (1 bit): « Stack Bit » MPLS permet l'insertion de plusieurs labels dans le même paquet. Ce bit lorsqu'il est à 1 permet d'identifier si ce label est le dernier du paquet.

? TTL (8 bits): Time To Live

II.3.1 Le Label dans les autres Réseaux étendus

Un label peut être mis en oeuvre dans les différentes technologies ATM, Frame Relay, PPP et Ethernet. Pour les réseaux Ethernet un nouveau champ appelé « SHIM » a été introduit entre les couches 2 et 3 comme l'indique le schéma suivant :

Figure II.4: Encapsulation pour ATM, Frame Relay et Ethernet [5] II.3.2 Le transport des labels

Le transport des labels dans un réseau MPLS est appliquée aux protocoles de la couche 2 qui peuvent transporter des labels à l'intérieur même de leur entête (c'est le cas des protocoles ATM et Frame Relay). Dans le cas du protocole ATM le label sera transporté dans le champ « VPI/VCI » de l'entête et dans le cas du Frame Relay le champ « DLCI » aura la tâche de transporter le label. Pour les protocoles ne pouvant pas utiliser cette méthode le label sera transporté dans le champ « SHIM » qui sera inséré entre l'entête de la couche liaison et l'entête de la couche réseau.

II.4 Commutation des labels

Lorsqu'un paquet arrive dans un réseau MPLS en fonction de la FEC auquel appartient le paquet l'ingress node consulte sa table de commutation et affecte un label au paquet et le transmet au LSR suivant.

13

Figure II.5: Arrivée d'un paquet IF sur l'Ingress node [7]

Lorsque le paquet MPLS arrive sur un LSR interne du nuage MPLS, le protocole de routage fonctionnant sur cet équipement détermine dans la base de données des labels LFIB le prochain label à appliquer à ce paquet pour qu'il parvienne jusqu'à sa destination. L'équipement procède ensuite à une mise à jour de l'en-tête MPLS (swapping du label et mise à jour du champ TTL, du bit S) avant de l'envoyer au noeud suivant.

Figure II.6: un label sur un LSR [7]

Enfin , une fois que le paquet MPLS arrive à l'Engress node il lui sera retiré toute trace MPLS et le paquet sera transmis à la couche réseau.

14

Figure II.7 : retrait du label sur l'engress node [7] II.5 Méthode de distribution des labels et le protocole LDP [5]

Dans un réseau MPLS, il existe deux méthodes pour créer et distribuer les labels : Implicit routing et Explicit routing. Ces deux méthodes sont celles utilisées pour définir les chemins LSP dans le réseau MPLS.

II.5.1 La méthode Implicit Routing [5]

C'est la méthode de base choisie par l'IETF pour les réseaux MPLS. C'est un modèle fondé sur la topologie du réseau. Dans ce cas les labels sont créés à l'issue de l'exécution des protocoles de routage classique. Cette distribution est réalisée grâce au protocole LDP. Chaque routeur LSR doit donc mettre en oeuvre un protocole de routage interne de niveau 3 comme le protocole OSPF et les décisions de routage sont prises indépendamment les unes des autres.

Figure II.8 : Le routage implicite [5]

II.5.2 La méthode Explicit Routing [5]

Cette méthode explicite est fondée sur les requêtes (REQUEST-BASED) et consiste à ne construire une route que lorsqu'un flux de données est susceptible de l'utiliser. Cette méthode est utilisée pour CR-LDP (CR-LDP=LDP+TE) et RSVP-TE.

15

Le LSP n'est plus déterminé à chaque bond contrairement au routage implicite, Ce qui permet à MPLS de faire du « Traffic Engineering » afin d'utiliser efficacement les ressources du réseau et d'éviter les points de forte congestion en répartissant le trafic sur l'ensemble du réseau. Ce mécanisme permet à un opérateur de faire du TE en imposant au réseau des contraintes sur les flux du point source jusqu'au point destination. Ainsi des routes autres que le plus court chemin peuvent être utilisées. Le routeur Ingress ELSR choisit le chemin de bout en bout au sein du réseau MPLS.

Figure II.9: routage explicite [5]

II.5.3 Le protocole LDP

LDP est un ensemble de procédure par lesquelles un routeur LSR en informe un autre des affectations faites des labels. Dans un réseau MPLS deux routeurs LSR sont liés au label de distribution lorsqu'ils utilisent un LDP pour échanger leurs affectations. Ce protocole LDP est bidirectionnel et est utilisé dans le backbone MPLS. Les routeurs LSR se basent sur l'information de label pour commuter les paquets labellisés. Chaque routeur LSR lorsqu'il reçoit un paquet labellisé utilise le label local pour déterminer l'interface et le label de sortie. Il est donc nécessaire de propager les informations sur ces labels à tous les routeurs LSR. Pour cela des protocoles de distribution sont employés pour l'échange des labels entre les routeurs LSR. L'autre objectif du protocole LDP est l'établissement des chemins appelés « LSP» sur le réseau MPLS. Il définit un ensemble de procédures et de messages permettant l'échange des labels et la découverte dynamique des noeuds adjacents grâce aux messages échangés par UDP.

16

II.6 Protocole de signalisation

L'architecture MPLS ne préconise pas l'utilisation d'un " Label Distribution Protocol " en particulier. Plusieurs protocoles ont été standardisés :

? Protocoles existants et étendus afin de supporter la distribution de labels : RSVP , RSVP-TE , BGP.

? Nouveaux protocoles définis dans le but de " distribuer les labels ": LDP mis en place pour MPLS exclusivement dans le but de distribuer les labels entre les différents LSR et CR-LDP qui est protocole utilisé pour la réservation des ressources.

Le protocole RSVP utilisait initialement un échange de messages pour réserver les ressources des flux IP à travers un réseau. Une version étendue de ce protocole RSVP-TE en particulier pour permettre les tunnels de LSP autorise actuellement RSVP à être utilisé pour distribuer des étiquettes MPLS. Ainsi sa permet de prendre en compte la notion de Qualité de Service et d'ingénierie trafic.

II.7 Mode de fonctionnement des VPNs [4]

II.7.1 Généralités [4]

Les réseaux privés virtuels reposent sur des protocoles nommés « protocoles de tunneling » Ils ont pour but de sécuriser le réseau en cryptant les données partant des extrémités du VPN à l'aide d'algorithmes de cryptographie. On utilise le terme « Tunnel » pour représenter le passage sécurisé dans lequel circulent les données cryptées.

II.7.2 Les types d'utilisation de VPN [4]

Dans cette partie, nous étudierons les 3 types d'utilisation du VPN qui sont :

? Le VPN d'accès ? L'intranet VPN ? L'extranet VPN

a- Le VPN d'accès [4]

Le VPN d'accès est utilisé pour permettre à des utilisateurs d'accéder au réseau privé de leur entreprise. L'utilisateur se sert de sa connexion Internet pour établir la connexion VPN.

b- L'intranet VPN [4]

17

L'intranet VPN est utilisé pour relier au moins deux intranets entre eux. Ce type de réseau est particulièrement utile au sein d'une entreprise possédant plusieurs sites distants.

c- L'extranet VPN [4]

Une entreprise peut utiliser le VPN pour communiquer avec ses clients et ses partenaires. Elle ouvre alors son réseau local à ces derniers. Dans ce cadre, il est fondamental que l'administrateur du VPN puisse tracer les clients sur le réseau et gérer les droits de chacun sur celui-ci.

II.7.3 Protocoles utilisés pour le VPN [4]

Il existe deux catégories de protocoles : les protocoles de niveau 2 et niveau 3. Nous avons 3 protocoles de niveau 2 pour réaliser des VPN: le PPTP et le L2TP. Il existe aussi un protocole de niveau 3 IP Sec qui permet de transporter des données chiffrées pour les réseaux IP. Nous allons plus présenter le protocole IP sec dans le paragraphe suivant.

IP Sec est un protocole qui permet de sécuriser les échanges au niveau de la couche réseau. Il s'agit en fait d'un protocole apportant des améliorations au niveau de la sécurité au protocole IP afin de garantir la confidentialité, l'intégrité et l'authentification des échanges. Le protocole IP Sec est basé sur trois modules:

? Le premier Authentification Header (AH) vise à assurer l'intégrité et l'authenticité des datagrammes IP et ne fournit aucune confidentialité.

? Le second Encapsulating Security Payload (ESP) peut aussi permettre l'authentification des données mais est principalement utilisé pour le cryptage des informations.

Le troisième Internet Key Exchange (IKE) permet de gérer les échanges ou les associations entre protocoles de sécurité. Le protocole IP Sec est souvent utilisé avec le L2TP.

II.8 Les Applications de la Technologie MPLS

II.8.1 Les VPN MPLS

L'une des applications les plus importantes du protocole MPLS est de pouvoir créer des réseaux privés virtuels. Pour créer des VPNs clients, il est donc nécessaire

18

d'isoler les flux de chacun des clients. Pour cela le label MPLS est constitué de non plus d'un label mais de 2 labels :

? Le premier label (extérieur) identifie le chemin vers le LSR destination, et change à chaque bond.

? le second label (intérieur) spécifie le VPN-ID attribué au VPN et n'est pas modifié entre le LSR source et le LSR destination.

C'est le LSR source qui applique ces 2 labels au paquet de data lorsqu'un VPN est utilisé:

La gestion des VPN dans le backbone est assurée par l'opérateur par le biais du routeur LER. Chaque LER associe de manière statique une VRF aussi appelée LIB dans la norme MPLS à chacune de ses interfaces utilisateur. La VRF est une table de routage associée à un VPN qui donne les routes vers les réseaux IP faisant partie de ce VPN.

La table VRF n'est seulement consultable que par les paquets émis par un site faisant parti du VPN (du site émetteur). Cette table contient les routes reçues du site client directement connecté ainsi que des autres LER. La distribution des routes est contrôlée via EBGP s'appuyant sur des attributs permettant d'identifier l'ensemble des tables VRF auxquelles un LER distribue les routes ainsi que les sites autorisés à fournir les routes.

Figure II.10 : schéma d'une VRF [6]

II.8.2 La QOS

Avec la technologie MPLS et la définition des classes disposant chacune d'un niveau de priorité, il est possible de garantir une qualité de service adaptée à chacun des

19

flux utilisant la solution VPN/MPLS. La QoS est un élément crucial pour un réseau d'opérateur. En effet, l'opérateur doit pouvoir garantir à ses clients le transport de leurs flux en garantissant différentes contraintes, comme par exemple : Débit minimal garanti, Débit maximal, Latence, Gigue.

Ainsi cette solution permet de véhiculer la voix sur IP (VoIP) et de mettre en place des applications de visioconférence dans des conditions excellentes sur des réseaux VPN/MPLS à forts taux d'utilisation. La Qualité de Service (QoS), représente une série de techniques nécessaires pour gérer différents paramètres sur une ligne telle que la bande passante, le temps de transfert, la gigue, ou la perte de paquets. Lorsqu'une entreprise utilise MPLS, il est essentiel pour elle que ses besoins soient respectés en garantissant une disponibilité des ressources malgré les variations de charge du réseau.

Deux types d'architectures sont étudiés par l'IETF (Internet Engineering Task Force) pour définir la QoS IP :

? Integrated Services (IntServ)

? Differential Services (DiffServ)

II.8.2.1 IntServ

Int-Serv suppose que pour chaque flux demandant de la QoS, les ressources nécessaires sont réservées à chaque bond entre l'émetteur et le récepteur. IntServ requiert une signalisation de bout en bout, assurée par RSVP, et doit maintenir l'état de chaque flux (messages RSVP, classification, policing et scheduling par flux de niveau 4). IntServ permet donc une forte granularité de QoS par flux et pour cette raison, est plutôt destiné à être implémenté à l'accès.

IntServ définit 2 classes de services :

? Guaranteed : garantie de bande passante, délai et pas de perte de trafic ? Controlled Load : fournit différents niveaux de services en best effort

II.8.2.2 DiffServ

DiffServ, quant à lui, est davantage destiné à être appliqué en coeur de réseau opérateur. Les différents flux classifiés selon des règles prédéfinies sont agrégés selon un nombre limité de classes de services, ce qui permet de minimiser la signalisation.

20

DiffServ ne peut pas offrir de QoS de bout en bout et a un comportement « Hop By Hop ».

DiffServ définit 2 classifications de service (Expedited, Assured) qui peuvent être corrélées aux classifications de service IntServ (Guaranteed, Controlled Load)

DiffServ utilise les 6 premiers bits du champ TOS de l'entête IP afin de classifier le trafic dans des classes ou contrats au niveau de l'ingress-LSR. Ce champ s'appellera DS-Field dans DiffServ. Au niveau des LSR, DiffServ définit des PHB (Per Hop Behaviors) afin de construire ces LSPs. Ainsi au niveau des Edges LSR, DiffServ utilise le champ DS-Field, et à l'intérieur du corps MPLS, il invoque les PHBs

Figure II.11 : Architecture du DSCP

On utilise beaucoup DiffServ aujourd'hui car son implémentation est très simple et son efficacité est bonne. Présentons les Différents champs DSCP

Tableau II.2 : Présentation des champs DSCP

Type de flux	Diffserv	Code point DSCP	Nom commercial
Traffic réseau (routage, contrôle)	CS7, CS7	56,48	Critical/network
Voix	EF	46	Prenium
Visio-conférence	AF31, AF42, AF43	34, 36, 38	Platinium

21

Signalisation Voix

	AF31, AF32, AF33	26 ,28 ,30	Gold
Critique	AF21, AF22, AF23	18,20 ,22	Silver
Prioritaire	AF11, AF12, AF13	10, 12,14	Bronze
Standard	CS0	0	Best effort

Ces champs présentés ci haut sont à entrer lorsque l'on configure DiffServ sur les routeurs. DiffServ définit 2 classifications de service (Expedited, Assured) qui peuvent être corrélées aux classifications de service IntServ (Guaranteed, Controlled Load).

MPLS est amené à inter fonctionner avec DiffServ, car LDP supporte avant tout de la QoS à faible granularité. Le mapping entre le champ DS de l'en-tête IP et le SHIM header de l'en-tête MPLS reste à définir.

II.8.3 Traffic Engineering

Tout comme la qualité de service, le « Traffic Engineering » est un élément crucial pour un réseau d'opérateur. Comme sus-indiqué, il existe deux modes pour l'établissement des LSP sur un réseau MPLS. Dans le cadre du routage implicite, le chemin sera défini selon l'IGP. Par conséquent, le chemin de base sélectionné sera par défaut celui qui contient le moins de sauts. Dans un réseau MPLS, le TE permet d'optimiser l'utilisation des ressources d'un réseau afin d'éviter la congestion. C'est la prise en compte de la bande passante disponible sur un lien lors des décisions de routage qui rend possible cette optimisation. Pour cela, il faut utiliser le protocole « Source Routing » pour le configurer. Ainsi, pour sa mise en place dans un réseau, l'opérateur doit utiliser un protocole de routage particulier qui doit implémenter l'algorithme CSPF. C'est cet algorithme qui permet le choix d'une route en fonction des paramètres comme par exemple le débit disponible sur un lien. Des évolutions des protocoles de routages existant comme OSPF-TE ou ISIS-TE ont été développés afin d'implémenter l'algorithme CSPF. Dans un réseau MPLS, le respect de ces contraintes lors des décisions de routage est fait grâce à la présence d'un protocole de routage implémentant

22

l'algorithme CSPF. Enfin, la réservation de la bande passante éventuelle, qui doit être faite sur les routeurs, est très souvent faite grâce au protocole RSVP-TE

Le Traffic Engineering concerne l'optimisation des performances d'un réseau opérationnel en contrôlant les ressources de ce réseau. Cela permettra de gérer le trafic de façon intelligente, en évitant les engorgements. Le problème que l'on a à résoudre est de mettre en place un LSP en minimisant les métriques et en prenant en compte les contraintes de bande passante attachée à chacun des LSP..

II.9 Evolutions du MPLS [6]

II.9.1 GMPLS [6]

Une première extension du MPLS est le Generalized MPLS. Le concept de cette dernière technologie étend la commutation aux réseaux optiques. Le label, en plus de pouvoir être une valeur numérique peut alors être mappé par une fibre, une longueur d'onde et bien d'autres paramètres. Le GMPLS met en place une hiérarchie dans les différents supports de réseaux optiques. Il permet donc de transporter les données sur un ensemble de réseaux hétérogènes en encapsulant les paquets successivement à chaque entrée dans un nouveau type de réseau. Ainsi, il est possible d'avoir plusieurs niveaux d'encapsulations selon le nombre de réseaux traversés, le label correspond à ce réseau étant conservé jusqu'à la sortie du réseau.

II.9.2 VPLS [6]

Virtual Private LAN Service définit un service de VPN au niveau de la couche 2. Le but est ici de simuler un réseau LAN à travers l'utilisation d'un réseau MPLS classique. La plus grande partie des traitements va s'effectuer sur les LER. Chaque LER maintient une table liée aux adresses MAC. On appelle cette table Virtual Forwarding Instance. [6]

MPLS est donc une technologie qui a su prendre une place prépondérante dans les réseaux longue distance opérateurs. A travers sa présentation nous observons son but qui est d'optimiser le temps de traitement des paquets au sein du coeur de réseau et grâce aux extensions et applications du MPLS nous avons pu apprécier ses fonctionnalités car les quantités de données transportées sur les réseaux sont de plus en plus importantes,

23

et le routage IP actuel ne satisfait pas aux contraintes qui sont désormais de l'ordre de la bande passante et du temps de transmission.

24

Chapitre III : CHOIX ET IMPLEMENTATION DE LA SOLUTION

VPN /MPLS

De nombreuses entreprises qui se retrouvent avoir plusieurs sites répartis dans les villes où les régions du pays ont une nécessité de mettre en place du VPN pour un acheminement plus rapide des données et une facilité du travail pour que l'entreprise puisse prospérer. Le VPN passant par internet est celui qui est mis en place chez certains. Avec le MPLS nous proposons aux entreprises d'utiliser ce dernier et d'en tirer ses avantages d'où cette représentation que nous vous ferons part dans ce chapitre.

III.1 Cahier des charges

III.1.1. Présentation du Projet

Matrix Télécoms qui est un fournisseur d'accès à internet à une convergence totale vers le protocole IP au sein de son coeur du réseau et se trouve confronté à un problème de performance au niveau du routage vu l'accroissement de la taille de son réseau et l'augmentation considérable de ses clients. Ainsi il nous a été de proposer une solution pour pallier à ce problème.

III.1.2. Les Objectifs

Dans l'objectif d'améliorer les performances réseaux de Matrix Télécoms, nous devons implémenter un backbone MPLS au sein de leur réseaux. Les objectifs de notre travail sont :

? Concevoir une architecture qui va permettre de mettre en place le Protocole VPN/MPLS pour dynamiser le service VPN fournit.

? Utiliser le protocole MPLS pour optimiser le routage au sein du réseau de Matrix Télécoms grâce à la commutation des labels

? Optimiser l'utilisation de la bande passante

? Assurer la gestion de la QoS grâce à la notion de classe de service et du Traffic Engineering au niveau du MPLS

25

III.2 L'architecture de Matrix Télécoms

III.2.1. Etude de l'architecture logique globale de Matrix Télécoms

Figure III.1 : Architecture logique globale de Matrix Télécoms

Ainsi nous pouvons observer dans cette architecture logique que Matrix Télécoms utilise comme fournisseur d'accès internet la société CAMTEL et ainsi redistribue sa connexion internet tout au long de la ville de Yaoundé à travers des routeurs Relais considéré comme POP pour pouvoir desservir sa clientèle. CAMTEL est la structure qui s'occupe de pouvoir interconnecter les deux agences de Matrix Télécoms Yaoundé et de Matrix Télécoms Douala grâce à sa Fibre optique. Nous précisons ici que les différents POP de matrix Télécoms au sein de Yaoundé sont connectés encore en ce moment par des liaisons radios et ceux de douala sont en migration de connexion par Fibre Optique.

III.2.2. Identification des POPs de Matrix Télécoms au sein de Yaoundé

A travers cette architecture de Matrix Télécoms Yaoundé nous voyons qu'elle dispose de 4 POPS pour desservir ses clients à savoir : le POP de Franco, le POP de Mvolyé, le POP du PDC et tout cela connecté sur le POP principal de Ngousso à travers

26

des liaisons radios. Ainsi Matrix Télécoms utilise des radios Nano stations pour pouvoir connecté chaque client à travers ses POP repartis dans la ville pour qu'il puisse avoir accès au service internet.

Figure III.2 : Présentation de l'architecture existante à Matrix Télécoms S.A [2] III.3 Etude du matériel Cisco intégrant le MPLS

III.3.1 Choix du Matériel intégrant le MPLS

Matrix Télécoms utilise les équipements CISCO au sein de son backbone et il nous a été demandé de nous basé sur l'équipementier CISCO pour pouvoir effectué un choix du matériel. Ainsi nous avons vu que les Routeurs qui intègrent le MPLS commençant au niveau de la gamme de série des NCS 5000 grâce à une description qui était faite au préalable de chacun. Il y avait aussi diverses autres comparaisons au niveau des ports utilisés, de l'Ios installé sur chacun des routeurs. Ici nous nous sommes juste attardés sur la fonctionnalité du Routeur MPLS qui était intégré car c'est celui du MPLS qui est recherché.

27

Tableau III.1 : Description de quelques routeurs Cisco au niveau du MPLS [8]

III.3.2. Solution Retenue

Nous avons opté notre choix sur le routeur CISCO 7200 car ce dernier implémente très bien ceci.

? WAN edge Award-winning quality-of-service (QoS) feature performance [8]

? Broadband aggregation Up to 8,000 Point-to-Point Protocol (PPP) sessions per chassis [8]

? Multiprotocol Label Switching provider edge (MPLS PE) Number one choice for provider edge deployment today [8]

? Voice/video/data integration Time-division multiplexer (TDM)-enabled VXR chassis and voice port adapters [8]

? IP Security virtual private networking (IPsec VPN) Scalable to 5,000 tunnels per chassis [8]

28

? High-end customer premises equipment (CPE) [8]

III.4 Le protocole de Routage

III.4.1 Choix du protocole de Routage au sein du Coeur du Réseau

L'implémentation du protocole de routage se fera avec une comparaison entre les protocoles à état de lien et les protocoles à vecteur distance. Ceci se fera de manière à justifier le choix du protocole choisi.

Tableau III.1 : Comparaison entre les différents protocoles de routage [10]

	RIP V1	RIP V2	OSPF	EIGRP
IGP/EGP	IGP	IGP	IGP	IGP
Famille	Vecteur de distance	Vecteur de distance	Etat de liens	Vecteur de distance
Distance Administrative	120	120	110	90 (routes interne) 170(routes externes)
Métrique	Nombre de sauts	Nombre de sauts	Coût	-Bande passante (par défaut) délai (part défaut), Fiabilité, charge
Portée Maximale de sauts	15 (16 inaccessible)	15 (16 inaccessible)	Illimité	224
Envoi des mises à jour	Toute la table	Toute la table	Seulement les changements	Seulement les changements
Temps de Maj.	30s	30s	Seulement les changements	Seulement les changements
Support VLSM	Ne supporte pas le VLSM	supporte le VLSM	Supporte le VLSM	Supporte le VLSM
Convergence	Lente	Lente	Lente	lente
Algorithme	Bellman-Ford	Bellman-Ford	SPF (Dijkstra)	DUAL

29

Authentification

	Non	Oui	Oui	oui
Types de paquets	2 types (Requête, Réponse)	2 types (Requête, Réponse)	5 types de paquet (Hello, DBD, LSR, LSU, LSAck)	5 types de paquet (Hello, maj., demande, réponse, Ack)
Décomposition Réseau	Pas de décomposition Réseau	Pas de décomposition Réseau	Notion d'Aires (Area)	Notion d'AS

III.4.2. Solution retenue

Pour pouvoir implémenter MPLS au sein de notre coeur du réseau nous allons utiliser un protocole à état de lien OSPF ou IS-IS car à partir de ce tableau comparatif nous pouvons voir que sa portée maximale est illimitée, il est un protocole à état de lien, son support sur le VLSM et son algorithme implémenté SPF (Dijkstra) qui nous permettra surtout d'implémenter du Trafic Engineering à travers l'algorithme CSPF de manière à créer notre propre LSP dans notre coeur du réseau.

Mais pour les Routeurs qui sont hors du coeur réseau nous appliquerons le protocole de routage EIGRP ou RIP car de ce côté un protocole a vecteur distance suffira et une redistribution se verra être faite de manière à faciliter la compréhension de route entre OSPSF et EIGRP.

III.4.3. Le protocole de Routage externe

Pour implémenter le MPLS les routeurs d'extrémité ou de bordures doivent pouvoir être connectée entre eux et échanger le contenu sur leur système autonome AS grâce à un protocole de routage. Ce protocole nous permettra de contrôler parfaitement les informations transmises. Nous allons utiliser le protocole de routage externe EGP, précisément le protocole BGP qui est un protocole de référence pour les interconnexions entre opérateurs et offre des fonctions très élaborées. Le but d'un tel protocole permettra de pouvoir propager des routes connues vers d'autres système AS en pouvant appliquer des restrictions décidées par l'administrateur de chaque AS.

30

III.4.4 Choix du protocole pour implémenté le VPN

III.4.4.1. Comparaison entre MPLS et IP Sec

Pour pouvoir implémenter notre VPN, nous avons fait une étude comparative entre le protocole MPLS et celui du IPsec qui tous deux sont des protocoles utilisés pour effectuer du VPN. Ceci a été fait à travers un tableau de quelques éléments sélectionnés qui se présente comme suit :

Tableau II.3 : Comparaison entre MPLS et IP Sec [4]

		MPLS			IPSEC
QOS		Gestion optimale des flux permettant notamment : ? une intégration facile de services IP (VoIP, vidéo, etc.) ? de donner la priorité à vos flux métier			Inexistante
Principe / Sécurité		Vos données ne transitent pas via Internet (Connexion directe via le réseau opérateur).			Vos données transitent par Internet (Connexion sécurisée via Internet). Chaque site est exposé aux risques d'Internet.
Performances		Optimisation du réseau (choix de la route la plus rapide)			Ralentissements dûs au cryptage / décryptage des données.
Applications compatibles		Toutes les applications, y compris les logiciels d'entreprise vitaux exigeant une qualité de service élevée et une faible latence et les applications en temps réel (vidéo et voix sur IP)			Accès à distance et nomade sécurisé. Applications sous IP, notamment courrier électronique et Internet. Inadapté au trafic en temps réel ou à priorité élevée
Etendue		Dépend du réseau MPLS du fournisseur de services			Très vaste puisque repose sur l'accès à Internet
Evolutivité	· Intégration facilitée de nouveaux sites ou de liens de secours au réseau existant. · Intégration simple des offres IP complémentaires (VoIP...).		· Intégration plus complexe de nouveaux sites ou de liens de secours. · Beaucoup de contraintes à l'intégration de technologies IP complémentaires

Mise en
oeuvre,
administration
et gestion

Vitesse de
déploiement

· Déploiement simplifié. · Maintenance facilitée.

Le fournisseur de services doit
déployer un routeur MPLS en
bordure de réseau
pour permettre un accès client

· Déploiement plus complexe.

· Maintenance très contraignante

Possibilité d'utiliser
l'infrastructure du réseau Ip
existant

31

Prise en
charge par le
client

Non requise. Le MPLS est une technologie réseau

Logiciels ou matériels client requis

III.4.4.2. Solution Retenue

Pour une implémentation du VPN au sein de la structure Matrix Télécoms nous optons pour le protocole MPLS car il intègre cette fonctionnalité même et est une raison principale et sécuritaire pour les grands fournisseurs d'accès comme Matrix Télécoms de pouvoir bénéficier d'une interconnexion de leurs différents sites et de pouvoir ainsi proposer du VPN qui ne sera pas prise en charge par le client avec aucun logiciel client comme openVPN et permettra d'accroitre leur chiffre d'affaire avec ce VPN car ce sera leur propre réseau local qui permettra d'interconnecter les clients désirant du VPN.

III.4.4.3. Présentation du Routeur Cisco 7200

Pour pouvoir implémenter MPLS, le choix du Routeur est très important car il y'a ceux qui ne supportent pas la technologie MPLS. Nous allons utiliser le routeur Cisco de série 7200 pour des raisons suivantes :

32

? Les routeurs Cisco 7200 sont des routeurs compacts haute performance conçu pour un déploiement à la périphérie du réseau et dans le centre de données, où performances et services sont essentiels pour faire face aux besoins des entreprises, des administrations et des fournisseurs de services. [12]

? Les Cisco7200 sont également capables de gérer les applications suivantes : Accès haut débit à Internet pour professionnel, spécialistes, et particuliers Messagerie électronique ; [12]

? la téléphonie sur IP ; le FAX sur IP ; la Vidéo MPEG Services [12]

? VPN (Virtual Private Networking) et le E-business [12]

? Ils sont adaptés aux exigences NGN [12]

Figure III.3 : Routeur Cisco 7200 [12]

Par manque d'équipement Cisco en physique nous allons pour la suite utiliser des Ios Cisco 7200 ayant pour image (c7200-jk8s-mz.122-15.T17.image) car ils ont les avantages de pouvoir déployer notre maquette du VPN/MPLS.

III.4.4.4. Caractéristiques minimales pour le déploiement de notre architecture MPLS

Tableau III.2 : Besoins matériels du déploiement en virtuel

Outils		Quantité		Performance
Une machine Laptop ou Desktop		1		Minimum core duo 2.2 GHz de processeur 4 Go de Ram et 100 Go de disque dur
Un simulateur GNS3		1		Version 1.3.0
Virtual box		1		Version 5.0.0
Des machines virtuelles		3		Minimum 512 de ram et 15 Go de disque dur

33

Windows 7,
Windows XP et un
Serveur Debian

Des routeurs Cisco 7200	7	Avec 256 Mo de Ram et des ports séries et Ethernet
Des switches	2	Simple
Logiciel Wireshark	1

III.5 Implémentation de la solution VPN/MPLS

III.5.1. Présentation de la maquette de notre réalisation

Figure III.4 : Maquette de déploiement

III.5.2 Plan d'adressage

La répartition des adresses IP est fixée dans le tableau qui suit :

34

Tableau III.3 : plan d'adressage

Routeurs	Interfaces	Adresse IP	Adresse loopback
LERMATRIX1	S3/0	195.168.2.1/30	171.16.1.1/32
	S3/1	192.168.25.1/30
LSR1	S3/1	195.168.1.1/30	171.16.2.1 /32
	S3/2	195.168.3.1/30
	S3/0	195.168.2.2/30
LSR2	S3/0	195.168.1.2/30	171.16.5.1/32
	S3/1	195.168.4.1/30
LSR3	S3/0	195.168.4.2/30	171.16.3.1/32
	S3/1	195.168.3.2/30
	S3/2	195.168.5.1/30
LERMATRIX2	S3/0	195.168.5.1/30	171.16.1.2/32
	S3/1	195.168.8.1/30
Client1	S3/1	195.168.25.2/30	//
	F2/0	192.168.10.1/24
Client2	S3/0	192.168.8.2/30	//
	F2/1	192.168.20.1/24
Serveur de VOIP, FTP et SMTP	//	192.168.10.5/24	//
Machine cliente windows7	//	192.168.10.20/24	//
Machine Cliente Windows XP2	//	192.168.20.2/24	//

Ici nous précisons que le choix d'adressage a été fait avec des adresses publiques tout au coeur du réseau MPLS vu que c'est notre réseau opérateur et nous avons utilisé les adresses privées pour les machines et routeurs du client qui sont hors du coeur du réseau.

35

III.5.3 Configuration des interfaces

Enable pour passer en mode super utilisateur on aura un # qui apparaitra.

Puis conf t pour passer en mode de configuration du terminal

Router (config) # hostname pour pouvoir changer le nom du routeur

Router (config) # Interface `nom de l'interface' (pour entrer dans l'interface que l'on veut configurer)

Router (config -if) # ip add `adresse IP' `masque' (pour adresser l'interface du routeur)

Router (config -if) # no sh (pour allumer l'interface du routeur)

Cette configuration sera appliquée sur chaque interface des routeurs respectivement comme dans cette architecture de manière à respecter le choix d'adressage et de pouvoir s'assurer que l'adressage a été bien fait et que les noms des routeurs ont été bien mis en place pour un repérage facile de ces dernier.

III.5.4. Le routage OSPF au sein du coeur du réseau MPLS

Router (config) # router ospf 1 (activation du processus OSPF)

Router (config-router) # network `adresse réseau' `masque générique' area 0 (Ici nous avons l'adresse réseau et le masque générique pour pouvoir déclarer les réseaux qui participerons au processus ospf donc on fera pareil pour tous les différents sous réseaux que nous devons appliquer le protocole OSPF au sein du coeur du réseau).

Donc on appliquera le protocole OSPF au sein des interfaces respectives se trouvant au Coeur du réseau à savoir LERMatrix 1, LSR1, LSR2, LSR3, et LERMatrix2. Le protocole de routage interne au backbone sera actif sur les LER et LSR du backbone IP partagé. Il permettra d'abord d'assurer la connectivité IP entre les routeurs du backbone puis l'établissement de session TDP (Tag Distribution Protocol) issu de Cisco ou LDP.

III .5.5 Mise en place des VRF sur les routeurs LERMatrix 1 et LERMatrix 2

III .5.5.1 Création de la VRF

Création de deux tables de routage virtuelles VRF pour chaque client. À l'intérieur de la configuration de la VRF, nous désignons de RD des futures routes de

36

cette VRF ainsi que le RT (Route Target) dans les deux sens (import et export). Chaque VRF a sa propre Routing Information Base (RIB, Table de routage) et table Cisco Express Forwarding. Ceci doit être activé avec ip cef.

Router (config)#ip vrf Client1 (création de la table virtuelle du Client 1et Client 2 qui nous permettra de virtualiser une partie du routeur).

Router (config-vrf)#rd 1:1 (affectation d'une RD à la table de routage vrf qui crée préfixé a une adresse IPv4 donnera une adresse VPNv4 unique dans tout le réseau. Chaque VRF doit avoir une RD unique et une ou plusieurs RT en import et/ou export.)

Router (config-vrf)#route-target import 1:1 (permet d'indiquer quelles tables importer à la vrf.).

Router (config-vrf)#route-target export 5:5(permet d'indiquer quelles tables exporter à la table de routage de notre VRF).

Router (config-vrf)#exit (pour sortir de la table VRF crée).

Ceci doit être fait respectivement sur le Routeur LERMatrix1 et LERMAtrix2.

III.5.5.2 Assignation de la vrf forwarding

Assignation à l'interface LERMatrix 1 connecté au Client 1 et celui de LERMatrix 2 connecté au Client 2 d'une VRF forwarding sur chacune de leur interface. Router (config) #'interface connecté au Client'

Router (config-if) #ip vrf forwarding Client1 (affectation de ip vrf forwarding au Client1).

Router (config-if) #ip add `adresse IP' `masque' (adresse de l'interface connecté au Client).

Remarque : Il faut entrer la commande « IP vrf forwarding » avant la commande « ip address », car les routeurs Cisco suppriment la configuration IP lors de l'affectation d'une interface à une vrf.

Router (config-if) #no sh (pour redémarrer une interface).

III.5.6 Configuration du routage EIGRP

Le routage EIGRP est appliqué à tous les interfaces et routeurs hors du réseau de manière à pouvoir faire une redistribution de manière très facile.

? Routage EIGRP au niveau des routeurs Clients

Router (config) # router Eigrp 1 (activation du processus EIGRP)

37

Router (config-router) # network `adresse réseau' (déclaration du réseau) Router (config-router) #no auto-summary (pour demander de ne pas résumer les routes) « pour configuration voir annexe »

? Routage EIGRP au niveau des Routeur LERMatrix1 et LERMatrix2 Router (config) #router eigrp 1 (activation du processus EIGRP)

Router (config-router) #address-family ipv4 vrf Client1 (pour pouvoir mettre l'adresse ipv4 dans la table VRF du Client1 crée)

Router (config-router-af) #network adresse Réseau (déclaration du réseau) Router (config-router-af) #no auto-summary (pour demander de ne pas résumer les routes)

On remarque qu'on ne mélangera pas les adresses IPv4 et VPNv4, leur configuration sera donc séparée dans la configuration du protocole de routage.

De même, que pour la commande Ping, il faut spécifier la vrf pour afficher sa table de routage.

Router (config-router-af) #autonomous-system 1 (permet une configuration globale du protocole de routage EIGRP qui a été créé)

Router (config-router-af) #exit (pour sortir) « pour configuration voir annexe »

III.5.7 Activation du protocole MPLS sur les routeurs du coeur du

Réseau

La mise en oeuvre du protocole MPLS sur les routeurs Cisco est très simple. La création des tables de forwarding est faite dynamiquement grâce au protocole de distribution de label. Pour pouvoir utiliser MPLS sur les routeurs Cisco, il faut d'abord activer le Cisco Express Forwarding (CEF). Sur nos routeurs cette commande est implémentée par défaut.

Router (config)# ip cef (Première opération à effectuer pour utiliser MPLS qui est d'activer CEF comme méthode de commutation sur tous les routeurs du backbone)

Router (config) # tag-switching advertise-tags (cette commande active MPLS et démarre le processus de distribution des labels).

Router (config)# mpls label protocol ldp (Cette commande permet de sélectionner le protocole utilisé pour la distribution des labels. Par défaut, c'est le

38

protocole propriétaire Cisco TDP (Tag Distribution Protocol) qui est utilisé. Pour notre réseau, nous utilisons LDP (Label Distribution Protocole).

Router (config-int)# mpls ip (Les interfaces doivent encapsuler les paquets avant de les envoyer sur le réseau MPLS. Cette commande doit être ajoutée dans la configuration de chaque interface du coeur du réseau. )

Cette configuration n'est pas utilisée pour les interfaces des LER connectées au routeur Client 1 et Client 2, car ces machines utilisent des paquets IP standards. Donc on applique ses commandes au sein des routeurs LERMatrix1, LSR1, LSR2, LSR3, et LERMatrix2 qui ont des interfaces aux coeurs du réseau notamment « pour configuration voir annexe »).

III.5.8 Mise en place du protocole MP-BGP

Pour configurer la liaison vpnv4 entre les deux routeurs LERMatrix1 et LERMatrix2 que l'on cherche à faire, il nous faut configurer sur les deux routeurs, comme on le ferait en BGP, une relation de voisinage en prenant comme référence les adresses IP de loopback paramétrées précédemment. Il faut configurer BGP afin qu'il transporte les routes d'un point de la VRF à l'autre. BGP est le protocole de référence de l'Internet pour les interconnexions entre opérateurs. Il fait partie de la famille des EGP (Exterior Gateway Protocol) dont il est aujourd'hui le seul membre. BGP ne sert donc que pour les opérateurs, c'est-à-dire pour ceux qui ont leur propre politique de routage à l'extérieur de leur AS (Autonomous System). Un réseau fonctionnant sous une autorité unique est appelé un système autonome.

Router (config) #router bgp 1 (activation du processus bgp)

Router (config-router) #neighbor `adresse' `loopback' remote-as 1 (Ici on a précisé l'adresse source qui sera mis dans le système Autonomous System)

Router (config-router) #neighbor `adresse' `loopback' update-source Lo0 (précisions de l'adresse source pour les mis à jour Bgp car BGP refuse les mises à jours des voisins dont l'IP n'est pas configurée avec la commande neighbor, ce qui pourrait poser des problèmes en cas de lien redondant.)

Router (config-router) #address-family vpnv4 (activation du support vpnv4 dans la VRF car Par défaut BGP ne transporte et ne reçoit que des routes IPv4 pour transporter les routes des VRFs. BGP enverra des routes VPNv4 puis il faudra donc

39

activer le support de cette famille d'adresse et définir les voisins avec qui on échangera de type de routes.)

Router (config-router-af) #neighbor `adresse' `loopback' activate (activation de l'adresse loopback)

Router (config-router-af) #neighbor adresse loopback send-community extended (pour pouvoir définir les voisins avec qui échanger les routes.)

Router (config-router-af)#exit (pour sortir)

Nous précisons ici que lors de la mise en place du protocole MP-BGP lorsque nous débuterons sur le routeur LERMatrix1 nous devrions mettre la loopback de routeur LERMatrix2 comme loopback que l'on active et suivrons les étapes puis inversement quand on sera sur la configuration au niveau du routeur LERMatrix1.

III.5.9. Gestion de la redistribution respective des préfixes sur les

routeurs LER

Avant de pouvoir tester le bon fonctionnement de notre VPN, il nous manque encore une brique importante de notre architecture. Il faut configurer les routeurs LERMatrix 1 et LERMatrix2 de telle sorte que la redistribution des routes soit effective mutuellement dans les deux sens entre BGP et EIGRP. L'avantage de ce type d'architecture est la scalabilité. Le but est que les deux protocoles étant différents puisse pouvoir communiquer.

III.5.9.1 Redistribution d'EIGRP dans BGP

Ici on s'occupe de redistribuer les routes apprises par EIGRP dans BGP.

Router (config)#router bgp 1 (activation du processus bgp)

Router (config-router) #address-family ipv4 vrf Client1 (pour pouvoir mettre

l'adresse ipv4 dans la table VRF du Client1 crée)

Router (config-router-af)#redistribute eigrp 1 metric 1 (pour redistribuer

EIGRP dans le protocole BGP)

Router (config-router-af)#exit (pour sortir)

III.5.9.2 Redistribution de BGP dans EIGRP

On s'occupe de redistribuer les routes apprises par BGP dans EIGRP Router (config)#router eigrp 1 (activation du processus EIGRP)

40

Router (config-router) #address-family ipv4 vrf Client1 (pour pouvoir mettre l'adresse ipv4 dans la table VRF du Client1 crée)

Router (config-router-af)#redistribute bgp 1 metric 1024 1 255 1 1500 (pour redistribuer BGP dans le protocole EIGRP)

Router (config-router-af)#exit (pour sortir)

(Pour configuration voir annexe)

III.5.10. Configuration du traffic Engineering sur les Routeurs du coeur du Réseau

Cela s'appliquera sur les routeurs Matrix 1, R1, R2, R3, et Matrix 2 .Le but est de mettre en oeuvre certains mécanismes offerts par MPLS pour effectuer du Traffic Engineering sur un réseau. Les scénarios sont généralement ceux-ci :

? Création d'un lien statique pour répartir la charge sur un réseau ? Création d'un lien dynamique

Ici nous alors faire la création d'un lien statique qui définira explicitement une route reliant LERMatrix1 à LERMatrix2 en passant par LSR1, LSR2 et LSR3. Or un paquet allant de LERMatrix1 à LERMatrix2 emprunte le chemin le plus direct, c'est-à-dire qu'il ne passe pas par LSR3 directement. Sur un réseau réel, les chemins les plus courts sont parfois congestionnés alors que d'autres sont sous-utilisés. Le Traffic Engineering permet de répartir la charge sur le réseau en obligeant certains flux à emprunter les chemins moins utilisés par le protocole de routage interne.

III.5.10.1 Autorisation du Traffic Engineering sur les routeurs

Il faut configurer tous les routeurs du coeur du réseau afin qu'ils supportent le Traffic Engineering. La commande mpls traffic-eng tunnels active la fonction tunnel du routeur.

Afin que chaque routeur puisse être identifié par une adresse IP unique, nous utilisons une interface virtuelle appelée loopback 0.

A ce niveau nous devons ajouter les interfaces loopback de chaque routeur du coeur du réseau mais nous avons déjà fait cela plus haut en configurant les interfaces pour pouvoir faire notre MPLS. Mais nous devrions entrer dans chaque interface du routeur et activer le mpls traffic-eng tunnels.

41

Router (config-if) # ip rsvp bandwith 1000 au niveau de chaque interface on peut faire une réservation de ressource avec le protocole RSVP

Pour faire du Traffic Engineering, le routeur doit connaître la topologie du réseau. Pour cela, on peut lui dire d'utiliser la topologie connue par OSPF grâce à la commande mpls traffic-eng area. L'area est toujours la même que celle dans laquelle on veut faire du Traffic Engineering.

Router (config)# router ospf 1 (activation du processus OSPF)

Router (config-router)# mpls traffic-eng area 0

Router (config-router)# mpls traffic-eng router-id loopback 0 permet de configurer l'identificateur du routeur utilisé pour le Traffic Engineering. Nous identifions les routeurs avec leur adresse de loopback.

Pour qu'OSPF ajoute les adresses d'identifications des routeurs dans les tables, il faut ajouter chaque sous réseau dans l'area 0.

Router (config-router)# network `adresse réseau' `masque générique' area 0

Pour une autorisation des tunnels sur une interface, la commande mpls traffic-eng tunnels doit être ajoutée dans la configuration de cette interface. Chaque interface utilisée par le tunnel doit être configurée ainsi :

Router (config-int)# mpls traffic-eng tunnels

(Pour configuration voir annexe)

III.5.10.2 Création du chemin de manière statique

Un tunnel est unidirectionnel. Il faut donc créer un tunnel pour le chemin d'aller et un autre pour le chemin de retour. Un tunnel est défini sur le routeur se trouvant à son entrée. Dans notre cas, cela correspond aux deux LER Matrix 1 et LERMatrix 2.

Le routeur voit un tunnel comme une interface. Il suffit de taper la commande interface tunnel id pour le créer et entrer dans son mode de configuration. L'id étant le numéro permettant d'identifier le tunnel sur le réseau.

Router (config)# interface tunnel `numéro du tunnel' (création du tunnel)

Il faut configurer l'adresse IP de cette interface. Un tunnel ne doit pas être numéroté (unnumbered) car il représente une connexion unidirectionnelle. On l'associe à l'identificateur du routeur.

Router(config-int)# ip unnumbered loopback 0

42

Router(config-int)# tunnel destination `adresse loopback du LER destination' ( pour définir la destination du tunnel)

Router (config-int)# tunnel mode mpls traffic-eng (La commande suivante indique que le mode d'encapsulation des paquets utilisé pour le tunnel est MPLS)

Le tunnel doit être signalé aux IGP afin qu'il soit pris en compte lors de la création des tables de routage. Pour cela, il faut utiliser la commande suivante :

Router (config-int)# tunnel mpls traffic-eng autoroute announce

La commande ci-dessous indique au tunnel qu'il doit suivre la route explicitée par l'identificateur 1.

Router (config-int)# tunnel mpls traffic-eng path-option 1 explicit identifier 1 Ci-dessous est définie la route explicitée par l'identificateur 1. Cette route est

indiquée en faisant la liste des routeurs devant être traversés par le tunnel. Selon notre

architecture , le tunnel doit passer par LSR1, LSR2, LSR3 pour finir à Matrix 2. Router (config)# ip explicit-path identifier 1

Router (cfg-ip-expl-path)# next-address `ip_address' (adresse loopback du prochain LSR)

Router (cfg-ip-expl-path)# next-address `ip_address' (adresse loopback du prochain LSR)

Router (cfg-ip-expl-path)# next-address `ip_address' (adresse loopback du prochain LSR)

Router 1(cfg-ip-expl-path)# next-address `ip_address' (adresse loopback de destination du LER de sortie)

Donc ici on a crée un tunnel de chaque coté du LER pour pouvoir établir le chemin LSP (pour configuration voir annexe).

III.5.10.3 Création d'un chemin de manière dynamique

Pour la création dynamique de tunnels, la plupart des commandes utilisées sont identiques à celles utilisées précédemment. La commande ci-dessous indique aux routeurs que le tunnel doit être créé dynamiquement en respectant la contrainte définie ci-dessus.

Router (config-int)# tunnel traffic-eng path-option 1 dynamic (pour une création du chemin LSP de manière dynamique.)

43

Ils existent plusieurs autres protocoles pour effectuer du Traffic Engineering. Dans nos tests, nous avons utilisé OSPF, afin que les routeurs puissent connaître la topologie du réseau, et RSVP pour configurer les paramètres de bande passante et utilisé pour la signalisation et l'allocation des ressources pour l'ingénierie de trafic puis LDP pour la distribution des labels. Le but de ce travail n'est pas de décrire ces protocoles, mais de montrer les possibilités offertes grâce à ces protocoles.

III.5.11 Gestion de la QOS

III.5.11.1. Choix du protocole l'implémentation de la QoS

Pour choisir le protocole utilisé pour mettre en place notre qualité de service au sein de notre coeur du réseau nous allons nous baser sur une étude comparative entre le protocole Intserv et le protocole Difffserv qui sont tous deux utilisées pour pouvoir réaliser la QOS avec MPLS.

Tableau II.5 : Comparaison entre intserv et diffserv [3]

	Avantages
		? Pas plus de 300/400 postes (pas "scalable"
INTSERV	Adapté aux réseaux locaux	? Nécessite la prise en charge du protocole
		RSVP par les routeurs
		? nécessite en effet d'établir préalablement
	? Adapté aux réseaux étendus comme ISP car	un contrat dans tous les
	pas d'info d'état à	équipements de son
	maintenir au niveau des	domaine. Ceci implique
DIFFSERV	routeurs	une connaissance
	? Pas de protocole lourd de signalisation à	approfondie des
	implémenter comme	applicatifs pouvant transiter
	RSVP	sur le réseau et peut se révéler parfois difficile à appliquer.

44

Nous souhaitons attirer l'attention sur le fait que ni INTSERV ni DIFFSERV ne sont des modèles parfaits répondant à toutes les exigences d'une bonne qualité de service. Ces deux modèles ne doivent donc pas être opposés, mais plutôt associés de manière complémentaire

III.5.11.2. Solution retenue

Notre choix se portera sur Diffserv car IntServ est très performant et bien adapté aux réseaux de petite envergure comme les LAN, alors que DiffServ s'adapte mieux à des réseaux de grande échelle comme ceux des ISP. Ce qui fait de l'association de ces deux techniques un très bon compromis pour mettre en place une QoS de bout-en bout IntServ aux extrémités, et DiffServ en coeur de réseau.

Les opérateurs qui offrent désormais des services de VPN et de Traffic Engineering (TE) peuvent se concurrencer en offrant divers niveaux de qualité de service en fonction des différents types de trafic que l'on peut rencontrer sur le réseau. Par exemple, lorsque l'on souhaite utiliser des services de voix sur IP sur nos réseaux, il est essentiel de garantir une bande passante et un délai de transmission optimal. Dans le cas de transfert de données importantes, il est nécessaire de garantir un taux de perte de paquet faible. Le modèle DiffServ permet la gestion de cette QoS de bout en bout (end-to-end) dans notre réseau.

Pour implémenter Diffserv, on sépare tout d'abord les interfaces qui recevront les données de celles qui les enverront. Pour l'interface qui reçoit les données, on créé tout d'abord les ACLs puis les classes. On attribue ensuite une valeur au champ DSCP.

III.5.11.3 Création des access-list

Router (config) # access-list 101 permit tcp any any eq 16383 (autorise le trafic TCP en provenance et à destination de n'importe quelle adresse IP concernant le port 16383.)

Router (config) # access-list 101 permit tcp any any eq 16384 (autorise le trafic TCP en provenance et à destination de n'importe quelle adresse IP concernant le port 16384.)

Router (config) # access-list 102 permit tcp any any eq 20 (autorise le trafic TCP en provenance et à destination de n'importe quelle adresse IP concernant le port 20.)

45

Router (config) # access-list 102 permit tcp any any eq 21 (autorise le trafic TCP en provenance et à destination de n'importe quelle adresse IP concernant le port 21)

Ceci est appliqué sur le Routeur LERMatrix1 et LERMatrix2 (pour configuration voir annexe)

Cette Access-list est dite "étendue", elle permet d'autoriser le trafic TCP en provenance et à destination de n'importe quelle adresse IP et concernant les ports cités ci-dessus les ports 16383 et 16384 sont basés sur le protocole temps réel RTP.

On peut ensuite créer une classe et y associer l'ACL:

III.5.11.4 Création des classes

Router (config) # class-map VOIP (création de la classe-map VOIP)

Router (config-cmap) # match access-group 101 (association de la Class-map

crée a l'access-list 101)

Router (config-cmap) # end (pour sortir de la class map)

Router (config) # class-map ftp (création de la classe-map FTP)

Router (config-cmap) # match access-group 102 (association de la Class-map

crée a l'access-list 102)

Router (config-cmap)# end (pour sortir complètement de la class map)

Ainsi nous pourrions dire que ces commandes permettent de liér les access-list

crées à une classe précise. On peut associer autant d'ACL que l'on souhaite à une classe.

La class-map est ainsi créée.

III.5.11.5 Attribution de la valeur au champ DSCP

Une "policy-map" permet de définir une action associée à une "class-map", c'est-à-dire, le traitement à lui appliquer comme par exemple une bande passante. Router (config)# policy-map dscp (pour définir la policy-map attribué au champ DSCP)

Router (config-pmap)# class VOIP (une "policy-map" est appliquée à la classe

VOIP)

Router (config-pmap-cmap)# set ip dscp 46 (attribution de la valeur Codepoint DSCP 46 qui correspond à la VOIP dans le tableau des champs DSCP)

46

Router (config-pmap-cmap)# class ftp (une "policy-map" est appliquée à la classe ftp)

Router (config-pmap-cmap)# set ip dscp 22 (attribution de la valeur Codepoint DSCP 22 qui correspond à une critique dans le tableau des champs DSCP)

III.5.11.6 Création des classes sur l'interface de réception

La configuration des classes est faite pour éviter d'utiliser ceux qui sont sur le

routeur par défaut dans le but de pouvoir préparer à allouer une bande passante à chaque

service que l'on souhaite assurer une stabilité.

Router (config) # class-map nom de la classe (création d'une classe)

Router (config-cmap) # match ip dscp 46 (affectation du champ DSCP46 à

cette classe qui viens d'être crée)

Router (config-cmap) # end (pour sortir de la classe)

Router (config) # class-map `nom de classe' (création d'une classe)

Router (config-cmap) # match ip dscp 22 (affectation du champ DSCP 22 à

cette classe qui viens d'être crée)

Router (config-cmap)# end (pour sortir de la classe)

III.5.11.7 Allocation de la bande passante

Nous devons maintenant attribuer la bande passante disponible à chaque service que nous souhaitons assuré la continuité et la disponibilité en cas de saturation.

Router (config) # policy-map « nom de la polycy-map que l'on veut créer » (pour définir un service policy-map qui sera appliquée à la classe crée plus haut)

Router (config-pmap) # class `nom de classe' (on crée une classe qui sera appliquée à la policy-map)

Router (config-pmap-cmap)# priority percent 60 (on spécifie une bande passante minimum pour ce flux égal à 60% de la bande passante totale.)

Router (config-pmap-cmap) # class `nom de la classe' (on crée une classe qui sera appliquée à la policy-map)

Router (config-pmap-cmap) # bandwidth percent 40 (on spécifie une bande passante égale à 40% de la bande passante totale sera divisée entre les différents flux) Router (config-pmap-cmap) # end

47

Nous avons vu que grâce à la mise en place de notre maquette VPN/MPLS, nous avons pu ainsi connecter nos deux sites distants grâce au réseau du fournisseur de Matrix Télécoms à travers le VPN. Nous avons utilisé le principe de commutation de label au sein du coeur du réseau et avons implémenter des services comme le Traffic Engineering pour pouvoir tracé le chemin LSP que nos labels devrons suivre au coeur du réseau et la QoS pour assurer une qualité de service au service partagé par les deux sites distants. Les services partagés par ses deux sites client sont le service SMTP, DNS, VOIP et FTP.

48

Chapitre IV : TEST DE FONCTIONNEMENT DE LA SOLUTION

IMPLEMENTEE

Concernant l'implémentation de notre réseau VPN MPLS. Nous nous sommes tout au long des précédents chapitres, plus particulièrement celui du chapitre III appesantis sur l'implémentation et démarches qui ont contribué à la réalisation de notre maquette démontrant la réalisation et la mise en place du VPN/MPLS avec la gestion de la QOS et du trafic Engineering grâce à l'outil GNS3, Virtual box et les IOS CISCO utilisées pour la virtualisation. Dans le présent chapitre nous présenterons dans un premier temps l'essentiel des résultats obtenu lors de nos travaux à savoir Le VPN/MPLS, l'ingénierie de trafic, la QOS et puis nous ferons des remarques sur le bien fait du MPLS.

IV.1 Résultats concernant le MPLS

IV.1.1 Test du MPLS un routeur

Figure IV.1: Le protocole MPLS au sein des interfaces

Ici nous pourrons observer que le protocole MPLS est bien activé sur tous les interfaces depuis le LER d'entrée en passant par chaque LSR de bond en bond en changeant de label jusqu'à arriver au LER de sortie en utilisant le protocole LDP pour la distribution des labels.

49

On tape show mpls forwarding-table pour vérifier sur chaque routeur la table de MPLS.

IV.1.2 Test du MPLS à travers Wireshark

Figure IV.2: Observation de MPLS sur une interface avec l'outil Wireshark

Avec L'outil wireshark utilisé pour voir les paquets circulant, nous avons établi une liaison entre nos deux sites distants, un mail a été envoyé d'un client à un autre et un test d'appel a été effectué grâce à notre serveur VOIP de manière à maintenir la liaison et observer les paquets qui circulent en clair sur notre architecture réseau. Ainsi nous avons filtré les paquets MPLS transitant au coeur de notre réseau et nous avons observés le changement du label marquant le fonctionnement de notre protocole MPLS.

IV.1.3 Visualisation de la table de MPLS

Etant sur une interface du routeur coeur du réseau à savoir LSR ou un routeur d'extrémité LER nous pouvons visualiser la table de MPLS ou nous pouvons observer le label qui le leur est assigné, les interfaces de sortie et autres. Ceci grâce à une commande show mpls forwarding-table.

50

Figure IV. 3 : Vérification de la table de MPLS

IV.2 Test de Protocole de routage implémenté

Figure IV. 4 Visualisation des protocoles de routage au sein de notre coeur du réseau

A travers cet outil de visualisation, nous pouvons observer les protocoles de routage OSPF implémenté au coeur du réseau, le protocole de distribution de label LDP implémenté, le protocole de signalisation RSVP et le protocole de routage externe BGP qui permet de transporter notre table VRF d'un site à un autre avec notre VPN.

IV.3 Vérification des labels

Pour pouvoir observer si les labels sont bien distribués et échangé entre les LSR nous utiliserons la commande show mpls ip binding. Ainsi au niveau de chaque interface où est activé le MPLS nous pourrons donc voir son label d'entrée et celui de sortie. On pourra le vérifier sur tous les routeurs du coeur du réseau et les LER d'entrée et sortie notamment pour des éventuelles vérifications.

51

Figure IV.5 : Table de label sur chaque interface IV.4 Résultats concernant le MPLS Traffic Engineering

Pour pouvoir voir si le traffic engineering est activé on tape la commande show mpls traffic-eng autoroute ainsi on verra enabled pour signaler qu'il est actif et son tunnel destination qui a été créé pour acheminer le label.

Figure IV.6 : vérification de l'activation de MPLS traffic Engineering

Ici on pourra observer le protocole RSVP qui nous montre que le chemin LSP est créé et une réservation de ressource est effectuer quittant du LER Matrix2 au LER Matrix1.donc on pourra taper show ip rsvp host Sender.

52

Figure IV.7 : observation de l'IP RSVP host receivers

Pour observer le traffic-eng tunnels on doit taper la commande show mpls traffic-eng tunnels ainsi nous pourrons voir le tunnel 1 et le tunnel 2 créé avec la route ou chemin explicite qui a été allouée avec leur RSVP pour pouvoir relier nos deux LER d'entrée et sortie notamment.

Figure IV.8 : visualisation du traffic-eng tunnels

Pour voir les interfaces où le tunnel est activé on tape la commande show mpls traffic-eng tunnels brief et on verra les deux interfaces des LER qui ont ce tunnel et up pour dire qu'ils sont activés.

53

Figure IV.9 : observation du tunnel crée IV.5 Résultats concernant le VPN

Ici nous observons le vpnv4 et le bgp qui assurera à relier le Client2 crée au client1 qui aura accès au VPN avec le tag respectifs et qui pourront faire transiter et faire passer leurs informations.

Figure IV.10 : Le bgp vpnv4 pour le client1

La table Vrf du client nous montre le principe que les tables du routeur matrix 1 seront importées dans les tables du routeur Matrix2 grâce à leurs routes qui seront importés et exporté chacune dans un sens selon la communication respective

Figure IV.11 : Le vrf détaillé du client 1

54

IV.6 Résultats concernant QOS

La QoS ici a été géré avec la création des class-map pour chaque service que l'on souhaite contrôler le flux à travers les classes au niveau du champ dscp. La configuration est utilisée pour placer le plus prioritaire au trafic du port TCP auquel il correspond et les autres avec leur priorité respective de manière à pouvoir assurer un service de qualité pour les utilisateurs.

Figure IV.9 : La création de la class-map

Une Access Control List permet de filtrer les paquets IP, c'est à dire les paquets du niveau 3. Elle permet de définir les actions possibles des utilisateurs du réseau

Figure IV.10:création des access list

Pour une bonne implémentation de notre QoS nous avons fait des tests avec notre serveur Debian 6.01 contenant les services SMTP, VOIP et FTP et avons essayé de charger le serveur avec le Ping de la mort de manière à imaginer qu'un gros téléchargement était effectué puis nous avons effectué un appel entre les deux sites pour tester la liaison ceci en imaginant deux clients VPN qui se transmettait les informations. Ainsi avec la notion de classe appliquée à chaque flux nous avons eu une stabilité du service malgré la perturbation que nous avons faire subir au flux.

55

CONCLUSION GENERALE ET PERSPECTIVES

Parvenu au terme de la réalisation de notre maquette, il était question pour nous de pouvoir proposer une technique d'amélioration, d'optimisation du processus de routage dans le réseau interne de Matrix Télécoms, de l'utilisation de la bande passante, une meilleure gestion de la QoS et enfin apporter une amélioration sur le VPN fourni par Matrix Télécoms. Ainsi à travers le MPLS, nous voyons un protocole qui apporte au protocole IP une amélioration de ceux cités plus haut et surtout le mode connecté. MPLS offre indéniablement plusieurs services intéressants à exploiter comme son VPN, le Traffic Engineering et sa Qos implémenté à travers DiffServ qui introduit la notion de classe de priorité à chaque flux. Le développement des technologies à contrainte temporelle telles que la VoIP ou les applications vidéo, sont de plus en plus fréquentes, et requièrent l'utilisation d'un réseau pouvant respecter ces besoins d'où le protocole MPLS. A travers cette maquette de simulation et l'implémentation de l'architecture VPN, nous pouvons garantir un meilleur routage au sein du coeur du réseau de Matrix Télécoms grâce aux services implémentées par MPLS et qui ont été mis en place. MPLS n'étant pas lié à une technique de niveau 2 particulière, il peut être déployé sur des infrastructures hétérogènes (Ethernet, ATM, Frame Relay) avec la prise en charge de la gestion de contraintes sur la qualité de service (DiffServ) et du Traffic Engineering pour une éventuelle migration sans toutefois vouloir changer tout le matériel existant au sein du coeur du réseau. MPLS-TE permet une réduction des risques et des taux de congestion et peut donc être considéré comme un mécanisme améliorant la QoS La logique modulaire selon laquelle le MPLS a été développé permet de l'étendre avec beaucoup de souplesse, comme en témoigne l'apparition du GMPLS destiné à devenir un standard. MPLS pourra-il vraiment assurer une transition facile vers l'Internet optique. Pour un approfondissement sur le MPLS il faudra se pencher sur les équipements réels en physique pour pouvoir pousser haut ce déploiement.

56

Bibliographie

Ouvrages

[1] ISMAIL, «Mise en oeuvre d'un coeur de réseau,» INSTITUT NATIONAL DES TECHNOLOGIES DE L'INFORMATION ET DE LA COMMUNICATION, Université de Bechar, 2009/2010.

[2] «Etude et optimisation d'un backbone,» Université virtuelle de Tunis, 2014.

[3] «MPLS-rt,» 25 septembre 2015. [En ligne]. Available: https://mpls-rt.wikispaces.com/home. [Accès le 2 juin 2016].

[4] « courssnet.com,» 2015. [En ligne]. Available:
http://www.coursnet.com/2014/11/cours-frame-relay.html. [Accès le 20 mars 2016].

[5] «Cisco Systems,» 1992-2002 Cisco Systems. [En ligne]. Available: https://archive.icann.org/en/tlds/org/applications/register/attachments/h ardware/network/Color-Cisco_7200.pdf. [Accès le 03 Aout 2016].

Ouvrages spécialisés

[6] Université. de. Bechar, «igm.univ,» 12 juin 2013. [En ligne]. Available: http://www-igm.univ-mlv.fr/~dr/XPOSE2006/marot/architecture.html. [Accès le 12 avril 2016].

[7] B. B. e. J. M. Fourcade, «frame ip,» 2011-2015. [En ligne]. Available: http://www.frameip.com/mpls/. [Accès le 10 Avril 2016].

[8] N. O. Q. M. Z. Tarik NOUCHTI OuafaEl QASMI Med ZakariaHILALI, «Etude comparative et réalisation d'un VPN MPLS,» ecole marocaine des sciences de l'ingénieur, Maroc, 2009-2010.

[9] «CISCO,» [En ligne]. Available:
http://www.cisco.com/c/en/us/products/routers/buyers-guide.html. [Accès le 02 septembre 2016].

57

[14] julienberton, «Mise en place d'un VPN MPLS,» 16 fevrier 2015. [En

ligne]. Available: http://ccie.julienberton.fr/ipv6-forum-certified-
course-network-engineer-silver/. [Accès le 10 mai 2016].

Mémoires

[12] TANGUEP. FREDDY. Rolland, «CONCEPTION ET DÉPLOIEMENT DE LA TECHNOLOGIE MPLS DANS UN RÉSEAU MÉTROPOLITAIN,» Maroua, 2013.

Articles du web

[15] Guillon-Robin, «RSVP MPLS/TE Traffic Engineering,» 21 juin 2010.

[En ligne]. Available: https://wapiti.telecom-
lille.fr/commun/ens/peda/options/st/rio/pub/exposes/exposesrio2004/G uillon-Robin/public/3rsvpte/36comparaison.htm. [Accès le 17 mai 2015].

[17] [En ligne]. Available: http://www.httr.ups-
tlse.fr/pedagogie/cours/reshd/atm/concepts.htm. [Accès le 14 mars 2016].

[18] «ACAdemia,» 2016. [En ligne]. Available:
http://www.academia.edu/7036152/R%C3%A9seau_IP_and_Routage_ Comparaison_entre_les_diff%C3%A9rents_protocoles_de_routage_RI P_V1_RIP_V2_OSPF_EIGRP. [Accès le 24 Aout 2016]..

[19] C. N. ACADEMY, cour sur le Frame Relay, 2007-2008.

[13] « router-switch.com,» 2002-2016. [En ligne]. Available:

http://www.router-switch.com/Price-cisco-routers-cisco-router-7200-series_c41. [Accès le 25 Aout 2016].

ANNEXES

s Configuration du routeur LERMatrix1

hostname LERMatrix1

logging queue-limit 100

ip subnet-zero

no ip icmp rate-limit unreachable

ip tcp synwait-time 5

no ip domain lookup

ip vrf Client1

rd 1:1

route-target export 5:5

route-target import 1:1

ip cef

mpls label protocol ldp

mpls ldp logging neighbor-changes

mpls traffic-eng tunnel

s Configuration de la QOS

class-map match-all VOIP match access-group 101 class-map match-all ftp match access-group 102 class-map match-all hpriorite match ip dscp ef

class-map match-all bpriorite match ip dscp af23

policy-map dscp

class VOIP

set dscp ef

class ftp

set dscp af23

58

policy-map QOS

class hpriorite

priority percent 40

class ftp

bandwidth percent 30

s Création du Tunnel 1

interface Loopback0

ip address 171.16.1.1 255.255.255.255

interface Tunnel1

ip unnumbered Loopback0

tunnel destination 172.16.1.2

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 1 1

tunnel mpls traffic-eng bandwidth 512

tunnel mpls traffic-eng path-option 1 explicit

identifier 1

s Configuration des interfaces

interface Serial3/0

ip address 192.168.2.1 255.255.255.252

mpls traffic-eng tunnels

tag-switching ip

serial restart_delay 0

ip rsvp bandwidth 1000

interface Serial3/1

ip vrf forwarding Client1

ip address 192.168.25.1 255.255.255.252

s Le routage EIGRP

exit-address-family

s La création du chemin LSP

router eigrp 1

address-family ipv4 vrf Client1

redistribute bgp 1 metric 1024 1 255 1 1500

network 192.168.25.0 0 0.0.0.3

no auto-summary

autonomous-system 1

exit-address-family

s Le routage OSPF

router ospf 1

mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 log-adjacency-changes

network 171.16.1.1 0.0.0.0 area 0 network 192.168.2.0 0.0.0.3 area 0

s Le routage BGP

bgp log-neighbor-changes

neighbor 171.16.1.2 remote-as 1

neighbor 171.16.1.2 update-source

Loopback0

no auto-summary

address-family vpnv4

neighbor 171.16.1.2 activate

neighbor 171.16.1.2 send-community

extended

no auto-summary

exit-address-family

address-family ipv4 vrf Client1

redistribute eigrp 1 metric 1

no auto-summary

no synchronization

ip explicit-path identifier 1 enable next-address 171.16.2.1 next-address 171.16.5.1 next-address 171.16.3.1 next-address 171.16.1.2

59

s Création des ACL

access-list 101 permit tcp any any eq 16383 access-list 101 permit tcp any any eq 16384 access-list 102 permit tcp any any eq ftp-data access-list 102 permit tcp any any eq ftp no cdp log mismatch duplex

s Configuration du routeur

LERMatrix2

hostname LERMatrix2

logging queue-limit 100

ip subnet-zero

no ip icmp rate-limit unreachable

ip tcp synwait-time 5

no ip domain lookup

ip vrf Client2

rd 1:1

route-target export 1:1

route-target import 5:5

ip cef

mpls label protocol ldp

mpls ldp logging neighbor-changes

mpls traffic-eng tunnels

s Configuration de la QOS

class-map match-all VOIP

match access-group 101

class-map match-all ftp

match access-group 102

class-map match-all hpriorite

match ip dscp ef

class-map match-all bpriorite

match ip dscp af23

policy-map dscp

class VOIP

set dscp ef

class ftp

set dscp af23

policy-map QOS

class hpriorite

priority percent 40

class ftp

bandwidth percent 30

interface Loopback0

s Création du Tunnel 2

ip address 171.16.1.2 255.255.255.255

interface Tunnel2

ip unnumbered Loopback0

tunnel destination 171.16.1.1

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 1 1

tunnel mpls traffic-eng bandwidth 512

tunnel mpls traffic-eng path-option 1 explicit identifier 1

60

s Configuration des interfaces

interface Serial3/0 ip address 192.168.5.2 255.255.255.252 mpls traffic-eng tunnels

tag-switching ip serial restart_delay 0

ip rsvp bandwidth 1000

interface Serial3/1

ip vrf forwarding Client2 ip address 192.168.8.1

255.255.255.252

s Le routage EIGRP

router eigrp 1

auto-summary

address-family ipv4 vrf Client2 redistribute bgp 1 metric 1024 1 255 1 1500

network 192.168.8.0 0.0.0.3 no auto-summary autonomous-system 1 exit-address-family

s Le routage OSPF

router ospf 1

mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 log-adjacency-changes

network 171.16.1.2 0.0.0.0 area 0 network 192.168.5.0 0.0.0.3 area 0

s Le routage BGP

router bgp 1

bgp log-neighbor-changes

neighbor 171.16.1.1 remote-as 1

neighbor 171.16.1.1 update-source

Loopback0

no auto-summary

address-family vpnv4

neighbor 171.16.1.1 activate

neighbor 171.16.1.1 send-community

extended

no auto-summary

exit-address-family

address-family ipv4 vrf Client2

redistribute eigrp 1 metric 1

no auto-summary

exit-address-family

s Création du chemin LSP

ip explicit-path identifier 1 enable next-address 171.16.3.1 next-address 171.16.5.1 next-address 171.16.2.1 next-address 171.16.1.1

s Creation des ACL

access-list 101 permit tcp any any eq 16383 access-list 101 permit tcp any any eq 16384 access-list 102 permit tcp any any eq ftp-data

access-list 102 permit tcp any any eq ftp

Configuration du routeur LSR1 s Configuration des interfaces

61

interface Loopback0

ip address 171.16.2.1 255.255.255.255

interface Serial3/0

ip address 195.168.2.2 255.255.255.252

mpls traffic-eng tunnels

ip rsvp bandwidth 1000

interface Serial3/1

ip address 195.168.1.1 255.255.255.252

mpls traffic-eng tunnels

ip rsvp bandwidth 1000

interface Serial3/2

ip address 195.168.3.1 255.255.255.252

mpls traffic-eng tunnels

ip rsvp bandwidth 1000

s Le routage OSPF

router ospf 1

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

log-adjacency-changes

network 171.16.2.1 0.0.0.0 area 0

network 195.168.1.0 0.0.0.3 area 0

network 195.168.2.0 0.0.0.3 area 0

network 195.168.3.0 0.0.0.3 area 0

Configuration du routeur LSR2

s Configuration des interfaces interface Loopback0

ip address 171.16.5.1 255.255.255.255 interface Serial3/0

ip address 195.168.1.2 255.255.255.252

mpls traffic-eng tunnels serial restart_delay 0

ip rsvp bandwidth 1000 interface Serial3/1

ip address 195.168.4.1 255.255.255.252 mpls traffic-eng tunnels

serial restart_delay 0 ip rsvp bandwidth 1000

s Le routage OSPF

router ospf 1

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0 log-adjacency-changes

network 171.16.5.1 0.0.0.0 area 0 network 195.168.1.0 0.0.0.3 area 0 network 195.168.4.0 0.0.0.3 area 0 Configuration du routeur LSR3 ip cef

mpls label protocol ldp

mpls ldp logging neighbor-changes mpls traffic-eng tunnels

s Configuration des interfaces

interface Loopback0

ip address 171.16.1.1 255.255.255.255 interface Serial3/0

ip address 195.168.4.2 255.255.255.252 mpls traffic-eng tunnels

tag-switching ip

62

serial restart_delay 0

ip rsvp bandwidth 1000

interface Serial3/1

ip address 195.168.3.2 255.255.255.252

mpls traffic-eng tunnels

serial restart_delay 0

ip rsvp bandwidth 1000

interface Serial3/2

ip address 195.168.5.1 255.255.255.252

mpls traffic-eng tunnels

serial restart_delay 0

ip rsvp bandwidth 1000

s Le routage OSPF

router ospf 1

mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 log-adjacency-changes

network 171.16.3.1 0.0.0.0 area 0 network 195.168.3.0 0.0.0.3 area 0 network 195.168.4.0 0.0.0.3 area 0 Configuration du routeur Client1

s Configuration des interfaces

interface FastEthernet2/0

ip address 192.168.10.1 255.255.255.0 interface Serial3/1

ip address 192.168.25.2 255.255.255.252

63

? Le routage EIGRP

router eigrp 1

network 192.168.25.0 0.0.0.3

network 192.168.10.0

no auto-summary

Configuration du routeur Client2 ? Configuration des interfaces

Interface FastEthernet2/1

ip address 192.168.20.1 255.255.255.0 Interface Serial3/0

ip address 192.168.8.2 255.255.255.252 ? Le routage EIGRP

router eigrp 1

network 192.168.8.0 0.0.0.3 network 192.168.20.0 no auto-summary

Quelques commandes de vérifications

Show ip vrf : vérifies l'existence de la table VRF.

Show ip vrf `interfaces' : Vérifie les interfaces actives qui ont une VRF assigné Show ip route vrf emsi : Vérifies les informations de routage au niveau du routeur LER.

Traceroute vrf emsi `adresse IP' : Vérifies les informations de routage au niveau du routeur.

Show ip bgp vpnv4 tag : Vérifie le protocole de routage BGP.

Show ip cef vrf emsi `adresse ip' détail : Vérifie les informations de routage au niveau du routeur LER.