Escolar Documentos
Profissional Documentos
Cultura Documentos
Octobre 2011
1.
GESTION DES RESEAUX INFORMATIQUES ................................................................................... 3 1.1. INTRODUCTION..............................................................................................................................................3 1.2. GENERALITES ...............................................................................................................................................4 1.3. PRINCIPE GENERAL ......................................................................................................................................5 1.4. ARCHITECTURE DADMINISTRATION .............................................................................................................6
2. PROTOCOLE POUR LA GESTION DES RESEAUX DANS LE MODELE TCP/IP : SNMP .............. 8 2.1. QUELQUES CONCEPTS FONDAMENTAUX ......................................................................................................9 2.2. ARCHITECTURE DE SNMP .........................................................................................................................11 2.3. MODELE D'INFORMATION ............................................................................................................................12 2.4. STRUCTURE DES INFORMATIONS DADMINISTRATION DE RESEAUX (SMI) ................................................16 2.5. MODELE FONCTIONNEL DADMINISTRATION DES RESEAUX .....................................................................18 2.6. PROTOCOLE SNMP ...................................................................................................................................20 3. SECURITE DES VERSIONS DE SNMP ................................................................................................ 26 3.1. SNMP VERSION 1 ......................................................................................................................................26 3.2. SNMP VERSION 2 ......................................................................................................................................26 3.3. SNMP VERSION 3 ......................................................................................................................................27 4. MISE EN UVRE DE SNMP ................................................................................................................. 29 4.1. CONFIGURATION DE SNMP SUR W INDOWS ..............................................................................................29 4.2. CONFIGURATION DE SNMP SOUS LINUX (UBUNTU) ..................................................................................31 4.3. CONFIGURATION DE SNMP SUR UN ROUTEUR CISCO..............................................................................32 5. RMON : REMOTE MONITORING .......................................................................................................... 33 5.1. RMON 1 .....................................................................................................................................................33 5.2. RMON 2 .....................................................................................................................................................34 6. UTILISATION DE SYSLOG .................................................................................................................... 35 6.1. FONCTIONNEMENT DE SYSLOG ..................................................................................................................35 6.2. EXEMPLE CENTRALISATION DE FICHIERS SYSLOG SUR UN SERVEUR CENTRAL.......................................36 7. OUTILS DE SUPERVISION ET DADMINISTRATION DES RESEAUX ............................................ 38 7.1. FONCTIONNALITES DE BASE.......................................................................................................................38 7.2. FONCTIONNALITES AVANCEES ...................................................................................................................38 8. BIBLIOGRAPHIE .................................................................................................................................... 40
1.2. GENERALITES
La gestion des rseaux informatiques constitue un problme dont lenjeu est de garantir au meilleur cot non seulement la qualit du service global rendu aux utilisateurs mais aussi la ractivit face aux besoins de changement et dvolution. La gestion des rseaux informatiques se dfinit comme tant lensemble des moyens mis en oeuvre (connaissances, techniques, mthodes, outils) pour superviser, exploiter des rseaux informatiques et planifier leur volution en respectant les contraintes de cot et de qualit. La qualit de service se dcline sur plusieurs critres, du point de vue de lutilisateur final, notamment la disponibilit, la performance (temps de rponse), la fiabilit, la scurit Les activits dadministration sont communment classes en activits de : Supervision qui consiste surveiller les systmes et rcuprer les informations sur leur tat et leur comportement, ce qui peut tre fait par interrogation priodique ou par remonte non sollicite dinformations de la part des quipements de rseaux eux-mmes. Administration qui dsigne plus spcifiquement les oprations de contrle froid du rseau avec la gestion des configurations et de la scurit, Exploitation qui dsigne lensemble des activits permettant de traiter les problmes oprationnels sur le rseau : maintenance, assistance technique
Chaque objet est gr localement par un processus appel agent qui transmet rgulirement ou sur sollicitation les informations de gestion relatives son tat et aux vnements qui le concernent au systme dadministration. Le systme dadministration comprend un processus (manager ou grant) qui peut accder aux informations de gestion de la MIB locale via un protocole dadministration comme SNMP ou CMIP de qui le met en relation avec les divers agents. Le principe repose donc sur les changes : Dautre part, entre les lments administrs et le systme dadministration. Dune part, entre une base dinformations appele MIB (Management Information Base) et lensemble des lments administrs (objets) ;
Mibs Prives
Poll SNMP Trap SNMP ICMP = Ping SNMP : Simple Network Management Protocol MIB : Management Information Base Trap SNMP Poll SNMP SNMP (Mib 2 +Mib Prive) Poll ICMP Poll SNMP Non-SNMP SNMP Mib 2 (Standard)
NMS Manager
Unix/Linux/Win
Trap SNMP
Chaque entit dans le rseau a un Agent pour lopration de gestion, une base de donnes stockes dans MIB et assume les travaux ci-dessous : - Collecter des informations statistiques concernant la communication, et les oprations de rseau. - Stocker les informations localement dans les MIBs. - Rpondre aux commandes de lentit de contrle de rseau, Transmet des informations statistiques lentit dadministration de rseau, modifie les paramtres, donne des informations dtat
Lentit dadministration a une entit logicielle de gestion (Network Management System : NMS) pour grer le rseau interface permettant ladministrateur de raliser des oprations de gestion. Diffrents cas sont envisags : Le nud supervis ne supporte pas SNMP : dans ce cas, la supervision consiste seulement vrifier via ICMP (ping) de sa prsence ou disponibilit sur le rseau. Dans certains cas il est possible davoir accs dautres informations via un proxy SNMP (voir plus loin).
Le nud supporte SNMP Mib 2 : dans ce cas seuls les donnes contenues dans la Mib 2, peuvent tre rcupres. Pour rappel la Mib 2, est une Mib standard convenues entre les diffrents constructeurs, et est embarque sur lcrasante majorit des quipements rseaux. Gnralement elle permet laccs des donnes non-spcifiques aux constructeurs : Trafic Entrant, Trafic Sortant, Taux dErreur sur un interface, Nom systme de lquipement, Disponibilit,etc. Le nud supporte en plus de la Mib 2, une Mib prive du constructeur : dans ce cas il est possible daccder en plus aux informations de la Mib 2, des informations spcifiques mises disposition par le constructeur dans sa Mib prive.
Remarques Importantes : 1. Afin daccder aux Informations contenues dans les Mibs, il faut que ces dernires soient compiles ou charges (loaded) au niveau du NMS Manager, lapplication centrale de supervision. 2. Pour des raisons de scurit, il nest pas recommand de superviser via SNMP des quipements derrire un firewall, c'est--dire dans une zone considre comme non-scurise.
La station NMS peut envoyer des requtes un priphrique afin dobtenir des informations sur son paramtre. Lagent du priphrique reoit la requte et renvoie les informations demandes. Lorsquelle reoit cette rponse, la station NMS peut utiliser les informations de configuration du priphrique afin de dterminer les oprations entreprendre en fonction de son tat.
10
11
12
Administration des Rseaux La gestion de rseau est dfinie par la branche iso(1). Dans cette branche on trouve un certain nombre de dfinitions dorganisations subordonnes. La gestion de rseau entre dans le noeud org(3). Sous le noeud dod(6) se trouvent un certain nombre de rseaux subordonns. La gestion de rseau entre dans le noeud internet(1). Sous le noeud internet(1) se trouvent un certain nombre de noeuds subordonns reprsentant diffrents services et tentatives de normalisation. La gestion de rseau standardise se trouve dans le rseau mgnt(2). Sous le noeud mgnt(2) se trouvent un certain nombre de noeuds subordonns reprsentant diffrents services et tentatives de normalisation. La gestion de rseau standardise se trouve dans le noeud MIB-2(1). Sous le noeud mib-2(1) se trouvent un certain nombre de noeud subordonns reprsentant diffrents groupement de variables MIB. Sous le noeud system(1), on trouve 2 variables MIB sysDescr(1) et sysLocation(2). Les identifiants dobjets de ces variables sobtiennent en crivant de gauche droite les diffrents noeuds, spars par des points : + sysDescr : 1.3.6.1.2.1.1.1 + sysLocation : 1.3.6.1.2.1.1.2 La reprsentation numrique dun nud de larborescence est appele aussi Object Identifier : OID .
system : Description de toutes les entits grs interfaces : Interface de donnes dynamiques ou statiques at (adress translation) : Table dadresses IP pour les correspondances dadresses MAC ip : Statistiques du protocole IP, adresse cache et table de routage
13
icmp : Statistiques du protocoles ICMP tcp : Paramtres TCP, statistiques et table de connexion udp : Statistiques UDP egp : Statistiques EGP, table daccessibilit snmp : Statistiques du protocole SNMP
En plus du standard MIB de TCP/IP, qui sappelle maintenant MIB-II, un nombre important de RFC dtaillent des variables MIB pour divers type de priphriques. Examinons quelques lments de donnes de la MIB pour en clarifier le contenu. Variables MIB sysUpTime ifNumber ifMtu ifInOctet ipDefaultTTL ipInReceives ipForwDatagrams ipOutNoRoutes ipReasmOKs ipFragOKs ipRoutingTable icmpInEchos tcpMaxConn tcpInSegs udpInDatagrams Catgorie systme interfaces interfaces interfaces ip ip ip ip ip ip ip icmp tcp tcp udp Signification Dure coul depuis dernier dmarrage Nombre dinterfaces rseau MTU dune interface particulire Nombre doctet entrants sur un interface MTU dune interface particulire Nbre de datagrammes reus Nbre de datagrammes achemins Nbre derreurs de routage Nbre de datagrammes rassembls Nbre de datagrammes fragments Table de routage IP Nbre de demandes decho ICMP reues Nbre maxi de connexions TCP autorises Nbre de segments reus par TCP Nbre de datagrammes UDP reus
Les valeurs des lments de chacune des variables ci-dessus peuvent tre enregistres au moyen dun seul entier. Toutefois, la MIB permet galement de dfinir des valeurs plus complexes, comme par exemple la variable ipRoutingTable qui fait rfrence la table de routage dun routeur. Des variables MIB supplmentaires sont dfinies pour le contenu de la table et pour permettre aux protocoles dadministration de rseaux de rfrencer les donnes correspondant chaque entre.
14
Directement au nud enterprises vient se greffer lidentifiant de chaque constructeur (cisco dans lexemple ci-dessus). De sorte que chaque constructeur a un identifiant unique qui le diffrencie des autres. Puis au dessous de chaque identifiant de constructeur, viennent se greffer les mibs prives du constructeur.
Figure 3 Exemple darborescence des mibs prives cas de cisco Au niveau de la reprsentation sous forme de chiffres, le nud cisco est reprsent par le chiffre 9 , de sorte que lensemble des nuds des mibs cisco par exemple vont commencer par lOID (Object IDenfier) : .1.3.6.1.4.1.9. 1 3 6 1 4 1 9 : : : : : : : iso org dod internet private enterprises cisco
15
En complment du standard MIB qui dfinit les informations spcifiques dadministration rseaux et leur signification, un standard spar spcifie lensemble des rgles utilises pour dfinir et identifier les variables MIB. Ce sont les rgles de gestion des informations dadministration, SMI (Structure of Management Information). Pour que le protocole dadministration de rseaux reste simple, SMI pose des restrictions sur les types de variables autorises dans la MIB, spcifie les rgles de nommage de ces variables et cre les rgles de dfinition des types de variables. Par exemple: SMI comprend des dfinitions de termes comme IpAddress (dfini comme une chane de 4 octets) et Counter (entier appartenant lintervalle [0,2e32-1] et indique que ce sont les termes utiliss pour dfinir les variables MIB. De plus, SMI dcrit la faon dont la MIB rfrence les tables de valeurs (les tables de routage IP, par exemple).
Dans les 2 cas, la notation formelle limine toutes les ambiguts possibles, tant du point de vue de la reprsentation que de la signification. Au lieu de dire par exemple, quune variable contient une valeur entire, un concepteur qui utilise ASN.1 doit dfinir la forme exacte et le domaine des valeurs prises par cet entier.
16
Administration des Rseaux } Dans ce cas, il sert attribuer la variable de gauche la dfinition du membre de droite. SEQUENCE reprsente une liste ordonne dlments. Cette liste ordonne contient les champs dune trame Ethernet, notamment ladresse de destination, ladresse source, le type dEthernet, les donnes et le CRC. Le type dun champ est spcifi la suite du nom. Par exemple, destAddr et srcAddr sont dclars comme tant de type OCTET STRING, dfinissant une variable de 0 ou plusieurs octets.La valeur de chaque octet est comprise entre 0 et 255. La taille de la chane obtenue est place aprs la dclaration de la chane OCTET STRING. Ethertype est dfini en tant que INTEGER, savoir une valeur entire de taille et de prcision arbitraire. Le (1501..65535) situ juste aprs permet de dfinir sa plage de valeur. Le champ de donne est de type ANY et sa taille varie de 46 1500 octets.En utilisant la notation ASN.1, les messages SNMP prennent le format suivant: SNMP-message::= SEQUENCE { version INTEGER {version-1(1)}, community OCTET STRING, data ANY }
17
18
Elle comprend la collecte dinformations statistiques(mesure du trafic, temps de rponse, taux derreurs, etc. ), le stockage et linterprtation des mesures (archivage des informations statistiques dans la MIB, calculs de charge du systme, tenue et examen des journaux chronologiques de ltat du systme).
19
20
2.6.1.1. Type de lire les informations GET GetRequest : Cette requte permet aux stations de gestion (manager) d'interroger les objets grs et les variables de la MIB des agents. La valeur de l'entre de la MIB (nom) est passe en paramtre. Elle permet d'accder une variable prcise. GetNextRequest : Cette requte permet aux stations de gestion de recevoir le contenu de l'instance qui suit l'objet nomm (pass en paramtre) dans la MIB. Cette commande permet en particulier aux stations de gestion de balayer les tables des MIB. Elle permet d'accder plusieurs variables simultanment. GetResponse: des requtes, l'agent rpond toujours par GetResponse. Toutefois si la variable demande n'est pas disponible, le GetResponse sera accompagn d'une erreur noSuchObject.
21
Administration des Rseaux GetBulkRequest : (version 2 et version 3 ) Cette requte est une amlioration du SNMP, elle permet aux stations de gestion (manager) d'interroger les objets grs et les variables de la MIB des agents. Il permet la station de gestion de rcuprer efficacement des grandes donnes . Exemple : GetRequest(1.3.6.1.2.1.6.4) provoque le retour de GetResponse (tcpMaxConn = x ) o x est le rsultat de la requte).
2.6.1.2. Type de modification des informations SET SetRequest : Cette requte permet aux stations de gestion de modifier une valeur de la MIB ou d'une variable et de lancer des priphriques. Elle permet par exemple un manager de mettre jour une table de routage. SetRequest provoque aussi le retour de GetResponse. Exemple: SetRequest(1.3.6.1.2.1.6.13.1.1 GetResponse(tcpConnState = 12). = 12 ) provoque le retour de
2.6.1.3. Type de non sollicits Les alarmes TRAP : Lorsquun priphrique entre dans un tat anormal, lagent SNMP prvient le gestionnaire SNMP par le biais dun Trap SNMP. Le message Trap peuvent tre cold start (dmarrage froid), warm start (dmarrage chaud), rinitialisation de lagent SNMP, authentication failure (chec dauthentification, lorsquun nom de communaut incorrect est spcifi dans une requte), loss of EGP neighbour (perte de voisin EGP) InformRequest : (version 2 et version 3) Le but de l'InformRequest-PDU est rellement de faciliter la communication d'information entre les stations de gestion de rseau. L'agent SNMP sur un NMS peut choisir d'informer des autres d'une certaine information en envoyant une InformRequest-PDU cet autre l'agent de SNMP.
22
Description des champs : version : Version de SNMP. community : Nom de la communaut (agit comme un mot de passe). request-id : Utilis pour diffrencier les messages. error-status : Utilis pour signaler une erreur (0 si pas d'erreur). error-index : Indique la sous-catgorie d'erreur. variablebindings : Nom des variables avec leurs valeurs. enterprise : Type de l'objet gnrant l'alarme. agent-addr : Adresse de l'metteur de l'alarme. generic-trap : Identificateur de l'alarme. specific-trap : Identificateur d'alarme spcifique. time-stamp : Temps coul depuis la dernire rinitialisation de l'entit. Le champ communaut (community) est une chane de caractre quil faut voir comme un mot de passe de validation dune requte SNMP par lagent ou par le manager. Si la communaut est incorrecte, la requte est rejete. La communaut passe en clair sur le rseau.
2.6.2.2. Envoie dun message Pour envoyer un message, l'agent de SNMP doit excuter les procdures suivantes : Utilise ASN.1 pour crer un PDU. Ce PDU est mis un service d'authentification , avec des adresses de destination, et de la source et du nom de la communaut, le service d'authentification va alors excuter leurs oprations et les oprations de cryptage.
23
Le message est construit partir du PDU avec l'ajout du nom de la communaut et la version de SNMP. Ce nouvel objet ASN.1, est enfin cod en utilisant BER et envoy au service de transport.
Il y a deux ports dsigns pour l'utilisation de SNMP : le numro 161pour les requtes standard et le numro 162 pour l'coute des alarmes destines la station d'administration. Cas de perte PDU
24
Administration des Rseaux UDP est un protocole qui n'est pas fiable 100% et la perte de trames est donc possible. Or rien n'empche UDP de perdre un trame contenant un message SNMP. Dans ce cas, plusieurs cas s'offrent nous : Le paquet perdu est du type Get ou une rponse d'un agent administr. Cela provoque un manque d'information au niveau de la station d'administration qui n'est pas important : Voyant la rponse ne pas arriver, la station d'administration peut dcider d'elle mme de renvoyer sa requte. L'identificateur de requte tant identique, il n'y a pas de risque de recevoir plusieurs rponses dues des questions dupliques. En cas de non-rponse permanent, cette station peut dclarer ce priphrique muet comme dfaillant. Le paquet perdu est du type Set. Il est alors plus judicieux de faire un Get sur cette entre afin de savoir si c'est la requte qui a t perdue ou alors sa rponse. C'est une alarme qui a t perdue. Comme aucun acquittement n'est ncessaire suite une alarme, la station d'administration ne sera jamais avertie par le signal. Il est donc ncessaire que la station d'administration scrute rgulirement l'tat de ses agents pour se mettre au courant des ventuels changements pour lesquels il n'aurait pas reu d'alarme.
25
26
Administration des Rseaux C'est un message trait comme une squence des nombres de 32 bits. Il est juste un calcul mathmatique excut sur ces nombres et inclus avec le message.. L'authentification montre seulement que le message est vritable, il n'empche pas une oreille indiscrte de lire le message.
Il se compose de quatre morceaux : l'expditeur, le sous-ensemble de traitement de message, le sous-ensemble de scurit, et le sous-ensemble de contrle d'accs. Le travail de l'expditeur est d'envoyer et recevoir des messages. Il essaye de dterminer la version de chaque message reu (c.--d., v1, v2, ou v3) et, si la version est soutenue, remet le message au loin au sous-ensemble de traitement de message. L'expditeur envoie galement des messages de SNMP d'autres entits . Le sous-ensemble de traitement de message prpare des messages pour tre envoy et extrait des donnes partir des messages reus. Un systme de traitement de message peut contenir des modules de traitement de message multiple. Par exemple, un sous-ensemble peut avoir des modules pour traiter les demandes SNMPv1, SNMPv2, et SNMPv3. Il peut galement contenir un module pour d'autres modles de traitement qui doivent tre dfinis encore. Le sous-ensemble de scurit fournit des services d'authentification et d'intimit. L'authentification emploie des valeurs de la communaut (versions 1 et 2 de SNMP) ou l'authentification utilisateur-base par SNMPv3. l'authentification Utilisateur-base emploie les algorithmes de MD5 ou de SHA pour authentifier des utilisateurs sans envoyer un mot de
27
Administration des Rseaux passe dans l'espace libre. Le service d'intimit emploie l'algorithme de DES pour chiffrer et dchiffrer des messages de SNMP.
28
3. Configurer le champ communaut (community) pour la scurit et spcifier les stations qui peuvent accder cet agent l.
29
30
mv /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.org
rocommunity public # Community name pour Lire syslocation "estem, casablanca" # Lieu
31
32
Le rle du manager snmp est de collecter par SNMP les donnes de trafic sur les agents RMON et de les prsenter sous forme tabulaire ou graphique. Les agents, aussi appels sonde RMON, sont chargs de l'analyse et ventuellement de la capture du trafic en un point quelconque du rseau et de rpondre au requte du manager snmp. Une sonde RMON peut aussi tre considre comme un analyseur rseau communiquant. Les sondes RMON ou agent RMON sont disponibles sous plusieurs formes. Il existe des quipements ddis cette fonction (Netscout, Sniffer distributed), dautres non ddis cette fonction mais incluant des agents RMON comme cest le cas de certains commutateurs Ethernet. Finalement les sondes RMON existent sous forme de logiciels installer sur des systmes dexploitation standards Windows ou LINUX (Sonde Network General). Le standard RMON dfinit des jeux de compteurs de trafic et de fonctions quil rassemble dans des groupes numrots et spcifis dans des fichiers MIB. RMON se dcline en deux versions, RMON 1 et RMON 2, pour couvrir les 7 couches du modle OSI.
5.1. RMON 1
Le standard RMON 1 a t cr initialement pour avoir des informations sur le trafic rseau au niveau physique et liaison (Physical et logical link layer) et supporte les protocoles Ethernet et Token Ring. Le standard RMON1 est dfini par le RFC 1757 (Request For Comments) de lIETF (Internet Engineering Task Force). Une sonde RMON ou un commutateur Ethernet supportant le standard RMON1 (groupes 1,4,5,6) fournit des statistiques sur le(s) segments Ethernet: 1. Quantit de paquets et doctets reus et transmis au global sur le segment. 2. Quantit de paquets de broadcast, de multicast et derreurs au global sur le segment. 3. Tailles des paquets et rpartition 4. Quantit de paquets et doctets reus et transmis par une adresse Ethernet (MAC). 5. Quantit de paquets et doctets reus et transmis pour une paire dadresses Ethernet dans le sens source vers destination. 6. Quantit de paquets et doctets reus et transmis pour une paire dadresses Ethernet dans le sens destination vers source. 7. Quantit de paquets et doctets reus et transmis par les n adresses Ethernet les plus bavardes.
33
5.2. RMON 2
Le standard RMON version 2 a tendu lanalyse du trafic rseau de RMON 1 limit au niveau Ethernet aux protocoles de niveau suprieur tel que TCP/IP. Le standard RMON2 est dfini par le RFC 2021 (Request For Comments) de lIETF (Internet Engineering Task Force). Des informations statistiques sont disponibles au niveau de la couche rseau (IP) et de la couche application (TCP/UDP) : 1. Quantit de paquets et doctets reus et transmis par protocole de transport (IP, IPX, AppleTalk etc.). 2. Quantit de paquets et doctets reus et transmis par un host IP (adresse IP). 3. Quantit de paquets et doctets reus et transmis pour une paire dadresses IP dans le sens source vers destination. 4. Quantit de paquets et doctets reus et transmis pour une paire dadresses IP dans le sens destination vers source. 5. Quantit de paquets et doctets reus et transmis par les n adresses IP les plus bavardes. 6. Quantit de paquets et doctets reus et transmis par un host IP (adresse IP) pour une application identifie par le port TCP/UDP. 7. Quantit nombre de paquets et doctets reus et transmis pour une paire dadresses IP dans le sens source vers destination pour une application identifie par le port TCP/UDP. 8. Quantit de paquets et doctets reus et transmis pour une paire dadresses IP dans le sens destination vers source pour une application identifie par le port TCP/UDP. 9. Quantit de paquets et doctets reus et transmis par les n adresses IP les plus bavardes pour une application identifie par le port TCP/UDP.
34
6. UTILISATION DE SYSLOG
Syslog est un protocole dfinissant un service de journaux d'vnements d'un systme informatique. C'est aussi le nom du format qui permet ces changes. Lintrt de son utilisation rside dans sa capacit fournir des informations systmes sur ltat de lquipement, que ne peuvent fournir les Mibs. La combinaison des deux permettra de mettre en en place une configuration avance.
Plate-forme
Mthode
Linux
BSD
Solaris (2.5
infrieurs)
et
et En plus du flux habituel, une porte multithreaded appele /etc/.syslog_door est utilise.
HP-UX 11 et suprieur
35
Un journal au format syslog comporte dans l'ordre les informations suivantes : la date laquelle a t mis le log, le nom de l'quipement ayant gnr le log (hostname), une information sur le processus qui a dclench cette mission, le niveau de gravit du log, un identifiant du processus ayant gnr le log et enfin un corps de message. Certaines de ces informations sont optionnelles.
Les niveaux de gravit Syslog, souvent appels level sont au nombre de huit reprsents par un chiffre de 0 (Emergency) 7 (Debug) :
0 Emerg (emergency) 1 Alert 2 Crit (critical) 3 Err (error) 4 Warning 5 Notice 6 Info (informational) 7 Debug 8 none
Systme inutilisable Une intervention immdiate est ncessaire Erreur critique pour le systme Erreur de fonctionnement Avertissement vnement normal mritant d'tre signal pour information seulement Message de mise au point Ignorer ce message
Cette indication est particulirement importante car elle normalise de fait la reprsentation de la gravit d'un log, ce qui rend par exemple possible l'interoprabilit entre quipements de collecte de logs et quipements de gnration d'alertes.
36
R1>enable R1#configure terminal Enter configuration commands, one per line. R1(config)#logging host 192.168.105.3 Ladresse IP 192.168.105.3 est ladresse IP du serveur qui centralisera lensemble des syslog. Remarque : Il est tout fait possible de centraliser sur un mme serveur syslog , les syslog de lensemble des routeurs, switchs ou serveurs dune entreprise. Une fois centralise une mthode dutilisation serait la recherche rgulire dans le syslog central de mots cls indiquant le dysfonctionnement recherch. End with CNTL/Z.
37
Le choix de lune ou autre solution, doit rpondre plusieurs critres, et pas uniquement techniques : Le cot dacquisition La Qualit du support et service aprs-vente La facilit de mise en uvre Ltendue du primtre superviser ou administrer.
Sur le plan technique, nous prsentons ci-aprs quelques critres diffrenciateurs, permettant de juger ou classifier les solutions les unes par rapport aux autres.
38
Administration des Rseaux Ci-aprs, sont indiques quelques fonctionnalits avances que peuvent supporter les outils de supervision ou dadministration : Multi-tenancy Gestion des VLANs Gestion de HSRP Hot Standby Router Protocol Gestion des Rseaux MPLS et IP VPN Gestion des Protocoles de Routage Monitoring de la Tlphonie sur IP : SIP, Jitter,etc. Plug-Ins de Performance Constructeurs
39
8. BIBLIOGRAPHIE
GESTION DES RESEAUX INFORMATIQUES : JP et M Claude - Ed Eyrolles GESTION DE RESEAUX : Arpege - Ed Masson RESEAUX LOCAUX : Samuel Pierre - Ed Eyrolles COMPRENDRE LES RESEAUX D'ENTREPRISE : Philippe Gomez et Pierre Bichon - Ed Eyrolles
40