Memoire IRSM Nicolas Garnier 2 With Cover Page v2

Accelerat ing t he world's research.
Memoire IRSM Nicolas Garnier 2

Abdessamad Ouzayd
Related papers Download a PDF Pack of t he best relat ed papers 
CONSERVAT OIRE NAT IONAL DES ART S ET MET IERS JURY PRESIDENT MEMBRES
Younes Fahraoui
Memoire de fin d'ét ude

Ando Tsi
Nouveau Document Microsoft Office Word (2)

mohamed fet hallah
CONSERVATOIRE NATIONAL DES ARTS ET METIERS
PARIS
MEMOIRE
Présenté e vue d’o te ir

le DIPLOME d’INGENIEUR CNAM
SPECIALITE : Informatique
OPTION : Réseaux, Systèmes et Multimédia
Par
Nicolas GARNIER
Encadré par Xavier JEANNIN - RENATER
Étude, o eptio et déploie e t des te h ologies d’i gé ierie
de trafi sur l’i frastru ture de production MPLS de RENATER
Soutenu le 26 février 2013
JURY
PRESIDENT Jean Pierre Arnaud
MEMBRES Françoise Sailhan
Nicolas Pioch
Re e ie e ts
Je souhaite remercier tout particulièrement Xavier Jeannin, mon tuteur de stage, qui de
par son expérience, ses connaissances, sa cu iosit et sa o e hu eu ’a permis de
e e à te e e p ojet. Je le e e ie gale e t d’a oi pa tag avec moi son bureau
et ses bonzaïs pendant 9 mois.
Je tiens à remercier les membres des équipes de RENATER - Frédéric Loui, Lionel David,
Thierry Bono, Simon Muyal, Anthony Fisson ; de BT - Florence Picard et Dahlia Gokana ;
et de Cisco - Jérôme Durand et Vincent Makowski, ui ’o t t a s is leu s sa oi -faire.
Je remercie également Patrick Donath, directeur du GIP RENATER, et Laurent Gydé,

directeur technique, pou ’a oi pe is d’i t g e RENATER et de fi a e e p ojet,
notamment les déplacements aux Etats-Unis pour le CPOC, qui a été une formidable
expérience pour un futur ingénieur réseaux.
Je remercie mes professeurs du CNAM, Jean Pierre Arnaud, responsable de la chaire

réseaux et mon tuteur pédagogique pour ce mémoire, et Nicolas Pioch, pour leurs
enseignements des réseaux, vivant et de qualité.
Enfin, je remercie ma compagne, Célia Pasquetti, pour son soutien et son aide
inconditionnelle durant ces quatre années de cours du soir au CNAM.
Glossai e
AS Autonomous System : ensemble de réseaux informatiques IP
intégrés à Internet et dont la politique de routage est cohérente.
BGP Border Gateway Protocol : P oto ole d’ ha ge de outes e t e
différents système autonomes AS.
BT British Telecom Global Services, le prestataire qui assure la
maintenance, la configuration et la supervision de RENATER
CERN Organisation Européenne pour la Recherche Nucléaire
(originellement Conseil Européen pour la Recherche Nucléaire).
CC-IN2P3 Centre de Cal ul de l’Institut National de Physique Nucléaire et de
Physique des Particules.
CoS Classes of Services : Classes de services.
CR-LDP Constraint Routing LDP : E te sio de LDP pou l’ tablissement de
tunnels MPLS-TE.
CSPF Constraint Shortest Path First : Algorithme de calcul du chemin le
plus court dans un graphe contraint.
DSCP Differentiated Services Code Point : Code de différenciation de
services dans un paquet IP.
DWDM Dense Wavelength Division Multiplexing : Multiplexage optique
dense de longueur d’onde.
ECMP Equal-cost multi-path routing : Partage de charge à coûts de liens
égaux.
FRR Fast ReRoute : Mécanisme de résilience MPLS qui procure une
o e ge e apide e as de pa e d’u œud ou d’u lie .
GRIF Grille de Re he he d’Ile de France.
GTR Garanties de Temps de Rétablissement.
HNO Heures Non Ouvrées
IGP Interior Gateway Protocol : Protocole de routage interne.
IETF Internet Engineering Task Force : Littéralement « Détachement
d'ingénierie d'Internet ». Groupe informel, international, qui
produit la plupart des nouveaux standards d'Internet (RFC).
IOS Internetwork Operating System : Le « Système d'exploitation pour
la connexion des réseaux » produit par Cisco pour ses équipements
réseaux.
IP Internet Protocol : P oto ole d’ad essage, en versions v4 et v6.
IS-IS Intermediate System to Intermediate System : Protocole de
routage interne multi-protocoles à états de lien.
ISR Service RENATER Infrastructures pour les Services Réseaux
L2VPN Layer 2 Virtual Private Network : Interconnexion de réseaux privés
sur la couche 2 « liaison ».
L2VPN-PW Layer 2 Virtual Private Network Pseudo Wire : E ulatio d’u e
interconnexion directe Ethernet via un L2VPN.
L3VPN Layer 3 Virtual Private Network : Interconnexion de réseaux privés
sur la couche 3 « réseau ».
LDP Label Distribution Protocol : Protocole standardisé pour l'échange
d'information sur les étiquettes (labels) entre routeurs MPLS.
LHC Large Hardon Collider : Littéralement « Grand collisionneur de
hadrons ». Accélérateur de particule situé entre la France et la
Suisse au CERN.
LHCONE Large Hardon Collider Open Network Environnement : Réseau
distribué de transfert des données des expériences LHC.
LHCOPN Large Hardon Collider Optical Private Network : Réseau
hiérarchique de transfert des données des expériences LHC.
LSP-TE Label Switched Path Traffic Engineering : Connexion point à point
unidirectionnelle, dans un contexte MPLS, à laquelle est associé un
ensemble de paramètres TE.
MPLS Multi Protocol Label Switching : Protocole de commutation de
labels. pouvant être utilisé pour transporter tout type de trafic.
MPLS-TE Multi-Protocol Label Switching Traffic Engineering : Extension
d’i g ie ie de trafic pour MPLS.
NHOP et NNHOP Next HOP / NextNext HOP : Noeud à joindre dans le mécanisme
FRR.
NOC Network Operations Center : Service ou prestataire chargé du
contrôle et de la ai te a e d’u seau.
NR Nœud RENATER : Poi t de p se e d’u ou plusieu s uipe e ts
de œu de seau RENATER.
NREN National Research and Education Network : Réseau National pour
la Re he he et L’edu atio .
OSPF Open Shortest Path First : Protocole de routage interne IP à « état
de liens ».
QoS Quality of Services : Ensemble de mécanismes et de conventions
qui détermine le niveau de qualité visé sur un accès réseau.
RENATER Réseau National de télécommunications pour la Technologie
l'Enseignement et la Recherche. NREN français.
RSVP-TE Resource Reservation Protocol – Traffic Engineering : Protocole de
réservation de ressources – Extension pour le TE.
RFC Requests For Comments : Littéralement « demande de
commentaires ». Série u ot e de do u e ts pu li s pa l’IETF
décrivant les aspects techniques d’Internet.
TE Traffic Engineering : Ingénierie de trafic.
T0/1/2/3 Tier 0/1/2/3 : Hiérarchie de centres de calculs au sein des projets
LHCOPN et LHCONE
VRF Virtual Routing and Forwarding : Routage et Transfert Virtuel.
M a is e ui pe et d’instancier plusieurs routeurs virtuels dans
un même routeur physique.
Ta le des ati es
1 Introduction .................................................................................................................. 1
2 MPLS et Ingénierie de trafic ......................................................................................... 7
2.1 Enjeux et principes ................................................................................................ 7
2.2 MPLS-TE ................................................................................................................. 8
2.3 Signalisation des LSP-TE ...................................................................................... 18
2.4 Conclusion partielle ............................................................................................. 23
3 Étude du besoin .......................................................................................................... 24
3.1 Optimisation des liens de backup et contrôle du trafic ...................................... 24
3.2 Projet LHCONE..................................................................................................... 24
3.3 Analyse du périmètre réseau RENATER-5 ........................................................... 30
4 Choix des solutions et faisabilité ................................................................................ 36
4.1 Protocole de tests ............................................................................................... 36
4.2 Établissement de tunnels MPLS-TE ..................................................................... 39
4.3 Utilisation des tunnels MPLS-TE.......................................................................... 50
4.4 Types de trafic supportés par les tunnels MPLS-TE ............................................ 61
4.5 Gestion centralisée de MPLS-TE.......................................................................... 64
5 Généralisation et Déploiement .................................................................................. 65
5.1 Fonctionnalités MPLS-TE dans le périmètre réseau R-5 ..................................... 65
5.2 Choi de ise e œu e du p ojet LHCONE ....................................................... 66
5.3 Validatio su l’e se le du p i t e ............................................................. 71
5.4 Déploiement ........................................................................................................ 82
5.5 Exploitation ......................................................................................................... 83
6 Résultats et discussion................................................................................................ 84
6.1 Résultats du projet .............................................................................................. 84

6.2 Retour sur expérience ......................................................................................... 87
6.3 Perspective .......................................................................................................... 87
6.4 Bilan personnel .................................................................................................... 88
7 Appendices ................................................................................................................. 89
7.1 Table des illustrations ......................................................................................... 89
7.2 Références ........................................................................................................... 90
8 Annexes ...................................................................................................................... 91
8.1 Etude de métrologie RENATER............................................................................ 91
8.2 CPOC RENATER-5 TE ............................................................................................ 91
8.3 Supervision du tunnel MPLS-TE de test sur RENATER ........................................ 91
8.4 Base d’e ploitatio des tu els TE ..................................................................... 92
8.5 Etat du réseau après le déploiement de MPLS-TE .............................................. 93

1 Introduction
Les expériences menées en Suisse et en France par le CERN sur le collisionneur de

particules « Large Hardon Collider » (LHC) génèrent une très grande quantité de
données. Celles-ci sont distribuées à des centres de calculs internationaux, classés par
importance en Tier (T) 0, 1, 2 et 3.
Le T0 correspond au CERN, les T1 sont de grands centres de calculs mondiaux. En France

par exemple le CC-IN2P3 à Lyon et le GRIF en Ile de France. Le T0 et les T1 sont reliés au
réseau « Large Hardon Collider Optical Private Network » (LHCOPN). Les centres de
al ul d’i po ta e oi d e, T et T , so t eli s au T le plus p o he ia leu s
« seau atio au pou la e he he et l’ du atio » (NREN) respectifs.
La distribution des données suit le schéma d’a hite tu e « Monarch » [1], où toutes les
do es de a d es pa les T et T so t d’a o d pli u es su le T de rattachement.
Ce schéma ’est pas opti al a il nécessite d’i po ta ts espa es de sto kages de
données sur les T1 et génère beaucoup de trafic sur les liaisons T0-T1 et T1-T1.
Figure 1 - Distribution des données LHC dans le schéma "Monarch"
Le « Large Hardon Collider Open Network Environnement » (LHCONE) est une phase
complémentaire au LHCOPN, ui ise à e u seau d’i te o e io e t e les T , T
et T des diff e ts pa s pa ti ipa t, afi d’a lio e les ha ges et t a sfe ts de
données.
RENATER, le Réseau National de télécommunications pour la Technologie

l'Enseignement et la Recherche, a la charge du projet LHCONE pour sa partie française.
1
Introduction
Le « LHCONE France » est o pos d’u e a hite tu e opti ue d di e et de circuits de

type « Layer 2 Virtual Private Network » (L2VPN). Ces derniers utilisent l’architecture de
production IP/MPLS de RENATER.
La bande passante utilisée par les circuits transportés dans ces L2VPN étant importante,
il est nécessaire de contrôler leur influence globale sur le réseau et sur les
interconnexions vers le « LHCONE international », à Paris et Genève. Dans ce but, et afin
de ne pas augmenter à court terme la capacité de ses liens et interconnexions, RENATER
a hoisi d’utilise des a is es d’i g ie ie de t afi (Traffic Engineering TE).
Ces dernières devront permettre :

 D’ide tifie le chemin utilisé par les circuits L2VPN du projet LHCONE.
 De choisir un chemin à utiliser.
 D’opti ise l’utilisatio de l’infrastructure réseau de RENATER, et donc
de retarder de couteux investissements.
Les a is es d’i g ie ie de t afi is e œu e devront également pouvoir être

r utilis s da s d’aut es p ojets, endant le réseau RENATER « TE compatible ».
Ce mémoire présente en premier lieu, d’u poi t de ue th o i ue, les enjeux et

principes de l’i g ie ie de t afi , ainsi que les standards défi is pa l’i dust ie pour
MPLS. Nous ne décrirons pas ici le mode de fonctionnement général de MPLS, mais
seulement elui de ses e te sio s pou l’i g ie ie de t afi .
Il aborde ensuite, du point de vue opérationnel, les besoins de RENATER en ingénierie de

trafic, les choix technologiques possibles, puis l’ tude de faisa ilit et le déploiement de
la solution retenue. Les résultats et conclusions sont enfin proposés.
Présentation de RENATER
Le G oupe e t d’I t t Pu li RENATER a t o stitu e ja ie 1993 pour fédérer
les infrastructures de télécommunication pour la e he he et l’ du atio .
Les organismes membres du GIP RENATER sont de grands organismes de recherche :

CNRS, CPU, CEA, INRIA, CNES, INRA, INSERM, ONERA, CIRAD, IRSTEA, IRD, BRGM, ainsi
2
que le Mi ist e de l’E seig e e t sup rieur et de la Recherche et le Ministère de
l’Édu atio Nationale.
Plus de 1300 sites sont raccordés via les réseaux de collectes régionaux au réseau
national RENATER, dont une centaine déjà en IPv6. Ce réseau fournit une connectivité
atio ale et i te atio ale, il olue guli e e t e fo tio de l’ olutio des
technologies et des capacités des infrastructures disponibles.
Le réseau RENATER, aujou d’hui da s sa e sio is, est o pos d’u e i f ast u tu e
métropolitaine à très haut débit, et de liaisons internationales à haut débit. RENATER est
aussi p se t da s les d pa te e ts et te itoi es d’Out e-Mer.
Le GIP RENATER est gale e t aît e d’ou age du SFINX, poi t d’ ha ges e t e
opérateurs créé en 1995.
Le réseau RENATER fournit un service de connectivité IPv4 et IPv6 :
E o pl e t de l’u i ast, RENATER p opose u se i e ulti ast, disponible en mode

natif pour les deux versions du protocole IP (IPv4 et IPv6). Une offre de circuits dédiés
est disponible sur RENATER. Cette offre repose sur des technologies diverses (MPLS,
DWDM, etc).
Deux catégories de circuits sont disponibles :
 Des circuits point-à-point qui permettent un service d’i te o e ion privée
entre 2 établissements.
 Des circuits multipoints à ultipoi ts ui pe ette t d’i te o e te au sein
d’u e seau p i plusieu s ta lisse e ts RENATER.
RENATER propose également des services applicatifs tel que :

 Une solution anti-spam et anti-virus.
 Un se i e de F d atio d’Ide tit s Édu ation Recherche.
 Le service de mobilité réseau Eduroam.
 Une plateforme de certification, pour les serveurs et les personnes.
 Un service d’i te o e io d’IPBXs pour les établissements ayant déployé de la
ToIP.
3
Introduction
Figure 2 - Architecture réseau de RENATER
4
Figure 3 - Architecture de RENATER en Ile de France
Figure 4 - Organismes membres de RENATER
Plus d’i fo atio s peu e t t e t ou es su le site e de RENATER

http://www.renater.fr/.
5
Introduction
L’orga isatio i ter e de RENATER est la suivante :
Figure 5 - Organigramme interne de RENATER
Ce p ojet s’est d oul , entre octobre 2011 et juin 2012, au sei de l’ uipe
Infrastructure pour les Services Réseaux (ISR) dont le rôle est de piloter et de planifier
les olutio s du œu de seau RENATER.
6
2 MPLS et Ingénierie de trafic
2.1 Enjeux et principes

Les seau d’op ateu s so t aujou d’hui o f o t s à de nouveaux enjeux. La
c oissa e des d its d’a s, la convergence des services dits « triple play » (Internet,
voix/visioconférence, télévision/vidéo à la demande), ou comme dans le cas présenté
dans cette étude, des projets scientifiques aux besoins et exigences particulières.
Ces évolutions entraînent une augmentation considérable des volumes de trafic et de

nouvelles contraintes en termes de qualité de service (QoS) et de disponibilité du
réseau. Des mécanismes supplémentaires d’i g ie ie de t afic, de QoS et de
sécurisation deviennent alors nécessaires.
L’i g ie ie de t afi eg oupe l’e se le des thodes et mécanismes de contrôle du

