rapport sm

Simon MUYAL Mastre SCR - 1 -

Rapport de stage :

Mise en place d'outils de supervision IPv6 au sein du rseau RENATER

Entreprises:

Simon MUYAL Mastre SCR, ENSEEIHT

2002-2003


Remerciements

Je tiens tout particulirement remercier mes matres de stage M. Silvre

PRADELLA et M. Bernard TUY pour leur accueil chaleureux, ainsi que M. Dany VANDROMME, le directeur du GIP RENATER, de mavoir accept en tant que stagiaire au sein de CS et du GIP RENATER. Je remercie galement M. Jrme DURAND, M. Pierre-Emmanuel GOIFFON, M Thierry BONO et M. Franois-Xavier ANDREU pour leur soutient technique.

D'une faon plus gnrale, je remercie l'ensemble du NOC (Network Operations Center) CS et le GIP RENATER, pour lintrt quils mont port tout au long de mon stage ainsi que pour leur aide et prcisions. Je remercie de mme, ma tutrice de stage Mme. Batrice PAILLASSA pour son encadrement pendant celui-ci.


Sommaire REMERCIEMENTS................................................................................................................ 3

SOMMAIRE ............................................................................................................................. 4

INTRODUCTION.................................................................................................................... 5

1. PRESENTATION DES ENTREPRISES........................................................................... 6 1.1 PRESENTATION DE CS ....................................................................................................... 6

1.1.1 Historique de CS ....................................................................................................... 7 1.1.2 Organisation et activits de CS................................................................................. 8 1.1.3 Prsentation du NOC .............................................................................................. 10

1.2 PRESENTATION DE RENATER........................................................................................ 11 1.2.1 Le rseau RENATER ............................................................................................... 11 1.2.2 RENATER et IPv6 ................................................................................................... 12

1.3 PRESENTATION DU GIP RENATER................................................................................ 12 1.3.1 Historique................................................................................................................ 12 1.3.2 Son mtier : Matrise d'ouvrage.............................................................................. 12

2. ETUDES DES BESOINS................................................................................................... 13 2.1 OUTILS DE SUPERVISION UTILISES EN IPV4...................................................................... 14

2.1.1 Au NOC (CS)........................................................................................................... 14 2.1.2 Au GIP Renater ....................................................................................................... 15

2.2 ETAT DE LART DES MIB IPV6 ........................................................................................ 17 2.3 LES OUTILS EXISTANTS EN IPV6 ...................................................................................... 19

3. TRAVAUX REALISES ..................................................................................................... 21 3.1 MISE EN PLACE D'UN LOOKING GLASS............................................................................. 21

3.1.1 Problmatique ......................................................................................................... 21 3.1.2 Solution Mise en place de loutil: ........................................................................ 22

3.2 INVENTAIRE DES EQUIPEMENTS DE RENATER-3 : ......................................................... 25 3.2.1 Contexte................................................................................................................... 25 3.2.2 Objectifs .................................................................................................................. 26 3.2.3 Prsentation de l'application .................................................................................. 27

3.3 CONCLUSION ................................................................................................................... 34

4. EVOLUTIONS POSSIBLES ............................................................................................ 34 4.1 EVOLUTIONS A COURT TERME ......................................................................................... 34 4.2 EVOLUTIONS A MOYEN ET LONG TERMES ........................................................................ 34

5. CONCLUSION................................................................................................................... 35

6. GLOSSAIRE....................................................................................................................... 36

7. REFERENCES BIBLIOGRAPHIQUES......................................................................... 37

8. ANNEXES........................................................................................................................... 38


Introduction

Ce stage, dune dure de six mois, a consist mettre en place des outils dadministration IPv6 pour le rseau RENATER.

Ce rapport prsente le travail que jai effectu lors de mon stage au sein de CS et du

GIP RENATER. Il sest droul du 1 avril au 16 mai 2003 au NOC RENATER dans l'entreprise CS et du 19 mai au 30 septembre 2003 au GIP RENATER. Pendant la priode au NOC RENATER, je me suis familiaris avec un environnement technique et un ensemble dapplications IPv6. Ceci ma permis ensuite, dans la deuxime partie de mon stage au GIP RENATER de mettre en place des outils dadministration IPv6.

Le projet ralis sest avr trs intressant et trs enrichissant pour mon exprience professionnelle. En effet, ma formation sinscrit prcisment dans ce secteur (spcialisation Systmes de Communications et Rseaux). Grce ce stage, jai travaill sur des projets qui mont permis dentrevoir en quoi consiste la profession dingnieur dans ce secteur dactivit.

Le but de ce rapport nest pas de faire uniquement une prsentation exhaustive de tous les aspects techniques que jai pu apprendre ou approfondir, mais aussi, de manire synthtique et claire, de faire un tour dhorizon des aspects techniques et humains auxquels jai t confront.

Je vous expose dans ce rapport en premier lieu une prsentation des entreprises. Ensuite, je vous explique les diffrents aspects de mon travail durant ces quelques mois et enfin, en conclusion, je rsume les apports de ce stage.


1. Prsentation des entreprises

1.1 Prsentation de CS CS Communication & Systmes est un acteur majeur des technologies de l'information et de l'intgration de systmes. Il se compose de 3000 collaborateurs dont 70 % d'ingnieurs. Il a ralis un chiffre daffaires en 2002 de 387 millions deuros.

La vocation du groupe CS est de construire des solutions globales dans le domaine des tlcommunications, des systmes et services informatiques et de la scurit. CS met au service de ses clients son intelligence des rseaux, son expertise scientifique et technique et son savoir-faire industriel.

Associant avance technologique, orientation produit / march et solidit financire, CS apporte ses clients des rponses en forte ractivit aux grandes mutations des technologies et des marchs mondiaux. Etre un acteur engag de la rvolution des rseaux qui modle dj le troisime millnaire : c'est ainsi que le Groupe CS exprime sa fidlit sa vocation originelle d'innovateur technologique sur des marchs forte croissance. Sa vocation est de participer la rvolution des rseaux de communication et d'information. Celle-ci se situe au croisement de l'industrie, des systmes et des services. Son ambition est de s'tablir parmi les leaders europens sur ses marchs grce sa capacit d'innovation, son potentiel humain et technologique, sa solidit financire et sa stratgie de croissance dynamique.


1.1.1 Historique de CS

1902 Cration de la Compagnie des Signaux et dEntreprises Electriques (CSEE) par Francis Cumont, un pionnier de la signalisation lectrique pour les chemins de fer et le mtropolitain. La socit devient la rfrence majeure dans les domaines mcanique, lectrique puis lectromcanique.

Annes 50-60 CS prend le virage de llectronique pour lappliquer la signalisation, aux tl-contrles et aux tlmesures. La socit simpose alors sur des marchs en pleine croissance : Tlcoms, Dfense, Pages routiers et Transports.

Annes 90 CS se positionne, travers ses diffrents mtiers, comme un spcialiste des rseaux et des systmes d'information.

1991-1995 CS est marqu par une croissance rsolue dans le domaine des technologies de l'information, en particulier grce lacquisition des socits SECRE, RCE, Vrilog et CSTI.

1996-1997 Le Groupe CS mne bien un recentrage dcisif de ses activits sur des secteurs forte croissance lis aux systmes d'information : dveloppement dans le domaine du logiciel avec l'acquisition du groupe CISI, renforcement de la dimension quipement tlcoms et ingnierie de rseau avec l'acquisition de Philips Communication d'Entreprise, cration du ple scurit avec l'acquisition de MATRA Scurit, de Ritzenthaler et de sa filiale Haffner. Par la mme occasion, il abandonne ses activits CSEE-Transport et CS-Dfense

Juillet 1999 CS Compagnie des Signaux devient CS Communication & Systmes, unifiant ainsi la marque commerciale et la dnomination sociale du groupe, intgrant les marques CISI, ATHESA, EXPERDATA, TRANSTEC, AIP. Ces marques, encore prsentes dans lesprit de tous ceux qui leur font confiance sont amenes disparatre progressivement.

