CONSERVATOIRE NATIONAL DES ARTS ET METIERS
PARIS
MEMOIRE
Présenté en vue d’obtenir
le DIPLOME d’INGENIEUR CNAM
SPECIALITE : Informatique
OPTION : Réseaux, Systèmes et Multimédia
Par
Nicolas GARNIER
Encadré par Xavier JEANNIN - RENATER
Étude, conception et déploiement des technologies d’ingénierie
de trafic sur l’infrastructure de production MPLS de RENATER
Soutenu le 26 février 2013
JURY
PRESIDENT
MEMBRES
Jean Pierre Arnaud
Françoise Sailhan
Nicolas Pioch
Remerciements
Je souhaite remercier tout particulièrement Xavier Jeannin, mon tuteur de stage, qui de
par son expérience, ses connaissances, sa curiosité et sa bonne humeur m’a permis de
mener à terme ce projet. Je le remercie également d’avoir partagé 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, qui m’ont transmis leurs savoir-faire.
Je remercie également Patrick Donath, directeur du GIP RENATER, et Laurent Gydé,
directeur technique, pour m’avoir permis d’intégrer RENATER et de financer ce projet,
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.
Glossaire
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 : Protocole d’échange de routes entre 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 Calcul 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 : Extension de LDP pour 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 convergence rapide en cas de panne d’un nœud ou d’un lien.
GRIF Grille de Recherche 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 : Protocole d’adressage, 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 : Emulation d’une 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’ingénierie 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 maintenance d’un réseau.
NR Nœud RENATER : Point de présence d’un ou plusieurs équipements de cœur de réseau RENATER.
NREN National Research and Education Network : Réseau National pour la Recherche et L’education.
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 numérotée de documents publiés par 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écanisme qui permet d’instancier plusieurs routeurs virtuels dans un même routeur physique.
Table des matières
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 Choix de mise en œuvre du projet LHCONE ....................................................... 66
5.3 Validation sur l’ensemble du périmètre ............................................................. 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’exploitation des tunnels TE ..................................................................... 92
8.5 Etat du réseau après le déploiement de MPLS-TE .............................................. 93
1
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
calcul d’importance moindre, T2 et T3, sont reliés au T1 le plus proche via leurs
« réseaux nationaux pour la recherche et l’éducation » (NREN) respectifs.
La distribution des données suit le schéma d’architecture « Monarch » [1], où toutes les
données demandées par les T2 et T3 sont d’abord répliquées sur le T1 de rattachement.
Ce schéma n’est pas optimal car il nécessite d’importants espaces de stockages 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, qui vise à créer un réseau d’interconnexion entre les T1, T2
et T3 des différents pays participant, afin d’améliorer les échanges et transferts 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.
Introduction
2
Le « LHCONE France » est composé d’une architecture optique 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 choisi d’utiliser des mécanismes d’ingénierie de trafic (Traffic Engineering TE).
Ces dernières devront permettre :
D’identifier le chemin utilisé par les circuits L2VPN du projet LHCONE.
De choisir un chemin à utiliser.
D’optimiser l’utilisation de l’infrastructure réseau de RENATER, et donc
de retarder de couteux investissements.
Les mécanismes d’ingénierie de trafic mis en œuvre devront également pouvoir être
réutilisés dans d’autres projets, rendant le réseau RENATER « TE compatible ».
Ce mémoire présente en premier lieu, d’un point de vue théorique, les enjeux et
principes de l’ingénierie de trafic, ainsi que les standards définis par l’industrie pour
MPLS. Nous ne décrirons pas ici le mode de fonctionnement général de MPLS, mais
seulement celui de ses extensions pour l’ingénierie de trafic.
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 faisabilité et le déploiement de
la solution retenue. Les résultats et conclusions sont enfin proposés.
Présentation de RENATER
Le Groupement d’Intérêt Public RENATER a été constitué en janvier 1993 pour fédérer
les infrastructures de télécommunication pour la recherche et l’éducation.
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
3
que le Ministère de l’Enseignement supérieur et de la Recherche et le Ministère de
l’Éducation 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é
nationale et internationale, il évolue régulièrement en fonction de l’évolution des
technologies et des capacités des infrastructures disponibles.
Le réseau RENATER, aujourd’hui dans sa version 5bis, est composé d’une infrastructure
métropolitaine à très haut débit, et de liaisons internationales à haut débit. RENATER est
aussi présent dans les départements et territoires d’Outre-Mer.
Le GIP RENATER est également maître d’ouvrage du SFINX, point d’échanges entre
opérateurs créé en 1995.
Le réseau RENATER fournit un service de connectivité IPv4 et IPv6 :
En complément de l’unicast, RENATER propose un service multicast, 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’interconnexion privée
entre 2 établissements.
Des circuits multipoints à multipoints qui permettent d’interconnecter au sein
d’un même réseau privé plusieurs établissements RENATER.
RENATER propose également des services applicatifs tel que :
Une solution anti-spam et anti-virus.
Un service de Fédération d’Identités Éducation Recherche.
Le service de mobilité réseau Eduroam.
Une plateforme de certification, pour les serveurs et les personnes.
Un service d’interconnexion d’IPBXs pour les établissements ayant déployé de la
ToIP.
Introduction
4
Figure 2 - Architecture réseau de RENATER
5
Figure 3 - Architecture de RENATER en Ile de France
Figure 4 - Organismes membres de RENATER
Plus d’informations peuvent être trouvées sur le site web de RENATER http://www.renater.fr/.
Introduction
6
L’organisation interne de RENATER est la suivante :
Figure 5 - Organigramme interne de RENATER
Ce projet s’est déroulé, entre octobre 2011 et juin 2012, au sein de l’équipe
Infrastructure pour les Services Réseaux (ISR) dont le rôle est de piloter et de planifier
les évolutions du cœur de réseau RENATER.
7
2 MPLS et Ingénierie de trafic
2.1 Enjeux et principes
Les réseaux d’opérateurs sont aujourd’hui confrontés à de nouveaux enjeux. La
croissance des débits d’accè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’ingénierie de trafic, de QoS et de
sécurisation deviennent alors nécessaires.
L’ingénierie de trafic regroupe l’ensemble des méthodes et mécanismes de contrôle du
routage permettant d’optimiser l’utilisation des ressources, tout en garantissant la QoS
(bande passante, délais...). L’objectif de ces 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 solutions d’ingénierie de trafic ont été proposées à chaque évolution des
technologies réseau. Nous allons nous concentrer ici sur celles qui s’appliquent aux
technologies IP [2] et MPLS [3], qui sont aujourd’hui utilisés dans un nombre de réseaux
d’opérateurs, dont RENATER.
Limitations du routage IP en termes d’ingénierie de trafic
Avec des réseaux IP, on dispose de peu d’outils pour effectuer à la fois du partage 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.
MPLS et Ingénierie de trafic
8
Enfin le routage explicite proposé par IPv4, IP source routing [RFC791], est inefficient
parce qu’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 mode n’a jamais vraiment été implémenté
et utilisé, il est toutefois repris dans IPv6.
2.2 MPLS-TE
2.2.1 Présentation
L’ingénierie de trafic appliquée aux réseaux MPLS est normalisée sous le nom MPLS-TE
(Multi Protocol Label Switching - Traffic Engineering) [RFC2702].
MPLS-TE permet l’établissement 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’appuyant sur 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’établissement 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.
9
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’un
graphe de réseau étendu dont les liens et les nœuds possèdent un ensemble de
paramètres d’ingénierie de trafic. Ces derniers sont détaillés dans la partie §2.2.4.
Cette topologie TE est distribuée et mise à jour périodiquement dans l’ensemble 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 routés de façon
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
maximum, les éléments (liens, nœuds) à inclure/exclure, la priorité, etc. 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 calculs relatifs à l’établissement ou la modification des
LSP-TE. On parle de mode distribué (Online) lorsque tous les calculs de LSP-TE sont
réalisés localement sur les nœuds de tête. A grande échelle, ce mode n’est pas optimal.
Les nœuds de tête risquent une surcharge et des inters blocages peuvent apparaître.
MPLS et Ingénierie de trafic
10
Il est aussi possible de déporter l’ensemble 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 aujourd’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’adaptation et de protection avancés.
2.2.3 Types d’architecture et passage à l’échelle
Nous allons détailler ici les différentes d’architectures 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 premier mode d’architecture de LSP-TE primaires est appelé TE stratégique. Il
s’organise autour d’un maillage 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 entre les routeurs de cœur de réseau
P↔P. Mais elle peut aussi être mise en œuvre entre 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
paramètre est dépendant de l’architecture physique du réseau (nombre de routeurs,
11
nombre de sauts, etc.), et est d’autant plus important pour les routeurs de cœurs
fortement maillés.
Au-delà d’un certain nombre 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 sur un nœud et
10.000 en transit, et pour Juniper, en Février 2012, 10.000 LSP-TE terminaux et 64.000
en transit. Les matériels évoluent donc dans le sens d’une utilisation de plus en plus
importante de LSP-TE.
MPLS et Ingénierie de trafic
12
Le second mode d’architecture 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
fonction du mode d’architecture TE et du nombre de nœuds présents dans le réseau.
Figure 10 - Complexité du contrôle des architectures MPLS-TE
Architecture de tunnels de protection
Les LSP-TE peuvent être utilisés en protection des liens d’une architecture standard ou
d’une architecture TE. On parle alors 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
préférable d’utiliser également des mécanismes de classification de trafic pour éviter la
congestion dans un réseau dégradé.
13
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 à mettre en œuvre 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’ensemble des paramètres TE suivants sont associés aux liens d’une 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
bande passante maximale du lien, lorsque l’on ne veut dédier qu’une partie d’un
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
création ou de la suppression d’un LSP-TE. Huit valeurs de bande passante,
appelées « pools de bande passante », sont associées à ce paramètre. 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
contrainte pour inclure ou exclure certains liens d’un chemin. Cela permet
d’autoriser ou d’interdire certains liens aux LSP-TE. On associe souvent ces
groupes administratifs à des couleurs.
MPLS et Ingénierie de trafic
14
La métrique TE vient compléter la métrique IGP. Elle permet 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’identifiant TE du routeur distant. 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 succession d’adresses de liens ou de nœuds
que le LSP-TE doit emprunter ou exclure. Il peut s’agir d’un chemin
explicite complet, ou d’un chemin explicite partiel, indiquant une suite
non continue de liens et/ou de nœuds à emprunter.
o Lorsque le chemin est explicite partiel ou qu’il n’est pas spécifié, on parle
de chemin dynamique. Le chemin dynamique est alors calculé, soit par le
routeur de tête soit par un serveur central, à l’aide d’un algorithme de
calcul de chemin contraint (Constraint Shortest Path First, CSPF). Le calcul
des chemins dynamique par les routeurs de tête pose toutefois un
problème d’optimisation de l’usage de la topologie TE. En effet, chaque
routeur de tête ne connait l’état que de ses propres LSP-TE. Des
phénomènes d’inter blocages peuvent donc apparaître.
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 priorités de préemption d’établissement et de maintien des
tunnels.
15
Le calcul des chemins peut être déporté des routeurs d’entrée vers un
serveur central. L’optimisation de l’ensemble 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’un LSP-TE à
résister à la préemption.
• La priorité d’établissement (setup, ps) correspond à la capacité d’un LSP-
TE à préempter un autre LSP-TE.
Ces deux paramètres créent une situation d’hystérésis et permettent donc
d’éviter les phénomènes de changement d’état intempestifs.
La bande passante à réserver. Elle peut être absolue ou s’adapter
dynamiquement à la charge réelle du LSP-TE. Dans le second cas, un phénomène
de retard d’adaptation peut apparaître si les intervalles de mesure ne sont pas
adaptés au type du trafic. Des seuils d’annonce de l’utilisation de la bande
passante sont également paramétrables, pour évaluer une charge croissante ou
décroissante des LSP-TE.
Le mode d’annonce des LSP-TE dans les tables de routage. Trois modes existent :
o Aucune annonce : le LSP-TE n’est pas annoncé dans la table de routage 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.
MPLS et Ingénierie de trafic
16
o « IGP Shortcut Forwarding Adjacancy » : le LSP-TE est annoncé comme
une interface physique à tous les routeurs de l’IGP. Dans ce mode, 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
court chemin contraint. Il s’agit de la métrique TE ou de la métrique 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éfaillances d’un LSP-TE, il
est possible de paramétrer pour chaque LSP-TE des chemins de secours
explicites. Ces chemins de secours peuvent prendre la forme d’un LSP-TE global
préétabli dans la topologie TE, ou de LSP-TE de protection locale de lien ou de
nœud (Fast Reroute). Si aucun LSP-TE de secours n’est configuré, le trafic suivra
le chemin de l’IGP.
De la qualité de service : MPLS-TE peut être considéré comme un mécanisme de
signalisation de chemin contraint. S’il ne réserve pas physiquement 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 service d’un ré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 »).
17
Algorithme CSPF, réalisé en 3 phases :
Dans l’exemple ci-dessous, le routeur P1 est à l’origine du LSP-TE tel que :
LSP-TE 1 Origine : P1 Destination : P6 BP nécessaire : 8M Affinité : Liens noirs
P1
P6
10M
50
10M
50
20M
50
10M
50
20M
50
10M
100
P1
P6
10M
50
10M
50
20M
50
5M
50
10M
50
20M
50
10M
50
10M
100
P1
P6
10M
50
10M
50
20M
50
10M
50
20M
50
10M
100
10M : Bande passante TE disponible
100 : Métrique TE
Phase 1
Phase 2
Phase 3
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.
MPLS et Ingénierie de trafic
18
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’ajouter au protocole de distribution de labels LDP des fonctions d’ingénierie de trafic.
Malgré certains avantages, comme l’utilisation actuelle de LDP dans les réseaux MPLS, et
une bonne résistance au passage à l’échelle, l’industrie 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 aujourd’hui en « status informationnal », ce qui
signifie qu’elle ne devrait plus être utilisée et implémentée dans 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 destiné à l’origine 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 effectue un contrôle d’admission local, pour s’assurer que les contraintes sont
bien respectées (bande passante, groupes administratifs). Ce contrôle
d’admission local est nécessaire pour prendre en compte les cas d’erreur 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.
19
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 constitués d’un en-tête RSVP commun suivi d’un ensemble d’objets 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’acquittement 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 : Confirme l’établissement d’un tunnel dans le sens descendant.
Srefresh : Rafraîchit un ensemble de sessions RSVP-TE.
Hello : Maintient l’adjacence entre deux voisins RSVP-TE, permet de détecter la
perte d’un voisin. 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’effectue sans perte de trafic, grâce à la procédure de
création du nouveau LSP-TE, bascule du trafic puis suppression de l’ancien LSP-TE
MPLS et Ingénierie de trafic
20
(« 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’établissement d’un LSP-TE par RSVP-TE est effectué en deux temps. Tout d’abord, 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 route explicite du LSP, codée dans l’objet ERO (Explicite 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’admission local pour vérifier que le prochain lien valide les contraintes TE du LSP-TE.
En réponse, le routeur de destination renvoie un message Resv de proche en proche
vers l’origine du tunnel. 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’adresse de la source et de la destination 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.
21
La figure ci-dessous détaille les étapes du processus d’établissement d’un LSP-TE avec
RSVP-TE, en donnant l’exemple d’une réservation le long du chemin
R1R2R3R5R6R7.
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équence d’établissement est alors annulée.
(2) R2 envoie un Path message à R3. R3 fait les mêmes vérifications qu’en (1).
(3) R3 envoie un Path message à R5. Mêmes vérifications.
(4) R5 envoie un Path message à R6. Mêmes vérifications.
(5) R6 envoie un Path message à R7. 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.
(8) R5 envoie un Resv message à R3 et indique un incoming label=10921.
(9) R3 envoie un Resv message à R2 et indique un incoming label=21.
(10) R2 envoie un Resv message à R1 et indique un incoming label=18.
L’établissement du LSP-TE est alors finalisé.
MPLS et Ingénierie de trafic
22
Maintien des LSP-TE, états RSVP-TE
À chaque LSP-TE signalé sur un nœud est associé un état RSVP-TE. Celui-ci regroupe
l’ensemble des informations du LSP-TE à savoir :
Adresse source et destination.
Numéros de tunnel-TE et de LSP-TE.
Bande passante.
Nœud précédent, nœud suivant.
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 n’est pas rafraîchi au-delà d’une période d’expiration d’état, il
expire et le LSP est détruit. Il s’agit d’une propriété de RSVP que 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 suppression des états en cas d’isolement d’un
nœ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’expiration L. Par défaut, on a L = 4 R, c’est-à-dire qu’un état expire sur 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 problèmes de passage à l’échelle. Un mécanisme de réduction des
rafraîchissements (Refresh Reduction, RR) a alors été défini dans la [RFC2961]. Ce
23
mécanisme consiste à transmettre des messages Srefresh contenant la liste des états à
rafraichir.
Cette procédure d’acquittement et de réduction des rafraîchissements permet de
diminuer considérablement la quantité d’informations RSVP-TE à traiter pour le
maintien des états tout en conservant les propriétés soft state de RSVP.
Suppression d’un LSP
La suppression explicite d’un 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 suppression d’un 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 suppression d’un LSP peut également être implicite, en cas
d’expiration 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’ingénierie de trafic pour MPLS, MPLS-TE.
MPLS-TE est un ensemble d’outils et de mécanismes, qui viennent étendre MPLS. Il
fonctionne au-dessus et grâce à MPLS, sans en perturber le fonctionnement normal.
Deux modes d’architectures pour MPLS-TE existent. Une utilisation globale, où
uniquement MPLS-TE est utilisé pour l’acheminement du trafic. Cette approche est
puissante mais complexe. Une utilisation ponctuelle, où l’on peut bénéficier des
avantages de MPLS-TE sans avoir à modifier toute l’architecture réseau.
Enfin, la seule méthode de signalisation disponible pour MPLS-TE est aujourd’hui RSVP-
TE, qui est le choix des principaux équipementiers réseaux (Cisco, Juniper, etc.). CR-LDP
est devenue obsolète.
Étude du besoin
24
3 Étude du besoin
Dans cette partie, nous allons tout d’abord présenter les besoins fonctionnels en
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 compatibles avec l’existant, et définir un plan de mise en
œuvre.
3.1 Optimisation des liens de backup et contrôle du trafic
L’architecture réseau de RENATER est fiabilisée par la présence de nombreux liens de
secours. A part quelque cas de point de présence RENATER pendulaire, chaque nœ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’utiliser ces liens de secours pour quelques projets scientifiques compatibles avec un
partage ponctuel de la bande passante.
Pour réaliser cet usage, il faut être capable de s’affranchir du routage interne (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
25
phase complémentaire au LHCOPN. C’est un réseau d’interconnexion qui vise à
distribuer les échanges de données avec et entre les T1, T2 et T3.
Figure 13 – LHCOPN, échanges hiérarchiques des données avec les T2.
Figure 14 – LHCONE, échanges distribués des données entre les T2.
Tier 3
Tier 3
Tier 3
Tier 3
Tier 3
Étude du besoin
26
La partie française du réseau LHCONE, adopte deux stratégies d’architecture pour le
raccordement des sites :
Un réseau dédié, qui s’appuie sur l’architecture optique de RENATER, et qui est
indépendant de sa politique de routage (VLANs et longueurs d’ondes optiques
sont réservées dans l’architecture 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’appuieront sur l’architecture physique et logique du ré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».
27
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) afin d’être redirigées dans le ré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’1Gbit/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» n’est pas négligeable.
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. Dans la plupart des cas, on peut parler d’une liaison 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 peuvent êtres routés via l’une ou
l’autre des deux liaisons.
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).
Étude du besoin
28
La liaison entre Lyon1 - Genève est l’accès nominal pour l’interconnexion vers le
« LHCONE international » de Genève. Cette liaison est déjà chargée par le trafic
de production habituel de RENATER.
L’utilisation de mécanismes d’ingénierie de trafic pour orienter les liaisons L2VPN-
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 service permettrait de garantir qu’en cas de congestion de
l’accès secours (cas de panne de l’accès primaire par exemple), le trafic plus
prioritaire pourrait être écoulé sans dégradation de performance.
Dans l’exemple ci-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 besoins fonctionnels en termes d’ingénierie de trafic sont :
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.
29
Convergence rapide, réoptimisation des tunnels TE en cas d’une coupure 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 étant un pilote de l’utilisation d’ingénierie de trafic sur RENATER, les choix
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.
Étude du besoin
30
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 composé d’une soixantaine de nœuds (NR), et
d’environs 75 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
31
Les routeurs de type CRS-1 sont les organes de cœur du réseau, leurs capacité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
type de routeur ne sera donc pas pris en compte dans l’étude.
Aussi, le Réseau Académique Parisien (RAP), qui est en cours d’intégration dans
RENATER, est composé de routeurs JUNIPER. L’étude de la compatibilité de ces
équipements avec MPLS-TE sera effectuée dans l’étude de l’intégration de RAP dans
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éments principaux de l’architecture et du routage 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 un protocole à état des liens. Les
tables de routage Ipv4 et Ipv6 sont séparées (mode ISIS multi-topology, dit
« dual-stack »).
Étude du besoin
32
Le protocole de détection de coupure réseau « Bidirectionnal Forwarding
Detection » (BFD) est présent sur toutes les interfaces de cœur de ré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, point d’échange IX…). 2 route-reflectors (RR) sont déployés sur
Paris1 et Lyon1, simplifiant la configuration BGP en évitant d’avoir à configurer
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 Ipv6 n’utilisent pas MPLS.
MPLS fonctionne en mode « frame » : Un en-tête est ajouté devant le paquet IP.
MPLS est activé sur toutes les interfaces du cœur de réseau, pas sur les interfaces
vers les sites utilisateurs de RENATER.
L’allocation de label ne s’applique que pour les routes internes apprises par 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. En cas de convergence de l’IGP, celle de LDP
est immédiate.
33
3.3.3 Services de circuits dans RENATER-5
Les services VPN sont aussi déployés au-dessus de ce cœur MPLS.
RENATER propose des solutions d’interconnexion 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 à
partir du cœur 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
propagées via BGP aux routeurs d’extrémité.
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
Dans le cas d’un L2VPN VLAN-à-VLAN, il est possible d’activer plusieurs services sur le
même port. Dans celui L2VPN port-à-port, il est nécessaire qu’une interface physique
soit intégralement dédiée sur ses deux extrémités. Il faudra alors disposer d’une autre
interface physique pour les autres types de services.
Étude du besoin
34
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 cœur de ré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).
CE 1 CE 2
Nuage MPLS
PE 1 PE 2
Mapping VLAN ID vers VC ID Mapping VC ID vers VLAN ID
Pseudo Wire
Vlan 2000 VC 222 Vlan 2000VC 222
Figure 20 – L2VPN-PW dans une architecture MPLS
Dans le cas d’un L2VPN 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érentes encapsulations d’une trame Ethernet dans
un L2VPN-PW. Dans le premier cas, le VLAN de transport (Tag Service Delimiting) n’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
35
L3VPN MPLS
La solution L3VPN MPLS présente sur RENATER-5 repose sur l’exploitation de l’en-tête
MPLS, où l’on 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
traditionnel de BGP, il est possible d’utiliser ou non un route reflector (RR). C’est le cas
dans l’architecture de RENATER.
Dans l’exemple ci-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
routeurs d’extrémité (PE) appartenant à la VRF.
Nuage MPLS
CE 1CE 3
PE2
PE 1 PE 3
CE 2
Peering
iBGP
Peering
eBGP
RR
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
routeur d’interconnexion. Seul l’usage des services Ipv4 unicast est permis dans un
L3VPN sur RENATER.
Choix des solutions et faisabilité
36
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
Afin de valider la configuration et l’usage des paramètres d’une topologie et des tunnels
MPLS-TE, nous avions besoin de procéder à une phase de maquettage. Pour cela,
RENATER dispose habituellement d’un « banc de test » composé de 3 routeurs. J’ai
plutôt proposé d’utiliser une maquette de réseau virtuelle via le logiciel de simulation
Dynamips/GNS3.
Ce logiciel est capable d’émuler des plateformes de routeurs Cisco 7200 et toutes leurs
fonctions logicielles. Nous pouvons y injecter le système IOS de notre choix, en
l’occurrence l’IOS Version 12.2(33) SRE3.
L’intérêt d’utiliser un logiciel de simulation est de pouvoir, à moindre frais et sans
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
professionnelles, ou j’ai pu notamment simuler et préparer des configurations de
commutateurs et de routeurs, et par l’utilisation pédagogique qui en est faite au CNAM.
Cette maquette est constituée de 8 routeurs de cœurs (P1 à P8, P6 noté RR) et de deux
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. Par souci de simplicité, elles sont égales dans les deux sens d’un lien.
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 échanges dans le cœur de réseau sont effectués par MPLS.
Les routeurs clients (CE) annoncent leurs préfixes IP au cœur de réseau via BGP4.
37
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.
Quantification de l’influence des fonctionnalités MPLS-TE sur 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 simulation Dynamips/GNS3.
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 commandes sont valables pour le système d’exploitation IOS Cisco.
Elles sont à transcrire pour les équipements qui fonctionnent avec IOSXR (Cisco CRS-1 et
12000).
1 Cf. références en §7.2
Choix des solutions et faisabilité
38
.47.0
10.1.0.1
10.5.0.1
10.4.0.1
10.3.0.1
10.2.0.1 10.6.0.1
10.7.0.1 10.8.0.1
Métriques IGP
Sous-réseau
d’un lien en
10.0.x.x
Adresse de
loopback
.78.0
.57.0 .58.0
.15.0 .35.0
.17.0
.12.0
.26.0
.36.0
.13.0
100
.38.0
.48.0
100
100
.23.0
Figure 23 – Architecture de test mise en place via Dynamips/GNS3
39
4.2 Établissement de tunnels MPLS-TE
Dans cette section, nous verrons les différentes phases liées à l’établissement de tunnels
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.
Établissement d’un tunnel TE à chemin explicite.
Établissement d’un tunnel TE à chemin dynamique.
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 première étape dans la réalisation d’une architecture 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.
Exemple de configuration d’une interface :
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] : Bande passante en kbps de l’interface. Représente
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]
kbps ou pourcentage de la bande passante de l’interface.
B : Bande passante réservable par flux dans des tunnels MPLS-TE. [1-
Choix des solutions et faisabilité
40
10000000] kbps
o attribute-flag (32 bit, en hexadécimal) : groupe administratif du lien. Il sera
comparé au champ affinity des tunnels lors de la phase d’établissement 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
[…]
On observe les paramètres TE qui s’échangent via IS-IS-TE dans les TEDB. Le
rafraichissement de ces informations est initié périodiquement par IS-IS, mais également
à chaque modification, ou réservation d’une ressource.
Les tunnels TE seront mis en concurrence pour l’obtention et la réservation des
ressources TE. En cas de manque de ressources, les tunnels ne pourront s’établir
directement, les mécanismes de préemptions (cf §4.2.5) seront alors mis en œuvre.
41
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.
.47.0
10.1.0.1
10.5.0.1
10.4.0.1
10.3.0.1
10.2.0.1 10.6.0.1
10.7.0.1 10.8.0.1
Sous-réseau
d’un lien en
10.0.x.x
Adresse de
loopback
.78.0
.57.0 .58.0
.15.0 .35.0
.17.0
.12.0
.26.0
.36.0
.13.0
Tunnel MPLS TE
bidirectionnel
P4-P2
Figure 24 – Tunnel MPLS-TE à chemin explicite
Nous créons tout d’abord 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
next-address 10.3.0.1
exclude-address 10.5.0.1
Un tunnel MPLS-TE est vu comme une interface par le routeur.
Configuration d’un tunnel 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
Choix des solutions et faisabilité
42
o tunnel destination : adresse de Loopback du routeur cible de sortie du tunnel.
o tunnel mpls traffic-eng priority : Priorités d’établissement et de maintien du
tunnel.
o tunnel mpls traffic-eng bandwidth : Bande passante TE requise pour
l’établissement du tunnel.
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 : signale l’état administratif et opérationnel du tunnel TE.
o Path option : Chemin sélectionné pour le tunnel et son poids.
o Config Parameters : paramètres généraux du tunnel.
43
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
dans la topologie TE (le tunnel n’est pas forcément éligible au meilleur chemin).
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 chemin de plus forte priorité ne peut pas s’établir. On parle alors
de tunnel secondaire non établis.
Tunnel mpls traffic-eng path-option 2[+] explicit name «autre chemin explicite»
Enfin, cette commande nous permet de vérifier manuellement les capacités d’accueil de
la topologie TE avant l’établissement d’un tunnel TE à chemin explicite :
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 1: 10.0.48.2 : affinity 00000000, bandwidth 1000 (kbps)
Hop 2: 10.0.38.2 : affinity 00000000, bandwidth 1000 (kbps)
Hop 3: 10.0.38.1 : affinity 00000000, bandwidth 1000 (kbps)
Hop 4: 10.0.23.2 : affinity 00000000, bandwidth 1000 (kbps)
Hop 5: 10.0.23.1 : affinity 00000000, bandwidth 1000 (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.
Choix des solutions et faisabilité
44
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).
Configuration d’un tunnel à chemin dynamique :
interface Tunnel1
ip unnumbered Loopback1
load-interval 30
tunnel destination 10.2.0.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng bandwidth 100
tunnel mpls traffic-eng path-option 1 dynamic
tunnel mpls traffic-eng path-selection metric te
o path-option 1 dynamic : Le chemin utilise l’algorithme CSPF pour s’établir.
o path-selection metric te : type de métrique prise en compte dans le calcul CSPF.
Statut d’établissement du tunnel à chemin dynamique :
P4#sh mpls traffic-eng tunnels tunnel 2
Name: P4_t2 (Tunnel2) Destination: 10.2.0.1
Status: Admin: up Oper: up Path: valid Signalling:
connected
path option 1, type dynamic (Basis for Setup, path weight 8)
Config Parameters:
Bandwidth: 100 kbps (Global) Priority: 5 4 Affinity: 0x0/0xFFFF
Metric Type: TE (interface)
AutoRoute: disabled LockDown: disabled Loadshare: 100 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: dynamic path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
[…]
RSVP Signalling Info:
Src 10.4.0.1, Dst 10.2.0.1, Tun_Id 2, Tun_Instance 1
RSVP Path Info:
My Address: 10.0.48.1
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
45
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 0: 10.0.48.1 : affinity 00000000, bandwidth 4800 (kbps)
Hop 1: 10.0.48.2 : affinity 00000000, bandwidth 1000 (kbps)
Hop 2: 10.0.58.2 : affinity 00000000, bandwidth 900 (kbps)
Hop 3: 10.0.58.1 : affinity 00000000, bandwidth 1000 (kbps)
Hop 4: 10.0.15.2 : affinity 00000000, bandwidth 800 (kbps)
Hop 5: 10.0.15.1 : affinity 00000000, bandwidth 1000 (kbps)
Hop 6: 10.0.12.1 : affinity 00000000, bandwidth 800 (kbps)
Hop 7: 10.0.12.2 : affinity 00000000, bandwidth 1000 (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 comparaison d’affinité entre les tunnels et la topologie TE permet de restreindre 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 : affinité de l’interface dans la topologie TE, en hexadécimal.
o Affinity [valeur] [masque] : lors du calcul CSPF, l’affinité du tunnel est comparé à
l’attribute-flags des interfaces. Si les deux valeurs correspondent, l’interface est
éligible à la suite de l’algorithme CSPF. Le masque d’affinité se comporte de la
sorte : un bit à 1 dans le masque signifie « ne pas tenir compte de ce bit de
l’attribute-flag pour la comparaison avec l’affinité du tunnel ».
Choix des solutions et faisabilité
46
Le temps nécessaire à la signalisation et l’établissement des tunnels dans les modes
explicites et dynamiques n’a pu être quantifié sur la maquette. Les documentations
annoncent un temps de l’ordre de 100ms
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 mode convient lorsque l’on a la connaissance de la matrice des flux du réseau, et que
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 son type d’allocation (global|sub-pool).
Dans le cas où la bande passante disponible dans la topologie TE est inférieure à celle
demandée par le tunnel, celui-ci ne peut s’établir, l’erreur « 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 permet au tunnel d’adapter sa contrainte de bande passante 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
47
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
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: 0 kbps (Global) Priority: 6 5 Affinity: 0x0/0xFFFF
Metric Type: TE (interface)
AutoRoute: disabled LockDown: disabled Loadshare: 979 bw-based
auto-bw: (300/248) 0 Bandwidth Requested: 979
Samples Missed 0: Samples Collected 0
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 20
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=979 kbits, burst=1000 bytes, peak rate=979 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=979 kbits, burst=1000 bytes, peak rate=979 kbits
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
Choix des solutions et faisabilité
48
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
ip unnumbered Loopback1
tunnel destination 10.2.0.1
tunnel mpls traffic-eng bandwidth 800
tunnel mpls traffic-eng priority 6 5
interface Tunnel2
ip unnumbered Loopback1
tunnel destination 10.2.0.1
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng priority 5 5
interface Tunnel 3
ip unnumbered Loopback1
tunnel destination 10.2.0.1
tunnel mpls traffic-eng bandwidth 200
tunnel mpls traffic-eng priority 7 7
Dans ce cas, la bande passante disponible dans la topologie TE n’est pas toujours
suffisante, les tunnels qui peuvent s’établir sur les liens TE seront alors ceux qui ont la
plus forte priorité d’établissement. Aussi, la priorité de maintien permet à un tunnel déjà
établi de résister à une préemption.
L’ordre d’établissement des tunnels TE et leurs paramètres de préemption ont donc leur
importance, des situations d’inter blocage 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’un message de nouvelle adjacence IGP.
o timers [frequence] : Fréquence de réoptimisation périodique
49
o timers [delai] : Délai avant la première réoptimisation suite à l’établissement du
tunnel MPLS-TE.
Interface tunnel 1
tunnel mpls traffic-eng path-option 1 dynamic lockdown
L’option lockdown permet d’empêcher la réoptimisation de ce tunnel à chemin
dynamique.
La réoptimisation périodique permet une meilleure utilisation de l’ensemble de la
topologie TE, de prendre en compte les éventuels changements de métrique IGP, TE, de
bande passante TE disponible, etc.
Toutefois, le calcul d’établissement CSPF des tunnels TE est local à chaque routeur, et
dans le cas d’une topologie TE chargée en tunnels TE d’origine 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’utilisation de la bande passante 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écroissant des seuils d’utilisation de la bande passante. Par défaut, les seuils suivant
sont présent sur toutes les interfaces d’une 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 contraintes physiques du réseau et de s’adapter aux types de flux présents dans les
tunnels MPLS-TE (données, VOIP…).
Choix des solutions et faisabilité
50
Exemple de configuration :
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 types 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 peuvent être annoncés dans le routage interne d’un réseau de
différentes manières. Le choix du type d’annonce va influer sur la manière de faire
circuler du trafic dans ces tunnels (voir §2.2.5).
Aucune annonce dans l’IGP
C’est le comportement par défaut des tunnels MPLS-TE. Ceux-ci ne sont pas annoncés
dans l’IGP, il faudra alors spécifier des routes statiques via le tunnel pour des une
adresse ou un préfixe IP.
Exemple de configuration :
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
51
Mode d’annonce du tunnel « 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é.
Configuration d’un tunnel 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.15.0/24 [115/30] via 10.0.47.2, GigabitEthernet1/0
I L1 10.0.17.0/24 [115/20] 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’annonce du tunnel « IGP Shortcut Forwarding Adjacancy»
Le dernier mode d’annonce des tunnels 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 routeurs en sont donc informé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
Choix des solutions et faisabilité
52
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
I L1 10.0.17.0/24 [115/20] via 10.0.47.2, GigabitEthernet1/0
P7#sh ip route
I L1 10.2.0.1/32 [115/18] via 10.0.47.1, GigabitEthernet4/0
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 :
Relance de la procédure d’établissement (§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 secours autour d’une coupure de lien ou de nœ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.
53
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
bidirectionnel
P4-P2
Tunnel MPLS TE
Protection globale
bidirectionnel
P4-P2
Figure 25 – Exemple de protection globale d’un tunnel MPLS-TE
Sur le routeur de tête du tunnel MPLS-TE à protéger, il faut d’abord configurer un
chemin explicite pour le tunnel de protection :
ip explicit-path name Tunnel_1_sec enable
next-address 10.7.0.1
next-address 10.1.0.1
Choix des solutions et faisabilité
54
Configuration d’un tunnel de protection globale pour un tunnel 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 :
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)
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 nombre de liens et de nœuds communs entre le chemin nominal et le chemin
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 visualiser l’état du tunnel de protection globale. Ces
derniers héritent des paramètres tunnel primaire (métrique TE ou IGP, type d’annonce
IGP, affinité).
55
Lors de la phase d’établissement, le tunnel de secours ne s’établi qu’après le primaire.
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’une bascule sur le tunnel de protection globale sont les
suivants :
Erreur d’établissement du tunnel MPLS-TE primaire (via signalisation RSVP-TE).
Notification de perte d’adjacence via 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 :
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 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#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 79
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 inverse, où l’on rétablit le trafic sur le tunnel principal :
Sending 100, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Choix des solutions et faisabilité
56
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 4/37/172 ms
Aucune perte n’est observée dans ce cas.
En cas de défaut du tunnel MPLS-TE, le mode de protection globale fournit une
convergence plus rapide qu’un second chemin principal explicite ou dynamique.
Le temps de convergence est toutefois dépendant du nombre de sauts effectués par le
tunnel et des délais de propagation jusqu’au routeur 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.
Protection locale d’un lien ou d’un nœud « Fast Reroute » (FRR) :
Le mode de protection « Fast Reroute » permet d’améliorer les lacunes des modes
précédents en termes de temps de convergence.
La protection locale d’un lien ou d’un nœud s’effectue sur le nœud en amont, 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 »
57
Dans notre configuration les deux types de tunnels de Fast-Reroute sont testés :
Un tunnel NHOP qui protège le tunnel principal d’une défaillance du lien P8-P3.
Un tunnel NNHOP qui protège le tunnel principal d’une défaillance du nœud P3.
Ces tunnels sont unidirectionnels, ils ne protègent le tunnel principal que dans le sens
P4-P2.
10.5.0.1
Tunnel MPLS TE
bidirectionnel
P4-P2
Tunnel
Fast-Reroute
NHOP
P8-P3
Tunnel
Fast-Reroute
NNHOP
P8-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
Choix des solutions et faisabilité
58
(2) Création du tunnel de protection de lien (NHOP) ou de nœud (NNHOP) sur le routeur P8 en amont du lien / nœud à protéger :
interface Tunnel 100
ip unnumbered Loopback1
tunnel destination 10.3.0.1 | 10.2.0.1
tunnel mode mpls traffic-eng
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écifier l’adresse du lien ou nœud à protéger.
o exclude-address 10.0.38.2 : Pour une protection de lien, spécifier
l’adresse ip du lien à exclure (adresse de l’interface du routeur).
o exclude-address 10.3.0.1 : Pour une protection de nœud, spécifier la
loopback du nœud à protéger.
(4) Association du tunnel de FRR avec l’interface à protéger (interface d’accès au lien ou nœud à protéger) : 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écifie la bande passante TE du tunnel de FRR et son type d’allocation.
(6) Création d’une session RSVP Hello entre le lien ou nœud à protéger et le nœ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
(protection du nœud) puis sur les interfaces à protéger (protection du lien).
59
Détails d’une session « 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 qui transitent par les liens/nœuds proté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#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 14
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.
En situation de défaut du lien ou nœud protégé, la session RSVP Hello n’est plus active,
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
Choix des solutions et faisabilité
60
Du point de vue du routeur de tête du tunnel P4, l’information du FRR le long du chemin
est transmise sans que cela n’impacte l’état du 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 5)
Change in required resources detected: reroute pending
L’information de reroutage est transmise au routeur de tête du tunnel TE. Une
réoptimisation pourra être lancée pour trouver un meilleur chemin.
La création des tunnels de protection FRR d’un lien ou d’un nœud peut également être
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 : temps avant qu’un tunnel FRR
automatique non utilisé soit supprimé.
o auto-tunnel backup config affinity affinity-value [mask mask-value] : précise
l’affinité des tunnels FRR automatiques.
Dans la maquette de test, nous n’avons pas pu voir de différence 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. Notamment parce qu’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.
61
4.3.3 Partage de charge entre plusieurs tunnels
Un partage de charge entre plusieurs tunnels (primaire ou de FRR) peut s’établir 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’après les spécifications 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’utilisateur final, sera 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 statique d’une adresse ou un préfixe via un tunnel MPLS-TE.
Déclarer le tunnel dans l’IGP (mode IGP shortcut autoroute ou IGP shortcut
Forwarding adjancy).
L2VPN-PW
Les L2VPN-PW utilisent la table de commutation MPLS pour acheminer le trafic. Ce
dernier suit donc le routage défini par l’IGP dans le réseau.
Pour diriger explicitement le trafic d’un L2VPN-PW, il est possible d’associer le L2VPN-
PW et son VC à un tunnel MPLS-TE. Pour cela on utilise la fonction « Preferred Path ».
Choix des solutions et faisabilité
62
CE 1 CE 2
Nuage MPLS-TE
Mapping VLAN ID vers VC ID Mapping VC ID vers VLAN ID
P
P
PE 1
Vlan 2000 VC 222
PE 2
Vlan 2000VC 222
Tunnel
TE
Pseudo-Wire
Dirigé dans
tunnel TE
Figure 29 – L2VPN Pseudo-Wire dirigé dans un tunnel MPLS-TE
Exemple de configuration :
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’option *disable-
fallback] permet de désactiver le L2VPN si le tunnel n’est pas opérationnel.
Détail d’une connexion L2VPN :
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 :
*Ready+ si IGP utilisé lorsque le tunnel n’est pas opérationnel.
*disable+ si l’option *disable-fallback] est utilisée.
63
L3VPN
Les L3VPN MPLS utilisent la table de commutation MPLS pour acheminer le trafic d’un
PE à l’autre. Dans le mode par défaut, le trafic suivra donc le routage défini par l’IGP. On
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 méthode peut s’appliquer à une route entre deux PE (Un seul Tunnel TE uni ou
bidirectionnel), comme à l’ensemble du plan de routage spécifique à la VRF (Création
d’un maillage complet entre les PE concernés par la VRF, N∙(N-1)/2 connexions à créer et
maintenir).
CE 1CE 3
PE2
PE 1 PE 3
CE 2
Peering
eBGP
RR
Tunnels
TE
Figure 30 – Utilisation de tunnels TE avec des L3VPN MPLS
La procédure est de configuration est :
1. Créations une loopback L (non annoncée dans 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.
Choix des solutions et faisabilité
64
Exemple de configuration :
Sur PE1 Sur PE3
1 interface Loopback2
ip address 10.2.1.1 255.255.255.255
interface Loopback2
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
tunnel 1
ip route 10.2.1.1 255.255.255.255
tunnel 1
Résultat dans les tables de routage :
S 10.4.1.1/32 is directly connected,
Tunnel1
S 10.2.1.1/32 is directly connected,
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, son utilisation comme un niveau d’infrastructure à part entière nécessitera
d’utiliser un outil de gestion centralisé, et ce pour deux raisons :
Humaine, car la gestion manuelle d’un grand nombre de tunnels MPLS-TE
concurrents devient quasi-impossible à partir d’un certain point.
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 nécessitent pas le déploiement d’une architecture
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 difficile de s’appuyer sur un outil de gestion automatique sans craindre
de bug.
65
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.
Un seul routeur 6509-E (Orsay-swi-001), en version 12.2(18) SXF12a, n’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’inverse, les incompatibilités sont :
Le trafic Ipv6 n’est pas supporté. La cohabitation avec MPLS-TE nécessite une
séparation des tables de routage Ipv6 dans l’IGP.
Le trafic multicast n’est pas support mais n’est normalement pas impacté.
Chassis IOS Ext
ensi
on
IS-I
S TE
MP
LS-T
raff
ic E
ngin
eeri
ng
Aut
o b
and
wid
th IG
P /
TE m
etri
c F
ast
Rer
ou
te (
FRR
) P
ath
Pro
tect
ion
Aut
oro
ute
An
no
unce
For
war
din
g A
dja
cen
cyP
arta
ge d
e ch
arge
Dif
f-Se
rv-A
war
e (D
S-TE
)
Co
S Tu
nn
el S
elec
tio
n L
2VP
N :
Tun
nel S
elec
tion
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
Généralisation et Déploiement
66
5.2 Choix de mise en œuvre du projet LHCONE
L’architecture cible du projet « 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
Afin de respecter les contraintes temporelles du projet, j’ai proposé de n’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.
67
En prévision d’autres utilisations 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
deploiement à Genève (mise en service prévue pour l’été 2012).
Malgré l’utilisation de MPLS-TE, certaines interconnexion sont inévitables et déjà
saturées. Elles se comportent comme des goulets d’étranglement. C’est le cas 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
projet de modification de l’infrastrucutre RENATER.
Jusqu’à juillet 2012, la connexion avec le réseau GEANT, pour le trafic IP standard, se
situait sur le NR de Paris1. Cette liaison était saturée, et RENATER et GEANT ont été
forcés d’utiliser provisoirement la liaison de secours depuis Paris2, ce qui n’est pas
souhaitable. (cf figures 32 et 33).
Une étude d’origine et destination des flux à demontré qu’une partie importante 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).
Généralisation et Déploiement
68
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
69
Les propositions de chemins principaux et secondaires sont les suivantes :
Figure 36 – Chemins principaux LHCONE L2VPN TE
Généralisation et Déploiement
70
Figure 37 – Proposition de chemins secondaires LHCONE L2VPN TE
71
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 simulation. Toutefois, les règles d’ingénierie et de déploiement sur
RENATER nous imposent de procéder à une phase de validation en environnement réel,
afin de s’assurer de la non perturbation du déploiement sur les services en production.
Pour ce faire, nous avons tout d’abord utilisé le banc de test disponible dans les locaux
parisiens BT. Hors, ce banc de tests est réduit à trois équipements (Cisco 7600, 12000 et
7200) et nous n’avons pas pu valider nos tests sur les plateformes 6500 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
Cisco), où nous avons bénéficié de tous les types d’équipements réseaux présents sur
RENATER. Ce CPOC, d’une durée d’une semaine, s’est déroulé du 5 au 11 mai 2012, dans
le centre de tests Cisco à San José, en Californie aux Etats-Unis.
Bien que l’usage initial 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’opportunité de ce CPOC, les tests de performance et d’intégration dans 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’objectif de déployer
rapidement dans RENATER les mécanismes MPLS-TE validés, les préparatifs décris dans
la section suivantes ont étés mis en œuvre.
Généralisation et Déploiement
72
5.3.1 CPOC : Planification et préparatifs
Afin de pouvoir valider, en un temps très court, l’ensemble des tests décrits dans la
section suivante, un cahier de tests a été rédigé. Celui-ci détaille précisément la mise en
œuvre 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
document a également pour but de recueillir l’ensemble des observations et résultats.
Le cahier de test CPOC est fourni dans sa version finale, allégé des configurations des
routeurs, dans l’annexe « CPOC RENATER5-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 technique :
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 partie est dédiée aux tests d’interopérabilité et
de performance de la nouvelle plateforme Cisco ASR9000 et des interfaces 100 Gigabit
Ethernet (100GbE).
73
Nom du test Planning prévisionnel
Validé
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
Généralisation et Déploiement
74
7600 – 3
CRS – 6
7600 – 1 7600 – 5
7600 – 7
CRS – 2
ASR 9000 – 9
7604S
12K
CRS1
6504-E
Ethernet 10GbEthernet 1Gb
Traffic injector
ASR 9000
LACP LACP
12000 – 86500 – 4
Traffic Injector - 2
Traffic Injector - 3Full routing BGP
70 isis adjacency
Traffic Injector - 1
Ethernet 100Gb
Figure 38 – Topologie du CPOC RENATER-5
L’objectif de cette topologie est de permettre tous les tests nécessaires pendant le
CPOC. Puisque cette topologie est préparée à l’avance de la semaine de tests, celle-ci ne
pourra être modifiée et il a donc été important d’envisager tous les cas de figure.
75
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 :
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.
1 - Test unitaire numéro X
2 - Configuration de tout les routeurs. validation des
fonctionnalités et comportements
3 - sauvegarde des configurations des routeurs
et des traces de résultats dans Test_X_router_Y.zip
4 - Le rapporteur des tests consigne les résultats et archive les sauvegardes
Généralisation et Déploiement
76
5.3.3 CPOC, exemple de test : « Etablissement de tunnel TE à chemin
explicite »
Objectifs
Valider l’établissement d’un tunnel 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’interface des tunnels est déclaré sous la forme « 10XY ». 10 signifie que
c’est un tunnel TE à chemin explicite. 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 mise en œuvre est décrite dans la figure 40 page suivante.
77
7600 – 3
CRS1 – 6
7600 – 1 7600 – 5
7600 – 7
CRS1 – 2
ASR 9000 – 9
LACP LACP
12000 – 86500 – 4
Traffic Injector - 2
Traffic Injector - 3Full routing BGP
Traffic Injector - 1
&
Tunnel 1018/1081
Tunnel 1028/1082
Tunnel 1014/1041
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
index 20 next-address strict ipv4 unicast 10.3.3.1
index 30 next-address strict ipv4 unicast 10.3.7.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
!
Généralisation et Déploiement
78
! Pour 12000-8
!
explicit-path name 12000-8–7600-1
index 10 next-address strict ipv4 unicast 10.3.3.1
index 20 next-address strict ipv4 unicast 10.3.2.1
!
explicit-path name 12000-8–CRS-2
index 10 next-address strict ipv4 unicast 10.3.7.1
index 20 next-address strict ipv4 unicast 10.3.3.1
index 30 next-address strict ipv4 unicast 10.3.6.1
!
interface tunnel-te 1081
description TUNNEL TE1081–12000-8–7600-1
ipv4 unnumbered Loopback2
load-interval 30
destination 10.3.1.1
path-option 10 explicit name 12000-8–7600-1
!
interface tunnel-te 1082
description TUNNEL TE1082–12000-8–CRS-2
ipv4 unnumbered Loopback2
load-interval 30
destination 10.3.2.1
path-option 10 explicit name 12000-8–CRS-2
!
! Pour 7600-1
!
interface Tunnel 1018
description TUNNEL TE1018–7600-1–12000-8
ip unnumbered Loopback2
load-interval 30
tunnel destination 10.3.8.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng bandwidth 100
tunnel mpls traffic-eng path-option 10 explicit name 7600-1–12000-8
!
interface Tunnel 1014
description TUNNEL TE1014–7600-1–6500-4
ip unnumbered Loopback2
load-interval 30
tunnel destination 10.3.4.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng bandwidth 100
tunnel mpls traffic-eng path-option 10 explicit name 7600-1–6500-4
!
ip explicit-path name 7600-1–12000-8 enable
index 10 next-address 10.3.2.1
index 20 next-address 10.3.3.1
!
ip explicit-path name 7600-1–6500-4 enable
index 10 next-address 10.3.2.1
index 20 next-address 10.3.7.1
!
! Pour 6500-4
!
interface Tunnel 1041
description TUNNEL TE1041–6500-4–7600-1
ip unnumbered Loopback2
load-interval 30
tunnel destination 10.3.1.1
79
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng bandwidth 100
tunnel mpls traffic-eng path-option 10 explicit name 6500-4–7600-1
!
ip explicit-path name 6500-4–7600-1 enable
index 10 next-address 10.3.7.1
index 20 next-address 10.3.2.1
!
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:
Admin: up Oper: up Path: valid Signalling: connected
path option 10, type explicit 7600-1-12000-8 (Basis for Setup, path weight
25)
Config Parameters:
Bandwidth: 100 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute announce: disabled LockDown: disabled Loadshare: 100 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 10 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : TenGigabitEthernet1/4, 16037
Next Hop : 10.0.12.2
RSVP Signalling Info:
Src 10.3.1.1, Dst 10.3.8.1, Tun_Id 1018, Tun_Instance 1
RSVP Path Info:
My Address: 10.0.12.1
Explicit Route: 10.0.12.2 10.0.23.2 10.0.38.2 10.3.8.1
Record Route: NONE
Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits
Shortest Unconstrained Path Info:
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
Number of LSP IDs (Tun_Instances) used: 1
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:
Admin: up Oper: up Path: valid Signalling: connected
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:
Généralisation et Déploiement
80
Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff
Metric Type: TE (default)
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
Aucun problème n’est rencontré dans l’établissement des tunnels TE à chemin explicite.
L’interopérabilité entre les plateformes et les versions logicielles et bonne. Toutes les
plateformes ont été testées en tant que tête et queue de tunnel TE.
81
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’interopérabilité 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’une limite matérielle, les paramètres BFD sur les routeurs 12000 ne
peuvent pas être réglés à moins de 3x250ms. Cela pourra être un inconvénient
pour les mécanismes de « fast-reroute ».
2. L’activation 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 règles de configuration pour l’utilisation de MPLS-TE avec les L3VPN ne sont
pas les mêmes pour IOS et IOSXR. Cela pourra être un problème d’un point de
vue opérationnel.
4. Le mode de protection globale à chemin préétabli n’est pas disponible pour 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 modes d’auto configuration de maillage MPLS-TE (auto-tunnel mesh) ont été
testés mais leurs impacts sur les services de RENATER n’ont pas été vérifiés.
8. Les interfaces 100GbE ont été configurées avec succès entre les deux routeurs
CRS-2 et CRS-6, mais les tests de performance n’ont pas pu être menés à cause
d’un défaut d’interface sur les injecteurs 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 section suivante décris les processus de déploiement et de mise en œuvre.
Généralisation et Déploiement
82
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 Activation d’ISIS-TE sur 1 routeur
de chaque type.
Eventuelles pertes de paquets sur les
L2VPN, opération effectuée en HNO.
T2 Création d’un tunnel MPLS-TE de
test, sous surveillance pendant 2
semaines.
Aucun effet négatif observé sur le réseau.
Les figures 34 et 35 en annexe montrent
l’état de ce tunnel de test et son impact
sur le routeur de tête.
T3 Rédaction de la procédure de
déploiement et d’exploitation
Règles de nomenclature et de
numérotation, règles de configurations,
procédure de dépannage.
T4 Formation des équipes de BT à ces
procédures.
Quatre formations de 3h.
T5 Activation d’ISIS-TE sur tous les
routeurs.
Eventuelles pertes de paquets sur les
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
site LHCONE de Nantes suivant les
chemins définis en §5.2.
Aucun effet sur le trafic de production.
T7 Bascule des L2VPN LHCONE dans
les tunnels MPLS-TE.
Eventuelles pertes de paquets sur les
L2VPN. Opération effectué en journée et
en coordination avec les responsables des
sites concernés.
T8 Création des tunnels TE entre
Lyon1 et Genève, puis bascule du
L2VPN-PW LHCONE.
Séparation du trafic GEANT standard et
LHCONE.
83
5.5 Exploitation
La refonte du système d’informations (SI) de RENATER étant à l’étude lors de ce projet,
toutes les données d’exploitation des tunnels TE ont été répertoriées dans un fichier de
type tableur Excel.
Ce fichier, fourni en annexe, a été conçu dans l’objectif d’inté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
Résultats et discussion
84
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 bénéfices de l’utilisation de MPLS-TE.
La bascule des L2VPN du site LHCONE de Nantes dans des tunnels TE n’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.
85
(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
entre l’utilisation par le
LHCONE et l’utilisation par le
trafic IP standard (trou d’un
jour semaine 26).
(4) La liaison RENATER / GEANT à
Paris 1 est toujours chargée,
cependant l’utilisation de la
liaison de secours à Paris 2 a
pu être arrêtée (semaine 27).
Résultats et discussion
86
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 cas de l’utilisation de la liaison Grenoble – Genève d’économiser l’installation
d’une nouvelle liaison Lyon – Genève, soit environs 50K€.
Décongestion de certains axes et nœ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
classes de services n’ont pas été traités et seraient sûrement nécessaires en cas
de panne sur le réseau.
Enfin, ce projet a mis en évidence que certains points et interconnexions se comportent
comme des goulets d’étranglement inévitables. Les mécanismes d’ingénierie de trafic
sont alors à utiliser en complément, et non en substitut total, de la gestion et du suivi
des capacités de l’architecture et de la topologie réseau.
87
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
aujourd’hui les solutions d’ingénierie de trafic proposé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 ne pas provoquer d’effet de bord dans le réseau. La maitrise de l’implémentation
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 simulation réseau qui ont été mis en œuvre pour
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
En plus du déploiement des autres sites Tiers 2 LHCONE, d’autres usages possibles de
MPLS-TE ont été répertoriés :
o Partage de charge sur l’axe doublé Paris-Lyon-Marseille (PLM).
o Gestion des trafics sur l’axe PLM via des Tunnels-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’utilisation de MPLS-
TE dans RENATER.
De plus, l’utilisation de tunnels-TE en inter domaine est aujourd’hui un sujet de
recherche actif, notamment avec BGP-TE [6], ce valide le choix de cette technologie pour
une utilisation plus intense dans les réseaux d’opérateurs.
Résultats et discussion
88
D’autres solutions et protocoles qui permettent d’obtenir des résultats similaires sont
également à l’étude, comme les « Software Defined Network » dont OpenFlow [7] est un
exemple prometteur et soutenu par de nombreux acteurs de l’informatique (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 aux équipements réseaux. On pourra trouver un exemple d’utilisation par
Google : http ://www.wired.com/wiredenterprise/2012/04/going-with-the-flow-google/
6.4 Bilan personnel
Durant ces 9 mois, j’ai eu l’opportunité de travailler sur différents aspects de la gestion
de projet. La rédaction de l’étude des besoins, l’étude de faisabilité, la validation de la
solution choisie et la coordination du déploiement de tunnels MPLS-TE.
Le travail réalisé s’est avéré très enrichissant pour mon expérience professionnelle, aussi
bien d’un point de vue théorique et technique, qu’humain. Travailler avec les
différentes entités de RENATER, son NOC et Cisco m’a permis d’appréhender le rôle de
chacun dans la mise en œuvre et la gestion d’une architecture réseau d’opérateur.
La phase préliminaire d’étude théorique a fait appel et a enrichi mes méthodes de
recherche et mes connaissances acquises lors de ma formation d’ingénieur au CNAM.
L’étude de faisabilité et la validation de la solution technique lors du CPOC ont
grandement amélioré mes compétences techniques sur les protocoles et équipements
réseaux de type opérateur, mais également ma pratique et rédaction de l’Anglais
technique. J’ai également animé et piloté l’équipe d’ingénierie durant la semaine de
tests CPOC.
Enfin, la phase de déploiement a nécessité de travailler suivant les procédures internes à
RENATER : rédaction des documents d’exploitation, plan de déploiement, formation des
différentes équipes à la gestion et l’usage de ces nouveaux protocoles. Cette partie m’a
permis de comprendre le travail d’un ingénieur d’études et projets dans une entité
comme RENATER.
89
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 – Exemple d’établissement 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 orienté par de l’ingénierie de trafic .......................... 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 – Encapsulation d’une trame Ethernet taguée 802.1Q ..................................... 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 – Exemple de protection globale d’un tunnel MPLS-TE .................................... 53
Figure 26 – Tunnel de protection « Next Hop » ................................................................ 56
Figure 27 – Tunnel de protection « Next Next Hop » ........................................................ 56
Figure 28 – Exemple de protection FRR d’un tunnel 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’exemple « Etablissement de tunnel TE à chemin explicite » .. 77
Figure 41 – Weathermap d’exploitation LHCONE ............................................................. 83
Figure 42 – Supervision du L2VPN-TE du site LHCONE de Nantes .................................... 84
Appendices
90
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, techniques de l’ingénieur, 18p.
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, techniques de l’ingénieur, 23p.
[5] Frédéric JOUNAY, Orange Labs. VPWS (Virtual Private Wire Service), Technologie
Pseudowire ou circuit virtuel, techniques de l’ingénieur, 24p.
[6] http ://tools.ietf.org/html/draft-gredler-bgp-te-01
[7] http ://www.openflow.org/
Documentation Cisco
Tunnels TE à chemin explicite et dynamique.
http ://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/TE_1208S.pdf
Bande passante automatique des tunnels TE.
http ://www.cisco.com/en/US/docs/ios/12_2t/12_2t4/feature/guide/ftbwadjm.pdf
Métriques TE/IGP des tunnels MPLS-TE. http ://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsmetric.pdf
Protection locale FRR des tunnels TE avec BFD.
http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_link_node_prot.pdf
Protection globale des tunnels TE. http ://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_te_path_prot.pdf
Annonce des tunnels TE à l’ensemble des routeurs de l’IGP.
http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_te_fwd_adjacency.pdf
Tunnels TE, primaire ou de secours automatiques.
http ://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/gsmeshgr.pdf
Diffserv Aware TE http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsdserv3.pdf
91
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 sont les résultats de l’étape T2 du déploiement des tunnels MPLS-
TE sur RENATER §5.4.
Sur la première, on observe que le tunnel de test est opérationnel sur RENATER, et qu’il
est possible d’y injecter du trafic.
Sur la seconde, on observe les performances matérielles du routeur de tête du tunnel
TE. Le déploiement a eu lieu en semaine 21, les courbes d’utilisation des ressources
matérielles du routeur sont stables, il n’y a pas eu d’effet de bord.
Annexes
92
8.4 Base d’exploitation des tunnels TE
93
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 ^IGP Id:
IGP Id: 0000.0000.0001.00, MPLS-TE Id:193.51.178.10 Router Node (isis level-1)
IGP Id: 0000.0000.0002.00, MPLS-TE Id:193.51.178.2 Router Node (isis level-1)
IGP Id: 0000.0000.0003.00, MPLS-TE Id:193.51.178.12 Router Node (isis level-1)
IGP Id: 0000.0000.0039.00, MPLS-TE Id:193.51.178.39 Router Node (isis level-1)
IGP Id: 0000.0000.0051.00, MPLS-TE Id:193.51.178.51 Router Node (isis level-1)
IGP Id: 0000.0000.0052.00, MPLS-TE Id:193.51.178.52 Router Node (isis level-1)
IGP Id: 0000.0000.0056.00, MPLS-TE Id:193.51.178.56 Router Node (isis level-1)
IGP Id: 0000.0000.0180.00, MPLS-TE Id:193.51.178.180 Router Node (isis level-1)
IGP Id: 0000.0000.0183.00, MPLS-TE Id:193.51.178.183 Router Node (isis level-1)
IGP Id: 0000.0000.0184.00, MPLS-TE Id:193.51.178.184 Router Node (isis level-1)
IGP Id: 0000.0000.0185.00, MPLS-TE Id:193.51.178.185 Router Node (isis level-1)
IGP Id: 0000.0000.0186.00, MPLS-TE Id:193.51.178.186 Router Node (isis level-1)
IGP Id: 0000.0000.0188.00, MPLS-TE Id:193.51.178.188 Router Node (isis level-1)
IGP Id: 0000.0000.0189.00, MPLS-TE Id:193.51.178.189 Router Node (isis level-1)
IGP Id: 0000.0000.0190.00, MPLS-TE Id:193.51.178.190 Router Node (isis level-1)
IGP Id: 0000.0000.0198.00, MPLS-TE Id:193.51.178.198 Router Node (isis level-1)
IGP Id: 0000.0000.0199.00, MPLS-TE Id:193.51.178.199 Router Node (isis level-1)
IGP Id: 0000.0000.0138.00, MPLS-TE Id:193.51.178.138 Router Node (isis level-1)
IGP Id: 0000.0000.0145.00, MPLS-TE Id:193.51.178.145 Router Node (isis level-1)
IGP Id: 0000.0000.0171.00, MPLS-TE Id:193.51.178.171 Router Node (isis level-1)
IGP Id: 0000.0000.0172.00, MPLS-TE Id:193.51.178.172 Router Node (isis level-1)
IGP Id: 0000.0000.0173.00, MPLS-TE Id:193.51.178.173 Router Node (isis level-1)
IGP Id: 0000.0000.0174.00, MPLS-TE Id:193.51.178.174 Router Node (isis level-1)
IGP Id: 0000.0000.0175.00, MPLS-TE Id:193.51.178.175 Router Node (isis level-1)
IGP Id: 0000.0000.0176.00, MPLS-TE Id:193.51.178.176 Router Node (isis level-1)
IGP Id: 0000.0000.0178.00, MPLS-TE Id:193.51.178.178 Router Node (isis level-1)
IGP Id: 0000.0000.0179.00, MPLS-TE Id:193.51.178.179 Router Node (isis level-1)
IGP Id: 0000.0000.0200.00, MPLS-TE Id:193.51.178.200 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
Neighbor ID: 0000.0000.0188.00 (area: isis level-1, IP: 193.51.189.57)
Paramètres des Tunnels MPLS Traffic Engineering
id tunnel
type de
chemin
metrique
suivie
Priorité
établissement
Priorité
maintient Affinité Masque Annonce IGP Protection
Partage de charge
(groupe)
Partage de charge
(poids)
13122 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
23122 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
13123 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
23123 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
13125 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
23125 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
13126 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
23126 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
0 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
0 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
0 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
0 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
13127 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
23127 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
13128 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
23128 Explicite TE 7 7 0x0 0xffff Aucune Aucune Aucun 0
Annexes
94
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
Neighbor ID: 0000.0000.0045.00 (area: isis level-1, IP: 193.51.179.149)
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 ----
ip unnumbered Loopback2
tunnel mode mpls traffic-eng
tunnel destination 193.51.178.185
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 ----
95
ip unnumbered Loopback2
tunnel mode mpls traffic-eng
tunnel destination 193.51.178.178
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:
Admin: up Oper: up Path: valid Signalling: connected
path option 10, type explicit EP-NANTES-RTR-021=>PARIS1-RTR-021-PRIMARY (Basis for
Setup, path weight 83)
Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute announce: disabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 10 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : TenGigabitEthernet1/2, 332
Next Hop : 193.51.189.57
RSVP Signalling Info:
Src 193.51.178.183, Dst 193.51.178.185, Tun_Id 13122, Tun_Instance 146
RSVP Path Info:
Annexes
96
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
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
Shortest Unconstrained Path Info:
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
Number of LSP IDs (Tun_Instances) used: 146
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
Annexes
Étude, conception et déploiement des technologies d’ingénierie de trafic sur l’infrastructure de
production MPLS de RENATER. Mémoire d’ingénieur EICNAM, Paris 2013, Nicolas GARNIER.
Résumé
Les expériences menées par le CERN sur le LHC sont génératrices d’une grande 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’utiliser des mécanismes
d’ingénierie de trafic.
L’objectif de cette étude est de définir et déployer les moyens nécessaires à l’orientation, vers des
chemins choisis, des connexions VPN entre les centres de calcul et le LHCONE.
MPLS-TE s’est révélé être le mécanisme unanimement utilisé et proposé sur le marché. Après avoir
défini son utilisation dans l’architecture cible, nous l’avons testé et validé sur une maquette virtuelle,
puis en situation réelle chez l’équipementier Cisco, avant de le mettre en production.
Ce déploiement a permis d’utiliser les liaisons sous-exploitées du réseau RENATER et d’ouvrir de
nouvelles possibilités en termes de planification de l’infrastructure.
Abstract
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.