outage pe etta t d’opti ise l’utilisatio des essou es, tout e ga a tissa t la QoS
(bande passante, délais... . L’o je tif de es mécanismes est de maximiser la quantité de
trafic pouvant transiter dans un réseau afin de retarder l’investissement dans de
nouvelles infrastructures.
Des solutio s d’i g ie ie de t afi o t t p opos es à chaque évolution des

technologies réseau. Nous allons nous concentrer ici sur celles qui s’appliquent aux
technologies IP [2] et MPLS [3], ui so t aujou d’hui utilis s da s u o bre de réseaux
d’op ateu s, dont RENATER.
Limitations du routage IP en ter es d’i gé ierie de trafi

Avec des réseaux IP, on dispose de peu d’outils pou effe tue à la fois du pa tage de
charge en plusieurs chemins, router explicitement du trafic en fonction de ses qualités et
éventuellement réserver des ressources.
Pour assurer ces fonctions, il est nécessaire de combiner des mécanismes de niveau 3,
comme les classes de services, le partage de charge, la manipulation de métrique, et des
mécanismes de niveau 2, comme la configuration des circuits virtuels qui permet de
créer une topologie logique correspondant aux besoins. Ces combinaisons apportent de
la complexité, influent généralement sur tout le trafic, et ont donc leurs limites.
7
MPLS et Ingénierie de trafic
Enfin le routage explicite proposé par IPv4, IP source routing [RFC791], est inefficient
pa e u’il suppose que chaque paquet contienne la description du chemin emprunté
dans le réseau. Cela présente plusieurs défauts majeurs : des risques liés à la sécurité,
une surcharge importante des paquets, un traitement complexe dans les routeurs
internes du réseau pour chaque paquet. Ce ode ’a ja ais ai e t t i pl e t
et utilisé, il est toutefois repris dans IPv6.
2.2 MPLS-TE
2.2.1 Présentation
L’i g ie ie de t afic appliquée aux réseaux MPLS est normalisée sous le nom MPLS-TE
(Multi Protocol Label Switching - Traffic Engineering) [RFC2702].
MPLS-TE pe et l’ ta lisse e t de LSP-TE (Label Switched Path – Traffic Engineering),
routés explicitement ou dynamiquement, en fonction de contraintes relative à une
topologie TE. Ces LSP-TE peuvent être assimilés à des connexions point-à-point, un
mode « circuit » est alors créé dans les réseaux IP/MPLS, s’appu a t su le routage
interne, mais fonctionnant en parallèle.
La technologie MPLS-TE permet également de répondre à des exigences de haute
disponibilité et de sécurisation des services notamment temps réels via le mécanisme
MPLS-TE Fast-Reroute.
Fonctionnalités notables proposées par MPLS-TE :
 Création de LSP-TE MPLS unidirectionnels, indépendants du routage IGP et

contraints par des critères de métrique, de bande passante requise (fixe ou
adaptative), de délai, etc.
 Qualité de service, grâce aux critères de bande passante, priorités
d’ ta lisse e t et de maintien des tunnels et aux chemins préférés (couleurs
administratives et affinités).
 Reprise rapide sur incident, sécurisation des LSP-TE (Fast-Reroute).
 Prise en compte des différentes Classes de services (CoS).
 Partage de charge entre plusieurs LSP-TE.
8
2.2.2 Architecture MPLS-TE
La partie suivante est une synthèse des éléments présentés dans le document MPLS :
applications à l’ingénierie de trafic et à la sécurisation par J.L. Le Roux [4].
Routage par contrainte MPLS-TE

Le routage MPLS-TE, dit « par contrainte », peut être décomposé suivant ces six étapes :
Figure 6 - Routage par contraintes MPLS-TE
En (1) et (2), se constitue une topologie TE, ou base de données TE (TEDB). Il s’agit d’u
graphe de réseau étendu dont les liens et les œuds possèdent un ensemble de
pa a t es d’i g ie ie de t afi . Ces derniers sont détaillés dans la partie §2.2.4.
Cette topologie TE est distribuée et mise à jour périodiquement da s l’e se le du

réseau par les protocoles de routage à états des liens classiques. Par exemple, OSPF ou
ISIS ont été étendus pour TE en OSPF-TE [RFC3630] et ISIS-TE [RFC5305].
En (3), la création de LSP-TE ou tunnels MPLS-TE. Il s’agit de LSP MPLS out s de faço
explicite ou dynamique dans la topologie TE. Ils sont caractérisés par un ensemble de
contraintes TE incluant la bande passante, le délai maximum, le nombre de sauts
a i u , les l e ts lie s, œuds à i lu e/e lu e, la p io it , et . Les paramètres
associés aux LSP-TE sont détaillés dans la partie §2.2.5.
Les étapes (4) et (5) décrivent les al uls elatifs à l’ ta lisse e t ou la modification des
LSP-TE. On parle de mode distribué (Online) lorsque tous les calculs de LSP-TE sont
alis s lo ale e t su les œuds de tête. A grande échelle, ce mode ’est pas optimal.
Les œuds de t te is ue t u e su ha ge et des i te s lo ages peu e t appa aît e.
9
Il est aussi possible de déporter l’e se le des traitements sur un serveur externe, qui
aura une vision complète de toute la topologie TE et de toutes les contraintes. Les
solutions adoptées pour le placement des LSP-TE seront alors optimales. On parle dans
ce cas de mode centralisé (Offline).
Signalisation des LSP-TE

La mise en place dans le réseau des LSP-TE calculés en étapes (4) et (5) est réalisée, dans
l’ tape (6), par les protocoles de signalisation TE, tels que CR-LDP [RFC3468] ou RSVP-TE
[RFC3209]. Ces protocoles ont également la charge de remonter les informations et
alertes TE aux équipements de tête de LSP-TE. Leurs fonctionnements sont décrits dans
la partie §2.3.
La performance de ces protocoles de signalisation permet aujou d’hui à MPLS-TE de

répondre à des exigences de haute disponibilité et de sécurisation des services temps
réels, via des mécanismes d’adaptatio et de protection avancés.
2.2.3 Types d’architecture et passage à l’échelle

Nous allons détailler ici les différentes d’a hite tu es qui peuvent être construites
autour de LSP-TE. On peut différencier deux types de LSP-TE, les primaires dont le rôle
est de faire circuler du trafic, et les secondaires dont le rôle est de protéger les
primaires.
Architecture de LSP-TE primaires

Le p e ie ode d’a hite tu e de LSP-TE primaires est appelé TE stratégique. Il
s’o ga ise autou d’u aillage complet de LSP-TE entre les routeurs (full mesh en
anglais). Cette architecture est construite pour servir de base de commutation globale
dans le réseau.
Habituellement cette architecture est réalisée e t e les outeu s de œu de réseau

P↔P. Mais elle peut aussi être mise e œu e e t e les routeurs de bordure PE↔PE.
Pour N routeurs, le nombre de LSP-TE initié par chaque routeur est N•(N-1). Il faut
ajouter à ce nombre les LSP-TE en transit entre deux autres routeurs. Ce dernier
pa a t e est d pe da t de l’a hite tu e ph si ue du seau o e de outeu s,
10
o e de sauts, et . , et est d’auta t plus i po ta t pou les outeu s de œu s
fortement maillés.
Au-delà d’u e tai o e de LSP, le mode de calcul des LSP centralisés (Offline)
devient indispensable pour le bon fonctionnement du réseau.
Figure 7 - Exemple de topologie TE stratégique : topologie physique
Figure 8 - Exemple de topologie TE stratégique : topologie logique
Les capacités de traitement et de mémoire des équipements données par les

équipementiers sont : pour Cisco en 2003, jusqu'à 600 LSP-TE terminant su u œud et
10.000 en transit, et pour Juniper, en Février 2012, 10.000 LSP-TE terminaux et 64.000
en transit. Les at iels olue t do da s le se s d’u e utilisatio de plus e plus
importante de LSP-TE.
11
Le se o d ode d’a hite tu e de LSP-TE primaire est dit TE tactique. On utilise ici des
LSP-TE pour des besoins ponctuels. Le nombre de LSP-TE est alors déterminé par les
pilotes du réseau.
Figure 9 - Tunnels TE tactique : Exemple de répartition entre les routeurs A et C
Complexité
La complexité du contrôle, par les machines mais surtout pour les humains, croit en
fo tio du ode d’a hite tu e TE et du o e de œuds p se ts dans le réseau.
Figure 10 - Complexité du contrôle des architectures MPLS-TE
Architecture de tunnels de protection

Les LSP-TE peu e t t e utilis s e p ote tio des lie s d’u e a hite tu e sta da d ou
d’u e a hite tu e TE. O pa le alo s de Protection de la connectivité. Les routeurs
calculent des LSP-TE de protection, complets ou de re-routage rapide (« Fast-ReRoute »
FRR). Seule la connectivité est préservée, pas forcément la bande passante. Il est donc
p f a le d’utilise également des mécanismes de classification de trafic pour éviter la
congestion dans un réseau dégradé.
12
Si les LSP-TE de protection réservent également de la bande passante, on parle alors de
Protection de la bande passante.
Cette architecture est plus complexe à ett e e œu e et à maintenir. Il faut conjuguer

MPLS-TE et des mécanismes de QoS. Aussi, une bande passante disponible plus
importante, globalement dans le réseau, est requise.
Toutefois, cette architecture permet de garantir des accords de qualité de service

(Service Level Agreement) définis entre un opérateur et son client, et ce même durant
des incidents sur le réseau.
2.2.4 Topologie TE
L’e se le des pa a t es TE sui a ts so t asso i s au lie s d’u e topologie TE dans
la TEDB. Les liens étant unidirectionnels, chacun de leurs sens peut avoir des paramètres
TE de valeurs différentes.
 La bande passante maximale pouvant être utilisée, qui correspond en général à
la bande passante physique du lien.
 La bande passante maximale réservable est disponible pour un ensemble de
LSP-TE sur le lien. Elle peut être supérieure à la bande passante maximale du lien,
pour prendre en compte le fait que tous les LSP-TE ne sont pas chargés
simultanément, on parle de « surréservation ». Elle peut être inférieure à la
a de passa te a i ale du lie , lo s ue l’o e eut d die u’u e pa tie d’u
lien pour les tunnels TE. On parle alors de « sous-réservation ».
 La bande passante disponible du lien. C’est la bande passante résiduelle
réservable par des LSP-TE sur le lien. Elle est modifiée dynamiquement lors de la
atio ou de la supp essio d’u LSP-TE. Huit valeurs de bande passante,
appel es « pools de a de passa te », so t asso i es à e pa a t e. Il s’agit de
la bande passante réservable pour chaque niveau de priorité et de préemption
des LSP-TE.
 Les groupes administratifs du lien, ou couleurs est un paramètre utilisé comme
co t ai te pou i lu e ou e lu e e tai s lie s d’un chemin. Cela permet
d’auto ise ou d’i te di e e tai s lie s au LSP-TE. On associe souvent ces
groupes administratifs à des couleurs.
13
 La métrique TE ie t o pl te la t i ue IGP. Elle pe et d’utiliser une

topologie avec des poids de liens différents de la topologie IP. Elle peut être
utilisée par exemple pour représenter le délai du lien, il devient alors possible de
calculer le plus court chemin avec délai contraint, la métrique IGP représentant
le critère à optimiser et la métrique TE le délai.
2.2.5 LSP-TE
Un LSP MPLS-TE est une connexion point à point unidirectionnelle à laquelle est associée
un ensemble de paramètres TE :
 L’adresse du routeur destination est l’ide tifia t TE du outeu dista t. Ce
dernier est une adresse interne logique (Loopback) annoncée dans les extensions
TE des IGP.
 Le chemin, explicite ou dynamique :
o Le chemin explicite est une su essio d’ad esses de lie s ou de œuds
que le LSP-TE doit e p u te ou e lu e. Il peut s’agi d’u he i
e pli ite o plet, ou d’u he i e pli ite pa tiel, i di ua t u e suite
o o ti ue de lie s et/ou de œuds à e p u te .
o Lo s ue le he i est e pli ite pa tiel ou u’il ’est pas sp ifi , o pa le
de chemin dynamique. Le chemin dynamique est alors calculé, soit par le
routeur de tête soit par un serveur central, à l’aide d’u algo ith e de
calcul de chemin contraint (Constraint Shortest Path First, CSPF). Le calcul
des chemins dynamique par les routeurs de tête pose toutefois un
po l e d’opti isatio de l’usage de la topologie TE. E effet, ha ue
routeur de tête ne connait l’ tat ue de ses propres LSP-TE. Des
ph o es d’i te lo ages peu e t do appa aît e.
Plusieurs paramètres existent pour améliorer cette problématique :
 Une réoptimisation périodique des chemins, initiée par une
temporisation paramétrable.
 Des p io it s de p e ptio d’ ta lisse e t et de ai tie des
tunnels.
14
 Le al ul des he i s peut t e d po t des outeu s d’e t e e s un
se eu e t al. L’opti isatio de l’e se le de la topologie TE est
alors assurée.
Le fonctionnement du calcul CSPF est détaillé en page 18.
 Les affinités sont utilisées conjointement avec les groupes administratifs des
liens, et permettent de définir les liens à inclure, à préférer et à exclure du
chemin.
 Les priorités de préemption sont un mécanisme permettant de définir des
niveaux de priorité pour les LSP-TE. En cas de pénurie de bande passante, un LSP-
TE prioritaire peut préempter un LSP-TE moins prioritaire pour récupérer la
bande passante allouée. Les priorités de préemption sont codées sur 3 bits de 0 à
7, 0 étant la plus forte priorité. Un tunnel possède deux priorités de préemption :
• La priorité de maintien (hold, ph) correspond à la capacité d’u LSP-TE à
résister à la préemption.
• La p io it d’ ta lisse e t (setup, ps o espo d à la apa it d’u LSP-
TE à préempter un autre LSP-TE.
Ces deu pa a t es e t u e situatio d’h st sis et pe ette t do
d’ ite les ph o es de ha ge e t d’ tat i te pestifs.
 La bande passante à réserver. Elle peut t e a solue ou s’adapte
dynamiquement à la charge réelle du LSP-TE. Dans le second cas, un phénomène
de eta d d’adaptatio peut appa aît e si les i te alles de esu e e so t pas
adapt s au t pe du t afi . Des seuils d’a o e de l’utilisatio de la a de
passante sont également paramétrables, pour évaluer une charge croissante ou
décroissante des LSP-TE.
 Le ode d’a o e des LSP-TE dans les tables de routage. Trois modes existent :
o Aucune annonce : le LSP-TE ’est pas a o da s la ta le de outage du
routeur. Il faut spécifier statiquement les routes qui emprunteront le LSP-
TE.
o « IGP Shortcut », ou « autoroute » : le LSP-TE est inclus dans la table de
routage du routeur de tête. La métrique du LSP-TE est utilisée pour le
calcul CSPF.
15
o « IGP Shortcut Forwarding Adjacancy » : le LSP-TE est annoncé comme

u e i te fa e ph si ue à tous les outeu s de l’IGP. Da s e ode, le LSP-
TE doit être bidirectionnel et comporter une métrique IGP (IS-IS ou OSPF)
 La métrique à utiliser pour le LSP-TE : ce paramètre, utilisé dans le mode « IGP
Shortcut, autoroute », indique la métrique à utiliser pour déterminer le plus
ou t he i o t ai t. Il s’agit de la t i ue TE ou de la t i ue IGP. La
métrique TE peut être absolue ou relative à la métrique IGP.
 Le partage de charge entre plusieurs LSP-TE : Ce paramètre permet à plusieurs
LSP-TE de partager une même destination suivant des chemins différents
(explicites ou dynamiques), avec une pondération du partage de la charge de
trafic utilisée dans chaque LSP-TE.
 Des LSP-TE de secours : Pour pallier les éventuelles d failla es d’u LSP-TE, il
est possible de paramétrer pour chaque LSP-TE des chemins de secours
explicites. Ces chemins de se ou s peu e t p e d e la fo e d’u LSP-TE global
préétabli dans la topologie TE, ou de LSP-TE de protection locale de lien ou de
œud Fast Re oute . Si au u LSP-TE de se ou s ’est o figu , le t afi sui a
le he i de l’IGP.
 De la qualité de service : MPLS-TE peut être considéré comme un mécanisme de
sig alisatio de he i o t ai t. S’il e se e pas ph si ue e t la bande
passante sur les liens mais des ressources dans la topologie TE, MPLS-TE est
toutefois capable de prendre en compte les divers mécanismes qualité et classes
de se i e d’u seau.
Si les LSP-TE sont en concurrence pour les ressources déclarées dans TEDB, MPLS-TE ne
procède en aucun cas à de la réservation de bande passante physique. Pour garantir de
la bande passante aux flux des LSP-TE, il faudra associer des mécanismes classiques de
classes de services (cf §8 « Diffserv Aware TE »).
16
Algorithme CSPF, réalisé en 3 phases :
Da s l’e e ple i-dessous, le outeu P est à l’o igi e du LSP-TE tel que :
LSP-TE 1 Origine : P1 Destination : P6 BP nécessaire : 8M Affinité : Liens noirs
20M 10M
50 50
P6
10M 10M 10M 20M

Phase 1 50 50 50
100
10M 5M
50 50
P1
20M
50
P6
Phase 2 10M 10M 10M 20M

100 50 50 50
10M
50
P1
20M
50
P6
10M 10M 10M 20M

Phase 3 50 50 50
100
10M
50
P1
10M : Bande passante TE disponible

100 : Métrique TE
Figure 11 – Algorithme de sélection du chemin dynamique CSPF en trois phases.
(1) Configuration du LSP-TE sur le routeur de tête : définition des objectifs et

contraintes.
(2) Elimination des liens qui ne valident pas les critères TE du LSP-TE.
(3) Calcul du plus court chemin (SPF) sur la topologie contrainte résultante.
17
2.3 Signalisation des LSP-TE

Dans la partie §2.2.2, nous avons évoqués deux protocoles de signalisation de LSP-TE
dans un réseau, CR-LDP et RSVP-TE.
L’id e de CR-LDP (Constraint-based Routing over Label Distribution Protocol) est

d’ajoute au p oto ole de dist ibution de labels LDP des fo tio s d’i g ie ie de t afi .
Malg e tai s a a tages, o e l’utilisatio actuelle de LDP dans les réseaux MPLS, et
u e o e sista e au passage à l’ helle, l’i dust ie lui a préféré RSVP-TE, pour des
raisons de maturité, de stabilité et de compatibilité inter-équipements.
La norme IETF de CR-LDP [RFC3468] est aujou d’hui en « status informationnal », ce qui
sig ifie u’elle e de ait plus t e utilis e et i pl e t e da s les équipements. C’est
pourquoi nous ne détaillerons pas son fonctionnement dans ce document.
2.3.1 RSVP-TE
RSVP est un protocole de signalisation desti à l’o igi e pour IntServ [RFC1633], un
modèle QoS. RSVP a par la suite été adapté pour devenir un protocole de signalisation
qui supporte les extensions nécessaires à MPLS-TE.
Le protocole RSVP-TE effectue trois fonctions principales dans le but de signaler le LSP-
TE le long du chemin préalablement défini :
 Il effe tue u o t ôle d’ad issio lo al, pou s’assu er que les contraintes sont
bien respectées (bande passante, groupes administratifs). Ce contrôle
d’ad issio lo al est essai e pou p e d e e o pte les as d’e eu de
calcul de route, par exemple lorsque les informations dans la TEDB ne sont plus à
jour.
 Il réserve la bande passante. La bande passante résiduelle du lien est
décrémentée de la valeur de bande passante du LSP-TE (pour tous les pools de
priorité inférieure ou égale à la priorité ph du LSP-TE). Il est important de noter
que cette réservation de ressources est purement logique et ne se traduit pas
par une réservation physique de bande passante.
 Il distribue les labels et entraîne une mise à jour des tables MPLS en transit et IP
en tête de LSP-TE.
18
RSVP TE est un « soft-state protocol ». Cela veut dire qu’il a besoin de rafraîchir
périodiquement ses réservations dans le réseau.
Messages et objets RSVP-TE

Le protocole RSVP-TE tourne entre routeurs adjacents. Il repose sur un ensemble de
messages o stitu s d’u e -tête RSVP commun suivi d’u e se le d’o jets RSVP-TE.
Ces messages sont transportés directement sur IP ou sur UDP. Par défaut, le
rafraîchissement périodique des messages permet de prendre en compte les éventuelles
pertes de paquets. Il existe également un mécanisme optionnel d’a uitte e t et de
retransmission permettant de traiter directement les éventuelles pertes de message. Les
principaux messages RSVP-TE sont les suivants :
 Path : Etablit et maintient le LSP-TE dans le sens descendant.

 Resv : Etablit et maintient le LSP-TE dans le sens montant.
 PathTear : Supprime le LSP-TE dans le sens descendant.
 ResvTear : Supprime le LSP-TE dans le sens montant.
 PathErr : Indique une erreur dans le sens montant.
 ResvErr : Indique une erreur dans le sens descendant.
 ResvConf : Confi e l’ ta lisse e t d’u tu el da s le se s des e da t.
 Srefresh : Rafraîchit un ensemble de sessions RSVP-TE.
 Hello : Mai tie t l’adja e e e t e deu oisi s RSVP-TE, permet de détecter la
pe te d’u oisi . Cette procédure est optionnelle.
Distinction entre tunnel TE et LSP-TE

RSVP-TE fait la distinction entre la notion de tunnel TE et de LSP-TE :
Un tunnel TE correspond à une entité de routage point à point unidirectionnelle, avec

des contraintes TE. Il est instancié par deux LSP-TE qui peuvent varier. Chaque LSP-TE
correspondant à un chemin particulier du tunnel TE.
Ainsi, RSVP-TE permet aux instances de tunnel TE de supporter divers évènements. Par
exemple un changement de route suite à une réoptimisation, un reroutage sur panne,
etc. Ce changement de LSP-TE s’effe tue sa s pe te de t afi , g â e à la p o du e de
création du nouveau LSP-TE, as ule du t afi puis supp essio de l’a ie LSP-TE
19
(« create before break »). Aussi, les ressources nécessaires ne sont pas réservées
plusieurs fois dans les TEDB des routeurs traversés.
Établissement des LSP-TE

L’ ta lisse e t d’u LSP-TE par RSVP-TE est effectué en deux temps. Tout d’a o d, un
message Path est envoyé de la source vers la destination, de proche en proche, le long
de la route explicite. Ce message Path contient les informations suivantes :
 L’adresse de la source et de la destination du LSP.

 Les numéros de tunnel et de LSP.
 La bande passante du LSP.
 Les groupes administratifs à inclure et ceux à exclure.
 Un ensemble de paramètres de classe de service et de sécurisation.
 La oute e pli ite du LSP, od e da s l’o jet ERO E pli ite Route Object).
À la réception du message Path, chaque routeur de transit instancie un nouvel état

RSVP-TE, enregistre les informations reçues dans le message et réalise un contrôle
d’ad issio lo al pou ifie ue le p o hai lie alide les o t ai tes TE du LSP-TE.
En réponse, le routeur de destination renvoie un message Resv de proche en proche

e s l’o igi e du tu el. Ce message Resv réserve la bande passante et distribue les
labels. Cela entraîne une mise à jour des tables MPLS en transit et de la table IP sur la
tête du tunnel TE.
Le message Resv contient les informations suivantes :
 L’ad esse de la sou e et de la desti atio du LSP.

 Les numéros de tunnel et de LSP.
 La bande passante du LSP.
 Le label alloué localement pour le LSP.
Lorsque le message Resv est arrivé sur la tête et que la table de routage IP est mise à
jour, le tunnel TE peut être utilisé pour aiguiller du trafic le long du LSP-TE.
20
La figure ci-dessous d taille les tapes du p o essus d’ ta lisse e t d’u LSP-TE avec
RSVP-TE, e do a t l’e e ple d’u e se atio le lo g du he i
R1R2R3R5R6R7.
Figure 12 – Exemple d’établissement de LSP-TE par RSVP-TE
(1) R1 est tête du tunnel TE (head-end), il envoie un Path message à R2. Celui-ci
vérifie le format du message et la disponibilité des ressources TE demandées.
Si les ressources ne sont pas disponibles, R2 renvoie un message PathErr à
R1, la s ue e d’ ta lisse e t est alo s a ul e.
(2) R2 envoie un Path message à R3. R3 fait les es ifi atio s u’e (1).
(3) R3 envoie un Path message à R5. Mêmes vérifications.
(6) R7 est la queue de tunnel TE (tail-end). Il envoie un Resv message à R6. Ce
message contient le label de commutation MPLS à employer pour le tunnel
TE par R6. Dans ce cas le label=implicit-null.
(7) R6 envoie un Resv message à R5 et indique un incoming label=42.
L’ ta lisse ent du LSP-TE est alors finalisé.
21
Maintien des LSP-TE, états RSVP-TE

À chaque LSP-TE signalé sur un œud est associé un état RSVP-TE. Celui-ci regroupe
l’e se le des i fo atio s du LSP-TE à savoir :
 Adresse source et destination.

 Numéros de tunnel-TE et de LSP-TE.
 Bande passante.
 Nœud précédent, œud sui a t.
 Route explicite.
 Labels entrant et sortant.
Cet état permet le maintien du LSP-TE, il est décomposé en deux sous-états :
 Le sous-état PSB (Path State Block) : créé par le message Path, il maintient les
informations contenues dans les messages Path reçus et retransmis.
 Le sous-état RSB (Resv State Block) : créé par le message Resv, il maintient les
informations contenues dans les messages Resv reçus et retransmis.
Si un sous-état RSVP-TE ’est pas afraîchi au-delà d’u e p iode d’e pi atio d’ tat, il
expire et le LSP est d t uit. Il s’agit d’u e p op i t de RSVP ue RSVP-TE hérite. Elle
présente certains avantages comme le support des pertes de messages, des reroutages
et des pertes de connectivité ainsi que la supp essio des tats e as d’isole e t d’u
œud. Elle présente également certains inconvénients, en particulier une lourdeur de
traitement et un impact sur la CPU des routeurs. À chaque sous-état RSVP-TE (PSB, RSB)
sont associés deux timers : le timer de rafraîchissement R, à 30s par défaut, et le timer
d’expiratio L. Par défaut, on a L = 4 R, ’est-à-di e u’u tat e pi e su non-réception
de quatre messages de rafraîchissement successifs.
Le rafraîchissement est une procédure locale entre deux routeurs qui utilise les
messages Hello. Toutefois, comme indiqué plus haut, la procédure de rafraîchissement
des états RSVP est très consommatrice de ressources, notamment les CPU des routeurs,
et pose des p o l es de passage à l’ helle. Un mécanisme de réduction des
rafraîchissements (Refresh Reduction, RR) a alors été défini dans la [RFC2961]. Ce
22
mécanisme consiste à transmettre des messages Srefresh contenant la liste des états à
rafraichir.
Cette p o du e d’a uitte e t et de du tio des rafraîchissements permet de

diminuer considérablement la quantité d’i fo atio s RSVP-TE à traiter pour le
maintien des états tout en conservant les propriétés soft state de RSVP.
Suppressio d’u LSP

La supp essio e pli ite d’u LSP-TE peut être initiée par la tête de tunnel TE, via un
message PathTear envoyé de la source à la destination. Ce message entraine la
destruction des états RSB et PSB.
La supp essio d’u LSP-TE peut être initiée par la queue de tunnel via un message
ResvTear, de la destination vers la source. Ce message détruit les états RSB. Il attend
ensuite la réponse de la tête de tunnel (message PathTear) pour entraîner une
destruction totale du LSP. La supp essio d’u LSP peut gale e t t e i pli ite, e cas
d’e pi ation des états RSVP.
2.4 Conclusion partielle

Au terme de ce chapitre, nous avons terminé la présentation et l’étude théorique de la
technologie d’i g ie ie de t afi pou MPLS, MPLS-TE.
MPLS-TE est u e se le d’outils et de a is es, qui viennent étendre MPLS. Il

fonctionne au-dessus et grâce à MPLS, sans en perturber le fonctionnement normal.
Deu odes d’a hite tu es pou MPLS-TE existent. Une utilisation globale, où
uniquement MPLS-TE est utilis pou l’a he i e e t du t afi . Cette app o he est
puissante mais complexe. Une utilisation ponctuelle, où l’o peut fi ie des
avantages de MPLS-TE sa s a oi à odifie toute l’a hite tu e seau.
Enfin, la seule méthode de signalisation disponible pour MPLS-TE est aujou d’hui RSVP-
TE, qui est le choix des principaux équipementiers réseaux (Cisco, Juniper, etc.). CR-LDP
est devenue obsolète.
23
Étude du besoin
3 Étude du besoin
Da s ette pa tie, ous allo s tout d’a o d p se te les esoi s fo tio els e
ingénierie de trafic de RENATER, pour le projet LHCONE.
Nous détaillerons ensuite les équipements, protocoles et mécanismes mis en place

actuellement sur RENATER-5. Nous pourrons ainsi choisir les fonctions et
implémentations de MPLS-TE o pati les a e l’e ista t, et d fi i u pla de ise e
œu e.
3.1 Optimisation des liens de backup et contrôle du trafic

L’a hite tu e seau de RENATER est fia ilis e pa la p se e de nombreux liens de
secours. A part quelque cas de point de présence RENATER pendulaire, chaque œud
RENATER (NR) est interconnecté au minimum avec deux autres NR. En dehors des
incidents ces liens restent inexploités, ce qui représente une perte de capacité et une
perte économique.
Ces incidents ayant une durée limitée et une occurrence faible, il est envisageable
d’utilise es lie s de se ou s pou quelques projets scientifiques compatibles avec un
partage ponctuel de la bande passante.
Pour réaliser cet usage, il faut t e apa le de s’aff a hi du outage i te e IGP) et de

