de trafic sur l infrastructure de production MPLS de RENATER

Dimension: px
Commencer à balayer dès la page:

Download "de trafic sur l infrastructure de production MPLS de RENATER"

Transcription

1 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

2

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

4

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

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

7 Table des matières 1 Introduction MPLS et Ingénierie de trafic Enjeux et principes MPLS-TE Signalisation des LSP-TE Conclusion partielle Étude du besoin Optimisation des liens de backup et contrôle du trafic Projet LHCONE Analyse du périmètre réseau RENATER Choix des solutions et faisabilité Protocole de tests Établissement de tunnels MPLS-TE Utilisation des tunnels MPLS-TE Types de trafic supportés par les tunnels MPLS-TE Gestion centralisée de MPLS-TE Généralisation et Déploiement Fonctionnalités MPLS-TE dans le périmètre réseau R Choix de mise en œuvre du projet LHCONE Validation sur l ensemble du périmètre Déploiement Exploitation Résultats et discussion Résultats du projet... 84

8 6.2 Retour sur expérience Perspective Bilan personnel Appendices Table des illustrations Références Annexes Etude de métrologie RENATER CPOC RENATER-5 TE Supervision du tunnel MPLS-TE de test sur RENATER Base d exploitation des tunnels TE Etat du réseau après le déploiement de MPLS-TE... 93

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

10 Introduction 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 2

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

12 Introduction Figure 2 - Architecture réseau de RENATER 4

13 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 5

14 Introduction 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. 6

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

16 MPLS et Ingénierie de trafic 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 IPv MPLS-TE 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. 8

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

18 MPLS et Ingénierie de trafic 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 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, 10

19 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 en transit, et pour Juniper, en Février 2012, LSP-TE terminaux et en transit. Les matériels évoluent donc dans le sens d une utilisation de plus en plus importante de LSP-TE. 11

20 MPLS et Ingénierie de trafic 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é. 12

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

22 MPLS et Ingénierie de trafic 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 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. 14

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

24 MPLS et Ingénierie de trafic 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»). 16

25 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 20M 50 10M 50 P6 Phase 1 10M M 50 10M 50 20M 50 P1 10M 50 5M 50 20M 50 P6 Phase 2 10M M 50 10M 50 20M 50 P1 10M 50 20M 50 P6 Phase 3 10M M 50 10M 50 20M 50 P1 10M 50 10M : Bande passante TE disponible 100 : Métrique TE Figure 11 Algorithme de sélection du chemin dynamique CSPF en trois phases. (1) Configuration du LSP-TE sur le routeur de tête : définition des objectifs et contraintes. (2) Elimination des liens qui ne valident pas les critères TE du LSP-TE. (3) Calcul du plus court chemin (SPF) sur la topologie contrainte résultante. 17

26 MPLS et Ingénierie de trafic 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 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. 18

27 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 19

28 MPLS et Ingénierie de trafic («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. 20

29 La figure ci-dessous détaille les étapes du processus d établissement d un LSP-TE avec RSVP-TE, en donnant l exemple d une réservation le long du chemin R1R2R3R5R6R7. Figure 12 Exemple d établissement de LSP-TE par RSVP-TE (1) R1 est tête du tunnel TE (head-end), il envoie un Path message à R2. Celui-ci vérifie le format du message et la disponibilité des ressources TE demandées. Si les ressources ne sont pas disponibles, R2 renvoie un message PathErr à R1, la séquence d établissement est alors annulée. (2) R2 envoie un Path message à R3. R3 fait les mêmes vérifications qu en (1). (3) R3 envoie un Path message à R5. Mêmes vérifications. (4) R5 envoie un Path message à R6. Mêmes vérifications. (5) R6 envoie un Path message à R7. Mêmes vérifications. (6) R7 est la queue de tunnel TE (tail-end). Il envoie un Resv message à R6. Ce message contient le label de commutation MPLS à employer pour le tunnel TE par R6. Dans ce cas le label=implicit-null. (7) R6 envoie un Resv message à R5 et indique un incoming label=42. (8) R5 envoie un Resv message à R3 et indique un incoming label= (9) R3 envoie un Resv message à R2 et indique un incoming label=21. (10) R2 envoie un Resv message à R1 et indique un incoming label=18. L établissement du LSP-TE est alors finalisé. 21

30 MPLS et Ingénierie de trafic 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 22

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

32 Étude du besoin 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 Contexte Dans le cadre du projet de recherche international LHC, le LHCOPN (figure 13) est un réseau dédié qui interconnecte les laboratoires du CERN T0 et des centres de calcul T1 répartis dans le monde entier. Les échanges de données entre T0, T1 et T2 suivent le schéma «monarch, présenté en introduction. Le réseau LHCONE (figure 14) est une 24

33 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. Tier 3 Tier 3 Tier 3 Figure 13 LHCOPN, échanges hiérarchiques des données avec les T2. Tier 3 Tier 3 Figure 14 LHCONE, échanges distribués des données entre les T2. 25

34 Étude du besoin 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». 26

35 Figure 16 Tiers 1, 2 et 3 du réseau LHCONE sur RENATER 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). 27

36 Étude du besoin 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. 28

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

38 Étude du besoin 3.3 Analyse du périmètre réseau RENATER 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 Cisco IOS XR Software, Version RTR-011 Cisco CRS-1 Cisco IOS XR Software, Version RTR

39 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 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 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»). 31

40 Étude du besoin 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. 32

41 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-toany», 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. 33

42 Étude du besoin Un L2VPN-PW est créé dans une architecture MPLS via les mécanismes suivants : Les interfaces de connexion des sites utilisateurs (CE) sont tagués avec un VLAN. Les interfaces de 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). Mapping VLAN ID vers VC ID Mapping VC ID vers VLAN ID Vlan 2000 VC 222 VC 222 Vlan 2000 Nuage MPLS CE 1 PE 1 Pseudo Wire PE 2 CE 2 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 34

43 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. CE 2 Peering ebgp PE2 RR Nuage MPLS Peering ibgp PE 1 PE 3 CE 1 CE 3 Figure 22 L3VPN sur VRF «VERTE» - Peering ebgp et ibgp sur Route Reflector Du point de vue des sites interconnectés, le L3VPN se comporte comme un unique routeur d interconnexion. Seul l usage des services Ipv4 unicast est permis dans un L3VPN sur RENATER. 35

44 Choix des solutions et faisabilité 4 Choix des solutions et faisabilité Cette section met en évidence le fonctionnement et le rôle des fonctionnalités de MPLS- TE dans son implémentation proposée par Cisco. Nous pourrons alors choisir les fonctionnalités qui répondent le mieux aux besoins du projet. 4.1 Protocole de tests 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. 36

45 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 Cisco 1. 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

46 Choix des solutions et faisabilité Adresse de loopback Sous-réseau d un lien en 10.0.x.x Métriques IGP Figure 23 Architecture de test mise en place via Dynamips/GNS3 38

47 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 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 mpls traffic-eng attribute-flags 0xABCD mpls traffic-eng administrative-weight 5 o Bandwidth [ ] : 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. [ ] kbps ou pourcentage de la bande passante de l interface. B : Bande passante réservable par flux dans des tunnels MPLS-TE. [1-39

48 Choix des solutions et faisabilité ] 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: , nbr_node_id:14, gen:31 frag_id 0, Intf Address: 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]: bw[1]: bw[2]: bw[3]: bw[4]: bw[5]: bw[6]: bw[7]: [ ] 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. 40

49 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 Tunnel MPLS TE bidirectionnel P4-P Adresse de loopback Sous-réseau d un lien en 10.0.x.x 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 next-address exclude-address 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 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 7 7 tunnel mpls traffic-eng bandwidth 800 tunnel mpls traffic-eng path-option 1 explicit name Tunnel_1_pri 41

50 Choix des solutions et faisabilité 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: 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 , Dst , Tun_Id 1, Tun_Instance 18 RSVP Path Info: My Address: Explicit Route: 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: 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. 42

51 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 [paramètres] Query Parameters: Destination: 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: : affinity , bandwidth 5000 (kbps) Hop 1: : affinity , bandwidth 1000 (kbps) Hop 2: : affinity , bandwidth 1000 (kbps) Hop 3: : affinity , bandwidth 1000 (kbps) Hop 4: : affinity , bandwidth 1000 (kbps) Hop 5: : affinity , bandwidth 1000 (kbps) Hop 6: o Query Parameters : paramètres demandés. o Query Results : Chemins résultants qui répondent aux contraintes. 43

52 Choix des solutions et faisabilité Etablissent d un tunnel TE à chemin dynamique La création de chemins dynamiques utilise un algorithme de recherche du chemin le plus court selon des contraintes, CSPF (détaillé en 2.2.4). Configuration d un tunnel à chemin dynamique : interface Tunnel1 ip unnumbered Loopback1 load-interval 30 tunnel destination tunnel mode mpls traffic-eng tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 1 dynamic tunnel mpls traffic-eng path-selection metric te o path-option 1 dynamic : Le chemin utilise l algorithme CSPF pour s établir. o path-selection metric te : type de métrique prise en compte dans le calcul CSPF. Statut d établissement du tunnel à chemin dynamique : P4#sh mpls traffic-eng tunnels tunnel 2 Name: P4_t2 (Tunnel2) Destination: Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 8) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 5 4 Affinity: 0x0/0xFFFF Metric Type: TE (interface) AutoRoute: disabled LockDown: disabled Loadshare: 100 bw-based auto-bw: disabled Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled [ ] RSVP Signalling Info: Src , Dst , Tun_Id 2, Tun_Instance 1 RSVP Path Info: My Address: Explicit Route: On retrouve ici les mêmes informations que dans le status du tunnel TE à chemin explicite. On peut toutefois observer des différences : State : dynamic path option 1 is active : indique que le tunnel TE est bien en mode CSPF. Explicit Route : détail de la route choisie par le CSPF et signalée pour ce tunnel TE. Statuts généraux du tunnel : P4#sh mpls traffic-eng tunnels tunnel 2 brief Signalling Summary: LSP Tunnels Process: running Passive LSP Listener: running RSVP Process: running 44

