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

Modernisation du service IP Transit de Covage Services - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

Embed Size (px)

Citation preview

Page 1: Modernisation du service IP Transit de Covage Services - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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 - Thèse professionnelle - Jean Rebiffé - Télécom ParisTech - 2010

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