contrôler le chemin emprunté par des trafics de type circuit L2 ou L3 VPN.
Le projet LHCONE est une illustration de cet usage, nous allons décrire ses besoins dans
la partie suivante.
3.2 Projet LHCONE
3.2.1 Contexte
Dans le cadre du projet de recherche international LHC, le LHCOPN (figure 13) est un
réseau dédié qui interconnecte les laboratoires du CERN T0 et des centres de calcul T1
répartis dans le monde entier. Les échanges de données entre T0, T1 et T2 suivent le
schéma « monarch, présenté en introduction. Le réseau LHCONE (figure 14) est une
24
phase complémentaire au LHCOPN. C’est u seau d’i te o e io qui vise à
distribuer les échanges de données avec et entre les T1, T2 et T3.
Tier 3
Tier 3
Tier 3
Figure 13 – LHCOPN, échanges hiérarchiques des données avec les T2.
Tier 3
Tier 3
Figure 14 – LHCONE, échanges distribués des données entre les T2.
25
Étude du besoin
La partie française du réseau LHCONE, adopte deu st at gies d’a hite tu e pour le
raccordement des sites :
 U seau d di , ui s’appuie sur l’a hite tu e opti ue de RENATER, et qui est
i d pe da t de sa politi ue de outage VLANs et lo gueu s d’o des opti ues
so t se es da s l’a hite tu e DWDM . Les sites T1 et les principaux T2 font
partie de ce réseau dédié ou y sont directement connectés. Le réseau « LHCONE
France» est connecté au réseau LHCONE général via deux interconnexions, à
Paris et à Genève.
 Des interconnexions de type point-à-point, des autres T2 et T3 au réseau
« LHCONE France». Ces connexions, de type L2VPN-PseudoWire (L2VPN-PW)
s’appuie o t su l’a hite tu e ph si ue et logi ue du seau RENATER.
Deux interconnexions entre le « LHCONE France » et le « LHCONE international » sont

présentes à Paris et à Genève.
Figure 15 – Infrastructure RENATER dédiée « LHCONE France».
26
Figure 16 – Tiers 1, 2 et 3 du réseau LHCONE sur RENATER
3.2.2 Besoins en ingénierie de trafic