53 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_t 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: Bandwidth: 100 Priorities: 5 (setup), 4 (hold) Affinity: 0x0 (value), 0xFFFF (mask) Query Results: Min Bandwidth Along Path: 800 (kbps) Max Bandwidth Along Path: 4800 (kbps) Hop 0: : affinity , bandwidth 4800 (kbps) Hop 1: : affinity , bandwidth 1000 (kbps) Hop 2: : affinity , bandwidth 900 (kbps) Hop 3: : affinity , bandwidth 1000 (kbps) Hop 4: : affinity , bandwidth 800 (kbps) Hop 5: : affinity , bandwidth 1000 (kbps) Hop 6: : affinity , bandwidth 800 (kbps) Hop 7: : affinity , bandwidth 1000 (kbps) Hop 8: 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». 45

54 Choix des solutions et faisabilité 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 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 to 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 [ ] : Fréquence de mise à jour de la bande passante, en secondes. o max-bw 1000 min-bw 100 : Bande passante minimale et maximale autorisée 46

55 Résultat dans la table de routage : P4#sh mpls traffic-eng tunnels tunnel 1 accounting Tunnel1 (Destination ; Name P4_t1) 30 second output rate 1043 kbits/sec, 104 packets/sec P4#sh mpls traffic-eng tunnels tunnel 1 Name: P4_t1 (Tunnel1) Destination: Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type explicit Tunnel_1_pri (Basis for Setup, path weight 15) Config Parameters: Bandwidth: 0 kbps (Global) Priority: 6 5 Affinity: 0x0/0xFFFF Metric Type: TE (interface) AutoRoute: disabled LockDown: disabled Loadshare: 979 bw-based auto-bw: (300/248) 0 Bandwidth Requested: 979 Samples Missed 0: Samples Collected 0 Active Path Option Parameters: State: explicit path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : - OutLabel : GigabitEthernet2/0, 34 RSVP Signalling Info: Src , Dst , Tun_Id 1, Tun_Instance 20 RSVP Path Info: My Address: Explicit Route: Record Route: NONE Tspec: ave rate=979 kbits, burst=1000 bytes, peak rate=979 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=979 kbits, burst=1000 bytes, peak rate=979 kbits On observe ici le trafic écoulé pendant les 30 dernières secondes sur une interface de type tunnel TE. Le champ «auto-bw : (300/248) 0 Bandwidth Requested : 979» indique que la valeur demandée par le tunnel TE est bien mise à jour. Résultat dans la topologie TE : la bande passante dans la topologie est réservée par niveau de priorités : link[0]: Broadcast, DR: , nbr_node_id:19, gen:48 frag_id 0, Intf Address: 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]: bw[1]: bw[2]: bw[3]: bw[4]: bw[5]: bw[6]: bw[7]:

56 Choix des solutions et faisabilité Fonctions d adaptation Préemption Pour mettre en évidence le fonctionnement des niveaux de priorités de préemption des tunnels, nous avons créé trois tunnels à chemin dynamique avec les paramètres suivants : interface Tunnel1 ip unnumbered Loopback1 tunnel destination tunnel mpls traffic-eng bandwidth 800 tunnel mpls traffic-eng priority 6 5 interface Tunnel2 ip unnumbered Loopback1 tunnel destination tunnel mpls traffic-eng bandwidth 1000 tunnel mpls traffic-eng priority 5 5 interface Tunnel 3 ip unnumbered Loopback1 tunnel destination tunnel mpls traffic-eng bandwidth 200 tunnel mpls traffic-eng priority 7 7 Dans ce cas, la bande passante disponible dans la topologie TE n est pas toujours suffisante, les tunnels qui peuvent s établir sur les liens TE seront alors ceux qui ont la plus forte priorité d établissement. Aussi, la priorité de maintien permet à un tunnel déjà établi de résister à une préemption. L ordre d établissement des tunnels TE et leurs paramètres de préemption ont donc leur importance, des situations d inter blocage ou de sous-optimisation de la topologie TE pouvant apparaître. Les phases de réoptimisation décrites dans la section suivante permettent dans une certaine limite de résoudre ces points. Réoptimisation La réoptimisation consiste à relancer périodiquement ou sur évènement le calcul CSPF pour chaque tunnel à chemin dynamique : mpls traffic-eng reoptimize events link-up mpls traffic-eng reoptimize timers [delai] [frequence] o events link-up : Initie la réoptimisation du tunnel MPLS-TE lors de la réception d un message de nouvelle adjacence IGP. o timers [frequence] : Fréquence de réoptimisation périodique 48

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

58 Choix des solutions et faisabilité Exemple de configuration : interface Gi 2/0 mpls traffic-eng flooding thresholds up 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 Mode d annonce du tunnel dans le routage interne Les tunnels MPLS-TE peuvent être annoncés dans le routage interne d un réseau de différentes manières. Le choix du type d annonce va influer sur la manière de faire circuler du trafic dans ces tunnels (voir 2.2.5). Aucune annonce dans l IGP C est le comportement par défaut des tunnels MPLS-TE. Ceux-ci ne sont pas annoncés dans l IGP, il faudra alors spécifier des routes statiques via le tunnel pour des une adresse ou un préfixe IP. Exemple de configuration : P4(config)#ip route tunnel 1 Résultat dans la table de routage : S /24 is directly connected, Tunnel1 50

59 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 : Ou La métrique cumulée du chemin traversé. 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 [ ] /8 is variably subnetted, 24 subnets, 2 masks I L /24 [115/10] via , Tunnel1 I L /24 [115/30] via , GigabitEthernet1/0 I L /24 [115/30] via , GigabitEthernet1/0 I L /24 [115/20] via , GigabitEthernet1/0 I L /24 [115/10] via , Tunnel1 I L /24 [115/10] via , 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 51

60 Choix des solutions et faisabilité 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 Tunnel 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 L /24 [115/18] via , Tunnel1 I L /24 [115/28] via , Tunnel1 I L /24 [115/20] via , GigabitEthernet1/0 P7#sh ip route I L /32 [115/18] via , GigabitEthernet4/0 Le tunnel est déclaré dans la table de routage avec un poids ISIS égal à 8. La table de routage du routeur P7 à bien pris en compte ce nouveau lien dans ses calculs de plus court chemin 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. 52

61 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 Protection globale bidirectionnel P4-P2 Tunnel MPLS TE bidirectionnel P4-P2 Figure 25 Exemple de protection globale d un tunnel MPLS-TE Sur le routeur de tête du tunnel MPLS-TE à protéger, il faut d abord configurer un chemin explicite pour le tunnel de protection : ip explicit-path name Tunnel_1_sec enable next-address next-address

62 Choix des solutions et faisabilité Configuration d un tunnel de protection globale pour un tunnel MPLS-TE : interface tunnel 1 tunnel mpls traffic-eng path-option protect 1 explicit name Tunnel_1_sec o Protect 1 : Il est possible de déclarer jusqu à 8 tunnels de protection globale, identifiés par niveau de priorité. o Name Tunnel_1_sec : Chemin explicite du tunnel de protection globale. En situation nominale, le tunnel MPLS-TE primaire est en service, celui de protection globale est en attente. Il est également signalé et réserve des ressources dans la topologie TE : P4#sh mpls traffic-eng tunnels tunnel 1 Name: P4_t1 (Tunnel1) Destination: Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type explicit Tunnel_1_pri (Basis for Setup, path weight 15) Path Protection: 0 Common Link(s), 0 Common Node(s) path protect option 1, type explicit Tunnel_1_sec (Basis for Protect, path weight 21) [ ] Sont indiqués ci-dessus : o Le chemin de protection globale choisi et son poids. o Le nombre de liens et de nœuds communs entre le chemin nominal et le chemin de protection globale. P4#sh mpls traffic-eng tunnels tunnel 1 protection P4_t1 LSP Head, Tunnel1, Admin: up, Oper: up Src , Dest , Instance 141 Fast Reroute Protection: None Path Protection: 0 Common Link(s), 0 Common Node(s) Primary lsp path: Protect lsp path: [ ] 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é). 54

63 Lors de la phase d établissement, le tunnel de secours ne s établi qu après le primaire. On ne peut donc pas redémarrer le tunnel ou changer sa configuration lorsque celui-ci est en mode dégradé. Les évènements déclencheurs d une bascule sur le tunnel de protection globale sont les suivants : Erreur d établissement du tunnel MPLS-TE primaire (via signalisation RSVP-TE). Notification de perte d adjacence via l IGP, RSVP Hello, «Bidirectional Forwarding Detection» (BFD). Préemption des ressources TE par un tunnel aux priorités plus importantes. Lorsque le tunnel TE primaire est hors service, celui de protection globale devient actif : P4#sh mpls traffic-eng tunnels tunnel 1 Name: P4_t1 (Tunnel1) Destination: Status: Admin: up Oper: up Path: valid Signalling: connected path protect option 1, type explicit Tunnel_1_sec (Basis for Protect, path weight 21) path option 1, type explicit Tunnel_1_pri Path Protection: Backup lsp in use. Path protect option 1, type explicit Tunnel_1_sec (Basis for Protect, path weight 21) P4#sh mpls traffic-eng tunnels tunnel 1 protection P4_t1 LSP Head, Tunnel1, Admin: up, Oper: up Src , Dest , Instance 79 Fast Reroute Protection: None Path Protection: Backup lsp in use. Mesure du temps de convergence du chemin de protection globale : Ci-dessous, test de coupure de tunnel TE. Une trace de ping entre les deux machines QEMU dont le trafic circule via le tunnel TE. Sending 100, 100-byte ICMP Echos to , 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 , timeout is 2 seconds:!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 55

64 Choix des solutions et faisabilité!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 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» 56

