Étude, conception et déploiement des technologies d'ingénierie de ...

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.

http://fr.wikipedia.org/wiki/Internet

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/.

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.


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.


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.


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.


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.


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


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.



(6) R7 est la queue de tunnel TE (tail-end). Il envoie un Resv message à R6. Ce

message contient le label de commutation MPLS à employer pour le tunnel

TE par R6. Dans ce cas le label=implicit-null.

(7) R6 envoie un Resv message à R5 et indique un incoming label=42.




L’établissement du LSP-TE est alors finalisé.


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


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-


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


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


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 6: 10.2.0.1

o Query Parameters : paramètres demandés.

o Query Results : Chemins résultants qui répondent aux contraintes.


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


load-interval 30




tunnel mpls traffic-eng path-option 1 dynamic

tunnel mpls traffic-eng path-selection metric te

o path-option 1 dynamic : Le 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 :



Status: Admin: up Oper: up Path: valid Signalling:

connected

path option 1, type dynamic (Basis for Setup, path weight 8)

Config Parameters:




auto-bw: disabled


State: dynamic path option 1 is active


[…]



RSVP Path Info:


Explicit Route: 10.0.48.2 10.0.58.2 10.0.58.1 10.0.15.2

10.0.15.1 10.0.12.1 10.0.12.2 10.2.0.1

On retrouve ici les mêmes informations que dans le status du tunnel TE à chemin

explicite. On peut toutefois observer des différences :

State : dynamic path option 1 is active : indique que le tunnel TE est bien en

mode CSPF.

Explicit Route : détail de la route choisie par le CSPF et signalée pour ce tunnel

TE.

Statuts généraux du tunnel :

P4#sh mpls traffic-eng tunnels tunnel 2 brief

Signalling Summary:

LSP Tunnels Process: running

Passive LSP Listener: running

RSVP Process: running

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 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 ».


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



Status:



Config Parameters:




auto-bw: (300/248) 0 Bandwidth Requested: 979

Samples Missed 0: Samples Collected 0




InLabel : -

OutLabel : GigabitEthernet2/0, 34



RSVP Path Info:


Explicit Route: 10.0.48.2 10.0.38.2 10.0.38.1 10.0.23.2 10.0.23.1 10.2.0.1

Record Route: NONE


RSVP Resv Info:

Record Route: NONE


On observe ici le trafic écoulé pendant les 30 dernières secondes sur une interface de

type tunnel TE.

Le champ « auto-bw : (300/248) 0 Bandwidth Requested : 979 » indique que la valeur

demandée par le tunnel TE est bien mise à jour.

Résultat dans la topologie TE : la bande passante dans la topologie est réservée par

niveau de priorités :

link[0]: Broadcast, DR: 0000.0000.0004.02, nbr_node_id:19, gen:48

frag_id 0, Intf Address:10.0.48.1

TE metric:5, IGP metric:100, attribute flags:0x0

SRLGs: None

physical_bw: 1000 (kbps), max_reservable_bw_global: 5000 (kbps)

max_reservable_bw_sub: 0 (kbps)

Global Pool Sub Pool

Total Allocated Reservable Reservable

BW (kbps) BW (kbps) BW (kbps)

--------------- ----------- ----------

bw[0]: 0 5000 0

bw[1]: 0 5000 0

bw[2]: 0 5000 0

bw[3]: 0 5000 0

bw[4]: 0 5000 0

bw[5]: 979 4021 0

bw[6]: 0 4021 0

bw[7]: 0 4021 0


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





interface Tunnel2





interface Tunnel 3





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…).


50


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.


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.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


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


P7#sh ip route


Le tunnel est déclaré dans la table de routage avec un poids ISIS égal à 8. La table de

routage du routeur P7 à bien pris en compte ce nouveau lien dans ses calculs de plus

court chemin.

4.3.2 Protection des tunnels MPLS-TE

Pour fiabiliser un tunnel MPLS-TE, plusieurs modes de protection existent :

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




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 :



Status:



Path Protection: 0 Common Link(s), 0 Common Node(s)

path protect option 1, type explicit Tunnel_1_sec (Basis for Protect, path

weight 21)

[…]

Sont indiqués ci-dessus :

o Le chemin de protection globale choisi et son poids.

o Le 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 :



Status:


path protect option 1, type explicit Tunnel_1_sec (Basis for Protect, path

weight 21)

path option 1, type explicit Tunnel_1_pri

Path Protection: Backup lsp in use.

Path protect option 1, type explicit Tunnel_1_sec (Basis for Protect, path

weight 21)


P4_t1

LSP Head, Tunnel1, Admin: up, Oper: up


Fast Reroute Protection: None

Path Protection: Backup lsp in use.

Mesure du temps de convergence du chemin de protection globale : Ci-dessous, test de