Les connexions L2VPN-PW depuis les T2 et T3 devront aboutir sur les routeurs de Paris1,
Lyon1 ou Orsay (figure 15 afi d’ t e edi ig es da s le seau d di « LHCONE
France».
Plusieurs points sont à souligner quant à ces connexions :
 Le projet LHC est susceptible de consommer une grande quantité de ressources
en bande passante. En effet, le projet dans son ensemble génère et transmet au
moins 1 Hexabit de données par an. La consommation moyenne par site Tiers 2
est estimée à plus d’ Gbit/s.
 La cohabitation du trafic de ce projet avec les autres utilisateurs de RENATER est
possible sur le réseau de production. Cependant, le risque de saturation, de
manque de disponibilité du réseau causé par les liaisons L2VPN « LHCONE
France» ’est pas gligea le.
Du point de vue du réseau RENATER :

 Pour des questions de fiabilité, tous les NR sont au moins 2-connectés aux autres
NR. Da s la plupa t des as, o peut pa le d’u e liaiso principale, et d’une
liaison de secours. Cependant, une étude de la matrice des trafics est à réaliser
car pour un même NR certains préfixes IP peu e t t es out s ia l’u e ou
l’aut e des deu liaiso s.
 Les liaisons de secours sont peu utilisées par la politique de routage actuelle.
 Les liaisons de secours sont généralement performantes (10Gb/s).
27
Étude du besoin
 La liaison entre Lyon1 - Ge e est l’a s o i al pou l’i te o e io e s le

« LHCONE international » de Genève. Cette liaison est déjà chargée par le trafic
de production habituel de RENATER.
 L’utilisatio de a is es d’i g ie ie de t afi pou o ie te les liaiso s L VPN-

PW vers le « LHCONE France», au travers de ces liaisons de secours, apporterait les
avantages suivants :
 Utilisation/rentabilisation des liaisons de secours.
 Allègement, non saturation des liaisons principales du réseau RENATER.
 Gestion/Routage de flux sur le réseau avec allocation de ressources réseaux.
 L’usage des CoS de se i e pe ett ait de ga a ti u’e as de o gestio de
l’a s se ou s as de pa e de l’a s p i ai e pa e e ple , le t afi plus
prioritaire pourrait être écoulé sans dégradation de performance.
Da s l’e e ple i-dessous, une connexion L2VPN entre un Tiers 2 à Strasbourg et le

réseau « LHCONE France» à Paris 1 pourrait emprunter deux chemins physiques :
 Strasbourg-Nancy-Paris1, qui est le lien principal.
 Strasbourg-Nancy-Reims-Paris2-Paris1, le lien se secours.
Figure 17 - Exemple de L2VPN-PW orienté par de l’ingénierie de trafic
Les esoi s fo tio els e ter es d’i gé ierie de trafi so t :

 Création de tunnels TE conditionnés par des critères de bande passante
nécessaire et/ou de couleurs administratives et affinités.
 Capacité à sélectionner le trafic en transit dans ces tunnels TE.
 Sécurisation des tunnels TE : Tunnels TE de secours préétablis ou pré-calculés.
28
 Convergence rapide, réoptimisation des tunnels TE e as d’u e oupu e des
liens principaux ou de secours du réseau RENATER.
Des fonctions supplémentaires peuvent également être intéressantes :

 Partage de charge des tunnels entre plusieurs liens physiques.
 Supervision de ces liens, métrologie.
Ce projet ta t u pilote de l’utilisatio d’i g ie ie de t afi su RENATER, les hoi

fonctionnels devront permettre un déploiement et une évaluation rapide au sein du
réseau RENATER.
Les changements à apporter aux infrastructures et protocoles mis en place devront être
les plus légers possibles.
29
Étude du besoin
3.3 Analyse du périmètre réseau RENATER-5
3.3.1 RENATER-5, environnement matériel
Le réseau RENATER-5 métropolitain est o pos d’u e soi a tai e de œuds NR , et

d’e i o s routeurs. Tous ces routeurs sont de marque Cisco.
Figure 18 – Topologie métropolitaine de RENATER
Cinq modèles sont présents, leurs types et versions logicielle sont énumérées ci-dessous.
Type de routeur Version logicielle Code RENATER

Cisco 7609 Version 12.2(33) SRE3 RTR-021
Cisco 720X Version 12.4(24) T6 RTR-031
Cisco 6509-E Version 12.2(33) SXJ et 12.2(18) SXF12a SWI-001
Cisco 12410 Cisco IOS XR Software, Version 3.9.1 RTR-011
Cisco CRS-1 Cisco IOS XR Software, Version 4.0.1 RTR-001
30
Les routeurs de type CRS-1 sont les o ga es de œu du seau, leu s apa it s de
routage, de commutation sont les plus importantes. Trois routeurs de ce type sont
présents dans les NR de Paris 1, Paris 2 et Lyon 1.
Les routeurs de type 7609 sont utilisés dans la majeure partie des NR, complétés par
quelques routeurs de type 12410. Enfin, les commutateurs routeur de type 6509 sont
présents sur les sites de Lyon 1 et Orsay, ils sont dédiés à des projets spécifiques, type
LHCONE.
Les routeurs de type 720X ne participent pas au routage des projets de type LHCONE. Ils
sont utilisés pour le trafic Ipv6, le multicast et pour les liaisons vers les DOM-TOM. Ce
t pe de outeu e se a do pas p is e o pte da s l’ tude.
Aussi, le Réseau Académique Parisien (RAP , ui est e ou s d’i t g atio dans

RENATER, est composé de routeurs JUNIPER. L’ tude de la o pati ilit de es
équipements avec MPLS-TE se a effe tu e da s l’ tude de l’i t g atio de RAP da s
RENATER (prévue au 3ème et 4ème trimestre 2012).
RENATER est interconnecté à Internet via des opérateurs de transit IP et également via
le réseau GEANT (Gigabit European Advanced Network Technology). Au début de ce
projet, deux accès à GEANT existent, 1 primaire à Paris 1 et 1 secours à Paris 2.
La société British Telecom Global Services (BT) est le prestataire qui assure la
configuration, la supervision du réseau RENATER et la maintenance des équipements qui
le composent.
3.3.2 RENATER-5, architecture de routage

Les l e ts p i ipau de l’a hite tu e et du outage de RENATER-5 sont les suivants :
 Des liaisons point-à-point Ethernet entre les NR. Certaines de ces liaisons sont
doublées ou triplées. Le routage est alors effectué en partage de charge « Equal
Cost Multiple Path » ECMP.
 Le protocole de routage interne présent dans RENATER-5 est « Intermediate
System to Intermediate System » ISIS . C’est u p oto ole à tat des lie s. Les
tables de routage Ipv4 et Ipv6 sont séparées (mode ISIS multi-topology, dit
« dual-stack »).
31
Étude du besoin
 Le protocole de détection de coupure réseau « Bidirectionnal Forwarding

Detection » BFD est p se t su toutes les i te fa es de œu de seau. Les
réglages de BFD permettent de détecter une coupure en 150ms ou 250ms en
fonction des capacités physiques des routeurs.
 Le protocole de routage externe est BGP4. Il permet également de recevoir et de
propager les préfixes externes, c’est-à-dire des établissements raccordés à
RENATER et de tous les peers (Gigabit European Advanced Network Technology,
GEANT, transit, poi t d’ ha ge IX… . oute-reflectors (RR) sont déployés sur
Pa is et L o , si plifia t la o figu atio BGP e ita t d’a oi à o figu e
un maillage complet BGP.
MPLS
Les points importants de la politique de routage MPLS de RENATER-5 sont les suivants :
 MPLS est utilisé pour encapsuler le trafic Ipv4 unicast ainsi que les services
L2VPN et L3VPN. Les trafics Ipv4 multicast et Ip ’utilise t pas MPLS.
 MPLS fonctionne en mode « frame » : Un en-tête est ajouté devant le paquet IP.
 MPLS est a ti su toutes les i te fa es du œu de seau, pas su les interfaces
vers les sites utilisateurs de RENATER.
 L’allo atio de la el e s’appli ue ue pou les outes i te es app ises pa l’IGP.
 MPLS utilise une adresse de Loopback (lo2) des routeurs pour les désigner
 LDP [RFC5036] a été choisi comme protocole de distribution de label. Il repose
sur les tables construites par IS-IS. E as de o e ge e de l’IGP, celle de LDP
est immédiate.
32
3.3.3 Services de circuits dans RENATER-5
Les services VPN sont aussi déployés au-dessus de ce cœu MPLS.
RENATER p opose des solutio s d’i terconnexion privée de niveau 2, L2VPN Ethernet [5]
et de niveau 3 (L3VPN), reposant sur MPLS.
 Les L2VPN reposent sur la technologie « Virtual Private Wire Service » (VPWS),
ou « Pseudo-Wire » (L2VPN-PW) qui construit un circuit Ethernet point à point à
pa ti du œu MPLS.
 Les L3VPN reposent sur la technologie MPLS-VPN. Le mode utilisé est « any-to-
any », chaque site connecté au L3VPN peut dialoguer directement avec un autre
site, sans devoir passer par un site central. Les informations de routage sont
p opag es ia BGP au outeu s d’e t it .
L2VPN PseudoWire
Deux types de L2VPN PW peuvent être configurés, des L2VPN VLAN-à-VLAN et des
L2VPN port-à-port.
Figure 19 – Les différents types de L2VPN-PW dans RENATER
Da s le as d’u L VPN VLAN-à-VLAN, il est possi le d’a ti e plusieu s se i es su le

même port. Dans celui L2VPN port-à-po t, il est essai e u’u e i te fa e ph si ue
soit i t g ale e t d di e su ses deu e t it s. Il faud a alo s dispose d’u e aut e
interface physique pour les autres types de services.
33
Étude du besoin
Un L2VPN-PW est créé dans une architecture MPLS via les mécanismes suivants :
 Les interfaces de connexion des sites utilisateurs (CE) sont tagués avec un VLAN.
 Les interfaces de œu de seau PE) établissent une correspondance entre ce
VLAN et un circuit virtuel (VC). Le VC est acheminé vers la sortie du L2VPN-PW
par MPLS.
 En sortie, le VC est retraduit en VLAN (pas forcément identique).
Mapping VLAN ID vers VC ID Mapping VC ID vers VLAN ID
Vlan 2000 VC 222 VC 222 Vlan 2000

Nuage MPLS
CE 1 PE 1 PE 2 CE 2
Pseudo Wire
Figure 20 – L2VPN-PW dans une architecture MPLS
Da s le as d’u L VPN VLAN-à-VLAN ou les 2 sites interconnectés souhaitent

communiquer sur plusieurs VLAN, on utilisera la solution du QinQ (IEEE 802.1ad) qui
permet de dissocier les VLAN clients du VLAN de transport.
La figure ci-dessous présente les diff e tes e apsulatio s d’u e t a e Ethe et dans
un L2VPN-PW. Dans le premier cas, le VLAN de transport (Tag Service Delimiting ’est
pas transmis aux CE. Dans le second cas, il est supprimé, conservé ou échangé.
Figure 21 – Encapsulation d’une trame Ethernet taguée 802.1Q
34
L3VPN MPLS
La solution L3VPN MPLS présente sur RENATER-5 epose su l’e ploitatio de l’e -tête
MPLS, où l’o définit des VPN discriminés par un label supplémentaire (en plus du label
de commutation). Chaque VPN possède sa propre table de routage IP dans le concept de
Routage et Transfert Virtuel « Virtual Routing and Forwarding » (VRF) impliquant une
notion de « Route Distinguisher » et « Route target » (RD et RT). [RFC2547].
Le protocole de routage utilisé est BGP. Celui-ci échange les routes annoncées dans le
VPN via son extention Multi-Protocol BGP (MPBGP). Comme pour le fonctionnement
t aditio el de BGP, il est possi le d’utilise ou o u oute efle to RR . C’est le as
da s l’a hite tu e de RENATER.
Da s l’e e ple i-dessous, 3 routeurs clients (CE) sont interconnectés via un L3VPN sur
la VRF « VERTE ». Le RR a la charge de distribuer toutes les routes annoncés vers les
outeu s d’e t it (PE) appartenant à la VRF.
CE 2
Peering
eBGP
PE2
RR
Nuage MPLS
Peering
iBGP
PE 1 PE 3
CE 1
CE 3
Figure 22 – L3VPN sur VRF « VERTE » - Peering eBGP et iBGP sur Route Reflector
Du point de vue des sites interconnectés, le L3VPN se comporte comme un unique

outeu d’i te o e io . Seul l’usage des se i es Ipv4 unicast est permis dans un
L3VPN sur RENATER.
35
Choix des solutions et faisabilité
4 Choix des solutions et faisabilité
Cette section met en évidence le fonctionnement et le rôle des fonctionnalités de MPLS-

TE dans son implémentation proposée par Cisco. Nous pourrons alors choisir les
fonctionnalités qui répondent le mieux aux besoins du projet.
4.1 Protocole de tests

Afi de alide la o figu atio et l’usage des pa a t es d’u e topologie et des tu els
MPLS-TE, nous avions besoin de procéder à une phase de maquettage. Pour cela,
RENATER dispose ha ituelle e t d’u « banc de test » composé de 3 outeu s. J’ai
plutôt p opos d’utilise une maquette de réseau virtuelle via le logiciel de simulation
Dynamips/GNS3.
Ce logi iel est apa le d’ ule des platefo es de outeu s Cis o et toutes leu s
fonctions logicielles. Nous pouvons y injecter le système IOS de notre choix, en
l’o u e e l’IOS Version 12.2(33) SRE3.
L’i t t d’utilise u logi iel de si ulatio est de pou oi , à oi d e f ais et sa s
aucuns risques, recréer une topologie réseau dont le but est de représenter le plus
fidèlement les différents aspects du réseau RENATER-5.
Le choix des logiciels Dynamips/GNS3 a été porté par mes précédentes expériences
p ofessio elles, ou j’ai pu ota e t si ule et p pa e des o figu atio s de
o utateu s et de outeu s, et pa l’utilisatio pédagogique qui en est faite au CNAM.
Cette maquette est o stitu e de outeu s de œu s P à P , P ot RR et de deu

routeurs clients (CE1 et CE2). Deux machines virtuelles linux QEMU sont également
présentes, elles permettront de simuler un échange entre deux sites.
Les protocoles utilisés sont ceux présents sur R-5, à savoir :
 Le protocole de routage interne est IS-IS. Les métriques sont précisées sur la
figure 25. Pa sou i de si pli it , elles so t gales da s les deu se s d’u lie .
 Les métriques IS-IS sont par défaut de 10. Elles ont été fixées à 100 sur les liens
P4-P8, P8-P3, P3-P2, pour simuler un lien de secours.
 Les ha ges da s le œu de seau so t effe tu s pa MPLS.
 Les outeu s lie ts CE a o e t leu s p fi es IP au œu de réseau via BGP4.
36
Le protocole de tests suivi est :
 Deux phases de configuration de MPLS-TE :
o Configuration de la topologie TE et établissement de tunnels TE.
o Utilisation de ces tunnels TE dans le réseau.
 Pour chaque fonction et paramètre, présentation des commandes de
configuration, des traces de consoles avec leurs explication, pour des routeurs de
type Cisco.
 Les trafics de type ipv4 unicast, L2VPN et L3VPN seront insérés dans les tunnels
MPLS-TE.
 Deux machines virtuelles QEMU client/serveur « iperf » permettront de simuler
une charge de trafic dans le réseau.
 Qua tifi atio de l’i flue e des fonctionnalités MPLS-TE su l’utilisation CPU et
mémoire des routeurs, mais aussi sur le bon fonctionnement des autres
protocoles. Il est possible que ces deux aspects se révèlent non représentatifs sur
l’outil de si ulatio D a ips/GNS .
Toutes les notions évoquées dans les sections suivantes sont détaillées en §2.2.
La liste des commandes nécessaire à la programmation des routeurs est disponible sur le
site de Cisco1. Ces o a des so t ala les pou le s st e d’e ploitatio IOS Cis o.
Elles sont à transcrire pour les équipements qui fonctionnent avec IOSXR (Cisco CRS-1 et
12000).
1
Cf. références en §7.2
37
10.2.0.1 .26.0 10.6.0.1
.12.0
100 .36.0
.23.0
10.1.0.1 .13.0 10.3.0.1
.15.0 .35.0
.38.0
.17.0 10.5.0.1
100
.57.0 .58.0
10.7.0.1 .78.0 10.8.0.1
.48.0 Adresse de
.47.0 loopback
100 Sous-réseau
d’un lien en
10.0.x.x
10.4.0.1
Métriques IGP
Figure 23 – Architecture de test mise en place via Dynamips/GNS3
38
4.2 Établissement de tunnels MPLS-TE
Da s ette se tio , ous e o s les diff e tes phases li es à l’ ta lisse e t de tu els
MPLS-TE, ainsi que leur mise en concurrence pour les ressources de la topologie TE. Les
points suivants sont abordés :
 Configuration de la topologie TE.

 Éta lisse e t d’u tu el TE à he i e pli ite.
 Éta lisse e t d’u tu el TE à he i d a i ue.
 Configuration du critère de bande passante TE des tunnels.
 Critères de préemption des tunnels.
 Ré optimisation périodique des chemins des tunnels
 Annonce des ressources disponibles dans la topologie TE.
4.2.1 Topologie TE
La p e i e tape da s la alisatio d’u e a hite tu e MPLS-TE est de créer une
topologie TE. Cela consiste à déclarer pour toutes les interfaces du réseau les
paramètres suivants :
 Bande passante physique du lien.

 Bande passante réservable par le TE.
 Groupe administratif.
 Métrique TE.
E e ple de o figu atio d’u e i te fa e :

interface GigabitEthernet1/0
bandwidth 1000
ip rsvp bandwidth 1000 1000
mpls traffic-eng attribute-flags 0xABCD
mpls traffic-eng administrative-weight 5
o Bandwidth [1-10000000] : Ba de passa te e k ps de l’i te fa e. Rep se te

normalement la bande passante physique du lien.
o ip rsvp bandwidth A B :
 A : Bande passante réservable par des tunnels MPLS-TE. [1-10000000]
k ps ou pou e tage de la a de passa te de l’i te fa e.
 B : Bande passante réservable par flux dans des tunnels MPLS-TE. [1-
39
10000000] kbps
o attribute-flag (32 bit, en hexadécimal) : groupe administratif du lien. Il sera
comparé au champ affinity des tu els lo s de la phase d’ ta lisse e t des
tunnels.
o mpls traffic-eng administrative-weight : Métrique TE du lien (absolue ou
relative). Si un lien ne comporte pas de métrique TE, la métrique IGP est utilisée.
Sur chaque routeur, IS-IS-TE a la charge de propager les informations de topologie TE.
Visualisation de la topologie TE :
P4#sh mpls traffic-eng topology
[…]
link[1]: Broadcast, DR: 0000.0000.0001.01, nbr_node_id:14, gen:31
frag_id 0, Intf Address:10.0.15.1
TE metric:10, IGP metric:10, attribute flags:0x0
SRLGs: None
physical_bw: 1000 (kbps), max_reservable_bw_global: 1000 (kbps)
max_reservable_bw_sub: 0 (kbps)
Global Pool Sub Pool
Total Allocated Reservable Reservable
BW (kbps) BW (kbps) BW (kbps)
--------------- ----------- ----------
bw[0]: 0 1000 0
bw[1]: 0 1000 0
bw[2]: 0 1000 0
bw[3]: 0 1000 0
bw[4]: 0 1000 0
bw[5]: 0 1000 0
bw[6]: 0 1000 0
bw[7]: 100 900 0
[…]
O o se e les pa a t es TE ui s’ ha ge t ia IS-IS-TE dans les TEDB. Le
rafraichissement de ces informations est initié périodiquement par IS-IS, mais également
à ha ue odifi atio , ou se atio d’u e essou e.
Les tu els TE se o t is e o u e e pou l’o te tio et la se atio des

ressources TE. En cas de manque de ressources, les tu els e pou o t s’ ta li
directement, les mécanismes de préemptions (cf §4.2.5) se o t alo s is e œu e.
40
4.2.2 Etablissement d’un tunnel TE à chemin explicite
Nous allons configurer un tunnel MPLS-TE bidirectionnel entre P4 et P2 suivant le
chemin explicite P4 – P8 – P3 – P2. La configuration détaillée ci-dessous est celle du
tunnel unidirectionnel P4-P2 créé sur P4, la tête de tunnel.
10.2.0.1 .26.0 10.6.0.1
.12.0 .36.0
10.1.0.1 .13.0 10.3.0.1
.15.0 .35.0
Tunnel MPLS TE
.17.0 10.5.0.1
bidirectionnel
P4-P2
.57.0 .58.0
10.7.0.1 .78.0 10.8.0.1
Adresse de
.47.0 loopback
Sous-réseau
d’un lien en
10.0.x.x
10.4.0.1
Figure 24 – Tunnel MPLS-TE à chemin explicite
Nous créons tout d’a o d le détail du chemin explicite. C’est une liste ordonnée des
routeurs à inclure, ou à exclure :
ip explicit-path name Tunnel_1_pri enable
next-address 10.8.0.1
exclude-address 10.5.0.1
Un tunnel MPLS-TE est vu comme une interface par le routeur.

Co figu atio d’u tu el MPLS-TE à chemin explicite (paramètres de base, sur P4) :
interface Tunnel1
ip unnumbered Loopback1
tunnel destination 10.2.0.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 800
tunnel mpls traffic-eng path-option 1 explicit name Tunnel_1_pri
41
o tunnel destination : adresse de Loopback du routeur cible de sortie du tunnel.

o tunnel mpls traffic-eng priority : P io it s d’ ta lissement et de maintien du
tunnel.
o tunnel mpls traffic-eng bandwidth : Bande passante TE requise pour
l’ ta lisse e t du tu el.
o tunnel mpls traffic-eng path-option 1 explicit : Chemin explicite associé au
tunnel.
Statut et informations sur le tunnel :

P4#sh mpls traffic-eng tunnels tunnel 1
Name: P4_t1 (Tunnel1) Destination: 10.2.0.1
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type explicit Tunnel_1_pri (Basis for Setup, path weight 15)
Config Parameters:
Bandwidth: 800 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (interface)
AutoRoute: disabled LockDown: disabled Loadshare: 800 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : GigabitEthernet2/0, 34
RSVP Signalling Info:
Src 10.4.0.1, Dst 10.2.0.1, Tun_Id 1, Tun_Instance 18
RSVP Path Info:
My Address: 10.0.48.1
Explicit Route: 10.0.48.2 10.0.38.2 10.0.38.1 10.0.23.2
10.0.23.1 10.2.0.1
Record Route: NONE
Tspec: ave rate=800 kbits, burst=1000 bytes, peak rate=800 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=800 kbits, burst=1000 bytes, peak rate=800 kbits
Shortest Unconstrained Path Info:
Path Weight: 8 (TE)
Explicit Route: 10.0.48.1 10.0.48.2 10.0.58.2 10.0.58.1
10.0.15.2 10.0.15.1 10.0.12.1 10.0.12.2 10.2.0.1
History:
Tunnel:
Time since created: 12 minutes, 22 seconds
Time since path change: 1 minutes, 32 seconds
Number of LSP IDs (Tun_Instances) used: 18
Current LSP:
Uptime: 1 minutes, 32 seconds
Prior LSP:
ID: path option 1 [14]
Removal Trigger: configuration changed
o Status : sig ale l’ tat ad i ist atif et op atio el du tu el TE.
o Path option : Chemin sélectionné pour le tunnel et son poids.
o Config Parameters : paramètres généraux du tunnel.
42
o OutLabel : Label de commutation MPLS associé au Tunnel.
o RSVP Signalling Info : informations sur la signalisation RSVP du chemin du tunnel.
o Shortest Unconstrained Path Info : informations sur le plus court chemin existant
da s la topologie TE le tu el ’est pas fo e t ligi le au eilleu he i .
o History : Historique de création/modification du tunnel.
Plusieurs chemins explicites peuvent être déclarés pour chaque tunnel. Ceux-ci sont
définis par un niveau de priorité. Ces chemins secondaires seront sélectionnés
séquentiellement si le he i de plus fo te p io it e peut pas s’ ta li . O pa le alo s
de tunnel secondaire non établis.
Tunnel mpls traffic-eng path-option 2[+] explicit name «autre chemin explicite»
E fi , ette o a de ous pe et de ifie a uelle e t les apa it s d’a ueil de

la topologie TE a a t l’ ta lisse e t d’u tu el TE à he i e pli ite :
P4#sh mpls traffic-eng topology path destination 10.2.0.1 [paramètres]
Query Parameters:
Destination: 10.2.0.1
Bandwidth: 0
Priorities: 0 (setup), 0 (hold)
Affinity: 0x0 (value), 0xFFFFFFFF (mask)
Query Results:
Min Bandwidth Along Path: 1000 (kbps)
Max Bandwidth Along Path: 5000 (kbps)
Hop 0: 10.0.48.1 : affinity 00000000, bandwidth 5000 (kbps)
Hop 6: 10.2.0.1
o Query Parameters : paramètres demandés.

o Query Results : Chemins résultants qui répondent aux contraintes.
43
4.2.3 Etablissent d’un tunnel TE à chemin dynamique

La création de chemins dynamiques utilise un algorithme de recherche du chemin le plus
court selon des contraintes, CSPF (détaillé en §2.2.4).
Co figu atio d’u tu el à he i d a i ue :
interface Tunnel1
load-interval 30
tunnel mpls traffic-eng path-option 1 dynamic
tunnel mpls traffic-eng path-selection metric te
o path-option 1 dynamic : Le he i utilise l’algo ith e CSPF pou s’ ta li .

o path-selection metric te : type de métrique prise en compte dans le calcul CSPF.
Statut d’ ta lisse e t du tu el à he i d a i ue :
Status: Admin: up Oper: up Path: valid Signalling:
connected
path option 1, type dynamic (Basis for Setup, path weight 8)
Config Parameters:
auto-bw: disabled
State: dynamic path option 1 is active
[…]
RSVP Path Info:
Explicit Route: 10.0.48.2 10.0.58.2 10.0.58.1 10.0.15.2
10.0.15.1 10.0.12.1 10.0.12.2 10.2.0.1
On retrouve ici les mêmes informations que dans le status du tunnel TE à chemin
explicite. On peut toutefois observer des différences :
 State : dynamic path option 1 is active : indique que le tunnel TE est bien en
mode CSPF.
 Explicit Route : détail de la route choisie par le CSPF et signalée pour ce tunnel
TE.
Statuts généraux du tunnel :

P4#sh mpls traffic-eng tunnels tunnel 2 brief
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
44
Forwarding: enabled
Periodic 45epartition45on: every 3600 seconds, next in 3222 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 222 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
P4_t2 10.2.0.1 - Gi2/0 up/up
o Periodic reoptimization : le calcul CSPF est relancé périodiquement pour chaque

tunnel (voir §4.2.5).
Informations sur la topologie TE le long du chemin dynamique sélectionné :

P4#sh mpls traffic-eng topology path tunnel 2
Query Parameters:
Destination: 10.2.0.1
Bandwidth: 100
Priorities: 5 (setup), 4 (hold)
Affinity: 0x0 (value), 0xFFFF (mask)
Query Results:
Min Bandwidth Along Path: 800 (kbps)
Max Bandwidth Along Path: 4800 (kbps)
Hop 8: 10.2.0.1
Nous avons ici une vue générale de la topologie TE traversée par le tunnel, des affinités,
des disponibilités et réservations en bande passante TE.
La o pa aiso d’affi it e t e les tu els et la topologie TE pe et de est ei d e les

chemins des tunnels à un type, ou un groupe de liens :
interface gi 1/0
mpls traffic-eng attribute-flags 0xABCD
interface tunnel 2
tunnel mpls traffic-eng affinity 0xA000 mask 0x1000
o Attribute-flags : affi it de l’i te fa e da s la topologie TE, en hexadécimal.

o Affinity [valeur] [masque] : lo s du al ul CSPF, l’affi it du tu el est o pa à
l’att i ute-flags des interfaces. Si les deux aleu s o espo de t, l’i te fa e est
ligi le à la suite de l’algo ith e CSPF. Le as ue d’affi it se o po te de la
sorte : un bit à 1 dans le masque signifie « ne pas tenir compte de ce bit de
l’att i ute-flag pou la o pa aiso a e l’affi it du tunnel ».
45
Le te ps essai e à la sig alisatio et l’ ta lisse e t des tu els da s les odes

e pli ites et d a i ues ’a pu t e ua tifi su la a uette. Les do u e tatio s
a o e t u te ps de l’o d e de s
4.2.4 Bande passante des tunnels

La bande passante TE déclarée pour les tunnels sert de contrainte pour leur
établissement dans la topologie TE.
Mode statique
Ce ode o ie t lo s ue l’o a la o aissa e de la at i e des flu du seau, et ue
le trafic est lissé sur les liens.
Commande pour les tunnels TE :
interface Tunnel1
tunnel mpls traffic-eng bandwidth [global-pool|sub-pool] 800
Spécifie la bande passante du tunnel MPLS-TE et so t pe d’allo atio glo al|su -pool).
Dans le cas où la bande passante disponible dans la topologie TE est inférieure à celle
demandée par le tunnel, celui- i e peut s’ ta li , l’e eu « path error PCALC» est
retournée par le calcul CSPF :
Path Option 1:
Last Error: PCALC:: No addresses to connect 10.4.0.1 to 0.0.0.0
Mode automatique
Ce second mode pe et au tu el d’adapte sa o t ai te de a de passa te au trafic
réellement écoulé pendant un espace de temps.
Exemple de configuration :
interface Tunnel1
load-interval 30
tunnel mpls traffic-eng auto-bw frequency 300 max-bw 1000 min-bw 100
o load-interval [30-600] : Intervalle de temps utilisé pour le calcul de la bande

passante moyenne utilisée.
o frequency [300-604800] : Fréquence de mise à jour de la bande passante, en
secondes.
o max-bw 1000 min-bw 100 : Bande passante minimale et maximale autorisée
46
Résultat dans la table de routage :
P4#sh mpls traffic-eng tunnels tunnel 1 accounting
Tunnel1 (Destination 10.2.0.1; Name P4_t1)
30 second output rate 1043 kbits/sec, 104 packets/sec

Status:
Config Parameters:
auto-bw: (300/248) 0 Bandwidth Requested: 979
Samples Missed 0: Samples Collected 0
InLabel : -
OutLabel : GigabitEthernet2/0, 34
RSVP Path Info:
Explicit Route: 10.0.48.2 10.0.38.2 10.0.38.1 10.0.23.2 10.0.23.1 10.2.0.1
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
On observe ici le trafic écoulé pendant les 30 dernières secondes sur une interface de
type tunnel TE.
Le champ « auto-bw : (300/248) 0 Bandwidth Requested : 979 » indique que la valeur
demandée par le tunnel TE est bien mise à jour.
Résultat dans la topologie TE : la bande passante dans la topologie est réservée par
niveau de priorités :
link[0]: Broadcast, DR: 0000.0000.0004.02, nbr_node_id:19, gen:48
frag_id 0, Intf Address:10.0.48.1
TE metric:5, IGP metric:100, attribute flags:0x0
SRLGs: None
physical_bw: 1000 (kbps), max_reservable_bw_global: 5000 (kbps)
max_reservable_bw_sub: 0 (kbps)
Global Pool Sub Pool
Total Allocated Reservable Reservable
BW (kbps) BW (kbps) BW (kbps)
--------------- ----------- ----------
bw[0]: 0 5000 0
bw[1]: 0 5000 0
bw[2]: 0 5000 0
bw[3]: 0 5000 0
bw[4]: 0 5000 0
bw[5]: 979 4021 0
bw[6]: 0 4021 0
bw[7]: 0 4021 0
47
4.2.5 Fonctions d’adaptation
Préemption
Pour mettre en évidence le fonctionnement des niveaux de priorités de préemption des
tunnels, nous avons créé trois tunnels à chemin dynamique avec les paramètres
suivants :
interface Tunnel1
interface Tunnel2
interface Tunnel 3
Da s e as, la a de passa te dispo i le da s la topologie TE ’est pas toujou s

suffisante, les tunnels qui peuvent s’ ta li su les lie s TE se o t alo s eu ui o t la
plus fo te p io it d’ ta lisse e t. Aussi, la p io it de ai tie pe et à u tunnel déjà
établi de résister à une préemption.
L’o d e d’ ta lisse e t des tu els TE et leu s pa a t es de p e ptio o t do leu
i po ta e, des situatio s d’i te lo age ou de sous-optimisation de la topologie TE
pouvant apparaître. Les phases de réoptimisation décrites dans la section suivante
permettent dans une certaine limite de résoudre ces points.
Réoptimisation
La réoptimisation consiste à relancer périodiquement ou sur évènement le calcul CSPF
pour chaque tunnel à chemin dynamique :
mpls traffic-eng reoptimize events link-up
mpls traffic-eng reoptimize timers [delai] [frequence]
o events link-up : Initie la réoptimisation du tunnel MPLS-TE lors de la réception

d’u essage de ou elle adja e e IGP.
o timers [frequence] : Fréquence de réoptimisation périodique
48
o timers [delai] : Délai avant la première réopti isatio suite à l’ ta lisse e t du
tunnel MPLS-TE.
Interface tunnel 1
tunnel mpls traffic-eng path-option 1 dynamic lockdown
L’optio lo kdo pe et d’e p he la optimisation de ce tunnel à chemin

dynamique.
La réopti isatio p iodi ue pe et u e eilleu e utilisatio de l’e se le de la

topologie TE, de prendre en compte les éventuels changements de métrique IGP, TE, de
bande passante TE disponible, etc.
Toutefois, le al ul d’ ta lisse e t CSPF des tu els TE est lo al à ha ue outeu , et
da s le as d’u e topologie TE ha g e e tu els TE d’o igi e et destination diverse, la
seule réoptimisation périodique ne sera pas suffisante. Il faudra alors centraliser le calcul
de tous les chemins dynamiques MPLS-TE sur un serveur externe.
4.2.6 Annonce de la bande passante TE disponible.
Les interfaces de la topologie TE propagent régulièrement à travers le réseau, via IS-IS-

TE, l’ tat de l’utilisatio de la a de passa te TE.
Cette propagation est périodique, la fréquence peut être changée en utilisant la
commande suivante sur une interface :
interface Gi 2/0
mpls traffic-eng link timers periodic-flooding [180s par défaut]
Cette propagation peut également être déclenchée sur franchissement croissant ou

d oissa t des seuils d’utilisatio de la a de passa te. Pa d faut, les seuils sui a t
so t p se t su toutes les i te fa es d’u e topologie TE :
 Occupation BP décroissante (%) : 100, 99, 98, 97, 96, 95, 90, 85, 80, 75, 60, 45,
30, 15.
 Occupation BP croissante (%) : 15, 30, 45, 60, 75, 80, 85, 90, 95, 97, 98, 99, 100.
Il est possible de modifier ces seuils pour chaque interface afin de représenter au mieux
les o t ai tes ph si ues du seau et de s’adapte aux types de flux présents dans les
tunnels MPLS-TE do es, VOIP… .
49
interface Gi 2/0
mpls traffic-eng flooding thresholds up 15 30 50 60 70 71 72 73 74 80 100
4.3 Utilisation des tunnels MPLS-TE

Etude des différentes t pes d’utilisation des tunnels MPLS-TE. A savoir :
 Annonce des tunnels TE au reste du routage.
 Protection des tunnels TE.
 Partage de charge entre plusieurs tunnels TE.
 Types de trafic supportés par les tunnels TE.
4.3.1 Mode d’annonce du tunnel dans le routage interne

Les tunnels MPLS-TE peu e t t e a o s da s le outage i te e d’u seau de
diff e tes a i es. Le hoi du t pe d’a o e a i flue su la a i e de fai e
circuler du trafic dans ces tunnels (voir §2.2.5).
Au u e a o e da s l’IGP
C’est le o po te e t pa d faut des tunnels MPLS-TE. Ceux-ci ne sont pas annoncés
da s l’IGP, il faud a alo s sp ifie des outes stati ues ia le tu el pou des u e
adresse ou un préfixe IP.
P4(config)#ip route 192.168.0.0 255.255.255.0 tunnel 1
Résultat dans la table de routage :

S 192.168.0.0/24 is directly connected, Tunnel1
50
Mode d’a o e du tu el « IGP Shortcut, Autoroute »
Ce mode annonce le tunnel TE dans la table de routage IGP du routeur de tête du tunnel
TE. La métrique associée au tunnel est :
 La métrique cumulée du chemin traversé.
Ou
 La métrique « autoroute TE », qui peut être absolue ou relative (-10 ; +10) à celle
du chemin traversé.
Co figu atio d’u tu el MPLS-TE en mode « IGP Shortcut, Autoroute » :
interface Tunnel1
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng autoroute metric absolute 10
o tunnel mpls traffic-eng autoroute announce : annonce le tunnel dans la table de

routage IGP du routeur de tête du tunnel
o tunnel mpls traffic-eng autoroute metric [absolute|relative] : valeur de la
métrique associée au tunnel.
Aperçu de la table de routage du routeur de tête du tunnel MPLS-TE configuré en mode

« IGP Shortcut, Autoroute » :
P4#sh ip route
[…]
10.0.0.0/8 is variably subnetted, 24 subnets, 2 masks
I L1 10.0.12.0/24 [115/10] via 10.2.0.1, Tunnel1
I L1 10.0.13.0/24 [115/30] via 10.0.47.2, GigabitEthernet1/0
I L1 10.0.23.0/24 [115/10] via 10.2.0.1, Tunnel1
I L1 10.0.26.0/24 [115/10] via 10.2.0.1, Tunnel1
[…]
On observe que le Tunnel TE à bien pris sa place dans la table de routage Ipv4.
Mode d’a o e du tu el « IGP Shortcut Forwarding Adjacancy»

Le de ie ode d’a o e des tu els MPLS-TE est le mode « IGP Shortcut Forwarding
Adjacancy ». Celui-ci annonce le tunnel MPLS-TE comme un nouveau lien dans la
topologie de l’IGP. Tous les outeu s e so t do i fo s. Ce mode nécessite que le
tunnel soit bidirectionnel, et que les deux tunnels soient configurés de la façon
suivante :
interface Tunnel1
tunnel mpls traffic-eng forwarding-adjacency
isis metric 8 level-1
51
o tunnel mpls traffic-eng forwarding-adjacency : active le forwarding Adjacancy

pour le tunnel MPLS-TE
o isis metric 8 level-1 : spécifie la valeur de la métrique IGP annoncée pour le
tunnel (10 par défaut).
Statut des tunnels annoncés en « IGP Shortcut Forwarding Adjacancy » :

P4#sh isis mpls traffic-eng tunnel
System Id Tunnel Name BW Metric Nexthop Metric Mode
Forwarding-adjacencies
System Id Tunnel Name BW Metric Nexthop Metric Type
P2.00 Tunnel1 0 10.2.0.1
8 L1
Résultat dans les tables de routage : P4 est le routeur de tête du tunnel, P7 est un
routeur de la topologie IGP :
P4#sh ip route
I L1 10.0.12.0/24 [115/18] via 10.2.0.1, Tunnel1
I L1 10.0.15.0/24 [115/28] via 10.2.0.1, Tunnel1
P7#sh ip route
Le tunnel est déclaré dans la table de routage avec un poids ISIS égal à 8. La table de
routage du routeur P7 à bien pris en compte ce nouveau lien dans ses calculs de plus
court chemin.
4.3.2 Protection des tunnels MPLS-TE

Pour fiabiliser un tunnel MPLS-TE, plusieurs modes de protection existent :
 Rela e de la p o du e d’ ta lisse e t (§4.2.2) :
o Liste de chemins explicites non préétablis.
o Relance calcul CSPF.
 La protection globale, où un tunnel de secours complet est préétabli.
 La protection locale, appelée « Fast-Reroute », qui consiste à trouver des
solutions locales de se ou s autou d’u e oupu e de lie ou de œud et de
reprendre ensuite le chemin initial.
Ces deux derniers modes peuvent cohabiter, toutefois, certaines restrictions existent :
 Un tunnel de protection globale ne peut être lui-même protégé par de la
protection locale « Fast-Reroute ».
 Les chemins des tunnels de protection globale doit être explicite.
52
 Le routeur de tête du tunnel ne peut pas utiliser les deux modes simultanément.
Dans ce test, nous avons établi un tunnel MPLS-TE entre les routeurs P2 et P4 via P3 et
P8 et un tunnel de secours via P1 et P7. (cf. figure 25).
Protection globale :
Tunnel MPLS TE
Tunnel MPLS TE
Protection globale
bidirectionnel
bidirectionnel
P4-P2
P4-P2
Figure 25 – Exemple de protection globale d’un tunnel MPLS-TE
Sur le routeur de tête du tunnel MPLS-TE à p ot ge , il faut d’a o d o figu e u

chemin explicite pour le tunnel de protection :
ip explicit-path name Tunnel_1_sec enable
53
Co figu atio d’u tu el de p ote tio glo ale pou u tu el MPLS-TE :

interface tunnel 1
tunnel mpls traffic-eng path-option protect 1 explicit name Tunnel_1_sec
o Protect 1 : Il est possible de déclarer jusqu’à 8 tunnels de protection globale,

identifiés par niveau de priorité.
o Name Tunnel_1_sec : Chemin explicite du tunnel de protection globale.
En situation nominale, le tunnel MPLS-TE primaire est en service, celui de protection

globale est en attente. Il est également signalé et réserve des ressources dans la
topologie TE :
Status:
Path Protection: 0 Common Link(s), 0 Common Node(s)
path protect option 1, type explicit Tunnel_1_sec (Basis for Protect, path
weight 21)
[…]
Sont indiqués ci-dessus :
o Le chemin de protection globale choisi et son poids.
o Le o e de lie s et de œuds o u s e t e le he i o i al et le he i
de protection globale.
P4#sh mpls traffic-eng tunnels tunnel 1 protection

P4_t1 LSP Head, Tunnel1, Admin: up, Oper: up
Src 10.4.0.1, Dest 10.2.0.1, Instance 141
Fast Reroute Protection: None
Path Protection: 0 Common Link(s), 0 Common Node(s)
Primary lsp path:10.0.48.1 10.0.48.2
10.0.38.2 10.0.38.1
10.0.23.2 10.0.23.1 10.2.0.1
Protect lsp path:10.0.47.1 10.0.47.2
10.0.17.2 10.0.17.1
10.0.12.1 10.0.12.2 10.2.0.1
[…]
Cette commande permet de visualise l’ tat du tu el de p ote tio glo ale. Ces
de ie s h ite t des pa a t es tu el p i ai e t i ue TE ou IGP, t pe d’a o e
IGP, affinité).
54
Lo s de la phase d’ ta lisse e t, le tu el de se ou s e s’ ta li u’ap s le p i ai e.
On ne peut donc pas redémarrer le tunnel ou changer sa configuration lorsque celui-ci
est en mode dégradé.
Les évènements déclencheurs d’u e as ule su le tu el de p ote tio glo ale so t les
suivants :
 E eu d’ ta lisse e t du tu el MPLS-TE primaire (via signalisation RSVP-TE).
 Notifi atio de pe te d’adja e e ia l’IGP, RSVP Hello, « Bidirectional
Forwarding Detection » (BFD).
 Préemption des ressources TE par un tunnel aux priorités plus importantes.
Lorsque le tunnel TE primaire est hors service, celui de protection globale devient actif :
Status:
path protect option 1, type explicit Tunnel_1_sec (Basis for Protect, path
weight 21)
path option 1, type explicit Tunnel_1_pri
Path Protection: Backup lsp in use.
Path protect option 1, type explicit Tunnel_1_sec (Basis for Protect, path
weight 21)

P4_t1
LSP Head, Tunnel1, Admin: up, Oper: up
Fast Reroute Protection: None
Path Protection: Backup lsp in use.
Mesure du temps de convergence du chemin de protection globale : Ci-dessous, test de

coupure de tunnel TE. Une trace de ping entre les deux machines QEMU dont le trafic
circule via le tunnel TE.
Sending 100, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (99/100), round-trip min/avg/max = 8/76/304 ms
1% de pertes lors d’une bascule Tunnel TE principal / Tunnel TE de secours. A la vue des
faibles performances du simulateur (latence en 8 et 304ms), il est impossible de
quantifier le temps de convergence.
Ci-dessous, le test i e se, où l’o ta lit le t afi su le tu el p i ipal :

Sending 100, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
55
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 4/37/172 ms
Aucune perte ’est o se e da s e as.
En cas de défaut du tunnel MPLS-TE, le mode de protection globale fournit une

o e ge e plus apide u’u se o d he i p i ipal e pli ite ou d a i ue.
Le temps de convergence est toutefois dépendant du nombre de sauts effectués par le
tunnel et des délais de propagatio jus u’au outeur de tête. Le temps de convergence
reste toutefois trop important pour envisager la circulation de trafic à contraintes fortes
de qualité de services tels que de la voix ou de la téléphonie sur IP.
Prote tio lo ale d’u lie ou d’u œud « Fast Reroute » (FRR) :
Le mode de protection « Fast Reroute » pe et d’a liorer les lacunes des modes
précédents en termes de temps de convergence.
La p ote tio lo ale d’u lie ou d’u œud s’effe tue su le œud e a o t, où est
créé un tunnel de protection locale unidirectionnel FRR de type « Next HOP » (NHOP) ou
« Next Next HOP » (NNHOP).
Figure 26 – Tunnel de protection « Next Hop »
Figure 27 – Tunnel de protection « Next Next Hop »
56
Dans notre configuration les deux types de tunnels de Fast-Reroute sont testés :
 Un tunnel NHOP qui protège le tu el p i ipal d’u e d failla e du lie P -P3.
 Un tunnel NNHOP qui protège le tu el p i ipal d’u e d failla e du œud P .
Ces tunnels sont unidirectionnels, ils ne protègent le tunnel principal que dans le sens
P4-P2.
Tunnel
Fast-Reroute
NHOP
P8-P3
Tunnel
Fast-Reroute Tunnel MPLS TE
NNHOP 10.5.0.1
bidirectionnel
P8-P2 P4-P2
Figure 28 – Exemple de protection FRR d’un tunnel MPLS-TE
La procédure de création de tunnels de protection locale FRR est :
(1) Activer le FRR dans la configuration du tunnel TE sur le routeur de tête :

interface tunnel 1
tunnel mpls traffic-eng fast-reroute
57
(2) C atio du tu el de p ote tio de lie NHOP ou de œud NNHOP su le

routeur P8 en amont du lie / œud à p ot ge :
interface Tunnel 100
tunnel destination 10.3.0.1 | 10.2.0.1
tunnel mpls traffic-eng path-option 1 explicit name Tunnel_100_frr
o tunnel destination : 10.3.0.1 pour du NHOP

o tunnel destination : 10.2.0.1 pour du NNHOP
(3) Chemin explicite du tunnel de protection FRR :

ip explicit-path name Tunnel_100_frr enable
include-address « chemin complet NHOP ou NNHOP »
ou
exclude-address 10.0.38.2 ou 10.3.0.1
Il est possible de spécifier le chemin complet du tunnel NHOP/NNHOP ou de

sp ifie l’ad esse du lie ou œud à p ot ge .
o exclude-address 10.0.38.2 : Pour une protection de lien, spécifier
l’ad esse ip du lie à e lu e ad esse de l’i te fa e du outeu .
o exclude-address 10.3.0.1 : Pou u e p ote tio de œud, sp ifie la
loop a k du œud à p ot ge .
(4) Asso iatio du tu el de FRR a e l’i te fa e à p ot ge i te fa e d’a s au lie

ou œud à p ot ge :
interface gi 2/0
mpls traffic-eng backup-path tunnel 100
(5) Paramètres spécifiques du tunnel de FRR :

interface tunnel 100
tunnel mpls traffic-eng backup-bw [global-pool|sub-pool|any]
[valeur|Unlimited]
Sp ifie la a de passa te TE du tu el de FRR et so t pe d’allo atio .
(6) C atio d’u e sessio RSVP Hello e t e le lie ou œud à p ot ge et le œud

en amont. Cette session permettra détecter les défaillances :
Configuration générale du routeur
ip rsvp signalling hello
interface gi 2/0
ip rsvp signalling hello
Initie la session RSVP Hello entre les routeurs, à configurer globalement

p ote tio du œud puis su les i te fa es à p ot ge p ote tio du lie .
58
D tails d’u e sessio « RSVP Hello » entre P8 et P3 :
P8#sh ip rsvp hello client nbr detail
Hello Client Neighbors
Remote addr 10.0.38.1, Local addr 10.0.38.2
Nbr State: Normal Type: Reroute
Nbr Hello State: Up
LSPs protecting: 2
I/F: Gi2/0
Les tunnels de FRR ne sont pas associés à un tunnel MPLS-TE en particulier. Ils protègent
tous les LSP des tunnels MPLS-TE ui t a site t pa les lie s/ œuds p ot g s. Les
tunnels éligibles à la protection seront sélectionnés en fonction des ressources
disponibles dans la topologie TE, des paramètres des tunnels de FRR et des paramètres
de bande passante et niveaux de préemption des tunnels TE.
Détails des tunnels MPLS-TE protégés par les tunnels de protection FRR :
P8#sh mpls traffic-eng fast-reroute database
Headend frr information:
Protected tunnel In-label Out intf/label FRR intf/label Status
LSP midpoint frr information:

LSP identifier In-label Out intf/label FRR intf/label Status
10.4.0.1 1 [14] 34 Gi2/0:33 Tu100:33
ready
On voit ci-dessus que le tunnel 1 de P4 est pris en compte par un tunnel de FRR.
On peut également noter les labels MPLS en situation nominale et en situation de FRR.
P4_t1
LSP Head, Tunnel1, Admin: up, Oper: up
Fast Reroute Protection: Requested
[…]
Du point de vue de P4, la protection FRR est demandée. Le tunnel sera éligible au FRR
dans la topologie.
E situatio de d faut du lie ou œud p ot g , la sessio RSVP Hello ’est plus a ti e,

le défaut est alors détecté et le Fast Reroute activé :
P8#sh mpls traffic-eng fast-reroute database
Headend frr information:
Protected tunnel In-label Out intf/label FRR intf/label Status
LSP midpoint frr information:

LSP identifier In-label Out intf/label FRR intf/label Status
10.4.0.1 1 [14] 34 Gi2/0:33 Tu100:33
active
59
Du point de vue du routeur de tête du tunnel P , l’i fo atio du FRR le lo g du he i

est transmise sans que cela ’impa te l’ tat du tu el :
Status:
Change in required resources detected: reroute pending
L’i fo atio de eroutage est transmise au routeur de tête du tunnel TE. Une
réoptimisation pourra être lancée pour trouver un meilleur chemin.
La atio des tu els de p ote tio FRR d’u lie ou d’u œud peut gale e t t e
effectuée automatiquement via la configuration suivante :
Configuration générale du routeur :
mpls traffic-eng auto-tunnel backup
mpls traffic-eng auto-tunnel backup nhop-only
mpls traffic-eng auto-tunnel backup tunnel-num [min num] [max num]
mpls traffic-eng auto-tunnel backup timers removal unused sec
mpls traffic-eng auto-tunnel backup config affinity affinity-value [mask
mask-value]
o auto-tunnel backup : Active la protection FRR automatique.
o auto-tunnel backup nhop-only : exclu la création de tunnels FRR NNHOP.
o auto-tunnel backup tunnel-num [min num] [max num] : identifiant mini et maxi
des tunnels FRR.
o auto-tunnel backup timers removal unused sec : te ps a a t u’u tu el FRR
automatique non utilisé soit supprimé.
o auto-tunnel backup config affinity affinity-value [mask mask-value] : précise
l’affi it des tu els FRR auto ati ues.
Dans la a uette de test, ous ’a o s pas pu oi de diff e ce significative sur les

temps de convergence après défaillance entre les modes de protection globale et de
protection locale FRR. Cependant, le nombre de sauts et la charge de notre maquette
est limitée, et toutes les références à ce sujet concordent sur le fait que le mode de
protection Fast-Reroute fournit une convergence plus rapide que le mode de protection
globale. Nota e t pa e u’il ne dépend pas des délais de propagation dans le réseau.
Aussi, il est préconisé dans le cas de trafics à forte contraintes de QoS tels que de la voix
ou de la téléphonie sur IP.
60
4.3.3 Partage de charge entre plusieurs tunnels
U pa tage de ha ge e t e plusieu s tu els p i ai e ou de FRR peut s’ ta li si :
 Les tunnels ont la même origine/destination.
 Les tunnels ont le même poids (métrique TE en statique et « IGP Shortcut
autoroute », métrique IGP en « IGP Shortcut forwarding Adjacancy »).
Le partage de charge est effectué en fonction du rapport de bande passante TE des

tunnels ou en fonction des poids de répartition attribués :
interface tunnel 1
tunnel mpls traffic-eng load-share [poids de 61epartition]
D’ap s les sp ifi atio s fournies par Cisco, le partage de charge au moyen de tunnels
MPLS-TE conserve le séquencement des datagrammes TCP. Ce dernier point, important
du point de vue des performances pour l’utilisateu fi al, se a toutefois à vérifier.
4.4 Types de trafic supportés par les tunnels MPLS-TE
Trafic Ipv4
Comme indiqué dans la partie §4.3.1, deux solutions existent pour router du trafic Ipv4
dans un tunnel MPLS-TE :
 Route stati ue d’u e ad esse ou u p fi e ia u tu el MPLS-TE.
 D la e le tu el da s l’IGP ode IGP sho t ut autoroute ou IGP shortcut
Forwarding adjancy).
L2VPN-PW
Les L2VPN-PW utilisent la table de commutation MPLS pour acheminer le trafic. Ce