65 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. Tunnel Fast-Reroute NHOP P8-P3 Tunnel Fast-Reroute NNHOP P8-P Tunnel MPLS TE bidirectionnel P4-P2 Figure 28 Exemple de protection FRR d un tunnel MPLS-TE La procédure de création de tunnels de protection locale FRR est : (1) Activer le FRR dans la configuration du tunnel TE sur le routeur de tête : interface tunnel 1 tunnel mpls traffic-eng fast-reroute 57

66 Choix des solutions et faisabilité (2) Création du tunnel de protection de lien (NHOP) ou de nœud (NNHOP) sur le routeur P8 en amont du lien / nœud à protéger : interface Tunnel 100 ip unnumbered Loopback1 tunnel destination tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name Tunnel_100_frr o tunnel destination : pour du NHOP o tunnel destination : 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 ou 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 : Pour une protection de lien, spécifier l adresse ip du lien à exclure (adresse de l interface du routeur). o exclude-address : 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). 58

67 Détails d une session «RSVP Hello» entre P8 et P3 : P8#sh ip rsvp hello client nbr detail Hello Client Neighbors Remote addr , Local addr 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 [14] 34 Gi2/0:33 Tu100:33 ready On voit ci-dessus que le tunnel 1 de P4 est pris en compte par un tunnel de FRR. On peut également noter les labels MPLS en situation nominale et en situation de FRR. P4#sh mpls traffic-eng tunnels tunnel 1 protection P4_t1 LSP Head, Tunnel1, Admin: up, Oper: up Src , Dest , Instance 14 Fast Reroute Protection: Requested [ ] Du point de vue de P4, la protection FRR est demandée. Le tunnel sera éligible au FRR dans la topologie. En situation de défaut du lien ou nœud protégé, la session RSVP Hello n est plus active, le défaut est alors détecté et le Fast Reroute activé : P8#sh mpls traffic-eng fast-reroute database Headend frr information: Protected tunnel In-label Out intf/label FRR intf/label Status LSP midpoint frr information: LSP identifier In-label Out intf/label FRR intf/label Status [14] 34 Gi2/0:33 Tu100:33 active 59

68 Choix des solutions et faisabilité Du point de vue du routeur de tête du tunnel P4, l information du FRR le long du chemin est transmise sans que cela n impacte l état du tunnel : P4#sh mpls traffic-eng tunnels tunnel 1 Name: P4_t1 (Tunnel1) Destination: Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type explicit Tunnel_1_pri (Basis for Setup, path weight 5) Change in required resources detected: reroute pending L information de reroutage est transmise au routeur de tête du tunnel TE. Une réoptimisation pourra être lancée pour trouver un meilleur chemin. La création des tunnels de protection FRR d un lien ou d un nœud peut également être effectuée automatiquement via la configuration suivante : Configuration générale du routeur : mpls traffic-eng auto-tunnel backup mpls traffic-eng auto-tunnel backup nhop-only mpls traffic-eng auto-tunnel backup tunnel-num [min num] [max num] mpls traffic-eng auto-tunnel backup timers removal unused sec mpls traffic-eng auto-tunnel backup config affinity affinity-value [mask mask-value] o auto-tunnel backup : Active la protection FRR automatique. o auto-tunnel backup nhop-only : exclu la création de tunnels FRR NNHOP. o auto-tunnel backup tunnel-num [min num] [max num] : identifiant mini et maxi des tunnels FRR. o auto-tunnel backup timers removal unused sec : temps avant qu un tunnel FRR automatique non utilisé soit supprimé. o auto-tunnel backup config affinity affinity-value [mask mask-value] : précise l affinité des tunnels FRR automatiques. Dans la maquette de test, nous n avons pas pu voir de différence significative sur les temps de convergence après défaillance entre les modes de protection globale et de protection locale FRR. Cependant, le nombre de sauts et la charge de notre maquette est limitée, et toutes les références à ce sujet concordent sur le fait que le mode de protection Fast-Reroute fournit une convergence plus rapide que le mode de protection globale. Notamment parce qu il ne dépend pas des délais de propagation dans le réseau. Aussi, il est préconisé dans le cas de trafics à forte contraintes de QoS tels que de la voix ou de la téléphonie sur IP. 60

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

70 Choix des solutions et faisabilité Pseudo-Wire Dirigé dans tunnel TE P Tunnel TE Mapping VLAN ID vers VC ID Mapping VC ID vers VLAN ID Vlan 2000 VC 222 Nuage MPLS-TE VC 222 Vlan 2000 CE 1 PE 1 PE 2 CE 2 Figure 29 L2VPN Pseudo-Wire dirigé dans un tunnel MPLS-TE P Exemple de configuration : pseudowire-class L2VPN encapsulation mpls preferred-path interface Tunnel1 [disable-fallback] En cas de panne du tunnel TE, le L2VPN utilise le routage standard IGP. L option *disablefallback] 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/ up, line protocol up, Eth VLAN 2000 up Destination address: , 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. 62

71 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 2 Peering ebgp PE2 Tunnels TE RR PE 1 PE 3 CE 1 CE 3 Figure 30 Utilisation de tunnels TE avec des L3VPN MPLS La procédure est de configuration est : 1. Créations une loopback L (non 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. 63

72 Choix des solutions et faisabilité Exemple de configuration : Sur PE1 1 interface Loopback2 ip address Sur PE3 interface Loopback2 ip address ip vrf RED rd 2200:2 route-target export 2200:2 route-target import 2200:2 bgp next-hop Loopback2 3 ip route tunnel 1 ip route tunnel 1 Résultat dans les tables de routage : S /32 is directly connected, Tunnel1 S /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. 64

73 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 Cisco IOS XR Software, Version Cisco CRS-1 Cisco IOS XR Software, Version 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 Chassis IOS Extension IS-IS TE MPLS-Traffic Engineering Auto bandwidth IGP / TE metric Fast Reroute (FRR) Path Protection Autoroute Announce Forwarding Adjacency 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 : Partage de charge Diff-Serv-Aware (DS-TE) CoS Tunnel Selection 7609 v12.2(33)sre3 650X v12.2(33)sxj 650X v12.2(18)sxf12a IOS XR v3.9.1 CRS-1 IOS XR v4.0.1 Fonctionnalités vérifiées avec des IOS Advance Enterprise Services L2VPN : Tunnel Selection 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é. 65

74 Généralisation et Déploiement 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. 66

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

76 Généralisation et Déploiement Les graphes suivants représentent la quantité de trafic écoulée, en Gigabit par secondes, sur la période de Janvier à mai Figure 32 Liaison primaire RENATER / GEANT saturée Figure 33 Liaison de secours RENATER/GEANT utilisée provisoirement Figure 34 Liaison Lyon1 Genève, déjà utilisée par le LHCONE Figure 35 Liaison Grenoble Genève inutilisée 68

77 Les propositions de chemins principaux et secondaires sont les suivantes : Figure 36 Chemins principaux LHCONE L2VPN TE 69

78 Généralisation et Déploiement Figure 37 Proposition de chemins secondaires LHCONE L2VPN TE 70

79 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, et 7200) et nous n avons pas pu valider nos tests sur les plateformes 6500 et CRS-1, essentiels au fonctionnement de RENATER (Cf ). 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. 71

80 Généralisation et Déploiement 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). 72

81 Nom du test Planning prévisionnel Configuration initiale Jour 1 Test 1. IPv4 and IPv6 configuration Jour 1 Test 2. ECMP and LAG configuration Jour 1 Test 3. ISIS configuration Jour 1 Test 4. MPLS configuration Jour 1 Test 5. Injectors capabilities overview (IXIA) Jour 1 Test 6. BGP configuration Jour 1 Test 7. Multicast configuration Jour 1 Test 8. BFD for ISIS Jour 1 Test 9. L2VPN VLAN Based Jour 1 Test 10. L3VPN MPLS-VPN: Any to any VRF Jour 1 Test 11. 6VPE Jour 1 Validé 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 Test 26. Operation Administration and Maintenance (OAM) Semaine Semaine MPLS-TE Avancés Test 27. Full mesh Jour 5 100GE tests Test GE performance & stress test between CRS-2 and CRS-6. Jour 5 ASR-9000 intégration Test 29. ASR-9000 integration (ISIS, BGP, LDP, RSVP-TE ) Semaine 73

82 Généralisation et Déploiement ASR Traffic Injector Traffic Injector - 3 Full routing BGP 70 isis adjacency CRS 2 CRS 6 LACP LACP Traffic injector CRS1 7604S 12K 6504-E ASR 9000 Ethernet 100Gb Ethernet 10Gb Ethernet 1Gb Traffic Injector - 2 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. 74

83 5.3.2 Protocole de test défini Le protocole général de test et de validation, pour tous les tests suit le cycle suivant : 1 - Test unitaire numéro X 4 - Le rapporteur des tests consigne les résultats et archive les sauvegardes 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 Figure 39 Protocole de rapport des tests CPOC Chaque test est organisé suivant les points : Objectifs : Description brève des objectifs fonctionnels du test et des résultats attendus. Conditions : Prérequis matériels, protocolaires. Description du déroulement du test. Configuration : Configuration complète des routeurs pour le test. Résultats : Traces de routeurs, tests de performance. Commentaires et recommandations. 75

84 Généralisation et Déploiement 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 , , and CRS-2 seront les têtes (HEAD-END) de 3 tunnels aux chemins suivants : Tunnel 1018 : CRS Tunnel 1014 : CRS Tunnel 1028 : CRS-2 CRS 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. 76

85 ASR Traffic Injector Tunnel 1018/1081 Traffic Injector - 3 Full routing BGP Tunnel 1014/1041 Tunnel 1028/1082 CRS1 2 CRS1 6 LACP LACP & Traffic Injector - 2 Figure 40 Topologie de l exemple «Etablissement de tunnel TE à chemin explicite» Configurations! Pour CRS-2! explicit-path name CRS index 10 next-address strict ipv4 unicast index 20 next-address strict ipv4 unicast index 30 next-address strict ipv4 unicast ! interface tunnel-te 1028 description TUNNEL TE1028 CRS ipv4 unnumbered Loopback2 load-interval 30 destination path-option 10 explicit name CRS ! 77