coupure de tunnel TE. Une trace de ping entre les deux machines QEMU dont le trafic

circule via le tunnel TE.

Sending 100, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 99 percent (99/100), round-trip min/avg/max = 8/76/304 ms

1% de pertes lors d’une bascule Tunnel TE principal / Tunnel TE de secours. A la vue des

faibles performances du simulateur (latence en 8 et 304ms), il est impossible de

quantifier le temps de convergence.

Ci-dessous, le test 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:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


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


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


tunnel destination 10.3.0.1 | 10.2.0.1


tunnel mpls traffic-eng path-option 1 explicit name Tunnel_100_frr

o tunnel destination : 10.3.0.1 pour du NHOP

o tunnel destination : 10.2.0.1 pour du NNHOP

(3) Chemin explicite du tunnel de protection FRR : ip explicit-path name Tunnel_100_frr enable

include-address « chemin complet NHOP ou NNHOP »

ou

exclude-address 10.0.38.2 ou 10.3.0.1

Il est possible de spécifier le chemin complet du tunnel NHOP/NNHOP ou de

spé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_t1

LSP Head, Tunnel1, Admin: up, Oper: up


Fast Reroute Protection: Requested

[…]

Du point de vue de P4, la protection FRR est demandée. Le tunnel sera éligible au FRR

dans la topologie.

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


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 :



Status:



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 ».


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


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.


64


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

http://www.cisco.com/

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).


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


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.


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


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


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


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 - 3Full routing BGP


&

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



!

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

!


78

! Pour 12000-8

!

explicit-path name 12000-8–7600-1



!

explicit-path name 12000-8–CRS-2




!


description TUNNEL TE1081–12000-8–7600-1


load-interval 30


path-option 10 explicit name 12000-8–7600-1

!


description TUNNEL TE1082–12000-8–CRS-2


load-interval 30


path-option 10 explicit name 12000-8–CRS-2

!

! Pour 7600-1

!




load-interval 30




tunnel mpls traffic-eng path-option 10 explicit name 7600-1–12000-8

!




load-interval 30





!

ip explicit-path name 7600-1–12000-8 enable

index 10 next-address 10.3.2.1


!




!

! Pour 6500-4

!




load-interval 30


79




!




!

Résultats

Ces résultat sont valables IOS & IOSXR : traces de console de routeur, état détaillé des

tunnels MPLS-TE 1018 et 1028 sur 7600-1 et CRS-2.

7600-1#sh mpls traffic-eng tunnels tunnel 1018

Name : TUNNEL TE1018–7600-1–12000-8 (Tunnel1018) Destination : 10.3.8.1

Status:


path option 10, type explicit 7600-1-12000-8 (Basis for Setup, path weight

25)

Config Parameters:


Metric Type: TE (default)

AutoRoute announce: disabled LockDown: disabled Loadshare: 100 bw-based

auto-bw: disabled




InLabel : -

OutLabel : TenGigabitEthernet1/4, 16037

Next Hop : 10.0.12.2



RSVP Path Info:


Explicit Route: 10.0.12.2 10.0.23.2 10.0.38.2 10.3.8.1

Record Route: NONE


RSVP Resv Info:

Record Route: NONE



Path Weight: 25 (TE)

Explicit Route: 10.0.12.2 10.0.23.2 10.0.38.2 10.3.8.1

History:

Tunnel:

Time since created: 7 minutes, 41 seconds

Time since path change: 6 minutes, 55 seconds


Current LSP : [ID : 1]

Uptime : 6 minutes, 55 seconds

RP/0/RP0/CPU0 :CRS-2#sh mpls traffic-eng tunnels 1028

Name : tunnel-te1028 Destination : 10.3.8.1

Status:


path option 10, type explicit CRS-2–12000-8 (Basis for Setup, path weight

105)

G-PID: 0x0800 (derived from egress interface properties)

Bandwidth Requested: 0 kbps CT0

Creation Time: Mon May 7 23:15:21 2012 (00:14:43 ago)

Config Parameters:


80

Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff


Hop-limit: disabled

AutoRoute: disabled LockDown: disabled Policy class: not set

Forwarding-Adjacency: disabled

Loadshare: 0 equal loadshares

Auto-bw: disabled

Fast Reroute: Disabled, Protection Desired: None

Path Protection: Not Enabled

History:

Tunnel has been up for: 00:14:43 (since Mon May 07 23:15:21 UTC 2012)

Current LSP:

Uptime: 00:14:43 (since Mon May 07 23:15:21 UTC 2012)

Path info (IS-IS 2200 level-1):

Hop0: 10.0.26.6

Hop1: 10.0.36.1

Hop2: 10.0.37.2

Hop3: 10.0.78.2

Hop4: 10.3.8.1