de ie suit do le outage d fi i pa l’IGP da s le seau.
Pour diriger explicitement le t afi d’u L VPN-PW, il est possi le d’asso ie le L VPN-
PW et son VC à un tunnel MPLS-TE. Pour cela on utilise la fonction « Preferred Path ».
61
Pseudo-Wire P Tunnel
Dirigé dans TE
tunnel TE
Mapping VLAN ID vers VC ID Mapping VC ID vers VLAN ID
Vlan 2000 VC 222 VC 222 Vlan 2000

Nuage MPLS-TE
CE 1 PE 1 PE 2 CE 2
Figure 29 – L2VPN Pseudo-Wire dirigé dans un tunnel MPLS-TE
pseudowire-class L2VPN
encapsulation mpls
preferred-path interface Tunnel1 [disable-fallback]
En cas de panne du tunnel TE, le L2VPN utilise le routage standard IGP. L’optio disa le-
fallback] permet de désactiver le L VPN si le tu el ’est pas op atio el.
D tail d’u e o e io L VPN :

P4#sh mpls l2transport vc detail
Local interface: Gi3/0.2000 up, line protocol up, Eth VLAN 2000 up
Destination address: 10.2.0.1, VC ID: 222, VC status: up
Output interface: Tu1, imposed label stack {33 16}
Preferred path: Tunnel1, active
Default path: ready [disable]
Next hop: point2point
o Output interface : le tunnel est sélectionné comme route préférée.