86 Généralisation et Déploiement! Pour ! explicit-path name index 10 next-address strict ipv4 unicast index 20 next-address strict ipv4 unicast ! explicit-path name CRS-2 index 10 next-address strict ipv4 unicast index 20 next-address strict ipv4 unicast index 30 next-address strict ipv4 unicast ! interface tunnel-te 1081 description TUNNEL TE ipv4 unnumbered Loopback2 load-interval 30 destination path-option 10 explicit name ! interface tunnel-te 1082 description TUNNEL TE CRS-2 ipv4 unnumbered Loopback2 load-interval 30 destination path-option 10 explicit name CRS-2!! Pour ! interface Tunnel 1018 description TUNNEL TE ip unnumbered Loopback2 load-interval 30 tunnel destination tunnel mode mpls traffic-eng tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 10 explicit name ! interface Tunnel 1014 description TUNNEL TE ip unnumbered Loopback2 load-interval 30 tunnel destination tunnel mode mpls traffic-eng tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 10 explicit name ! ip explicit-path name enable index 10 next-address index 20 next-address ! ip explicit-path name enable index 10 next-address index 20 next-address !! Pour ! interface Tunnel 1041 description TUNNEL TE ip unnumbered Loopback2 load-interval 30 tunnel destination

87 tunnel mode mpls traffic-eng tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 10 explicit name ! ip explicit-path name enable index 10 next-address index 20 next-address ! 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 et CRS #sh mpls traffic-eng tunnels tunnel 1018 Name : TUNNEL TE (Tunnel1018) Destination : Status: Admin: up Oper: up Path: valid Signalling: connected path option 10, type explicit (Basis for Setup, path weight 25) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute announce: disabled LockDown: disabled Loadshare: 100 bw-based auto-bw: disabled Active Path Option Parameters: State: explicit path option 10 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : - OutLabel : TenGigabitEthernet1/4, Next Hop : RSVP Signalling Info: Src , Dst , Tun_Id 1018, Tun_Instance 1 RSVP Path Info: My Address: Explicit Route: Record Route: NONE Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 25 (TE) Explicit Route: History: Tunnel: Time since created: 7 minutes, 41 seconds Time since path change: 6 minutes, 55 seconds Number of LSP IDs (Tun_Instances) used: 1 Current LSP : [ID : 1] Uptime : 6 minutes, 55 seconds RP/0/RP0/CPU0 :CRS-2#sh mpls traffic-eng tunnels 1028 Name : tunnel-te1028 Destination : Status: Admin: up Oper: up Path: valid Signalling: connected path option 10, type explicit CRS (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: (00:14:43 ago) Config Parameters: 79

88 Généralisation et Déploiement Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff Metric Type: TE (default) Hop-limit: disabled AutoRoute: disabled LockDown: disabled Policy class: not set Forwarding-Adjacency: disabled Loadshare: 0 equal loadshares Auto-bw: disabled Fast Reroute: Disabled, Protection Desired: None Path Protection: Not Enabled History: Tunnel has been up for: 00:14:43 (since Mon May 07 23:15:21 UTC 2012) Current LSP: Uptime: 00:14:43 (since Mon May 07 23:15:21 UTC 2012) Path info (IS-IS 2200 level-1): Hop0: Hop1: Hop2: Hop3: Hop4: 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: UTC Path CRS status enabled 0xa: next-address strict x14: next-address strict x1e: next-address strict Tests de «traceroute» entre les routeurs CRS-2 et , pour les chemins fixés par l IGP et par le tunnel TE RP/0/RP0/CPU0:CRS-2#traceroute Tracing the route to [MPLS: Label Exp 0] 37 msec 20 msec 13 msec [MPLS: Label 30 Exp 0] 15 msec 13 msec 5 msec 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 MRU 9180 [Labels : Exp : 0]. 1 * L MRU 9214 [Labels : 118 Exp : 0] 192 ms L MRU 9204 [Labels: implicit-null Exp: 0] 202 ms! 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. 80

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

90 Généralisation et Déploiement 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 T1 T2 T3 T4 T5 T6 T7 T8 Etat actuel Activation d ISIS-TE sur 1 routeur de chaque type. Création d un tunnel MPLS-TE de test, sous surveillance pendant 2 semaines. Rédaction de la procédure de déploiement et d exploitation Formation des équipes de BT à ces procédures. Activation d ISIS-TE sur tous les routeurs. Création des tunnels TE pour le site LHCONE de Nantes suivant les chemins définis en 5.2. Bascule des L2VPN LHCONE dans les tunnels MPLS-TE. Création des tunnels TE entre Lyon1 et Genève, puis bascule du L2VPN-PW LHCONE. Eventuelles pertes de paquets sur les L2VPN, opération effectuée en HNO. 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. Règles de nomenclature et de numérotation, règles de configurations, procédure de dépannage. Quatre formations de 3h. Eventuelles pertes de paquets sur les L2VPN, opération effectuée en HNO, et suivant un planning de migration progressif. 2 à 3 routeurs/j. 20 jours de travail pour le NOC RENATER. Aucun effet sur le trafic de production. Eventuelles pertes de paquets sur les L2VPN. Opération effectué en journée et en coordination avec les responsables des sites concernés. Séparation du trafic GEANT standard et LHCONE. 82

91 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 83

92 Résultats et discussion 6 Résultats et discussion 6.1 Résultats du projet Nous présentons dans cette partie deux résultats : Le fonctionnement des L2VPN-TE entre le site LHCONE de NANTES / Paris 1 et Lyon 1. La nouvelle infrastructure déployée entre RENATER et GEANT à Genève (cf 5.2), et les 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. 84

93 (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). 85

94 Résultats et discussion 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. 86

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

96 Résultats et discussion 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. 88

97 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 Figure 8 - Exemple de topologie TE stratégique : topologie logique Figure 9 - Tunnels TE tactique : Exemple de répartition entre les routeurs A et C Figure 10 - Complexité du contrôle des architectures MPLS-TE Figure 11 Algorithme de sélection du chemin dynamique CSPF en trois phases Figure 12 Exemple d établissement de LSP-TE par RSVP-TE Figure 13 LHCOPN, échanges hiérarchiques des données avec les T Figure 14 LHCONE, échanges distribués des données entre les T Figure 15 Infrastructure RENATER dédiée «LHCONE France» Figure 16 Tiers 1, 2 et 3 du réseau LHCONE sur RENATER Figure 17 - Exemple de L2VPN-PW orienté par de l ingénierie de trafic Figure 18 Topologie métropolitaine de RENATER Figure 19 Les différents types de L2VPN-PW dans RENATER Figure 20 L2VPN-PW dans une architecture MPLS Figure 21 Encapsulation d une trame Ethernet taguée 802.1Q Figure 22 L3VPN sur VRF «VERTE» - Peering ebgp et ibgp sur Route Reflector Figure 23 Architecture de test mise en place via Dynamips/GNS Figure 24 Tunnel MPLS-TE à chemin explicite Figure 25 Exemple de protection globale d un tunnel MPLS-TE Figure 26 Tunnel de protection «Next Hop» Figure 27 Tunnel de protection «Next Next Hop» Figure 28 Exemple de protection FRR d un tunnel MPLS-TE Figure 29 L2VPN Pseudo-Wire dirigé dans un tunnel MPLS-TE Figure 30 Utilisation de tunnels TE avec des L3VPN MPLS Figure 31 Architecture cible sites Tiers 2 / FR LHCONE 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 Figure 36 Chemins principaux LHCONE L2VPN TE Figure 37 Proposition de chemins secondaires LHCONE L2VPN TE Figure 38 Topologie du CPOC RENATER Figure 39 Protocole de rapport des tests CPOC Figure 40 Topologie de l exemple «Etablissement de tunnel TE à chemin explicite».. 77 Figure 41 Weathermap d exploitation LHCONE Figure 42 Supervision du L2VPN-TE du site LHCONE de Nantes

98 Appendices 7.2 Références RFC IS-IS [RFC1195] MPLS [RFC3031] LDP [RFC5036] L3VPN MPLS [RFC2547] CR-LDP [RFC3468] en status «informationnal» MPLS-TE [RFC2702] IS-IS-TE [RFC5305] OSPF-TE [RFC3630] RSVP-TE [RFC3209] Bibliographie [1] https ://indico.cern.ch/getfile.py/access?contribid=1&resid=1&materialid=slide s&confid= [2] Jean-Louis Mélin, Qualité de service sur IP, Eyrolles. [3] J.M. Bonnin, ENST, MPLS, techniques de l ingénieur, 18p. Christophe Fillot, Implémentation Mpls avec 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. Bande passante automatique des tunnels TE. Métriques TE/IGP des tunnels MPLS-TE. Protection locale FRR des tunnels TE avec BFD. Protection globale des tunnels TE. Annonce des tunnels TE à l ensemble des routeurs de l IGP. Tunnels TE, primaire ou de secours automatiques. Diffserv Aware TE http ://www.cisco.com/en/us/docs/ios/12_0s/fea ture/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_2s/fea ture/guide/fsmetric.pdf guration/guide/mp_link_node_prot.pdf http ://www.cisco.com/en/us/docs/ios/mpls/confi guration/guide/mp_te_path_prot.pdf guration/guide/mp_te_fwd_adjacency.pdf http ://www.cisco.com/en/us/docs/ios/12_0s/fea ture/guide/gsmeshgr.pdf ure/guide/fsdserv3.pdf 90

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

100 Annexes 8.4 Base d exploitation des tunnels TE 92

Service de VPN de niveau 2 sur RENATER

Service de VPN de niveau 2 sur RENATER Service de VPN de niveau 2 sur RENATER Documentation SSU-DOC-L2VPN-RENATER_FR.doc 1 / 13 Table des matières 1 Introduction... 3 2 A qui s adresse ce document... 3 3 Vue d ensemble... 3 4 Service L2VPN

