Difference between revisions of "Supervision"

From Livre IPv6

 
m (Administration d’un réseau uniquement en IPv6)
 
(17 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
{{suivi |L'exemple « mini-ping » revisité|L'exemple « mini-ping » revisité|Mise en œuvre par les constructeurs | Mise en œuvre par les constructeurs }}
 +
 +
 +
__TOC__
 +
 
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 :
 
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.
 
*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.
Line 12: Line 17:
 
==<div id="MIBIPv6">MIBs IPv6</div>==
 
==<div id="MIBIPv6">MIBs IPv6</div>==
  
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.).
+
[[image:Sup3.png|thumb|right|200px|Figure 16-1 ''Architecture d'administration - Interrogation des MIB'']]
 +
 
 +
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'administration - Interrogation des MIB.).
  
[[image: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 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.
 
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.
+
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 <tt>IP ADDRESS</tt> est décrite dans le RFC 1902 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 RFC 2465 introduit la définition d'un champ "Ipv6Address" sur 16 octets.
  
[[image:Sup4.gif]]
+
[[image:Sup4.png|thumb|none|500px|Figure 16-2 ''Evolution de la MIB'']]
  
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.
+
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 (RFC 2452 et RFC 2454) ont été publiés en 1998. De même, une MIB concernant le protocole ICMPv6 a été décrite dans le RFC 2466.
 +
 
 +
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 (RFC 2851 - Juin 2000). Ce RFC définit le champ <tt>IP ADDRESS</tt> 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 RFC4001 obsolète les RFC 2851 et RFC 3291. 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 RFC 2011, RFC 2012, RFC 2013 et RFC 2096. Les dernières propositions publiées sont :
 +
 
 +
*draft-ietf-ipv6-rfc2011-update-10.txt (mai 2004) (RFC Editor Queue),
 +
*RFC 4022 (Mars 2005),
 +
*RFC 4113 (Juin 2005),
 +
*draft-ietf-ipv6-rfc2096-update-07.txt (février 2004) (RFC Editor Queue).
 +
 
 +
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 <tt>draft-ietf-idr-bgp4-mibv2-05.txt</tt> (Juillet 2005) et <tt>draft-ietf-ospf-ospfv3-mib-10.txt</tt> (Décembre 2005) mais le premier de ces drafts a expiré en janvier 2006, 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.
 
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.
 +
 +
==Administration des réseaux IPv6==
 +
 +
===Administration d’un réseau Double Pile===
 +
 +
Le fait d’administrer des réseaux IPv6 ne se traduit pas toujours par l’emploi d’outils qui transportent l’information en IPv6. En effet, la plupart des équipements sur le réseau étant en double pile (IPv4 – IPv6), l’accès peut se faire en IPv4 puis les informations concernant la supervision IPv6 sont récupérées. Cette solution est retenue très souvent car certaines applications ne supportent pas encore le transport en IPv6.
 +
 +
Cela permet aussi aux NOC (''Network Operations Center'') n’ayant pas déployé encore un plan d’adressage IPv6 pour la supervision, d’administrer des réseaux aussi bien IPv4 qu’IPv6.
 +
 +
===Administration d’un réseau uniquement en IPv6===
 +
 +
L’administration d’un réseau uniquement en IPv6 est différente de l’administration d’un réseau ayant une double pile. En effet, du fait que les équipements ne sont accessibles qu’en IPv6, toute l’information de supervision doit être récupérée via le protocole IPv6. Il est donc indispensable dans ce cas là que toutes les applications utilisées pour l’administration du réseau supportent ce protocole.
 +
L’administration d’un réseau IPv6 est donc semblable à celle d’un réseau IPv4. Les informations récupérées sont souvent les mêmes dans les deux cas. Le point essentiel reste les constructeurs ainsi que les éditeurs de logiciels qui doivent rendre disponible les protocoles ainsi que les applications permettant l’administration d’un réseau IPv6.
 +
 +
{{suivi |L'exemple « mini-ping » revisité|L'exemple « mini-ping » revisité|Mise en œuvre par les constructeurs | Mise en œuvre par les constructeurs }}

Latest revision as of 14:28, 27 February 2006

L'exemple « mini-ping » revisité Table des matières Mise en œuvre par les constructeurs


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

Figure 16-1 Architecture d'administration - Interrogation des MIB

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'administration - Interrogation des MIB.).


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 le RFC 1902 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 RFC 2465 introduit la définition d'un champ "Ipv6Address" sur 16 octets.

Figure 16-2 Evolution de la MIB


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 (RFC 2452 et RFC 2454) ont été publiés en 1998. De même, une MIB concernant le protocole ICMPv6 a été décrite dans le RFC 2466.

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 (RFC 2851 - 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 RFC4001 obsolète les RFC 2851 et RFC 3291. 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 RFC 2011, RFC 2012, RFC 2013 et RFC 2096. Les dernières propositions publiées sont :

  • draft-ietf-ipv6-rfc2011-update-10.txt (mai 2004) (RFC Editor Queue),
  • RFC 4022 (Mars 2005),
  • RFC 4113 (Juin 2005),
  • draft-ietf-ipv6-rfc2096-update-07.txt (février 2004) (RFC Editor Queue).

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-05.txt (Juillet 2005) et draft-ietf-ospf-ospfv3-mib-10.txt (Décembre 2005) mais le premier de ces drafts a expiré en janvier 2006, 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.

Administration des réseaux IPv6

Administration d’un réseau Double Pile

Le fait d’administrer des réseaux IPv6 ne se traduit pas toujours par l’emploi d’outils qui transportent l’information en IPv6. En effet, la plupart des équipements sur le réseau étant en double pile (IPv4 – IPv6), l’accès peut se faire en IPv4 puis les informations concernant la supervision IPv6 sont récupérées. Cette solution est retenue très souvent car certaines applications ne supportent pas encore le transport en IPv6.

Cela permet aussi aux NOC (Network Operations Center) n’ayant pas déployé encore un plan d’adressage IPv6 pour la supervision, d’administrer des réseaux aussi bien IPv4 qu’IPv6.

Administration d’un réseau uniquement en IPv6

L’administration d’un réseau uniquement en IPv6 est différente de l’administration d’un réseau ayant une double pile. En effet, du fait que les équipements ne sont accessibles qu’en IPv6, toute l’information de supervision doit être récupérée via le protocole IPv6. Il est donc indispensable dans ce cas là que toutes les applications utilisées pour l’administration du réseau supportent ce protocole. L’administration d’un réseau IPv6 est donc semblable à celle d’un réseau IPv4. Les informations récupérées sont souvent les mêmes dans les deux cas. Le point essentiel reste les constructeurs ainsi que les éditeurs de logiciels qui doivent rendre disponible les protocoles ainsi que les applications permettant l’administration d’un réseau IPv6.

L'exemple « mini-ping » revisité Table des matières Mise en œuvre par les constructeurs
Personal tools