o Pile de labels MPLS {33 16} : 33 pour le label du L2VPN ; 16 pour le label de sortie
du tunnel MPLS-TE.
o Default path :
 Read si IGP utilis lo s ue le tu el ’est pas op atio el.
 disa le si l’optio disa le-fallback] est utilisée.
62
L3VPN
Les L3VPN MPLS utilisent la table de commutation MPLS pou a he i e le t afi d’u
PE à l’aut e. Da s le ode pa d faut, le t afi sui a do le outage d fi i pa l’IGP. O
peut toutefois déclarer des chemins explicites pour les VRF des L3VPN. Pour cela, il faut
déclarer une route dans VRF vers le PE de sortie « Next Hop » via un tunnel MPLS Traffic
Engineering.
Cette thode peut s’appli ue à u e oute e t e deu PE U seul Tu el TE u i ou

idi e tio el , o e à l’e se le du pla de outage sp ifi ue à la VRF C atio
d’u aillage o plet entre les PE concernés par la VRF, N∙(N-1)/2 connexions à créer et
maintenir).
CE 2
Peering
eBGP
PE2
RR
Tunnels
TE
PE 1 PE 3
CE 1
CE 3
Figure 30 – Utilisation de tunnels TE avec des L3VPN MPLS
La procédure est de configuration est :

