Page 1
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
1
Thèse professionnelle
Modernisation du service IP Transit de Covage Services
Conception et architecture de réseaux
Jean Rebiffé
Elève ingénieur Mastère spécialisé Télécom ParisTech [email protected]
Réalisée sous la direction de : Monsieur Phong-Quang Nguyen
Ingénieur Réseau - CCIE #8809 [email protected]
Monsieur Ahmed Serhouchni Maître de conférences [email protected]
Covage Services 30, avenue Edouard Belin 92500 Rueil-Malmaison http://www.covage.com/
Télécom ParisTech 46, rue Barrault 75634 Paris Cedex 13 http://www.telecom-paristech.fr/
Page 2
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
2
Remerciements
En premier lieu, merci à mon maitre de stage, Phong Nguyen, qui a su au travers de ses compétences techniques me
guider dans mes recherches, tout en me laissant la liberté d’explorer les nombreuses pistes s’offrant au projet. Merci
également de la confiance qu’il m’a accordé, notamment pendant la phase de déploiement.
Merci à Sébastien Maillet, responsable de l’équipe ingénierie, m’avoir permis réaliser ma thèse professionnelle en
m’accueillant au sein des équipes techniques, pour avoir défendu le projet et pour m’avoir permis d’explorer de
nouveaux axes de réflexions sur l’IP Transit.
Merci à Guillaume Auchere, pour les conseils toujours avisés et pour la proximité que j’ai eu avec lui au cours de ce
stage qui font de lui un grand ami depuis longtemps.
Merci à Zakaria Aberchane avec qui j’ai commencé le travail sur le projet et qui fut à la fois un confident et un
challenger pendant les trois premiers mois du stage.
Merci à Aurélie Gournay, Adel Hidous, et Delphine Gautherot avec qui j’ai partagé des points de vue et qui ont vécu
l’expérience d’un stage chez Covage.
Merci à Jérome Cloet pour ses qualités d’écoute exceptionnelles et sa culture technique qui font de lui un
interlocuteur passionnant.
Je tiens tout particulièrement à remercier la famille Des Aulnois pour les soutiens dont ils ont su faire preuve durant
ces 6 mois de stage et m’accorder un accueil très chaleureux à une période de ma vie que je percevrai, peut-être
bientôt, comme un renaissance.
Un très grand merci à Isabelle et Arnaud Des Aulnois qui m’ont apporté une aide précieuse dans la rédaction et la
structure de cette thèse professionnelle.
Page 3
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
3
Sommaire 1 Introduction .............................................................................................................................................................. 5
2 Plan de déroulement du stage .................................................................................................................................. 6
3 La société Covage ...................................................................................................................................................... 7
3.1 Présentation générale de Covage ..................................................................................................................... 7
3.2 Objectifs et réalisations de Covage ................................................................................................................... 8
3.3 Services de la société Covage ........................................................................................................................... 9
3.4 Le service IP Transit........................................................................................................................................... 9
4 Projet IP Transit ...................................................................................................................................................... 10
4.1 Buts du service IP Transit ................................................................................................................................ 10
4.2 Historique du service IP Transit ...................................................................................................................... 10
4.3 Etat du service IP Transit depuis 2008 ............................................................................................................ 11
4.4 Commercialisation de l’IP Transit ................................................................................................................... 11
4.5 Evolutions nécessaires du service IP Transit ................................................................................................... 12
4.5.1 Amélioration des performances .............................................................................................................. 13
4.5.2 Support des AS 32 bits ............................................................................................................................. 13
4.5.3 Déploiement d’IPv6 ................................................................................................................................. 14
5 Plateforme IP Transit .............................................................................................................................................. 15
5.1 Rôle de la plateforme IP Transit ...................................................................................................................... 15
5.2 Interfaces de la plateforme IP Transit ............................................................................................................. 16
5.2.1 Présentation générale des interfaces de la plateforme IP Transit .......................................................... 16
5.2.2 Le lien iBGP : utilisation des Pseudowires ................................................................................................ 17
5.2.3 Les liens avec le Backbone MPLS : Les deux VRFs « IPT-1 » ..................................................................... 18
5.2.4 Les liens avec les fournisseurs de transit ................................................................................................ 20
5.3 Connexion des clients au service IP Transit : les VRFs « IPT » ......................................................................... 21
5.4 Absence d’import entre les VRFs « IPT » et propagation des routes .............................................................. 23
5.5 Annonces inconditionnelles des routes par défaut et cas de pannes ............................................................. 24
5.6 Propagation des annonces BGP ...................................................................................................................... 25
5.6.1 Les annonces BGP pour les flux descendants depuis Internet vers les clients ........................................ 25
5.6.2 Les annonces BGP pour les flux montants depuis les clients vers Internet ............................................. 27
5.6.3 Utilisation de l’attribut de communauté NO_EXPORT sur la session iBGP .............................................. 29
5.6.4 Contrôle des flux montant et descendants .............................................................................................. 29
5.7 Les ACLs et le policing appliqués sur la plateforme IP Transit ........................................................................ 32
5.7.1 L’ACL appliquée en sortie vers Internet : IPT-ALL-IF-OUT ........................................................................ 32
5.7.2 Les ACLs en pour les paquets arrivants d’Internet : IPT-<FAI>-IN ............................................................ 33
5.7.3 L’ACLs des paquets entrant depuis le Backbone MPLS : IPT-CORE-IN ..................................................... 34
5.7.4 L’ACL des paquets sortant vers le Backbone MPLS : IPT-CORE-OUT ........................................................ 35
5.7.5 Policing des flux entrant : la policy-map IPT-POLCING ............................................................................ 35
Page 4
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
4
5.8 Evolution possible de la plateforme : Les points de peering .......................................................................... 36
6 Architecture IPv6 .................................................................................................................................................... 38
6.1 Architecture proposée .................................................................................................................................... 38
6.2 Objectif d’agrégation d’IPv6 ........................................................................................................................... 40
6.3 Taux d’utilisation imposé par le RIPE-NCC ...................................................................................................... 40
6.4 Evolutions possibles de l’espace d’adressage IPv6 ......................................................................................... 41
6.5 Relations avec le RIPE-NCC : demande de l’allocation initiale IPv6 ................................................................ 41
6.6 Routage IPv6 ................................................................................................................................................... 42
6.7 Les ACLs de protections .................................................................................................................................. 42
6.8 Les VRFs « IPT6 », correspondant aux VRFs « IPT » d’IPv4 ............................................................................. 43
6.9 Implémentation 6to4 dans l’architecture ....................................................................................................... 44
6.9.1 Fonctionnement du 6to4 ......................................................................................................................... 44
6.9.2 Rôle d’encapsulation du 6to4 relay router .............................................................................................. 46
6.9.3 Rôle de décapsulation du 6to4 relay router ............................................................................................. 47
6.9.4 Autres mécanismes de transition utilisant des préfixes anycast ............................................................. 47
6.10 Gestion de la délégation DNS inverse pour IPv6 ............................................................................................. 48
7 Mise en production la nouvelle plateforme IP Transit............................................................................................ 49
7.1 Différence entre la nouvelle et l’ancienne architecture ................................................................................. 50
7.2 Problème rencontrés lors de la migration ...................................................................................................... 50
7.2.1 L’ACL filtrant les paquets arrivant depuis le Backbone MPLS (IPT-CORE-IN) ........................................... 50
7.2.2 Policy-map de l’ancienne architecture .................................................................................................... 50
7.2.3 Défauts matériels ..................................................................................................................................... 51
8 Conclusion ............................................................................................................................................................... 52
8.1 Conclusion sur les réalisations ........................................................................................................................ 52
8.2 Conclusion sur mon stage ............................................................................................................................... 52
9 Bibliographie ........................................................................................................................................................... 53
10 Table des figures ................................................................................................................................................. 54
11 Index ................................................................................................................................................................... 55
Page 5
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
5
1 Introduction
Dans le cadre du stage chez Covage Services, j’ai réalisé de nombreux tests et recherches sur le service IP Transit.
Monsieur Phong Nguyen, m’a donc confié sous son contrôle, le travail de créer l’architecture de la nouvelle
plateforme IP Transit correspondant aux attentes nouvelles que les clients de Covage ont du service IP Transit. Suite
à ces recherches, j’ai pu proposer une utilisation possible de la plage IPv6 qui est allouée à Covage pour l’architecture
de ce nouveau service.
Ainsi, j’ai pu réaliser de nombreux tests de validation sur la plateforme de laboratoire, simulant au mieux les
conditions réelles dans lesquelles fonctionnera la plateforme réelle pour vérifier son fonctionnement général, aussi
bien en situation nominale qu’en cas de panne.
J’ai proposé, par ailleurs, le plan de migration de l’ancienne à la nouvelle architecture que Phong Nguyen et moi-
même avons exécuté pour la mise en production de la nouvelle plateforme, en décembre 2010.
Par ailleurs, lors de ce stage, il m’a été confié de faire l’étude concernant les opportunités que représentent des
points de peering et la recherche de partenaires de peering ainsi que la mise en œuvre du protocole NetFlow,
nécessaire pour mieux comprendre les flux. D’autres aspects directement liés ont également été abordés dans le
cadre de ce service : comme les relations avec le RIPE-NCC et la mise en œuvre de la zone de délégation DNS inverse
pour la plage IPv6 de Covage.
Le choix du matériel avait été fait avant le début du stage et certaines parties comme le Policing sont reprises sans
modification .Mon action a été de tester en laboratoire son fonctionnement sur la nouvelle plateforme et vérifier
que ce mécanisme qui existait déjà en IPv4 pouvait être réutilisé avec IPv6.
Page 6
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
6
2 Plan de déroulement du stage
Objectif du stage : améliorer le service IP Transit (modernisation)
Performance : supporter plus de clients et des clients consommant plus de bande passante.
Ajout de nouveaux protocoles : IPv6.
Déployer les améliorations sans interrompre le service livré client (Satisfaction client).
Moyens :
Matériel de laboratoire simulant le fonctionnement du service actuel.
Matériel devant être déployé déjà acquis.
Documentation :
o des protocoles (BGP, IPv6) et de leurs objectifs.
o des déploiements existants chez les grands opérateurs (retours d’expérience).
Développements / Validation (Juillet 2010 – Novembre 2010) :
Nouvelle plateforme.
Architecture du service IPv6.
Plan de déploiement par étapes.
Tests en laboratoire :
o Nouvelles fonctionnalités.
o Service dans sa configuration finale.
o Migration ancienne plateforme nouvelle plateforme.
Mise en production (Décembre 2010) :
Exécution du plan de déploiement.
Initialement prévue en décembre 2010.
Retard causé par des problèmes de stabilité du matériel (redémarrage hebdomadaire).
o Echange standard en cours avec le fournisseur pour optimisation matériel.
Résultats :
Future plateforme conforme aux besoins.
Pas besoin de modifications lourdes du service qui fonctionne actuellement.
Plan de déploiement des nouvelles fonctionnalités : IPv6.
Page 7
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
7
3 La société Covage
3.1 Présentation générale de Covage
Covage est une société par actions simplifiées au Capital Social de 10 000 000 €. Son siège social est localisé à Rueil-
Malmaison, elle a été crée en novembre 2004.
Les sociétés Vinci Networks et AXIA NetMedia Corporation sont actionnaires à parité de Covage, spécialisée dans les
réseaux de télécommunications construits pour les collectivités.
Figure 1 : L’actionnariat dans la société Covage (extrait du site http://www.covage.com/)
La société Covage a crée par la suite d’autres structures telles que Covage Services en 2007 (chiffre d’affaire en 2009,
13 260 000 €), pour les services IP, et Covage Networks en 2008, pour les réseaux de transmission.
Les principaux dirigeants de cette structure sont :
Monsieur Jean-Michel Soulier, Président ;
Monsieur Norbert Blanchard, Directeur des Opérations ;
Monsieur Pascal Edmond, Directeur Commercial et Développement ;
Monsieur Clément Verhile, Directeur des Concessions ;
Monsieur Anne Grenier, Directeur des Relations Institutionnelles ;
Madame Valérie Alvarez, Directrice Juridique.
Covage représente à ce jour 240 millions d’euros d'investissements ainsi que 14 DSP (délégation de service publique)
sur l'ensemble du territoire français et compte 120 salariés.
Pour mémoire, une DSP est un contrat par lequel une collectivité (le délégant) va confier la gestion d’un service
public à une entreprise privée (le délégataire) qui est Covage.
Page 8
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
8
3.2 Objectifs et réalisations de Covage
Comme présentée sur le site web de l’entreprise *COVAGE+, la société Covage, via ses sociétés locales, assure la
construction et l’exploitation de réseaux de télécommunications en fibre optique pour le compte de ses collectivités
délégantes. A ce titre, Covage commercialise des services télécoms à tous les opérateurs qui peuvent ainsi offrir leurs
meilleurs services aux entreprises, services publics et grand public.
Par ailleurs, Covage fait figure de cas particulier : en effet, cette société est aujourd’hui le premier opérateur
d’opérateurs neutres et indépendants à avoir fait le pari de la fibre optique. Elle maîtrise de bout en bout la chaîne
de valeur de l’opérateur d’opérateurs, du déploiement de l’infrastructure jusqu’à la fourniture du service télécom à
forte valeur ajoutée aux fournisseurs d’accès. Elle s’est spécialisée dans l’exploitation des services Très Haut Débit.
Le succès de Covage repose sur le fait que cette société propose à tous les opérateurs et fournisseurs d’accès des
services de connectivité optique, de bande passante et d’hébergement sur l’ensemble de ses réseaux et territoires.
Les principaux clients de la société sont :
Les opérateurs nationaux (tel que Free, Bouygues et SFR)
Les opérateurs internationaux (Cogent, Colt, Easynet, Global Crossing, Interoute, Tella, Verizon Business)
Les opérateurs de services aux entreprises (Altitude Télécom, Completel, Orange Business Services, SFR
Bussiness Team)
Les opérateurs régionaux et nationaux (Acropolis, Adesta, Celeste, Risc Group, Sanef, TDF, Territoires sans
fil)
Les opérateurs de proximité (Aes Dana, Afone, Akinea, Artal, Asia, Atoo, Aurus etc…)
Covage répond aux besoins croissants des collectivités locales françaises et des opérateurs de télécommunication
dans le domaine des nouveaux usages du haut débit et de l’IP (VoIP, Internet, TV, VOD, mobilité)…
Opérateur d’opérateurs, Covage propose des services d’installation et intégration des équipements actifs, maintien
et supervision de réseaux, commercialisation de services de connectivité optique, de bande passante garantie et
symétrique, de services d’hébergement aux Fournisseurs d’Accès Internet et opérateurs de services de
télécommunications nationaux et locaux.
Covage commercialise aussi une palette d’offres d’activation financièrement très attractives, ouverte à différents
types d’accès (PON, CPL, ADSL, Wifi etc…) et différents services (Réseaux privés virtuels, Voix sur IP, vidéo, etc.). Axia
met en œuvre la technologie IP MPLS qui offre aux opérateurs toutes les garanties de performance et de qualité des
réseaux.
Voici des exemples d’utilisation :
1. La santé
Au Creusot, grâce au haut débit, les deux hôpitaux et le centre IRM locaux jouissent d’un accès Très Haut Débit
amélioré et immédiat à l’information lorsqu’il s’agit de diagnostic médical ou de partage du savoir avec d’autres
centres en région Bourgogne
2. L’enseignement et la recherche :
Par ailleurs, le haut débit est un formidable outil de flexibilité dans son approche de l’enseignement et de la
recherche. Les barrières géographiques sont dépassées et l’accès à un contenu peut s’effectuer à n’importe quelle
heure du jour et de la nuit. Un accès plus important à des ressources, infrastructures et professeurs par
l’intermédiaire de la recherche en ligne et de la vidéoconférence. A Clermont-Ferrand, ces nouveaux usages sont là
pour améliorer l’efficacité et l’implication des étudiants et chercheurs dans leur parcours universitaire.
Ainsi, à Toulouse, Arras et Chalon sur Saône, grâce au très haut débit, l’accès aux services de visioconférence,
Page 9
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
9
hébergement de site, Voix sur IP et plus généralement les services de téléphonie de dernière génération deviennent
disponibles.
3. Les entreprises des technologies de l’information et de la communication :
Covage répond directement aux attentes du très haut débit exprimées par les entreprises présentes sur leur
territoire (à proximité de la fibre optique, réseaux hertziens et DSL) qui pourront bénéficier de services intégrés (voix,
Internet, data), de la sauvegarde de leurs données à distance, de la protection de leur savoir faire.
En 2008, Covage est présent sur des réseaux d’initiative publique répartis sur l’ensemble du territoire.
Covage commercialise ses services de bande passante sur fibre optique sur les réseaux du Creusot-Montceau,
d’Arras, de Chalon sur Saône de Cosne sur Loire, du Sicoval, du Grand Angoulême, de Clermont Communauté,
Covage participe au développement des réseaux de Caen la mer ; du Grand Toulouse, du Conseil Général de Haute
Garonne, de la Communauté Urbaine de Bordeaux, du département de la Seine et Marne et du département de
l’Hérault.
3.3 Services de la société Covage
La société Covage propose les services suivants, comme décrit sur le site de l’entreprise :
Le service de transmission ;
Le service de VPN Ethernet ;
Le service de VPN IP ;
Le service IP Transit ;
Le service d’hébergement ;
La fibre optique noire (ou FON).
Le service sur lequel j’ai été affecté est le service IP Transit dont les caractéristiques sont développées dans le
paragraphe suivant, sous le contrôle de l’équipe Ingénierie au même titre que le sont le service de VPN Ethernet et le
service de VPN IP.
3.4 Le service IP Transit Le Service de transit IP est le service permettant l’accès à Internet à très haut débit sur fibre optiques pour les clients
opérateurs. Ce service est accessible au travers de l’infrastructure de Covage et donc présent dans toutes les régions
où est présent l’entreprise, grâce à la capillarité du réseau Covage.
Ce service propose de nombreux débits différents sur différents raccordements. Il offre d’autre part, la possibilité
d’être doublement raccordé (un client actuellement). Ce service peut être personnalisé à chaque client opérateur.
Dans son fonctionnement, il s’agit d’un service proche du service de VPN IP, mais par lequel le client relie un site à
Internet plutôt que de relier deux sites entre eux.
Comme indiqué dans les documents contractuels [IPTSTAS], Covage s’engage sur les garanties de niveau de service,
avec :
un taux de disponibilité de 99,98% ;
un débit symétrique ;
un temps de rétablissement d’inférieur à 4 heures ;
une latence de 25 ms AR et une gigue de 5 ms inter-DSP.
Page 10
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
10
4 Projet IP Transit
4.1 Buts du service IP Transit
Covage en temps qu’ « opérateur d’opérateurs » permet aux opérateurs régionaux d’établir une connectivité entre
les centres d’interconnexion situés à Paris et les opérateurs régionaux. Dans le cadre de l’accès à Internet, la
remontée des flux sur Paris est quasiment obligatoire. Tous ces opérateurs installent donc des équipements de
routage : au même endroit et réalisant le même objectif.
Le projet IP Transit a pour but de permettre aux clients de ne plus avoir à installer d’équipement sur Paris pour
l’accès à Internet. Il s’agit donc de réaliser une mutualisation des équipements sur une plateforme gérée par Covage.
Le service IP Transit est un service proposant d’effectuer le routage sur Internet accessible directement depuis les
régions (les DSP de Covage).
4.2 Historique du service IP Transit
Initialement composé d’un ensemble de VRFs sur le Backbone, il reliait l’opérateur Level3 Communication aux
opérateurs locaux que Covage avait mis en place pour ses clients. C’est donc Level3 qui assurait le routage sur
Internet alors que Covage réalisait simplement le lien entre les clients et l’unique fournisseur de transit (Level3).
Dans ce mode de fonctionnement, les plages IP étaient fournies par Level3. Covage était restreint à effectuer le
routage vers les régions. Cette architecture est encore visible pour quelques clients ne souhaitant pas quitter les
adresses assignées par Level 3 Communications.
Page 11
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
11
4.3 Etat du service IP Transit depuis 2008
Par la suite, ce service a évolué pour donner plus d’indépendance à Covage en lui permettant d’avoir un numéro d’AS
et une plage d’adresses IP, ce qui lui permet de faire son propre routage vers Internet. Depuis 2008, le mode de
fonctionnement du service repose sur :
La plateforme IP Transit est composée des deux routeurs IPTs. Elle effectue le routage Internet et gère les
interconnexions vers deux fournisseurs de transit (Neo Telecoms et Level 3 Communication).
Des liens logiques qui relient les clients à la plateforme IP Transit. Ces liens sont, en fait, un ensemble de
VRFs uniquement dédiées à l’IP Transit configurées sur le Backbone MPLS de Covage. Le Backbone est de
dimension nationale et est présent là où Covage possède des marchés publics (DSP). Cet aspect est très
proche du service « VPN IP » commercialisé par Covage.
Ce schéma représente de manière simple ces deux éléments du service IP Transit et les liens qu’ils entretiennent
avec les clients (pour le Backbone) et les fournisseurs (pour la plateforme) :
Plateforme IP Transit
AS44902
Backbone MPLS
(multi-service)
AS64512
Fournisseur de
transit InternetFournisseur de
transit Internet
Internet
Client du service
IP Transit
Client du service
IP TransitClient du service
IP Transit
Covage
Clients
Fournisseurs
Figure 2 : Service IP Transit : le Backbone MPLS et la plateforme
4.4 Commercialisation de l’IP Transit
Covage commercialise le transit IP sous forme de deux services distincts à ses clients, à savoir :
Un contrat pour le service de routage Internet ;
Un contrat pour le service de bande passante.
En 2010, ces services ont réalisé un chiffre d’affaire de 108 000€ pour la vente de transit IP et de 184 520€ pour la
vente de bande passante associée. Ce chiffre d’affaire concerne une clientèle de 75 opérateurs qui totalisaient 998
Mbps, le 2 novembre 2010. La bande passante vendue était environ 10 fois supérieure à la bande passante
réellement consommée aux heures de pointe.
Les fournisseurs d’IP Transit ont coûté à la société un montant de 27 600€ pour Level3 et de 14 400€ pour Neo
Telecoms. La facturation appliquée par ces deux fournisseurs est basée sur la règle du 95ème centile comme cela est
Page 12
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
12
généralement le cas pour le Transit IP, avec une facturation minimale de 100Mbps. C'est-à-dire que sur un mois, en
effectuant un relevé toutes les 5 minutes (soit 8640 relevés par mois), seule la 8208ème valeur la plus élevée est prise
en compte pour la facturation. Si cette valeur est inférieure à 100Mbps, comme cela est souvent le cas en 2010 pour
Covage, la facturation est basée sur un minimum de 100Mbps. Si cette valeur de facturation est supérieure au débit
contracté, alors la facturation est basée sur cette valeur, quelles que soient les valeurs suivantes.
On notera par ailleurs que des solutions, comme le peering abordé plus loin, sont envisagées pour réduire le recours
aux fournisseurs de transit. L’indépendance que procure un numéro d’AS et une plage d’adresse IP allouée permet,
par ailleurs, un mise en concurrence très forte de ces fournisseurs : ainsi Covage peut profiter au mieux des
mécanismes de facturation de chacun de ses fournisseurs (facturation au 90ème centile au lieu du 95ème, facturation
forfaitaire, …). C’est pourquoi, Level3 s’est récemment aligné sur le prix de leurs concurrents : la facture est ainsi
passée de 3000€ par mois à moins de 1000€ par mois.
A titre d’exemple, vous trouverez ci-dessous l’évolution des débits commercialisés par Covage auprès de ses
clients depuis 2008 :
Figure 3 : Evolution de la somme des débits commercialisés du service IP Transit
4.5 Evolutions nécessaires du service IP Transit
A la mi-2010, ce service devait évoluer selon 2 axes :
Le service devait supporter une plus grande capacité en terme de bande passante, pour supporter un plus
grand nombre de clients ainsi qu’un plus gros volume par client. En effet, le service actuel réalise plus de
100Mbps de trafic réel pour 1Gbps commercialisé alors que le matériel utilisé (des Cisco 7204) montre ses
limites : d’après les tests, ces machines ne pourront pas supporter plus de quelques centaines de Mbps,
limitant le service.
La plateforme devait également supporter des évolutions techniques comme le support de l’IPv6 et des
numéros d’AS 32bits. Le remplacement des routeurs de la plateforme (les Cisco 7204 par de Cisco 7606) et
du logiciel (des IOS plus récents) employé par ces routeurs devaient permettre ces nouveautés (en plus de
la puissance de commutation évoquée précédemment).
Enfin, une refonte de l’ingénierie des interactions entre la plateforme et le Backbone est également inévitable pour
IPv6, en raison de l’absence du support d’OSPFv3 pour IPv6 dans les VRFs. OSPF était le protocole utilisé pour
l’échange de routes (IPv4 uniquement) entre l’ancienne plateforme IP Transit et le Backbone MPLS de Covage.
Page 13
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
13
A titre d’exemple, vous trouverez ci-dessous deux extraits permettant de comparer les versions de matériels et de
logiciels utilisés sur l’ancienne plateforme IP Transit et sur la nouvelle plateforme, ces changements de versions nous
permettent les trois évolutions souhaitées :
# Extrait de la commande “show version” sur un routeur Cisco 7204 de l’ancienne plateforme
Cisco IOS Software, 7200 Software (C7200-ADVENTERPRISEK9-M), Version 12.4(15)T8, RELEASE
SOFTWARE (fc3)
Compiled Tue 02-Dec-08 00:44 by prod_rel_team
Cisco 7204VXR (NPE-G1) processor (revision C) with 983040K/65536K bytes of memory.
SB-1 CPU at 700MHz, Implementation 1025, Rev 0.2, 512KB L2 Cache
# Extrait de la commande “show version” sur un routeur Cisco 7606 de la nouvelle plateforme
Cisco IOS Software, c7600s72033_rp Software (c7600s72033_rp-ADVIPSERVICESK9-M), Version
12.2(33)SRE1, RELEASE SOFTWARE (fc2)
Compiled Tue 30-Mar-10 07:53 by prod_rel_team
cisco CISCO7606-S (R7000) processor (revision 1.1) with 983008K/65536K bytes of memory.
SR71000 CPU at 600MHz, Implementation 1284, Rev 1.2, 512KB L2 Cache
4.5.1 Amélioration des performances
L’amélioration des performances nécessite un renouvellement des équipements actuels par d’autres plus puissants
et il s’agit dans ce sens que d’un remplacement.
Les deux nouveaux Cisco 7606 sont proches des matériels déployés dans le Backbone MPLS (des Cisco 7609) et sont
donc bien connus par les équipes techniques. Cependant, contrairement au Backbone, ils doivent être équipés de
cartes (commutation et routage) gérant un grand nombre de routes, conformes au nombre de routes présentes sur
Internet : 330000 routes IPv4 environ et 4000 en IPv6 actuellement, 1Go de mémoire est également nécessaires pour
cette gestion.
J’ai donc réalisé pour Covage l’intégralité des tests nécessaires sur ce matériel pour être utilisé sur la plateforme IP
Transit. Ces deux Cisco 7606 ont posé des problèmes de stabilité occasionnés par des défaillances matérielles, sur la
mémoire vive et la carte de routage SUP720-3BXL essentiellement.
4.5.2 Support des AS 32 bits
Le nombre d’organisations (opérateurs) présentes sur Internet ne cesse de croître et le protocole BGP assurant le
routage sur Internet n’est prévu que pour une représentation sur 16 bits de ces organisations, les numéros d’AS.
Cependant, un passage des numéros d’AS de 16 bits à 32 bits est nécessaire pour permettre à plus d’organisations de
se présenter.Cette extension se fait sous forme d’un ajout au protocole existant (sans grande modification). Un
mécanisme de transition est prévu pour que les routeurs ne prenant pas encore en compte la modification n’en
gênent pas le déploiement. Cependant, pour pouvoir se connecter de manière propre à ces numéros d’AS sur 32 bits,
il faut réaliser une mise à jour logicielle.
Dans le cadre de l’architecture que Covage à mis en place pour le routage Internet, cette modification ne concerne
que la plateforme IP Transit et non le Backbone MPLS. Ce support a donc été testé et mis en place dans le cadre de la
nouvelle plateforme IP Transit. Cette mise à jour place Covage à l’état de l’art et permettra à Covage d’avoir des
clients ou des fournisseurs utilisant des numéros d’AS 32 bits.
Page 14
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
14
4.5.3 Déploiement d’IPv6
En novembre 2010, le pool d’adresses IPv4 disponible était quasiment épuisé : le registre géré par l’IANA indiquait
environ 2% d’espace libre (7 blocs « /8 » disponibles). L’épuisement total prévu est pour novembre 2011 pour les 5
registres régionaux (les 5 RIRs comme le RIPE-NCC), gérant les allocations aux organisations. Après cet épuisement
annoncé, il sera impossible aux organisations d’obtenir de nouvelles adresses. Ces chiffres soulignent qu’il est urgent
de trouver des solutions pour maintenir la croissance d’Internet. Parmi les améliorations que propose IPv6 par
rapport à IPv4, l’espace d’adressage bien plus important d’IPv6 en fait un protocole incontournable, avec pour seule
alternative la généralisation de la traduction d’adresse réseau (NAT) pour IPv4.
IPv6 est un nouveau protocole pour Covage, il était en effet complètement absent du réseau jusqu’en novembre
2010. Le déploiement de ce protocole pour l’entreprise et ses clients nécessite donc un investissement en terme
d’ingénierie pour le rendre cohérent avec l’ingénierie IPv4 tout en profitant au maximum des bienfaits d’IPv6 : le plan
d’adressage IPv6 est, par exemple, un axe majeur en ce qui concerne les possibilités créées par un espace
d’adressage aussi grand (32 bits entièrement gérés par Covage). Ce protocole impose également des contraintes
différentes, définies dans les RFCs, les politiques du RIPE-NCC et les objectifs techniques propres à IPv6. (Par exemple
supprimer le NAT impose d’assigner plus d’une adresse aux clients, ce que Covage fait en IPv4).
A l’inverse de l’augmentation des performances et du support d’IPv6, le déploiement d’IPv6 est particulièrement
lourd car il concerne les fournisseurs, la plateforme IP Transit, le Backbone MPLS puis devra faire l’objet d’une
proposition auprès de chacun des clients.
Page 15
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
15
5 Plateforme IP Transit
5.1 Rôle de la plateforme IP Transit
L’ensemble de la table de routage Internet ne peut pas être propagé dans les VRFs du Backbone MPLS car le matériel
de ce Backbone est limité à 256000 routes. En effet, par l’aspect multiservice, il est nécessaire de séparer les
fonctions de routage Internet de la fonction transport des flux. Pour le service de transit IP, le Backbone ne
supportera donc que deux routes par défaut, menant les flux IP à la plateforme IP Transit.
La plateforme IP Transit désigne les deux routeurs IPTs nommés « IPT-TH2 » et « IPT-GLS » : ce sont des routeurs
utilisant le protocole BGP pour échanger avec les fournisseurs de transit. Les fournisseurs de transit nous permettent
d’échanger le trafic avec tout Internet. On peut par ailleurs considérer les VRFs « IPT-1 » comme faisant partie de la
plateforme en raison de leurs liens forts avec les routeurs IPTs (même si elles ne possèdent pas la table de routage
complète).
Ces deux routeurs forment donc l’AS 44902 et sont les seuls routeurs de Covage possédant la table de routage
complète d’Internet (fin 2010, il y aura environ 330000 routes en IPv4 et 4000 routes en IPv6). Leurs noms désignent
le projet IP Transit (« IPT ») ainsi que les Datacenters sur lesquels ils sont installés : TeleHouse2 pour IPT-TH2 (dans le
11e arrondissement à Paris) et GlobalSwitch pour IPT-GLS (à Clichy, près de Paris).
Ci-dessous, vous trouverez une vue du routage Internet que possède IPT-GLS (de la nouvelle plateforme). Dans
l’ordre, nous remarquons principalement : le nombre de routes Internet (les « network entries »), la présence d’un
fournisseur de transit (AS8218), la VRF IPT-1 du Backbone (AS64512) et le second routeur de l’AS : IPT-TH2
(93.95.56.153).
! Vue IPv4 et IPv6 depuis IPT-GLS (AS44902, ID 93.95.56.111), le 09/12/2010 à 15h40
!
IPT-GLS-7606>show bgp ipv4 unicast summary
BGP router identifier 93.95.56.111, local AS number 44902
BGP table version is 428910, main routing table version 428910
333794 network entries using 42725632 bytes of memory
667423 path entries using 34705996 bytes of memory
122189/60703 BGP path/bestpath attribute entries using 15151436 bytes of memory
88948 BGP AS-PATH entries using 3243584 bytes of memory
4 BGP community entries using 96 bytes of memory
4 BGP route-map cache entries using 128 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 95826872 total bytes of memory
2 received paths for inbound soft reconfiguration
BGP activity 341119/3404 prefixes, 686954/15617 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
83.167.32.45 4 8218 97336 743 428910 0 0 05:38:32 333629
93.95.56.149 4 64512 3986 3969 428910 0 0 05:38:30 141
93.95.56.153 4 44902 112290 58409 428910 0 0 05:39:00 333648
IPT-GLS-7606>show bgp ipv6 unicast summary
BGP router identifier 93.95.56.111, local AS number 44902
BGP table version is 23291, main routing table version 23291
3914 network entries using 594928 bytes of memory
3914 path entries using 297464 bytes of memory
3124/3083 BGP path/bestpath attribute entries using 387376 bytes of memory
88949 BGP AS-PATH entries using 3243624 bytes of memory
4 BGP community entries using 96 bytes of memory
4 BGP route-map cache entries using 128 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 4523616 total bytes of memory
BGP activity 341119/3404 prefixes, 686954/15617 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:1B48:2:103::51
4 8218 16417 741 23291 0 0 05:38:36 3908
2A02:2358:1:2::56:110
Page 16
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
16
4 44902 0 0 1 0 0 never Idle (Admin)
2A02:2358:2:1::29
4 64512 3973 3971 23291 0 0 05:38:32 4
5.2 Interfaces de la plateforme IP Transit
5.2.1 Présentation générale des interfaces de la plateforme IP Transit
Chacun des deux routeurs IPTs possède 3 liens différents : le lien iBGP, le lien vers le Backbone MPLS et le lien vers
les fournisseurs de transit, ce sont aussi bien des liens logiques (VLANs) que des voisinages BGP.
Le schéma ci-dessous met en évidence le lien qui existe entre la plateforme, les VRFs du Backbone et les fournisseurs
de transit. (Le lien iBGP sera expliqué ultérieurement).
IPT-TH2 IPT-GLS
TH2 vrf IPT-1 GLS vrf IPT-1
Client 1
Client 2
vrf IPT
vrf IPT
vrf IPT
Client 3
Level3
AS3356
Neo Telecoms
AS8218
AS44902
Backbone MP-BGP
AS64512
Pseudowire via
le backbone MPLS
Dans le datacenter de
GlobalSwitch (Clichy)Dans le datacenter de
TeleHouse2 (Paris)
TH2 GLS
Figure 4 : Liens du service IP Transit : VRFs IPT et IPT-1 du Backbone MPLS, clients et fournsseurs de transit
Page 17
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
17
Au niveau physique, les liens des deux routeurs IPTs sont donc tous liés au PE sur lequel ils sont situés : le PE de TH2
(7609) pour IPT-TH2 et le PE de GLS (7609) pour IPT-GLS :
Les deux liens iBGP (IPv4 et IPv6) entre les deux routeurs IPTs sur une interface physique (Po90), les VLANs
distinguant les liens.
Les deux liens vers les VRFs (nommées « IPT-1 » pour IPv4 et « IPT6-1 » pour IPv6) sur une seconde
interface physique (Po91), les VLANs distinguant les liens.
L’ensemble des liens vers les fournisseurs de transit sur une troisième interface physique (Po92), avec un
VLAN par fournisseur (IPT-TH2 a deux fournisseurs de transit tandis que IPT-GLS n’en a qu’un seul).
Les trois liens physiques utilisés sont des liens etherchannel qui ne comprennent qu’un seul lien Gigabit Ethernet: il
s’agit simplement de trois fibres optiques reliant IPT-GLS au PE de GLS.
Ci-dessous, le schéma qui illustre les trois liens physiques (Po90, Po91 et Po92), d’une part entre TH2 et IPT-TH2 et
d’autre part entre GLS et IPT-GLS :
Backbone IP/MPLS Covage
AS 64512
760
9IPT-GLS
760
9IPT-TH2
Neo1
L3
Neo2
760
9
760
9TH2
760
9GLS
Tro
nc d
e c
olle
cte
clie
nts
PE
vrf IPT
Client
Tro
nc d
e c
olle
cte
clie
nts
Vlan1025
vrf IPT-1
Echange des
préfixes via MP-BGP Peering e
BG
P
Po91.1025
Po90.1029Po92.1030
Po92.1031
Tro
nc d
e c
olle
cte
op
éra
teu
r
Po90.1029
xconnect 1029Po90.1029
xconnect 1029Vlan1025
vrf IPT-1
Po91.1025
Po90.1029 Po92.1030
Tro
nc d
e c
olle
cte
op
éra
teu
r
iBGP de IPT-TH2 à IPT-GLS
Pseudowire #1029 de TH2 à GLS
Pe
erin
g e
BG
P
Pe
erin
g e
BG
P
Figure 5 : Liens physiques entre les routeurs de la plateforme et le Backbone MPLS
Après cette présentation générale sur les interfaces physiques, nous aborderons la façon dont sont utilisés ces trois
liens physiques : le lien iBGP, le lien vers le Backbone MPLS (VRF « IPT-1 ») et le lien vers les fournisseurs de transit.
5.2.2 Le lien iBGP : utilisation des Pseudowires
Les deux routeurs IPTs, IPT-TH2 et IPT-GLS sont connectés entre eux par un pseudowire établi entre le PE de
TeleHouse2 et le PE de Globalswitch. Il s’agit bien d’un lien de couche 2 et d’un point de vue IP, ils sont donc
directement connectés et accessibles sur le même sous-réseau : 93.95.56.152/30 pour IPv4 et 2a02:2358:1:2::/64
pour IPv6.
Cependant, avec l’utilisation de ce pseudowire, bien que les routeurs IPTs ne le voient que comme un switch, un
problème qui surviendrait sur le lien n’est pas aussi facilement détecté par les protocoles de routage qu’avec
l’utilisation d’un vrai câble : les interfaces des routeurs restent actives, « up/up » et le sous-réseau est considéré
comme accessible. Par exemple, lorsque le PE de GLS redémarre ou encore lorsque le câble reliant IPT-GLS et le PE de
GLS est rompu, le lien reste actif du point de vue d’IPT-TH2.
Page 18
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
18
Ce type de panne doit être détecté par le protocole de routage : pour accélérer la convergence, on doit modifier la
valeur des timers de ces protocoles : ainsi, pour le lien iBGP (utilisant le pseudowire) nous avons dû donc appliquer
un intervalle « HoldTimer » de 15 secondes au lieu des 90 utilisées par défaut (RFC4271). D’autres mécanismes de
détections de pannes par envoi de paquets comme le protocole BFD auraient pu améliorer la détection des pannes
mais ils ne sont pas utilisés.
Configuration du pseudowire
Le pseudowire requis nécessite une configuration très simple : on utilise le VLAN 1029 des deux cotés pour joindre
les routeurs IPTs. Le pseudowire est monté entre les interfaces de Loopback des PEs, en utilisant le VC 1029. (Pour le
lien iBGP IPv6, nous avons choisi de créer d’autres sous-interfaces, utilisant un autre pseudowire).
Les sous-interfaces à configurer sur les PEs de TH2 et de GLS sont les suivantes :
! Sur le PE de TH2 (adresse IP locale : 10.129.1.27)
!
interface Port-channel90.1029
encapsulation dot1Q 1029
xconnect 10.129.1.29 1029 encapsulation mpls
! Sur le PE de GLS (adresse IP locale : 10.129.1.29)
!
interface Port-channel90.1029
encapsulation dot1Q 1029
xconnect 10.129.1.27 1029 encapsulation mpls
5.2.3 Les liens avec le Backbone MPLS : Les deux VRFs « IPT-1 »
Les VRFs « IPT-1 » sont situés sur les PEs de TH2 et de GLS. Le but de ces VRFs est d’interconnecter les routeurs IPTs
de la plateforme IP Transit avec le Backbone MPLS.
Les deux routeurs IPTs sont reliés au Backbone MPLS par une VRF nommé « IPT-1 » (et « IPT6-1 » pour IPv6), situés
sur les Pes de TH2 et de GLS. Les routeurs IPTs annoncent chacun uniquement une route par défaut IPv4 et IPv6 dans
ces deux VRFs dédiées au service IP Transit. Dans l’autre sens, ces VRFs IPT-1 annonce les préfixes assignés aux clients
vers les routeurs IPTs.
Ces VRFs IPT-1 retransmettent ensuite à toutes les VRFs IPT du Backbone la route par défaut qu’elles apprennent
depuis les routeurs IPTs. Ces VRFs IPT selon ensuite en mesure d’utiliser la route par défaut pour router les paquets
des clients.
Configuration des VRFs « IPT-1 » :
Ces deux VRFs IPT-1 ont donc une configuration simple, à l’exception d’une longue liste de route-target import (un
import pour chaque VRF IPT) : une seule interface et un seul voisin eBGP.
On remarque que l’on accepte ici qu’un seul préfixe de la part d’IPT-TH2, on vérifie que ce préfixe soit la route par
défaut. L’export-map appliqué est une autre protection : on exporte uniquement avec le route-target 3105 la route
par défaut, toutes les autres ont un route-target remplacé par 3186 (qui n’est importé dans aucune VRF du
Backbone).
Ces deux VRFs « IPT-1 » sont munis de RD différents et ne s’importent pas entre elles.
Voici la configuration de la VRF « IPT-1 » présente sur le PE de TH2, celle du PE de GLS lui ressemble fortement, seuls
les RD, le route-target export et les adresses IP indiquées changent :
Page 19
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
19
! Pour la VRF « IPT-1 » du PE de TH2
! (en rouge : ce qui change pour la VRF « IPT-1 » du PE de GLS)
!
ip vrf IPT-1
description === IPT - Plateforme IP Transit ===
rd 64512:3105
import map IPT-CLIENT-RT
export map IPT-EXPORT
route-target export 64512:3105
route-target import 64512:3120
route-target import 64512:3121
route-target import 64512:3122
route-target import 64512:3123
! 26 autres "route-target import 64512:xxxx" au total
!
!
!
router bgp 64512
!
address-family ipv4 vrf IPT-1
no synchronization
neighbor 93.95.56.142 remote-as 44902
neighbor 93.95.56.142 description === IPT-TH2 ===
neighbor 93.95.56.142 timers 5 15
neighbor 93.95.56.142 activate
neighbor 93.95.56.142 send-community
neighbor 93.95.56.142 soft-reconfiguration inbound
neighbor 93.95.56.142 route-map IPT-IPT-TH2-IN in
neighbor 93.95.56.142 maximum-prefix 100 1 restart 1
exit-address-family
!
interface Vlan1025
description === IPT - eBGP vers IPT-TH2 (IPv4) - IPT-TH2 Po91.1025 ===
ip vrf forwarding IPT-1
ip address 93.95.56.141 255.255.255.252
ip access-group IPT-CORE-OUT out
no ip redirects
no ip proxy-arp
!
!
route-map IPT-IPT-TH2-IN permit 10
match ip address prefix-list IPT-DEFAULT
route-map IPT-IPT-TH2-IN deny 20
!
route-map IPT-EXPORT permit 10
description Exporte la route par defaut avec le route-target prevu par la VRF
match ip address prefix-list IPT-DEFAULT
route-map IPT-EXPORT permit 20
description Exporte les autres routes avec un route-target importe nulle part
set extcommunity rt 64512:3186
!
!
ip prefix-list IPT-DEFAULT seq 5 permit 0.0.0.0/0
!
end
Nous pouvons voir, dans cette configuration :
Une seule interface (Vlan1025) configurée en point à point qui relie la VRF IPT-1 de TH2 à IPT-TH2 ;
Un seul voisin eBGP qui nous permet d’échanger des routes avec IPT-TH2 ;
Des imports de nombreux route-target (1 par VRF « IPT ») ;
Un filtrage de ce qu’envoie IPT-TH2, limitant à la seule route par défaut (0.0.0.0/0).
Configuration des routeurs IPTs vers les « VRFs IPT-1 » :
Sur le routeur IPT-TH2, on peut voir qu’un filtre est également appliqué pour ne transmettre aucun préfixe, à
l’exception de la route par défaut :
Page 20
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
20
! Sur IPT-TH2 (en rouge : ce qui change sur IPT-GLS)
!
interface Port-channel91.1025
description === IPT - eBGP vers GLS vrf IPT-1 (IPv4) - GLS Vlan1025 ===
encapsulation dot1Q 1025
ip address 93.95.56.150 255.255.255.252
!
!
!
router bgp 44902
neighbor 93.95.56.149 remote-as 64512
neighbor 93.95.56.149 description === CORE (vrf IPT-1) ===
neighbor 93.95.56.149 timers 5 15
!
address-family ipv4
neighbor 93.95.56.149 activate
neighbor 93.95.56.149 send-community both
neighbor 93.95.56.149 default-originate route-map IPT-CORE-DEFAULT-OUT
neighbor 93.95.56.149 soft-reconfiguration inbound
neighbor 93.95.56.149 route-map IPT-CORE-IN in
neighbor 93.95.56.149 route-map IPT-CORE-OUT out
exit-address-family
!
!
!
route-map IPT-CORE-IN permit 10
match ip address prefix-list IPT-COVAGE-LONGER
!
route-map IPT-CORE-IN permit 20
match ip address prefix-list IPT-CLIENT
!
route-map IPT-CORE-IN deny 300
!
route-map IPT-CORE-OUT deny 10 ! Interdiction de toutes les annonces
!
route-map IPT-CORE-DEFAULT-OUT permit 10 ! Uniquement pour la route par défaut
set metric 400
!
5.2.4 Les liens avec les fournisseurs de transit
Les routeurs IPTs sont reliés aux fournisseurs de transit et échangent avec eux la table de routage Internet à l’aide de
BGP de manière traditionnelle. Cependant, le routeur n’est pas physiquement relié à ces fournisseurs mais traverse
aussi les PEs de TH2 et de GLS : ces PEs ne sont alors utilisés pour ces liens que comme un simple commutateur
Ethernet, les interfaces vers les fournisseurs sont en mode accès alors que l’interfaces vers le routeur IPT est en trunk
avec un VLAN par fournisseur.
Les routeurs IPTs de la plateforme voient donc tous les fournisseurs sur une seule interface physique (Po92) sur
laquelle chacun des fournisseurs est configuré sur une sous-interface différente : IPT-TH2 a deux fournisseurs de
transit placés sur Po92.1030 pour Neo Telecoms, Po90.1031 pour Level3 ; IPT-GLS n’a qu’un fournisseur de transit,
Neo Telecoms (placé sur Po92.1030).
Le but de ce design est de permettre à l’interconnexion vers les fournisseurs de supporter d’autres services dans le
futur, sans multiplier les interconnexions physiques entre le fournisseur et les PEs de TH2 ou de GLS. Actuellement,
ces liens ne supportent que le service de transit IP, les autres services étant traités sur des liens plus anciens, comme
l’ancien service de transit fournis par Level3.
Le regroupement des différents liens vers les fournisseurs de transit sur une même interface physique (Po92) permet
également d’appliquer un policing unique sur l’interface physique des routeurs IPTs et donc de limiter les débits
entrants par les fournisseurs. Nous aborderons ultérieurement le sujet du policing qui est appliqué sur cette interface
physique.
Page 21
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
21
5.3 Connexion des clients au service IP Transit : les VRFs « IPT »
Ces VRFs « IPT » du Backbone ont pour but de connecter les clients au service d’IP Transit. Les VRFs « IPT » importent
uniquement les deux routes par défaut émises des VRFs « IPT-1 », d’où les route-targets import de 64512:3105 et
64512:3107.
Soulignons qu’il n’existe pas de communication directe entre les VRFs « IPT » de même qu’il n’existe aucun import
entre les VRFs « IPT-1 ». Les imports ne se font qu’entre les « IPT » et les « IPT-1 ». Les VRFs « IPT-1 » annonçant
chacune une route par défaut (0.0.0.0/0), apprises des routeurs IPTs, alors que les VRFs « IPT » annoncent les
préfixes assignés aux clients (exemple : 93.95.56.0/26).
Par conséquent, les paquets d’une VRF « IPT » à une autre VRF « IPT » repassent systématiquement par l’une des
VRFs « IPT-1 ». Cependant, on peut noter que cela n’augmente pas réellement le nombre d’équipements traversés
par les paquets, car les deux PEs de TH2 et de GLS supportant ces VRFs IPT-1 sont situés au cœur du Backbone MPLS,
tous les autres PEs étant attachés à ces équipement centraux.
Toutes les VRFs utilisent des routes distinguisher (rd) et des route-target différents, ce qui permet de mieux contrôler
les annonces des routes : l’usage de RDs différents permet, notamment, d’avoir les deux routes par défaut présentes
dans les VRFs IPT des PE alors qu’avec un unique RD, les route-reflectors n’annoncent que la route par défaut qu’ils
sélectionnent.
La configuration de cette VRF « IPT » la plus simple est :
! Sur un PE du Backbone MPLS
!
ip vrf IPT
rd 64512:3120
route-target export 64512:3120 # RT importé uniquement dans les VRFs IPT-1 de TH2 et de GLS
route-target import 64512:3105 # Import de la route par défaut des VRFs IPT-1 de TH2
route-target import 64512:3107 # Import de la route par défaut des VRFs IPT-1 de TH2
!
!
ip route vrf IPT 10.0.0.0 255.0.0.0 Null0 tag 1918
ip route vrf IPT 172.16.0.0 255.240.0.0 Null0 tag 1918
ip route vrf IPT 192.168.0.0 255.255.0.0 Null0 tag 1918
!
router bgp 64512
!
address-family ipv4 vrf IPT
no synchronization
redistribute connected
redistribute static route-map IPT-RFC1918
maximum-paths ibgp 2
exit-address-family
!
interface GigabitEthernet3/5
ip vrf forwarding IPT
ip address 93.95.58.1 255.255.255.252
!
!
route-map IPT-RFC1918 deny 10
match tag 1918
route-map IPT-RFC1918 permit 100
!
end
Dans cet exemple de VRF IPT :
Une VRFs avec un seul client connecté sur l’interface Gi3/5, le client n’ayant lui-même qu’une seule adresse
IP assignée (93.95.58.2).
Les routes statiques permettent d’éviter l’envoi de paquet à destination de plage d’adresses privée. La
redistribution de ces trois routes ne doit pas être faite et est bloquée par la route-map IPT-RFC1918.
Page 22
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
22
Le route-target 3120 est réservé à cette VRF et n’est importé que dans les VRFs « IPT-1 » (sur les PEs de TH2
et de GLS). Le préfixe 93.95.58.0/30 arrivera alors directement dans ces VRFs et sera annoncé aux deux
routeurs IPT.
Cette VRF est destinée à évoluer en fonction des activations clients, elle doit donc être simple et permettre la
modification fréquente. Par ailleurs, elle ne subit pas de modification majeure avec le changement de la plateforme
IP Transit (contrairement aux deux VRFs « IPT-1 »).
Du point de vue routage, on peut observer très simplement le fonctionnement sur le PE lui-même comme indiqué ci-
dessous :
! Sur un PE (quelconque) du Backbone MPLS
>show bgp vpnv4 unicast vrf IPT
BGP table version is 360, local router ID is 10.129.1.9
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 64512:3120 (default for vrf IPT)
*>i0.0.0.0 10.129.1.27 200 100 0 44902 i
* i0.0.0.0 10.129.1.29 400 100 0 44902 i
*> 93.95.58.0/30 0.0.0.0 0 32768 ?
>show ip route vrf IPT
Gateway of last resort is 10.129.1.27 to network 0.0.0.0
B* 0.0.0.0/0 [200/200] via 10.129.1.27, 6d16h
S 10.0.0.0/8 is directly connected, Null0
93.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 93.95.58.0/30 is directly connected, GigabitEthernet3/5
L 93.95.58.1/32 is directly connected, GigabitEthernet3/5
S 172.16.0.0/12 is directly connected, Null0
S 192.168.0.0/16 is directly connected, Null0
La présence de la route par défaut est assurée par les VRFs IPT-1 de TH2 (10.192.1.27) et GLS (10.192.1.29). La route
du client (93.95.58.0/30) est exportée par la VRF (ici, avec le route-target 64512:3120) qui ne sera importée que par
les VRFs « IPT-1 ».
Page 23
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
23
5.4 Absence d’import entre les VRFs « IPT » et propagation des routes
On a déjà noté l’absence de communication entre les nombreuses VRFs « IPT », cette partie présente l’implication
que cela a dans le routage au cours d’une communication entre clients.
Le label propagé pour la route par défaut ne porte pas la mention « IPv4 VRF Aggr » comme les autres routes ont sur
les PEs du Backbone, la route par défaut à un traitement spécial : lorsqu’un paquet porte le label de cette route
(389), il est directement envoyé au prochain saut qui est 93.95.56.146 sur l’interface Vlan1025 (c’est IPT-TH2). Par
ailleurs, le champ TTL d’IP est décrémenté, de manière à ce que la VRF « IPT-1 » du PE de TH2 soit visible au
traceroute.
Dans cet extrait, on peut voir que la route par défaut exportée par le PE de TH2, portant le label 389 n’est pas
« Aggr ». Le label n’est pas « aggregate/IPT-1 » mais à une interface et une adresse IP :
# Sur le PE de TH2
LAB-7609-TH2>show bgp vpnv4 unicast vrf IPT-1 0.0.0.0 0.0.0.0
BGP routing table entry for 64512:3105:0.0.0.0/0, version 56
Paths: (2 available, best #1, table IPT-1)
Advertised to update-groups:
1 2
44902
93.95.56.146 from 93.95.56.146 (93.95.56.110)
Origin IGP, metric 200, localpref 100, valid, external, best
Extended Community: RT:64512:3105
mpls labels in/out 389/nolabel
44902, (received-only)
93.95.56.146 from 93.95.56.146 (93.95.56.110)
Origin IGP, metric 200, localpref 100, valid, external
mpls labels in/out 389/nolabel
LAB-7609-TH2#show mpls forwarding-table vrf IPT-1
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
19 Pop Label IPv4 VRF[V] 0 aggregate/IPT-1
389 No Label 0.0.0.0/0[V] 1428 Vl1025 93.95.56.146
Par exemple, un traceroute depuis le PE de CREUSOT est représenté comme ci-dessous :
# Sur le PE de CREUSOT
LAB-7603-CREUSOT#traceroute vrf IPT 93.95.63.2
Type escape sequence to abort.
Tracing the route to 93.95.63.2
1 93.95.56.146 [MPLS: Label 389 Exp 0] 0 msec 4 msec 0 msec # TH2 via la route par défaut
2 93.95.56.147 0 msec 0 msec 0 msec # IPT-TH2 imposé par le “next hop” du label 389
3 93.95.56.146 0 msec 0 msec 0 msec # TH2 via la route 93.95.63.0/24
4 93.95.63.2 0 msec * 0 msec # JURA via la route 93.95.63.0/24 (label 20)
On peut le comparer avec le label que propose le PE de CREUSOT sur plusieurs routes dont vous trouverez ci-joint le
modèle :
# Sur le PE de CREUSOT
LAB-7603-CREUSOT#show bgp vpnv4 unicast vrf IPT 93.95.58.0
BGP routing table entry for 64512:3120:93.95.58.0/24, version 39
Paths: (1 available, best #1, table IPT)
Multipath: iBGP
Advertised to update-groups:
1
Local
0.0.0.0 from 0.0.0.0 (10.129.1.9)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
Extended Community: RT:64512:3120
mpls labels in/out IPv4 VRF Aggr:19/nolabel(IPT)
Page 24
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
24
Voici le schéma représentant le parcours des paquets depuis un client de JURA vers un client de CREUSOT (en bleu
les annonces BGP et MP-BGP, en rouge le parcours des paquets) :
IPT-TH2 IPT-GLS
TH2 vrf IPT-1
64512:3105: 0.0.0.0/0
JURA vrf IPT
CREUSOT vrf IPTPaquet d’un client de JURA
vers un client de CREUSOT
src: 93.95.58.114, dst: 93.95.63.2
64512:3120: 93.95.63.0/24
93.95.63.0/24
0.0.0.0/0
Retransmission MP-iBGP :
64512:3105: 0.0.0.0/0
Annonce MP-iBGP :
64512:3132: 93.95.58.112/30
Annonce MP-iBGP :
64512:3120: 93.95.63.0/24
93.95.63.0/24
Annonce eBGP :
0.0.0.0/0
Paquet envoyé à IPT-TH2
sans consultation de la
table de routage Retransmission eBGP :
93.95.58.112/30
93.95.63.0/24
AS44902
Figure 6 : Communication entre deux clients IP Transit
5.5 Annonces inconditionnelles des routes par défaut et cas de pannes
Dans l’architecture précédente, basée sur OSPF, l’annonce de la route par défaut traversait le lien physique sur lequel
les fournisseurs de transit étaient connectés (Po92), la perte de ce lien entrainait donc immédiatement l’arrêt de
l’annonce de la route par défaut vers les VRFs « IPT ».
Dorénavant, en cas de perte des liens vers les fournisseurs de transit ainsi que du lien iBGP, les routeurs IPTs
continuent d’annoncer inconditionnellement la route par défaut dans les VRFs « IPT-1 » du Backbone qui la propage
aux VRFs « IPT ».
! Sur IPT-TH2
!
router bgp 44902
!
address-family ipv4
neighbor 93.95.56.145 default-originate route-map IPT-CORE-DEFAULT-OUT
exit-address-family
!
address-family ipv6
neighbor 2A02:2358:1:1::27 default-originate route-map IPT6-CORE-DEFAULT-OUT
exit-address-family
!
Page 25
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
25
Nous pouvons alors imaginer deux problèmes potentiels :
En cas de panne du lien vers le fournisseur, le routeur IPT-GLS devra utiliser le lien iBGP pour rediriger
l’intégralité du trafic vers les fournisseurs du routeur IPT-TH2. Cette panne engendrerait un cas de routage
non-optimal.
En cas de panne simultanée du fournisseur et du lien iBGP, le routeur IPT-TH2 ou IPT-GLS risque de recevoir
des paquets pour lesquels il ne possède plus de route et donc d’interrompre totalement les flux montants.
Ce cas n’est pas forcément un cas de double panne, si ces liens sont sur une même carte ou une même
interface physique.
Pour éviter de se retrouver dans cette situation, il faut obligatoirement séparer au maximum le lien supportant les
fournisseurs et le lien iBGP (entre IPT-TH2 et TH2 comme entre IPT-GLS et GLS), au niveau des interfaces physiques et
des câbles empruntés ainsi que par les cartes matérielles utilisées sur les PE de TH2 et GLS. Notons pour une
éventuelle amélioration qu’il serait possible de modifier ce comportement en rendant cette annonce conditionnelle,
via l’usage de route-map.
5.6 Propagation des annonces BGP
5.6.1 Les annonces BGP pour les flux descendants depuis Internet vers les clients
L’ancienne architecture utilisait la redistribution de routes apprises par OSPF dans BGP pour générer l’annonce des
préfixes Covage envoyés ensuite aux fournisseurs de transit. Ces annonces étaient donc vues comme des nouvelles
routes dans BGP, avec un AS_PATH vide.
Dans la nouvelle architecture, ces préfixes arrivent par eBGP depuis les VRFs « IPT-1 » : les deux cas sont traités
différemment, selon qu’il s’agisse des préfixes IPT-CLIENT qui doivent être retransmis aux fournisseurs de transit ou
IPT-COVAGE qui sont spécifiques à chaque client et doivent être agrégés (en deux /21) :
Les préfixes IPT-CLIENT qui sont annoncés sur Internet sont donc ceux qui ont été émis à l’origine par la VRF
« IPT » située sur un PE régional. Comme cette information arrive depuis le Backbone, par MP-BGP, il porte
le numéro d’AS du Backbone qui est un numéro privé : 64512. Leur annonce sur l’Internet publique impose
donc le retrait de ce numéro d’AS privé que les annonces portent dans l’attribut AS_PATH, cela peut être
fait très simplement avec la commande « neighbor … remove-private-as » appliquée sur les voisins eBGP
que sont les fournisseurs de transit Neo Telecoms et Level3.
Dans le cas d’annonces des préfixes IPT-COVAGE, les routeurs IPTs apprennent des préfixes spécifiques à
chaque assignation client (de /24 à /30) alors qu’il faut annoncer sur Internet un préfixe le plus générique
possible : les deux /21 assignés à Covage. La création de ce préfixe générique peut se faire à l’aide de la
commande « aggregate-address » dans BGP. Le processus BGP ne crée ce préfixe générique qu’en présence
d’au moins un préfixe inclus dedans : cette commande crée une annonce qui porte également deux
attributs très liés au mécanisme agrégation (ATOMIC_AGGREGATE et AGGREGATOR). Ce dernier indique
que l’agrégation a été réalisée par l’AS de Covage (AS44902) et par les routeurs IPT-TH2 ou IPT-GLS ayant
respectivement les router-id 93.95.56.110 ou 93.95.56.111.
Le schéma suivant montre la propagation des annonces pour deux préfixes spécifiques 93.95.56.112/30 et
93.95.63.0/24 assignés à des clients :
Page 26
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
26
Level3
AS3356
Neo Telecoms
AS8218
IPT-TH2 IPT-GLS
TH2 vrf IPT-1
Aggrégation des préfixes précifiques /24, /26, /30 en
deux préfixes IPT-COVAGE plus génériques.
(L’aggrégation ne se fait ni sur les préfixes marqué
« NO_EXPORT », ni sur le préfixe de rueil).
109.205.64.0/21
router bgp 44902
address-family ipv4
aggregate-address 178.22.144.0 255.255.248.0 advertise-map IPT-AGGREGATION
aggregate-address 93.95.56.0 255.255.248.0 advertise-map IPT-AGGREGATIONset community no-export
93.95.58.112/30
93.95.63.0/24
Préfixe aggrégé IPT-COVAGE :
93.95.56.0/21 (ou 178.22.144.0/21)
Préfixe IPT-CLIENT :
109.205.64.0/21 ou 109.239.112.0/23
Deux préfixes assigné à des clients
dans une plage alloué à Covage.
GLS vrf IPT-1
JURA vrf IPT
CREUSOT vrf IPT
XXX vrf IPT
Figure 7 : Propagation des routes utilisées pour les flux descandants depuis les Internet vers les clients
La propagation des annonces suit le chemin :
Les VRFs « IPT » des PE régionaux JURA et CREUSOT annoncent en MP-BGP aux deux VRFs « IPT-1 » des PEs
de TH2 et GLS ;
Les VRFs « IPT-1 » des PEs de TH2 et GLS les annoncent en eBGP aux routeurs IPTs ;
Les routeurs IPTs agrègent ces préfixes en 93.95.56.0/21 et les envoient aux fournisseurs de transit.
Les préfixes Covage (93.95.56.0/21 et 178.22.148.0/21) annoncés sur Internet entraient auparavant dans BGP par
une redistribution d’OSPF dans BGP. Il s’agit maintenant d’une agrégation (en /21) de préfixes plus spécifiques (/24 à
/30) apprises par un AS privé (AS64512) en BGP. Les annonces BGP sont donc perçues différemment pour les
routeurs d’Internet : l’attribut ORIGIN à la valeur « IGP » plutôt que « INCOMPLETE » (cet attribut entre en compte
dans l’algorithme de choix du meilleur chemin), les attributs AGGREGATOR et ATOMIC_AGGREGATE ajoutés ne sont
là qu’à titre informatif.
Voici donc le processus de réception des préfixes qu’un système autonome ayant des liens avec nos deux
fournisseurs de transit devrait avoir (d’après les observations faites sur le looking-glass de Jaguar Network, les
chemins moins intéressants car plus long ont été supprimés) :
# Sur le looking-glass de l’opérateur Jaguar Networks (http://extranet.jaguar-network.com/)
>show bgp ipv4 unicast 93.95.56.0/21
BGP routing table entry for 93.95.56.0/21, version 69196869
Paths: (12 available, best #2, table default)
Advertised to update-groups:
1 2
Page 27
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
27
3356 44902, (aggregated by 44902 93.95.56.110)
212.73.207.161 from 212.73.207.161 (4.68.3.205)
Origin IGP, metric 20000, localpref 75, valid, external, atomic-aggregate
Community: 3356:2 3356:22 3356:100 3356:123 3356:502 3356:2066 30781:75
8218 44902, (aggregated by 44902 93.95.56.111)
193.105.232.1 from 193.105.232.1 (83.167.63.20)
Origin IGP, metric 111, localpref 90, valid, external, atomic-aggregate, best
Community: 8218:101 30781:3375 30781:8218 30781:65000
8218 44902, (aggregated by 44902 93.95.56.111)
194.68.129.202 from 194.68.129.202 (83.167.63.20)
Origin IGP, metric 111, localpref 90, valid, external, atomic-aggregate
Community: 8218:101 30781:3375 30781:8218 30781:65000
! 9 autres chemins supprimés
5.6.2 Les annonces BGP pour les flux montants depuis les clients vers Internet
Dans le sens montant, il n’existe aucune difficulté particulière :
il s’agit d’un routage basé sur la table de routage complète d’Internet pour les routeurs IPTs de la
plateforme : IPT-TH2 et IPT-GLS ;
un routage basé sur la propagation d’une route par défaut par MP-iBGP et eBGP dans les VRFs du
Backbone.
Le schéma suivant nous montre bien, la propagation de la table de routage Internet dans la plateforme IP Transit
d’une part, ainsi que la propagation des deux routes par défaut d’autre part :
Level3
AS3356
Neo Telecoms
AS8218
IPT-TH2 IPT-GLS
TH2 vrf IPT-1
router bgp 44902
address-family ipv4
neighbor 93.95.56.145 default-originate
route-map IPT-CORE-DEFAULT-OUT
!
route-map IPT6-CORE-DEFAULT-OUT permit 10
set metric 200
Route par défault 0.0.0.0/0
émise par IPT-TH2
router bgp 44902
address-family ipv4
neighbor 93.95.56.149 default-originate
route-map IPT-CORE-DEFAULT-OUT
!
route-map IPT6-CORE-DEFAULT-OUT permit 10
set metric 400
GLS vrf IPT-1
show bgp vpnv4 unicast vrf IPT
*>i0.0.0.0 10.129.1.27 200 100 0 44902 i
* i 10.129.1.29 400 100 0 44902 i
*> 93.95.63.0/24 0.0.0.0 0 32768 ?
Envoie de toutes les
routes d’internet
Route par défault 0.0.0.0/0
émise par IPT-GLS
Figure 8 : Propagation des routes utilisées pour les flux montants depuis les clients vers Internet
Page 28
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
28
La route par défaut est annoncée par IPT-TH2 dans la VRF « IPT-1 » du PE de TH2 et par IPT-GLS dans la VRF « IPT-1 »
du PE de GLS (ou les VRFs « IPT6-1 » pour IPv6). Ces routes par défaut sont exportées dans le Backbone par les route-
target 64512:3105 et 64512:3107 respectivement. Ces deux route-target sont importées dans les VRFs « IPT » du
Backbone : ces VRFs reçoivent donc simplement deux routes par défaut, dont la meilleure est sélectionnée par
l’attribut MULTI_EXIT_DISC. Lorsque cet attribut est identique, un équilibrage de charge a lieu, grâce à la commande
« maximum-paths ibgp 2 » utilisée dans toutes les VRFs « IPT » et « IPT6 » du Backbone.
Voici donc les commandes émettant l’annonce de la route par défaut en IPv4 et IPv6 :
! Sur IPT-GLS (en rouge : ce qui est différent sur IPT-TH2)
!
router bgp 44902
!
address-family ipv4
neighbor 93.95.56.149 default-originate route-map IPT-CORE-DEFAULT-OUT
exit-address-family
!
address-family ipv6
neighbor 2A02:2358:2:1::29 default-originate route-map IPT6-CORE-DEFAULT-OUT
exit-address-family
!
!
route-map IPT-CORE-DEFAULT-OUT permit 10
set metric 400
!
end
Sur la VRFs « IPT » d’un PE quelconque (celui qui héberge un client 93.95.63.0/24) on peut voir les deux routes par
défaut apprisses au travers des VRFs « IPT-1 » (NEXT_HOP 10.192.1.27 et RT:3105 pour celle de TH2 et NEXT_HOP
10.192.1.29 RT:3107 pour celle de GLS) :
! Sur un PE (quelconque) du Backbone, une VRF IPv4
!
>show bgp vpnv4 unicast vrf IPT
BGP table version is 853, local router ID is 10.129.1.69
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 64512:3112 (default for vrf IPT)
*>i0.0.0.0 10.129.1.27 200 100 0 44902 i
* i 10.129.1.29 400 100 0 44902 i
*> 93.95.63.0/24 0.0.0.0 0 32768 ?
>show bgp vpnv4 unicast vrf IPT 0.0.0.0 0.0.0.0
BGP routing table entry for 64512:3132:0.0.0.0/0, version 853
Paths: (2 available, best #1, table IPT)
Advertised to update-groups:
1 2
44902
10.192.1.27 from 10.192.1.27 (10.192.1.27)
Origin IGP, metric 200, localpref 100, valid, internal, best
Extended Community: RT:64512:3105
mpls labels in/out nolabel/37
44902
10.192.1.29 from 10.192.1.29 (10.192.1.29)
Origin IGP, metric 400, localpref 100, valid, internal, best
Extended Community: RT:64512:3107
mpls labels in/out nolabel/83
Sur les routeurs IPTs, les flux sont traités par les routes apprisses en BGP, ils possèdent la table de routage complète
d’Internet, cette table de routage est apprise par les deux fournisseurs de transit en eBGP.
Page 29
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
29
5.6.3 Utilisation de l’attribut de communauté NO_EXPORT sur la session iBGP
Pour réduire le routage non-optimal sur les flux descendants, nous utilisons l’attribut de communauté NO_EXPORT
sur les préfixes annoncés entre IPT-TH2 et IPT-GLS : de cette manière, si IPT-TH2 perd sa connexion avec la VRF IPT-1
du PE de TH2, il cesse d’annoncer tous les préfixes Covage et clients aux fournisseurs de transit. Ces deux types de
préfixe, sont traités légèrement différemment étant donné que le préfixe Covage annoncé est issu de l’agrégation.
Les attributs de communautés sont des attributs permettant d’appliquer une politique commune à toutes les
annonces portant ces attributs. Trois de ces attributs sont « bien connus » et doivent être implémenté par le logiciel.
Dans le cas de l’attribut NO_EXPORT, ayant pour valeur 0xFFFFFF01, l’action appliquée est de ne pas transmettre
l’annonce à un autre AS. Il n’y a donc rien de particulier à configurer sur les liens eBGP : la simple application de cet
attribut confine l’annonce à notre AS 44902.
En revanche, pour les préfixes Covage, on applique l’attribut de communauté NO_EXPORT même aux préfixes plus
spécifiques (comme 93.95.61.0/26) puis on demande à ce que le préfixe agrégé (comme 93.95.56.0/21) ne soit pas
généré si les préfixes spécifiques portent cet attribut NO_EXPORT.
La méthode est la suivante : Il faut appliquer deux route-map :
L’une concerne l’attribut de communauté NO_EXPORT aux routes sortantes sur iBGP
L’autre conditionne la création du préfixe agrégé grâce à la commande « aggregate-address … advertise-
map ».
Voici donc la configuration nécessaire sur les routeurs IPTs pour réduire ce routage non optimal :
! Sur IPT-TH2 (en rouge : ce qui change sur IPT-GLS)
!
router bgp 44902
address-family ipv4
! Les deux préfixes « IPT-COVAGE » alloués à Covage par le RIPE-NCC
aggregate-address 178.22.144.0 255.255.248.0 advertise-map IPT-AGGREGATION
aggregate-address 93.95.56.0 255.255.248.0 advertise-map IPT-AGGREGATION
! route-map appliqué aux NLRI sortantes sur le lien iBGP (vers IPT-GLS)
neighbor 93.95.56.154 route-map IPT-IBGP-OUT out
exit-address-family
!
!
route-map IPT-IBGP-OUT permit 10
match ip address prefix-list IPT-COVAGE-LONGER
set community no-export additive
!
route-map IPT-IBGP-OUT permit 20
match ip address prefix-list IPT-CLIENT
set community no-export additive
!
route-map IPT-IBGP-OUT permit 300
!
!
route-map IPT-AGGREGATION deny 10
description Ne pas aggreger les routes venant en iBGP (marquees de no-export)
match community IPT-NOEXPORT
!
route-map IPT-AGGREGATION permit 20
match ip address prefix-list IPT-COVAGE-AGGREGABLE
!
5.6.4 Contrôle des flux montant et descendants
Le contrôle des flux peut se faire par BGP en modifiant
les annonces envoyées aux fournisseurs pour les flux descendants
les annonces reçues des fournisseurs pour les flux montants.
Page 30
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
30
5.6.4.1 Les flux descendants
Bien que les annonces BGP nous permettent un contrôle assez fin sur la manière dont les flux sont routés dans
Internet, nous avons choisi de laisser arriver les flux descendants de manière la plus naturelle possible sans privilégier
un fournisseur plutôt qu’un autre (donc sans modifier l’AS_PATH de nos annonces) et sans privilégier un lien plutôt
qu’un autre (donc sans appliquer de valeurs à la MULTI_EXIT_DISC de nos annonces).
En ce qui concerne les flux entrants, nous préférons ne pas agir sur les attributs BGP pour les préfixes que
nous annonçons pour laisser au maximum le choix du meilleur chemin, donc préférer que le flux
descendant traverse le moins d’AS possibles. Cette politique nous conduit à un équilibre moyen entre les
fournisseurs de transit : Neo Telecoms nous envoie environ 60% de notre trafic en entrée, ce qui pose des
problèmes de facturation : en effet, le forfait de 100Mbps n’étant pas entièrement consommé pour Level3
mais dépassé pour Neo Telecoms.
En ce qui concerne les deux liens Neo Telecoms : en nous permettant d’accéder à l’un de leurs routeurs
pour consulter la table de routage, nous avons pu observer que les annonces faites vers leur routeur de
GlobalSwitch se voient assigner une valeur de 10 à attribut MULTI_EXIT_DISC alors que les annonces que
nous faisions vers leur routeur de TeleHouse2 se voient assigner une valeur de 30. C’est donc le lien passant
par IPT-GLS qui est le plus sollicité : la route passant par GlobalSwitch sera plutôt choisie par leurs routeurs.
Cependant, nous pouvons observer aussi qu’une très faible partie continue d’arriver par le lien Neo
Telecoms de TeleHouse2. On peut donc supposer que l’algorithme de sélection sur TeleHouse2 choisit le
lien eBGP (car cette étape se produit avant dans l’algorithme de sélection). Les paquets arrivant dans l’AS
de Neo Telecoms par leur routeur de TeleHouse2 seraient donc directement envoyés à notre routeur IPT-
TH2 plutôt que d’aller vers leur routeur de GlobalSwitch pour ensuite entrer dans notre AS par le routeur
IPT-GLS.
Une fois arrivé sur la plateforme, le flux entant est ensuite directement envoyé par les routeurs IPTs aux VRF « IPT-
1 » du Backbone, sans utiliser le lien iBGP (à l’exception du client Rueil en IPv6).
Pour la gestion de ces annonces vers les fournisseurs de transit, nous avons quatre choix qui s’offrent à nous, nous
permettant des changements avec plus ou moins d’amplitude :
La modification de l’attribut MULTI_EXIT_DISC, seulement pour le cas d’un fournisseur avec lequel nous
possédons plusieurs liens. Or, cette modification ne semble pas pertinente pour Neo Telecoms car la
facturation est basée sur la somme de l’usage des liens et l’arrivée des flux dans le Backbone MPLS par le PE
de TH2 ou le PE de GLS et n’influe pas sur la qualité du service.
La copie de notre numéro d’AS dans l’AS_PATH nous permet de gérer chaque annonce dans l’Internet
finement.
Bien que non destiné à cela, l’attribut ORIGIN est modifiable et permet de proposer un choix à un AS distant
s’il reçoit notre annonce avec deux longueurs d’AS_PATH identiques. Cette modification n’est pas encore
effectuée. Cependant, lors de la phase de migration, l’annonce IPT-CLIENT possédait bien une ORIGIN
différente (IGP pour IPT-TH2 dans l’ancienne configuration contre INCOMPLETE pour le nouvel IPT-GLS).
Les fournisseurs nous proposent de modifier la LOCAL_PREF de notre route dans leur AS, au travers de
l’attribut de communauté. En appliquant la communauté « 3356:70 » sur les préfixes annoncés à Level3, le
fournisseur applique un LOCAL_PREF de 70. Cette modification est extrême : bien que nous ne l’ayons
jamais utilisée, elle conduirait le fournisseur à passer par un autre fournisseur : tout le trafic passerait donc,
en réalité, par le second fournisseur.
Page 31
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
31
5.6.4.2 Les flux montants
Dans le sens montant, nous n’avons pas de préférence entre les fournisseurs de transit, nous laissons également BGP
choisir le meilleur chemin selon son algorithme de sélection, sans modifier la LOCAL_PREF par défaut ou les attributs
envoyés par nos voisins.
L’objectif est de laisser faire au mieux BGP et nous préférions utiliser le lien entre IPT-TH2 et IPT-GLS dont nous
maitrisons la qualité plutôt que de prendre un chemin qui serait moins optimal du point de vue du fournisseur.
Pour les flux montants :
La longueur de l’AS_PATH est avant tout autre chose prise en compte par nos routeurs (sans modifier la
LOCAL_PREF) pour choisir en premier lieu les chemins les plus courts en termes d’AS traversés.
Certains AS préfèrent que nos flux montants vers leurs réseaux passent par Neo Telecoms plutôt que par
Level3 : nous recevons les annonces depuis Level3 avec l’AS_PATH répétées plusieurs fois : Le système
autonome 12322 (Proxad) a au moins deux fournisseurs de transit : 174 (Cogent) et 8218 (Neo Telecoms). Il
préfère visiblement utiliser le moins possible le 174. L’absence de modification des LOCAL_PREF sur nos
deux fournisseurs de transit (3356 et 8218) impose à nos routeurs d’utiliser 8218 comme le souhaite
Proxad. Dans le cas où la route apprise via 3356 est éliminée par la longueur de l’AS_PATH, il ne reste plus
que des routes apprises par 8218, la MULTI_EXIT_DISC (« metric ») est alors prise en compte dans la
comparaison.
Enfin, nous préférons ne pas modifier les valeurs des MULTI_EXIT_DISC des annonces transmisses par Neo
Telecoms : lors de la comparaison entre les deux routes passantes par ce fournisseur, BGP choisira celle qui
convient le plus à la société Neo Telecoms. Notons cependant que pour les préfixes annoncés avec un
AS_PATH aussi long du coté de Level3 que du coté de Neo Télécoms, la valeur de la MULTI_EXIT_DISC ne
sera pas prise en compte et l’étape suivante éliminera le chemin passant pas IPT-GLS car apprise par iBGP
(marqué « internal »).
Neo Telecoms (AS8218) nous propose pour une majorité de routes une valeur de MULTI_EXIT_DISC plus basse sur
GlobalSwitch (0) que sur TeleHouse2 (11). Le routeur IPT-TH2 utilisera donc la route vers le routeur Neo Telecom de
GlobalSwitch en passant par IPT-GLS.
Les annonces de Proxad (AS12322) me semblent un cas intéressant à observer, nous respectons leur choix de
préférer Neo Telecoms plutôt que Cogent (choix par l’AS_PATH) et nous respectons le choix de Neo Telecom de
passer par GlobalSwitch (choix réalisé par la valeur de l’attribut MULTI_EXIT_DISC) :
# Sur IPT-TH2
IPT-TH2>show bgp ipv4 unicast 78.192.0.0/10
BGP routing table entry for 78.192.0.0/10, version 154998486
Paths: (3 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
8218 12322, (received & used)
83.167.32.45 from 93.95.56.154 (93.95.56.111)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: 8218:102
8218 12322, (received & used)
83.167.32.41 from 83.167.32.41 (83.167.63.11)
Origin IGP, metric 11, localpref 100, valid, external
Community: 8218:102
3356 174 12322 12322 12322 12322 12322 12322, (received & used)
213.242.111.109 from 213.242.111.109 (4.68.187.231)
Origin IGP, metric 0, localpref 100, valid, external
Community: 3356:2 3356:22 3356:86 3356:500 3356:666 3356:2064
Page 32
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
32
5.7 Les ACLs et le policing appliqués sur la plateforme IP Transit
Les ACLs qui sont deployées sur les routeurs de la plateforme IP Transit ont trois objectifs :
Nettoyer le réseau de paquets non conformes à un routage sur Internet ;
Protéger les équipements des réseaux de paquets pouvant lui être nocifs ;
Protéger le réseau et les clients des paquets usurpés.
Le nettoyage consiste à détruire les paquets dont la source ou la destination ne font pas partis des adresses routables
globalement (telles que les adresses privées, les adresses réservées à la documentation, les adresses multicast, etc).
La création de cette liste de plages d’adresses interdites peut être faite à partir de recherches sur Internet : le
registre de l’espace d’adressage IPv4 de l’IANA permet de connaitre l’usage de chaque plage IP, les RFCs associées
donnent les raisons et l’usage qui doit être fait de ces adresses IP.
L’objectif de protection du réseau quand à lui est spécifique à l’architecture que chaque organisation met en place :
dans le cas de l’IP Transit, nous souhaitons protéger la plateforme mais aussi le Backbone sur lequel fonctionne une
grande partie des services commercialisés par l’entreprise. Il faut donc ici bloquer chaque plage IP ou chaque adresse
une par une, et gérer l’ensemble de ces ACLs en fonction des évolutions, que ce soit de la plateforme IP Transit ou
pour chaque nouveau client.
5.7.1 L’ACL appliquée en sortie vers Internet : IPT-ALL-IF-OUT
L’ACL à appliquer en sortie vers Internet se limite à un nettoyage pour supprimer les paquets qui seraient inutiles. Les
paquets qui pourraient être nocifs à la session BGP sont déjà supprimés en amont, par les ACLs placées en entrée de
la plateforme IP Transit.
Remarquons que le blocage des adresses non routables en destination est normalement inutile car ces adresses ne
devraient pas être annoncées sur Internet : aucune route ne devrait être présente dans les routeurs pour effectuer le
routage. Par ailleurs, ce type de paquet est détruit systématiquement à l’arrivée dans la VRF « IPT » du Backbone par
la présence de routes statiques vers Null0. Cependant, pour prévenir tout problème lié à ces adresses, l’ACL « IPT-
ALL-IF-OUT » placée sur ces interfaces prend tout de même en compte la destination.
Les interfaces sortant vers Internet ont l’application l’ACL « IPT-ALL-IF-OUT » représentée ci-dessous :
! Sur IPT-TH2 et sur IPT-GLS
!
ip access-list extended IPT-ALL-IF-OUT
remark === RFC1918 et Martians (protection)
deny ip 0.0.0.0 0.255.255.255 any
deny ip 10.0.0.0 0.255.255.255 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip 169.254.0.0 0.0.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.0.2.0 0.0.0.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip 198.18.0.0 0.1.255.255 any
deny ip 198.51.100.0 0.0.0.255 any
deny ip 203.0.113.0 0.0.0.255 any
deny ip 224.0.0.0 15.255.255.255 any
deny ip 240.0.0.0 15.255.255.255 any
deny ip any 0.0.0.0 0.255.255.255
deny ip any 10.0.0.0 0.255.255.255
deny ip any 127.0.0.0 0.255.255.255
deny ip any 169.254.0.0 0.0.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.0.2.0 0.0.0.255
deny ip any 192.168.0.0 0.0.255.255
deny ip any 198.18.0.0 0.1.255.255
deny ip any 198.51.100.0 0.0.0.255
deny ip any 203.0.113.0 0.0.0.255
deny ip any 224.0.0.0 15.255.255.255
deny ip any 240.0.0.0 15.255.255.255
Page 33
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
33
!
!
interface Port-channel92.1030
description === Lien vers Neo Telecoms ===
ip access-group IPT-ALL-IF-OUT out
!
interface Port-channel92.1031
description === Lien vers Level3 ===
ip access-group IPT-ALL-IF-OUT out
!
5.7.2 Les ACLs en pour les paquets arrivants d’Internet : IPT-<FAI>-IN
Cependant, un rôle de protection doit avoir lieu à l’entrée sur les interfaces Internet : c’est pour cette raison que
l’ensemble des adresses IP des routeurs de la plateforme sont bloquées afin d’éviter toute attaque sur ces machines
qui peuvent être de natures différentes :
Des tests en laboratoire ont mis en évidence la fragilité de l’IOS utilisé aux flood TCPSyn : il est évident, que
pour permettre le routage et la résolution de problèmes, les flux BGP et ICMP soient admis mais à la seule
condition que le flux soit transmis de routeur à routeur après vérification de la source et de la destination.
Comme chaque interface supporte une session BGP différente, il est nécessaire de créer une ACL spécifique
à chaque interface : elle porte un nom lié à l’interface et n’est appliquée qu’une seule fois.
Un autre rôle de protection a lieu sur ces interfaces : elles doivent empêcher la venue d’adresses IP de l’entreprise
depuis Internet : elles sont considérées par l’ACL comme usurpées et les paquets doivent être détruites.
Un machine émettant des paquets venant d’Internet et portant l’adresse source 93.95.56.1 tenterait
vraisemblablement de se faire passer pour l’un de nos clients ou pire encore, tenterait de se faire passer
pour un de nos routeur (pour éventuellement casser une session BGP et perturber le routage).
Certains fonctionnements particuliers du routage IP peuvent être affectés par cette protection contre
l’usurpation : Mobile IP avec son principe de « routage triangulaire » ne fonctionnera pas pour les mobiles
situés à l’extérieur et voulant communiquer avec un client de Covage. En effet, les « mobiles nodes »
utilisant une adresse IP de Covage en temps que « home address » enverront des paquets ayant pour
source 93.95.56.0/21 et seront bloqués par cette ACL.
Voici l’ACL appliquée en entrée sur l’interface avec Neo Telecoms. Elle reprend en premier lieu la partie
« nettoyage » des adresses non routables et protège la plateforme IP Transit : chacune de plages IP de Covage
utilisées entre les IPTs et les adresses données par les fournisseurs utilisées par la plateforme pour les
interconnexions BGP sont filtrés. L’ACL finit par sa fonction d’ « antispoofing » :
! Sur IPT-GLS (En rouge, ce qui est spécifique à cette ACL IPT-<FAI>-OUT
!
ip access-list extended IPT-NEO-IN
remark === RFC1918 et Martians (protection)
deny ip 0.0.0.0 0.255.255.255 any
deny ip 10.0.0.0 0.255.255.255 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip 169.254.0.0 0.0.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.0.2.0 0.0.0.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip 198.18.0.0 0.1.255.255 any
deny ip 198.51.100.0 0.0.0.255 any
deny ip 203.0.113.0 0.0.0.255 any
deny ip 224.0.0.0 15.255.255.255 any
deny ip 240.0.0.0 15.255.255.255 any
deny ip any 0.0.0.0 0.255.255.255
deny ip any 10.0.0.0 0.255.255.255
deny ip any 127.0.0.0 0.255.255.255
deny ip any 169.254.0.0 0.0.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.0.2.0 0.0.0.255
deny ip any 192.168.0.0 0.0.255.255
Page 34
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
34
deny ip any 198.18.0.0 0.1.255.255
deny ip any 198.51.100.0 0.0.0.255
deny ip any 203.0.113.0 0.0.0.255
deny ip any 224.0.0.0 15.255.255.255
deny ip any 240.0.0.0 15.255.255.255
remark === Subnet Covage (protection)
deny ip any host 93.95.56.110
deny ip any host 93.95.56.111
deny ip any 93.95.56.144 0.0.0.3
deny ip any 93.95.56.148 0.0.0.3
deny ip any 93.95.56.152 0.0.0.3
remark === Interco FAI.Covage: BGP, ICMP
permit tcp host 83.167.32.45 host 83.167.32.46 eq bgp
permit tcp host 83.167.32.45 eq bgp host 83.167.32.46
permit icmp host 83.167.32.45 host 83.167.32.46 echo
permit icmp host 83.167.32.45 host 83.167.32.46 echo-reply
remark === Interco FAI-Covage et ClientBGP-Covage (protection)
deny ip any host 83.167.32.42
deny ip any host 83.167.32.46
deny ip any host 213.242.111.110
remark === Antispoofing Covage (protection)
deny ip 93.95.56.0 0.0.7.255 any
deny ip 178.22.144.0 0.0.7.255 any
remark === Permit client
permit ip any any
!
!
interface Port-channel92.1030
description === Lien vers Neo Telecoms ===
ip access-group IPT-NEO-IN in
!
Nous avons donc 2 ACLs de ce type sur IPT-TH2 et une ACL sur IPT-GLS :
IPT-NEO-IN sur l’interface Port-channel92.1030 de IPT-GLS.
IPT-NEO-IN sur l’interface Port-channel92.1030 de IPT-TH2.
IPT-LEVEL3-IN sur l’interface Port-channel92.1031 de IPT-TH2.
5.7.3 L’ACLs des paquets entrant depuis le Backbone MPLS : IPT-CORE-IN
Cette ACL est relativement proche des ACLs IPT-NEO-IN et IPT-LEVEL3-IN qui sont placées en entrée sur les interfaces
Internet. Ses objectifs sont les suivants :
Protéger la plateforme IP Transit des attaques émises par les clients.
Vérifier que les paquets émis sont bien des paquets émis par des clients légitimes de Covage donc s’assurer
que l’adresse source des paquets est dans un préfixe de Covage. Là encore cette vérification pourra nuire au
Mobile IP, pour les « mobile node » visitant notre réseau : les paquets du « mobile node » seront bloqués
car ils ont pour source la « home address » qui est hors de préfixe.
Comme nous le verrons lors du déploiement, cette règle concernant la légitimité des paquets que nos clients
émettent mais dont la source est hors de notre préfixe n’est pas tout à fait exacte. Certains clients utilisent le service
d’IP Transit pour émettre des paquets avec l’adresse source 81.255.91.210 vers Internet. Les paquets venant
d’Internet vers ses clients utiliseront forcément un autre chemin retour pour revenir au client : ils font en effet parti
d’un préfixe annoncé en BGP par un autre AS (3215), ce qui laisse penser qu’ils sont également client d’un autre
opérateur.
Cette ACL ressemble donc aux ACL nommées IPT-<FAI>-IN mais elle utilise dans sa version finale la règle antispoofing
inverse, bloquer ce qui est hors de nos préfixes :
! Sur IPT-TH2 et sur IPT-GLS, à la fin de l’ACL IPT-CORE-IN
!
remark === Antispoofing Covage (protection)
permit ip 93.95.56.0 0.0.7.255 any
Page 35
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
35
permit ip 178.22.144.0 0.0.7.255 any
remark === Permit client
deny ip any any
5.7.4 L’ACL des paquets sortant vers le Backbone MPLS : IPT-CORE-OUT
Pour finir, le dernier objectif des ACLs consiste à protéger les équipements du Backbone MPLS des attaques venant
d’Internet : c’est le rôle de cette ACLs qui est donc constituée de la liste des adresses IP que les PE utilisent dans les
interconnexions avec les clients.
Cette ACL doit par ailleurs être simple à modifier car il s’agit d’ajouter des entrées à chaque fois qu’un client est
ajouté (un « deny » de plus) : cette ACLs est donc amenée à être modifié très souvent.
Voici quelques lignes de cette ACL :
! Sur IPT-TH2 et sur IPT-GLS
!
ip access-list extended IPT-CORE-OUT
remark === Subnet Covage vers vrf IP Transit (troubleshooting)
permit ip 93.95.56.0 0.0.7.255 any
permit ip 178.22.144.0 0.0.7.255 any
remark === IP sur PE Covage (protection en provenance d Internet)
deny ip any host 93.95.56.1
deny ip any host 93.95.56.17
deny ip any host 93.95.56.21
deny ip any host 93.95.56.25
deny ip any host 93.95.56.29
! 105 autres adresses désignant des interfaces des PEs du Backbone MPLS
permit ip any any
!
interface Port-channel91.1025
ip access-group IPT-CORE-OUT out
!
5.7.5 Policing des flux entrant : la policy-map IPT-POLCING
Les clients utilisant le service d’IP Transit sont normalement limités en débit (descendant et montant) par les
équipements d’accès : il n’y a donc pas besoin de limiter les débits de clients au niveau de la plateforme elle-même.
Cette policy n’a pas pour but de limiter la bande passante des clients.
Il apparait nécessaire de limiter les flux venant d’Internet qui pourraient saturer les liens du Backbone MPLS. Il s’agit
là d’une protection du Backbone implémenté sur les routeurs IPTs.
Etant donné que les IOS ne supportent pas plus de 256 class-map, il faut trouver une solution pour regrouper les
clients au sein de quelques class-map :
Les clients ayant commandés plus de 10Mbps de trafic sont traités dans des class-map qui leur sont
propres. C'est-à-dire que seule la plage IP qui leur est assignée est prise en compte par la class-map.
Les clients avec un petit débit (>10Mbps) sont regroupés 10 par 10 au sein de class-map nommés « AGG-
<debit> » auxquels sont appliqués seule limitation de bande passante. Pour éviter que ces 10 clients aient à
partager une même bande passante, on additionne l’ensemble des débits commandés par les clients puis
on applique une augmentation de 25%. Ainsi, pour la class-map « AGG-1M-1 » qui prend en compte 10
clients 1Mbps chacun, on applique une politique de 12,5Mbps.
Pour finir, on note que BGP a un traitement à part de manière a ne pas être gêné par les flux des clients,
étant donné l’importance de ce protocole pour la plateforme IP Transit. La class-map IPT-BGP lui est dédié
et à 50Mbps d’assigné.
Page 36
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
36
Voici l’exemple de ces trois cas de figure au sein de trois « class-map » différentes intégrées dans l’unique « policy-
map » :
! Principe des policy-map appliquées sur la plateforme IP Transit
!
class-map match-any IPT-CLIENTA
description CLIENT-A
match access-group name IPT-CLIENTA
!
class-map match-any AGG-1M-1
description Aggregation de clients 5M - 10 au maximum
match access-group name IPT-CLIENT1
match access-group name IPT-CLIENT2
match access-group name IPT-CLIENT3
match access-group name IPT-CLIENT4
match access-group name IPT-CLIENT5
match access-group name IPT-CLIENT6
match access-group name IPT-CLIENT7
match access-group name IPT-CLIENT8
match access-group name IPT-CLIENT9
match access-group name IPT-CLIENT10
!
policy-map IPT-POLICING
description Global IP-Transit Policing
class IPT-BGP
police 50000000 conform-action transmit exceed-action drop
class IPT-CLIENTA
police 20000000 conform-action transmit exceed-action drop
class AGG-5M-1
police 12500000 conform-action transmit exceed-action drop
class class-default
police cir 5000000
conform-action transmit
exceed-action drop
violate-action drop violate-action drop
!
!
interface Port-channel92
description === Interface supportant les liens vers fournisseurs de transit ===
service-policy input IPT-POLICING
!
5.8 Evolution possible de la plateforme : Les points de peering
Dans le cadre du service IP Transit, il est intéressant de chercher les évolutions futures de l’architecture dont les
objectifs sont de réduire les coûts liés aux fournisseurs de transits et d’améliorer la qualité du routage.
L’interconnexion directe avec d’autres opérateurs permet de réaliser ces deux objectifs et c’est ce que permet de
faire aisément les points de peering, en permettant à de nombreux opérateurs de se retrouver sur un même LAN.
Des études ont été réalisées sur les opportunités qui permettraient à Covage d’utiliser les points de peering présents
en France. Ceux-ci sont surtout présents dans le datacenter de TeleHouse2 où Covage est fortement implanté, la
plateforme IP Transit étant déjà bien mieux équipé du coté d’IPT-TH2, avec deux fournisseurs de transit contre un
seul du coté d’IPT-GLS.
A la fin 2010, trois points de peering on été identifiés comme attractifs pour Covage :
France-IX ;
Equinix Exchange ;
Le SFINX.
Ces trois points ont été sélectionnés pour le nombre de partenaires disponibles ainsi que pour leur réactivité et leur
visibilité (présentations aux conférences). D’autre ont été présent sur les datacenter Parisiens voir dans d’autre
régions du pays mais semblent actuellement en perte de vitesse : PaNAP à fusionné avec France-IX, Free-IX ne
répond pas aux e-mails et PariX n’as plus de site web.
Page 37
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
37
Nous avons également observé que les points de peering français ont une importance très faible en termes de
partenaire comme en termes d’échange de route ou de débit. Cependant, les points de Londre, Amsterdam et de
Franckfort sont actuellement inaccessibles pour Covage. L’entreprise ne souhaite d’ailleurs pas s’éloigner de son
cœur de métier.
Un autre problème est d’estimer l’importance que ces points de peering peuvent avoir pour Covage. Il est nécessaire
de mesurer les flux susceptibles d’y transiter. Cela permet d’imaginer l’avantage que cela peut nous apporter en
termes de qualité de routage mais surtout d’estimer les économies réalisées en réduisant le recours aux fournisseurs
de transit, dont les facture annuels s’élèvent à 2000€/mois (.
Les principaux fournisseurs de contenus, gros consommateurs de bande passante y sont présents (Google et Akamai
en autres). Ils on répondu favorablement à un échange direct de flux sur les points de peering précédemment
mentionnés. Compte tenu de l’importance des contenus hébergés par ces fournisseurs, une mesure plus précise des
flux susceptibles de transiter par ces points de peering sera nécessaire avant de pouvoir effectivement s’y connecter.
Le protocole NetFlow de Cisco est implémenté sur les routeurs IPTs formant la plateforme IP Transit (notons que
Covage s’intéresse est également à son utilisation au sein du Backbone). Nous nous sommes donc intéressés à son
fonctionnement et avons réalisé des tests pour connaitre le comportement des routeurs IPT : ceux-ci traitent bien
des mesures effectuées sur les flux, selon le processus décrit ci-dessous :
La collecte se réalise assez simplement en activant la commande « ip flow ingress » sur les interfaces
recevant du flux :. Seul le flux entrant dans le réseau est considéré, dans le cas de la plateforme actuelle
pour réduire l’impact sur le Backbone MPLS, ces mesures ne sont effectués qu’au sein des routeurs IPTs, qui
seront alors mesure de nous informer précisément des AS source et destination de chaque flux ainsi que
des masques précis utilisés.
Dans un premier temps, nous traitons les flux dans leurs sens le plus large : un flux est ainsi constitué des
adresses IP source et destination, du protocole (TCP, UDP, ICMP, …) et des ports source et destination. (mls
ip flow interface). Les valeurs par défaut on été conservées comme les timers.
La collecte a été configurée de manière à remonter le maximum d’informations vers le serveur collectant
ces informations : la version 9 de NetFlow (prenant également en charge l’IPv6, en ajoutant les valeurs
diverses tels que les TTLs minimum et maximum observées, les VLAN-id, les interfaces d’entrée et de sortie,
le prochain saut BGP, etc…).
Page 38
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
38
6 Architecture IPv6
6.1 Architecture proposée
L’architecture IPv6 est conçue pour être très proche de l’architecture IPv4, avec pour seule différence une agrégation
supplémentaire au niveau des PEs du Backbone. Cette architecture reprend un ensemble de VRFs distincts nommés
« IPT6-1 » et « IPT6 » respectivement à la place des VRFs « IPT-1 » et « IPT » que l’on réserve à l’IPv4.
Covage a fait une demande de préfixe IPv6 en septembre 2010 et s'est vu attribuer le préfixe 2a02:2358::/32. Pour
permettre aux clients d'utiliser l'auto-configuration prévu par IPv6, il faut leur assigner au moins des /64. Il nous faut
donc gérer 32 bits d’adressage.
Pour permettre à un client d'utiliser le routage, il faut lui attribuer plusieurs préfixes /64, c'est à dire un préfixe plus
générique. Dans ce préfixe que nous lui assignerons, il devra gérer ses « End Sites » ainsi que les différents sous-
réseaux de chaque End Site (le « subnet id »). Enfin, il faut attribuer un préfixe suffisamment large au client pour lui
permettre de gérer confortablement ses end sites et ses sous-réseau, et lui éviter de demande trop régulièrement à
Covage de nouvelles assignations. Covage doit également gérer ces plages assignées aux clients dans son préfixe.
Interface identifier
/12/3 /64/32
:
2000::/3 IPv6 Global Unicast de l’IANA
2a00::/12 RIPE-NCC depuis octobre 2006
2a02:2358::/32 Covage depuis septembre 2010
/128
2 a 0 2 2 3 5 8
/48
::::
Figure 9 : Préfixe IPv6 alloué à Covage
Cette architecture à été crée pour suivre les recommandations du RIPE-NCC, suivant la politique décrite dans le
document [RIPE-481+. Elle s’écarte par contre de la recommandation officielle de l’IETF d’assigner un /48 par site
final. Dans la [RFC3177+, l’IAB recommande l’assignation à un /48 par « end site », mais un brouillon de RFC
([RFC3177BIS] destiné à devenir « Best Current Practices »), nous indique que cette recommandation ne sera
probablement plus maintenue dans l’année à venir. Nous recommanderons donc à nos clients opérateurs d’assigner
des /56 pour chacun de leurs sites finaux.
Hiérarchie du découpage (du plus spécifique au moins spécifique) :
Les clients se voient assigner des plages d’adresses IPv6 suffisamment larges (des /48) pour qu’ils puissent,
à leur tour, les assigner aux sites finaux :
o de leurs clients routés des /56, le client pourra alors utiliser jusqu’à 16 sous-réseaux ;
o pour les clients « directement connectés » à leur routeur (donc sans routage), des /64.
Tous les clients du PE sont situés dans la même VRF « IPT6 ». Le PE réalise une agrégation en un seul /40.
Ce /40 est annoncé dans le Backbone jusqu’au deux VRFs IPT6-1 situés sur les PEs de TH2 et de GLS, qui les
transmettent directement aux routeurs IPTs.
Les routeurs IPTs réalisent eux-mêmes une agrégation des différents /40 des PEs en un seul /32 pour
l’annoncer aux fournisseurs de transits, comme ils le font déjà en IPv4.
Plage réservée à la plateforme IP Transit :
Dans le plan, d’adressage proposé, le premier /40 est arbitrairement réservé à la plateforme IP Transit, avec
un /48 assigné par POP (TeleHouse2 et GlobalSwitch), comme recommandé par la politique IPv6 du RIPE-
NCC ;
Page 39
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
39
Les routeurs IPT ont des « interface identifiées » (64 dernier bits de l’adresse IPv6) identiques sur toutes
leurs interfaces (56:110 pour IPT-TH2 et 56:111 pour IPT-GLS, correspondant à leurs router-id en BGP).
Plages réservées aux VRFs « IPT6 » :
Pour chaque préfixe /40 alloué à un PE, la première adresse (finissant par ::1) correspond à l’adresse de
Loopback6 de test ;
Le premier /48 du PE est destiné à être découpé pour les interconnexions avec les clients ;
Les /48 suivants sont destinés à être assignés aux clients.
Bien que le RIPE-NCC recommande d’utiliser des préfixe /64 pour les interconnexions avec les clients, nous avons
choisi d’utiliser des /126. Notons que le premier /48 du PE (comme 2a02:2358:500::/48) dispose encore de
suffisamment d’espace disponible s’il était nécessaire d’assigner un /64 d’interconnexion supplémentaire par client
du PE.
Interface identifier
/12/3 /64/32
:
/128
2 a 0 2 2 3 5 8
/48
:::
/40
:
ClientCovage
/56
Assignation par End Sites recommandés
Agrégation par PE proposée
Identifiant de PE
Identifiant du client
Identifiant de End Site
Identifiant de sous-réseau: subnet ID
Figure 10 : Utilisation des 32 bits d'adressage du préfixe alloué à Covage
Sur ce schémaon voit l’identifiant du PE en rouge et l’identifiant du client pour ce PE en vert. Par ailleur, en bleu,
l’adressage réservée au client dans lequel il doit désigner créer une distinction entre l’identifiant de « End Site » et le
« subnet id » comme indiqué dans la RFC 4291 [IPV6ARCH].
Voici le plan d’adressage tel qu’il existait sur la maquette IPv6 :
Découpage de la plage IPv6 de Covage 2a02:2358::/32
2a02:2358::/32 Plage IPv6 de Covage
2a02:2358::/40 plage IPv6 réservé à la plateforme IP Transit
2a02:2358:1::/48 plage réservée au routeur IPT-TH2
2a02:2358:1::56:110 adresse de l’interface Loopback6 du routeur IPT-TH2
2a02:2358:1:1::/64 sous-réseau d’interconnexion IPT-TH2 à la VRF « IPT6-1 » de TH2
2a02:2358:1:2::27 adresse de l’interface du PE de TH2 vers IPT-TH2
2a02:2358:1:2::56:110 adresse du routeur IPT-TH2 vers le Backbone (PE de TH2)
2a02:2358:1:2::/64 sous-réseau d’interconnexion entre IPT-TH2 et IPT-GLS
2a02:2358:1:2::56:110 adresse du routeur IPT-TH2
2a02:2358:1:2::56:111 adresse du routeur IPT-GLS
2a02:2358:2::/48 plage réservée au routeur IPT-GLS
2a02:2358:2::56:111 adresse de l’interface Loopback6 du routeur IPT-GLS
2a02:2358:2:1::/64 sous-réseau d’interconnexion IPT-GLS à la VRF « IPT6-1 » de GLS
2a02:2358:1:2::29 adresse de l’interface du PE de GLS vers IPT-GLS
2a02:2358:1:2::56:111 adresse du routeur IPT-GLS vers le Backbone (PE de GLS)
2a02:2358:300::/40 agrégat de la VRF « IPT6 » du PE de TH2
2a02:2358:300::1/128 adresse de l’interface Loopback6 du PE de TH2
2a02:2358:400::/40 agrégat de la VRF « IPT6 » du PE de GLS
2a02:2368:400::1/128 adresse de l’interface Loopback6 du PE de GLS
2a02:2358:500::/40 agrégat de la VRF « IPT6 » du PE de JURA
2a02:2358:500::1/128 adresse de l’interface Loopback6 du PE de JURA
Page 40
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
40
2a02:2358:500::1:0/126 sous-réseau d’interconnexion pour le client 1
2a02:2358:500::1:1 adresse de l’interface du PE pour l’interconnexion avec le client 1
2a02:2358:500::1:2 adresse du routeur du client 1
2a02:2358:500::2:0/126 sous-réseau d’interconnexion pour le client 2
2a02:2358:500::2:1 adresse de l’interface du PE pour l’interconnexion avec le client 2
2a02:2358:500::2:2 adresse du routeur du client 2
2a02:2358:500::3:0/126 sous-réseau d’interconnexion pour le client 3
2a02:2358:500::3:1 adresse de l’interface du PE pour l’interconnexion avec le client 3
2a02:2358:500::3:2 adresse du routeur du client 3
2a02:2358:501::/48 plage assigné au client 1
2a02:2358:502::/48 plage assigné au client 2
2a02:2358:503::/48 plage assigné au client 3
2a02:2358:600::/40 agrégat de la VRF « IPT6 » du PE de CREUSOT
2a02:2368:600::1/128 adresse de l’interface Loopback6 du PE de CREUSOT
L’architecture IPv6 proposée ici ne varie véritablement de l’architecture IPv4 déjà en place que par l’allocation de
plages par PE (utilisation de l’agrégation). Par ailleurs elle distingue clairement les plages réservées à la plateforme IP
Transit, rendue possible par le volume que nous donne l’espace d’adressage IPv6 : elle à l’avantage de pouvoir
désigner toutes les plages d’un POP par un seul « end site », comme recommandé par le RIPE-NCC dans la politique
IPv6 [RIPE-481].
6.2 Objectif d’agrégation d’IPv6
Cette architecture permet de bénéficier au maximum d’IPv6 dont l’agrégation dans les tables de routage est l’un des
principaux objectifs, comme relevé dans la politique du RIPE-NCC [RIPE-481] :
“In IPv6 address policy, the goal of aggregation is considered to be the most important.”
-- IPv6 Address Allocation and Assignment Policy, RIPE-NCC. http://www.ripe.net/docs/ipv6policy.html.
Cependant, l’agrégation en /40 implique un gaspillage car l’intégralité de chaque /40 est réservée aux clients d’un PE,
même si un seul client y est présent (donc un seul /48). Dans la situation actuelle, le Backbone MPLS possède 24 PEs
supportant une VRF « IPT6 », ce qui conduit à la consommation de 10% de la plage IPv6 allouée à Covage, alors que
chacun de ces PEs ne possède que peu de clients. Nous avons supposé que le nombre de PEs augmenterait très
faiblement alors même que le nombre de clients pourrait s’accroitre.
Notons que le RIPE-NCC, en plus de placer l’agrégation comme le principal but d’IPv6 nous demande un taux
d’utilisation minimale avant de pouvoir se voir réassigner une plage IPv6.
6.3 Taux d’utilisation imposé par le RIPE-NCC
Le RIPE-NCC impose un usage minimum de l’adressage IPv6 avant de pouvoir redemander une nouvelle allocation :
ce minimum est calculé selon le HD-Ratio qui prend en compte le rapport entre au nombre de /56 assignées et le
nombre de /56 assignables.
Le HD-Ratio requis pour effectuer une nouvelle demande est de 0.96, ce qui représente plus de 36% d’utilisation des
/56.
En cas de sous utilisation des préfixes agrégés (/40) dans de trop nombreux PEs et d’une multiplication trop
importante du nombre de PEs, ce taux d’utilisation risque de ne pas être atteint alors que l’espace d’adressage serait
consommé. L’agrégation proposée doit donc impérativement être contrôlée au cours de l’évolution du service IP
Page 41
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
41
Transit, notamment en cas de croissance de Covage qui tendrait à une multiplication des PEs, phénomène qui doit
donc être particulièrement suivi.
6.4 Evolutions possibles de l’espace d’adressage IPv6
L’espace d’adressage tel que décrit ici doit donc être évolutif pour ne pas gêner l’obligation du taux d’utilisation.
Dans le cas évoqué précédemment, il sera possible de réduire la taille des agrégations à /44 par exemple pour tous
les PEs ou bien seulement pour les PEs supportant un nombre trop faible de clients et dans un cas extrême, il serait
nécessaire de la supprimer totalement. Cette suppression de l’agrégation serait au prix d’un accroissement de la
table de routage : un HD-ratio de 0.94 correspond à plus de 16 millions de /56 assignés dans le préfixe /32, soit bien
plus que ce que ne peut supporter les routeurs actuels. Par ailleurs, en cas de suppression totale du mécanisme
d’agrégations, les plages assignées aux clients apparaitraient dispersées sur le début de la plage IPv6 de Covage.
6.5 Relations avec le RIPE-NCC : demande de l’allocation initiale IPv6
L’usage des plages IPv4, IPv6 et du numéro d’AS sur Internet requière une coordination entre les réseaux qui est
assuré en Europe par le RIPE-NCC : comme Covage n’avait pas d’adresse IPv6 alloué jusqu’en septembre 2010, une
demande a dû être faite auprès de cet organisme. Cette demande d’ « allocation initiale IPv6 » se fait simplement sur
son site web, et il n’exige que peu de justifications. L’assignation des précédentes ressources, comme le numéro d’AS
et les plages IPv4 sont déjà des preuves d’une utilisation future d’IPv6.
Suite à cette demande, le préfixe 2a02:2358::/32 a été assigné à Covage le 2 septembre 2010 et une entrée « inet6 »
à été créée dans la base de données du RIPE-NCC :
% Information related to '2a02:2358::/32'
inet6num: 2a02:2358::/32
netname: FR-COVAGE-20100902
descr: Covage Services
country: FR
org: ORG-CS91-RIPE
admin-c: SM5984-RIPE
admin-c: PN2522-RIPE
admin-c: GA2401-RIPE
tech-c: SM5984-RIPE
tech-c: PN2522-RIPE
tech-c: GA2401-RIPE
status: ALLOCATED-BY-RIR
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: COVAGE-MNT
mnt-routes: COVAGE-MNT
notify: [email protected]
notify: [email protected]
notify: [email protected]
notify: [email protected]
changed: [email protected] 20100902
source: RIPE
Covage sera bientôt “LIRs with 4-star IPv6 RIPEness” :
Le RIPE-NCC définit une échelle de déploiement d’IPv6 chez les LIRs, suivant quatre étoiles et donc de suivre
l’évolution du déploiement IPv6 dans l’Internet :
Avoir un préfixe IPv6 alloué par le RIPE-NCC (2a02:2358::/32 pour Covage) ;
Avoir un objet « route6 » renseigné dans la base de données whois du RIR ;
Avoir un objet « domain » pour la délégation DNS inverse du préfixe IPv6 ;
Avoir le préfixe IPv6 annoncé dans le routage global BGP.
Page 42
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
42
L’allocation doit être obtenue en premier lieu, les étapes suivantes peuvent être obtenues dans un ordre
quelconque. Par ailleurs, la création d’une cinquième étoile dans la classification est actuellement à l’étude.
Covage a obtenu l’allocation le 2 septembre 2010 et devrait obtenir la quatrième étoile avant la fin de l’année 2010 :
ce qui correspondra à un déploiement intégral d’IPv6 dans le Backbone (les VRFs « IPT6 »).
6.6 Routage IPv6
L’un des objectifs de l’architecture IPv6 était de rapprocher au maximum le traitement sur IPv6 et sur IPv4, tout en
simplifiant le fonctionnement la plateforme IP Transit précédente qui utilisait OSPF pour les échanges entre le
Backbone MPLS et les routeurs IPTs de la plateforme.
L’utilisation d’IPv6 dans les VRFs permet de très peu modifier le Backbone. Il n’est pas nécessaire d’utiliser un
protocole de routage interne spécifique à IPv6 puisque tout est contenu dans ces VRFs. Notons que le résultat est
assez proche de la solution « 6PE » de Cisco. Il permet en outre de n’apporter aucune modification aux LSR ne faisant
que de la communication de label, les « P » (Le Backbone MPLS de Covage ne possède aucun P) et de n’avoir que de
l’IPv6 dans les VRFs au niveau des « PE ».
Comme OSPFv3 pour IPv6 n’est pas encore disponible dans les VRFs, ce protocole a été exclu dès le début pour le
routage IPv6. Nous avons pu réaliser ces objectifs en utilisant eBGP pour assurer le routage entre les IPTs et les VRFs
Backbone.
Pour maintenir séparer au maximum les architectures IPv4 et IPv6, elles sont traitées dans des ensembles VRFs
distincts (IPT et IPT-1 pour IPv4 contre IPT6 et IPT6-1 pour IPv6) mais de manière très proche. D’une part nous
apportons le moins de modification possible aux VRFs « IPT » actuelles qui ne supportent que l’IPv4. D’autre part,
cette distinction effectuée sur les deux protocoles permet de faire évoluer de manière différente la façon dont
Covage gère les deux protocoles. La livraison elle-même des connexions avec les clients aura lieu sur des interfaces
distinctes.
Les VRFs « IPT » utilisent la commande « ip vrf » ne supportant qu’IPv4, alors que les VRFs « IPT6 » utilisent la
commande « vrf definition » qui supporte les deux protocoles même si nous ne servons que d’IPv6. Il est donc plus
facile de ne pas toucher aux VRFs actuelles et de créer les nouvelles « IPT6 » comme s’il s’agissait d’un service
différent.
Ainsi, dans l’architecture IP Transit, les seules interfaces sur lesquelles sont configurées à la fois IPv6 et IPv4 sont les
trois interfaces de la plateforme connectées aux fournisseurs de transit.
Pour IPv4, aucune modification n’est à apporter sur les VRFs « IPT » situées sur les 24 PEs que compte Covage. En
revanche, IPv6 n’est absolument pas activé sur les PEs du Backbone Covage. Il faut donc activer le routage IPv6 d’une
part et le support de l’IPv6 dans les VRF d’autre part, puis créer et configurer les VRFs « IPT6 » qui seront dédiées à
l’IPv6. Pour finir, le routage IPv6 dans les VRFs nécessite d’activer la famille VPNv6 dans les instances MP-BGP, en
restant au plus proche de ce que fait la famille VPNv4 : c'est-à-dire en gardant TH2 et GLS comme route-reflector.
6.7 Les ACLs de protections
Il n’existe pas par ailleurs de plage réservé au routage privé dans l’adressage IPv6 général mais au contraire, le
routage publique est restreint à la plage 2000::/3 comme décrit par *IPV6ARCH+ et tout ce qui est à l’extérieur n’est
donc pas routable sur Internet.
Bien que l’usage de la plage Globale soit préféré, on peut mentionner la présence de deux plages IPv6 destinées à un
routage unicast privés :
Page 43
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
43
Les adresses IPv6 unicast locales de site (fec0::/10), rendue obsolètes depuis 2004 ;
Les adresses IPv6 locales uniques (ULA, fc00::/7) qui suivent un usage particulier, décrit dans la RFC4193
parue en 2005.
L’usage des plages IPv6 est tenu par l’IANA dans son registre « IPv6 Address Space » :
http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml.
Dans la plage 2000::/3, certaines ne doivent pas être routées, on note deux plages :
2001:2::/48 destinée aux benchmarks (comme l’est 198.18.0.0/15) ;
2001:db8::/32 destinée à la documentation (comme 192.0.2.0/24, 198.51.100.0/24 et 203.0.113.0/24).
Nous avons également relevé des plages qu’il ne faut pas considérer dans les exclusions :
2001::/23 est la plage des adresses à usage spéciale, gérée par un registre distinct de l’IANA et dans laquelle
on trouve des préfixes (3 préfixes en 2010) qui peuvent être routables globalement ou non.
2001::/32 pour Teredo, un mécanisme de transition vers IPv6, qui doit permettre de joindre un relai.
2001:10::/28, bien que le protocole l’utilisant ne soit pas routable globalement, la RFC5180 recommande de
ne pas l’inscrire dans les configuration car il s’agit d’une allocation temporaire qui sera retournée à l’IANA
en 2014.
2002::/16 est la plage réservée au 6to4 et doit permettre aux paquet de traverser Internet IPv4.
Les ACLs utilisées en IPv6 ont le même rôle que celles d’IPv4. Elles sont formées de la même manière mais le nombre
de plages à exclure les rend plus concises.
Voici par exemple, l’ACL « IPT6-ALL-IF-OUT » de 5 lignes que l’on peut comparer aux 24 lignes de « IPT-ALL-IF-OUT » :
ipv6 access-list IPT6-ALL-IF-OUT
remark === Non routables (idem que IPv4 RFC1918 et Martians) (protection)
deny ipv6 2001:2::/48 any
deny ipv6 2001:DB8::/32 any
deny ipv6 any 2001:2::/48
deny ipv6 any 2001:DB8::/32
sequence 10000 remark === Permit any
permit ipv6 2000::/3 2000::/3
De façon analogue, Covage ne gère qu’un préfixe IPv6 : 2a02:2358::/32, alors que 2 préfixes IPv4 doivent être gérés.
Cela allège également les ACLs.
6.8 Les VRFs « IPT6 », correspondant aux VRFs « IPT » d’IPv4
La principale différence sur l’architecture IPv6 est la création d’une agrégation au niveau de chaque PE : nous avons
alors la présence de la commande « aggregate-address ». Tous les clients du PE sont représentés sous un seul
préfixes /40, que nous appelons « préfixe du PE ».
On peut donc comparer cette VRF « IPT6 » avec la VRF « IPT » :
! Sur le PE de BOISSY (en route, ce qui change sur les autres VRFs IPT6 du Backbone)
! (En vert, ce qui est spécifique au client 1)
!
ipv6 unicast-routing
mls ipv6 vrf
!
!
vrf definition IPT6
description === IPT - Clients IP Transit Generiques (IPv6) ===
rd 64512:3164
!
address-family ipv6
Page 44
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
44
route-target export 64512:3164
route-target import 64512:3160
route-target import 64512:3161
maximum routes 1000 10
exit-address-family
!
!
ipv6 route vrf IPT6 2a02:2358:601::/48 2a02:2358:600::1:2
!
!
router bgp 64512
!
address-family ipv6 vrf IPT6
redistribute connected
redistribute static
no synchronization
maximum-paths ibgp 2
aggregate-address 2A02:2358:600::/40 summary-only ! Préfixe IPv6 du PE de BOISSY
exit-address-family
!
interface Loopback6
description === IPT - IPv6 debug purpose only ===
vrf forwarding IPT6
no ip address
ipv6 address 2A02:2358:600::1/128
!
interface Gi3/6 ! Pour le client 1
vrf forwarding IPT6
no ip address ! Il peux utiliser la plage 2a02:2358:601::/48
ipv6 address 2A02:2358:600::1:1/126 ! Il doit utiliser l’adresse 2a02:2358:600::1:2/126
!
end
6.9 Implémentation 6to4 dans l’architecture
Le 6to4 est une technologie de transition permettant aux paquets IPv6 de traverser une partie d’Internet IPv4, décrit
dans la RFC3056 « Connection of IPv6 Domains via IPv4 Clouds » [6TO4]. Il s’agit donc pour IPv6 de fonctionner
comme une surcouche d’IPv4 et permet aux utilisateurs d’Internet d’utiliser IPv6 lorsque leur FAI ne leur fournit
qu’une adresse IPv4.
6.9.1 Fonctionnement du 6to4
Le processus décrit ci-dessous reprend une communication IPv6 entre l’hôte 2a02:2358::1 et l’hôte 2002:V4ADDR::1
(dans laquelle « V4ADDR » désigne l’adresse IPv4 du routeur « 6to4 relay router » chargé de décapsuler), le préfixe
de l’îlot 6to4 est donc dépendant de l’IPv4 de son routeur.
Par la suite nous prendrons pour V4ADDR, l’adresse IPv4 192.0.2.3, soit 0x0c000203 en hexadécimal. Les paquets
ont alors le parcours suivant, correspondant au schéma joint :
Lors de l’émission d’un paquet par l’hôte 2a02:2358::1 vers l’hôte 2002:c00:203::1 :
le paquet suit la route 2002::/16, le préfixe 6to4 présent dans la table de routage BGP menant jusqu’à un
fournisseur 6to4. Il s’agit d’un routage anycast : le paquet est alors routé au « 6to4 relay router » le plus
proche selon le protocole BGP.
Le fournisseur implémente la fonction d’encapsulation du « 6to4 relay router » : le paquet IPv6 reçu par le
routeur est alors encapsulé dans un paquet IPv4. L’adresse de destination du paquet est choisie copiant
V4ADDR de l’adresse IPv6 destination (les octets 3 à 8 donc). La destination du paquet est donc 192.0.2.3.
Le protocole numéro 41 désigne un paquet IPv6 comme charge utile du paquet IPv4.
Le paquet IPv4 suit alors le routage traditionnel dans Internet pour aller à l’adresse 192.0.2.3. Il traverse les
équipements non compatibles avec IPv6.
Page 45
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
45
Cette adresse doit être l’adresse d’un routeur « 6to4 router » (aussi appelé « 6to4 border router ») qui
décapsule le paquet, et retrouve le paquet IPv6 d’origine. (Il vérifie également que l’adresse de destination
IPv6 correspond à l’adresse de destination IPv4).
Le paquet IPv6 est routé au sein de l’îlot 6to4, jusqu’à l’hôte 2002:c00:203::1.
Le paquet IPv6 depuis l’hôte 2002:c00:203::1 vers l’hôte 2a02:2358::1 :
Le paquet IPv6 est routé jusqu’à la sortie de l’îlot 6to4, généralement par la route par défaut.
Le routeur « 6to4 router » encapsule le paquet IPv6 dans un paquet IPv4. Le paquet IPv4 a pour destination
l’adresse IPv4 192.88.99.1, appelée « 6to4 Relay anycast address » par la RFC3068.
Le paquet IPv4 suit la route 192.88.99.0/24 (« 6to4 Relay anycast prefix ») annoncée en BGP par les
fournisseurs 6to4. C’est un routage « anycast », le paquet est routé au « 6to4 relay router » le plus proche
selon le protocole BGP.
Le fournisseur implémente la fonction de décapsulation du « 6to4 relay router » : ce routeur retire l’entête
IPv4 et retrouve le paquet IPv6 original.
Le paquet IPv6 est envoyé dans l’Internet IPv6 et suit le routage traditionnel jusqu’à l’hôte 2a02:2358::1.
Ce schéma représente le parcourt des paquets entre l’hôte IPv6 natif et l’hôte hébergé par un îlot 6to4 :
Routage IPv4 anycast
192.88.99.1
Routage vers l’adresse IPv4
V4ADDRRoutage IPv6 anycast
2002::/16
îlot 6to4 : 2002:V4ADDR::/48
sur l’IPv4 : V4ADDR
Route par défaut pour
sortir du site ::/0
Internet IPv4Internet IPv6
Routage IPv6 normal vers
2a02:2358::1Décaspulation
DécaspulationEncaspulation
Encaspulation
Routage normal vers
l’adresse IPv6
2002:V4ADDR::1
2a02:2358::1 2002:V4ADDR::1
6to4 relay router 6to4 router
Figure 11 : Fonctionnement du 6to4 : échange de paquets entre un hôte IPv6 natif et un hôte dans un îlot 6to4
Routage anycast d’un de nos clients IPv6 natif vers un correspondant Internet 6to4 :
Nos clients souhaitant joindre un correspondant situé sur un îlot 6to4 passera donc par la route suivante (que nous
indique BGP), annoncé par « Surf Net » (AS1103, http://www.surfnet.nl/) :
show bgp ipv6 unicast 2002::/16
BGP routing table entry for 2002::/16, version 2388
Paths: (1 available, best #1, table default)
Not advertised to any peer
8218 1103, (received & used)
2001:1B48:2:103::51 from 2001:1B48:2:103::51 (83.167.63.2)
Origin IGP, metric 10, localpref 100, valid, external, best
Community: 8218:102
Routage anycast d’un client qui implémenterait un îlot 6to4 vers un hôte IPv6 natif d’Internet :
Si l’un de nos clients implémentait un « îlot 6to4 » sur l’une de nos IPv4, nos routeurs IPTs enverraient leur trafic
encapsulé à la route annoncée par une entreprise américaine nommé « Hurricane Electric » (AS6939,
http://www.he.net/), avec pour alternative « CZNIC » (AS25192, http://www.nic.cz/) de la République tchèque :
Page 46
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
46
# Sur IPT-TH2 (2 fournisseurs de décapsulation « 6to4 relay router », via Neo ou Level3)
IPT-TH2>show bgp ipv4 unicast 192.88.99.0 255.255.255.0
BGP routing table entry for 192.88.99.0/24, version 162304112
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Advertised to update-groups:
1
3356 8928 25192, (received & used)
213.242.111.109 from 213.242.111.109 (4.68.187.231)
Origin IGP, metric 20801, localpref 100, valid, external
Community: 3356:2 3356:22 3356:100 3356:123 3356:500 3356:2064 8928:10900 8928:11012
8928:20901 8928:65191
8218 6939, (received & used)
83.167.32.45 from 93.95.56.154 (93.95.56.111)
Origin IGP, metric 11, localpref 100, valid, internal
Community: 8218:102
8218 6939, (received & used)
83.167.32.41 from 83.167.32.41 (83.167.63.11)
Origin IGP, metric 11, localpref 100, valid, external, best
Community: 8218:102
Pour pouvoir fournir la meilleure qualité de service possible à nos clients utilisant l’IPv6, nous avons cherché à
permettre aux mécanismes de transition de fonctionner de façon optimale : c'est-à-dire d’en avoir la maîtrise plutôt
que de laisser agir aléatoirement l’anycast vers des fournisseurs de 6to4 dont nous ne connaissons pas la fiabilité, les
intentions ou les performances (tels que Hurricane Electric et Surf Net). Il s’agit en fin de compte de proposer à l’IPv6
natif d’interagir du mieux possible avec ce mécanisme de transition plutôt que de mettre le 6to4 en avant au
détriment de l’IPv6 natif de bout en bout qui reste la meilleur solution.
6.9.2 Rôle d’encapsulation du 6to4 relay router
Les paquets à destination d’une adresse IPv6 commençant par « 2002: » sont routés en anycast sur Internet IPv6,
ainsi le préfixe 2002::/16. Ce préfixe est présent dans la table de routage BGP apprisse depuis les fournisseurs et on
voit, dans la base de donnée du RIPE-NCC, que 25 AS différents déclare un objet « route6: 2002::/16 ». Les paquets
suivent donc un chemin « au plus proche » selon BGP mais sans aucune information sur les capacités des
fournisseurs 6to4.
Par ailleurs, suivre la route 2002::/16 envoie le paquet dans une direction qui est peut-être contradictoire avec la
destination du paquet IPv4 qui sera générée. Par exemple, notre client IPv6 natif pourrait communiquer avec client
d’un FAI français en 6to4, mais par la voie de BGP le travail d’encapsulation risque d’être fait par un fournisseur 6to4
américain (utilisant 2 fois les liens transatlantiques par paquet).
Plutôt que de laisser BGP choisir un chemin quelconque, nous pouvons effectuer nous même le travail
d’encapsulation qui doit être fait pour ces paquets. Il s’agit là de les encapsuler, au moment leur passage par notre
plateforme IP Transit, dans de l’IPv4 à destination de l’adresse « V4ADDR » contenue dans l’adresse IPv6 de
destination. De cette manière, les paquets qu’émettent nos clients IPv6 (natif) à destination de correspondants situés
dans un « îlot 6to4 » seront encapsulés par les routeurs IPTs qui est, pour eux, un point de passage obligatoire.
Pour cela, la configuration mise en œuvre est très simple : elle permet à un paquet IPv6 à destination de la plage
2002::/16 (comme l’est 2002:c000:203::1 de l’exemple précédent) d’être routé vers IPT-TH2 qui doit l’encapsuler
dans un paquet IPv4 ayant pour destination 192.0.2.3, (et pour source 93.95.56.108) et dont le numéro de protocole
est 41.
Dans la configuration, seules les adresses IPv4 sources changent entre IPT-TH2 et IPT-GLS avec respectivement
93.95.56.108 et 93.95.56.109, qui sont les adresses que nous réservons à l’encapsulation 6to4. Cette distinction
permettra de mieux identifier les problèmes et de mieux comprendre le cheminement des flux.
Page 47
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
47
Voici un extrait de la configuration de la partie « 6to4 relay router (encapsulation only) » sur IPT-TH2 :
! Sur IPT-TH2 (En rouge : ce qui change sur IPT-GLS)
!
interface Tunnel2002
no ip address
no ip redirects
ipv6 enable
tunnel source 93.95.56.108
tunnel mode ipv6ip 6to4
!
ipv6 route 2002::/16 Tunnel2002
!
end
Il existe cependant d’autres filtres pour bloquer des paquets à destination de plages non routables sur Internet
publique. Par exemple, le route 2002:a00::/24 pointe vers l’interface Null0 pour ne pas encapsuler les paquets qui
seraient sans cela encapsulés pour atteindre une adresse de la plage 10.0.0.0/8.
6.9.3 Rôle de décapsulation du 6to4 relay router
Dans le sens retour des paquets, pour permettre à nos clients n’ayant pas d’IPv6 natif mais possédant une IPv4 de
Covage d’être un « îlot 6to4 », il est nécessaire d’implémenter la décapsulation du « 6to4 relay router » donc de
décapsuler les paquets IPv4 à destination de 192.88.99.1 (pour retrouver le paquet IPv6).
Cependant, après tests, il s’avère que le matériel que nous utilisons ne peut faire cette décapsulation qu’en logiciel,
ce qui impacte fortement le CPU et limite le trafic à environ 4000 paquets par secondes (soit 6Mbps pour des
paquets de 1500 octets).
Par ailleurs, la stratégie mise en place est de pousser l’IPv6 native en délivrant des IPv6 de notre préfixe
(2a02:2358::/32) plutôt que d’inciter les clients à créer des « îlots 6to4 » qui seraient basés sur une IPv4 de l’un de
nos préfixes (comme 93.95.56.0/21). Les clients qui auraient créés un « îlot 6to4 » verront leurs paquets routé en
anycast sur Internet IPv4 vers le préfixe 192.88.99.0/24 appris par BGP, sans intervention de notre part, selon le
routage classique.
Nous souhaitons donc proposer une qualité optimale de routage pour IPv6 pour nos clients utilisant l’IPv6 natif,
même si leurs correspondants Internet utilisent du 6to4 mais nous ne souhaitons pas encourager nos clients à utiliser
le 6to4. C’est donc bien l’IPv6 natif qui est mis en avant.
6.9.4 Autres mécanismes de transition utilisant des préfixes anycast
Notons que d’autres mécanismes de transition utilisent des préfixes routés en anycast sur Internet, comme Teredo
(normalisé par la RFC4380) qui utilise le préfixe 2001::/32. Cependant, le matériel que nous utilisons ne semble pas
supporter du tout ce mécanisme, comme l’ensemble de la gamme Cisco.
Dans ce cas, lorsqu’ un usager d’Internet utilisant Teredo souhaite communiquer avec un de nos clients utilisant IPv6
natif, les paquets sont routés en Anycast. Il semble d’ailleurs que les routeurs BGP de Neo Telecoms bloquent le
préfixe 2001::/32.
Pour nos clients, il ne sera en fin de compte possible d’utiliser ce mécanisme qu’en empruntant la route que nous
annonce Level3. Au moment du déploiement d’IPv6 sur IPT-GLS, nous ne possédons pas de routage IPv6 par Level3.
! Sur IPT-GLS
!
>show bgp ipv6 unicast 2001::/32
% Network not in table
Page 48
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
48
6.10 Gestion de la délégation DNS inverse pour IPv6
Tout comme en IPv4, l’allocation par le RIPE-NCC d’une plage IPv6 impose de gérer la délégation inverse du DNS pour
les clients : ainsi, lorsque Covage fera une assignation d’une partie de son espace IPv6 à un opérateur local (un /48), il
sera nécessaire de pouvoir déléguer la résolution inverse DNS pour la plage assignée au client.
Dans le cas nouveau d’IPv6, la configuration de la délégation est assez simple :
Demander au RIPE-NCC de configurer deux entrées « NS » vers ses serveurs de noms dans la zone qu’il a
administre : « 0.a.2.ip6.arpa. », correspondant à la plage IPv6 2a00::/12 et que l’IANA leur délègue( qui doit
être fait à l’aide de l’objet DOMAIN dans la base de données du RIPE-NCC). Cependant, à l’heure actuelle,
cet enregistrement n’a pas encore été créé.
Créer une zone DNS pour notre préfixe : « 8.5.3.2.2.0.a.2.ip6.arpa. » sur les deux serveurs de noms, et la
faire évoluer avec les assignations.
Optionnellement, pour permettre à ces serveurs de noms d’être joint en IPv6, il sera nécessaire de leur
configurer une adresse IPv6 et la renseigner dans les enregistrements que l’on demande au RIPE-NCC de
publier.
Après configuration de l’objet « DOMAIN » de la base de données du RIPE-NCC, voici les deux enregistrements que le
serveur de noms du RIPE-NCC doit retourner sur demande d’une adresse de notre préfixe :
8.5.3.2.2.0.a.2.ip6.arpa. 86400 IN NS ns1.covage.com.
8.5.3.2.2.0.a.2.ip6.arpa. 86400 IN NS ns2.covage.com.
Les deux noms indiqués doivent avoir des enregistrements A et AAAA, donnant les adresse IPv4 et IPv6 auxquelles les
joindre. Par exemple, pour « ns1 », situé dans la zone « covage.com. » que Covage peut aussi gérer elle-même :
ns1.covage.com. 86400 IN A 93.95.56.140
ns1.covage.com. 86400 IN AAAA 2a02:2358:301::1
Les enregistrements A et AAAA de « ns2.covage.com. » seront logiquement semblables.
Pour la suite, les serveurs de noms doivent simplement implémenter une nouvelle zone DNS, correspondant au
préfixe IPv6 qui nous a été assignée : « 8.5.3.2.2.0.a.2.ip6.arpa. ». C’est alors simplement une liste d’enregistrement
« NS » pour déléguer une sous-zone au client, ou bien un enregistrement « PTR » pour désigner une machine.
Par exemple, lorsque nous implémentons la délégation pour le client nommé « client1 » auquel nous assignons la
plage « 2a02:2358:601::/48 », nous ne rencontrons pas de difficulté particulière liée à l’IPv6 dans la gestion de la
délégation DNS inverse.
Vous trouverez ci-dessous, un exemple de configuration simplifié, les durées sont celles proposées par le RIPE-NCC
par le document [RIPE-203] :
$ORIGIN 8.5.3.2.2.0.a.2.ip6.arpa.
$TTL 2d
; La représentation de la zone DNS
@ IN SOA ns1.covage.com. hostmaster.covage.com. (
2010102706 ; Serial (YYYYMMDDnn)
1d ; Refresh
2h ; Retry
1000h ; Expire
2d ) ; Minimum / Negative Cache TTL
IN NS ns1.covage.com.
IN NS ns2.covage.com.
; Pour la plage 2a02:2358:601::/48, on délègue aux deux serveurs du client
1.0.6.0 IN NS ns1.client1.example.
1.0.6.0 IN NS ns2.client1.example.
; Pour l’adresse 2a02:2358:301::1, c’est l’hôte « host1 »
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.3.0 IN PTR host1.covage.com.
Page 49
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
49
7 Mise en production la nouvelle plateforme IP Transit
La migration de l’ancienne vers la nouvelle plateforme s’est faite dans le mois de décembre 2010 : elle comporte une
période transitoire, l’architecture transitoire qui désigne l’architecture dans laquelle le routeur IPT-GLS est en
configuration cible alors que le routeur IPT-TH2 utilise encore l’ancienne configuration avec l’ancien matériel (un
Cisco 7204). Ces deux architectures doivent cohabiter malgré les différences dans leurs façons d’effectuer le routage.
J’ai donc préparé un plan de migration permettant d’appliquer la configuration qui fonctionne en laboratoire sur les
PEs de TH2 et de GLS. Les routeurs IPTs sont préparé avant et connecté physiquement pour entrer en production
sans modifications. Les modifications à appliquer aux PE sont prêtes à l’avance et applicable par copié-collé.
Le planning prévu pour ordonnancer les étapes de la modification a été prévu par Phong Nguyen, il comporte pour
chacun des deux routeurs, trois étapes :
Installation du nouveau matériel dans le datacenter et connections physiques, il est inutilisé mais est
accessible à distance ;
Déconfiguration de l’ancien routeur IPT (Cisco 7204) et configuration du nouveau routeur (Cisco 7606), il est
alors utilisé en temps que routeur secours pendant une semaine ;
Passage des flux sur le routeur IPT récemment installé : on test ainsi qu’il est capable de fonctionner en
nominal, et permet de commencer les modifications sur le second routeur.
Cette migration nécessite la cohabitation des deux, malgré leurs différences de fonctionnement, d’adressage et de
matériel. Il faut donc gérer cette différence pour permettre le passage de l’une à l’autre sans interruption du service
et sans causer de nouveaux problèmes. Un plan de changement progressif a été établi pour passer de l’ancienne à la
nouvelle architecture sans toutefois interrompre les flux de production. En jouant sur le protocole de routage, on
modifie le parcours des paquets pour le forcer à utiliser sur un routeur. On peut ensuite effectuer les actions de
modification nécessaires sur l’autre routeur, sans risque de pertes de paquets pour le service.
Comme l’ancienne architecture utilisait OSPF pour la communication entre IPT-TH2 et la VRF IPT-1 du PE de TH2, la
route par défaut qui est présente dans le Backbone MPLS présente un AS_PATH de taille différente. Il est donc
impossible de jouer sur l’attribut MULTI_EXIT_DISC car il n’est pas pris en compte quand l’AS_PATH est de taille
différent : c’est donc l’attribut LOCAL_PREF qui est notre dernière option. Contrairement à l’attribut
MULTI_EXIT_DISC, cet attribut LOCAL_PREF n’est pas transitif (d’un AS à l’autre) il sera donc nécessaire de modifier
l’annonce en entrée sur le Backbone, via les route-map IPT-IPT-TH2-IN et IPT-IPT-GLS-IN dans les VRFs « IPT-1 ».
Il faut également basculer les flux qui circulent entre les routeurs IPTs et Internet. Ils sont déplacés d’un routeur IPT à
l’autre en jouant sur les attributs BGP : la bascule des flux entrants se fait en modifiant l’AS_PATH de chacune des
annonces. Le flux montant est déplacé en deux temps : d’une part changer la LOCAL_PREF sur les annonces des deux
routes par défaut que le Backbone apprend depuis la plateforme. Sur les routeurs IPTs il faut appliquer une
LOCAL_PREF faible aux routes apprissent par iBGP, pour réduire au maximum l’usage de ce lien. Pour finir, il faut
couper tous les liens BGP en effectuant un shutdown de tous les voisins. Dans l’ancienne architecture (qui utilisait
OSPF), plutôt que de faire un shutdown, il suffit de stopper la redistribution de BGP dans OSPF.
Page 50
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
50
7.1 Différence entre la nouvelle et l’ancienne architecture
La première différence entre l’ancienne et la nouvelle est que les préfixes spécifique assigné aux clients (/30
notamment) sont maintenant annoncé jusqu’aux routeurs IPTs échangés en iBGP (entre les IPTs) dans la nouvelle
architecture alors que dans l’ancienne, les routeurs IPTs ne connaissait que les préfixes alloués par le RIPE-NCC (3
préfixes /21 et 1 /23). Des filtres temporaires doivent donc être mis en place pour la plateforme transitoire pour
éviter que ces préfixes spécifiques ne soient annoncés d’IPT-GLS à IPT-TH2 (lien iBGP), sous peine de voir le trafic
descendant emprunter ces routes plus spécifiques passant par IPT-GLS.
L’architecture transitoire présente une autre particularité : la VRF IPT-1 du PE de TH2 apprend la route par défaut par
redistribution d’OSPF, son AS_PATH est plus court (vide), au contraire de la VRF IPT-1 du PE de GLS qui l’apprend par
eBGP (avec 1 AS). Il ne nous est donc plus possible de jouer la métrique (l’attribut MULTI_EXIT_DISC en BGP et coût
en OSPF) de la route par défaut pour changer le parcours des flux montant vers Internet. Il faut donc augmenter la
valeur de l’attribut LOCAL_PREF au sein des VRFs IPT-1, pour faire en sorte que les VRFs IPT choisissent la route
annoncé par la nouvelle architecture. Cette modification ne peut être faite que sur le PEs, car la LOCAL_PREF est non-
transitif et il s’agit du seul attribut dont l’importance précède la longueur de l’AS_PATH dans l’algorithme de
sélection de BGP (hors weigth chez Cisco).
7.2 Problème rencontrés lors de la migration
7.2.1 L’ACL filtrant les paquets arrivant depuis le Backbone MPLS (IPT-CORE-IN)
L’ACL IPT-CORE-IN, qui a pour but de protéger la plateforme IP Transit et de supprimer une partie des paquets non
conformes à un routage sur Internet s’est avérée problématique : dès la mise en service, une grande quantité de
paquets n’avaient pas pour source une adresse IP des plages de IPT-COVAGE ou IPT-CLIENT. C'est-à-dire que nous
transmettons des paquets dont la source est hors des quatre préfixes que nous annonçons sur Internet. Après lecture
des fichiers de logs, certains paquets avaient pour source des adresses IP privées alors que d’autres sont des adresses
valides assignées.
Le service IP Transit est alors utilisé par un client pour émettre des paquets vers Internet mais pas pour en recevoir :
ceux-ci n’étant pas annoncés en BGP par notre AS. Avant d’en connaitre plus sur la légitimité de ces flux, il a été
décidé de les autoriser plus largement. Les adresses privées cependant bloquées par les ACL IPT-<FAI>-OUT.
7.2.2 Policy-map de l’ancienne architecture
L’ancienne architecture avait la même policy-map IPT-POLICING permettant de limiter le débit des paquets venant
d’Internet. Cependant, contrairement à la nouvelle architecture, elle était aussi appliquée sur le lien iBGP : les
paquets venant du Backbone MPLS pour aller vers Internet se retrouvaient donc limités par cette policy-map qui
classait ce flux dans la classe par défaut.
Lors du changement de l’architecture, nous nous sommes donc retrouvés à utiliser intensément le lien iBGP pour
envoyer les paquets vers le fournisseur de transit Level3 via le routeur IPT-TH2. Ces flux passant par Level3 se sont
donc retrouvés policés à 5Mbps. Cette limitation interrompait la communication BGP car les messages KEEPALIVE
n’arrivait plus dans les 15 secondes configurées du « HoldTimer ».
Bien que ce problème ai été vu lors de tests en laboratoire, les résultats n’ont pas été considéré comme alarmant : la
grande perte de paquets a été imputé aux faibles performances du routeur représentant IPT-TH2 (un Cisco 2811). Le
test mettait en évidence un routage correct via IPT-TH2, sans prendre en compte les performances.
Page 51
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
51
7.2.3 Défauts matériels
Durant la phase de test de la nouvelle plateforme, des redémarrages anormaux d’un des routeurs IPTs (Cisco 7606)
ont eu lieu en moyenne une par mois : ils furent attribués à un bug logiciel reproduit par la modification fréquente de
la configuration, ces modifications ne devant être qu’occasionnelles lors de la production. Lors du de la mise en
production de la plateforme, ces problèmes se sont révélés au contraire très fréquents sur le premier routeur
installé, IPT-GLS, pour atteindre plusieurs redémarrages par semaine. Les renseignements apportés par le fournisseur
ont confirmé qu’il s’agissait d’une défaillance matérielle de la carte SUP720, gérant le plan contrôle. Les
modifications très fréquentes dues à BGP avaient énormément sollicité la carte et provoqué cette grande perte de
paquets.
Un autre problème est apparu lors de la livraison du second routeur IPT : la carte de commutation ne pouvait
accepter plus de 256000 routes IPv4 environ dans la table de routage matérielle (CEF). Le routeur serait alors passé
en routage logiciel dès sa connexion aux fournisseurs de transit, qui ne gère pas plus de 100 paquets par secondes. Il
s’agit d’un problème lié à la carte effectuant la commutation : elle ne possède que 250Mo de mémoire vive alors que
1Go avait été commandé.
Le dépassement des 256000 routes produisait un message étrange ne correspondant pas aux messages vus
habituellement lors du dépassement de la capacité du CEF : ceci est probablement du au décalage entre la capacité
mémoire de la carte contrôleur par rapport à la carte de commutation du Cisco 7606.
# Sur le Cisco 7606 dont la carte de commutation manque (module 1) de mémoire vive
%SYS-DFC1-2-MALLOCFAIL: Memory allocation of 65536 bytes failed from 0x205D85C8, alignment 4
Pool: Processor Free: 63988 Cause: Not enough free memory
Alternate Pool: None Free: 0 Cause: No Alternate pool
-Process= "XDR LC Background", ipl= 0, pid= 221
-Traceback= 2059A85C 205BE56C 205D85D0 21532E9C 21585CC8 21586410 21586894 2158A990 2158ABB4
21512A90 216574DC 216509BC 216515F8
%COMMON_FIB-DFC1-3-NOMEM: Memory allocation failure for prefix in IPv4 CEF [0x21532F34]
(fatal) (2939 subsequent failures).
%COMMON_FIB-DFC1-4-DISABLING: IPv4 CEF is being disabled due to a fatal error.
%FIB-2-FIBDISABLE: Fatal error, slot 1/0 (1): CEF-IPv4: no memory
%XDR-DFC1-6-XDRLCDISABLEREQUEST: Client CEF push requested to be disabled.
-Traceback= 21652150 21507414 2157B170 215968EC 21596AB4 205840BC 205840A0
Il fallait alors interroger la carte de commutation (module 1) elle-même plutôt que le routeur (et donc la carte
contrôleur) pour se rendre compte que seulement 256Mo de mémoire vive sont installés :
# Sur le Cisco 7606 dont la carte de commutation (module 1) manque de mémoire vive
>show version
…
cisco CISCO7606-S (R7000) processor (revision 1.1) with 983008K/65536K bytes of memory.
…
>remote command module 1 show version
…
cisco Catalyst 6000 (SB1121) processor with 262144K bytes of memory.
…
Page 52
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
52
8 Conclusion
8.1 Conclusion sur les réalisations
Fin décembre 2010, en raison des retards occasionnés par les problèmes matériels, la migration de la plateforme n’a
pas pu être achevée : en effet l’un des deux routeurs est toujours un ancien Cisco 7204. Cependant, le design de la
plateforme cible est achevé et les tests en laboratoire sont concluants : les fonctionnalités requises peuvent être
déployées.
La plateforme pourra être déployée dans sa version cible, prévue pour durer quelques années, le matériel
défectueux aura alors été échangé par le fournisseur. Le déploiement de la plateforme suit un plan et ne nécessite
pas l’interruption du service.
Pour l’IPv4, aucune modification n’est nécessaire sur le réseau Backbone et le changement de plateforme apporte à
lui seul le gain de performance souhaité.
Concernant l’IPv6, un plan de déploiements est prévu, testé et a été exécuté sur une partie du réseau Backbone.
L’architecture prévue est suffisamment proche de ce qui existe en IPv4 pour permettre une prise en main rapide par
les équipes qui maitrisent déjà le service IP Transit, tout en utilisant de manière optimale les possibilités d’IPv6.
Début 2011, Covage sera donc en mesure de commercialiser plus de service IP Transit avec un support IPv6
pleinement opérationnel.
8.2 Conclusion sur mon stage
Au niveau professionnel, ce stage m’a permis d’appliquer des théories vues en cours, sur des aspects très poussés du
routage qui ne sont pas aussi étudiés en cours, mais aussi sur des aspects qui semblent à l’heure actuelle peu
maitrisés dans le monde des télécom : dans le cas d’IPv6, il s’agit de la première mise en œuvre par Covage.
Il m’a permis de manipuler de manière très pratique les protocoles employés chez les opérateurs Télécom
(notamment BGP), sur du matériel haut de gamme et dans le cadre des besoins nécessaires aux clients. En exécutant
la migration sur la plateforme réelle, j’ai également pu vivre la transformation de ce qui est l’outil de production de
Covage et non de manière théorique dans un laboratoire.
Je regrette, cependant, de ne pouvoir suivre l’évolution de la plateforme : ce qui m’aurait permis de constater à long
terme sur le service, la justesse ou non des choix que j’ai pris et leurs conséquences ainsi que la manière dont seront
appliquées les recherches que j’ai menées pour les évolutions futures.
Page 53
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
53
9 Bibliographie [ROUTING] Jeff Doyle, and Jennifer DeHaven Caroll. Routing TCP/IP, Volume II. Cisco Press, April 11, 2001. ISBN
978-1-57870-089-9.
[ROUTEAGGR] Understanding Route Aggregation in BGP, Document ID: 5441. Cisco Systems, August, 10 2005.
<http://www.cisco.com/application/pdf/paws/5441/aggregation.pdf>.
[BGPBESTPATH] BGP Best Path Selection Algorithm, Document ID: 13753. Cisco Systems, May 24, 2006.
<http://www.cisco.com/image/gif/paws/13753/25.pdf>.
[BGP4] Yakov Rekhter, Tony Li, and Susan Hares. A Border Gateway Protocol 4 (BGP-4), RFC 4271. IETF,
January 2006. <http://www.ietf.org/rfc/rfc4271>. ISSN 2070-1721.
[BGPAS32] Quaizar Vohra, and Enke Chen. BGP Support for Four-octet AS Number Space, RFC 4893. IETF, May
2007. <http://www.ietf.org/rfc/rfc4893>. ISSN 2070-1721.
[RFC1997] Paul Traina, Ravishanker Chandrasekeran, and Tony Li. BGP Communities Attribute, RFC 1997. IETF,
August 1996. <http://tools.ietf.org/html/rfc1997>. ISSN 2070-1721.
[RIPE-481] Brett Carr, Ondrej Sury, Jordi Palet Martinez, Andy Davidson, Rob Evans, Filiz Yilmaz, and Ingrid
Wijte. IPv6 Address Allocation and Assignment Policy, ripe-481. RIPE-NCC, September 2009.
<http://www.ripe.net/ripe/docs/ipv6policy.html>.
[IPV6GUA] Robert Hinden, Stephen Deering, and Erik Nordmark. IPv6 Global Unicast Address Format, RFC
3587. IETF, August 2003. <http://tools.ietf.org/html/rfc3587>. ISSN 2070-1721.
[IPV6ARCH] Robert Hinden, and Stephen Deering. IP Version 6 Addressing Architecture, RFC 4291. IETF,
February 2006. <http://tools.ietf.org/html/rfc4291>. ISSN 2070-1721.
[6TO4] Brian Carpenter, and Keith Moore. Connection of IPv6 Domains via IPv4 Clouds, RFC 3056. IETF,
February 2001. <http://tools.ietf.org/html/rfc3056>. ISSN 2070-1721.
[6TO4PREFIX] Christian Huitema. An Anycast Prefix for 6to4 Relay Routers, RFC 3068. IETF, June 2001.
<http://tools.ietf.org/html/rfc3068>. ISSN 2070-1721.
[6TO4SEC] Pekka Savola, and Chirayu Patel. Security Considerations for 6to4, RFC 3964. IETF, December 2004.
<http://www.ietf.org/rfc/rfc4271>. ISSN 2070-1721.
[TEREDO] Christian Huitema. Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs),
RFC 4380. IETF, February 2006. <http://tools.ietf.org/html/rfc4380>. ISSN 2070-1721.
[RIPE-203] Peter Koch. Recommendations for DNS SOA Values, ripe-203. RIPE-NCC, June 1999.
<http://www.ripe.net/docs/dns-soa.html>.
[RFC3177] IAB/IESG Recommendations on IPv6 Address Allocations to Sites, RFC 3177. IETF, September 2001.
<http://tools.ietf.org/html/rfc3177>. ISSN 2070-1721.
[RFC3177BIS] Thomas Narten, Geoff Huston, and Lea Roberts. IPv6 Address Assignment to End Sites, Work in
Progress. IETF, September 26, 2010. <http://tools.ietf.org/html/draft-ietf-v6ops-3177bis-end-sites-
00>.
[COVAGE] Covage – Opérateur d’opérateurs. http://www.covage.com/, consulté le 27 novembre 2010.
[IPTPRODUIT] Service IP Transit – Fiche Produit. Covage, Janvier 2010. Accessible sur le site de Covage :
http://www.covage.com/page/transit-ip-32.html.
[IPTSTAS] Spécifications techniques d’accès au Service « IP Transit » v1.0. Covage, 7 avril 2010. Accessible sur
le site de Covage : http://www.covage.com/page/transit-ip-32.html.
Page 54
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
54
10 Table des figures
Figure 1 : L’actionnariat dans la société Covage (extrait du site http://www.covage.com/) ........................................... 7
Figure 2 : Service IP Transit : le Backbone MPLS et la plateforme .................................................................................. 11
Figure 3 : Evolution de la somme des débits commercialisés du service IP Transit........................................................ 12
Figure 4 : Liens du service IP Transit : VRFs IPT et IPT-1 du Backbone MPLS, clients et fournsseurs de transit ............. 16
Figure 5 : Liens physiques entre les routeurs de la plateforme et le Backbone MPLS ................................................... 17
Figure 6 : Communication entre deux clients IP Transit ................................................................................................. 24
Figure 7 : Propagation des routes utilisées pour les flux descandants depuis les Internet vers les clients ................... 26
Figure 8 : Propagation des routes utilisées pour les flux montants depuis les clients vers Internet ............................. 27
Figure 9 : Préfixe IPv6 alloué à Covage ........................................................................................................................... 38
Figure 10 : Utilisation des 32 bits d'adressage du préfixe alloué à Covage .................................................................... 39
Figure 11 : Fonctionnement du 6to4 : échange de paquets entre un hôte IPv6 natif et un hôte dans un îlot 6to4 ...... 45
Page 55
Modernisation du service IP Transit de Covage Services Jean Rebiffé – Thèse professionnelle – Télécom ParisTech - 2010
55
11 Index
6
6PE, 42
6to4, 43, 44
6to4 relay router, 44
6to4 router, 45
A
ACL, 32, 43, 50
adresses IPv6 locales uniques, 43
adresses IPv6 unicast locales de site, 43
aggregate-address, 25, 29, 43
AGGREGATOR, 25, 26
agrégation, 25, 29, 38, 40, 43
allocation initiale IPv6, 41
anycast, 44, 46
AS 32bits, 12, 13
AS_PATH, 25, 30, 31, 49
ATOMIC_AGGREGATE, 25, 26
B
BFD, 18
C
class-map, 35
CZNIC, 45
D
décapsulation, 45, 47
DNS, 41, 48
E
eBGP, 18, 25, 42
encapsulation, 44, 46
etherchannel, 17
G
GlobalSwitch, 15, 30, 38
H
HD-Ratio, 40
HoldTimer, 18, 50
Hurricane Electric, 45, 46
I
IANA, 14, 32
iBGP, 16, 17, 24, 50
îlot 6to4, 44
inet6, 41
IPv6, 12, 14, 38
IPv6 address policy, 40
IPv6 RIPEness, 41
L
Level 3 Communication, 11
looking-glass, 26
Loopback, 18, 39
M
MULTI_EXIT_DISC, 28, 30, 49
N
NAT, 14
Neo Telecoms, 11, 20, 25, 31, 47
NetFlow, 37
NO_EXPORT, 29
numéro d’AS, 11, 25, 30, 41
O
OSPF, 12, 24, 25
OSPFv3, 12, 42
P
peering, 12, 36
points de peering, 36
policy-map, 36, 50
pseudowire, 17
R
RIPE-NCC, 14, 38, 40, 41
route6, 41, 46
routes distinguisher, 21
route-target, 18, 21, 28
T
TeleHouse2, 15, 30, 36, 38
Teredo, 43, 47
traduction d’adresse réseau, 14