Aujourd'hui, le groupe CS s'est dfinitivement recentr sur les technologies de l'information travers sa branche d'activit initialement connue sous le nom de CS SI (Systmes d'Informations), aprs le dpt de bilan de CS Tlcoms (quipements rseaux) et la revente de son activit CS Security (scurit physique).


1.1.2 Organisation et activits de CS CS se positionne aujourd'hui comme une SSII diffrencie, forte de ses 4 ples de comptences complmentaires :

Missions critiques (Applications industrielles et scientifiques, Dfense et Contrle du Trafic Arien (CTA) et Route)

Network Services Solutions et Conseil en Technologies Infogrance

1.1.2.1 Missions Critiques

Applications Industrielles et Scientifiques, dont la mission est de promouvoir et dvelopper des services et des solutions logicielles pour l'industrie et les organismes de recherche, plus spcifiquement pour les marchs de l'espace, l'aronautique, l'automobile, le nuclaire et les autres industries. Ses offres s'articulent autour des logiciels embarqus, systmes temps rels, ralit virtuelle, etc

Dfense / CTA, dont la mission est de fournir "cl en main" des systmes lis aux domaines sectoriels, comme le commandement, la conduite et la communication pour des applications militaires, le renseignement, simulateurs de contrle du trafic arien civil ou militaires, systmes d'informations logistiques, etc..

Route, dont la mission est d'intgrer des systmes appliqus au secteur du transport routier. Elle propose des offres pour les systmes de page et tl page, pour les rseaux d'appels d'urgence et la gestion et le contrle de trafic.


1.1.2.2 Network Services

Cette activit a pour mission de concevoir, dployer, intgrer et maintenir les rseaux des grandes ou moyennes entreprises de l'ensemble du secteur des services. Ses offres:

Audit

Intgration de Rseaux

Service clients

1.1.2.3 Solutions et Conseils en Technologie

Ses missions sont de promouvoir et dvelopper une offre de services associs aux systmes de communication, ainsi que de dvelopper les services pour certaines activits (banques, etc).

Pour cela ses offres son trs larges et englobent aussi bien :

la scurit des communications et applications distribues,

les solutions d'administration, supervision, hypervision des systmes de communication,

la convergence multimdia des technologies rseau

l'interaction entre l'oprateur et ses clients (Centres d'appels)

migration, conversion de donnes

montique

1.1.2.4 Infogrance

Cette activit a pour mission de grer et faire voluer loutil informatique de ses clients. Les solutions mises en uvre sont des solutions adaptes aux besoins prcis de chaque client, elles couvrent tout ou partie du systme dinformation. La direction dactivit Infogrance possde une comptence dans les activits de linformatique scientifique et technique, dans les activits de linformatique de gestion portant sur le maintien en condition oprationnelle des quipements (PC, serveurs, rseau), leur volution, et la production assure sur les ordinateurs du client ou sur ses moyens propres (plate-forme de traitement). Les services proposs sont les suivants :

Infogrance de systmes distribus,

Infogrance de production,

Infogrance de rseaux,

Infogrance de bout en bout,

Infogrance globale


1.1.3 Prsentation du NOC

Le NOC CS est le centre o sont administrs les rseaux des clients. Ce centre traite plusieurs contrats Education-Recherche tels que RENATER, GEANT ou 6NET mais aussi des contrats avec de grandes entreprises telles que Manpower, Kiabi ou Quick. Dans ces diffrents cas, CS propose une offre complte et modulaire de prestations de services lies la prise en charge, la conduite et lvolution des composants du Systme dInformation et la rnovation de leurs rseaux dans le cadre dun contrat dinfogrance globale.

SimonMast

1.2 Prsentation de RENATER

1.2.1 Le rseau RENATER

Le rseau Renater (Rseau National de Tlcommunications pour la Technologie, lEnseignement et la Recherche) a t cr dans les annes 1990 dans le but de fdrer et dorganiser les infrastructures de tlcommunications pour lEducation, la Recherche et lEnse gnement. Aujourdhui, plus de 600 sites sont raccords ce rseau. Ceci leur permet de commtablis internles dune pdvelo rseauloptimRenatdintelInterlpin

i MUYAL re SCR - 11 -

uniquer entre eux, daccder aux centres de recherche publique et prive ainsi quaux sements denseignement du monde entier via lInternet.

Le rseau Renater est compos d'une infrastructure mtropolitaine et des liaisons ationales haut dbit. Des points de prsence de Renater sont galement implants dans partements dOutre Mer. Renater est bas sur une architecture distribue : il comprend ine dorsale nationale haut dbit qui fdre des rseaux de collecte ( RdC) rgionaux pps avec le soutien des collectivits territoriales.

Renater est interconnect 2.5 Gbit/s aux autres rseaux de recherche europens via le europen GEANT. Dautre part, Renater contribue au dveloppement et isation de lInternet en France. Pour cela, le Groupement dIntrt Public (GIP)

er a cr le SFINX, un point dchange entre les oprateurs prsents en France. Le dbit rconnexion entre Renater et le SFINX est de 1 Gbit/s. Enfin, la communication avec net dans le reste du monde est assure par le raccordement de Renater 2.5 Gbit/s e dorsale Internet OpenTransit de France Tlcom.

Voici un schma dcrivant larchitecture globale du rseau RENATER3:


1.2.2 RENATER et IPv6

IPv6 est la nouvelle version du protocole IP de lInternet. Ce protocole a t conu pour saffranchir des limitations dIPv4 (pnurie dadresses IPv4, explosion des tables de routage), mais aussi pour prendre en compte les avances issues des recherches sur les rseaux, comme lauto configuration, la mobilit, le multicast ou encore la scurit. En Europe, les rseaux de la recherche sont trs actifs pour prparer et commencer cette migration, et proposer un service IPv6 pour les exprimentations des premiers utilisateurs. Renater est au premier plan de cette volution : dans Renater 3, le service IPv6 est disponible dans chaque point de prsence rgional de lpine dorsale. Tous les routeurs de Renater 3 sont dual stack (double pile IPv4 et IPv6). Depuis le 15 Avril 2003, la connexion de Renater avec GEANT transporte du trafic IPv6 en mode natif.

1.3 Prsentation du GIP RENATER

1.3.1 Historique

Cr en 1993, le GIP RENATER compte aujourdhui 7 organismes membres : Les ministres en charge de l'enseignement suprieur et de la recherche, le CNRS, le CEA, l'INRIA, le CNES, l'INRA et le CIRAD. Un GIP est un organisme but non lucratif, runissant des administrations de l'Etat et des organismes publics pour une activit dfinie : dans le cas du GIP Renater il s'agit de la matrise douvrage du rseau Renater.

1.3.2 Son mtier : Matrise d'ouvrage

Le GIP Renater est le matre d'ouvrage de la partie commune de Renater, constitue de son pine dorsale, des liaisons internationales, de ses actions pilotes, et du service SFINX. Il est le coordinateur du rseau pour l'ensemble des communauts acadmique et de recherche. Il reprsente le rseau Renater auprs des institutions franaises et trangres, et notamment auprs des autres rseaux de la recherche.


2. Etudes des besoins L'administration des rseaux se dcompose en un ensemble de tches, chacune ayant une fonction bien particulire. Afin de mieux dfinir les besoins, nous allons d'abord prsenter brivement l'ensemble de ces tches:

! Supervision - Monitoring: La supervision est essentielle la bonne administration dun rseau. Elle consiste vrifier qu'un ensemble d'quipements constituant un rseau (Routeurs, switchs, serveurs, PCs) fonctionne correctement. Elle permet donc de connatre tout moment la disponibilit du rseau. Un standard est utilis dans la quasi-totalit des rseaux pour raliser ceci. Il s'agit de SNMP (Simple Network Management Protocol) : Ce protocole permet de collecter diverses informations stockes dans les quipements du rseau dans des bases de donnes appeles MIB (Management Information Base). Les quipements sont aussi capables de faire remonter des alertes (traps) au collecteur SNMP via ce protocole.

! Mtrologie: La mtrologie fait partie de la supervision. Elle consiste

surveiller et analyser le trafic vhicul par les quipements rseaux. Elle permet donc dvaluer le type et la quantit de trafic dans le rseau. La mtrologie a pris ainsi une place importante dans le monde de ladministration des rseaux: Parmi les utilisateurs de ce service se trouvent les oprateurs qui lemploient entre autres pour suivre la consommation de leurs clients et vrifier quelle est conforme leur contrat (Accounting Billing). De mme, ils vrifient que leurs liens physiques natteignent pas la capacit limite. Grce aux fonctions de quelques outils, il est possible de faire du "reporting". De cette faon, il est plus facile de prvoir le dimensionnement du rseau lors de migrations.

! Scurit: De nos jours, il est indispensable d'avoir une politique de scurit

dans un rseau afin d'assurer principalement l'intgrit et la confidentialit des donnes. Pour cela, il faut mettre en place plusieurs niveaux de scurit. Premirement, il est ncessaire de scuriser laccs physique aux quipements rseaux (routeurs, switch) et aux serveurs (collecteurs, serveur dauthentification). Ensuite, afin de restreindre laccs aux utilisateurs non autoriss, des filtres sur les adresses IP et les ports (Access List, IPTables, ACL) ainsi que sur les services applicatifs (Certificats de scurit, PKI) sont mis en place. Finalement, linformation transmise sur le rseau doit tre crypte pour viter que des informations confidentielles comme les mots de passe circulent en clair. Actuellement la plus part des outils dadministration offrent ces fonctionnalits. Ainsi, ladministration peut se faire de manire sre et efficace.

! Topologie: La topologie permet de connatre travers l'laboration de

schmas l'architecture du rseau. Il est donc trs important de maintenir jour ces schmas pour avoir une vision correcte du rseau.


! Inventaire: L'inventaire permet de recenser l'ensemble des quipements qui

constitue un rseau. Il a aussi pour but de tenir jour la configuration de ces quipements. Si un inventaire nest pas fait, il se peut, par exemple, que certains quipements du rseau ne soient pas superviss. Cest pour cela quil est important de maintenir jour linventaire, en mme temps que le rseau volue.

Actuellement, il existe un ventail doutils permettant dadministrer des rseaux IPv4. Il est ncessaire de disposer galement d'un certain nombre d'instruments pour administrer les rseaux IPv6. Quelques outils existants en IPv4 sont dj disponibles en IPv6.

Le fait dadministrer des rseaux IPv6 ne signifie pas que les outils employs transportent linformation en IPv6. En effet, la majorit des quipements sur le rseau tant en Dual Stack (IPv4 IPv6), laccs aux quipements peut se faire en IPv4 pour rcuprer des informations sur la supervision IPv6. Cette solution est retenue trs souvent car certaines applications ne supportent pas encore le transport en IPv6. Cela permet aussi aux NOC nayant pas encore un plan dadressage de supervision en IPv6, dadministrer des rseaux aussi bien IPv4 qu IPv6. Gnralement, un pool dadresses est rserv pour ladministration des quipements. On peut diffrencier les interfaces ddies au trafic des interfaces de supervision. Ainsi, un plan dadressage est dfini et permet aux NOC daccder aux quipements. Cependant, un effort reste faire pour atteindre le mme niveau de supervision qu'en IPv4. Les rcentes normalisations ralises par les organismes comme lIETF ne sont pas encore mises en uvre par les constructeurs d'quipements ou les diteurs de logiciels de supervision. Par exemple, les MIB permettant de mesurer le trafic IPv6 sont pratiquement inexistantes chez des constructeurs comme Cisco.

2.1 Outils de supervision utiliss en IPv4

2.1.1 Au NOC (CS)

Afin de superviser de faon globale des rseaux comme RENATER, le NOC utilise des plate-formes de supervision telles que HP OpenView. Cette plate-forme intgre un ensemble doutils trs vaste (gnration de cartes rseaux, interrogation des quipements, alarmes). Cependant, ces plate-formes ne rpondent pas forcement des besoins prcis. Ainsi trs souvent, des programmes sont dvelopps pour automatiser des tches de supervision bien prcises. Par exemple, la configuration ou la mise jour des versions logicielles des routeurs peut se faire avec lutilisation de scripts. Ces scripts sont crits gnralement en Perl ou en Shell Unix. D'autre part, des outils de mtrologie sont employs au NOC RENATER. Celui qui est utilis principalement est MRTG. Il a le grand avantage de gnrer les graphes sur le web et dtre gratuit. Il se base sur des requtes SNMP collectant les informations de trafic sur lensemble des interfaces des quipements. De plus, sa configuration est simple : Dtection des interfaces actives sur un quipement lors de la gnration de la configuration, puis interrogation par polling SNMP sur lensemble de ces interfaces.


D'autres outils semblables tels qu'Infovista sont employs pour suivre le trafic de

rseaux tels que GANT. Cette application se base aussi sur des requtes SNMP pour collecter les informations sur le trafic. Infovista peut gnrer des rapports sur lensemble des quipements du rseau. Avec ces rapports, il est possible danalyser rapidement le trafic sur lensemble des liens pour une priode donne (semaine, moi, an). Cependant, il est ncessaire de configurer lensemble de ces quipements avec les mmes paramtres pour que les rapports gnrs soient cohrents. Les compteurs utiliss par Infovista sont cods sur 64 bits (au lieu de 32 bits), ce qui vite la remise zro rgulire, particulirement dans le cas des interfaces ayant un dbit lev. Cette application demande l'installation de plug-in afin de consulter les graphes sur le web.

2.1.2 Au GIP Renater

Bien que ladministration soit ralise par le NOC, le GIP Renater utilise aussi des outils de mtrologie. En effet, ces outils permettent principalement de vrifier si les dbits dfinis dans les contrats des diffrents sites sont respects. De plus, ils permettent de mieux dimensionner le rseau et de dtecter des problmes de scurit (Dni de services.). Deux applications ont t dveloppes au GIP ; la premire se base sur le protocole SNMP et la deuxime sur la fonctionnalit Netflow, propose dans les versions logicielles (IOS) des routeurs Cisco.

2.1.2.1 SNMP

Le premier outil de mtrologie se base sur un ensemble de programmes crits en C permettant de collecter les informations sur les MIB des routeurs de RENATER-3 via SNMP. Ces informations sont stockes dans une base de donnes Mysql et peuvent tre consultes via le web travers une interface ralise en PHP (consultable par le personnel du GIP). Les informations collectes sont les champs de la MIB (OID) correspondant au trafic et la charge CPU des routeurs.

Avec cet outil, le GIP est capable de connatre les sites qui dpassent le dbit autoris. En effet, dans le contrat dun site raccord RENATER-3, un dbit est spcifi et le site est tenu de le respecter.

Cet outil permet aussi de mieux dimensionner le rseau. Ainsi lors dune migration, il est possible dvaluer les liaisons qui se rapprochent de la saturation et qui doivent tre mises jour (cf. Annexe I). Il est possible aussi de dtecter ou confirmer des attaques de type Dni de Service (Denial of Service DoS). En effet, lors dune attaque de ce type, on peut observer soudainement un grand cart entre le trafic entrant et le trafic sortant sur lquipement (cf. Annexe II). Ceci ne permet pas daffirmer quil sagisse dun dni de service, mais permet de reprer une anomalie ou de confirmer une attaque de ce type.

2.1.2.2 Netflow

Le rseau RENATER-3 tant constitu dquipements Cisco, le deuxime outil employ au GIP se base sur la fonctionnalit Netflow que propose le constructeur sur ses quipements. Netflow permet de caractriser les flux de donnes et d'avoir des statistiques prcises sur le trafic.

SimonMast

Un flux est caractris par les adresses IP source et destination, les ports source et destination ainsi que le protocole, le type de service (Type of Service ToS) et lindex de linterface. Pour un flux donn, Netflow renvoie les informations suivantes : ! Les compteurs sur les paquets et les octets reus et envoys. ! Le temps de dbut et fin du flux. ! Le numro des interfaces dentre et sortie. ! Le protocole de transport employ (TCP ou UDP) !

collecdans donnweb

entre duneapplic

MUYAL re SCR - 16 -

Des informations sur le routage (Next-hop, AS source et destination, masque rseau source et destination).

Les routeurs envoient rgulirement les informations concernant les flux vers un teur Netflow. Un ensemble de scripts crits en C traite les informations et les stockent une base de donnes Mysql. Connaissant la plage dadresses attribue un site, les es peuvent tre agrges. Des histogrammes sur les flux peuvent tre consults sur le travers une interface PHP.

Voici le schma dcrivant larchitecture de loutil :

Avec cet outil, le GIP est capable de caractriser le trafic (FTP, Web, peer to peer) RENATER et les diffrents sites (cf. Annexe III). Ainsi, il est possible de voir la cause congestion, de dfinir une classe de service (Class of Service : CoS) pour un site ou une ation donne ou de reprer des serveurs warez.

Alarmes sur une(des) station(s)en temps-rel

BDMySQL

ServeurApache (+PHP4)

Trames Netflow(8Mb/s en journe,protocole UDP)

Programme rsident en C

Requtes SQL

SimonMast

2.2 Etat de lart des MIB IPv6

La croissance rapide des rseaux et la diversit des systmes pendant la dernire dcennie ont entran le besoin dune gestion globale des infrastructures rseaux. SNMP s'est avr tre une bonne solution propose et standardise par l'IETF (Internet Engineering Task Force). Ainsi, le protocole SNMP et les MIB sont devenus les deux lments principaux du modle de supervision de rseaux.

vers IPprotocOpenSpremitaienen IPvpas unne vtransp

du proa t mprinci

RFC 1tre rebits, 1dans l

premijour. P MUYAL re SCR - 17 -

Le protocole SNMP tant indpendant de l'architecture du protocole IP, son volution v6 na pas reprsent un problme majeur. La premire implantation de SNMP pour le

ole IPv6 a t ralise par lquipe du Loria de l'universit de Nancy (NET-SNMP ource) et a t disponible dans la version 5.0.3 de net-snmp, en mai 2002. Avant cette

re version, ladministration des rseaux IPv6 tait possible du fait que les quipements t Dual Stack IPv4-IPv6. En effet, il tait possible d'accder en SNMP sur un quipement 4 et de rcuprer des champs de la MIB concernant IPv6. Ainsi, jusqu'ici, il n'y avait grand besoin davoir une version de SNMP IPv6. Aujourdhui, certains rseaux projets

hiculent que du trafic IPv6 do la ncessit de disposer dune version IPv6 pour le ort du protocole SNMP.

Par contre, l'volution des MIB est plus complexe. Depuis les spcifications initiales

tocole IPv6, en 1995, la dfinition de la MIB-2 pour ladministration des rseaux IPv6 odifie deux occasions : la premire en 1998 et la deuxime en 2000. Le problme

pal tait de dfinir le type du champ "IP ADDRESS". Voici son volution dans les dernires annes :

En 1996, une premire reprsentation du champ "IP ADDRESS" est dcrite dans la

902 o la longueur rserve pour ce champ est de 4 octets. Avec ce champ ne peuvent prsentes que les adresses IPv4. En effet, les adresses IPv6 ayant une longueur de 128 6 octets sont ncessaires pour les reprsenter. C'est pourquoi, en 1998, nous trouvons a RFC 2465, la dfinition du champ "Ipv6Address" sur 16 octets.

Ainsi de nombreuses RFCs ont t affectes par ces modifications. Dabord, avec la

re approche de crer des MIB IPv4 et IPv6 indpendantes, de nouvelles RFC ont vu le rincipalement, les RFCs dcrivant les MIB IPv6 sur transport TCP ou UDP (RFC 2452


et RFC 2454) ont t publies en 1998. De mme, une MIB concernant le protocole ICMPv6 a t dcrite dans la RFC 2466.

Cependant, cette approche implique une gestion indpendante des protocoles IPv4 et

IPv6. Ainsi, l'IETF a dcid de dfinir une MIB-2 unifie, permettant de superviser les rseaux IPv4 et IPv6 (RFC 2851 Juin 2000). Cette RFC dfinit le champ "IP ADDRESS" comme une structure avec deux champs. Le premier champ permet de diffrencier le type dadresses (IPv4 ou IPv6). Le deuxime champ est une chane de caractres longueur variable. Ainsi, ce champ peut contenir des valeurs de longueur gale 4 ou 16 octets (IPv4 ou IPv6).

Afin damliorer la description de la RFC 2851 est apparue en mai 2002 la RFC 3291. Des informations supplmentaires sont dcrites comme le prfixe rseau, le numro de port utilis par la couche transport ou le numro dAS (Autonomus System) correspondant ladresse IPv4 ou IPv6. Ainsi la RFC 2851 devient obsolte.

Ensuite, la volont davoir une MIB unifie a entran aussi la mise jour de MIB dj existantes. Actuellement, lIETF publie des propositions (drafts) de mise jour pour les RFCs 2011, 2012, 2013 et 2096. Les dernires propositions publies sont draft-ietf-ipv6-rfc2011-update-03.txt (juillet 2003), draft-ietf-ipv6-rfc2012-update-03.txt (juin 2003), draft-ietf-ipv6-rfc2013-update-03.txt (avril 2003), draft-ietf-ipv6-rfc2096-update-04.txt (juin 2003). Ces drafts concernent respectivement les MIB IP, TCP, UDP et IP Forwarding table.

En raison de toutes ces modifications, les MIB ne sont pas entirement disponibles aujourdhui en IPv6. En effet, trs peu de ralisations ont t effectues par les constructeurs.

Juniper a ralis un premier effort en implmentant une MIB propritaire sur ses routeurs en se basant sur la RFC 2465. Cette MIB permet de faire de la mtrologie sur le nombre de paquets entrants et sortants. Par contre, elle ne permet pas de rcuprer le nombre doctets mis et reus.

Cisco a implment sur ses quipements une MIB propritaire (CISCO-IETF-IP-MIB). Cette MIB permet de rcuprer un certain nombre dinformations IPv6 de base (interfaces, messages ICMP : cf. Annexe IV). Par contre, malgr les demandes de plusieurs clients, Cisco na pas encore implant une MIB permettant de diffrencier le trafic sur les interfaces transportant les deux versions IP le trafic IPv6. Cisco annonce une MIB permettant davoir des compteurs sur le trafic IPv6 prochainement.

Une autre consquence est que les grandes plate-formes de supervision comme Tivoli

ou InfoVista ne sont pas disponibles en IPv6; HP OpenView propose une version IPv6 en beta-test.


2.3 Les outils existants en IPv6

Pour chaque tche de ladministration des rseaux vue prcdemment, il existe un ensemble doutils IPv6. Voici une liste des quelques outils IPv6 les plus employs aujourd'hui: ! ASPath-Tree:

Bas sur des captures rgulires de la table BGP IPv6, ASpath-tree gnre automatiquement un ensemble de pages HTML fournissant une vue graphique des chemins pour atteindre les autres AS sous forme darbre (Annexe V). A la base conu pour tre employ par des sites IPv6 impliqus dans l'exprimentation du protocole BGP l'intrieur du 6Bone, il peut tre aujourd'hui utilis dans n'importe quel rseau IPv6 oprationnel qui utilise BGP comme protocole de routage. En plus, il permet la dtection des entres anormales de routes annonces par BGP (les prfixes interdits ou non agrgs), des numros d'AS errons (rservs ou privs) et fournit un ensemble d'information complmentaire comme:

le nombre de routes (valid/total/suppressed/damped/history) le nombre d'AS dans la table (total, originating only, originating/transit, transit only,

private and reserved) le nombre de voisins actifs BGP (c.--d. annonant des routes) une analyse de la taille de rseau, en termes de distance inter-AS le nombre de prfixes circulant dans le rseau (total, 6Bone pTLAs, sTLAs, 6to4,

autres).

Lavantage dASPath-Tree est quil permet de connatre rapidement les chemins emprunts par les paquets pour atteindre un AS en se basant sur un routeur du rseau uniquement. Ceci simplifie beaucoup la mise en place de loutil. Cependant, ceci peut aussi prsenter un inconvnient. Normalement, nous devrions avoir un mme arbre quel que soit le routeur interrog au sein du rseau. Or, si un problme de configuration est fait (voisin mal dclar ), larbre ne sera plus le mme selon le routeur interrog.

ASPath-tree facilite donc la mise en place dune politique de routage au niveau dun backbone.

Loutil est disponible sur http://carmen.ipv6.tilab.com/ipv6/tools/ASpath-tree/

! Looking Glass :

Cet outil permet, travers une interface WEB, davoir un accs direct sur les routeurs ou switchs. Lutilisateur dispose dune liste de commandes qui peuvent tre excutes. Des scripts CGI permettant la connexion telnet ou SSH (en IPv4 ou IPv6) rcuprent linformation dsire et laffichent sur une page WEB. Son grand avantage est quil permet dobtenir des informations directement sur des quipements rseaux en temps rel sans avoir un compte ddi sur ces quipements. Cependant, le fait de donner des informations sur les quipements rseaux oblige mettre en place un certain nombre de mesures de scurit pour prserver la confidentialit des informations (accs restreint au serveur web).


! MRTG:

MRTG permet de gnrer des graphes sur le trafic rseau. Une version IPv6 de MRTG a t dveloppe par luniversit de Rome-3. Elle permet dinterroger les quipements via SNMP sur un transport IPv6. Dautres outils comme RRDtool, disponible en IPv6 permettent de faire de la mtrologie. Loutil est disponible sur http://www.uniroma3.6net.garr.it/mrtg

! Weather map :

Cet outil permet de prsenter une carte topologique du rseau avec son trafic actuel. Il se base gnralement sur des applications comme MRTG pour pouvoir afficher les graphes de trafic entre deux liens du rseau. Si nous voulons avoir un weather map reprsentant le trafic IPv6 uniquement, il est ncessaire que les MIB des routeurs distinguent bien le trafic IPv4 et IPv6. Or, actuellement, tous les constructeurs ne proposent pas cela. Des rseaux projets o le trafic est exclusivement IPv6, comme 6NET, peuvent disposer de cartes affichant la charge de trafic IPv6. En ce qui concerne le transport, il peut tre ralis entirement en IPv6. ! Ethereal :

Ethereal est un analyseur rseau. Il permet danalyser le trafic en temps rel en distinguant le trafic IPv4 et IPv6 sur une interface. Loutil est disponible sur http://www.ethereal.com ! Mping :

Mping (Multipoint ping) est un outil qui se base sur les fonctionnalits de ping6. Il permet de tester la connectivit entre plusieurs interfaces IPv6 et peut raliser des mesures de performances entre elles. Il ralise une collecte de donnes qui lui permet de gnrer des rapports et des histogrammes. Cet outil reste pratique tant que la taille du rseau nest pas trs importante. Lorsque le rseau grandit, le nombre de requtes est multipli. Ainsi, le trafic ICMP gnr est de plus en plus important, ce qui peut faire augmenter la CPU des quipements rseaux. ! Multicast beacon :

Multicast beacon est une application client/serveur donnant des matrices de mesures sur le trafic Multicast en IPv4 et IPv6. Chaque client possde un dmon beacon. Le dmon envoie un message priodiquement aux autres membres du groupe multicast pour mesurer les pertes, le dlai, la gigue, les doublons et le mauvais squencement des paquets. Ces informations sont envoyes au serveur beacon qui peut afficher ces informations dans une table. Cette application est ralise en java.


3. Travaux raliss

3.1 Mise en place d'un looking Glass

3.1.1 Problmatique

L'objectif principal est de mettre en place un outil permettant aux administrateurs de la communaut Renater d'accder rapidement quelques commandes sur les routeurs du backbone RENATER 3. En effet, cela doit permettre aux sites connects en IPv6 RENATER 3 de consulter des donnes qui les concernent sans intervention de la part du GIP ou du NOC et sans avoir se connecter aux quipements directement. Les oprations pouvant tre effectues sur les quipements rseaux sont principalement des tests de connectivit (ping) ou des consultations sur ltat du routage BGP en IPv6. Il est possible aussi dobtenir des informations sur les interfaces et le trafic (cf. Annexe VI). Ainsi, lorsqu'un site ou un rseau rgional est confront un problme, il peut d'abord vrifier si la cause provient rellement de RENATER. Ceci reprsente un gain de temps pour les experts et techniciens du NOC RENATER qui interviennent uniquement en cas de problme tant de leur ressort. Cet outil peut tre employ de mme par les personnes du GIP n'ayant pas accs aux routeurs directement. En effet, pour des raisons d'administration du rseau, un nombre restreint d'ordinateurs du GIP Renater est autoris accder directement aux routeurs. Pour la mise en place de cet outil, plusieurs problmes se posent. Le premier est la scurisation de la connexion entre le serveur WEB o se trouvent les scripts CGI et les routeurs. En effet, un looking glass avait t mis en place dans un rseau de test au NOC RENATER, mais la connexion aux routeurs se faisait en telnet. Ceci posait des problmes de scurit puisque le mot de passe d'accs au routeur ainsi que les donnes transfres taient non cryptes dans le rseau. Pour pallier ce problme la connexion aux routeurs se fait en SSH (Secure Shell).

SSH dfinit un protocole entre un client et un serveur pour l'tablissement d'une connexion distante chiffre. SSH remplace les r-commandes (rlogin, rsh) prsentant des carences au niveau scurit. Avec SSH, une connexion est toujours initialise par le client. Le serveur est en coute sur le port 22 (par dfaut, mais il est possible d'utiliser un port). L'authentification et les changes de cls se basent sur les mcanismes de cls publiques et cls prives de type RSA (Rivest, Shamir, Adleman). Le chiffrement des communications se fait avec les algorithmes de chiffrement ayant des longueurs de cls diffrentes : DES (56 bits ), IDEA (128 bits ), 3DES (168 bits ), RC4 (128 bits), Blowfish (256 bits). Ces algorithmes sont appels ciphers. Avec SSH, il est donc possible dassurer la confidentialit lors de transfert de donnes entre les quipements rseaux de Renater-3 et le looking glass.


Un autre problme qui se pose est le nombre de connexions SSH sur les routeurs. En effet, chaque requte effectue sur l'interface web, une connexion SSH sur le routeur se produit, ce qui fait augmenter la charge de la CPU (Central Processing Unit) de celui-ci. Si un ensemble de sites se connecte simultanment sur un routeur de concentration, la CPU risque d'augmenter, ce qui diminuerait les performances du routeur. Bien que le trafic IP soit pris en charge par les processeurs des cartes des routeurs, dautres services traits par le processeur du routeur (accs SSH, SNMP, mise jour des tables de routage) risquent dtre perturbs.

Ceci peut tre plus grave si un pirate envoie une multitude de requtes sur le serveur web. En effet, cela produirait un dni de service sur le routeur. Afin d'viter ce type de problmes, le nombre de connexions au serveur web est limit et un mot de passe est demand pour accder au looking glass.

3.1.2 Solution Mise en place de loutil:

Le serveur hbergeant le looking glass est un serveur Sun Solaris se trouvant au NOC RENATER. Ce serveur n'ayant pas encore migr vers IPv6 (Dual Stack IPv4 IPv6), la connexion au serveur WEB ainsi que la connexion SSH entre le serveur et les routeurs se fait pour l'instant en IPv4. Cependant, l'outil a t test sur un serveur ayant une pile IPv6 et fonctionne correctement.

Le langage utilis pour dvelopper cette application est perl. Ce langage dispose dun

module permettant deffectuer des commandes en SSH. De plus, cest un langage qui est bien adapt pour la gnration de CGI et permet de traiter avec facilit les chanes et expressions. Il est vrai que perl, tant un langage interprt, noffre pas des performances aussi leves que des langages compils tel que le C ou C++, mais il est tout fait adapt nos besoins. Le serveur WEB utilis est un serveur apache2 supportant la pile IPv6. Ainsi lorsque le serveur Sun Solaris aura migr, les utilisateurs pourront accder au serveur WEB en IPv6.

Un serveur TACACS+ permet de faire lauthentification ainsi que lautorisation lors de la connexion aux routeurs partir du looking glass.

Principe du serveur TACACS+ : Lauthentification correspond lidentification de lutilisateur. Cette identification

passe par la prsentation de lidentit de lutilisateur. TACACS+ peut aussi bien utiliser des techniques dauthentification classiques type login/mot de passe statique ou bien des procds plus volus base de challenge avec authentification rciproque. Nous utiliserons dans notre cas une authentification de type login/mot de passe o les informations seront cryptes.

Lors dune nouvelle connexion, le routeur met un message START au serveur TACACS+ dcrivant le type dauthentification utiliser. En retour, le dmon envoie un message REPLY. Ce type de message peut indiquer ou bien que lauthentification est termine, ou bien quelle doit continuer, auquel cas, le client rcupre linformation manquante et la retourne dans un message CONTINUE.


Le type de requte provenant du serveur peut tre une demande GETDATA,

GETUSER ou GETPASS. GETDATA est une requte gnrique de rcupration dinformation du profil utilisateur. Lautorisation permet de dterminer quels sont les droits de lutilisateur. Par exemple, aprs stre logu, lutilisateur peut essayer dutiliser certaines commandes. Lautorisation dtermine alors si lutilisateur peut ou non les utiliser. Lors dun accs un service particulier, le routeur ouvre une session dautorisation. Cette session consiste juste en lchange dune paire de messages : REQUEST/RESPONSE. La requte dcrit lauthentification pour lutilisateur ou le processus qui demande laccs au service. La rponse du serveur contient un ensemble dattributs pouvant restreindre ou modifier les actions du client, plutt quune simple rponse affirmative de type oui/non. Cest ainsi quil sera possible de limiter les commandes excuter avec le compte du looking glass. Installation et fonctionnement de loutil :

La version 5.X de perl est dj installe sur le serveur web. Un ensemble de modules perl a t install afin de pouvoir se connecter en SSH sur les quipements du backbone (cf. Annexe VII). Puisque le module NET::SSH::Perl permet de se connecter uniquement en IPv4, le module IO::Socket6 a t install et la librairie Perl.pm a t modifie afin de pouvoir effectuer des connexions SSH en IPv6 (cf. Annexe VIII).

Pour le serveur Tacacs+, un compte pour le looking glass a t cr ; il nautorise que

les commandes disponibles sur linterface web. Ainsi, si un pirate russissait accder au serveur et se connecter aux routeurs, il ne pourra effectuer que des commandes restreintes. Il ne pourra en aucun cas lire la configuration du routeur ni effectuer des modifications.

Les routeurs tant dj configurs pour interroger le serveur tacacs+, il nest pas ncessaire de modifier la configuration des routeurs (configuration : cf. Annexe IX).

Voici un schma dtaillant l'architecture globale de l'outil et son fonctionnement:


Tout d'abord un utilisateur (Site client, GIP ou NOC Renater) accde travers son

navigateur Web au serveur o se trouve le looking glass (1). Lutilisateur doit indiquer (cf. AnnexeX):

! Lquipement sur lequel il veut se connecter (liste droulante) ! La commande quil veut effectuer sur cet quipement.

La liste des quipements est gnre partir dun fichier de configuration contenant

les quipements du backbone ainsi que leurs caractristiques (cf. Annexe XI). Une fois les choix effectus, un script en perl effectue une connexion SSH vers lquipement choisi (2). Ce script rcupre les paramtres de connexion sur le mme fichier de configuration. Pour des raisons de scurit, il ne mest pas possible de dire la version de SSH ainsi que le cipher utilis pour la connexion aux quipements de RENATER 3. Ensuite le routeur interroge le serveur tacacs+ afin de vrifier la validit du mot de passe et de connatre les droits et les commandes que peut effectuer l'utilisateur connect au routeur (3 et 4). Une fois, l'identification ralise, le routeur excute la commande et renvoie le rsultat au serveur (5 et 6). Finalement, le script gnre une page HTML avec le rsultat de la commande et le serveur Web envoie cette page son tour l'utilisateur (7). Remarques :

Les scripts CGI prsentent des failles de scurit permettant des utilisateurs dexcuter des commandes sur le serveur ou se trouvent ces scripts. Afin de se prserver de ce genre dattaques, le code source a t analys par le CERT Renater. Le CERT Renater est la structure qui gre les incidents de scurit qui lui sont rapports.

SimonMast

3.2 Inventaire des quipements de RENATER-3 :

3.2.1 Contexte

Lorsquun nouveau site fait une demande de raccordement en IPv6 sur RENATER-3, il est ncessaire dans certains cas d'avoir une interface disponible sur l'un des quipements du Nud Renater (NR) sur lequel il va tre connect. Gnralement, un NR est compos d'un routeu Cisco 12400 et d'un switch Cisco ATM 8540. Sur certains NR, un deuxime routeur est prsont conneCiscorseautrafic Cest NR.

aujourdans l

est corouts

iBGP

dvelodu tratabli,routeu

r MUYAL re SCR - 25 -

sent pour pouvoir tablir des tunnels avec les sites. Les tunnels permettent aux sites qui raccords un rseau mtropolitain (MAN) ou rseau rgional nayant pas de ctivit IPv6 dtre connects Renater en IPv6. Les GSR (Giga Switch Router) de tant des quipements de backbone, la fonctionnalit de tunnel nest pas utilise dans le Renater-3. En effet, ces quipements sont destins transporter de grandes quantits de et la mise en place de tunnels pourrait entraner des surcharges sur la CPU des GSR. pour cela que des routeurs daccs ( Cisco 7200 ou 3600 ) sont installs dans certains

Pour savoir si des interfaces sont disponibles, il n'existe pas un autre moyen d'hui que de ce connecter directement sur les quipements. Or, comme nous avons vu a partie prcdente, l'accs aux quipements est limit quelques personnes.

Une fois que l'interconnexion physique avec le nouveau site est faite, un peering BGP

nfigur entre le routeur de Renater et le routeur du site afin que les paquets puissent tre .

Deux protocoles assurent le bon fonctionnement de BGP : eBGP(external BGP) et (internal BGP). Le protocole eBGP est un protocole de routage inter-systme autonome (AS). Il a t

pp pour remplacer Exterior Gateway Protocol (EGP). Pour qu'un AS puisse changer fic avec un autre AS, il est ncessaire d'avoir un accord mutuel. Une fois cet accord un peering est configur entre deux routeurs des diffrents systmes autonomes. Le r avec lequel le peering est tabli est appel neighbor BGP(voisin).

SimonMast

Le protocole iBGP permet aux routeurs appartenant un mme AS, de propager lintrieur dun AS les informations reus par eBGP:

donn

du rs

une inbackbaux rosuivi l

Ceci emais d

du GISSO RENA MUYAL re SCR - 26 -

Les changes BGP se font sur des connexions TCP afin de rendre fiable le transfert des es.

3.2.2 Objectifs

L'objectif principal tait de raliser une application permettant de dcrire la topologie eau Renater-3. Elle permet de faire:

! L'inventaire des interfaces disponibles sur les quipements du backbone ! L'inventaire des peerings BGP.

Ainsi, il est possible davoir rapidement une vue sur larchitecture dun NR, savoir si terface est libre ou connatre les peerings IPv6 configurs sur un quipement du

one. Ceci reprsente un gain de temps, puisquil nest pas ncessaire de se connecter uteurs pour obtenir ces informations. Cet outil permet donc l'quipe IPv6 de faire un orsqu'un site fait une demande de raccordement en IPv6. Cette application peut tre aussi utilise par le SSO pour consulter ltat des interfaces. La rcupration des informations sur les routeurs se fait deux fois dans la journe.

st suffisant car il n'est pas question ici de surveiller l'tat des peerings ou des interfaces 'avoir une vision sur l'architecture d'un nud Renater. Cette application est consultable travers une interface web, pour que les utilisateurs

P puissent y accder facilement. Les utilisateurs peuvent tre l'quipe IPv6 mais aussi le (Service de Suivi Oprationnel). Afin d'viter que des personnes extrieures TER accdent cette application, des rgles de scurit sont mises en place.


3.2.3 Prsentation de l'application

Pour raliser cette application, il est ncessaire de rcuprer sur les quipements du backbone l'ensemble des interfaces ainsi que les peering BGP. Avant de commencer le dveloppement de l'application, une tude sur les applications existantes au GIP a t faite; cela a permis de profiter d'outils dj prsents et viter de refaire des choses existantes.

3.2.3.1Utilisation de la base de donnes de mtrologie

L'outil de mtrologie prsent au paragraphe 2.1.2.1 rcupre via SNMP les interfaces des quipements pour connatre le trafic par interface. Ces informations sont stockes dans une base de donnes MySql. Nous utilisons donc cette base de donnes ce qui vite davoir plusieurs systmes dinformation. Ainsi, nous liminons le risque d'avoir des divergences dans diffrentes bases de donnes. Les informations utilises pour la supervision se trouvent un seul endroit mais peuvent tre utilises par plusieurs outils. L'utilisation de la mme base permet aussi d'conomiser des ressources (espace disque, mmoire). Le choix de MySQL comme base de donnes se justifie par plusieurs critres. Ce logiciel prsente les avantages d'tre gratuit et facile interfacer avec le web (scripts CGI perl ou php). Ici, MySql est suffisant car la taille de la base de donnes nest pas trs importante. Dans notre cas, il n'tait pas ncessaire dutiliser des bases de donnes payantes comme Oracle ou SQL Server qui offrent plus de fonctionnalits. Pour l'outil dj existant, un programme rcupre un ensemble de champs sur les MIB correspondant aux interfaces. Pour notre application, des champs de la MIB ont t ajouts la base de donnes afin de rpondre aux besoins de l'outil. Voici lensemble des champs de la MIB-2 rcuprs par lapplication: interfaces.ifTable.ifEntry.ifIndex : Numro identifiant l'interface sur l'quipement interfaces.ifTable.ifEntry.ifType: Type d'interface (ATM, POS, Ethernet) interfaces.ifTable.ifEntry.ifDescr: Nom de l'interface. Ex: "ATM1/1" ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifAlias: Description de l'interface. Ex: "Lien vers Bordeaux".

interfaces.ifTable.ifEntry.ifAdminStatus: Etat de l'interface (1:UP, 2:DOWN) (champ ajout) Ces champs sont rcuprs l'aide des commandes snmpget et snmpwalk qui permettent d'interroger les MIB.

3.2.3.2 Choix du langage CGI

Pour la gnration dynamique des pages html, plusieurs langages peuvent tre utiliss. Les plus rpandus sont Perl et PHP pour ce type d'application (interaction avec une base de donnes). Les deux langages prsentent l'avantage d'tre gratuit. Perl est pratique pour traiter des chanes ou des textes, ce qui n'est pas le cas ici. Le langage utilis pour l'interface web est donc PHP.


3.2.3.3 Interrogation des quipements

La collecte des informations concernant les interfaces se fait par polling SNMP comme nous l'avons vu prcdemment. Pour la collecte des peerings BGP IPv6, la premire ide tait d'utiliser aussi le protocole SNMP et la MIB BGP-4 (RFC 1657). Cependant, cette MIB ne permet pas de rcuprer les peerings BGP IPv6 (uniquement les neighbors IPv4). La solution choisie est de se connecter directement sur les routeurs et d'effectuer la commande qui permette de rcuprer les peerings BGP. L'ensemble des routeurs tant des Cisco, la commande effectue sera "show bgp ipv6 neighbor". Comme pour le looking glass, SSH est utilis pour la connexion aux routeurs ce qui permet de scuriser les changes de donnes. De mme, un compte Tacacs permet de faire l'authentification et l'autorisation. Le serveur utilis pour faire de la collecte SNMP n'est pas autoris ce connecter en SSH sur les routeurs de Renater-3. Les machines prsentes au GIP tant autorises ce connecter en SSH sont des PC de travail et non pas des serveurs ddis la supervision. C'est pour cela que l'interrogation se fera partir d'un serveur du NOC Renater dj autoris accder en SSH aux routeurs de Renater-3. Gnralement, une connexion SSH nest pas utilise pour collecter rgulirement des informations sur des routeurs (augmentation de la charge CPU). Dans notre cas, cette solution est envisageable car la connexion SSH se fait uniquement deux fois par jour. En effet, le but de lapplication est de donner une vision du rseau et non pas le superviser. Il ne serait pas envisageable de se connecter en SSH sur lensemble des routeurs du backbone avec une frquence de deux minutes pour rcuprer les peering IPv6.

3.2.3.4 Structure de la base de donnes

Toutes les informations rcupres sur les quipements sont stockes dans la base de donnes MySql employe aussi pour la mtrologie. La structure de la base de donnes a t adapte pour cette application. Deux champs ont t ajouts la table "interfaces" afin de pouvoir dterminer la disponibilit et la date depuis laquelle les interfaces sont Up ou Down. Dautre part, deux tables ont t cres (peering, AS) pour stocker les informations concernant les peering. La table quipement na pas t modifie.

Voici la structure de la base de donnes avec les modifications ralises:


La table peering contient les informations principales concernant les peerings (adresse IPv6 de lextrmit, description, tat, le numro dAS). La table AS contient le numro dAS et le nom de lAS.

3.2.3.5 Architecture de l'application

Voici un schma dcrivant l'architecture de l'application: Consultation WEB: L'utilisateur accde travers l'interface web l'application et effectue son choix (1). Alors le serveur web interroge travers des pages PHP la base de donnes MySql qui renvoie les informations au serveur web (2,3). Le serveur web est une distribution Linux Debian avec un serveur WEB apache 2.0 et la version 4 de PHP. Finalement, la page html est gnre puis envoye l'utilisateur (4). Collecte SNMP: Des scripts crits en C interrogent rgulirement les quipements du backbone en utilisant le protocole SNMP (1' et 2') pour rcuprer entre autres des informations sur les interfaces. Un autre script stocke ces informations dans la base de donnes MySql (3').


Collecte SSH: Des scripts crits en perl permettent de se connecter aux routeurs et rcuprer les peerings BGP IPv6 (1''). Ensuite, ceci est stock dans la base de donnes (2''). Un module perl permettant d'interagir avec les bases de donnes ainsi que les dpendances ont t installes. Les modules perl permettant de se connecter en SSH ont t aussi installs sur ce serveur.

Remarque : Le nom de lAS nest pas prsent parmi les informations rcupres sur le routeur. Afin de complter la table AS, la base RIPE est consulte travers la commande "whois". RIPE (Rseaux IP Europens) Network Coordination Centre (NCC) est lun des quatre organismes dans le monde qui fournit des services dattribution et enregistrement en accord avec lInternet mondial. Quotidiennement, un script en perl interroge la base RIPE pour rcuprer les noms dAS manquants dans la table AS. Afin que les noms dAS soient mis jour, une interrogation de la base RIPE est faite une fois par mois pour tous les numros dAS prsents dans la table AS.

3.2.3.6 Utilisation de l'outil Lutilisateur dispose dune carte de France o est reprsent l'ensemble des NR ainsi que les liens physiques. Cette carte est "cliquable" ce qui permet d'accder rapidement aux informations sur un NR.


En cliquant sur un NR, l'utilisateur peut alors visualiser soit un schma avec les interfaces, soit les peerings BGP. L'application permet de choisir parmi les quipements constituant le NR. Interfaces des quipements:

! Les routeurs: Afin de rendre plus lisible l'ensemble du schma, l'affichage se fait par type d'interface.

Une image au format PNG (Portable Network Graphic) est gnre par type d'interface. Pour ceci, un module php a t install sur le serveur WEB. Nous pouvons remarquer que les interfaces libres sont immdiatement aperues et que des couleurs permettent de distinguer le type de lien. Les interfaces qui sont prcdes d'une toile rouge sont down.


! Les switchs: Ils ont un seul type d'interface ce qui simplifie la prsentation. Uniquement sont diffrencies les interfaces libres des interfaces utilises:

Peering des quipements: Les peerings sont diviss en deux groupes: les peerings iBGP et eBGP:


Il est possible de voir l'tat du peering ainsi qu'un ensemble d'information (adresse IPv6 du voisin, temps depuis lequel le peering est Up ou Down) en cliquant sur le descripteur du peering.

Cas particulier du NRI de Paris (Nud Renater-3 International):

Nous avons vu que les NR taient constitus gnralement de deux ou trois quipements. Cela rend facile la comprhension de l'architecture lorsqu'un schma est gnr automatiquement. Vu le nombre dquipements qui constitue le NRI de Paris, un schma gnr serait plus difficile analyser, surtout si l'utilisateur ne connat pas exactement l'architecture. Pour cette raison, un schma a t fait dtaillant les liens physiques.

L'utilisateur peut cliquer sur l'un des quipements afin de voir le dtail des interfaces ou des peerings comme prcdemment pour un NR. Bien qu'il soit pratique d'avoir des cartes de ce type, elles prsentent un grand inconvnient: la mise jour. En effet, des modifications sont effectues frquemment, ce qui oblige de maintenir les cartes jour afin d'avoir une vision correcte de l'architecture. Ceci demande un temps considrable alors que la gnration automatique n'exige pas un suivi.


3.3 Conclusion

La ralisation de ces deux applications ma permis de travailler dans des environnements techniques diffrents. Jai utilis diffrents systmes dexploitation et divers langages de programmation selon les besoins. Le fait de travailler avec diffrentes quipes ma permis de voir que des amliorations pouvaient tre apportes aux applications.

4. Evolutions possibles

4.1 Evolutions court terme

Concernant l'application permettant de faire l'inventaire des interfaces ainsi que celui des peerings, des volutions peuvent tre apportes. En effet, nous avons vu pour le NRI de Paris que l'entretien des cartes demandait beaucoup de temps. Il a donc t envisag de gnraliser l'outil pour le NRI de Paris. Il est vrai que l'on perd de la visibilit sur l'architecture car il est difficile de voir rapidement les interconnexions entre chaque quipement. Cependant cet outil est destin des utilisateurs connaissant globalement larchitecture de Renater. Il est donc prfrable de faire un outil gnrique qui peut voluer au cours du temps sans avoir faire de mise jour importante. Une raison supplmentaire pour gnraliser loutil lensemble des NRI, est la migration prvue sur lIle de France. En effet, larchitecture ATM va tre remplace par une architecture reposant sur la technologie GigaEthernet. Avec cet outil, un suivi pourra tre fait tout au long de la migration. En ce qui concerne les peerings BGP, des complments peuvent tre apports. Lorsque des problmes de routage sont prsents dans le rseau, il est souvent ncessaire de connatre les routes reues (received routes) ainsi que les routes annonces (advertised routes) sur un peering. Pour cela, il faudra faire une capture de la table de routage ce qui en IPv6 est concevable (500 routes sur les routeurs du backbone). En IPv4 cela n'aurait pas t envisageable puisque les routeurs du backbone ont environ 120 000 routes. Il est vrai que le rseau IPv4 mondial est beaucoup plus important que le rseau IPv6, mais nous voyons dj ici l'intrt de l'agrgation dans l'adressage en IPv6 (tables de routages beaucoup plus petites).

4.2 Evolutions moyen et long termes

L'absence de MIB permettant de connatre les peering BGP IPv6, empche de faire une interrogation rgulire en SNMP sur les quipements. Nous pouvons envisager, lorsque les constructeurs implmenteront sur ses quipements ces MIB, de superviser les peerings BGP IPv6. Lorsqu'une perte de la session TCP du peering se produit, le client appelle pour signaler le problme. Afin dtre proactif et anticiper la plainte du client, un systme dalarmes pourrait tre mis en place permettant denvoyer des messages au NOC ainsi quau SSO si une anomalie se produit.


5. Conclusion

Pendant le droulement de mon stage, j'ai eu l'opportunit de travailler sur diffrents

aspects avec deux quipes diffrentes. Le travail ralis s'est avr trs enrichissant pour mon exprience professionnelle aussi bien en ce qui concerne le domaine technique que laspect humain. Le fait de travailler avec deux entits diffrentes (GIP et NOC Renater) m'a permis d'avoir une vision dtaille de la supervision et de la gestion de rseaux.

En effet, la premire partie du stage au NOC RENATER, m'a permis de savoir comment un rseau comme RENATER tait opr par un groupe d'expert.

Pendant la deuxime partie du stage au GIP RENATER, j'ai dcouvert comment tait assure la matrise d'ouvrage du rseau RENATER. Dans les travaux raliss, j'ai pu apporter mes connaissances thoriques et approfondir certains domaines que je ne connaissais pas encore; jai pu dcouvrir un ensemble doutils employs dans ladministration de rseaux. Jai pu aussi me familiariser avec le matriel constructeur quutilise RENATER pour constituer son backbone.

Le fait de travailler en quipe et utiliser des applications existantes m'a permis de

m'intgrer dans un groupe de travail et de voir en quoi consistait le travail d'ingnieur au sein d'une structure comme RENATER.


6. Glossaire

AS : Autonomous System ATM : Asynchronous Transfer Mode BdC : Boucle des Contenus BGP : Border Gateway Protocol CoS: Class of Service GIP : Groupement dIntrt Public ICMP : Internet Control Message Protocol IETF : Internet Engineering Task Force MIB : Management Information Base MRTG : Multi Router Traffic Grapher NOC : Network Operations Center NR: Nud Renater NRI : Nud Renater International PKI : Public Key Infrastructure RdC : Rseau de Collecte RIPE : Rseaux IP Europens SNMP : Simple Network Management Protocol SSH : Secure Shell TCP : Transmission Control Protocol ToS: Type of Service UDP: User Datagram Protocol


7. Rfrences bibliographiques

Rfrences Internes CS et au GIP RENATER: http://sem2.renater.fr : Site web technique IPv6 de RENATER Adresses Web:

http://www.renater.fr http://tools.6net.net http://www.sunfreeware.com: Tlchargement des logiciels (UCD-SNMP, ) http://www.perl.com : Documentation sur le langage perl http://www.perl.com/CPAN-local/modules/by-module: Tlchargement des modules perl http://www.cisco.fr : Documentation sur les MIB IPv6. http://www.juniper.net : Documentation Documentation: IPv6, Thorie et Pratique - Gisle Cizault OReilly Edition 03/2002 RFC :

RFC 1303-1351-1352-1353: SNMP v1 - Description du modle RFC 1442 1446 : SNMP v2 - Description du modle RFC 2271 2273 : SNMP v3 Description du modle RFC 2452: MIB IPv6 TCP RFC 2454: MIB IPv6 UDP RFC 2465: MIB IPv6 RFC 2466: MIB ICMPv6 RFC 1657: MIB BGP-4 DRAFT :

draft-ietf-ipv6-rfc2011-update-03.txt : draft sur la MIB IP draft-ietf-ipv6-rfc2012-update-03.txt : draft sur la MIB IP TCP draft-ietf-ipv6-rfc2013-update-03.txt : draft sur la MIB IP UDP draft-ietf-ipv6-rfc2096-update-04.txt : draft sur la MIB IP Forwarding Table

SimonMast

8. Annexes

Annexe I: Liaison Sature Ann MUYAL re SCR - 38 -

exe II: Dtection dun dni de service avec la mtrologie

SimonMast

Annexe III: Rpartition des flux Ann

c -c-c-c ---I---c c ---c c C MUYAL re SCR - 39 -

exe IV: Quelques champs de la MIB CISCO-IETF-IP iscoIetfIpMIBObjects OBJECT IDENTIFIER ::= { ciscoIetfIpMIB 1 }

- the IP general group Ip OBJECT IDENTIFIER ::= { ciscoIetfIpMIBObjects 1 } - the IPv6 specific group Ipv6 OBJECT IDENTIFIER ::= { ciscoIetfIpMIBObjects 2 } - the ICMP group Icmp OBJECT IDENTIFIER ::= { ciscoIetfIpMIBObjects 3 }

- - Textual Conventions - pv6AddrIfIdentifier - - Object definitions - Ipv6Forwarding OBJECT-TYPE ::= { cIpv6 1 } Ipv6DefaultHopLimit OBJECT-TYPE ::= { cIpv6 2 }

- - IPv6 Interface table - Ipv6InterfaceTable OBJECT-TYPE ::= { cIpv6 3 } Ipv6InterfaceEntry OBJECT-TYPE ::= { cIpv6InterfaceTable 1 } Ipv6InterfaceEntry ::= SEQUENCE {

cIpv6InterfaceIfIndex InterfaceIndex, cIpv6InterfaceEffectiveMtu Unsigned32, cIpv6InterfaceReasmMaxSize Unsigned32, cIpv6InterfaceIdentifier Ipv6AddrIfIdentifier, cIpv6InterfaceIdentifierLength INTEGER, cIpv6InterfacePhysicalAddress PhysAddress }

cIpv6InterfaceIfIndex OBJECT-TYPE ::= { cIpv6InterfaceEntry 1 } cIpv6InterfaceEffectiveMtu OBJECT-TYPE ::= { cIpv6InterfaceEntry 2 } cIpv6InterfaceReasmMaxSize OBJECT-TYPE ::= { cIpv6InterfaceEntry 3 } cIpv6InterfaceIdentifier OBJECT-TYPE ::= { cIpv6InterfaceEntry 4 } cIpv6InterfaceIdentifierLength OBJECT-TYPE ::= { cIpv6InterfaceEntry 5 } cIpv6InterfacePhysicalAddress OBJECT-TYPE

::= { cIpv6InterfaceEntry 6 }

SimonMast

Annexe V: ASPath-tree sur le rseau projet de RENATER MUYAL re SCR - 40 -


Annexe VI : Liste des commandes du looking glass : ! show BGP ipv6 ! show BGP ipv6 neighbors ! show BGP ipv6 summary ! show BGP ipv6 regexp $regexp o $regexp est une expression rgulire ! show BGP ipv6 quote_regexp $regexp ! show BGP ipv6 paths $regexp ! show ipv6 traffic ! show ipv6 interface ! show ipv6 neighbors ! show ipv6 tunnel ! show ipv6 route ! ping ipv6 $adresse - ping $adresse o $adresse est une adresse IPv6 ou IPv4 ! traceroute ipv6 $adresse - traceroute $adresse ! show ip bgp sum ! show ip bgp $adresse - sh bgp ipv6 $adresse ! show ip bgp dampening dampened-paths ! show ip mroute summary ! show ip mroute active ! show ip mbgp summary ! show ip mbgp $adresse

Annexe VII: Liste des librairies et modules perl installer pour SSH

! Net-SSH-Perl-1.23 : Permet de se connecter un quipement en SSH. Dpendances:

! gmp-4.1.2.tar.gz :Librairie permettant de faire des calculs arithmtiques de prcision ! Math::GMP (1.04 ou plus) (pour SSH1) : Utilis pour le calcul lors du chiffrement ! String::CRC32 (1.2 ou plus) (pour SSH1) : Permet de faire des checksums (utile lors

de lauthentification) ! Digest::MD5 (pour SSH1): partir dun message en entre, cet algorithme produit une

empreinte de 128 bits sur ce message qui permet de vrifier lintgrit des donnes. ! IO::Socket (pour SSH1): Ncessaire pour tablir une communication en IPv4. ! IO::Socket6 (pour SSH1): Ncessaire pour tablir une communication en IPv6.

Les modules suivants permettent dutiliser les diffrents algorithmes de chiffrements

(ciphers) lors de la connexion SSH : ! Crypt::DSA (0.03 ou plus) (pour SSH2) ! Crypt::DH (0.01 ou plus) (pour SSH2) ! Math::Pari (2.001804 ou plus) (pour SSH2) ! MIME::Base64 (pour SSH2) ! Digest::SHA1 (pour SSH2) ! Digest::HMAC_MD5 (pour SSH2) ! Digest::HMAC_SHA1 (pour SSH2) ! Convert::PEM (0.05 or greater) (pour SSH2)


Annexe VIII: Modifications principales sur la librairie Perl.pm

#Utilisation de Socket6 use Socket6;

... # On vrifie si c'est une adresse IPv4 ou IPv6 ## Lookup server's IP address.

if ( $raddr = inet_pton(AF_INET6, $ssh->{host})) { $version = 6; } elsif ($raddr = inet_aton( $ssh->{host})) { $version = 4; } else { die "unknown remote host: $ssh->{host}\n";} ...

# Cration de la socket en v4 ou v6 my $sock = $ssh->_create_socket;

if ($version == 6) {

socket($sock, AF_INET6, SOCK_STREAM, $proto) || croak "Net::SSH: Can't create socket v6: $!";

} elsif ($version == 4) { socket($sock, AF_INET, SOCK_STREAM, $proto) || croak "Net::SSH: Can't create socket v4: $!"; }

# Connexion en IPv6 if ($version == 6) {

# Connexion en IPv6 connect($sock, sockaddr_in6($rport, $raddr)) or die "Can't connect to $ssh->{host}, port $rport: $!"; } elsif ($version == 4) {

# Connexion en IPv4 connect($sock, sockaddr_in($rport, $raddr)) or die "Can't connect to $ssh->{host}, port $rport: $!"; }


Annexe IX: Configuration de Tacacs+ (serveur et quipements) Configuration du routeur Cisco : Voici la configuration qui est prsente sur lensemble des routeurs de RENATER-3

enable secret local_enable_password aaa new-model tacacs-server host XX.XX.XX.XX #adresse IP du serveur tacacs aaa authentication login default tacacs+ aaa authentication login default tacacs+ enable aaa authentication enable default tacacs+

Configuration du compte Looking-glass : Extrait du fichier /etc/tacacs.conf

key = "la_cle"

accounting file = /var/log/tac.log

default authorization = permit

user=normal_user{ login = des N75frezREER/LI }

user=looking_glass {

login = cleartext mot_de_passe_en_clair cmd = show

{ permit "bgp ipv6 neigh" permit "ipv6 traffic" ...

...

} }


Annexe X: Interface du Looking Glass IPv6


Annexe XI: fichier de configuration pour le looking glass Ceci est un extrait du fichier contenant la liste des quipements du backbone et leurs caractristiques : Adresse, description, login et mot de passe pour Tacacs

# # lg.cfg Configuration file for the looking glass. # package config; # # Common variables. # $Company = 'RENATER'; $Logo = Renater.gif'; $Email = '[email protected]'; # # List of routers (detailed info below). This is the order they # will appear in the pull-down menu. # @Routers = ( 'besancon','compiegne',', 'toulouse' ); # # Per-cisco variables. # $cfg{besancon} = { Host => '2001:660:X:X::X', Login => '***', Pass => '***', IXPoint => 'Routeur C12000 ', }; $cfg{compiegne} = { Host => '193.X.X.X', Login => '***', Pass => '***', IXPoint => 'Routeur C12000 ', }; $cfg{toulouse} = { Host => '2001:660:X:X::X', Login => '***', Pass => '***', IXPoint => 'Routeur C12000 ', };

Rapport de stage:Entreprises:Prsentation de CSHistorique de CSOrganisation et activits de CSMissions CritiquesNetwork ServicesSolutions et Conseils en TechnologieInfogrance

Prsentation du NOC

Prsentation de RENATERLe rseau RENATERRENATER et IPv6

Prsentation du GIP RENATER1.3.1 Historique1.3.2 Son mtier : Matrise d'ouvrage

Outils de supervision utiliss en IPv4Au NOC (CS)2.1.2 Au GIP Renater2.1.2.1 SNMP2.1.2.2 Netflow

2.2 Etat de lart des MIB IPv62.3 Les outils existants en IPv63.1 Mise en place d'un looking Glass3.1.1 Problmatique3.1.2 Solution Mise en place de loutil:

3.2 Inventaire des quipements de RENATER-3:3.2.1 Contexte3.2.2 Objectifs3.2.3 Prsentation de l'application3.2.3.1Utilisation de la base de donnes de mtrologie3.2.3.2 Choix du langage CGI3.2.3.3 Interrogation des quipements3.2.3.4 Structure de la base de donnes3.2.3.5 Architecture de l'application3.2.3.6 Utilisation de l'outil

3.3 Conclusion4.1 Evolutions court terme4.2 Evolutions moyen et long termes

rapport sm

Documents