Displayed 1 (of 1) heads, 0 (of 2) midpoints, 0 (of 1) tails

Displayed 1 up, 0 down, 0 recovering, 0 recovered heads

Ces résultats ne sont valables que pour IOSXR : détail du chemin explicite du tunnel TE

1028 sur CRS-2.

RP/0/RP0/CPU0:CRS-2#sh explicit-paths

Mon May 7 23:36:22.289 UTC

Path CRS-2–12000-8 status enabled

0xa: next-address strict 10.3.6.1

0x14: next-address strict 10.3.3.1

0x1e: next-address strict 10.3.7.1

Tests de « traceroute » entre les routeurs CRS-2 et 12000-8, pour les chemins fixés par

l’IGP et par le tunnel TE 1028.

RP/0/RP0/CPU0:CRS-2#traceroute 10.3.8.1

Tracing the route to 10.3.8.1

1 10.0.26.2 [MPLS: Label 16031 Exp 0] 37 msec 20 msec 13 msec

2 10.0.67.2 [MPLS: Label 30 Exp 0] 15 msec 13 msec 5 msec

3 10.0.78.2 15 msec * 10 msec

RP/0/RP0/CPU0 :CRS-2#traceroute mpls traffic-eng tunnel-te 1028

Tracing MPLS-TE Label Switched Path on tunnel-te1028, timeout is 2 seconds

0 10.0.26.5 MRU 9180 [Labels : 16038 Exp : 0]

. 1 *

L 2 10.0.36.1 MRU 9214 [Labels : 118 Exp : 0] 192 ms

L 3 10.0.37.2 MRU 9204 [Labels: implicit-null Exp: 0] 202 ms

! 4 10.0.78.2 15 ms

Commentaires et recommandations

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.


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.


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.


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).


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.


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.

http://www.wired.com/wiredenterprise/2012/04/going-with-the-flow-google/

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

https://indico.cern.ch/getFile.py/access?contribId=1&resId=1&materialId=slides&confId=151862

https://indico.cern.ch/getFile.py/access?contribId=1&resId=1&materialId=slides&confId=151862

http://www/

http://tools.ietf.org/html/draft-gredler-bgp-te-01

http://www.openflow.org/

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/TE_1208S.pdf

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/TE_1208S.pdf

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t4/feature/guide/ftbwadjm.pdf

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t4/feature/guide/ftbwadjm.pdf

http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsmetric.pdf

http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsmetric.pdf



http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_te_path_prot.pdf

http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_te_path_prot.pdf



http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/gsmeshgr.pdf

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/gsmeshgr.pdf

http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsdserv3.pdf

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)




























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


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
















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


up, Sources: IGP

=====================================================================================

SHOW RSVP-Te

=====================================================================================

nantes-rtr-021#sh ip rsvp

RSVP: enabled (on 6 interface(s))

MPLS/TE signalling enabled

nantes-rtr-021#sh ip rsvp interface

interface rsvp allocated i/f max flow max sub max

Te1/1 ena 0 7500M 7500M 0

Te1/2 ena 0 7500M 7500M 0

Te1/5 ena 0 7500M 7500M 0

Te2/1 ena 0 7500M 7500M 0

Te2/2 ena 0 7500M 7500M 0

nantes-rtr-021#sh ip rsvp neighbor

Neighbor Encapsulation Time since msg rcvd/sent

193.51.189.57 Raw IP 00:00:01 00:00:06

193.51.189.73 Raw IP 00:00:10 00:00:08

=====================================================================================

CONF PW et tunnnels

=====================================================================================

pseudowire-class PW-NANTES-R021=>PARIS1-R021

encapsulation mpls

preferred-path interface Tunnel13122 disable-fallback

!

pseudowire-class PW-NANTES-R021=>LYON1-R021

encapsulation mpls

preferred-path interface Tunnel13123 disable-fallback

!

interface TenGigabitEthernet1/3.3122

description -s-- IN2P3-SUBATECH-NANTES / VPN-VPWS-TE13122-LHCONE-NANTES-RTR-021-PARIS1-

RTR-021 ----

encapsulation dot1Q 3122

no cdp enable

xconnect 193.51.178.185 3122 pw-class PW-NANTES-R021=>PARIS1-R021

mtu 9180

!

interface TenGigabitEthernet1/3.3123

description -s-- IN2P3-SUBATECH-NANTES/ VPN-VPWS-TE13123-LHCONE-NANTES-RTR-021-LYON1-RTR-

021 ----

encapsulation dot1Q 3123

no cdp enable

xconnect 193.51.178.178 3123 pw-class PW-NANTES-R021=>LYON1-R021

mtu 9180

!

interface Tunnel13122

description -TE- 13122-NANTES-RTR-021=>PARIS1-RTR-021 / LHCONE PW-3122 ----




