Supervision

From Livre IPv6

Revision as of 14:17, 28 December 2005 by Laurent Toutain (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

L'administration des réseaux se décompose en un ensemble de tâches, chacune ayant une fonction bien particulière qui peuvent brièvement être décrite de la manière suivante :

  • Supervision (Monitoring) : La supervision est essentielle à la bonne administration d'un réseau. Elle consiste à vérifier qu'un ensemble d'équipements constituant un réseau (Routeurs, switchs, serveurs, PCs) fonctionne correctement. Elle permet de connaître à tout moment la disponibilité mais aussi les performances qu'offre le réseau.
  • Métrologie : Elle consiste à surveiller et analyser le trafic véhiculé par les équipements réseaux. Elle permet donc d'évaluer le type et la quantité de trafic dans le réseau. La métrologie a pris ainsi une place importante dans le monde de l'administration des réseaux. Parmi les utilisateurs de ce service se trouvent les opérateurs qui l'emploient entre autres pour suivre la consommation de leurs clients et vérifier qu'elle est conforme à leur contrat (Accounting - Billing). De même, ils vérifient que leurs liens physiques n'atteignent pas la capacité limite. Grâce aux fonctions de quelques outils, il est possible de faire du "reporting". Il est ainsi plus facile de prévoir le dimensionnement du réseau lors de migrations.
  • Sécurité: Il est indispensable d'avoir une politique de sécurité dans un réseau afin d'assurer principalement l'intégrité et la confidentialité des données. Pour cela, il faut mettre en place plusieurs niveaux de sécurité :
    • il est nécessaire de sécuriser l'accès physique aux équipements réseaux (routeurs, commutateurs) et aux serveurs (collecteurs, serveur d'authentification...).
    • pour restreindre l'accès aux utilisateurs non autorisés, des filtres sur les adresses IP et les ports (Access List, IPTables, ACL) ainsi que sur les services applicatifs (Certificats de sécurité, PKI) sont mis en place.
    • l'information transmise sur le réseau doit être chiffrée pour éviter que des informations confidentielles comme les mots de passe circulent en clair.

La plus part des outils d'administration offrent ces fonctionnalités :

  • Découverte de la Topologie: La topologie permet de connaître à travers l'élaboration de schémas l'architecture du réseau. Il est donc très important de maintenir à jour ces schémas pour avoir une vision correcte du réseau.
  • Inventaire: L'inventaire permet de recenser l'ensemble des équipements qui constitue un réseau. Il a aussi pour but de tenir à jour la configuration de ces équipements. Si un inventaire n'est pas fait, il se peut, par exemple, que certains équipements du réseau ne soient pas supervisés. C'est pour cela qu'il est important de maintenir à jour l'inventaire, en même temps que le réseau évolue.

MIBs IPv6

La croissance rapide des réseaux et la diversité des systèmes pendant la dernière décennie a entraîné le besoin d'une gestion globale des infrastructures réseaux. SNMP (Simple Network Management Protocol) s'est avéré être une bonne solution proposée et standardisée par l'IETF. Ce protocole permet de collecter diverses informations stockées dans les équipements du réseau dans des bases de données appelées MIBs (Management Information Base). Les équipements sont aussi capables de faire remonter des alertes (traps) au collecteur SNMP via ce protocole (cf. figure Architecture d'administation - Interrogation des MIB.).

Sup3.gif

Le protocole SNMP et les MIBs sont devenus les deux éléments principaux du modèle de supervision de réseaux. Le protocole SNMP étant indépendant de l'architecture du protocole IP, son évolution vers IPv6 n'a pas représenté un problème majeur. La première implémentation de SNMP pour le protocole IPv6 a été réalisée par l'équipe du Loria de l'université de Nancy (NET-SNMP OpenSource) et a été disponible dans la version 5.0.3 de net-snmp, en mai 2002. Avant cette première version, l'administration des réseaux IPv6 était possible du fait que les équipements avaient une double pile configurée IPv4 et IPv6. En effet, il n'était possible d'accéder en SNMP sur un équipement qu'en IPv4 et de récupérer des champs de la MIB concernant IPv6. Aujourd'hui, certains réseaux projets ne véhiculent que du trafic IPv6 d'où la nécessité de disposer d'une version IPv6 pour le transport du protocole SNMP. L'évolution des MIB est plus complexe. Depuis les spécifications initiales du protocole IPv6, en 1995, la définition de la MIB-2 pour l'administration des réseaux IPv6 a été modifiée à deux occasions en 1998 et en 2000 (cf. figure Evolution de la MIB.). Le problème principal était de définir le type du champ "IP ADDRESS". En 1996, une représentation initiale du champ "IP ADDRESS" est décrite dans la où la longueur réservée pour ce champ est de 4 octets. Avec ce champ ne peuvent être représentées que les adresses IPv4 puisque les adresses IPv6 ayant une longueur de 128 bits. C'est pourquoi, en 1998, le introduit la définition d'un champ "Ipv6Address" sur 16 octets.

Sup4.gif

Ainsi de nombreuses RFCs ont été affectées par ces modifications. D'abord, avec la première approche de créer des MIBs IPv4 et IPv6 indépendantes, de nouveaux RFC ont vu le jour. Principalement, les RFCs décrivant les MIBs IPv6 sur transport TCP ou UDP ( et ) ont été publiés en 1998. De même, une MIB concernant le protocole ICMPv6 a été décrite dans la . Cependant, cette approche implique une gestion indépendante des protocoles IPv4 et IPv6. Ainsi, l'IETF a décidé de définir une MIB-2 unifiée, permettant de superviser les réseaux IPv4 et IPv6 ( - Juin 2000). Ce RFC définit le champ "IP ADDRESS" comme une structure avec deux champs. Le premier champ permet de différencier le type d'adresses (IPv4 ou IPv6). Le deuxième champ est une chaîne de caractères de longueur variable qui peut contenir des valeurs de longueur égale à 4 ou 16 octets (IPv4 ou IPv6). Il devient possible de définir dans les MIBs des tables compatibles avec les deux versions d'IP. Afin d'améliorer la description de la MIB, en mai 2002, le obsolète les et . Des informations supplémentaires y sont décrites comme le préfixe réseau, le numéro de port utilisé par la couche transport ou le numéro d'AS (Automous System) correspondant à l'adresse IPv4 ou IPv6. Cette volonté d'avoir une MIB unifiée entraîne aussi la mise à jour des MIB déjà existantes. Actuellement, l'IETF publie des drafts de mise à jour pour les RFCs 2011, 2012, 2013 et 2096. Les dernières propositions publiées sont :

  • draft-ietf-ipv6-rfc2011-update-10.txt [Rou-id] (mai 2004), [RFC4022] (Mars 2005),
  • draft-ietf-ipv6-rfc2013-update-04.txt (octobre 2004),
  • draft-ietf-ipv6-rfc2096-update-07.txt (février 2004).

Ces drafts concernent respectivement les MIBs IP, TCP, UDP et IP Forwarding table. Pour les MIBs concernant le routage BGP4+ et OSPFv3, les derniers drafts proposés sont draft-ietf-idr-bgp4-mibv2-15.txt (Août 2004) et draft-ietf-ospf-ospfv3-mib-09.txt (avril 2004) mais le premier de ces drafts a expiré en juin 2004, ce qui laisse les MIBs concernant le routage externe IPv6 en suspens. En raison de toutes ces modifications, les MIBs ne sont pas entièrement disponibles aujourd'hui. En effet, uniquement quelques réalisations ont été effectuées par les constructeurs. Nous verrons par la suite les implémentations des différents constructeurs.

Personal tools