Plus en détail

Service de VPN de niveau 3 sur RENATER (L3VPN MPLS)

Service de VPN de niveau 3 sur RENATER (L3VPN MPLS) Service de VPN de niveau 3 sur (L3VPN MPLS) Documentation 1 / 14 Table des matières Suivi des Services aux Usagers 1 Introduction... 3 2 A qui s adresse ce document... 3 3 Vue d ensemble... 3 4 Descriptions

Plus en détail

GUILLON Samuel ROBIN David FI/FP 2005. RSVP-TE Ressource Reservation Protocol Traffic Engineering

GUILLON Samuel ROBIN David FI/FP 2005. RSVP-TE Ressource Reservation Protocol Traffic Engineering GUILLON Samuel ROBIN David FI/FP 2005 RSVP-TE Ressource Reservation Protocol Traffic Engineering OPTION RIO : RÉSEAUX ET INTERCONNEXIONS D ORDINATEURS 2004 Index 1 MPLS MultiProtocol Label Switching...3

Plus en détail

MPLS. AFNOG 2011 Brice Dogbeh-Agbo

MPLS. AFNOG 2011 Brice Dogbeh-Agbo MPLS AFNOG 2011 Brice Dogbeh-Agbo Mécanismes de base du routage IP Se repose sur les information fournies par les protocoles de routage de la couche réseau dynamique ou statique. Décision de transmission

Plus en détail

RENATER Service Accès Partenaire au RIE

RENATER Service Accès Partenaire au RIE RENATER Service Accès Partenaire au RIE Documentation Service Accès Partenaire au RIE via RENATER 1 / 13 Table des matières 1 Vue d ensemble... 3 2 Objet... 3 3 A qui s adresse ce document... 3 4 Descriptif

Plus en détail

Multi-Protocol Label Switching (MPLS)

Multi-Protocol Label Switching (MPLS) Multi-Protocol Label Switching (MPLS) Aude LE DUC 2008-2009 Les Environnements IP 1 Plan Principes Protocoles de distribution des labels Qualité de Service (Quality of Service QoS) Protections avec MPLS

Plus en détail

MPLS. Plan. Introduction Architecture MPLS Protocoles de signalisation. Nguyen Thi Mai Trang LIP6/PHARE Thi-Mai-Trang.Nguyen@lip6.

MPLS. Plan. Introduction Architecture MPLS Protocoles de signalisation. Nguyen Thi Mai Trang LIP6/PHARE Thi-Mai-Trang.Nguyen@lip6. MPLS Nguyen Thi Mai Trang LIP6/PHARE Thi-Mai-Trang.Nguyen@lip6.fr 01/10/2009 Master 2 - UPMC - UE RCG 1 Plan Introduction Architecture MPLS Protocoles de signalisation 01/10/2009 Master 2 - UPMC - UE RCG

Plus en détail

Vers un réseau déterministe

Vers un réseau déterministe Vers un réseau déterministe 1ere partie : Généraliste: Notions et définitions 2eme partie et 3eme partie : - MPLS et compagnie (RSVP, OSPF, BGP, TE, FR, VPLS...) - Topologie : Intégration du paramètre

Plus en détail

Réseau de campus de l USTL