tunnel mpls traffic-eng path-option 10 explicit name EP-NANTES-RTR-021=>PARIS1-RTR-021-

PRIMARY

!

interface Tunnel13123

description -TE- 13123-NANTES-RTR-021=>LYON1-RTR-021 / LHCONE PW-3123 ----

95




tunnel mpls traffic-eng path-option 10 explicit name EP-NANTES-RTR-021=>LYON1-RTR-021-

PRIMARY

!

=====================================================================================

SHOW PW et tunnels

=====================================================================================

nantes-rtr-021#sh int description

Interface Status Protocol Description

Te1/3.3122 up up -s-- IN2P3-SUBATECH-NANTES / VPN-

VPWS-TE13122-LHCONE-NANTES-RTR-021-PARIS1-RTR-021 ----

Te1/3.3123 up up -s-- IN2P3-SUBATECH-NANTES/ VPN-

VPWS-TE13123-LHCONE-NANTES-RTR-021-LYON1-RTR-021 ----

[...]

Tu13122 up up -TE- 13122-NANTES-RTR-021=>PARIS1-

RTR-021 / LHCONE PW-3122 ----

Tu13123 up up -TE- 13123-NANTES-RTR-021=>LYON1-

RTR-021 / LHCONE PW-3123 ----

nantes-rtr-021#sh mpls traffic-eng tunnels brief

Signalling Summary:

LSP Tunnels Process: running

Passive LSP Listener: running

RSVP Process: running

Forwarding: enabled

Periodic reoptimization: every 3600 seconds, next in 2014 seconds

Periodic FRR Promotion: Not Running

Periodic auto-bw collection: every 300 seconds, next in 215 seconds

P2P TUNNELS/LSPs:

TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT

-TE- 13122-NANTES-RTR-021=>P... 193.51.178.185 - Te1/2 up/up

-TE- 13123-NANTES-RTR-021=>L... 193.51.178.178 - Te1/1 up/up

-TE- 23123-LYON1-RTR-021=>NA... 193.51.178.183 Te1/1 - up/up

-TE- 23122-PARIS1-RTR-021=>N... 193.51.178.183 Te1/2 - up/up

Displayed 2 (of 2) heads, 0 (of 0) midpoints, 2 (of 2) tails

=====================================================================================

nantes-rtr-021#sh mpls traffic-eng tunnels tunnel 13122

Name: -TE- 13122-NANTES-RTR-021=>PARIS... (Tunnel13122) Destination: 193.51.178.185

Status:


path option 10, type explicit EP-NANTES-RTR-021=>PARIS1-RTR-021-PRIMARY (Basis for

Setup, path weight 83)

Config Parameters:



AutoRoute announce: disabled LockDown: disabled Loadshare: 0 bw-based

auto-bw: disabled




InLabel : -

OutLabel : TenGigabitEthernet1/2, 332

Next Hop : 193.51.189.57



RSVP Path Info:

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


RSVP Resv Info:

Record Route: NONE



Path Weight: 83 (TE)

Explicit Route: 193.51.189.57 193.51.189.54 193.51.189.46 193.51.189.49

193.51.189.38 193.51.178.185

History:

Tunnel:

Time since created: 2 days, 20 hours, 52 minutes

Time since path change: 1 days, 1 hours, 2 minutes


Current LSP: [ID: 146]

Uptime: 1 days, 1 hours, 2 minutes

Prior LSP: [ID: 124]

ID: path option unknown

Removal Trigger: path verification failed

=====================================================================================

nantes-rtr-021#sh mpls l2transport vc 3122 detail

Local interface: Te1/3.3122 up, line protocol up, Eth VLAN 3122 up

Interworking type is Ethernet

Destination address: 193.51.178.185, VC ID: 3122, VC status: up

Output interface: Tu13122, imposed label stack {332 446}

Preferred path: Tunnel13122, active

Default path: disabled

Next hop: point2point

=====================================================================================

nantes-rtr-021#sh mpls traffic-eng tunnels tunnel 13122 accounting

Tunnel13122 (Destination 193.51.178.185; Name -TE- 13122-NANTES-RTR-021=>PARIS1-RTR-021 /

LHCONE PW-3122 ----)

5 minute output rate 804391 kbits/sec, 77378 packets/sec

nantes-rtr-021#sh mpls traffic-eng tunnels tunnel 13123 accounting

Tunnel13123 (Destination 193.51.178.178; Name -TE- 13123-NANTES-RTR-021=>LYON1-RTR-021 /

LHCONE PW-3123 ----)

5 minute output rate 0 kbits/sec, 0 packets/sec

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.

Étude, conception et déploiement des technologies d'ingénierie de ...

Documents

Transcript of Étude, conception et déploiement des technologies d'ingénierie de ...