1. Créations une loopback L (non a o e da s l’IGP .
2. Déclaration de cette loopback comme identifiant du routeur dans la vrf.
3. Sur les autres PE dans la vrf : Création une route statique vers la loopback L via le
tunnel MPLS-TE.
63
Sur PE1 Sur PE3
1 interface Loopback2 interface Loopback2
ip address 10.2.1.1 255.255.255.255 ip address 10.4.1.1 255.255.255.255
2 ip vrf RED
rd 2200:2
route-target export 2200:2
route-target import 2200:2
bgp next-hop Loopback2
3 ip route 10.4.1.1 255.255.255.255 ip route 10.2.1.1 255.255.255.255

tunnel 1 tunnel 1
Résultat dans les tables de routage :

S 10.4.1.1/32 is directly connected, S 10.2.1.1/32 is directly connected,
Tunnel1 Tunnel1
4.5 Gestion centralisée de MPLS-TE

La création et la gestion manuelle de tunnels MPLS-TE est possible pour un besoin ou un
projet ponctuel, comme pour la gestion des flux LHCONE. Cependant, la généralisation
de MPLS-TE, so utilisatio o eu i eau d’i f ast u tu e à pa t e ti e essite a
d’utilise u outil de gestion centralisé, et ce pour deux raisons :
 Hu ai e, a la gestio a uelle d’u ga d o e de tu els MPLS-TE
concurrents devient quasi-i possi le à pa ti d’u e tai poi t.
 Technique, car le mode décentralisé, où les tunnels MPLS-TE sont connus et
créés localement, génère une sous-optimisation de la topologie TE.
Les besoins de notre projet ne essite t pas le d ploie e t d’u e a hite tu e

centralisée, toutefois, il est intéressant de connaitre les produits existants sur le marché.
Nous avons recensés les outils de gestion centralisée MPLS-TE suivants :
 Cisco IP center.
 WanDL IP/MPLSView.
 WebNMS MPLS-TE.
 Packet design TE Explorer.
 Totem (Toolbox for Traffic Engineering Methods).
Il est toutefois diffi ile de s’appu e su u outil de gestion automatique sans craindre
de bug.
64
5 Généralisation et Déploiement
5.1 Fonctionnalités MPLS-TE dans le périmètre réseau R-5

Pour rappel, les quatre types de routeurs concernés dans cette étude sont :
Type de routeur Version logicielle

Cisco 7609 Version 12.2(33) SRE3
Cisco 6509-E Version 12.2(33) SXJ et Version 12.2(18) SXF12a
Cisco 12410 Cisco IOS XR Software, Version 3.9.1
Cisco CRS-1 Cisco IOS XR Software, Version 4.0.1
Nous avons dressé ci-dessous un inventaire de disponibilité, pour chaque plateforme et

version logicielle, des fonctions de MPLS-TE étudiées dans la section précédentes. Ce
tableau a été réalisé grâce aux documentations disponibles sur le site internet
www.cisco.com.
g
ion
erin
E)
cy
S-T
lect
ce
n
cen
in e
ctio
oun
e (D
)
l Se
FRR
TE
rge
Eng
dja
th
Sele
n
Ann
tric
wa r
S
nne
ctio
cha
wid
te (
IS-I
gA
ffic
me
nel
v-A
: Tu
rote
rou
an d
ute
d in
e de
sion
-Tra
/ TE
Tun
-Ser
t Re
war
oro
ob
PN
hP
tag
n
LS
Exte
CoS
L2V
Diff
Aut
Aut
IGP
MP
Fas
Pat
For
P ar
Chassis IOS
7609 v12.2(33)SRE3            
650X v12.2(33)SXJ            
650X v12.2(18)SXF12a            
12000 IOS XR v3.9.1            
CRS-1 IOS XR v4.0.1            
Fonctionnalités vérifiées avec des IOS Advance Enterprise Services
Un seul routeur 6509-E (Orsay-swi-001), en version 12.2(18) SXF12a, ’est pas

compatible avec toutes les fonctionnalités MPLS-TE. Il sera mis à jour en 12.2(33) SXJ.
Aussi, les trafics spécifiés comme compatibles avec MPLS-TE sont :
 Ipv4 unicast.
 Tout trafic encapsulé dans MPLS.
A l’i e se, les i o pati ilit s so t :

 Le trafic Ip ’est pas suppo t . La oha itatio a e MPLS-TE nécessite une
séparation des tables de routage Ip da s l’IGP.
 Le t afi ulti ast ’est pas suppo t ais ’est o ale e t pas i pa té.
65
Généralisation et Déploiement
5.2 Choix de mise en œuvre du projet LHCONE

L’a hite tu e i le du p ojet « LHCONE France» est :
 Chaque site Tier2 LHCONE est raccordé via un L2VPN MPLS-TE (qui sont nommés
L2VPN-TE) au réseau « LHCONE France» en deux points : Paris 1 et Lyon 1, qui
sont les points de sortie vers le LHCONE sur GEANT.
 Les sites établissent deux sessions BGP, au travers de chacun de ces L2VPN-TE. Le
site choisit son point de sortie principal via une règle en sortie de « Local Pref ».
 La sécurisation sera effectuée grâce à ces deux sessions BGP. Les mécanismes de
sécurisation des L2VPN-TE ne seront pas utilisés.
Figure 31 – Architecture cible sites Tiers 2 / FR LHCONE
Afi de espe te les o t ai tes te po elles du p ojet, j’ai p opos de ’utiliser que des
fonctionnalités « simples » de MPLS-TE, pour réaliser cette architecture, à savoir :
 Tunnel MPLS-TE à chemin explicite. Aucune utilisation des autres contraintes TE.
 Sélection de chemin préféré via tunnel MPLS-TE pour L2VPN-PW.
66
En prévision d’aut es utilisatio s de MPLS-TE sur RENATER, le protocole ISIS-TE sera
déployé sur tous les routeurs compatibles.
Matrice des trafics RENATER et choix des chemins LHCONE L2VPN TE

Afin de determiner les chemins les moins chargés sur RENATER, et donc où il sera
souhaitable de diriger les L2VPN-PW du « LHCONE France», la métrologie des différents
chemins entre chaque sites Tiers 2 LHCONE et leurs points de sortie Paris 1 et Lyon 1 à
été étudiée. (Cf Etude de la métrologie LHCONE Tiers 2 : §9 Annexes)
Il apparaît que :
 La sortie préférée vers le LHCONE devra être le plus possible vers Genève (donc
par Lyon 1) car une liaison LHCONE transcontinentale vers les USA est en cours
deploie e t à Ge e ise e se i e p ue pou l’ t .
 Malg l’utilisatio de MPLS-TE, certaines interconnexion sont inévitables et déjà
satu es. Elles se o po te t o e des goulets d’ t a gle e t. C’est le as de
la liaison entre les routeurs de Lyon1 (rtr001) – Lyon1 (rtr021). Un projet de
doublement de capacité (2x10G) est alors planifié.
Aussi, la capacité des liens Paris 1 – Lyon 1 et Paris 2 – Lyon 2 a été doublée, et une
nouvelle liaison Marseille 2 – Lyon 2 a été ajoutée, entre le temps de cette étude et la
suite du projet.
Cette étude des trafics dans le réseau RENATER est à mettre en relation avec un autre
p ojet de odifi atio de l’i f ast u ut e RENATER.
Jus u’à juillet , la o e io a e le seau GEANT, pou le t afi IP sta da d, se
situait sur le NR de Paris1. Cette liaison était saturée, et RENATER et GEANT ont été
forcés d’utilise p o isoi e e t la liaiso de se ou s depuis Pa is , e ui ’est pas
souhaitable. (cf figures 32 et 33).
U e tude d’o igi e et desti atio des flu à de o t u’u e pa tie i po ta te du
trafic était à destination et vers les utilisateurs RENATER raccordés sur Lyon1. Un
nouveau raccordement RENATER/GEANT à Genève a alors été planifié.
Hors, la liaison Lyon1 – Genève, déjà occupée par le trafic du LHCONE, ne pourrait pas
supporter ce nouveau cumul de trafic. Ce trafic passera donc dans un L2VPN-TE via le NR
de Grenoble (cf figure 31), la liaison Grenoble Genève étant alors inutilisée (cf figure 35).
67
Les graphes suivants représentent la quantité de trafic écoulée, en Gigabit par secondes,
sur la période de Janvier à mai 2012.
Figure 32 – Liaison primaire RENATER / GEANT saturée
Figure 33 – Liaison de secours RENATER/GEANT utilisée provisoirement
Figure 34 – Liaison Lyon1 – Genève, déjà utilisée par le LHCONE
Figure 35 – Liaison Grenoble – Genève inutilisée
68
Les propositions de chemins principaux et secondaires sont les suivantes :
Figure 36 – Chemins principaux LHCONE L2VPN TE
69
Figure 37 – Proposition de chemins secondaires LHCONE L2VPN TE
70
5.3 Validation sur l’ensemble du périmètre
Dans la section §4, nous avons testé et évalué les fonctionnalités de MPLS-TE dans un
environnement de simulatio . Toutefois, les gles d’i g ie ie et de d ploie e t su
RENATER nous imposent de procéder à une phase de validation en environnement réel,
afi de s’assu e de la o pe tu atio du d ploie e t su les se i es e p odu tio .
Pour ce faire, nous avo s tout d’a o d utilis le a de test dispo i le da s les lo au
parisiens BT. Hors, ce banc de tests est réduit à trois équipements (Cisco 7600, 12000 et
et ous ’a o s pas pu alide os tests su les platefo es et CRS-1,
essentiels au fonctionnement de RENATER (Cf. §3.3.1).
Nous avons alors planifié avec Cisco un programme de tests et validation, intitulé « Cisco
Customer Proof Of Concept, CPOC » (Etude de faisabilité de concept pour les clients
Cis o , où ous a o s fi i de tous les t pes d’ uipe e ts seau p se ts su
RENATER. Ce CPOC, d’u e du e d’u e se ai e, s’est d oul du au ai , da s
le centre de tests Cisco à San José, en Californie aux Etats-Unis.
Bie ue l’usage i itial de MPLS-TE sur RENATER soit restreint (Cf. §5.1), il a été décidé
de tester toutes les fonctionnalités étudiées dans la section §4. Aussi, afin de profiter de
l’oppo tu it de e CPOC, les tests de pe fo a e et d’i t g atio da s RENATER de
nouveautés Cisco ont été ajoutés, tel que la plateforme routeur ASR9000 et les liaisons
Ethernet 100 Gigabit.
Afin de pallier aux difficultés de reproduire dans un temps très court le contexte exact
du réseau RENATER, avec tous ses services opérationnels et dans l’o je tif de d plo e
rapidement dans RENATER les mécanismes MPLS-TE validés, les préparatifs décris dans
la se tio sui a tes o t t s is e œu e.
71
5.3.1 CPOC : Planification et préparatifs

Afi de pou oi alide , e u te ps t s ou t, l’e se le des tests d its da s la
section suivante, un cahier de tests a été rédigé. Celui-ci détaille précisément la mise en
œu e du CPOC : la topologie réseau, les matériels nécessaire, les versions logicielles et
les configurations des routeurs, les scénarios de tests et leurs résultats attendus. Ce
do u e t a gale e t pou ut de e ueilli l’e se le des o se atio s et sultats.
Le cahier de test CPOC est fourni dans sa version finale, allégé des configurations des
routeurs, da s l’a e e « CPOC RENATER -TE ».
Les participants au CPOC ont été les suivants :

o RENATER : Frédéric LOUI, responsable adjoint du pôle ISR.
o RENATER : Xavier JEANNIN, ISR, en charge du projet LHCONE.
o RENATER : Nicolas GARNIER, ISR, en charge du projet MPLS-TE, préparation et
coordination du CPOC coté RENATER.
o BT : Florence PICARD, responsable du compte RENATER.
o BT : Dahlia GOKANA, ingénieure réseau.
En position d’appui te h i ue :
o Cisco : Vincent MAKOWSKI, correspondant éducation et recherche. Préparation
et coordination du CPOC coté Cisco.
o Cisco : Jérôme DURAND, consultant routage et commutation.
La liste des tests et la topologie mise en place sont présentées dans le tableau et la
figure suivante. La première partie des tests vise à recréer la configuration et les services
actuels présents sur RENATER-5. La seconde partie traite des fonctionnalités MPLS-TE,
simples et avancées. Enfin, la dernière pa tie est d di e au tests d’i te op a ilit et
de performance de la nouvelle plateforme Cisco ASR9000 et des interfaces 100 Gigabit
Ethernet (100GbE).
72
Planning
Nom du test Validé
prévisionnel
Configuration initiale Jour 1
Test 1. IPv4 and IPv6 configuration Jour 1
Test 2. ECMP and LAG configuration Jour 1
Test 3. ISIS configuration Jour 1
Test 4. MPLS configuration Jour 1
Test 5. Injectors capabilities overview (IXIA) Jour 1
Test 6. BGP configuration Jour 1
Test 7. Multicast configuration Jour 1
Test 8. BFD for ISIS Jour 1
Test 9. L2VPN – VLAN Based Jour 1
Test 10. L3VPN – MPLS-VPN: Any to any VRF Jour 1
Test 11. 6VPE Jour 1
MPLS-TE
Test 12. ISIS-TE configuration Jour 2
Test 13. RSVP-TE Topology Jour 2
Test 14. Explicit path Jour 2
Test 15. Dynamic path Jour 2
Test 16. Static route over MPLS-TE tunnels – LAG & ECMP usage with TE Jour 2
Test 17. Auto Bandwidth Jour 3
Test 18. Autoroute announce Jour 3
Test 19. Forwarding Adjancy Jour 3
Test 20. L2VPN TE tunnel selection Jour 3
Test 21. L3VPN TE tunnel selection Jour 3
Test 22. Path protection Jour 4
Test 23. Fast Reroute Jour 4
Test 24. Load sharing Jour 4
Test 25. SNMP alarms and statistics Semaine
Test 26. Operation Administration and Maintenance (OAM) Semaine
MPLS-TE Avancés
Test 27. Full mesh Jour 5
100GE tests
Test 28. 100GE performance & stress test between CRS-2 and CRS-6. Jour 5
ASR-9000 intégration
Test 29. ASR-9000 integration (ISIS, BGP, LDP, RSVP-TE…) Semaine
73
ASR 9000 – 9
Traffic
Injector - 1 7600 – 1 7600 – 5
Traffic Injector - 3
Full routing BGP
70 isis adjacency
CRS – 2 CRS – 6
LACP LACP
7600 – 3 7600 – 7
Traffic injector
CRS1
7604S
12K 6500 – 4 12000 – 8

6504-E
ASR
9000
Traffic
Ethernet 100Gb
Ethernet 10Gb Injector - 2
Ethernet 1Gb
Figure 38 – Topologie du CPOC RENATER-5
L’o je tif de ette topologie est de pe ett e tous les tests essai es pe da t le
CPOC. Puisque cette topologie est p pa e à l’a a e de la se ai e de tests, elle-ci ne
pou a t e odifi e et il a do t i po ta t d’e isage tous les as de figu e.
74
5.3.2 Protocole de test défini
Le protocole général de test et de validation, pour tous les tests suit le cycle suivant :
1 - Test unitaire numéro X
2 - Configuration de tout les

4 - Le rapporteur des tests
routeurs. validation des
consigne les résultats et
fonctionnalités et
archive les sauvegardes
comportements
3 - sauvegarde des
configurations des routeurs
et des traces de résultats
dans Test_X_router_Y.zip
Figure 39 – Protocole de rapport des tests CPOC
Chaque test est organisé suivant les points :
 Objectifs : Description brève des objectifs fonctionnels du test et des résultats

attendus.
 Conditions : Prérequis matériels, protocolaires. Description du déroulement du
test.
 Configuration : Configuration complète des routeurs pour le test.
 Résultats : Traces de routeurs, tests de performance.
 Commentaires et recommandations.
75
5.3.3 CPOC, exemple de test : « Etablissement de tunnel TE à chemin

explicite »
Objectifs
Valide l’ ta lisse e t d’u tu el MPLS-TE à chemin explicite sur les plateformes
logicielles IOS et IOSXR.
Conditions
Dans le test suivant, tous les routeurs implémentent MPLS-TE. Les routeurs 7600-1,
1200-8, 6500-4 and CRS-2 seront les têtes (HEAD-END) de 3 tunnels aux chemins
suivants :
 Tunnel 1018 : 7600-1  CRS-2  7600-3  12000-8
 Tunnel 1014 : 7600-1  CRS-2  7600-7  6500-4
 Tunnel 1028 : CRS-2  CRS-6  7600-3  7600-7  12000-8
Le numéro d’i te fa e des tu els est d la sous la fo e « 10XY ». 10 signifie que

’est u tu el TE à he i e pli ite. X est le numéro du routeur de tête, Y le numéro du
routeur de queue.
Tous les tunnels sont également créés dans le sens inverse. Les paramètres par défaut
sont appliqués aux tunnels, les contraintes comme la bande passante requise, les
priorités etc. ne sont pas appliquées ici.
La topologie ise e œu re est décrite dans la figure 40 page suivante.
76
ASR
9000 – 9
Traffic
Injector - 1 7600 – 1 7600 – 5
Traffic Injector - 3
Tunnel Full routing BGP
1018/1081
Tunnel CRS1 – 2 CRS1 – 6

1014/1041
Tunnel
1028/1082
LACP LACP
7600 – 3 7600 – 7
&
6500 – 4 12000 – 8
Traffic
Injector - 2
Figure 40 – Topologie de l’exemple « Etablissement de tunnel TE à chemin explicite »
Configurations
! Pour CRS-2
!
explicit-path name CRS-2–12000-8
index 10 next-address strict ipv4 unicast 10.3.6.1
!
interface tunnel-te 1028
description TUNNEL TE1028–CRS-2–12000-8
ipv4 unnumbered Loopback2
load-interval 30
destination 10.3.8.1
path-option 10 explicit name CRS-2–12000-8
!
77
! Pour 12000-8
!
explicit-path name 12000-8–7600-1
!
explicit-path name 12000-8–CRS-2
!
description TUNNEL TE1081–12000-8–7600-1
load-interval 30
path-option 10 explicit name 12000-8–7600-1
!
description TUNNEL TE1082–12000-8–CRS-2
load-interval 30
path-option 10 explicit name 12000-8–CRS-2
!
! Pour 7600-1
!
load-interval 30
tunnel mpls traffic-eng path-option 10 explicit name 7600-1–12000-8
!
load-interval 30
!
ip explicit-path name 7600-1–12000-8 enable
index 10 next-address 10.3.2.1
!
!
! Pour 6500-4
!
load-interval 30
78
!
!
Résultats
Ces résultat sont valables IOS & IOSXR : traces de console de routeur, état détaillé des
tunnels MPLS-TE 1018 et 1028 sur 7600-1 et CRS-2.
7600-1#sh mpls traffic-eng tunnels tunnel 1018
Name : TUNNEL TE1018–7600-1–12000-8 (Tunnel1018) Destination : 10.3.8.1

Status:
path option 10, type explicit 7600-1-12000-8 (Basis for Setup, path weight
25)
Config Parameters:
Metric Type: TE (default)
AutoRoute announce: disabled LockDown: disabled Loadshare: 100 bw-based
auto-bw: disabled
InLabel : -
OutLabel : TenGigabitEthernet1/4, 16037
Next Hop : 10.0.12.2
RSVP Path Info:
Explicit Route: 10.0.12.2 10.0.23.2 10.0.38.2 10.3.8.1
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
Path Weight: 25 (TE)
Explicit Route: 10.0.12.2 10.0.23.2 10.0.38.2 10.3.8.1
History:
Tunnel:
Time since created: 7 minutes, 41 seconds
Time since path change: 6 minutes, 55 seconds
Current LSP : [ID : 1]
Uptime : 6 minutes, 55 seconds
RP/0/RP0/CPU0 :CRS-2#sh mpls traffic-eng tunnels 1028

Name : tunnel-te1028 Destination : 10.3.8.1
Status:
path option 10, type explicit CRS-2–12000-8 (Basis for Setup, path weight
105)
G-PID: 0x0800 (derived from egress interface properties)
Bandwidth Requested: 0 kbps CT0
Creation Time: Mon May 7 23:15:21 2012 (00:14:43 ago)
Config Parameters:
79
Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff

Hop-limit: disabled
AutoRoute: disabled LockDown: disabled Policy class: not set
Forwarding-Adjacency: disabled
Loadshare: 0 equal loadshares
Auto-bw: disabled
Fast Reroute: Disabled, Protection Desired: None
Path Protection: Not Enabled
History:
Tunnel has been up for: 00:14:43 (since Mon May 07 23:15:21 UTC 2012)
Current LSP:
Uptime: 00:14:43 (since Mon May 07 23:15:21 UTC 2012)
Path info (IS-IS 2200 level-1):

Hop0: 10.0.26.6
Hop1: 10.0.36.1
Hop2: 10.0.37.2
Hop3: 10.0.78.2
Hop4: 10.3.8.1
Displayed 1 (of 1) heads, 0 (of 2) midpoints, 0 (of 1) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads
Ces résultats ne sont valables que pour IOSXR : détail du chemin explicite du tunnel TE
1028 sur CRS-2.
RP/0/RP0/CPU0:CRS-2#sh explicit-paths
Mon May 7 23:36:22.289 UTC
Path CRS-2–12000-8 status enabled
0xa: next-address strict 10.3.6.1
0x14: next-address strict 10.3.3.1
0x1e: next-address strict 10.3.7.1
Tests de « traceroute » entre les routeurs CRS-2 et 12000-8, pour les chemins fixés par
l’IGP et par le tunnel TE 1028.
RP/0/RP0/CPU0:CRS-2#traceroute 10.3.8.1
Tracing the route to 10.3.8.1
1 10.0.26.2 [MPLS: Label 16031 Exp 0] 37 msec 20 msec 13 msec
2 10.0.67.2 [MPLS: Label 30 Exp 0] 15 msec 13 msec 5 msec
3 10.0.78.2 15 msec * 10 msec
RP/0/RP0/CPU0 :CRS-2#traceroute mpls traffic-eng tunnel-te 1028

Tracing MPLS-TE Label Switched Path on tunnel-te1028, timeout is 2 seconds
0 10.0.26.5 MRU 9180 [Labels : 16038 Exp : 0]
. 1 *
L 2 10.0.36.1 MRU 9214 [Labels : 118 Exp : 0] 192 ms
L 3 10.0.37.2 MRU 9204 [Labels: implicit-null Exp: 0] 202 ms
! 4 10.0.78.2 15 ms
Commentaires et recommandations
Au u p o l e ’est e o t da s l’ ta lisse e t des tu els TE à he i e pli ite.
L’i te op a ilit e t e les platefo es et les e sio s logi ielles et o e. Toutes les
plateformes ont été testées en tant que tête et queue de tunnel TE.
80
5.3.4 Conclusions du CPOC
La plupart des tests planifiés ont été validés avec succès. Ce CPOC a permis de vérifier
l’i te op a ilit de MPLS-TE sur les plateformes Cisco (CRS-1, 7600, 7200 et 12000) et
les versions logicielles (IOS et IOS-XR), dans un contexte de configuration et de services
présents sur RENATER-5.
Toutefois, quelques comportements indésirables ont été observés et quelques

fonctionnalités importantes manquent :
1. A cause d’u e li ite at ielle, les pa a t es BFD su les outeu s e

peuvent pas être réglés à moins de 3x250ms. Cela pourra être un inconvénient
pour les mécanismes de « fast-reroute ».
2. L’a ti atio d’ISIS-TE provoque des brèves pertes de paquets sur les L2VPN. Cette
activation devra donc être prévue en heures non ouvrées (HNO) sur RENATER-5.
3. Les gles de o figu atio pou l’utilisatio de MPLS-TE avec les L3VPN ne sont
pas les es pou IOS et IOSXR. Cela pou a t e u p o l e d’u poi t de
vue opérationnel.
4. Le ode de p ote tio glo ale à he i p ta li ’est pas dispo i le pou les
IOSXR 4.1 présent sur RENATER-5. Une mise à jour en 4.2 est nécessaire.
5. Les temps de convergence avec « Fast-Reroute » sont très satisfaisants.
Cependant le FRR ne peut pas être utilisé sur le routeur de tête de tunnel TE.
6. La répartition de charge sur des tunnels TE est fonctionnelle mais est trop
approximativement contrôlée.
7. Les odes d’auto o figu atio de aillage MPLS-TE (auto-tunnel mesh) ont été
testés mais leurs i pa ts su les se i es de RENATER ’o t pas t ifi s.
8. Les interfaces 100GbE ont été configurées avec succès entre les deux routeurs
CRS-2 et CRS- , ais les tests de pe fo a e ’o t pas pu t e e s à ause
d’u d faut d’i te fa e su les i je teurs de trafic.
Ces conclusions pourront être utiles lors de futurs projets impliquant MPLS-TE sur
RENATER. Les fonctionnalités requises dans le projet LHCONE ont toutes étés validées.
La se tio sui a te d is les p o essus de d ploie e t et de ise e œuvre.
81
5.4 Déploiement
Le déploiement des fonctionnalités MPLS-TE choisies en 5.2, dans le réseau de
production de RENATER, a été décomposé dans les étapes suivantes :
Etape Description Effets sur le réseau / Remarques
T0 Etat actuel
T1 A ti atio d’ISIS-TE sur 1 routeur Eventuelles pertes de paquets sur les
de chaque type. L2VPN, opération effectuée en HNO.
T2 C atio d’u tu el MPLS-TE de Aucun effet négatif observé sur le réseau.
test, sous surveillance pendant 2 Les figures 34 et 35 en annexe montrent
semaines. l’ tat de e tu el de test et so i pa t
sur le routeur de tête.
T3 Rédaction de la procédure de Règles de nomenclature et de
d ploie e t et d’e ploitatio numérotation, règles de configurations,
procédure de dépannage.
T4 Formation des équipes de BT à ces Quatre formations de 3h.
procédures.
T5 A ti atio d’ISIS-TE sur tous les Eventuelles pertes de paquets sur les
routeurs. L2VPN, opération effectuée en HNO, et
suivant un planning de migration
progressif.
2 à 3 routeurs/j. 20 jours de travail pour le
NOC RENATER.
T6 Création des tunnels TE pour le Aucun effet sur le trafic de production.
site LHCONE de Nantes suivant les
chemins définis en §5.2.
T7 Bascule des L2VPN LHCONE dans Eventuelles pertes de paquets sur les
les tunnels MPLS-TE. L2VPN. Opération effectué en journée et
en coordination avec les responsables des
sites concernés.
T8 Création des tunnels TE entre Séparation du trafic GEANT standard et
Lyon1 et Genève, puis bascule du LHCONE.
L2VPN-PW LHCONE.
82
5.5 Exploitation
La efo te du s st e d’i fo atio s SI de RENATER ta t à l’ tude lors de ce projet,
toutes les do es d’e ploitatio des tu els TE o t t pe to i es da s u fi hie de
type tableur Excel.
Ce fichier, fourni en annexe, a été o çu da s l’o je tif d’i tégrer les données dans le
futur SI. Chaque entrée de tunnel TE possède donc une clé de référencement unique.
Une carte de supervision « Weathermap » a été créée spécialement pour le projet

LHCONE. Tous les sites raccordés en L2VPN-TE, avec leurs information de chemin
primaire et secondaire apparaissent.
Figure 41 – Weathermap d’exploitation LHCONE
83
Résultats et discussion
6 Résultats et discussion
6.1 Résultats du projet

Nous présentons dans cette partie deux résultats :
 Le fonctionnement des L2VPN-TE entre le site LHCONE de NANTES / Paris 1 et
Lyon 1.
 La nouvelle infrastructure déployée entre RENATER et GEANT à Genève (cf §5.2),
et les fi es de l’utilisatio de MPLS-TE.
La as ule des L VPN du site LHCONE de Na tes da s des tu els TE ’a pas eu d’impact
négatif sur le trafic. Nous pouvons observer dans les deux graphes suivants que le trafic
emprunte bien le chemin TE vers Paris 1, suivant la règle BGP exprimée en §5.2. Sur le
L2VPN-TE Nantes-Lyon, on observe un trafic faible et régulier qui correspond au
maintien de la session BGP.
Figure 42 – Supervision du L2VPN-TE du site LHCONE de Nantes
Les traces fournies en annexe 8.5 fournissent les états complets MPLS-TE (IS-IS-TE, RSVP-
TE, etc.) du routeur de Nantes.
Les traces de métrologies suivantes illustrent les étapes du projet de nouveau

raccordement RENATER/GEANT à Genève.
(1) Le trafic Lyon1 – LHCONE est

basculé dans un L2VPN-TE via
le site de Grenoble (semaine 26
jour 2). Cette liaison de secours
est désormais mieux utilisée.
84
(2) La nouvelle interconnexion
RENATER / GEANT pour le
trafic IP standard est mise en
service (semaine 26 jour 4).
(3) On observe sur la liaison

Lyon1 – Genève la bascule
e te l’utilisatio pa le
LHCONE et l’utilisatio pa le
t afi IP sta da d t ou d’u
jour semaine 26).
(4) La liaison RENATER / GEANT à

Paris 1 est toujours chargée,
epe da t l’utilisatio de la
liaison de secours à Paris 2 a
pu être arrêtée (semaine 27).
85
A partir de ces deux cas de déploiement, nous pouvons établir que les objectifs suivants,
définis en début de projet, ont été remplis :
 Choix des chemins empruntés par des trafics identifiés et meilleure utilisation
des liens de secours. Cette opération, bien que manuelle et qui requière une
étude et une surveillance de la matrice des trafics dans le réseau, a permis dans
le as de l’utilisatio de la liaison Grenoble – Ge e d’ o o ise l’i stallatio
d’u e nouvelle liaison Lyon – Ge e, soit e i o s K€.
 D o gestio de e tai s a es et œuds. MPLS-TE nous a permis de détourner
certains flux du routage normal et a permis la décongestion planifiée de certains
points critiques. Attention toutefois, les mécanismes MPLS-TE associés aux
lasses de se i es ’o t pas t t ait s et se aie t sû e e t essai es e as
de panne sur le réseau.
Enfin, ce projet a mis en évidence que certains points et interconnexions se comportent

o e des goulets d’ t a gle e t i ita les. Les a is es d’i g ie ie de t afi
sont alors à utiliser en complément, et non en substitut total, de la gestion et du suivi
des apa it s de l’a hite tu e et de la topologie seau.
86
6.2 Retour sur expérience
Nous avons été fortement contraints dans le choix de la solution technique qui nous a
permis de répondre aux besoins de ce projet. Les technologies MPLS-TE et RSVP-TE sont
aujou d’hui les solutio s d’i g ie ie de t afi p opos es par les grands fabricants de
matériel réseaux.
La validation de MPLS-TE dans le contexte RENATER a été une partie très importante du
projet, dont les temps auraient difficilement pu être réduits. En effet, il était impératif
de e pas p o o ue d’effet de o d da s le seau. La ait ise de l’i pl e tatio
Cisco apportée par tous les tests effectués et par le CPOC nous ont permis de déployer
rapidement la solution.
Enfin, on peut ajouter que les outils de si ulatio seau ui o t t is e œu e pou

ce projet (Dynamips/GNS3 §4) sont désormais utilisés, dans la limite de leurs
possibilités, par les ingénieurs réseaux de RENATER pour des besoins de test et de
spécification.
6.3 Perspective
E plus du d ploie e t des aut es sites Tie s LHCONE, d’aut es usages possibles de
MPLS-TE ont été répertoriés :
o Partage de charge su l’axe doublé Paris-Lyon-Marseille (PLM).
o Gestio des t afi s su l’a e PLM ia des Tu els-TE.
o Utilisation de la topologie TE comme indicateur pour répartir les besoins
prévisionnels en bande passante des projets scientifiques.
o Utilisation du Fast-Reroute pour fiabiliser le service de voix et téléphonie
sur IP RENATER.
Comme évoqué dans la partie §6.1, l’étude de l’association Diffserv – MPLS-TE est un
sujet d’ tudes qui deviendra nécessaire pour la généralisation de l’utilisatio de MPLS-
TE dans RENATER.
De plus, l’utilisatio de tu els-TE e i te do ai e est aujou d’hui u sujet de

recherche actif, notamment avec BGP-TE [6], ce valide le choix de cette technologie pour
u e utilisatio plus i te se da s les seau d’op ateu s.
87
D’aut es solutio s et p oto oles ui pe ette t d’o te i des sultats si ilai es so t

gale e t à l’ tude, o e les « Software Defined Network » dont OpenFlow [7] est un
exemple prometteu et soute u pa de o eu a teu s de l’i fo ati ue IBM,
Google, etc.).
Comme pour MPLS-TE en mode décentralisé, OpenFlow déporte la partie routage dans
une intelligence centrale, appelée « Network OS », laissant seulement le rôle de
commutation au uipe e ts seau . O pou a t ou e u e e ple d’utilisatio pa
Google : http ://www.wired.com/wiredenterprise/2012/04/going-with-the-flow-google/
6.4 Bilan personnel

Du a t es ois, j’ai eu l’oppo tu it de t a aille su diff e ts aspe ts de la gestio
de p ojet. La da tio de l’ tude des esoi s, l’ tude de faisa ilit , la alidatio de la
solution choisie et la coordination du déploiement de tunnels MPLS-TE.
Le t a ail alis s’est a t s e i hissa t pou o e p ie e p ofessio elle, aussi

ie d’u poi t de ue th o i ue et te h i ue, u’hu ai . T a aille a e les
diff e tes e tit s de RENATER, so NOC et Cis o ’a pe is d’app he de le rôle de
ha u da s la ise e œu e et la gestio d’u e a hite tu e seau d’op ateu .
La phase p li i ai e d’ tude th o i ue a fait appel et a e i hi es thodes de

e he he et es o aissa es a uises lo s de a fo atio d’i g ieu au CNAM.
L’ tude de faisa ilit et la alidatio de la solutio te h i ue lo s du CPOC o t

grandement amélioré mes compétences techniques sur les protocoles et équipements
seau de t pe op ateu , ais gale e t a p ati ue et da tio de l’A glais
te h i ue. J’ai gale e t a i et pilot l’ uipe d’i g ie ie du a t la se ai e de
tests CPOC.
Enfin, la phase de déploiement a nécessité de travailler suivant les procédures internes à

RENATER : da tio des do u e ts d’e ploitatio , pla de d ploie e t, fo atio des
diff e tes uipes à la gestio et l’usage de es ou eau p oto oles. Cette pa tie ’a
pe is de o p e d e le t a ail d’u i g ieu d’ tudes et p ojets da s u e e tit
comme RENATER.
88
7 Appendices
7.1 Table des illustrations

Figure 1 - Distribution des données LHC dans le schéma "Monarch" ................................. 1
Figure 2 - Architecture réseau de RENATER ........................................................................ 4
Figure 3 - Architecture de RENATER en Ile de France.......................................................... 5
Figure 4 - Organismes membres de RENATER ..................................................................... 5
Figure 5 - Organigramme interne de RENATER ................................................................... 6
Figure 6 - Routage par contraintes MPLS-TE ....................................................................... 9
Figure 7 - Exemple de topologie TE stratégique : topologie physique .............................. 11
Figure 8 - Exemple de topologie TE stratégique : topologie logique................................. 11
Figure 9 - Tunnels TE tactique : Exemple de répartition entre les routeurs A et C ........... 12
Figure 10 - Complexité du contrôle des architectures MPLS-TE ....................................... 12
Figure 11 – Algorithme de sélection du chemin dynamique CSPF en trois phases. .......... 17
Figure 12 – E e ple d’ ta lisse e t de LSP-TE par RSVP-TE .......................................... 21
Figure 13 – LHCOPN, échanges hiérarchiques des données avec les T2. .......................... 25
Figure 14 – LHCONE, échanges distribués des données entre les T2. ............................... 25
Figure 15 – Infrastructure RENATER dédiée « LHCONE France». ...................................... 26
Figure 16 – Tiers 1, 2 et 3 du réseau LHCONE sur RENATER ............................................. 27
Figure 17 - Exemple de L2VPN-PW o ie t pa de l’i g ie ie de t afi .......................... 28
Figure 18 – Topologie métropolitaine de RENATER .......................................................... 30
Figure 19 – Les différents types de L2VPN-PW dans RENATER ......................................... 33
Figure 20 – L2VPN-PW dans une architecture MPLS ......................................................... 34
Figure 21 – E apsulatio d’u e t a e Ethe et tagu e . Q ..................................... 34
Figure 22 – L3VPN sur VRF « VERTE » - Peering eBGP et iBGP sur Route Reflector.......... 35
Figure 23 – Architecture de test mise en place via Dynamips/GNS3 ................................ 38
Figure 24 – Tunnel MPLS-TE à chemin explicite ................................................................ 41
Figure 25 – E e ple de p ote tio glo ale d’u tu el MPLS-TE .................................... 53
Figure 26 – Tunnel de protection « Next Hop » ................................................................ 56
Figure 27 – Tunnel de protection « Next Next Hop » ........................................................ 56
Figure 28 – E e ple de p ote tio FRR d’u tu el MPLS-TE .......................................... 57
Figure 29 – L2VPN Pseudo-Wire dirigé dans un tunnel MPLS-TE ...................................... 62
Figure 30 – Utilisation de tunnels TE avec des L3VPN MPLS ............................................. 63
Figure 31 – Architecture cible sites Tiers 2 / FR LHCONE .................................................. 66
Figure 32 – Liaison primaire RENATER / GEANT saturée ................................................... 68
Figure 33 – Liaison de secours RENATER/GEANT utilisée provisoirement ........................ 68
Figure 34 – Liaison Lyon1 – Genève, déjà utilisée par le LHCONE..................................... 68
Figure 35 – Liaison Grenoble – Genève inutilisée.............................................................. 68
Figure 36 – Chemins principaux LHCONE L2VPN TE .......................................................... 69
Figure 37 – Proposition de chemins secondaires LHCONE L2VPN TE ............................... 70
Figure 38 – Topologie du CPOC RENATER-5 ...................................................................... 74
Figure 39 – Protocole de rapport des tests CPOC ............................................................. 75
Figure 40 – Topologie de l’e e ple « Eta lisse e t de tu el TE à he i e pli ite » .. 77
Figure 41 – Weathe ap d’e ploitatio LHCONE ............................................................. 83
Figure 42 – Supervision du L2VPN-TE du site LHCONE de Nantes .................................... 84
89
Appendices
7.2 Références
RFC
IS-IS [RFC1195]
MPLS [RFC3031]
LDP [RFC5036]
L3VPN MPLS [RFC2547]
CR-LDP [RFC3468] en status « informationnal »
MPLS-TE [RFC2702]
IS-IS-TE [RFC5305]
OSPF-TE [RFC3630]
RSVP-TE [RFC3209]
Bibliographie
[1] https ://indico.cern.ch/getFile.py/access ?contribId=1&resId=1&materialId=slide
s&confId=151862
[2] Jean-Louis Mélin, 2001. Qualité de service sur IP, Eyrolles.
[3] J.M. Bonnin, ENST, 2003. MPLS, te h i ues de l’i g ieu , p.
Christophe Fillot, 2001. Implémentation Mpls avec Cisco.
http://www.frameip.com/mpls-cisco/
[4] J.L. Le Roux, France Télécom R&D. MPLS : applications à l’ingénierie de trafic et à
la sécurisation, te h i ues de l’i g ieu , p.
[5] Frédéric JOUNAY, Orange Labs. VPWS (Virtual Private Wire Service), Technologie
Pseudowire ou circuit virtuel, te h i ues de l’i g ieu , p.
[6] http ://tools.ietf.org/html/draft-gredler-bgp-te-01
[7] http ://www.openflow.org/
Documentation Cisco
Tunnels TE à chemin explicite et http ://www.cisco.com/en/US/docs/ios/12_0s/fea
dynamique. ture/guide/TE_1208S.pdf
Bande passante automatique des tunnels http ://www.cisco.com/en/US/docs/ios/12_2t/12_
TE. 2t4/feature/guide/ftbwadjm.pdf
Métriques TE/IGP des tunnels MPLS-TE. http ://www.cisco.com/en/US/docs/ios/12_2s/fea
ture/guide/fsmetric.pdf
Protection locale FRR des tunnels TE avec http://www.cisco.com/en/US/docs/ios/mpls/confi
BFD. guration/guide/mp_link_node_prot.pdf
Protection globale des tunnels TE. http ://www.cisco.com/en/US/docs/ios/mpls/confi
guration/guide/mp_te_path_prot.pdf
A o e des tu els TE à l’e se le des http://www.cisco.com/en/US/docs/ios/mpls/confi
outeu s de l’IGP. guration/guide/mp_te_fwd_adjacency.pdf
Tunnels TE, primaire ou de secours http ://www.cisco.com/en/US/docs/ios/12_0s/fea
automatiques. ture/guide/gsmeshgr.pdf
Diffserv Aware TE http://www.cisco.com/en/US/docs/ios/12_2s/feat
ure/guide/fsdserv3.pdf
90
8 Annexes
8.1 Etude de métrologie RENATER

Voir document ci-après.
8.2 CPOC RENATER-5 TE

Voir document ci-après.
8.3 Supervision du tunnel MPLS-TE de test sur RENATER

Les figures ci-dessous so t les sultats de l’ tape T du d ploie e t des tu els MPLS-
TE sur RENATER §5.4.
Su la p e i e, o o se e ue le tu el de test est op atio el su RENATER, et u’il
est possi le d’ i je te du t afi .
Sur la seconde, on observe les performances matérielles du routeur de tête du tunnel

TE. Le déploiement a eu lieu en semai e , les ou es d’utilisatio des essou es
at ielles du outeu so t sta les, il ’ a pas eu d’effet de o d.
91
Annexes
8.4 Base d’exploitation des tunnels TE
92
Paramètres des Tunnels MPLS Traffic Engineering
type de metrique Priorité Priorité Partage de charge Partage de charge
id tunnel chemin suivie établissement maintient Affinité Masque Annonce IGP Protection (groupe) (poids)
13122 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
8.5 Etat du réseau après le déploiement de MPLS-TE

=====================================================================================
SHOW ISIS-TE
=====================================================================================
nantes-rtr-021# sh mpls traffic-eng topology brief | i ÎGP Id:

IGP Id: 0000.0000.0001.00, MPLS-TE Id:193.51.178.10 Router Node (isis level-1)
nantes-rtr-021#show mpls traffic-eng link-management igp-neighbors

"te1-2-bordeaux-rtr-021.noc.renater.fr"
Link ID:: Te1/1
Neighbor ID: 0000.0000.0171.00 (area: isis level-1, IP: 193.51.189.73)
up, Sources: IGP
"te1-2-rennes-rtr-021.noc.renater.fr"
Link ID:: Te1/2
93
Annexes
up, Sources: IGP
"Aucun voisin ISIS-TE pour l'instant"

Link ID:: Te1/5
"te1-3-vannes-rtr-021.noc.renater.fr."
Link ID:: Te2/1
up, Sources: IGP
=====================================================================================
SHOW RSVP-Te
=====================================================================================
nantes-rtr-021#sh ip rsvp
RSVP: enabled (on 6 interface(s))
MPLS/TE signalling enabled
nantes-rtr-021#sh ip rsvp interface

interface rsvp allocated i/f max flow max sub max
Te1/1 ena 0 7500M 7500M 0
Te1/2 ena 0 7500M 7500M 0
Te1/5 ena 0 7500M 7500M 0
Te2/1 ena 0 7500M 7500M 0
Te2/2 ena 0 7500M 7500M 0
nantes-rtr-021#sh ip rsvp neighbor

Neighbor Encapsulation Time since msg rcvd/sent
193.51.189.57 Raw IP 00:00:01 00:00:06
193.51.189.73 Raw IP 00:00:10 00:00:08
=====================================================================================
CONF PW et tunnnels
=====================================================================================
pseudowire-class PW-NANTES-R021=>PARIS1-R021
encapsulation mpls
preferred-path interface Tunnel13122 disable-fallback
!
pseudowire-class PW-NANTES-R021=>LYON1-R021
encapsulation mpls
preferred-path interface Tunnel13123 disable-fallback
!
interface TenGigabitEthernet1/3.3122
description -s-- IN2P3-SUBATECH-NANTES / VPN-VPWS-TE13122-LHCONE-NANTES-RTR-021-PARIS1-
RTR-021 ----
encapsulation dot1Q 3122
no cdp enable
xconnect 193.51.178.185 3122 pw-class PW-NANTES-R021=>PARIS1-R021
mtu 9180
!
interface TenGigabitEthernet1/3.3123
description -s-- IN2P3-SUBATECH-NANTES/ VPN-VPWS-TE13123-LHCONE-NANTES-RTR-021-LYON1-RTR-
021 ----
encapsulation dot1Q 3123
no cdp enable
xconnect 193.51.178.178 3123 pw-class PW-NANTES-R021=>LYON1-R021
mtu 9180
!
interface Tunnel13122
description -TE- 13122-NANTES-RTR-021=>PARIS1-RTR-021 / LHCONE PW-3122 ----
tunnel mpls traffic-eng path-option 10 explicit name EP-NANTES-RTR-021=>PARIS1-RTR-021-
PRIMARY
!
interface Tunnel13123
description -TE- 13123-NANTES-RTR-021=>LYON1-RTR-021 / LHCONE PW-3123 ----
94
tunnel mpls traffic-eng path-option 10 explicit name EP-NANTES-RTR-021=>LYON1-RTR-021-
PRIMARY
!
=====================================================================================
SHOW PW et tunnels
=====================================================================================
nantes-rtr-021#sh int description

Interface Status Protocol Description
Te1/3.3122 up up -s-- IN2P3-SUBATECH-NANTES / VPN-
VPWS-TE13122-LHCONE-NANTES-RTR-021-PARIS1-RTR-021 ----
Te1/3.3123 up up -s-- IN2P3-SUBATECH-NANTES/ VPN-
VPWS-TE13123-LHCONE-NANTES-RTR-021-LYON1-RTR-021 ----
[...]
Tu13122 up up -TE- 13122-NANTES-RTR-021=>PARIS1-
RTR-021 / LHCONE PW-3122 ----
Tu13123 up up -TE- 13123-NANTES-RTR-021=>LYON1-
RTR-021 / LHCONE PW-3123 ----
nantes-rtr-021#sh mpls traffic-eng tunnels brief

Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 2014 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 215 seconds
P2P TUNNELS/LSPs:
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
-TE- 13122-NANTES-RTR-021=>P... 193.51.178.185 - Te1/2 up/up
-TE- 13123-NANTES-RTR-021=>L... 193.51.178.178 - Te1/1 up/up
-TE- 23123-LYON1-RTR-021=>NA... 193.51.178.183 Te1/1 - up/up
-TE- 23122-PARIS1-RTR-021=>N... 193.51.178.183 Te1/2 - up/up
Displayed 2 (of 2) heads, 0 (of 0) midpoints, 2 (of 2) tails
=====================================================================================
nantes-rtr-021#sh mpls traffic-eng tunnels tunnel 13122
Name: -TE- 13122-NANTES-RTR-021=>PARIS... (Tunnel13122) Destination: 193.51.178.185

Status:
path option 10, type explicit EP-NANTES-RTR-021=>PARIS1-RTR-021-PRIMARY (Basis for
Setup, path weight 83)
Config Parameters:
AutoRoute announce: disabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled
InLabel : -
OutLabel : TenGigabitEthernet1/2, 332
Next Hop : 193.51.189.57
RSVP Path Info:
95
Annexes
My Address: 193.51.189.58
Explicit Route: 193.51.189.57 193.51.189.54 193.51.189.46 193.51.189.49
193.51.189.38 193.51.178.185
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
Path Weight: 83 (TE)
Explicit Route: 193.51.189.57 193.51.189.54 193.51.189.46 193.51.189.49
193.51.189.38 193.51.178.185
History:
Tunnel:
Time since created: 2 days, 20 hours, 52 minutes
Time since path change: 1 days, 1 hours, 2 minutes
Current LSP: [ID: 146]
Uptime: 1 days, 1 hours, 2 minutes
Prior LSP: [ID: 124]
ID: path option unknown
Removal Trigger: path verification failed
=====================================================================================
nantes-rtr-021#sh mpls l2transport vc 3122 detail

Local interface: Te1/3.3122 up, line protocol up, Eth VLAN 3122 up
Interworking type is Ethernet
Destination address: 193.51.178.185, VC ID: 3122, VC status: up
Output interface: Tu13122, imposed label stack {332 446}
Preferred path: Tunnel13122, active
Default path: disabled
Next hop: point2point
=====================================================================================
nantes-rtr-021#sh mpls traffic-eng tunnels tunnel 13122 accounting

Tunnel13122 (Destination 193.51.178.185; Name -TE- 13122-NANTES-RTR-021=>PARIS1-RTR-021 /
LHCONE PW-3122 ----)
5 minute output rate 804391 kbits/sec, 77378 packets/sec
nantes-rtr-021#sh mpls traffic-eng tunnels tunnel 13123 accounting
Tunnel13123 (Destination 193.51.178.178; Name -TE- 13123-NANTES-RTR-021=>LYON1-RTR-021 /
LHCONE PW-3123 ----)
5 minute output rate 0 kbits/sec, 0 packets/sec
96
Annexes
Étude, o eptio et d ploie e t des te h ologies d’i g ie ie de t afi sur l’i f ast u tu e de
production MPLS de RENATER. Mémoire d’i g ieu EICNAM, Pa is 3, Nicolas GARNIER.
R su
Les expériences menées par le CERN sur le LHC sont génératrices d’u e g a de quantité de données,
qui sont distribuées à des centres de calculs via les réseaux LHCOPN et LHCONE. RENATER, qui a la
charge de ces réseaux en France, souhaite répondre à la forte demande en bande passante sans
augmenter à court terme la capacité de ses liens. Pour cela, il a été choisi d’utilise des a is es
d’i g ie ie de t afi .
L’o je tif de ette tude est de d fi i et d plo e les o e s essai es à l’orientation, vers des
chemins choisis, des connexions VPN entre les centres de calcul et le LHCONE.
MPLS-TE s’est l t e le a is e u a i e e t utilis et p opos su le a h . Ap s a oi

défini son utilisation dans l’a hite tu e i le, ous l’a o s testé et validé sur une maquette virtuelle,
puis e situatio elle hez l’ uipe e tie Cisco, avant de le mettre en production.
Ce d ploie e t a pe is d’utilise les liaisons sous-exploitées du réseau RENATER et d’ou i de

ou elles possi ilit s e te es de pla ifi atio de l’i f ast u tu e.
A st a t
Experiments by CERN on the LHC are generating a large amount of data, which are distributed to
data centers via networks LHCOPN and LHCONE. RENATER is in charge of these networks in France. In
order to meet the high demand for bandwidth without increasing, in the short term, capacity of its
links, RENATER chose to use mechanisms of traffic engineering.
The objective of this study is to define and deploy the necessary resources and protocols to guide,
into chosen paths, VPN connections between data centers and LHCONE.
MPLS-TE mechanism turned out to be unanimously used and available on the market. After having
defined its use in the target architecture, we have tested and validated it on a virtual model, then in a
real context in Cisco equipment manufacturer facilities, before putting it into production.
This project enabled to use RENATER network underused links and opened up new possibilities in
terms of infrastructure planning.
Mots clés / Keywords : Ingénierie de trafic / Traffic Engineering, MPLS-TE, IS-IS-TE, RSVP-TE.

Memoire IRSM Nicolas Garnier 2 With Cover Page v2

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Memoire IRSM Nicolas Garnier 2 With Cover Page v2

Transféré par

Droits d'auteur :

Formats disponibles

Accelerat ing t he world's research.

Memoire IRSM Nicolas Garnier 2

Related papers Download a PDF Pack of t he best relat ed papers 

Memoire de ﬁn d'ét ude

Nouveau Document Microsoft Ofﬁce Word (2)

Présenté e vue d’o te ir

Étude, o eptio et déploie e t des te h ologies d’i gé ierie

de trafi sur l’i frastru ture de production MPLS de RENATER

Soutenu le 26 février 2013

Je remercie également Patrick Donath, directeur du GIP RENATER, et Laurent Gydé,

Je remercie mes professeurs du CNAM, Jean Pierre Arnaud, responsable de la chaire

2 MPLS et Ingénierie de trafic ......................................................................................... 7

2.1 Enjeux et principes ................................................................................................ 7

2.2 MPLS-TE ................................................................................................................. 8

2.3 Signalisation des LSP-TE ...................................................................................... 18

2.4 Conclusion partielle ............................................................................................. 23

3 Étude du besoin .......................................................................................................... 24

3.1 Optimisation des liens de backup et contrôle du trafic ...................................... 24

3.2 Projet LHCONE..................................................................................................... 24

3.3 Analyse du périmètre réseau RENATER-5 ........................................................... 30

4 Choix des solutions et faisabilité ................................................................................ 36

4.1 Protocole de tests ............................................................................................... 36

4.2 Établissement de tunnels MPLS-TE ..................................................................... 39

4.3 Utilisation des tunnels MPLS-TE.......................................................................... 50

4.4 Types de trafic supportés par les tunnels MPLS-TE ............................................ 61

4.5 Gestion centralisée de MPLS-TE.......................................................................... 64

5 Généralisation et Déploiement .................................................................................. 65

5.1 Fonctionnalités MPLS-TE dans le périmètre réseau R-5 ..................................... 65

5.2 Choi de ise e œu e du p ojet LHCONE ....................................................... 66

5.3 Validatio su l’e se le du p i t e ............................................................. 71

5.4 Déploiement ........................................................................................................ 82

5.5 Exploitation ......................................................................................................... 83

6.1 Résultats du projet .............................................................................................. 84

6.3 Perspective .......................................................................................................... 87

6.4 Bilan personnel .................................................................................................... 88

7.1 Table des illustrations ......................................................................................... 89

7.2 Références ........................................................................................................... 90

8.1 Etude de métrologie RENATER............................................................................ 91

8.2 CPOC RENATER-5 TE ............................................................................................ 91

8.3 Supervision du tunnel MPLS-TE de test sur RENATER ........................................ 91

8.4 Base d’e ploitatio des tu els TE ..................................................................... 92

8.5 Etat du réseau après le déploiement de MPLS-TE .............................................. 93

Les expériences menées en Suisse et en France par le CERN sur le collisionneur de

Le T0 correspond au CERN, les T1 sont de grands centres de calculs mondiaux. En France

Figure 1 - Distribution des données LHC dans le schéma "Monarch"

RENATER, le Réseau National de télécommunications pour la Technologie

Le « LHCONE France » est o pos d’u e a hite tu e opti ue d di e et de circuits de

Ces dernières devront permettre :

Les a is es d’i g ie ie de t afi is e œu e devront également pouvoir être

Ce mémoire présente en premier lieu, d’u poi t de ue th o i ue, les enjeux et

Il aborde ensuite, du point de vue opérationnel, les besoins de RENATER en ingénierie de

Les organismes membres du GIP RENATER sont de grands organismes de recherche :

Le réseau RENATER fournit un service de connectivité IPv4 et IPv6 :

E o pl e t de l’u i ast, RENATER p opose u se i e ulti ast, disponible en mode

RENATER propose également des services applicatifs tel que :

Figure 2 - Architecture réseau de RENATER

Figure 4 - Organismes membres de RENATER

Plus d’i fo atio s peu e t t e t ou es su le site e de RENATER

L’orga isatio i ter e de RENATER est la suivante :

Figure 5 - Organigramme interne de RENATER

2.1 Enjeux et principes

Ces évolutions entraînent une augmentation considérable des volumes de trafic et de

L’i g ie ie de t afi eg oupe l’e se le des thodes et mécanismes de contrôle du

Des solutio s d’i g ie ie de t afi o t t p opos es à chaque évolution des