Réseau de campus de l USTL Réseau de campus de l USTL Le réseau de campus est commun aux 5 établissements du DUSVA (Domaine Universitaire Scientifique de Villeneuve d'ascq): - USTL - ENIC - ENSCL - EC-Lille - IEMN Quelques chiffres:

Plus en détail

Routage dynamique et protocoles de routage. Claude Chaudet Xavier Misseri

Routage dynamique et protocoles de routage. Claude Chaudet Xavier Misseri Routage dynamique et protocoles de routage Claude Chaudet Xavier Misseri Principe du routage Configurer les tables de routage (des routeurs) afin que les paquets empruntent le meilleur chemin disponible

Plus en détail

Formation SIARS. Principes de base TCP/IP QoS

Formation SIARS. Principes de base TCP/IP QoS Formation SIARS Principes de base TCP/IP QoS Plan La situation actuelle Qu est-ce que la QoS? DiffServ IntServ MPLS Conclusion La situation actuelle La situation actuelle La famille des protocoles TCP/IP

Plus en détail

Routage dans l Internet Partie 3 (BGP)

Routage dans l Internet Partie 3 (BGP) Topologie Internet Routage dans l Internet Partie 3 () EGP IGP Isabelle CHRISMENT ichris@loria.fr Avec des supports de Nina Taft (Sprint) et Luc Saccavini (INRIA Grenoble) Internal Gateway Protocol : utiliser

Plus en détail

TD : Négociation de service avec MPLS. 1. Principes de fonctionnement de l architecture

TD : Négociation de service avec MPLS. 1. Principes de fonctionnement de l architecture TD : Négociation de service avec MPLS 1. Principes de fonctionnement de l architecture Dans les réseaux IP classiques, le routage n utilise que le préfixe de destination pour trouver le prochain saut.

Plus en détail

Spécifications de raccordement au service de Téléphonie sur IP (ToIP) de RENATER

Spécifications de raccordement au service de Téléphonie sur IP (ToIP) de RENATER Spécifications de raccordement au service de Téléphonie sur IP (ToIP) de RENATER Documentation Auteurs: Simon Muyal SSU-SPEC-ToIP_FR_20101221.doc 1 / 20 Table des matières 1 Sommaire... 4 2 A qui s adresse

Plus en détail

MPLS. Multiprotocol Label Switching

MPLS. Multiprotocol Label Switching MPLS Multiprotocol Label Switching Préparé par: Ayoub SECK Ingénieur-Chercheur en Télécommunications Spécialiste en Réseaux IP et Télécoms mobiles Certifié: JNCIA, CCNP,CCDP Suggestions: seckayoub@gmail.com

Plus en détail

Interconnexion des réseaux - Routage

Interconnexion des réseaux - Routage Interconnexion des réseaux - Routage Concept de l interconnexion Équipement de la couche 3 - Domaine de broadcast Détermination du chemin Routage Table de routage Algorithmes de routage statiques et dynamiques

Plus en détail

Architectures de QoS pour Internet

Architectures de QoS pour Internet Architectures de QoS pour Internet IntServ, Diffserv 2011 RMMQoS-chap5 1 Architecture Intserv Intégration de Service définie en 1997 dans les RFC2205 à RFC2216 définie par flux (ex : IP src + IP dst +

Plus en détail

Introduction à MPLS F. Nolot 2009 1

Introduction à MPLS F. Nolot 2009 1 Introduction à MPLS 1 Introduction à MPLS Introduction 2 Introduction Les fournisseurs d'accès veulent Conserver leur infrastructure existante ET Ajouter de nouveaux services non supportés par la technologie

Plus en détail

Objectifs du chapitre

Objectifs du chapitre Objectifs du chapitre L objectif de ce chapitre est de faire le point sur les conséquences d IPv6 en matière de routage. Nous verrons donc les modifications apportées par IPv6 sur les paramétrages de routage

Plus en détail

Routage IP: Protocoles. Page 1. 1994: création Bernard Tuy Modifications. 1995 Bernard Tuy 1997 Bernard Tuy 1998 Bernard Tuy

Routage IP: Protocoles. Page 1. 1994: création Bernard Tuy Modifications. 1995 Bernard Tuy 1997 Bernard Tuy 1998 Bernard Tuy Routage IP: Protocoles 1994: création Bernard Tuy Modifications 1995 Bernard Tuy 1997 Bernard Tuy 1998 Bernard Tuy Page 1 Plan Les protocoles de Routage IP Généralités RIP (2) IGRP OSPF EGP (2) BGP CIDR

Plus en détail

Les MPLS (Multiprotocol Label Switching) VPNs (Virtual Private Network) sont de

Les MPLS (Multiprotocol Label Switching) VPNs (Virtual Private Network) sont de Abstract Les MPLS (Multiprotocol Label Switching) VPNs (Virtual Private Network) sont de nouvelles alternatives pour sécuriser et améliorer le WANs (Wide Area Network). De plus en plus ils gagnent du terrain

Plus en détail

BAC PRO Système Electronique Numérique. Nom : Le routage Date : LE ROUTAGE

BAC PRO Système Electronique Numérique. Nom : Le routage Date : LE ROUTAGE 1. Sommaire LE ROUTAGE 1. Sommaire... 1 2. Un routeur, pour quoi faire?... 1 3. Principe de fonctionnement du routage.... 2 4. Interfaces du routeur... 3 4.1. Côté LAN.... 3 4.2. Côté WAN.... 3 5. Table

Plus en détail

L architecture IP VPN de TRANSPAC

L architecture IP VPN de TRANSPAC TEP de Veille technologique no?? 2002-2003 Les valeureux travailleurs :p L architecture IP VPN de TRANSPAC Table des matières 1 Introduction à Transpac 4 1.1 Présentation générale.............................

Plus en détail

Approche en Ligne pour une Gestion Autonome et Décentralisée des Réseaux MPLS-DiffServ

Approche en Ligne pour une Gestion Autonome et Décentralisée des Réseaux MPLS-DiffServ Approche en Ligne pour une Gestion Autonome et Décentralisée des Réseaux MPLS-DiffServ Rana Rahim-Amoud, Leïla Merghem-Boulahia, Dominique Gaïti rana.amoud@utt.fr Institut Charles Delaunay (ICD FRE CNRS

Plus en détail

Hypervision et pilotage temps réel des réseaux IP/MPLS

Hypervision et pilotage temps réel des réseaux IP/MPLS Hypervision et pilotage temps réel des réseaux IP/MPLS J.M. Garcia, O. Brun, A. Rachdi, A. Al Sheikh Workshop autonomique 16 octobre 2014 Exemple d un réseau opérateur national 8 technologies : 2G / 3G

Plus en détail

Multi-Domain VPN service, une infrastructure sans couture pour les re seaux re gionaux, NRENs et GEANT

Multi-Domain VPN service, une infrastructure sans couture pour les re seaux re gionaux, NRENs et GEANT Multi-Domain service, une infrastructure sans couture pour les re seaux re gionaux, NRENs et Auteurs : Xavier Jeannin (RENATER), Alain Bidaud (SYRHANO), Sebastien Boggia (OSIRIS), Jean Benoit (OSIRIS),

Plus en détail

Mise en place de raccordement fiabilisé pour les sites sur RAP

Mise en place de raccordement fiabilisé pour les sites sur RAP Mise en place de raccordement fiabilisé pour les sites sur RAP Description : Ce document présente les services de raccordement fiabilisé pour les sites sur RAP. Version actuelle : 1.4 Date : 15/09/09 Auteur

Plus en détail

Covage Services Version du doc v1.1. Spécifications techniques d accès au Service. Page 1 sur 11

Covage Services Version du doc v1.1. Spécifications techniques d accès au Service. Page 1 sur 11 Covage s Version du doc v1.1 Page 1 sur 11 Document : Date : STAS IP Transit v1.1 20/09/2011 Covage s Version du doc v1.1 Page 2 sur 11 Sommaire 1. Description du «IP Transit»... 3 2. Périmètre géographique

Plus en détail

L architecture IP VPN de TRANSPAC

L architecture IP VPN de TRANSPAC TEP de Veille technologique 2002-2003 Baillou Gilles * Ficheau Fabien * Mizzi Arnaud L architecture IP VPN de TRANSPAC Table des matières 1 Introduction à Transpac 3 2 Les VPNs 6 2.1 Qu est-ce qu un VPN.............................

Plus en détail

Cours réseaux Modèle OSI

Cours réseaux Modèle OSI Cours réseaux Modèle OSI IUT 1 Université de Lyon Introduction: le modèle OSI Un modèle théorique : le modèle OSI (Open System Interconnection) A quoi ça sert: Nécessité de découper/classifier l ensemble

Plus en détail

MPLS. Plan. Quel est le problème? Comment le résoudre en Théorie... Principe de MPLS. Architecture de réseaux MPLS. QoS et VPN. Farid Naït-Abdesselam.

MPLS. Plan. Quel est le problème? Comment le résoudre en Théorie... Principe de MPLS. Architecture de réseaux MPLS. QoS et VPN. Farid Naït-Abdesselam. MPLS Farid Naït-Abdesselam. Maître de Conférences Université des Sciences & Technologies de Lille. ENIC Telecom Lille 1 Tél.: +33 (0)3 20 43 64 01 E-mail: nait@enic.fr Web: http://www.lifl.fr /~nait 1

Plus en détail

Cours d histoire VPN MPLS. Les VPN MPLS B. DAVENEL. Ingénieurs 2000, Université Paris-Est Marne la Vallée. B. DAVENEL Les VPN MPLS

Cours d histoire VPN MPLS. Les VPN MPLS B. DAVENEL. Ingénieurs 2000, Université Paris-Est Marne la Vallée. B. DAVENEL Les VPN MPLS Les B. DAVENEL Ingénieurs 2000, Université Paris-Est Marne la Vallée B. DAVENEL Les Sommaire 1 2 3 4 B. DAVENEL Les Bibliographie PUJOLLE, Guy. Les réseaux, Quatrième édition, Eyrolles HARDY, Daniel. MALLEUS,

Plus en détail

Frame Relay. Introduction. Master 2 Professionnel STIC-Informatique Module RMHD 1

Frame Relay. Introduction. Master 2 Professionnel STIC-Informatique Module RMHD 1 Frame Relay Introduction Master 2 Professionnel STIC-Informatique Module RMHD 1 Introduction Les réseaux Frame Relay fournissent plus de fonctionnalités et de bénéfices que les connexions point-à-point

Plus en détail

PRINCIPES DU ROUTAGE IP PRINCIPES DU ROUTAGE IP IP ROUTING PRINCIPALS

PRINCIPES DU ROUTAGE IP PRINCIPES DU ROUTAGE IP IP ROUTING PRINCIPALS PRINCES DU ROUTAGE ROUTING PRINCALS securit@free.fr Slide n 1 TABLE DES MATIERES PLAN PROBLEMATIQUES PRINCES DU ROUTAGE PROTOCOLES DE ROUTAGE ROUTAGE STATIQUE ROUTAGE DYNAMIQUE DISTANT VECTOR vs LINK STATE

Plus en détail

La garantie de performance dans les réseaux TCP/IP

La garantie de performance dans les réseaux TCP/IP La garantie de performance dans les réseaux TCP/IP Olivier Bonaventure Groupe Infonet Institut d Informatique FUNDP Rue Grandgagnage 21, B 5000 Namur (Belgium) Email : Olivier.Bonaventure@info.fundp.ac.be

Plus en détail

Réseaux de communication Perspectives

Réseaux de communication Perspectives Réseaux de communication Perspectives Martin Heusse FoilTEX 1 Perspectives & technologies récentes Utilisation directe du médium 1 Perspectives & technologies récentes Utilisation directe du médium Niveau

Plus en détail

Chapitre 6-2. Ce chapitre présente le IPv6 ainsi que les protocoles de routage

Chapitre 6-2. Ce chapitre présente le IPv6 ainsi que les protocoles de routage Chapitre 6-2 Ce chapitre présente le IPv6 ainsi que les protocoles de routage 1. Présentation de IPv6 1.2. Adressage v6; 1.5 Le format V6 1.3. Les types d adressage; 1.6 Fonctionnement Multicasting 1.4

Plus en détail

Covage Services Version du doc v1.1. Spécifications techniques d accès au Service. Page 1 sur 11

Covage Services Version du doc v1.1. Spécifications techniques d accès au Service. Page 1 sur 11 s Version du doc v1.1 Page 1 sur 11 Document : Date : STAS VPN IP v1.1 20/09/2011 s Version du doc v1.1 Page 2 sur 11 Sommaire 1. Description du «VPN IP»... 3 2. Périmètre géographique de l offre... 3

Plus en détail

Architecture de commutation d étiquettes multi protocoles

Architecture de commutation d étiquettes multi protocoles RFC3031 page - 1 - Rosen & autres Groupe de travail Réseau E. Rosen, Cisco Systems, Inc. Request for Comments : 3031 A. Viswanathan, Force10 Networks, Inc. Catégorie : En cours de normalisation R. Callon,

Plus en détail

M2 ESECURE. Réseaux Routage interne : OSPF. Jean SAQUET Pierre BLONDEAU

M2 ESECURE. Réseaux Routage interne : OSPF. Jean SAQUET Pierre BLONDEAU M2 ESECURE Réseaux Routage interne : OSPF Jean SAQUET Pierre BLONDEAU OSPF Open Shortest Path First : Protocole défini par l'ietf : RFC 2328 (OSPF v2), basé sur l'état des liens (Link State Algorithm)

Plus en détail

1. Introduction... 3 1.1. Les objectifs... 3 1.2. Matériels requis... 3

1. Introduction... 3 1.1. Les objectifs... 3 1.2. Matériels requis... 3 Licence Professionnelle Systèmes Automatisés et Réseaux Industriels. MPLS VPN TP pour la spécialité Administration de Réseaux Guillaume BRETON, Sylvain LECOMTE & Jonathan GAUDIN Le 4 février 2008 TP N

Plus en détail

Service de collecte xdsl sur SYRHANO. J-SR - 05/06/2009 Alain BIDAUD - CRIHAN

Service de collecte xdsl sur SYRHANO. J-SR - 05/06/2009 Alain BIDAUD - CRIHAN Service de collecte xdsl sur SYRHANO J-SR - 05/06/2009 Alain BIDAUD - CRIHAN Service de collecte xdsl sur SYRHANO Plan Réseau régional SYRHANO infrastructure les services aux utilisateurs Service de collecte

Plus en détail

Profil des participants Le cours CCNA Exploration s adresse aux participants du programme Cisco

Profil des participants Le cours CCNA Exploration s adresse aux participants du programme Cisco Présentation et portée du cours : CNA Exploration v4.0 Networking Academy Profil des participants Le cours CCNA Exploration s adresse aux participants du programme Cisco diplômés en ingénierie, mathématiques

Plus en détail

MPLS. Multi Protocol Label Switching Objectifs initiaux

MPLS. Multi Protocol Label Switching Objectifs initiaux MPLS Multi Protocol Label Switching Objectifs initiaux accélérer commutation IP «lenteur» de la commutation IP saut par saut Cell switching router (Toshiba 94), IP switching (Ipsilon 96), Tag switching

Plus en détail

Cours : Réseaux 3 Routage avancé

Cours : Réseaux 3 Routage avancé ons épartement de Télécommunicatio Dé Cours : Réseaux 3 Routage avancé Prof. A. Dahbi Cycle Ingénieur 2011 1 Objectifs Les objectifs sont : Décrire le rôle des protocoles de routage dynamique. Identifier

Plus en détail

Implémentation des classes de services dans RENATER-3

Implémentation des classes de services dans RENATER-3 Implémentation des classes de services dans RENATER-3 Franck SIMON GIP RENATER ENSAM 151 Boulevard de l Hôpital 75013 PARIS Franck.Simon@renater.fr 15 octobre 2003 Résumé Présentation des classes de service

Plus en détail

Spécifications Techniques de raccordement au Service Multicast FMbone-2 de Renater

Spécifications Techniques de raccordement au Service Multicast FMbone-2 de Renater Spécifications Techniques de raccordement au Service Multicast FMbone-2 de Renater Complément au document «Spécifications techniques d interconnexion des Réseaux régionaux et métropolitains à Renater 2»

Plus en détail

OSPF Routage intra-domaine

OSPF Routage intra-domaine OSPF Routage intra-domaine Bernard Cousin Plan Présentation de OSPF Le protocole OSPF Les aires de routage d'ospf Les phases d'ospf Les messages d'ospf Conclusion Open Shortest Path First 2 1 OSPF Un protocole

Plus en détail

Multihome BGP sur REVE

Multihome BGP sur REVE Objectifs initiaux: Multihome BGP sur REVE Le Réseau métropolitain d Évry Val d Essone (REVE) Favoriser le développement des communications «haut débit» d'établissements implantés à Évry Mutualiser la

Plus en détail

CONVENTION AVEC LES MAITRES D OUVRAGES DES RESEAUX DE COLLECTE

CONVENTION AVEC LES MAITRES D OUVRAGES DES RESEAUX DE COLLECTE CONVENTION AVEC LES MAITRES D OUVRAGES DES RESEAUX DE COLLECTE GIP RENATER 1/28 ENTRE LES SOUSSIGNES : GIP RENATER, dont le siège social est situé 151, Boulevard de l Hôpital, 75013 Paris, N SIRET 180

Plus en détail

Cours n 15. Frame Relay

Cours n 15. Frame Relay Cours n 15 Frame Relay 1 Frame Relay Technologie à commutation de paquets Remplace les réseaux point-à-point trop coûteux Se base sur l encapsulation HDLC Multiplexage (partage de la BP du nuage) Inconvénients

Plus en détail

Architecture pour la prise en compte des raccordements multiples

Architecture pour la prise en compte des raccordements multiples Architecture pour la prise en compte des raccordements multiples Description : Ce document présente l architecture, principalement basée sur le protocole de routage BGP, pour les raccordements multiples

Plus en détail

Plan. 1. Introduction. 1.1 Notion de réseau. Réseau extrémité. Le cœur du réseau. Les Protocoles de Télécommunications Evolution Internet Cours de DEA

Plan. 1. Introduction. 1.1 Notion de réseau. Réseau extrémité. Le cœur du réseau. Les Protocoles de Télécommunications Evolution Internet Cours de DEA Plan Les Protocoles de Télécommunications Evolution Internet Cours de DEA Isabelle CHRISMENT ichris@loria.fr Introduction Routage dans l Internet IPv6 Communication de groupes et l Internet x sans fils,

Plus en détail

Architecture Principes et recommandations

Architecture Principes et recommandations FFT Doc 09.002 v1.0 (Juillet 2009) Fédération Française des Télécommunications Commission Normalisation Groupe de travail Interconnexion IP Sous-groupe Architecture Architecture Principes et recommandations

Plus en détail

Réseaux Couche Réseau

Réseaux Couche Réseau Réseaux Couche Réseau E. Jeandel Partiel Mercredi 10 novembre 14h Salle 001 Tout le cours jusqu aujourd hui, compris Cours non autorisé 1 Un routeur Un routeur Un routeur relie plusieurs réseaux entre

Plus en détail

Le service IPv4 multicast pour les sites RAP

Le service IPv4 multicast pour les sites RAP Le service IPv4 multicast pour les sites RAP Description : Ce document présente le service IPv4 multicast pour les sites sur RAP Version actuelle : 1.2 Date : 08/02/05 Auteurs : NM Version Dates Remarques

Plus en détail

Multi Protocol Label Switching [NE520]

Multi Protocol Label Switching [NE520] AUFFRAY Guillaume SERRE Samuel THEVENON Julien P2004 IR Multi Protocol Label Switching [NE520] 1 / 10 Introduction Au début de l'internet, la préoccupation majeure était de transmettre les paquets de données

Plus en détail

Introduction. La gestion des qualités de services dans Internet. La garantie de QoS. Exemple

Introduction. La gestion des qualités de services dans Internet. La garantie de QoS. Exemple Introduction Aujourd hui les applications (en particulier multimédia) nécessitent des qualités de service de natures très différentes La gestion des qualités de services dans Internet Exemples: Transfert

Plus en détail

Vers un réseau MPLS Adaptatif. Rana Rahim-Amoud rana.amoud@utt.fr Leïla Merghem-Boulahia et Dominique Gaïti {Leila.boulahia, dominique.gaiti}@utt.

Vers un réseau MPLS Adaptatif. Rana Rahim-Amoud rana.amoud@utt.fr Leïla Merghem-Boulahia et Dominique Gaïti {Leila.boulahia, dominique.gaiti}@utt. Vers un réseau MPLS Adaptatif Rana Rahim-Amoud ranaamoud@uttfr Leïla Merghem-Boulahia et Dominique Gaïti {Leilaboulahia, dominiquegaiti}@uttfr Université de Technologie de Troyes (UTT) France 7ème Journées

Plus en détail

Couche réseau : autour d IP. Claude Chaudet

Couche réseau : autour d IP. Claude Chaudet Couche réseau : autour d IP Claude Chaudet 2 ICMP : Signalisation dans IP Positionnement et rôle d'icmp IP est, en soi, un mécanisme simple dédié à l'acheminement de trames Il ne définit pas de messages

Plus en détail

CHAPITRE 9 : LE ROUTAGE de PAQUETS ou DATAGRAMMES IP

CHAPITRE 9 : LE ROUTAGE de PAQUETS ou DATAGRAMMES IP CHAPITRE 9 : LE ROUTAGE de PAQUETS ou DATAGRAMMES IP I. Théorie : a. Objectif :.l adressage de niveau 3 permet de regrouper des interfaces physiques au sein de réseaux logiques..le routage permet, en fonction

Plus en détail

Renater-4. Renater-4

Renater-4. Renater-4 RENATER-4 Philippe d Anfray 6 Mars 2006 Philippe.d-Anfray@renater.fr Ecole Grid5000 Réseau National de Télécommunications pour la Technologie, l Enseignement et la Recherche. maîtrise d ouvrage du réseau;

Plus en détail

Services d infrastructure réseaux

Services d infrastructure réseaux Services d infrastructure réseaux Cours de Réseaux Tuyêt Trâm DANG NGOC Université de Cergy-Pontoise 2012-2013 Tuyêt Trâm DANG NGOC Services d infrastructure réseaux 1 / 30 Plan 1 Adressage

Plus en détail

Réseaux grande distance

Réseaux grande distance Chapitre 5 Réseaux grande distance 5.1 Définition Les réseaux à grande distance (WAN) reposent sur une infrastructure très étendue, nécessitant des investissements très lourds. Contrairement aux réseaux

Plus en détail

Classification and Evaluation of Constraint- Based Routing Algorithms for MPLS Traffic Engineering. Samer Lahoud Géraldine Texier Laurent Toutain

Classification and Evaluation of Constraint- Based Routing Algorithms for MPLS Traffic Engineering. Samer Lahoud Géraldine Texier Laurent Toutain Classification and Evaluation of Constraint- Based Routing Algorithms for MPLS Traffic Engineering Samer Lahoud Géraldine Texier Laurent Toutain Plan de la présentation Contexte Objectifs du routage contraint

Plus en détail

Vers RENATER-6 : évolutions du réseau DWDM national. Emilie Camisard

Vers RENATER-6 : évolutions du réseau DWDM national. Emilie Camisard Vers RENATER-6 : évolutions du réseau DWDM national Emilie Camisard Assemblée Générale de REFIMEVE+ Paris, le 2/6/2014 Agenda Le GIP RENATER et le réseau RENATER La technologie DWDM Principes Utilisation

Plus en détail

SOMMAIRE Thématique : Réseaux et télécommunications

SOMMAIRE Thématique : Réseaux et télécommunications SOMMAIRE Thématique : Réseaux et télécommunications Rubrique : Réseaux - Télécommunications... 2 1 SOMMAIRE Rubrique : Réseaux - Télécommunications Evolution et perspective des réseaux et télécommunications...

Plus en détail

Services SYRHANO. Assemblée générale SYRHANO - 16/12/2008 alain.bidaud@crihan.fr

Services SYRHANO. Assemblée générale SYRHANO - 16/12/2008 alain.bidaud@crihan.fr Services SYRHANO Assemblée générale SYRHANO - 16/12/2008 alain.bidaud@crihan.fr Architecture Le réseau régional pour l'enseignement et la Recherche Architecture de SYRHANO 3 Le réseau régional SYRHANO

Plus en détail

SDN / Open Flow dans le projet de recherche de GEANT (GN3+)

SDN / Open Flow dans le projet de recherche de GEANT (GN3+) SDN / Open Flow dans le projet de recherche de GEANT (GN3+) Xavier Jeannin GIP RENATER 23-25, rue Daviel 75013 PARIS Résumé Dans le cadre du projet GN3+ (avril 2013 Mars 2015), parmi la tâche orientée

Plus en détail

Routage dans l Internet Partie 2 (OSPF)

Routage dans l Internet Partie 2 (OSPF) Algorithme de Routage État de liaisons Link State Routing Routage dans l Internet Partie 2 () Isabelle CHRISMENT ichris@loria.fr Stratégie: envoyer à tous les nœuds (pas seulement les voisins) information

Plus en détail

Cahier des Clauses Techniques Particulières. Convergence Voix - Données

Cahier des Clauses Techniques Particulières. Convergence Voix - Données Cahier des Clauses Techniques Particulières Convergence Voix - Données SOMMAIRE - Objet du document et du marché - Contexte et périmètre du projet - Configurations existantes et besoins - Services attendus

Plus en détail

RESEAUX ARCHITECTURES EN COUCHES. J.L Damoiseaux ; Dpt R&T 1

RESEAUX ARCHITECTURES EN COUCHES. J.L Damoiseaux ; Dpt R&T 1 RESEAUX ARCHITECTURES EN COUCHES J.L Damoiseaux ; Dpt R&T 1 Plan Notions sur les réseaux Couche/Service/Protocole Le modèle OSI Le modèle TCP/IP J.L Damoiseaux ; Dpt R&T 2 Problématique J.L Damoiseaux

Plus en détail

Description des UE s du M2

Description des UE s du M2 Parcours en deuxième année Unités d Enseignement (UE) ECTS Ingénierie des réseaux haut 4 débit Sécurité des réseaux et 4 télécoms Réseaux mobiles et sans fil 4 Réseaux télécoms et 4 convergence IP Infrastructure

Plus en détail

Cisco Certified Network Associate

Cisco Certified Network Associate Cisco Certified Network Associate Version 4 Protocoles et concepts de routage Chapitre 4 Quel événement peut-il occasionner une mise à jour déclenchée? Expiration d un minuteur de routage de mises à jour

Plus en détail

Conservatoire National des Arts et Métiers. Chaire de Réseaux

Conservatoire National des Arts et Métiers. Chaire de Réseaux Conservatoire National des Arts et Métiers 292, rue Saint Martin 75141 PARIS Cedex 03 Chaire de Réseaux Date de l examen : Mercredi 25 juin 2008 Titre de l enseignement : FORMATIQUE CYCLE APPROFONDISSEMENT

Plus en détail

D o s s i e r t e c h n i q u e

D o s s i e r t e c h n i q u e A N N E X E A L A C O N V E N T I O N R E L A T I V E A L A M I S E E N Œ U V R E D U N R E S E A U P R I V E P O U R L E S C O L L E G E S D E S Y V E L I N E S D o s s i e r t e c h n i q u e D é f i

Plus en détail

Le service de ToIP sur le réseau régional SYRHANO

Le service de ToIP sur le réseau régional SYRHANO AST-MG-v2 Le service de ToIP sur le réseau régional SYRHANO JTR 2010 - ToIP - Lyon CRIHAN - Alain Bidaud / Julien Bourdon Le service de ToIP sur SYRHANO Agenda SYRHANO : contexte régional Présentation

Plus en détail

Multi Protocol Label Switching

Multi Protocol Label Switching Multi Protocol Label Switching Du routage IP à la commutation de labels Application à la mise en place de VPN 1 Dans les réseaux IP traditionnels Routage des paquets ½ En fonction de l adresse destination

Plus en détail

L'architecture Mesh. frati@nyx.unice.fr

L'architecture Mesh. frati@nyx.unice.fr L'architecture Mesh frati@nyx.unice.fr On connaissait déjà le mode sans infrastructure : le mode Ad-Hoc mode habituel pour connecter deux ordinateurs entre eux (d égal à égal) permettant des partages de

Plus en détail

Chapitre X : Réseaux virtuels (VLAN)

Chapitre X : Réseaux virtuels (VLAN) Chapitre X : Réseaux virtuels (VLAN) Eric Leclercq & Marinette Savonnet Département IEM http://ufrsciencestech.u-bourgogne.fr http://ludique.u-bourgogne.fr/~leclercq 8 avril 2011 1 Principes Problématique

Plus en détail

Recommandations pour les sites et réseaux de collecte de la communauté académique RENATER : La supervision des réseaux IPv6 1/12

Recommandations pour les sites et réseaux de collecte de la communauté académique RENATER : La supervision des réseaux IPv6 1/12 Recommandations pour les sites et réseaux de collecte de la communauté académique RENATER : La supervision des réseaux IPv6 1/12 Sommaire : 1 La supervision IPv6 : Généralités... 3 1.1 Comment superviser

Plus en détail

DYNAMIC MULTIPOINT VIRTUAL PRIVATE NETWORK (DMVPN)

DYNAMIC MULTIPOINT VIRTUAL PRIVATE NETWORK (DMVPN) 2013-2014 DYNAMIC MULTIPOINT VIRTUAL PRIVATE NETWORK (DMVPN) EXPOSE DE : DIATOU DABO GLORIA YAKETE SADA DEM PROFESSEUR CHARGE M YOUSSEF INSTITUT SUPERIEUR D INFORMATIQUE (ISI) Master 2 Réseaux et Systèmes

Plus en détail

DIFF AVANCÉE. Samy. samy@via.ecp.fr

DIFF AVANCÉE. Samy. samy@via.ecp.fr DIFF AVANCÉE Samy samy@via.ecp.fr I. RETOUR SUR QUELQUES PROTOCOLES COUCHE FONCTIONS Protocoles 7 Application 6 Présentation 5 Session 4 Transport 3 Réseau 2 Liaison 1 Physique Interface entre l utilisateur

Plus en détail

Introduction aux Technologies de l Internet

Introduction aux Technologies de l Internet Introduction aux Technologies de l Internet Antoine Vernois Université Blaise Pascal Cours 2006/2007 Introduction aux Technologies de l Internet 1 Au programme... Généralités & Histoire Derrière Internet

Plus en détail

Stella MARC-ZWECKER. Téléinformatique 1. Objectifs du cours. Réseaux et Protocoles - L3 info

Stella MARC-ZWECKER. Téléinformatique 1. Objectifs du cours. Réseaux et Protocoles - L3 info Objectifs du cours Réseaux et Protocoles - L3 info Stella MARC-ZWECKER Maître de conférences Dpt. Informatique ULP stella@dpt-info.u-strasbg.fr Mécanismes de base de la transmission des données dans les

Plus en détail

Compte-rendu des tests pour le déploiement de classes de services sur RAP

Compte-rendu des tests pour le déploiement de classes de services sur RAP Compte-rendu des tests pour le déploiement de classes de services sur RAP Description : Ce document présente la validation des mécanismes de qualité de service par le biais de différents tests effectués

Plus en détail

Mobile IP et autres compagnons de voyage.

Mobile IP et autres compagnons de voyage. Mobile IP et autres compagnons de voyage. Cartigny Julien Université de Lille 1 LIFL / équipe RD2P Informatique mobile Evolution des ordinateurs: Augmentation de la puissance de calcul, des capacités de

Plus en détail

CENTRE DE RESSOURCES INFORMATIQUES IFMA -------

CENTRE DE RESSOURCES INFORMATIQUES IFMA ------- CENTRE DE RESSOURCES INFORMATIQUES IFMA ------- CONSULTATION POUR DEMANDE DE DEVIS CAHIER DES CHARGES RELATIF AU CHANGEMENT DU FIREWALL DE L IFMA --------------- Date limite d envoi de l'offre : 3 septembre

Plus en détail

Livre banc. Contrôle de trajet dynamique : la base de votre WAN hybride

Livre banc. Contrôle de trajet dynamique : la base de votre WAN hybride Contrôle de trajet dynamique : la base de votre WAN hybride Le réseau étendu (WAN, wide area network) a connu bien peu d innovations pendant une grande partie de la dernière décennie. Alors que le reste

Plus en détail

VPN BGP-MPLS VPN. Types de VPN. Objectifs des VPN Virtual Private Networks interconnecter équipements à travers réseau tiers

VPN BGP-MPLS VPN. Types de VPN. Objectifs des VPN Virtual Private Networks interconnecter équipements à travers réseau tiers VN BG-MLS 2008 VN BG-MLS 1 VN Objectifs des VN Virtual rivate Networks interconnecter équipements à travers réseau tiers (FAI, ) raisons économiques, partage d une infrastructure longue distance coût du

Plus en détail

Groupe Eyrolles, 2000, 2004, ISBN : 2-212-11330-7

Groupe Eyrolles, 2000, 2004, ISBN : 2-212-11330-7 Groupe Eyrolles, 2000, 2004, ISBN : 2-212-11330-7 Sommaire Cours 1 Introduction aux réseaux 1 Les transferts de paquets... 2 Les réseaux numériques... 4 Le transport des données... 5 Routage et contrôle

Plus en détail

Fiche de Réseau de données

Fiche de Réseau de données Fiche de Réseau de données V.R May 25, 2015 Contents I Le modèle OSI 2 1 Concepts de base 2 2 Modèle OSI 4 II Réseau de données 5 1 Erreurs et correction d erreurs 5 2 Contrôle de flux 6 3 Contrôle de

Plus en détail

Pile de protocoles TCP / IP

Pile de protocoles TCP / IP Pile de protocoles TCP / IP Fiche de cours La pile de protocoles TCP/IP est le standard de fait le plus utilisé au monde comme ensemble protocolaire de transmission dans les réseaux informatiques. La raison

Plus en détail

Compte-rendu du TP n o 4

Compte-rendu du TP n o 4 Qiao Wang Charles Duchêne 18 décembre 2013 Compte-rendu du TP n o 4 Document version 1.0 F2R UV301B Routage : peering BGP Sommaire 1. PLAN D ADRESSAGE 2 2. CONFIGURATION DU BANC 2 3. IBGP 4 1 Salle 27,

Plus en détail

RSVP-TE : Extensions à RSVP pour tunnels LSP

RSVP-TE : Extensions à RSVP pour tunnels LSP RFC3209 page - 1 - Awduche et autres Groupe de travail Réseau Request for Comments : 3209 Catégorie : En cours de normalisation décembre 2001 Traduction Claude Brière de L Isle D. Awduche, Movaz Networks,

Plus en détail

NFA083 Réseau et Administration Web TCP/IP

NFA083 Réseau et Administration Web TCP/IP NFA083 Réseau et Administration Web TCP/IP Sami Taktak sami.taktak@cnam.fr Centre d Étude et De Recherche en Informatique et Communications Conservatoire National des Arts et Métiers Rôle de la Couche

Plus en détail

Evolution de l infrastructure transport

Evolution de l infrastructure transport Les réseaux optiques I Les réseaux optiques Jean-Paul GAUTIER, jpg@urec.cnrs.fr CNRS / UREC Une des grandes tendances de la fin des années 90 est la demande croissante en bande passante des réseaux d entreprises

Plus en détail

Solution de téléphonie IP convergente d Allstream

Solution de téléphonie IP convergente d Allstream Solution de téléphonie IP convergente d Allstream Solution de lignes groupées IP Document de présentation technique 1 Table des matières Introduction 1 Lignes d accès classiques : un bref survol 1 Lignes

Plus en détail

Module : Technologies Réseau

Module : Technologies Réseau Université des Sciences et Technologies Houari Boumediene Faculté d Electronique et d Informatique Module : Technologies Réseau Rapport de projet : La qualité de service dans les réseaux informatiques

Plus en détail