La supervision de réseau par SNMPjmjmon.fr/LaSupervisionDeReseau/FR/LaSupervisiondeReseau.pdfréseau par SNMP , ainsi que de délivrer des Best-Practices basées sur plus de quinze

LasupervisionderéseauparSNMP

Jenesais

pasgrand'ch

ose

mais

jele

partagevolontier Je ne sais pas grand' chose mais je le partage volontier

La supervision de réseau par

SNMP

JMJ � 2015

c©Copyright 2010�2015

JMJ

La supervision de réseau par

SNMP

Jean-Marc Jurkiewicz

27.01.2014

II

Table des matières

I La théorie 1

1 En résumé 3

2 Historique 5

3 Architecture 7

3.1 Information de management . . . . . . . . . . . . . . . . . . . . . 83.1.1 Représentation . . . . . . . . . . . . . . . . . . . . . . . . 83.1.2 OIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.3 MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Protocole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.1 Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.2 Community String . . . . . . . . . . . . . . . . . . . . . . 163.2.3 Protocol Data Unit (PDU) . . . . . . . . . . . . . . . . . 16

3.3 Synthèse du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . 233.3.1 Requête . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.2 Réponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

II Le Network Operating Center 27

4 Pourquoi superviser un réseau 29

4.1 Les missions du Network Operating Center . . . . . . . . . . . . 294.1.1 Le Network Operating Center et ITIL / COBIT . . . . . 29

4.2 Les outils du NOC . . . . . . . . . . . . . . . . . . . . . . . . . . 314.3 Synthèse du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . 33

III Le � réseau type � supervisé 35

5 Le � réseau type � supervisé 37

5.1 Con�guration des équipements supervisés . . . . . . . . . . . . . 385.1.1 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.1.2 Dé�nition de la Station de Management . . . . . . . . . . 395.1.3 Autres paramètres SNMP . . . . . . . . . . . . . . . . . . 39

III

IV TABLE DES MATIÈRES

5.1.4 Autres paramètres généraux . . . . . . . . . . . . . . . . 405.2 Quelles variables collecter ? . . . . . . . . . . . . . . . . . . . . . 41

5.2.1 Inventaire . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.2 Baseline monitoring . . . . . . . . . . . . . . . . . . . . . 50

5.3 Compteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.3.1 Compteurs CLI . . . . . . . . . . . . . . . . . . . . . . . . 575.3.2 Compteurs SNMP . . . . . . . . . . . . . . . . . . . . . . 585.3.3 � Bouclage des compteurs � . . . . . . . . . . . . . . . . . 59

5.4 Synthèse du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . 59

IV SNMP et l'indexation 61

6 SNMP et l'indexation 63

6.1 Indexation simple . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.2 Indexation multiple . . . . . . . . . . . . . . . . . . . . . . . . . 68

V Quelques chi�res et calculs élémentaires 71

7 Quelques chi�res et calculs élémentaires 73

7.1 Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.2 Timeout et retries . . . . . . . . . . . . . . . . . . . . . . . . . . 757.3 Collecte d'informations . . . . . . . . . . . . . . . . . . . . . . . 78

7.3.1 Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787.3.2 SNMP V2c et Getbulk . . . . . . . . . . . . . . . . . . . 807.3.3 Optimisation maximale . . . . . . . . . . . . . . . . . . . 867.3.4 Limitations et putting all toghether . . . . . . . . . . . . 88

7.4 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907.5 Synthèse du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . 91

VI Quelques exemples concrets 93

8 Lecture des adresses MAC par SNMP 95

8.1 VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958.1.1 Getif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968.1.2 CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968.1.3 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

8.2 Adresses MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978.2.1 Getif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978.2.2 CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988.2.3 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

8.3 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 998.3.1 Getif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008.3.2 CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

TABLE DES MATIÈRES V

8.3.3 PERL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008.4 Port Interface Index . . . . . . . . . . . . . . . . . . . . . . . . . 101

8.4.1 Getif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018.4.2 CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018.4.3 PERL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

8.5 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028.5.1 Getif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028.5.2 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

8.6 En combinant le tout . . . . . . . . . . . . . . . . . . . . . . . . . 103

9 Considérations supplémentaires 105

9.1 Quand collecter ces informations . . . . . . . . . . . . . . . . . . 1069.2 Quelles informations stocker . . . . . . . . . . . . . . . . . . . . . 106

9.2.1 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1069.2.2 Switch B . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

9.3 Automatisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099.3.1 Native Vlan . . . . . . . . . . . . . . . . . . . . . . . . . . 109

VI TABLE DES MATIÈRES

Avant-Propos

SNMP n'est pas l'acronyme de la Société Nationale des Moniteurs de Plon-gée.

SNMP est l'acronyme de Simple Network Management Protocol.

Simple : Le protocole est simple � même si cela ne saute pas spontanémentaux yeux �, la représentation des données est parfois déroutante de même que lescorrélations nécessaires entre plusieurs informations de base, pour construire uneinformation pertinente pour celui qui veut l'exploiter : la construction de la tablede routage d'un routeur, de la table des Address MAC d'un switch. . .nécessitentde mettre en corrélation beaucoup d'informations simples.

Network Management : C'est donc pour gérer un réseau que l'on utiliseSNMP. Sa puissance fait qu'actuellement beaucoup d'autres équipements sontgérables pas SNMP (serveurs, imprimantes. . .).

Protocol] : Un protocole de communication dé�ni le comment : Commentaccéder à l'information, comment transmettre une information, que représentecette information.

Objectifs

Le but du présent document est de donner un aperçu pratique du protocoleSNMP, de décrire comment s'en servir activement et e�cacement pour super-viser un réseau TCP/IP. Vous n'échapperez pas bien sûr à un peu de théorie, leminimum requis, a�n de vous permettre de comprendre et surtout de savoir ourechercher lorsque vous rencontrerez un obstacle.

Il s'agit de décrire comment lire des informations relatives aux équipementsréseau par SNMP, ainsi que de délivrer des � Best-Practices �basées sur plus dequinze années d'expérience dans la supervision de réseau dans des entreprisesde taille nationale et internationale, à plusieurs milliers d'équipements actifs(switchs, routeurs, acces-points. . . ).

VII

VIII TABLE DES MATIÈRES

Ce document doit être considéré comme un livre de recettes concernantSNMP, pas un cours sur SNMP. D'autres ouvrages le feront bien mieux quecelui-ci.

Les exemples seront basés, d'une part sur des équipements de réseau du fa-bricant Cisco, et d'autres par, sur des outils, tous gratuits et disponibles surl'Internet.

Quelques programmes en PERL seront proposés dans di�érents domaines.

Les anglicismes seront autant que possible évités, sans pour autant chercherà tout prix à les exclure, si le terme anglais paraît le plus approprié à l'explica-tion. En particulier ne seront pas traduits les termes propres à SNMP.

Toute la théorie, les RFC et autres standards sont disponibles sur Internetet ne seront que très rapidement rappelées ici.

Audience

Ce document s'adresse à toute personne en charge de l'administration ou del'opération d'équipements réseau gérables par SNMP.

Pré-requis

Une bonne connaissance de la supervision de réseau est un plus.Des notions de con�guration d'équipement réseau par CLI, permettront demieux comprendre certains chapitres.Des notions de programmation PERL permettront d'adapter à votre propreréseau les exemples joints.

Opinions

Je n'ai aucun lien, aucun intérêt avec un fabricant quelconque, que ce soitd'équipements réseau ou d'outils de supervision ou de management.Les avis et opinions cités dans cet ouvrage n'engagent que moi-même et reposentsur mon expérience � large mais non exhaustive � des équipements et des outils.

La supervision de réseau est mon travail quotidien, j'exprimerai donc un avisteinté de l'aspect opérationnel, du côté d'un utilisateur. Il ne s'agit pas d'unesynthèse toute théorique de � data sheets �, mais d'un avis personnel et en tantque tel, subjectif.

IX

X TABLE DES MATIÈRES

Glossaire

Adresse IP Identi�cateur numérique de chaque équipement réseau,au niveau IP.

Adresse MAC Identi�cateur unique, utilisé par le niveau 2 de l'OSI.Identi�e l'interface physique d'accès au réseau.

ARP Address Resolution Protocol. RFC 826, 5227, 5494.http ://tools.ietf.org/html/rfc82.

BdD Base de données.

CLI Command Line Interface.

EGP Exterior Gateway Protocol. Protocole de routage dansl'Internet. Obsolète.

Équipement réseau Un appareil connectés au réseau : Switch, routeur, té-léphone. . .

FQDN Fully quali�ed Domain Name.

IETF Internet Engineering Task Force : Un groupe auto-organisé de personnes travaillant ensemble dans lebut d'améliorer la technologie de l'Internet voirhttp ://www.ietf.org/.

IP Internet Protocol.

MAC Media Access Control. Sous-couche basse du niveau 2de l'OSI.

MIB Management Information Base : RFC 1156 qui décritles objets managés de la MIB.

OSI Open Systems Interconnection.

SMI Structure of Management Information : RFC 1155 quidécrit comment les objets managés de la MIB sont dé-�nis.

TABLE DES MATIÈRES XI

SNMP Simple Network Management Protocole : RFC 1157 qui dé�nit leprotocole utilisé pour manager les objets dé�nis dans la MIB.

RFC Request For Comments : Ces documents sont les produits o�cielsde l'IETF. Ils sont gratuits, disponibles sur l'Internet.

WAN Wide Area Network.

XII TABLE DES MATIÈRES

Première partie

La théorie

1

Chapitre 1

En résumé

Avec l'apparition de réseaux de plus en plus étendus et par la même de plusen plus compliqués et surtout inter-connectés et hétérogènes, est apparue lanécessité fondamentale de pouvoir gérer ces réseaux de manière distante sansutiliser une technologie � propriétaire �, dépendante d'un constructeur.

L'IETF a eu l'intelligence de dé�nir en même temps comment construire unréseau TCP/IP et comment le gérer. Ces dé�nitions sont publiques -accessiblesgratuitement à tous- indépendantes de tout constructeur : les RFC.

Ceci a conduit à une architecture de gestion :� Standardisée : La même donnée est retrouvée de la même manière sur

des équipements de constructeurs di�érents. Pas d'interdépendance entrel'outil de gestion et l'équipement gérer ;

� Universellement supportée : Tous les composants d'un réseau TCP/IPsont tenus de supporter SNMP. Ses possibilités font que SNMP serépand aux imprimantes, aux téléphones. . . ;

� Portable : non limité à une architecture, un langage de programmationun système d'exploitation ;

� Extensible : pour pouvoir évoluer en même temps que le réseau et sescomposants ;

� Distribuée : La supervision du réseau peut être partagée de manière géo-graphique ou fonctionnelle.

Il n'y à, aujourd'hui, pour certaines opérations nécessaires à la gestion d'unréseau, aucune alternative à SNMP.

3

4 CHAPITRE 1. EN RÉSUMÉ

Chapitre 2

Historique

A mon sens, le succès mondial de l'Internet est en majeure partie dû aufait que ses spéci�cations techniques soient issues du travail d'un groupe indé-pendant de tout constructeur, sans membre, sans adhésion, et ouvert à tout unchacun : l'Internet Engineering Task Force (IETF) dont le soucis permanent estl'amélioration de l'Internet.

Par Engineering il est entendu que l'IETF ne prend en considération que lesaspects d'ingénierie, pas les aspects politiques ni commerciaux.

L'IETF est scindée en 8 domaines d'intérêt (aeras) eux même divisés en unecentaine de groupes de travail qui se partagent les travaux techniques, dont lesrésultats sont principalement les Request For Comments (RFC) qui � recom-mandent � comment concevoir, utiliser et superviser l'Internet.

L'un des comités de l'IETF est l'Internet Architecture Board (IAB), encharge des orientations à long termes de l'Internet. Parmi les rares recommanda-tions émises par l'IAB �gure, dès 1988, la RFC 1052 1 : � IAB Recommendationsfor the Development of Internet Network Management Standards �, c'est-à-dire� Recommandations pour le développement des normes de gestion du réseauInternet �.

Cette RFC dé�ni une stratégie de management à court terme basée surSNMP (RFC 1098 2) et une stratégie à long terme basée sur CMIS/CMIP� Common Management Information Service and Protocol � de l'OSI qui adonné CMOT � CMIS Over TCP/IP � (RFC 1095).En même temps, les informations de gestion ainsi que leur structure étaient dé�-nies de manière à être compatibles à la fois avec SNMP et l'OSI dans deux RFC :

1. voir : http ://tools.ietf.org/html/rfc10522. Voir http ://rfc-ref.org/RFC-TEXTS/1098/index.html. Rendue obsolète par RFC 1157

5

6 CHAPITRE 2. HISTORIQUE

RFC 1065 3 : � Structure and Identi�cation of Management Information forTCP/IP-based internet �, appelée aussi SMI ;

RFC 1066 4 : � Management Information Base for Network Management ofTCP/IP-based internets �, appelée aussi MIB.

Ces RFC recevant de l'IAB le statut de � Recommanded �, il est attendu quetous les réseaux TCP/IP construits à partir de ce moment adoptent et implé-mentent ces spéci�cations. En d'autres termes d'être gérables par SNMP, SMIet MIB.

A ce jour, il est attendu que la RFC 1052 soit respectée par la mise en ÷uvredes : RFC 1155 (SMI ex-1065), RFC 1156 (MIB ex 1066) et RFC 1157 (SNMPex- 1098)

Nous avons donc :Un protocole qui nous permet de manager des objets (SNMP = Le � Com-ment �), ces objets sont décrits dans les MIB (Le � Quoi �), la structure de cesobjets est dé�nie par la SMI (Le � C'est Quoi �).

J'ai essayé de mentionner dans ce document les versions les plus à jour desRFC. Dans tous les cas, il est conseillé d'utiliser :

http ://www.rfc-editor.org/cgi-bin/rfcsearch.pl

pour trouver la RFC la plus actuelle.

3. Voir http ://tools.ietf.org/html/rfc1065. Rendue Obsolète par RFC 11554. Voir http ://tools.ietf.org/rfc/rfc1066.txt Rendue Obsolète par RFC 1156

Chapitre 3

Architecture

C'est la RFC 1157 qui dé�nit le modèle architectural de SNMP (voir �gure3.1 page 8) :

� un ensemble de station de management et d'équipements réseau ;

� la station de management supervise et contrôle les équipements réseau ;

� ce sont les équipements réseaux qui sont en charge -par le biais d'agents demanagement- d'e�ectuer les fonctions de management requises par la sta-tion de management. C'est un modèle (certes inhabituel) client-serveur,la station de management est le client, les agents sur les équipements deréseau sont les serveurs ;

� un protocole � SNMP � est utilisé pour échanger des informations de ma-nagement entre la station de management et les agents des équipementsréseau.

La station de management et les équipements réseau supervisés par cette der-nière sont appelés la community (communauté).

SNMP minimise explicitement le nombre et la complexité des fonctions demanagement réalisées par l'agent tout en restant su�samment extensible pourpouvoir supporter des aspects non entrevus de la gestion et de l'opération duréseau.

Dans la suite du document nous nous plaçons du point de vue de la stationde management.

7

8 CHAPITRE 3. ARCHITECTURE

Figure 3.1 � Le modèle architectural de SNMP selon RFC 1157

3.1 Information de management

3.1.1 Représentation

Les informations de management échangées par le protocole SNMP sont re-présentées conformément au langage ASN.1 1 (Abstract Syntax Notation One,normalisé par l'ITU-T et l'ISO/IEC : Recommandation X.680 et suivantes),permettant un échange d'informations entre des machines dont l'architecture etle langage d'implémentation peuvent être di�érents.ASN.1 n'est ni plus ni moins qu'un langage de dé�nition (pas de l'implémenta-tion) : avec ASN.1 il est possible de décrire l'information qui va être échangée,indépendamment de sa représentation sur l'émetteur ou le récepteur.

On peut faire l'analogie entre ASN.1 et la partie � déclarations � d'un lan-gage de programmation.

Un sous ensemble des BER (Basic Encoding Rules Recommandation X.690)est utilisé pour � compiler � l'ASN.1 en un �ux d'octets transmissibles sur uneligne de communication.

Ceci rend encore une fois SNMP indépendant d'un constructeur qui souhai-

1. http ://www.itu.int/ITU-T/asn1/ et l'excellenthttp ://www.oss.com/asn1/resources/books-whitepapers-pubs/dubuisson-asn1-book.PDF

3.1. INFORMATION DE MANAGEMENT 9

terait commercialiser sa solution de supervision pour ses � et uniquement ses �équipements de réseau.C'est la même � phrase � que la station de management envoie à l'équipementréseau, quel qu'en soit le constructeur, pour savoir � Combien d'octets ont tran-sités par le lien Numéro 1 �, par exemple.

En particulier sont dé�nies les règles de nommage des informations permet-tant une identi�cation sans ambigüité de celle-ci par l'assignation d'un ObjectIDenti�er (les fameux OIDs).Ces règles reposent sur une structure arborescente. A chaque n÷ud � ou branche �est associé un nom (un mot débutant par un caractère écrit en lettre minuscule)et un nombre.

N.B C'est ce nombre (et non le nom) qui sera utilisé pour le transfert dedonnées.

Primitives ASN.1 autorisées :

La RFC1155 n'autorise que les types primitifs ASN.1 suivants :� INTEGER : Nombre de 32 bits (0 � 232 − 1). L'utilisation du zéro est

interdite dans une liste énumérée (par exemple l'ifOperStatus � voir cha-pitre 3.1.3 page 13 � peut prendre les valeurs 1,2 ou 3, pas 0,1 ou 2) ;

� OCTET STRING : Chaîne de caractères encodée sur 0 ou plusieurs oc-tets. Attention est aussi utilisé pour représenter des adresses MAC, au-quel cas ce ne sont pas des caractères ASCII qui sont retournés, mais dubinaire ;

� OBJECT IDENTIFIER : voir chapitre 3.1.2 page 10 ;

� NULL : Non utilisé.

Ainsi que les constructors suivants :

� SEQUENCE : Utilisé pour générer des listes de � type primitifs � ;

� SEQUENCE OF : Utilisé pour générer des tables de SEQUENCE.

Et les types suivants :

� NetworkAddress : Une adresse de l'un des protocoles possibles. Aujour-d'hui seul le protocole IP est possible, cette adresse est donc équivalenteà l'adresse IP (ci-dessous) ;

� IpAddress : Les 32 bits d'une adresse IP représentée en tant que OCTETSTRING de longueur 4 ;

� Counter : Nombre entier de 32 bits (0 � 232 − 1) qui ne peut que croitreavec le temps (monotone croissant) jusqu'à sa valeur maximale (4294967295)puis repasse à zéro et continue de croitre. Un redémarrage de l'agent ré-initialise les Counters à 0. Attention une réinitialisation des compteurspar CLI ne réinitialise pas les Counters accédés par SNMP ;

� Gauge : Nombre entier de 32 bits (0 � 232−1) qui peut croitre ou décroitre


mais reste bloqué à son maximum (4294967295 + 1 reste à 4294967295).C'est la valeur d'un objet à un instant donné ;

� TimeTicks : Nombre entier non-négatif comptant le temps exprimé en100e de secondes depuis une référence. C'est la description du type del'objet qui dé�nit la référence. Souvent la référence est le démarrage del'agent ;

� Opaque : Ce type permet le passage d'une syntaxe ASN.1 encodée commeune OCTET STRING, en tant que paramètre ; A noter : Il n'est de-mandé à une implémentation conforme de la RFC, que d'accepter et dereconnaître le type Opaque, PAS de la comprendre et de l'interpréter.

La notion de Counter et de Gauge peut paraître confuse. Voici deux exemplespour apporter un peu de lumière :

� Le nombre d'octets reçus ou émis, le nombre d'erreurs sur une interfacesont des Counters, dont on ne peut tirer un enseignement que si l'onprocède par Deltas successifs et réguliers : savoir que sur une interface ily a eu 100 000 erreurs en soit n'apporte que guère d'information si l'onne sait pas si ces erreurs ont eu lieu depuis les 2 ans que l'équipementfonctionne, ou si ces erreurs ont eu lieu dans les 5 minutes qui viennentde s'écouler.

� Le nombre de connections TCP est par contre un objet dont la valeuractuelle, la mesure instantanée, est importante, pas leur cumul : c'est letype Gauge qui convient ici.

De plus amples renseignements sur ASN.1 et BER peuvent être trouvés ici :

http ://luca.ntop.org/Teaching/Appunti/asn1.html

3.1.2 OIDs

Comme nous l'avons vu, les règles de nommage reposent sur une structurearborescente. La racine (ou le tronc) n'est pas nommée, 3 � branches � : iso, ccitt,et join-iso-ccitt sont immédiatement accessibles. En�n, la sous-branche internetse trouve être la première branche sous dod, ce qui se décrit de la sorte : :

internet OBJECT IDENTIFIER : := iso org(3) dod(6) 1

Ce qui implique que les OIDs de la branche internet commencent tous par1.3.6.1 selon le schéma de la �gure 3.2 page 11


Figure 3.2 � Structure arborescente des OIDs

Une autre façon de représenter cette arborescence est donné par l'outil Getif :(voir �gure 3.3 page 11).

Figure 3.3 � Représentation de l'arborescence par Getif

3.1.3 MIB

Maintenant que nous avons vu comment accéder à une information, voyonsquelles informations sont accessibles.

C'est ici que l'on commence à rencontrer quelques di�cultés.En e�et, si de nombreuses informations sont accessibles à partir de la branche


iso.org.dod.internet.mgt dont la nature est parfaitement documentée dans laRFC 1156, encore plus d'informations sont accessibles à partir de la branche� private �, dont le développement est laissé libre aux constructeurs et dont ladé�nition n'est pas toujours librement accessible.

Certains constructeurs, c'est le cas de Cisco ou Hewlett Packard entre autres,ont bien compris tout l'intérêt qu'il y a à ce que la documentation de ces MIBssoit accessible au plus grand nombre, d'autres constructeurs, dont un françaisdont je tairai le nom, conservent la dé�nition de leurs � MIBs Constructeurs �bien secrète. Néanmoins, les MIBs dé�nies par la RFC 1156 seront toujoursdé�nies comme suit et permettent déjà beaucoup d'opérations de supervision.

RFC1146

La RFC 1156 dé�ni les groupes suivants :

� System ;

� Interfaces ;

� Address Translation ;

� IP ;

� ICMP ;

� TCP ;

� UDP ;

� EGP.

Ainsi que la méthode d'implémentation suivante : � Si la sémantique d'ungroupe s'applique à une implémentation, alors elle doit implémenter tous lesobjets de ce groupe �.

En d'autres termes, toutes les branches ne sont pas explorables : Le groupeEGP ne doit être implémenté que si le protocole EGP est implémenté. (Celan'a aucun sens de chercher [ de fournir ] des informations sur quelque chose quin'existe pas).

Chacun de ses groupes seront explorés en détail dans les paragraphes sui-vants. Pour bien illustrer l'importance de comprendre comment une MIB estdécrite, attardons-nous un moment sur un objet de cette MIB, par exemple lestatut opérationellen d'une interface où ifOperStatus.La RFC 1156 nous présente cet objet de la sorte :


OBJECT :-----

ifOperStatus { ifEntry 8 }

Syntax :INTEGER {

up(1), - ready to pass packetsdown(2),testing(3) - in some test mode

}

Definition :The current operational state of theinterface. The testing(3) state indicatesthat no operational packets can be passed.

Access :read-only.

Status :mandatory.

Ce qui doit être interprété comme suit :

L'objet (comprendre ici l'information) a pour nom ifOperStatus

ifOperStatus est la 8e branche sous la branche ifEntry(elle-même dé�nie plus haut dans la RFC)

Cet objet est représenté par un entier qui peut prendre les valeurs1 signi�ant up2 signi�ant down3 signi�ant testing

La dé�nition de cet objet est : � The current operational state of the interface.The testing(3) state indicates that no operational packets can be passed. �.

Cet objet n'est accessible qu'en lecture : il est impossible par SNMP demodi�er cet objet.

L'implémentation de cet objet est obligatoire.

Un administrateur réseau pourra donc, en lisant cette variable pour uneinterface donnée, savoir si un équipement est branché à cette interface. Il nepourra pas, par SNMP, � débrancher le câble �.

Dans l'exemple ci-dessous (voit �gure 3.4 page 14), avec l'outil Getif, nous li-


sons, sur le switch nommé mgth03, le statut opérationnel des interfaces de ceswitch.

Nous retrouvons bien l'OID .1.3.6.1.2.1.2.2.1.8 ou.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifOperStatus,ainsi que les di�érentes dé�nitions données par la RFC.

Le lien entre les valeurs lues et les ports physiques du switch sera explicitédans un paragraphe ultérieur.

Les OIDs sont donc une espèce de jeu de piste dont la syntaxe ne devrait

Figure 3.4 � Exemple d'OID

pas être étrangère au programmeur d'un langage orienté objet.

3.2 Protocole

La RFC 1157 dé�ni aussi la communication entre la station de managementet les équipements de réseau. Cette communication repose sur l'échange de mes-sages. Chacun de ces messages est entièrement et indépendamment contenu dansun datagramme UDP unique utilisant les BER d'ASN.1.

Ces messages sont transportés sur TCP/IP en utilisant le protocole UDP, doncmoins �able que TCP mais plus rapide car sans connexion ni contrôle d'erreur.Il faut bien noter ici que des messages SNMP peuvent être perdus, dupliqués,retardés, désordonnés, c'est dans la nature même du protocole UDP.

3.2. PROTOCOLE 15

Tous les messages sont reçus sur le port UDP 161 à l'exception des Traps qui lesont sur le port UDP 162.

Un message est formé d' :� Un identi�ant de version ;

� Une Community String ;

� Un Protocol Data Unit (PDU).

Figure 3.5 � Encapsulation des messages SNMP

3.2.1 Versions

SNMP version 1 noté aussi SNMPv1 est l'implémentation initiale de SNMPtelle que décrite dans la RFC 1157. C'est le standard recommandé et le plusutilisé.

SNMP version 2 devait combler les lacunes en termes de sécurité de SNMPv1,est une extension de SNMPv1, supportée parallèlement à celle-ci. SNMP version2 est scindée en SNMPv2p (RFC 1441) et SNMPv2u (User-based security RFC1909, RFC 1910).

SNMPv2* (User-based Security + nouvelles fonctions RFC 1901), peut êtrevu comme le meilleur de SNMPv2p et SNMPv2u.

Deux standards SNMP ne pouvant coexister, l'IETF trouve un consensus uni-quement sur les améliorations ne concernant pas la sécurité avec SNMPv2c(community string based SNMPv2 RFC 3416, RFC 3417, RFC 3418).

SNMP version 3 (RFC 3411) devrait combler les lacunes des deux versionsprécédentes en termes de sécurité. De par sa complexité et son statut expéri-mental, SMPv3 n'est pas répandu et ne sera pas abordé dans ce document.

De nombreuses entreprises demandent à ce que leur informatique et leur ré-seau soit audités. Ces audits de sécurité détectent immédiatement si vous nemettez pas en ÷uvre SNMPv3, et vous recommanderont de le faire.

Dans le chapitre 5.1.1 en page 38 seront présentées des recommandations entermes de sécurité.


3.2.2 Community String

Comme dé�ni au chapitre 3 en page 7, la community est un domaine demanagement, regroupant la station de management et les équipements réseaumanagés par celle-ci.La Community String est une forme de mot de passe assurant une protectionrudimentaire de la communication entre les di�érents membres de la Commu-nity contre des accès non autorisés.La valeur par défaut est � public � pour les lectures et � private � pour les écri-tures.

Best Practice :

N'autorisez jamais la connexion d'un équipement sans avoir modi�éles valeurs des Community String.

3.2.3 Protocol Data Unit (PDU)

Ce sont les données transmises dont le format dépend du message envoyé.Le protocole dé�ni 5 PDUs dont l'implémentation est obligatoire :

� Get-Request-PDU. Demande la valeur courante d'un ou plusieurs objets(au sens SNMP, � objet � peut être assimilé à � variable �) ;

� GetNextRequest-PDU. Demande le prochain objet (variable) dans l'ordrelexical. Est utilisé pour traverser toute une table de la MIB, ou toute lastructure arborescente de la MIB ;

� GetResponse-PDU. Retourne la réponse d'une requête � Get � ou sertd'acquittement d'une requête � Set � ;

� SetRequest-PDU. Fixe la valeur d'un ou plusieurs objets (variables). Trèsrarement utilisé ;

� Trap-PDU. Noti�cation non sollicitée (c'est le seul message provenant del'équipement supervisé qui ne soit pas une réponse à une requête de lastation de management) de l'agent à la station de management.

3.2. PROTOCOLE 17

Figure 3.6 � Dé�nition des 5 di�érents PDUs par la RFC 1157

Structure de ces PDUs

La RFC 1157 dé�ni la structure de ces PDUs de la manière suivante (voir�gure 3.8 page 19 ) :

Request ID : utilisé pour corréler une réponse reçue à une requête en suspens.

Error Status :� 0 noError : pas d'erreur ;

� 1 tooBig : la taille du GetResponse-PDU dépasse une limite locale ;

� 2 noSuchName : pas de correspondance exacte entre le nom d'un objet(d'une variable) dans le champ VarBind et le nom d'un objet (d'une


Figure 3.7 � Échanges de PDUs entre la station de management et l'équipementsupervisé

variable) existant dans la MIB de l'équipement supervisé ;

� 3 badValue : tentative d'assignation d'une valeur inconsistante à un ob-jet ;

� 4 readOnly : lecture seule. Non utilisé suite à une erreur d'édition. Lecode (2) noSuchName est retourné en cas de tentative d'écriture d'unobjet accessible en lecture-seule ;

� 5 genErr : La valeur d'un objet (d'une variable) ne peut être déterminéeet la cause de cette indétermination n'est pas couverte par les cas d'er-reur précédents.

ErrorIndex : Fourni des informations supplémentaires (quelle variable dansune liste) dans le cas d'une réponse avec erreur.

VarBind (Variable Binding) : Couple formé par le nom d'une variable et sa

3.2. PROTOCOLE 19

Figure 3.8 � Structure des 5 di�érents PDUs par la RFC 1157

valeur ;

VarBindList : Liste de VarBinds.

Une amélioration sensible apportée par SNMPv2c (et v3) est la requête � Get-Bulk � qui permet d'obtenir en une requête unique, un grand nombre d'objets(de variables) en réponse. Même si une requête Get-Request permet déjà dansSNMPv1 de demander plusieurs OIDs dans la VarBindList, la réponse de l'agentest limitée en taille. Il est impossible de demander une réponse qui excèderaitla taille maximale du message de l'agent, sans obtenir en réponse l'erreur � too-Big �.Avec GetBulk, il est demandé à l'agent de � remplir � son message de réponsejusqu'à la taille maximale de celui-ci, même si ce message ne contient pas latotalité de la réponse. La station de management demandera la suite des infor-mations par une succession de GetNext.

La commande GetBulk requiert le passage des paramètres suivants :

N : Nonreapeater : nombre de variables scalaires (pas une table), c.à.dle nombre de variable (OIDs) pour lesquelles un GetNext sera fait (parl'agent).

M : Max-repetitions : le nombre de GetNext réalisés par l'agent pourchacun des OIDs restants.

Voici un exemple utilisant Net-Snmp sur une distribution Linux Fedora Core


12 positionnant le paramètre NonReapeater à 1 par l'option -Cn1 et position-nant le paramètre Max-repetition à 5 par l'option -Cr5. L'option NonReapeaters'applique à la première OID fournie en paramètre de la commande, à savoirsysLocation, l'option Max-repetition s'applique aux OIDs suivants, à savoir if-descr, ifType et ifInOctets :

Dans cet exemple, une requête unique retourne 16 VarBinds en une seule ré-ponse. Une transaction unique (2 messages : requête/réponse) au lieu d'unetransaction par variable : l'utilisation du réseau et celle du CPU de l'agent sontoptimisées. (Voir aussi le chapitre 7.3.2 en page 809.

La commande est :

# /usr/bin/snmpbulkget mgth03 -c MyCommunity -v2c -Cn1

-Cr5 sysLocation ifdescr ifType ifInOctets

les données retournées par cette commande sont :

.1.3.6.1.2.1.1.6.0 = STRING : Ici-Bat.1-4eEtage

.1.3.6.1.2.1.2.2.1.2.1 = STRING : Vlan1

.1.3.6.1.2.1.2.2.1.3.1 = INTEGER : 53

.1.3.6.1.2.1.2.2.1.10.1 = Counter32 : 1567180

.1.3.6.1.2.1.2.2.1.2.233 = STRING : Vlan233

.1.3.6.1.2.1.2.2.1.3.233 = INTEGER : 53

.1.3.6.1.2.1.2.2.1.10.233 = Counter32 : 963503476

.1.3.6.1.2.1.2.2.1.2.10001 = STRING : FastEthernet0/1

.1.3.6.1.2.1.2.2.1.3.10001 = INTEGER : 6

.1.3.6.1.2.1.2.2.1.10.10001 = Counter32 : 2937841830


.1.3.6.1.2.1.2.2.1.3.10002 = INTEGER : 6

.1.3.6.1.2.1.2.2.1.10.10002 = Counter32 : 0


.1.3.6.1.2.1.2.2.1.3.10003 = INTEGER : 6

.1.3.6.1.2.1.2.2.1.10.10003 = Counter32 : 236282432

La ligne jaune apparaît 1 fois (option -Cn1)

Les lignes bleues , magentas , oranges

se répètent 5 fois (option -Cr5)

3.2. PROTOCOLE 21

Traps

Une Trap est un message non sollicité (Ce n'est donc pas une réponse à unerequête) envoyé par l'agent à la station de management.Il s'agit en principe d'un évènement important détecté par l'équipement super-visé et dont le l'occurrence doit être signalée.Le type d'évènement générant une Trap est con�guré � par la station de mana-gement ou autrement � sur l'équipement supervisé.

Les Traps suivantes (et les évènements associés) sont dé�nies par la RFC 1157 :

Figure 3.9 � Structure des Traps-PDUs

Les évènements suivants génèrent, si l'équipement supervisé est ainsi con�-


guré, une Trap, appelée generic-trap :

0 coldStart : Réinitialisation telle que la con�guration de l'agent peutêtre altérée. En général, une mise sous tension ;

1 warmStart : Réinitialisation telle que la con�guration de l'agent n'estpas altérée. En principe, un � reboot � ou un � reload � ;

2 linkDown : Défaut/panne sur un des liens de communication connu del'agent ;

3 linkUp : Un des liens de communication connu de l'agent est disponible ;

4 authenticationFailure : Défaut d'authenti�cation. En général, unerequête e�ectuée avec une Community String inconnue ;

5 egpNeighborLoss : Une entité réseau avec qui l'équipement superviséformait une paire EGP est défectueuse et la paire n'existe plus. Obsolète ;

6 enterpriseSpeci�c : Un évènement spéci�que au constructeur de l'ob-jet supervisé est survenu.

3.3. SYNTHÈSE DU CHAPITRE 23

3.3 Synthèse du chapitre

Pour illustrer le chapitre qui s'achève, voyons ce qui se passe sur le réseaulorsque le programme Getif est démarré pour un switch Cisco C-3560 24 portsnommé mgth03 (la Community String ainsi que le nom de domaine ont été mas-qués).

Une fois le champ � Host Name � renseigné, Getif recherche des informationspar SNMP sur cet équipement a�n d'a�cher l'écran présenté par la �gure 3.10page 23.En sni�ant avec Wireshark les transactions SNMP entre le PC hébergeant Ge-

Figure 3.10 � Getif sur mgth03

tif et le switch mgth03 les deux messages présentés par la �gure 3.11 en page23 sont observés :

Figure 3.11 � Traces Wireshark du lancement de Getif sur mgth03


3.3.1 Requête

Nous voyons, présenté par la �gure 3.12 en page 24 un premier message, issudu PC (Adresse IP Source = 169.134.127.22) à destination du switch mgth03(Adresse IP Destination = 169.233.2.3), de type get-request :

Figure 3.12 � Traces Wireshark du lancement de Getif sur mgth03 - détails

Il s'agit bien, tel que vu dans les paragraphes précédents, d'une trame Ether-net (2e ligne), transportant de l'IP (3e ligne) entre le PC et le switch mgth03 (cesont leurs adresses IP), véhiculant un datagramme UDP (4e ligne) à destinationdu port 161 :

Concernant le protocole SNMP (5e ligne), la version est 1 (la donnée est � 0 �en position 0x30), la Community String est masquée (positions 0x33 à 0x3D).L'identi�ant de la requête est 9786 (ligne 10), soit 0x263A (positions 0x44 et0x45), message sans erreur.

La VarBindList contient 8 éléments (lignes 14 à la �n, soit depuis la position0x50 à la �n) :

La première valeur demandée est le � sysDescr � dont l'OID est1.3.6.1.2.1.1.1.0et le nom SNMPv2-MIB : :sysDescr.0. Il s'agit d'une valeur scalaire.Il est à noter que l'encodage de cette OID (et des autres) n'encode pas lespremiers � 1.3.6 � : en positions 0x58 à 0x5D est encodé � 1.2.1.1.1.0 �.


A noter aussi, comme il s'agit d'une requête, que la partie � valeur � desVarBinds est non spéci�ée (� unspeci�ed �), ceci a�n que la syntaxe etl'encodage ASN.1 soient respectés ;

Et ainsi de suite . . .

3.3.2 Réponse

Nous voyons un deuxième message, issu du switch mgth03 (Adresse IP Desti-nation = 169.233.2.3) à destination du PC (Adresse IP Source = 169.134.127.22)de type get-response :

Figure 3.13 � Traces Wireshark de la réponse de mgth03

Il s'agit bien d'une réponse, c'est bien une réponse à la requête précédente (id= 9786), sans erreur, et les objets (variables) sont retournées dans la VarBind-List. Ici aussi il est à noter que l'encodage des OIDs n'encode pas les premiers� 1.3.6 �.

Il ne reste plus à Getif de présenter tout cela fort joliment à l'utilisateur(voir Figure 3.10 page 23).


Deuxième partie

Le Network Operating Center

27

Chapitre 4

Pourquoi superviser un réseau

La supervision du réseau n'est pas une �n en soi. La seule et unique raisonpour laquelle un réseau est supervisé est que dans le monde actuel, chaqueinterruption de réseau a un coût et ce coût peut croitre à une vitesse vertigineuseselon l'activité de votre entreprise. Ce peut être un coût imputable à :

� perte de productivité (nombre de collaborateurs a�ectés x cout horairex durée de l'interruption) ;

� réputation altérée (clients, fournisseurs, partenaires. . .) ;

� perte de revenus (directs, pénalités, investissements. . .) ;

� autres (Locations de matériel, heures supplémentaires. . .).

Les sources d'interruptions de réseau sont nombreuses et variées. Pour l'ins-tant seule la supervision de multiples paramètres permet, d'une part d'observerl'état de santé du réseau (pro-actif) et d'autre part de diagnostiquer �nementa�n de rendre rapidement le réseau disponible.

4.1 Les missions du Network Operating Center

4.1.1 Le Network Operating Center et ITIL / COBIT

Dans le cadre de ITIL et/ou de COBIT, les missions du NOC s'inscriventpleinement dans � Délivrer et Supporter � (voir �gure 4.1 page 30).Pour pouvoir dé�nir ce qu'il y a à faire, il faut dé�nir de quoi le NOC estresponsable, quels services sont sous sa responsabilité.Si nous prenons le réseau type tel que décrit au paragraphe III, le réseau typesupervisé, en page 35, le NOC est responsable � au moins � :

� de l'accès au réseau local, dans le CdC et les Filiales : LAN Access ;

� de l'accès au réseau grande distance interconnectant CdC et �liales :WAN Access.

29

30 CHAPITRE 4. POURQUOI SUPERVISER UN RÉSEAU

Figure 4.1 � COBIT -extrait-

� de l'accès au réseau dans �l : WiFI Access.

Et voyons ce que l'ITIL dé�nit dans le Service Support et le ServiceDelivery

Service support

Le domaine � Service Support � s'attache au fonctionnement et au supportde l'infrastructure technologique. Il est décomposé selon les 6 processus suivants :

Processus Objectifs

Gestion des con�gurations Gérer l'infrastructure technologique enfaisant un état des lieux de l'existanta�n de mieux le gérer et le faire évoluer.

Gestion des incidents Mieux détecter les incidents, améliorerle délai de résolution des incidents selonleur criticité sur le fonctionnement del'entreprise.

Gestion des problèmes Mieux gérer les problèmes récurrents etmettre en ÷uvre des solutions de pré-vention a�n de réduire leur occurrence,voire les supprimer.

Gestion des changements Mettre en ÷uvre des démarches deconduite du changement a�n d'antici-per les e�ets de bord.

Gestion des mises en ÷uvre S'assurer de l'adéquation du serviceavec les besoins métiers.

Gestion de la disponibilité Assurer un niveau de disponibilité suf-�sant à un coût raisonnable.

Table 4.1 � ITIL - Services Support

4.2. LES OUTILS DU NOC 31

Service Delivery

Le domaine � Service Delivery � s'attache la plani�cation et l'amélioration àlong terme de la fourniture de services liés à l'infrastructure technologique. Ilest décomposé selon les 4 processus suivants :

Processus Objectifs

Gestion des niveaux de service Maintenir un certain niveau de qualitéde service grâce à des contrats de ser-vice renégociés périodiquement.

Gestion des capacités et perfor-mances

Véri�er l'adéquation des capacités etperformances avec les exigences ac-tuelles et à venir.

Gestion de la continuité des ser-vices IT

Dé�nir et mettre en ÷uvre des délaiscontractuels pour la reprise après inci-dent.

Gestion �nancière des services IT Gérer la rentabilité des moyens mis en÷uvre pour fournir le service.

Table 4.2 � ITIL - Services DeliveryParmi les missions principales d'un NOC on peut donc citer :

� améliorer/maintenir la disponibilité du réseau ;

� superviser les équipements du réseau a�n de garantir qu'aucune pannen'est due à un équipement ayant atteint ses limites de performances ;

� garantir que les informations de con�gurations sont disponibles pour ré-générer des équipements défectueux ;

� automatiser les tâches répétitives pour utiliser au mieux les ressources ;

� fournir ou être capable de fournir des rapports compréhensibles quisynthétisent ce qui se passe sur le réseau.

4.2 Les outils du NOC

Pour remplir ses missions, l'un des principaux outils du NOC, si ce n'est leprincipal outil du NOC, est la station de management telle que dé�nie auchapitre 3 en page 7.Cette station de management est avant tout un SNMP-Collector, c'est-à-direune machine qui, par SNMP, va collecter un nombre impressionnant d'infor-mations sur les équipements réseau, et présenter une synthèse � de préférencegraphique � de cette collecte.

Malgré tout ce que vous pourrez entendre des zélés commerciaux ou lire sur lespages WEB éditées par des marqueteurs géniaux, l'outil unique � qui fait tout


et tout seul � yaka clinker �. . . � n'existe pas. Tenez-vous le pour dit.

Il existe néanmoins quelques outils � très peu en fait � qui sont universellementreconnus et dont la qualité des informations fournies et la �abilité de fonction-nement sont largement reconnues, à juste titre à mon avis. Ce sont :

� Hewlett Packard Open View Network Node Manager, qui permet unereprésentation graphique de la topologie et de l'état de santé de votreréseau. En en seul coup d'÷il vous savez si c'est � OK � ou non. Il nesupervise � que � le réseau mais le fait très bien. Il s'agit de supervision� temps réel �. Inconvénients : NMM ne laisse pas à l'utilisateur la libertéabsolue de placer les équipements supervisés tel que l'utilisateur l'entendmais impose � sa � vision basée sur une topologie et une hiérarchie dé�-nies. Les coûts d'achats et de maintenance sont élevés.

� Infoblox NetMRI (ex Netcordia) : Collecteur d'information SNMP.Après quelques jours de collecte, NetMRI fournit des informations dequalité exceptionnelle sur la � santé � de votre réseau. Il s'agit plutôtici de Baseline Monitoring couplé à une base de données qui renddes diagnostics d'une redoutable précision. Les coûts d'achats et demaintenance sont élevés.

Si vous avez vraiment les moyens, rajoutez-y :

� Concord eHealth pour générer des graphes. A mon avis c'est une solu-tion beaucoup trop chère, mais l'aspect professionnel (pas meilleur) desgraphes générés par rapport aux mêmes graphes générés par MRTG peutséduire ou rassurer. De toute façon, ce ne sont en �nal que des variablesSNMP qui sont représentées graphiquement.

� Micromuse Netcool, en tant que � concentrateur d'évènements �. Lescoûts d'achats et de maintenance sont élevés.

Outils à éviter : Les outils Cisco. Tous. Dé�nitivement. . .

Pour ma part, j'utilise quotidiennement :

� HPOV NNM en cours de remplacement par une solution Freeware : Jmon,pour des raisons de coûts ;

� Infoblox NetMRI pour la qualité de la synthèse fournie ;

� MRTG/Jnet (une solution Freeware) pour tout ce qui concerne la géné-ration de graphes de di�érentes variables et en particulier de n'importequelle valeur accessible par SNMP -mais pas seulement-, sur n'importequel équipement réseau ;

� Getif et Net-SNMP sur Linux pour des recherches rapides.


Mes 3 philosophies de travail :

1. KISS : Keep It Simple, Stupid. Croyez-moi, ce sera toujours assez com-pliqué.

2. Il faut investir dans les personnes, pas dans les outils. Il vaut mieux unou deux experts du réseau, bien formés au réseau et à ses équipements,avec des outils � moins bons �, qu'un groupe d'incompétents servants desoutils à la pointe du progrès dont les � outputs � seront incompris.

3. "It is better to solve the right problem the wrong way than the wrong

problem the right way". Richard Hamming 1950s Bell Labs.


Dans toutes les entreprises et partout dans le monde, la recherche d'unesolution à un problème � informatique � débute toujours par le réseau, car lespersonnes en charge de celui-ci sont capables de fournir des rapports étayésde toutes les mesures nécessaires, les disculpant � la plupart du temps � detoute responsabilité dans le problème détecté. Le problème est ensuite transmisaux personnes du � Système �, qui s'en tirent nettement moins bien, mais � laplupart du temps aussi � arrivent à se disculper.En�n le problème arrive aux � Applications �. . .

Il convient donc pour le NOC d'être en mesure de donner le plus rapide-ment possible tous les détails caractérisant le réseau, avant l'apparition d'unproblème (changement de hardware, changement de con�guration, Traps,mesures de performance, historique (Baseline monitoring), etc).Pour ma part, je privilégie pour un outil donné, la facilité d'utilisation auxfonctionnalités, car elle permet un accès rapide aux informations nécessaires àrégler un problème, tout particulièrement lorsque ce problème coute X Eurosla minute.En second lieu, les fonctionnalités prennent le pas sur la solution technique.Si aujourd'hui les solutions techniques � doivent � � au sens marketing �contenir les mots Cloud, Virtual Machine, et que sais-je d'autre, hier d'autresmots étaient indispensables et demain cela en sera d'autres. Par contre letravail du NOC est resté sensiblement identique par-delà ces � générations � desolutions techniques.Ne vous attendez pas à ce que quelque machine virtuelle et � cloudisée � n'égalejamais un bon ingénieur connaissant � son � réseau.

La solution mise en ÷uvre doit donc être capable de fournir des donnéeset des rapports ayant un sens (cela peut paraître trivial), faciles de lecture etd'interprétation, sous forme graphique.

Il est de la responsabilité du NOC de dé�nir, avec ses � clients � et ses


fournisseurs, les SLA (Service Level Agrement), dé�nissant les durées acceptéesde pannes et les temps de réaction attendus. Ceci permettra de dimensionnerà la fois le personnel du NOC et ce qui est attendu de ses outils. Unepersonne seule, pour un service 7x7 sera d'astreinte tous les week-end. . .Si lesoutils ne permettent pas un accès distant, cette personne devra se rendre surson lieu de travail à toute heure du jour et de la nuit pour e�ectuer un diagnostic.

En�n il est aussi de la responsabilité du NOC de savoir s'il vaut mieuxs'occuper du problème de la Filiale A, dans laquelle 250 collaborateurs sontbloqués suite à un dysfonctionnement, ou si la lenteur du poste de travail dudirecteur �nancier au 4e étage, quand il est en WiFi et dans la salle de réunion� Direction � mérite que tout le personnel du NOC s'en occupe parce que leproblème est annoncé par le directeur informatique qui est en ce moment mêmeen réunion avec ce directeur chez qui � A la maison, le Wi� marche mieuxqu'ici. . . �.

Cela dépend de la culture de votre entreprise. . .Cela dépend de vous.

Troisième partie

Le � réseau type � supervisé

35

Chapitre 5

Le � réseau type � supervisé

Le schéma ci-dessous (voir �gure 5.1 en page 37) représente le réseau type quisera pris en exemple dans le reste du document. Il s'agit d'un schéma classique,sans prétention et malgré tout représentatif de beaucoup d'implémentations,inter-connectant en étoile, un Centre de Calcul (CdC) à de nombreuses �lialesdistribuées géographiquement au niveau national ou international.

Figure 5.1 � � Réseau Type �supervisé

Les puristes me pardonneront de mélanger les niveaux 2 et 3 de l'OSI, c'estpurement dans un but pédagogique.

37

38 CHAPITRE 5. LE � RÉSEAU TYPE � SUPERVISÉ

Ce réseau comprend un centre de calcul (CdC) hébergeant tous les ser-veurs utilisés par les applications s'exécutant dans les N �liales. Le LANde ce centre de calcul est segmenté en plusieurs VLANs : Serveurs WEB,Serveurs Base De Données, etc. Ces Vlans sont transportés sur plusieurs switchs.

L'accès au backbone est assuré par un fournisseur. Pour des raisons deredondance, une double connexion est assurée en utilisant 2 technologiesdi�érentes, une Principale et une Backup, sans partage de charge (WAN_Pet WAN_B). En fonctionnement normal, seul le WAN Principal (WAN_P)transporte les données.Pour les mêmes raisons de redondance � pas de Single Point of Failure � lecentre de calcul dispose de deux routeurs.

Le même concept est mis en ÷uvre dans les �liales, le seul changementnotable est le nombre de connexions possibles (ordre de grandeur : plusieursmilliers dans le centre de calcul, jusqu'à quelques centaines dans une �liale),ainsi que le découpage fonctionnel des VLANS. Dans une �liale seront plutôtdé�nis les VLANs Bureautique, Téléphonie, WiFi, etc etc.

5.1 Con�guration des équipements supervisés

Tous (presque) les équipements réseau supervisés sont issus du fabricant Cisco(switchs, routeurs, access points). Tous les exemples cités seront en conséquencedes commandes IOS. Pour de plus amples détails : www.cisco.com.

5.1.1 Sécurité

Comme nous l'avons vu précédemment, SNMP n'est pas un protocole sécurisé,hormis SNMPv3 dont l'implémentation et l'acceptation sont loin d'être géné-ralisées.Pour pallier à ce manque de sécurité, je recommande d'une part de toujoursutiliser deux Community Strings di�érentes en lecture et en écriture et surtoutpas les valeurs par défaut et d'autre part de limiter, par Access List (ACL)au niveau des équipements supervisés, les autorisations d'accès SNMP sur cetéquipement.Les messages SNMP pourront toujours être espionnés par un � malveillant �, ilsne seront pas encryptés, mais ce � malveillant � ne pourra émettre de requêtes,ni pour lire une valeur, ni pour en modi�er une : Votre réseau est préservé.

5.1. CONFIGURATION DES ÉQUIPEMENTS SUPERVISÉS 39

Best Practice :

Community String Read-Only di�érente de Community String Read-Write et di�érente de public/private.

Community String interdire l'utilisation du signe @ (arrobase)

Restriction d'accès SNMP par Access List

Exemple :

access-list 1 remark snmp_acces

access-list 1 permit 1.2.3.0 0.0.0.255

seules les machines situées dans le VLAN de Management(Adresses IP entre 1.2.3.1 et 1.2.3.254) auront un accès« SNMP » à cet équipement.

snmp-server community MailleCSRide RO 1

La Community String en lecture seule est MailleCSRide etl’ACL 1 s’applique.

snmp-server community MailleCSWraite RW 1

La Community String en lecture/écriture estMailleCSWraite et l’ACL 1 s’applique.

5.1.2 Dé�nition de la Station de Management

Les équipements réseau doivent aussi � savoir � à qui envoyer les Traps, etquels sont les évènements générant ces Traps. Une Community String spéci�quedédiée aux Traps est aussi dé�nie.

Exemple :

snmp-server host 1.2.3.22 MailleTraps

La station de management destinataire des Traps est àl’adresse 1.2.3.22, la Community String dédiée aux Trapsest MailleTraps.

snmp-server enable traps snmp

Seules les Traps SNMP (RFC 1157) sont autorisées.

5.1.3 Autres paramètres SNMP

Le paramètre snmp-server location permet de saisir un texte d'une longueurmaximale de 255 caractères. Il est judicieux d'y mettre une description de lalocalisation géographique de cet équipement à l'intérieur de la �liale. Ceci vous


permettra d'orienter une personne dans la �liale, a�n d'y réaliser une action,sans avoir à vous rendre vous-même sur place. Très utile. . .croyez moi.

Best Practice :

Toujours renseigner et tenir à jour les paramètres snmp-server locationet snmp-server contact.

Exemple :

snmp-server location 3eEtageArmoire2-Administrationsnmp-server contact NOC 00 44 33 22 11 99

5.1.4 Autres paramètres généraux

Best Practice :

Date & Heure : Synchroniser par NTP vos équipements. Dansun environnement international utilisez partoutle même fuseau horaire et de préférence UTC.Heure d'été / Heure d'hiver : ayez vos équipe-ments � à la même heure � que vous-même, celavous aidera à analyser les logs.

Hostname : Donner un nom, selon vos propres règles de nom-mage à vos équipements et surtout étiquetez voséquipements avec ce nom, de manière à ce quel'étiquette soit lisible même quand l'équipementest �xé dans un rack avec un autre équipementdessus et dessous. Cela encore une fois, vousorientera ou vous permettra d'orienter quelqu'un.Attention à la longueur du nom, sur un switch 48ports, la place pour une étiquette est restreinte.

Loopback : Si possible, toujours dé�nir une interface Loop-back dans vos équipements et en faire la sourcedes Traps émises par l'équipement

Banner exec : A utiliser pour a�cher des information perti-

nentes. (voir exemple)

Interface : Utiliser la � description � d'une interface pour no-ter ce qui y est connecté, si ce qui y est connectéest supervisé ou sous votre responsabilité.

Exemple :

5.2. QUELLES VARIABLES COLLECTER? 41

ntp server 1.2.3.4 prefer

ntp server 1.2.3.5

hostname abcs01

abc = code de la filiale

s = type (s => switch)

01 = rang

clock timezone CET 1

Définition du fuseau horaire

clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct

3:00

Définition du passage heure d'été à heure d'hiver

interface Loopback0

ip address 10.1.2.3 255.255.255.255

snmp-server trap-source Loopback0

banner exec *

abcs01 / NOC / 12-10-2011 jmj Dernière reconfiguration et par qui

3560 Config 2 Core V54 / 12/10/2011 jmj Modèle de configuration

et version/auteur

*

interface FastEthernet0/4

description abch321 Fa/0 L'équipement abch321 est connecté à ce

port

- - -

interface GigabitEthernet0/3

description abcs123 Gi 0/1 L'équipement abcs123 est connecté à

ce port

5.2 Quelles variables collecter ?

Nous l'avons vu plus précédemment, une station de management est avant toutun SNMP-Collector. Que faut-il collecter et à quelle fréquence ? C'est ce que leschapitres suivants vont tâcher de décrire. Les outils � freeware � utilisés sont :

1. Getif pour une représentation rapide et synthétique, à condition d'avoirchargé les MIBs qui conviennent

2. Un serveur Linux avec Net-SNMP, pour une représentation � brute �,telle que par exemple utilisée dans les programmes PERL cités enexemple.


La plupart des exemples concerneront un switch Cisco nommémgth03.mondomain.com, sauf mentions contraires.Il ne s'agit pas d'une liste exhaustive, mais minimale, à mon sens.

5.2.1 Inventaire

Un inventaire exhaustif des équipements à superviser est indispensable pouradministrer et gérer l'environnement.

Sur la partie détaillée du réseau pris en exemple (voir �gure 5.2 en page42) , il y a déjà 12 équipements à inventorier (en admettant que votre fournis-seur vous donne un accès SNMP � même si ce n'est qu'en lecture seule � surses équipements,).

Il est quasiment impossible de maintenir manuellement un inventaire dé-taillé des équipements à superviser.

Il est toujours bon de connaître en détail l'équipement supervisé. Le pointd'entrée pour cela est .iso.org.dod.internet.mgmt.mib-2.system ou .1.3.6.1.2.1.1.Ceci permettra entre autre, de générer automatiquement un inventaire, com-prenant le type d'équipement, la version logicielle, le numéro de série, etc, siles valeurs adéquates sont stockées et accessibles d'une manière ou d'une autre(dans une base de données, �at �le. . .).

Figure 5.2 � Équipements à inventorier


CLI : Show version

La commande show version permet une représentation � humainement-lisible � de ces paramètres : Les paramètres surlignés en jaune sont considérésdans cet exemple comme de première importance : le type d'équipement, sonnuméro de série, sa version logicielle. La �gure 5.3 page 43 en donne un exemple :

Figure 5.3 � CLI : show version

Linux et Getif

Figure 5.4 � Première collecte d'information par Net : :SNMP

En analysant la ligne correspondant à la lecture de sysDescr (�gure 5.5 page44), il est possible de connaître le type de switch : C3560, malheureusement passu�samment en détail (il manque le nombre de ports), et la version logicielle :12.2.(25).SEE2 FC1. Cette analyse requiert un peu de programmation � PERLpar exemple � et n'est pas satisfaisante.


Figure 5.5 � Première collecte d'information par Getif

Nota Bene : La description des MIBs mentionnées ci-dessous s'obtientvia le lien suivant :http ://tools.cisco.com/Support/SNMP/do/BrowseOID.do ?local=en

Il est possible d'obtenir directement pas SNMP les informations qui manquenten interrogeant les MIBs constructeur.

Commençons par le type de châssis obtenu en émettant une requête envers laMIB : .iso.org.dod.internet.private.enterprises.cisco.workgroup.ciscoStackMIB

.chassisGrp.chassisModel ou .1.3.6.1.4.1.9.5.1.2.16. qui retourne la chainede caractères � WS-C3560-24PS �. La description de la MIB (voir �gure 5.6page 45) nous informe que cet objet correspond au numéro de chassis : � Themanufacturer's model number for the chassis. �

La MIB : .iso.org.dod.internet.private.enterprises.cisco.workgroup. ciscoStack-

MIB.chassisGrp.chassisSerialNumber ou .1.3.6.1.4.1.9.5.1.2.17 nous permetd'accéder au numéro de série du switch : CAT1052ZM4D. La description dela MIB (voir �gure 5.7 page 45) nous informe que cet objet correspond aunuméro de série du switch : � The serial number of the chassis in a numericform. . . �, que cet object est obsolète et remplacé par entPhysicalSerialNumdans la ENTITY-MIB. Nous ignorerons cet avertissement pour l'instant.

Finalement la MIB : .iso.org.dod.internet.private.enterprises.cisco.workgroup.

ciscoStackMIB.moduleGrp.moduleTable.moduleEntry.moduleSwVersion ou.1.3.6.1.4.1.9.5.1.3.1.1.20 nous retourne la version logicielle : 12.2(25)SEE2.La description de la MIB (voir �gure 5.8 page 46) nous informe que cet objetcorrespond à la version logicielle du module : � The software version of themodule. �


Figure 5.6 � Cisco MIB browser pour la MIB CISCO-STACK-MIB, Object =chassisModel

Figure 5.7 � Cisco MIB browser pour la MIB CISCO-STACK-MIB, Object =chassisSerialNumber

En regardant attentivement l'accès à la version du logiciel (voir �gure 5.10page 47), nous constatons que la MIB .iso.org.dod.internet.private.enterprises.

cisco.workgroup.ciscoStackMIB. moduleGrp.moduleTable.moduleEntry ou.1.3.6.1.4.1.9.5.1.3.1.1 contient toutes les informations requises :

� modulModel ;

� modulSwVersion ;

� modulSerialNumberString.

Nous remarquons que dès que nous quittons les MIBs dé�nies par les RFC pourinterroger les MIBs Constructeurs, nous pouvons trouver la même infor-mation en plusieurs endroits, qui peuvent être obsolète, et cela en fonction de


Figure 5.8 � Cisco MIB browser pour la MIB CISCO-STACK-MIB, Object =modulSwVersion

l'équipement réseau (di�érents équipements du même constructeur réagissentdi�éremment), de la version logicielle de cet équipement, et du constructeurévidemment.Tout l'art de développer un logiciel de supervision réside dans la connaissancede ces MIBs Constructeurs.

Figure 5.9 � Accès au modèle de switch et au numéro de série

Remarque : L'indexation des MIBs (telle que le � .1 �à la �n des OIDs de la�gure 5.10 page 47) sera explicitée ultérieurement.


Figure 5.10 � Accès à la version logicielle

Le sysObjectID , d'une valeur de 563 1 nous renseigne sur le type dé-taillé de l'équipement :Cisco Catalyst 3560 Series Switches ;3560-24PS ;1.3.6.1.4.1.9.1.563.

Le sysUpTime vous permet de savoir depuis quand votre équipementest � up �. Utile en cas de recherche de cause de problème.

La valeur retournée par sysLocation est aussi à stocker en BdD car ilest fort probable que le jour où vous en aurez besoin, l'équipement sera horsservice et non interrogeable.

Nous avons ainsi collecté les premières informations à stocker dans laBdD. L'outil Jmon stocke ces valeurs dans la table nommée � Obj � tel quereprésenté par la �gure 5.11 en page 48

Il ne reste plus qu'à répéter cette collecte pour tous les équipements supervisés.

En�n, ces variables étant relativement statiques (en principe un switchest rarement renommé ou déplacé ou remplacé), la fréquence de collecte de cesinformations est relativement basse, de l'ordre de 1 à 2 fois par jour.

Un extrait d'un programme PERL de Jmon, sur la façon dont celui-cicollecte ces valeurs est donné ci-dessous, il est assumé que les équipements à

1. voir annexe


Figure 5.11 � Premières valeurs dans la base de données Jmon

superviser sont nommés dans le tableau (au sens PERL) Table_Objects (sinonil faut adapter la ligne 44).En�n il convient aussi, en ligne 41, de remplacer la chaîne de caractères"MyCommunity", par la community string adéquate.

1 #!/usr/bin/PERL2 use MRTG_lib ;3 use SNMP_Session ;4 use BER ;5 use SNMP_util ;6 use Socket;7

8 #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−9 sub Debug { # Print all parameters received for debug purpose

10 if ($debug) {11 foreach $para (@_) {12 print "$para";13 }14 }15 }16

17 ## −−−−−−−−−−−−−−−−−− MIB Definitions −−−−−−−−−−−−−−−−−−18 $Msystem = ".1.3.6.1.2.1.1";19 $M_sysDescr = "1.0";20 $M_sysObjectID = "2.0";21 $M_sysUpTime = "3.0";22 $M_sysContact = "4.0";23 $M_sysName = "5.0";24 $M_sysLocation = "6.0";25

26 $CiscoChassisModel = ".1.3.6.1.4.1.9.5.1.2.16.0";27 $CiscoChassisSN = ".1.3.6.1.4.1.9.5.1.2.19.0";28 $CiscoModulSWVersion = ".1.3.6.1.4.1.9.5.1.3.1.1.20";29 $CiscoMIbcHsrpGrpVirtualIpAddr = ".1.3.6.1.4.1.9.9.106.1.2.1.1.11";


30 $CiscoMIbcHsrpGrpStandbyState = ".1.3.6.1.4.1.9.9.106.1.2.1.1.15";31

32 # For APs :33 $CiscoceAssetSerialNumber = ".1.3.6.1.4.1.9.9.92.1.1.1.2.1";34 $CiscoceAssetTag = ".1.3.6.1.4.1.9.9.92.1.1.1.13.1";35 $CiscoImageString = ".1.3.6.1.4.1.9.9.25.1.1.1.2.5";36

37 #for4948 Switchs38 $CiscoceAssetOrderablePartN = ".1.3.6.1.4.1.9.9.92.1.1.1.3.1000";39 $CiscoceAssetSerialNumber4948 = ".1.3.6.1.4.1.9.9.92.1.1.1.2.1000";40

41 $Def_Community = "MyCommunity"; #42 $community = $Def_Community."@";43

44 OBJECT: foreach $Object (@Table_Objects) {45 print " \nPolling Entity (managed interfaces only) : $Object ($Obj_FQDN / $Obj_IPAddr) \n";46

47 @Tab_System = snmpwalk ($community.$Object,$Msystem);48

49 if (defined($Tab_System[0]) ) {50 $ObjIsSNMP = 1;51

52 foreach $Line (@Tab_System) {53 next if ($Line =~ /^9/);54 $Line =~ s/\r\n/−−/g;55 $Clef = substr $Line, 0,3;56 $Data = substr $Line, (index($Line,’:’)57 $Data =~s/^://;58 $Data =~s/’/_/;59 $System{$Clef} = $Data ;60 }61 Debug ( " Sys Descr = $System{$M_sysDescr } \n");62 Debug ( " Sys Obj ID = $System{$M_sysObjectID } \n");63 Debug ( " Sys Up Time = $System{$M_sysUpTime } \n");64 Debug ( " Sys Contact = $System{$M_sysContact } \n");65 Debug ( " Sys Name = $System{$M_sysName } \n");66 Debug ( " Sys Location= $System{$M_sysLocation } \n");67

68 if ( ($System{$M_sysObjectID} =~/685$/ ) || ($System{$M_sysObjectID}=~/626$/ ) ) { $ObjIsAP = 1; }

69 if ( $ObjIsAP ) { $CiscoChassisModel = $CiscoceAssetTag; } # AP70 if ($System{$M_sysObjectID} =~/626/ ) { $CiscoChassisModel =

$CiscoceAssetOrderablePartN; }71 $TabChassisModel = snmpget($community.$Object,$CiscoChassisModel);72 if( (defined ($TabChassisModel) ) && (length($TabChassisModel) > 2 )

) {73 @Temp = split (/:/,$TabChassisModel);74 $ChassisModel = $Temp[−1];75 Debug ( " Cisco Model = $ChassisModel \n")

unless ($Mode != 1);76 }77 $TabModuleSWVersion = snmpget ($community.$Object,$CiscoImageString)

; # CW_VERSION$12.4(10b)JDA3$78 if( defined ($TabModuleSWVersion)) {79 @Temp = split (/\$/,$TabModuleSWVersion);80 $ModuleSWVersion = $Temp[−1];


81 Debug ( " Cisco SWVer = $ModuleSWVersion \n")unless ($Mode != 1);

82 }83 if ( $ObjIsAP ) { $CiscoChassisSN = $CiscoceAssetSerialNumber; }84 if ($System{$M_sysObjectID} =~/626/ ) { $CiscoChassisSN =

$CiscoceAssetSerialNumber4948 ; }85 $TabChassisSN = snmpget($community.$Object,$CiscoChassisSN);86 if( ( defined ($TabChassisSN)) && (length($TabChassisSN) > 2 ) ) {87 @Temp = split (/:/,$TabChassisSN);88 $ChassisSN = $Temp[−1];89 Debug ( " Cisco SN = $ChassisSN \n")

unless ($Mode != 1);90 }91 } else {92 next OBJECT;93 }94 $community = $Community = " Unknown ;95 }

Le résultat de l'exécution de ce programme, écrit pour un a�chage WEB (CGI),est le suivant :

Figure 5.12 � Résultat du programme PERL collectant ces 1eres informations

5.2.2 Baseline monitoring

Certaines des missions du NOC énoncées au paragraphe 4.1 en page 29 tellesque :

� Superviser les équipements du réseau a�n de garantir qu'aucune pannen'est due à un équipement ayant atteint ses limites de performances ;

� Fournir ou être capable de fournir des rapports compréhensibles quisynthétisent ce qui se passe sur le réseau.

nécessitent d'une part de réaliser des mesures de certains paramètres (nous ver-rons lesquels par la suite) et aussi de disposer des résultats de ces mesures


dans le passé, a�n de connaître les tendances de variations et savoir si les va-leurs actuelles sont � normales � ou nécessitent une intervention. Le BaselineMonitoring nous permet de dé�nir, par comparaison avec les mesures passées,comment il y a lieu de réagir par rapport aux valeurs des mesures qui viennentd'être e�ectuées.Une représentation graphique de ces valeurs facilite grandement l'interprétationdes mesures et la prise de décision. MRTG est excellent pour réaliser de telsgraphes (voir la �gure 5.13 en page 51.

Figure 5.13 � Exemple de Baseline Monitoring


Variables

Les variables pour lesquelles il me semble indispensable de disposer d'un BaselineMonitoring sont :

� Débit entrant et sortant sur les liens WAN et les liens entre Switchs ;

� Charge CPU et utilisation mémoires (CPU et I/O) des équipements su-pervisés.

Sur la partie détaillée du réseau pris en exemple (voir la �gure 5.14 en page 52), en ce qui concerne les débits, il y a déjà 20 liens/interfaces à mesurer dans les2 directions et 12 équipements à mesurer en ce qui concerne la charge CPU etl'utilisation mémoire (en admettant que votre fournisseur vous donne un accèsSNMP � même si ce n'est qu'en lecture seule � à ses équipements).

Figure 5.14 � Paramètres minima à mesurer

Le nombre d'erreurs sur les liens pour lesquels une mesure de débit est e�ectuéeainsi que les latences entre le Centre de Calcul et les routeurs des di�érentes�liales sont des mesures supplémentaires très utiles aussi pour le dépannage.


Best Practice

Au minimum il convient d'avoir un Baseline Monitoring pour :

Débits : Les débits entrant et sortant sur les liens WAN et les liensentre Switchs ;CPU - Memory : La charge CPU et l'utilisation mémoire des équipe-ments dont vous avez la responsabilité.

Si possible il convient d'avoir un Baseline Monitoring pour :

Erreurs : Les taux d'erreurs sur les liens dont vous mesurez les débits ;Latence : La latence entre des points révélateurs de la santé du réseau.

ifInOctets - ifOutOctets - CPU - Errors

Le lien précédemment cité nous permet de trouver les MIBs suivantes :.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifInOctets ou1.3.6.1.2.1.2.2.1.10, qui donnent accès au nombre total d'octets reçus via uneinterface (voir la �gure 5.15 en page 53).

Figure 5.15 � MIB ifInOctets : Nombre d'octets reçus

ainsi que.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifOutOctets ou1.3.6.1.2.1.2.2.1.16, qui donnent accès au nombre total d'octets émis par uneinterface (voir la �gure 5.16 en page 54).

CPU : La mesure de la charge CPU des équipements est une tâche relativementnon aisée qui dépend de vos équipements, de la version logicielle dont ils sont


Figure 5.16 � MIB ifOutOctets : Nombre d'octets émis

munis.Je recommande d'utiliser dans la mesure du possible, pour la mesure de la chargeCPU, ce qui suit, a savoir :.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt. ciscoProcessMIB. ci-

scoProcessMIBObjects.cpmCPU ou 1.3.6.1.4.1.9.9.109.1.1.1.1.8 décrit ci-après (voir la �gure 5.17 en page 54).

Figure 5.17 � MIB cpmCPUTotal5minRev : Utilisation CPU

Erreurs en entrée : La MIB .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.

ifEntry. ifInErrors ou .1.3.6.1.2.1.2.2.1.14 donne accès au compteur d'erreurs


en entrée telle que décrit ci-après (voir la �gure 5.18 en page 55).

Erreurs en sortie : La MIB .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.

Figure 5.18 � MIB ifInErrors : Erreurs en entrée

ifEntry. ifOutErrors ou .1.3.6.1.2.1.2.2.1.20 donne accès au compteur d'erreursen sortie telle que décrit ci-après (voir la �gure 5.19 en page 55).

Figure 5.19 � MIB ifOutErrors : Erreurs en Sorties

Il peut être judicieux par la suite de grouper toutes les informations concernantune �liale sur un même rapport permettant une analyse extrêmement rapide encas de problème. La mise à disposition, en temps (quasi) réel de ces graphes


sur un Intranet est un gage de transparence vis-à-vis des utilisateurs et dumanagement.Tout changement dans l'enveloppe d'une des courbes représentées devra immé-diatement être analysée et il devra être trouver une explication à ce changement.Un exemple d'un tel Intranet peut ête trouvé �gure 5.20 page 56.

Figure 5.20 � Intranet groupant des informations

5.3 Compteurs

Parmi les variables qu'il convient de collecter, les compteurs occupent une placede choix. Il est indispensable de � compter � si l'on veut :

� Superviser les performances : erreurs, utilisation/activité ;

� Dépanner ;

� Plani�er ;

� Facturer.Il convient de bien comprendre ce que sont ces compteurs, pourquoi et en quoiils di�èrent des compteurs accessibles par CLI.

5.3. COMPTEURS 57

5.3.1 Compteurs CLI

Un compteur CLI compte des variables dé�nies par le constructeur de l'équi-pement, les valeurs de ces compteurs sont formatées pour être compréhensiblesdirectement.Leur remise à zéro est possible.

Exemple :sho int Gi1/0/1GigabitEthernet1/0/1 is up, line protocol is up (connected)Hardware is Gigabit Ethernet, address is 001f.6d95.b481 (bia 001f.6d95.b481)Description : mgtr12 Gi 6/2MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,reliability 255/255, txload 3/255, rxload 1/255Encapsulation ARPA, loopback not setKeepalive not setFull-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX SFPMedia-type configured as connectorinput flow-control is off, output flow-control is unsupportedARP type : ARPA, ARP Timeout 04 :00 :00Last input 00 :00 :22, output 00 :00 :00, output hang never

Last clearing of "show interface" counters 1y8w

Input queue : 0/75/0/0 (size/max/drops/flushes); Total output drops : 0Queueing strategy : fifoOutput queue : 0/40 (size/max)

5 minute input rate 4354000 bits/sec, 1787 packets/sec

5 minute output rate 12249000 bits/sec, 2072 packets/sec

96050693536 packets input, 29405454519098 bytes, 0 no buffer

Received 13102931 broadcasts (0 multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 13102931 multicast, 0 pause input

0 input packets with dribble condition detected

101782763426 packets output, 67509726107120 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

0 output buffer failures, 0 output buffers swapped out

sho int Gi1/0/1 counters?errors Show interface error countersetherchannel Show interface etherchannel countersprotocol interface protocol counterstrunk Show interface trunk counters| Output modifiers<cr>

sho int Gi1/0/1 counters errors

Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSizeGi1/0/1 0 0 0 0 0

Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants

Gi1/0/1 0 0 0 0 0 0 0


5.3.2 Compteurs SNMP

Les compteurs SNMP ont une dé�nition standardisée (par l'IETF, par l'IEEE,par certains constructeurs).Ils sont indépendants de type d'équipement et/ou du constructeur et ont unetaille spéci�ée (compteurs 32 bits ou 64 bits pour SNMP v2c ou v3).

A remarquer :Ces compteurs ne s'initialisent pas systématiquement à zéro.Ils sont dotés � le plus souvent � d'un indicateur de validité (discontinuity).Ne pas oublier que les requêtes SNMP incrémentent aussi certains compteurs.

La �gure 5.21 page 58 en est un exemple :

Figure 5.21 � Exemple de dé�nition de compteur

Si des mesures précises de temps entre polling sont nécessaires, il est préférabled'utiliser la variable sysUpTime de l'équipement lui-même, plutôt qu'un tempsdé�ni par la station de management, a�n d'éviter les dérives de temps de transit(Gigue).L'exemple représenté par la �gure 5.22 en page 59 montre que, même si lestemps d'émission de requête par la station de management sont dé�nis avecune extrême précision, l'arrivée de la requête sur l'équipement lui-même, puisl'arrivée de la réponse à la station de management sont entachés de la gigue dueau réseau.


Figure 5.22 � Dérives de temps de transit

5.3.3 � Bouclage des compteurs �

Un compteur SNMP étant de taille �xe (32 ou 64 bits), quand la valeur decelui-ci est de 2taille−1, une incrémentation de celui-ci le fait passer à zéro.

La durée nécessaire à ce bouclage peut être un paramètre déterminant lapériode de polling :

Interface Compteur 32 bits Compteur 64 bits10 Mb/s env. 3436s soient 57,26 min.100 Mb/s env. 343s soient 5,72 min.1000 Mb/s env. 34s env. 4680 ans1 Tb/s env. 4,6 ans

Poller un compteur 32 bits relatif à une interface à 1 Gb/s à une période supé-rieure à 34 secondes peut conduire à une lecture erronée de variables.


La supervision des variables mentionnées dans ce chapitre doit être considéréecomme un minimum. Il ne faut pas non plus tomber dans l'excès inverseet croire que le meilleur outil de supervision est celui qui supervise le plusde variables, qui collecte le maximum d'informations, qui produit le plus derapport, avec de belles couleurs et le logo de votre entreprise en haut à gauche,ou à droite, ou au milieu.

Il est de la responsabilité du NOC, en fonction des SLA sur lesquels ils'est engagé, de dé�nir les paramètres et les variables à superviser, de mêmeque la façon de détecter et de signaler un problème ou une défaillance.

Là encore la connaissance du réseau et de ce qu'il transporte est primor-diale. En e�et, si le réseau transporte principalement de la voix ou de la vidéo,


des mesures de gigue et de latences peuvent s'avérer indispensables, si la QoS(Quality of Service) est mise en oe uvre sur le réseau, des mesures de tra�c parclasse de service pourront être les bienvenues, si les SLA dé�nissent une valeurspour les latences ou classe de service.

Quatrième partie

SNMP et l'indexation

61

Chapitre 6

SNMP et l'indexation

La collecte des premières valeurs e�ectuée au paragraphe 5.2.1 Inventaireen page 42 est simple et ne pose pas de di�culté particulière, ni d'accèsni d'interprétation. Ces valeurs sont uniques pour l'équipement réseau. (Onsupposera cela vrai à ce stade du document).

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

63

64 CHAPITRE 6. SNMP ET L'INDEXATION

6.1 Indexation simple

Sur un équipement réseau, la plupart des variables qu'il est possible dechercher par SNMP ne sont pas uniques et existent pour toutes les interfacesde l'équipement. Par exemple l'Administrative Status (l'interface est-elle enmode shutdown ou non), ou le In Octets (le nombre d'octets reçus par lecette interface) sont des variables qui sont dé�nies et maintenues à jour à toutmoment et pour chaque interface.Si nous voulons savoir, sur notre switch nommé mgth03, si le port 3 de ce switchest en mode shutdown ou non, et combien d'octets ont été reçus, il faut savoir� comment � poser cette question, c'est-à-dire quelles variables rechercher surle switch.L'utilisation précédente de Getif, ou une connaissance des MIBs, nous a révélél'existence des 2 MIBS :.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifAdminStatus ou(1.3.6.1.2.1.2.2.1.7 ) et.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifInOctets ou(1.3.6.1.2.1.2.2.1.10 ), or une requête sur cette dernière donne le résultatreprésenté par la �gure 6.1 en page 64 :

Figure 6.1 � Indexation simple

Comment interpréter ces valeurs et comment savoir laquelle est relative àl'interface qui nous concerne, à savoir l'interface FastEthernet0/3 ?

Pour interpréter ces valeurs, il faut savoir que la plupart des variableslues sont indexées, ce qui revient à dire qu'elles se rapportent à un Index .L'interprétation des valeurs présentées dans le tableau précédent est :

6.1. INDEXATION SIMPLE 65

1ere ligne : Le nombre d'octet reçus par l'interface dont l' Index est 1est 15902182eme ligne : Le nombre d'octet reçus par l'interface dont l' Index est 2 est1730096653Etc

La lecture de l'Administrative Status nous retourne un tableau construitde la même manière.Si nous parvenons à savoir quel Index est à utiliser pour référencer l'interfaceFastEthernet0/3 qui nous préoccupe, il nous sera possible d'accéder auxinformations qui nous intéressent.

C'est le rôle de la MIB .iso.org.dod.internet.mgmt.mib-

2.interfaces.ifTable.ifEntry.ifDescr qui nous apprend que l'Index 10003a pour description FastEthernet0/3. (voir la �gure 6.2 en page 65) (En touterigueur il faudrait aussi utiliser la MIB .iso.org.dod.internet.mgmt.mib-

2.interfaces.ifTable.ifEntry.ifIndex, ce que nous omettrons de faire ici).

Attention : Cette MIB retourne la description des interfaces, au sensdu constructeur de l'équipement réseau et non la description qui est laisséelibre à l'utilisateur lors de la con�guration des interfaces. Cette dernière estretournée par l'OID : 1.3.6.1.2.1.31.1.1.1.18.

Figure 6.2 � MIB ifDescr

A ce stade, nous pouvons interroger le switch :� soit par snmpget, en précisant l'Index qui nous intéresse, auquel cas

une et une seule valeur nous sera retournée :


snmpget -c MyCommunity mgth03 .1.3.6.1.2.1.2.2.1.10.10003

.1.3.6.1.2.1.2.2.1.10.10003 = Counter32 : 250150566

� soit par snmpwalk, qui nous retournera l'ensemble des valeurs pourtoutes les interfaces et nous ne retiendrons que la valeur de l'Index quinous préoccupe (1003) :

snmpwalk -c MyCommunity mgth03 .1.3.6.1.2.1.2.2.1.10.1.3.6.1.2.1.2.2.1.10.1 = Counter32 : 1590218.1.3.6.1.2.1.2.2.1.10.233 = Counter32 : 1730231211.1.3.6.1.2.1.2.2.1.10.10001 = Counter32 : 3986327821.1.3.6.1.2.1.2.2.1.10.10002 = Counter32 : 100772179.1.3.6.1.2.1.2.2.1.10.10003 = Counter32 : 250150566.1.3.6.1.2.1.2.2.1.10.10004 = Counter32 : 8751578.1.3.6.1.2.1.2.2.1.10.10005 = Counter32 : 154427692.1.3.6.1.2.1.2.2.1.10.10006 = Counter32 : 4074811.1.3.6.1.2.1.2.2.1.10.10007 = Counter32 : 0.1.3.6.1.2.1.2.2.1.10.10008 = Counter32 : 177800811.1.3.6.1.2.1.2.2.1.10.10009 = Counter32 : 0.1.3.6.1.2.1.2.2.1.10.10010 = Counter32 : 0.1.3.6.1.2.1.2.2.1.10.10011 = Counter32 : 0.1.3.6.1.2.1.2.2.1.10.10012 = Counter32 : 0.1.3.6.1.2.1.2.2.1.10.10013 = Counter32 : 0.1.3.6.1.2.1.2.2.1.10.10014 = Counter32 : 0.1.3.6.1.2.1.2.2.1.10.10015 = Counter32 : 80746.1.3.6.1.2.1.2.2.1.10.10016 = Counter32 : 0.1.3.6.1.2.1.2.2.1.10.10017 = Counter32 : 0.1.3.6.1.2.1.2.2.1.10.10018 = Counter32 : 0.1.3.6.1.2.1.2.2.1.10.10019 = Counter32 : 0.1.3.6.1.2.1.2.2.1.10.10020 = Counter32 : 18954372.1.3.6.1.2.1.2.2.1.10.10021 = Counter32 : 735926285.1.3.6.1.2.1.2.2.1.10.10022 = Counter32 : 2937745282.1.3.6.1.2.1.2.2.1.10.10023 = Counter32 : 1430939777.1.3.6.1.2.1.2.2.1.10.10024 = Counter32 : 0.1.3.6.1.2.1.2.2.1.10.10101 = Counter32 : 201373754.1.3.6.1.2.1.2.2.1.10.10102 = Counter32 : 0.1.3.6.1.2.1.2.2.1.10.10501 = Counter32 : 0

Et en�n répéter ces requêtes pour l'Administrative Status.

En résumé quand une MIB retourne des variables indexées, elle doitaussi permettre la lecture d'une OIDs qui permet l'association entrel'Index et une variable de degré d'abstraction moindre (ici une interfacecar nous sommes au niveau interface : .iso.org.dod.internet.mgmt.mib-

6.1. INDEXATION SIMPLE 67

2. interfaces .ifTable.ifEntry.ifIndex ). Cet Index reste constant (heureuse-ment) dans cette branche de la MIB.Attention : la persistance dans le temps n'est pas garantie en cas de redémar-rage de l'équipement ou en cas de modi�cation matérielle : ajout/suppressiond'interface

Ceci peut être représenté de la sorte (voir la �gure 6.3 page 67) :

Figure 6.3 � Schématisation de l'indexation

A noter : les ifIndex ne sont pas tenus d'être éternellement relatifs à uneinterface/un port donné. La seule règle prévalant est qu'un ifIndex ne peut êtreré-attribué à une autre interface, un autre port, sans interruption du sysUpTime.Depuis la version IOS 12.1(5)T, datant de 2005, il existe une commande sur leséquipements Cisco permettant de �ger cette relation par-delà les reboot :

snmp-server ifindex persist

Cette commande évite d'avoir à corréler régulièrement les Index aux interfaces,pour s'assurer que les variables collectées se réfèrent bien à l'interface supervisée.

Quelques situations modi�ent toutefois relation ifIndex <=> Interface :� ajout/suppression d'interface physique ;

� adressage d'interface.

� . . .Pour l'interface de management du switch mgth03 � exemple pris car elle estdotée d'une adresse IP � et pour le port � Fa0/1 � doté d'une Description (ausens Cisco IOS) ces informations sont stockées de la sorte dans Jmon (voir�gure 6.4 en page 68) :


Figure 6.4 � Table ITF de Jmon

6.2 Indexation multiple

Comme nous venons de le voir, le principe d'indexation permet de spéci�erpour quelle interface, par le biais de l'index, se rapporte une valeur lue dansune table de valeurs.

6.2. INDEXATION MULTIPLE 69

Il est donc possible par ex. de lire la table du nombre d'octets émis pour toutesles interfaces de l'équipement interrogé puis d'a�ecter grâce à l'index chaqueligne de cette table à une interface de l'équipement, car pour cette table, l'indexse rapporte une interface.

Certaines valeurs qu'il peut être intéressant de lire se rapportent à plusd'un paramètre.Le cas typique est la table des adresses MAC , une adresse MAC est caracté-risée par l'interface sur laquelle elle est lue et le VLAN dans laquelle elle est vue.

Exemple : Soit un switch con�guré pour la voix sur IP, avec des télé-phones VoIP, transportant la voix sur le vlan 827 et les données sur le vlan 134.Un appareil est connecté au switch intégré du téléphone selon la �gure suivante(voir �gure 6.5 en page 69) :

Figure 6.5 � Switch port pour voix sur IP

Le port 12 de ce switch est con�guré de la sorte :

interface FastEthernet0/12switchport trunk encapsulation dot1qswitchport trunk native vlan 134switchport trunk allowed vlan 134,827switchport mode trunkspeed 100duplex full

La consultation de la table MAC pour le port 12 de ce switch nous donne :


mgth03#sho mac-address-table | incl 0/12134 0015.c5a5.35ca DYNAMIC Fa0/12134 0080.9f62.654f DYNAMIC Fa0/12827 0080.9f62.654f DYNAMIC Fa0/12

Le téléphone est vu dans les 2 VLANs : tant que le MAC Aging Timer ne s'estpas écoulé, puis cette adresse MAC ne sera plus connue que pour le VLAN 827.L'appareil est vu dans le VLAN 134.

Par SNMP il doit être possible de retrouver ces mêmes informations :� Une indexation par interfaces (� Toutes les adresses MAC pour toutes les

interfaces �) nous retournerait toutes les adresses MAC, mais impossiblede lier ce couple [adresse MAC, Interface] à un VLAN.

� Une indexation par VLAN (� Toutes les adresses MAC pour tous lesVLANs �) nous retournerait toutes les adresses MAC, mais impossiblede lier ce couple [adresse MAC, VLAN] à une Interface.

La solution mise en ÷uvre par SNMP consiste en une deuxième indexation quipermet de demander � Toutes les adresses MAC pour toutes les interfaces, pourun VLAN donné �.La façon de transmettre cette deuxième indexation est d'adjoindre cet index àla community string, en le précédant du signe @.Ex : soit la community string � public �, une requête concernant le VLAN 134serait transmise en utilisant la community string � public@134 �.

Un exemple détaillé est donné en annexe

Cinquième partie

Quelques chi�res et calculs

élémentaires

71

Chapitre 7

Quelques chi�res et calculs

élémentaires

Dans le chapitre qui suit , nous considérerons un réseau de taille moyenne consti-tué de près de 700 switchs (presque exclusivement des switchs à 48 ports), desrouteurs, de 1750 access-points non gérés par un contrôleur, et de divers autreséquipements dont la surveillance incombe au NOC (IPT, etc), répartis géo-graphiquement sur 60 �liales, chacune adressée dans un sous réseau di�érent(Masque réseau 255.255.0.0), et dans chacune de ces �liales, une vingtaine deVLANs partagent logiquement le sous réseau assigné à cette �liale.Ce réseau se résume comme suit (vu depuis l'outil Jmon �gure 7.1 page 73 ) :

Figure 7.1 � Taille d'un réseau moyen vu par l'outil Jmon

Soient :2938 équipements à superviser. Ces équipement représentent 68413 interfacesen tout, dont 10252 sont des interfaces dotées d'une adresse IP.Dans sa con�guration actuelle Jmon supervise tous ces équipements, 44291interfaces de ceux-ci, dont 9405 interfaces dotées d'une adresse IP.

Ce réseau inter-connecte 15792 éléments et équipements.

73

74CHAPITRE 7. QUELQUES CHIFFRES ET CALCULS ÉLÉMENTAIRES

Le dimensionnement du réseau permet de dé�nir certains paramètresfondamentaux de la supervision de réseau, tels que ceux abordés dans lesparagraphes suivants.

7.1 Polling

La détermination de la période d'interrogation � polling � des informationsSNMP est un paramètre important dont la valeur relève beaucoup plus de bonsens et d'expérience que de savantes formules. Dans une première approche ilpeut être tentant d'interroger les équipements aussi souvent que possible, a�nd'être en possession des informations les plus à jour possible et de d'interrogerun maximum, sinon toutes les interfaces � au sens � Cisco � �, cela peuttoujours être utile. . .

Cette approche, impacte immédiatement :� L'utilisation de la bande passante disponible. Il serait regrettable que

l'onéreux réseau dont vous avez la responsabilité opérationnelle ne serve�nalement qu'à transporter des données destinées à se superviser lui-même, au détriment des données � utiles �. L'overhead due à la super-vision doit rester dans un domaine acceptable, utilisant quelques pour-cents au maximum de la bande passante. La consommation de la bandepassante par SNMP est un paramètre qu'il est toujours intéressant desurveiller, certains outils commerciaux sont générateurs de tra�c SNMPintense (Cisco Works, Cisco WLSE,. . .)

� 2. Les équipements supervisés eux-mêmes. Là encore, les équipementsmis en ÷uvre n'ont pas pour fonction première d'être supervisés, maisassurent une fonction au sein du réseau. Les requêtes SNMP sont assezgourmandes en ressource CPU, même si au niveau du système d'exploi-tation de ces équipements, la gestion des requêtes SNMP est une tachede bas niveau ayant une priorité d'exécution faible.

� 3. La station de management elle-même devra être dotée de processeurspuissants et de beaucoup d'espace de stockage et d'une (ou plusieurs)interface(s) réseau performante(s). Ce point ci, avec les machinesdisponibles actuellement n'est plus réellement un problème.

Nous avons vu au paragraphe 5.2.1 Inventaire en page 42, que certainesvariables peuvent être lues à une période relativement grande de l'ordre de 12h,car presque statiques.

Les informations de � présence �, l'équipement répond (ping), sont géné-ralement collectés toutes les 5 minutes pour des éléments standards du réseautels que switchs, routeurs, access-points. Il est parfois souhaité de détecter plusrapidement la défaillance de certains éléments critiques au fonctionnement duréseau, dont on peut alors tester la présence à une période pouvant aller jusqu'à

7.2. TIMEOUT ET RETRIES 75

quelques secondes.

La collecte des informations requises pour le Base Line monitoring estgénéralement aussi e�ectuée avec une résolution de 5 minutes. La période depolling détermine ici e�ectivement la résolution, car si l'on sait par exemplequ'entre t0 et t0+5 par une interface donnée, 100 kbit sont passés, il estimpossible de savoir avec plus de détails � comment � ces 100 kbits sont passés.La seule chose que l'on sache est qu'entre t0 et t0+5 100 kbits sont passés. Unmeilleur pro�l de tra�c n'est pas décidable.

Il est important de conserver ceci en mémoire dans le cas où le certainesactions doivent être entreprises en cas de dépassement de seuils.

Dans l'exemple ci-après (�gure 7.2 page 75), si une action doit être dé-clenchée à partir de 50 kbits par minute, il est évident qu'une période de pollingde 5 minutes est inadéquate pour détecter ce dépassement de seuil, car elle nedétectera pas le dépassement de seuil ayant eu lieu à la minute t0+3.

Figure 7.2 � Période de polling et pro�l de tra�c

7.2 Timeout et retries

Dans notre exemple, le réseau est constitué de 2838 équipements et 9405adresses IP.Ces équipements sont, de toute évidence, d'une part testés pour leur accessibi-lité (ping ICMP ou UDP echo) et d'autre part accédés via SNMP.

Il est relativement aisé de dé�nir une approximation même grossière du


temps de transit d'un paquet à l'aide d'outil simple, tels que la commande pingpar exemple :

ping zler02PING zler02 (10.185.2.2) 56(84) bytes of data.64 bytes from zler02 (10.185.2.2) : icmp_seq=1 ttl=249 time=15.6 ms64 bytes from zler02 (10.185.2.2) : icmp_seq=2 ttl=249 time=14.3 ms64 bytes from zler02 (10.185.2.2) : icmp_seq=3 ttl=249 time=24.8 ms64 bytes from zler02 (10.185.2.2) : icmp_seq=4 ttl=249 time=14.7 ms64 bytes from zler02 (10.185.2.2) : icmp_seq=5 ttl=249 time=14.8 ms64 bytes from zler02 (10.185.2.2) : icmp_seq=6 ttl=249 time=14.7 ms64 bytes from zler02 (10.185.2.2) : icmp_seq=7 ttl=249 time=15.1 ms64 bytes from zler02 (10.185.2.2) : icmp_seq=8 ttl=249 time=15.6 msC-- zler02 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7300ms

rtt min/ avg /max/mdev = 14.386/ 16.258 /24.815/3.263 ms

Soient environ 16 ms dans cet exemple.

Il convient de ne pas oublier que certains équipements peuvent être dé-fectueux, auquel cas l'état � défectueux � met beaucoup plus de temps à êtreétabli que l'état � en ordre � car au lieu d'obtenir la réponse en environ 16 ms,le requête SNMP par exemple va attendre un timeout généralement �xé à 2secondes, et être réitérée un nombre de fois dé�ni par le paramètre retriesgénéralement �xé à trois ou quatre.

Dans l'exemple de la �gure 3.13 page 76, une requête est issue avec uneCommunity String inadéquate, pour illustrer une non-réponse à une requêteSNMP, simulant un équipement défectueux.

Le test d'accessibilité à l'équipement (ligne 1 et 2) est assuré en environ15 ms.L'échec de la requête SNMP n'est établi qu'après huit secondes (colonne� Time � durée entre les lignes 3 et 7 : 15 :28 :55 - 15 :28 :47).

Figure 7.3 � Trace Wireshark du timeout et retries sur une requête SNMP

Le récapitulatif (�gure 7.4 page 77) con�rme ces mesures.

Cette requête appliquée à tous les 2938 équipements du réseau pris en exempledure :

� Dans le cas où tous les équipements répondent à cette Community String :

7.2. TIMEOUT ET RETRIES 77

Figure 7.4 � Timeout et retry sur une requête SNMP - Récapitulatif

2938 x (14 + 14) ms = 82,264 secondes, soit moins d'une minute et demie ;

� Dans le cas où tous les équipements ne répondent pas à cette CommunityString : 2938 x 8 s = 23504 secondes, soient plus de six heures et demie ;

� Avec 1% d'équipement ne répondant pas à cette Community String (30équipements), cette requête dure environ 5 minutes et demie.

Ces valeurs sont des valeurs extrêmes applicables lorsque l'exécution de cesrequêtes est purement séquentielle. Il est bien sur possible de paralléliser grâceaux threads l'exécution de ces requêtes.

La connaissance de ces valeurs et de la stabilité du réseau (nombre d'équipe-ments défectueux en moyenne, durée et fréquence des interruptions réseau)permet de déterminer une période de polling appropriée.

Il serait tentant de diminuer les valeurs des paramètres timeout et re-

tries. Ceci peut être envisagé si le comportement du réseau est bien connuet maitrisé. Dans le cas d'un réseau international, à longue distance (liaisonsatellites p.ex.), ces valeurs seront ajustées à la hausse.

Ne pas oublier ici que SNMP repose sur UDP.

Best Practices :Un timeout de 2 secondes et une valeur de 3 pour les retries sont recom-mandés pour un réseau national occidental.


7.3 Collecte d'informations

Prenons l'exemple d'un outil de supervision de ce réseau nécessitant pour chacundes équipements supervisés, les informations suivantes a�n de représenter l'étatde ces équipements :

� Description de l'interface ;

� Alias de l'interface ;

� Administrative status de l'interface ;

� Operative status de l'interface ;

� Nom de l'interface ;

� Type de l'interface ;

� Les adresses IP allouées à cet objet ;

� Les masques de réseau des adresses IP alloués ;

� Les adresses IP allouées sont-elles virtuelles (HSRP Address) ? ;

� Les adresses IP allouées sont-elles Standby Master ?Les MIBS suivantes sont utilisées :

MifIndex = "1.3.6.1.2.1.2.2.1.1";

MifDescr = "1.3.6.1.2.1.2.2.1.2";

MifAlias = "1.3.6.1.2.1.31.1.1.1.18";

MifAdStat = "1.3.6.1.2.1.2.2.1.7";

MifOpStat = "1.3.6.1.2.1.2.2.1.8";

MifName = "1.3.6.1.2.1.31.1.1.1.1";

MifType = "1.3.6.1.2.1.2.2.1.3";

MipAdEntIfIndex = "1.3.6.1.2.1.4.20.1.2";

MipAdEntNetMask = "1.3.6.1.2.1.4.20.1.3";

CiscoMIbcHsrpGrpVirtualIpAddr = ".1.3.6.1.4.1.9.9.106.1.2.1.1.11";

CiscoMIbcHsrpGrpStandbyState = ".1.3.6.1.4.1.9.9.106.1.2.1.1.15";

Toutes les requêtes sont réalisées de la sorte :

@Tab_XYZ = snmpwalk ($community.$Object,$XYZ);

7.3.1 Alias

L'obtention des Alias sera l'exemple pris dans ce qui suit.Soit un switch con�guré avec quelques VLANs dont la Description (Alias),nous est de quelque intérêt. Ces VLANs sont con�gurés de la sorte :

7.3. COLLECTE D'INFORMATIONS 79

interface Vlan1

no ip address

shutdown

!

interface Vlan300

description Management

ip address ...

!

interface Vlan303

description FW Services

ip address ...

!

interface Vlan304

description WAN Access Transfert

ip address ...

!

interface Vlan308

description Data

ip address ...

!

interface Vlan309

description IPT

ip address ...

!

interface Vlan310

description tata

ip address ...

!

interface Vlan320

description toto

ip address ...

!

interface Vlan321

description tutu

ip address ...

!

...

L'obtention des Alias est réalisée par une requête snmpwalk envers l'OID1.3.6.1.2.1.31.1.1.1.18 (ifAlias).Le résultat de la requête est :


$ snmpwalk -c MyCS MyObject 1.3.6.1.2.1.31.1.1.1.18

.1.3.6.1.2.1.31.1.1.1.18.1 = STRING :

.1.3.6.1.2.1.31.1.1.1.18.300 = STRING : Management

.1.3.6.1.2.1.31.1.1.1.18.303 = STRING : FW Services

.1.3.6.1.2.1.31.1.1.1.18.304 = STRING : WAN Access Transfert

.1.3.6.1.2.1.31.1.1.1.18.308 = STRING : Data

.1.3.6.1.2.1.31.1.1.1.18.309 = STRING : IPT

.1.3.6.1.2.1.31.1.1.1.18.310 = STRING : tata

L'analyse des paquets échangés entre la station de management et l'objet in-terrogé, telle que représentée par la �gure 7.5 en page 80, nous indique que larequête commence par un GetNextRequest-PDU (ligne 189).Cette première requête demande à l'objet, ainsi que nous l'avons vu au chapitre3.2.3 en page 16, de retourner le prochain objet (variable) dans l'ordre lexical .Cela est logique car il est demandé par snmpwalk de parcourir une branche sansen connaitre les index.

Figure 7.5 � Trace Wireshark de la requête de tous les alias par snmpwalk

La réponse parvient par un GetResponse-PDU qui nous indique que la pro-chaine (la première dans ce cas) variable est d'index 1 : 1.3.6.1.2.1.31.1.1.1.18.1(ligne 190).Le prochain GetNextRequest-PDU est en conséquence envers cet index :1.3.6.1.2.1.31.1.1.1.18.1 qui répond par 1.3.6.1.2.1.31.1.1.1.18.300 etc etc...

L'obtention de toutes les informations requises dure 7,7 secondes, 878paquets et 88170 octets sont échangés, soient 114 paquets par seconde pour despaquets de taille moyenne de 100 octets (Figure 7.6 en page 81).

7.3.2 SNMP V2c et Getbulk

Avec le changement suivant,$Equipement = $Equipement." : : : : :2";


Figure 7.6 � Traces Wireshark de la requête des Alias - Récapitulatif

le module PERL mis en ÷uvre (SNMP_util.pl) va utiliser SNMP-V2c etGetBulk pour obtenir les variables.Les requêtes sont réalisées de la sorte :@Tab_XYZ = snmpwalk ($community.$Equipement,$XYZ);

L'analyse des paquets échangés entre la station de management et l'objet in-terrogé, telle que représentée par la �gure 7.7 en page 82, nous indique quela requête commence par un getbulkrequest (ligne 27 colonne Info) envers1.3.6.1.2.1.31.1.1.1.18.Cette requête peut être vue, dans un premier temps, comme une requête pourun � bloc � de variables, sans entrer dans les détails de la dé�nition de ce bloc.La réponse parvient par un GetResponse-PDU (ligne 28) qui retourne laliste des OIDs suivantes :

1.3.6.1.2.1.31.1.1.1.18.1,1.3.6.1.2.1.31.1.1.1.18.3001.3.6.1.2.1.31.1.1.1.18.3031.3.6.1.2.1.31.1.1.1.18.3041.3.6.1.2.1.31.1.1.1.18.3081.3.6.1.2.1.31.1.1.1.18.3091.3.6.1.2.1.31.1.1.1.18.3101.3.6.1.2.1.31.1.1.1.18.3201.3.6.1.2.1.31.1.1.1.18.3211.3.6.1.2.1.31.1.1.1.18.3221.3.6.1.2.1.31.1.1.1.18.323


Figure 7.7 � Trace Wireshark de la requête de tous les alias par GetBulk

1.3.6.1.2.1.31.1.1.1.18.330

soient 12 valeurs retournées dans la VarBindList .Cette liste est détaillée dans la fenêtre inférieure de l'outil Wireshark , fenêtred'analyse de la trame : variable-bindings : 12 items..La taille du paquet de réponse est de 428 octets (ligne 28, colonne Packet length)

Il convient de préciser ici que les 12 valeurs retournées correspondent àla valeur par défaut du paramètre Max-repetitions de l'implémentation deGetBulk utilisée.

Le second getbulkrequest (ligne 29) est envers 1.3.6.1.2.1.31.1.1.1.18.330 (ladernière valeur retournée par la requête précédente) auquel est répondu (ligne30) par 12 objets retournés dans la VarBindList , de 1.3.6.1.2.1.31.1.1.1.18.331à 5001 (331, 332, 800, 804, 826, 849, 850, 851, 853, 854, 857, 5001).

Le troisième getbulkrequest (ligne 31) est envers 1.3.6.1.2.1.31.1.1.1.18.5001 (ladernière valeur retournée par la requête précédente) auquel est répondu (ligne32) par 12 objets retournés dans laVarBindList , de 1.3.6.1.2.1.31.1.1.1.18.5013à 10111 (5013, 10101, 10102, 10103, 10104, 10105, 10106, 10107, 10108, 10109,10110, 10111).

Comment s'arrêter si le nombre d'objets n'est pas un multiple des 12 re-quis par le paramètre Max-repetitions ce qui est le cas pour cet équipement quiest doté des 38 interfaces suivants (voir �gure 7.1 en page 83) :


Table 7.1 � Les index des 38 interfaces dont les alias sont requisIndex 1 300 303 304 308 309Index 310 320 321 322 323 330Index 331 332 800 804 826 849Index 850 851 853 854 857 5001Index 5013 10101 10102 10103 10104 10105Index 10106 10107 10108 10109 10110 10111Index 10112 14504

Nous avons vu que les 3 premiers getbulkrequest nous ont retournés chacun 2des lignes du tableau ci-dessus, soient 36 des 38 interfaces.

Le quatrième getbulkrequest (ligne 33) est envers 1.3.6.1.2.1.31.1.1.1.18.10111(la dernière valeur retournée par la requête précédente) qui répondpar 12 objets retournés dans la VarBindList . Ces douze objets sont1.3.6.1.2.1.31.1.1.1.18.10112 et 14501 tels qu'attendus, puis retourne les objetspour 1.3.6.1.2.1.31.1.2.1.3.0.1 vide, 10101, 10102, 10103, 10104, 10105, 10106,10107, 10108, 10109.

Figure 7.8 � Traces Wireshark de la 4e et dernière requête des Alias par Get-Bulk

Soient bien 12 objets retournés au total : le paramètre Max-repetitions estrespecté.Mais que sont les 10 autres objets retournés ? Ne sont-ce que des informationsde � bourrage �, invalides mais juste là pour respecter Max-repetitions ?


La réponse est non.Et pourquoi cet OID 1.3.6.1.2.1.31.1.2.1.3.0.1. Est-ce le hasard ?Là encore la réponse est non. Il se trouve que 1.3.6.1.2.1.31.1.2.1.3.0 est laprochaine MIB interrogeable sur ce switch pour un parcours commencé en.1.3.6.1.2.1.31.1 (pas de réponse avant en � remontant � l'arbre des OIDs, voirla �gure 7.9 en page 84 ).

Figure 7.9 � Branche 1.3.6.1.2.1.31 sur le switch pris en exemple

L'agent SNMP de l'équipement interrogé a parcouru toute les feuilles de la� branche � 1.3.6.1.2.1.31.1.1.1.18 requises par la requête GetBulk � il a livrétoutes les informations relatives à cette � branche � � mais est contraint par leparamètre Max-repetitions de livrer 10 variables de plus.Cette agent � remonte � donc la branche sur laquelle il était, en direction dutronc, puis parcourt la première branche à sa disposition, qui dans ce cas est1.3.6.1.2.1.31.1.2.1.3.0 et parcourt le nombre de feuilles nécessaire à satisfairele paramètre Max-repetitions, bien que livrant là des informations pas du toutrequises par la station de management.On comprend aussi ici que la station de management qui emploie des requêtesGetBulk doit véri�er que les réponses obtenues sont vraiment des réponses etnon des informations de � bourrage �.

Nous venons de voir que grâce à l'utilisation de requêtes GetBulk dontle paramètre Max-repetitions est positionné à 12, 12 valeurs sont transmises enréponse à une requête unique. Il en ira de même pour toutes les autres tablesrequises, aussi il n'est pas exagérément optimiste d'espérer une division par unpeu moins que 12 (toutes les requêtes ne vont pas béné�cier de l'améliorationapportée par GetBulk), du nombre de paquets transmis.


Si avec des requêtes de type snmpwalk nous avons mesuré que 878 paquets ontété nécessaires pour transférer les informations relatives à l'ensemble des tablesprises en exemple dans ce chapitre, nous nous attendons à en mesurer environ87812 soient environ 73, de par l'utilisation de requêtes de type GetBulk . Ceciest véri�é (voir �gure 7.10 en page 85) : 94 paquets ont été mesurés.

Figure 7.10 � Traces Wireshark de la requête des Alias par GetBulk - Réca-pitulatif

De plus, toutes les informations sont obtenus en 1,1 secondes � à compareraux 7,7 secondes précédemment mesurées �, dans un échange de 94 paquets et20874 octets sont transférés, soient 86 paquets par seconde pour des paquetsd'une taille moyenne de 222 octets.

Il est apparait immédiatement que :

� Le nombre de paquets transmis est environ 9,3 fois moins important.

� Le nombre d'octets échangés pour transmettre exactement la même in-formation est divisé par environ 4,2.

� La durée requise pour transmettre la même information est divisée parenviron 7.

Au regard de cette remarquable amélioration des performances, il est plus quetentant de vouloir optimiser d'avantage, en observant que, en positionnant le


paramètre Max-repetitions à 38, non seulement le nombre de getbulkrequestsera limité à 1 � puisque nous savons qu'il n'y à qu'un Alias par interfaceet que celles-ci sont au nombre de 38 - mais en plus aucune donnée inutile� pour satisfaire un paramètre Max-repetitions non-sous-multiple du nombred'interface � ne sera transférée.

En optimisant de la sorte :@Tabl_Alias = snmpwalk($community.$JMJObject,0, 38 ,$MifAlias);

Il n'y a plus qu'une seule réponse concernant les alias, retournée dans un seulpaquet d'une taille de 1102 octets (voir le paragraphe suivant).

Cette optimisation est l'optimisation ultime qu'il est possible de réaliserconcernant la table des Alias. Celle-ci n'est possible que parce que d'une part,le nombre de varbinds à retourner est connu à priori et peut être passé en tantque paramètre Max-repetitions à la commande, et d'autre part, que pour cenombre de varbinds, la réponse est de taille à ne pas excéder la taille maximaled'un paquet.

7.3.3 Optimisation maximale

Dans ce chapitre nous tenterons d'appliquer l'optimisation apportée dans lechapitre précédent, non seulement à lecture de la table des Alias, mais à toutesles requêtes formulées et envers tous les objets supervisés, quelque soit lenombre d'interfaces dont ces objets soient pourvus.Il est clair ici que la di�culté réside dans le positionnement du paramètreMax-

repetitions.

En analysant les données à collecter (paragraphe 7.3 page 78), par l'outilde supervision il apparait que 2 groupes peuvent être formés a�n d'optimiserles requêtes GetBulk .D'une part les informations relatives aux interfaces, à savoir :

� Description de l'interface ;

� Alias de l'interface ;

� Administrative status de l'interface ;

� Operative status de l'interface ;

� Nom de l'interface ;

� Type de l'interface.Et d'autre part celles relatives aux adresses IP :

� Les adresses IP allouées à cet objet ;

� Les masques de réseau des adresses IP alloués ;

� Les adresses IP allouées sont-elles virtuelles (HSRP Address) ? ;


� Les adresses IP allouées sont-elles Standby Master ?Il y aura autant de Descriptions que d'Alias que d'Administrative status, queOperative status que de Noms, que de Types : Autant que d'interfaces.Il y aura autant d'adresses IP que de masques d'adresse, que de réponses auxquestions concernant la réalité (virtualité) et le Standby Master : Autant qued'adresses IP con�gurées sur l'objet.Il n'y a par contre aucun lien entre le nombre d'interfaces de l'objet et lenombre d'adresses IP con�gurées sur l'objet. Un switch 48 ports dispose d'aumoins 49 interfaces et une adresse IP de management (d'où les 49 interfaces :48 Ports + 1 VLAN). Un switch-routeur 12 ports disposera de 12+n interfaces,n étant le nombre d'adresses IP (VLANs) con�gurées.

L'interrogation d'un objet commencera par l'établissement de la liste desinterfaces de l'objet qui en délivrera le nombre. Ce nombre sera utilisé dans lesGetBulks suivant en tant que paramètre Max-repetitions. Une fois que toutesles informations relatives aux interfaces auront été collectées, le même principesera appliqué aux adresses IP :

1 @Tabl_Index = snmpwalk($community.$Equipement,$MifIndex); # $MifIndex= "1.3.6.1.2.1.2.2.1.1"

2 $MR = @Tabl_Index; # Max repetition

Les requêtes ultérieures relatives aux Interfaces/Index :

1 @Tabl_Desc = snmpgetbulk($community.$Equipement,0,$MR,$MifDescr);2 Etc

Pour les adresses IP :

1 @Tabl_AdrIf = snmpwalk($community.$Equipement,$MipAdEntIfIndex);2 $MR = @Tabl_AdrIf; # Max repetition

Les requêtes ultérieures relatives aux Adresses IP :

1 @Tabl_NetMask = snmpgetbulk($community.$Equipement,0,$MR,$MipAdEntNetMask);

2 Etc

Les résultats de cette optimisation apparaissent dans les deux �gures suivantes.Sur la �gure 7.11 en page 88, il apparait, qu'avant la ligne 19, l'OID requis est1.3.6.1.2.1.2.2.1.1, soit MifIndex (voir la colonne � Info �). En ligne 18 nousreconaissons une réponse identique à celle observée pour le quatrième dernierGetBulk initié avec un paramètre Max-repetitions positionné à 12 (voir �gure7.8 page 83). Ceci est conforme à nos attentes. A partir de ce moment nousdisposons du nombre d'interface et pouvons l'utiliser en tant que paramètreMax-repetitions.

À partir de la ligne 19, il n'y a plus qu'une seule réponse par requête :Le paramètre Max-repetitions est positionné au nombre d'interfaces, soit 38dans cet exemple (voir l'analyse de la trame de la ligne 19, en partie médiane


de la �gure).

Figure 7.11 � Traces Wireshark de toutes les requêtes par GetBulk optimisé

Sur la �gure 7.12 en page 89, il apparaît que toutes les informations sont ob-tenues en 0.62 secondes par l'échange de 44 paquets et 14658 octets, soient 70paquets par seconde pour des paquets de taille moyenne de 333 octets.

7.3.4 Limitations et putting all toghether

La mise en ÷uvre de GetBulk telle que dans l'exemple ci-dessus peut conduireà ce que le paquet de réponse atteigne la taille maximale du paquet, sans pourautant transmettre toutes les informations nécessaires.Par exemple un équipement doté de 100 interfaces, ne pourra retourner dansun paquet de taille maximale que les données relatives à une quarantained'interfaces.La réponse peut être donc incomplète c.à.d. ne pas concerner le nombre d'élé-ments �xé par le paramètre Max-repetitions. L'objet ne peut pas transmettre depaquets supplémentaires pour compléter la requête originale car ces paquets neseraient pas conformes au protocole qui impose qu'une réponse soit consécutiveà une requête.

L'utilisation de GetBulk dans les requêtes complique sévèrement l'ana-lyse des données retournées par l'objet interrogé. Le dimensionnement duparamètre Max-repetitions est crucial :

� Non-multiple du nombre de varbinds : La dernière réponse inclura desinformations non désirés, necessaire pour satisfaire le paramètre Max-


Figure 7.12 � Traces Wireshark de toutes les requêtes par GetBulk optimisé- Récapitulatif

repetitions. La station de management devra détecter et ignorer ces in-formations ;

� Multiple du nombre de varbinds : Si la réponse excède en taille lataille maximale d'un paquet, la station de management devra réitérerune requête. Pour cela elle devra détecter d'une part que le nombrede varbindsn'est pas complet et d'autre part extraire le dernier indexpour lequel une réponse est parvenue et reformuler une requête à partirde l'index suivant. Le paramètre Max-repetitions devra être recalculeraussi a�n d'optimiser le dernier paquet qui ne transportera aucuneinformation non désirée.

Un exemple PERL complet synthétisant tout cela est donné ci-dessous :

1 Debug (" −− Gathering Description \n") unless ($Mode != 1);2 $RestaFaire = $MR ; # $MR = @Tabl_Index lue précedemment3 $MIB = $MifDescr;4 $Split = $MIB.".";5 %Descr = ();6 while ($RestaFaire > 0) {7 @Tabl = snmpgetbulk($community.$ObjectV2,0,$RestaFaire,$MIB);8 $LgRetTable = @Tabl;9 $RestaFaire = $RestaFaire − $LgRetTable; # Reste a faire = depart −

fait10 foreach $Line (@Tabl) {11 @Temp = split (/$Split/,$Line);12 @Temp = split (/:/,$Temp[−1]);13 if (defined ($Temp[1] ) ) {14 $Descr{$Temp[0]} = $Temp[1];


15 } else {16 Debug ( "$Object ($Line) : No Descr returned, Skipping...") unless

($Mode != 1);17 exit();18 }19 }20 $MIB = $MifDescr.".$Temp[0]"; # Rebuild last OID21 }

Impact sur l'utilisation du réseau

Le graphe de la �gure 7.13 en page 90, représente l'impact sur le tra�c� SNMP � entrant (vers la station de management) de la mise en ÷vre deGetBulk . Le 8 mai 2012 (entre 05/04 et 05/10), le tra�c � SNMP � ne subitplus de peaks variant de 1,4Mb/s et 4,2 Mb/s. Ces peaks se stabilisent a 1,4Mb/s. Le tra�c moyen devient sans variation aux alentours de 200kb/s.

Figure 7.13 � Tra�c SNMP � entrant � sans puis avec requêtes GetBulk

Il en va de même pour le tra�c � SNMP � sortant (depuis la station demanagement), tel que représenté par la �gure 7.14 en page 91.

7.4 DNS

Il est très probable que la station de management ait, pour chaque équi-pement supervisé, à résoudre un nom en adresse IP ou une adresse IP ennom. Elle utilisera pour ce faire le service DNS de l'entreprise. Même si larésolution de nom (ou d'adresse IP) est rapide, la durée de cette résolutions'exprime en millisecondes et des millisecondes multipliées par des milliersd'équipement de transforment très vite en secondes. Ces secondes sont perdues


Figure 7.14 � Tra�c SNMP � sortant � sans puis avec requêtes GetBulk

à chaque période de � polling �. Pour ne plus les perdre, il su�t que la ré-solution des noms ou adresses IP se fasse en local sur la station de management :

Best Practices :Quand cela est possible, con�gurer le service de résolution de noms dela station de management de sorte à utiliser en priorité un �chier local,et mettre ce �chier local à jour quand le �chier central est altéré :Sous *nix : le �chier est /etc/hosts, l'ordre de recherche est dé�ni dans/etc/resolv.conf ou /etc/host.conf


Collecter des informations SNMP ponctuellement est une tâche très simple.Exploiter ces informations requiert une connaissance un peu plus poussée deSNMP et des di�érentes MIBs.

Concevoir un logiciel de supervision qui collecte ces informations de fa-çon régulière et les présente sous une forme � exploitable � à un utilisateurrequiert de bien maitriser les deux points ci-dessus cités, de savoir quellesinformations sont pertinentes pour la supervision du réseau et des connaissancespoussées concernant TCP/IP, les systèmes d'exploitation, les bases de données,les équipements supervisés. . .Il s'agit presque d'un art.

Il est toujours bon de sni�er le tra�c généré par une station de manage-ment et de l'analyser, a�n de se faire une idée du niveau de maturité deslogiciels mis en ÷uvre et du niveau des notions de supervision de réseaudisponibles au sein de l'équipe de développement des-dits logiciels.De même, le paramétrage d'un logiciel de supervision, la dé�nition opportunedes périodes de polling, des variables supervisées, des seuils d'alarme, etcnécessitent les mêmes connaissances � de manière un peu moins poussée


peut-être � mais surtout la connaissance du réseau à superviser et de ce qu'iltransporte.

� Je collecte TOUT, par SNMP Get � n'est pas un gage de maturité.Au contraire. Ni pour l'outil, ni pour la personne en charge de l'exploitation decelui-ci.

Sixième partie

Quelques exemples concrets

93

Chapitre 8

Lecture des adresses MAC

par SNMP

Je suis conscient que cet exercice à déjà été, à moult reprises, commenté etdisserté. Il n'en demeure pas moins un exemple type du cheminement qu'il yà lieu de réaliser, quelques fois, dans les méandres des MIBs, a�n d'obtenirla représentation souhaitées des informations recherchées. À de titre, cetteexemple à toute sa place dans ce document.

Comme mentionné au paragraphe 6.2 en page 68, une adresse MAC surun équipement est associée d'une part à l'interface physique de l'équipementpar laquelle cette adresse MAC est apprise, et d'autre part le VLAN con�gurépour cette interface.Nous allons voir dans ce chapitre comment, par SNMP, arriver à formuler lesrequêtes permettant de connaitre � Toutes les adresses Mac pour toutes lesinterfaces et pour tous les VLANs �.Une progression pas-à-pas sera adoptée. Cette démarche tachera de mettre enparallèle les informations obtenues par SNMP � avec l'outil GETIF o�rant uneinterface-utilisateur graphique � avec celles obtenues par CLI directement. Denombreux programmes en Perl concrétiseront cet exemple. Ces exemples deprogrammes assument que certaines variables, telle la Community String ou lesOIDs des MIBs sont initialisés préalablement aux extraits �gurant ici.

8.1 VLANs

Répondre à � Toutes les adresses Mac pour toutes les interfaces et pour tous lesVLANs � nécessite de connaitre toutes les interfaces et tous les VLANs.Commençons par les VLANs. Il convient d'établir la liste de tous les VLANsactifs sur l'équipement interrogé. Cette table est retournée par l'OID :.iso. org. dod. internet. private. enterprises. cisco. ciscoMgmt. ciscoVtp-

95

96 CHAPITRE 8. LECTURE DES ADRESSES MAC PAR SNMP

MIB. vtpMIBObjects. vlanInfo. vtpVlanTable. vtpVlanEntry. vtpVlanState ou.1.3.6.1.4.1.9.9.46.1.3.1.1.2, qui retourne, pour tous les VLANs con�gurés leurétat.

8.1.1 Getif

Interrogeons l'équipement avec l'outil Getif (voir �gure 8.1 en page 96 ) :

Figure 8.1 � Getif : Table de l'état des Vlans

Nous y voyons que le VLANs d'index 1 est dans l'état operational.Il en est de même pour les VLANs d'index 2, 126, 232, 702, 703. . .

8.1.2 CLI

La commande show vlans, initiée depuis la console de l'équipement nousretourne la même table :

1 sho vlan2

3 VLAN Name Status Ports4 −−−− −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− −−−−−−−−− −−−−−−−−−−−−−5 1 default active Gi1/2, Gi1/3, Gi1/46 2 VLAN0002 active Gi1/6, Gi1/18, Gi1/377 126 VLAN0126 active Gi1/1, Gi1/34, Gi1/358 232 VLAN0232 active9 702 VLAN0702 active

10 703 VLAN0703 active11 Etc

8.2. ADRESSES MAC 97

8.1.3 Perl

1 ### Get Active VLANS2 @Tabl = snmpwalk($community.$Object,$MibVtpVlanState);3 foreach $Line (@Tabl) {4 ($Vlan,$Status) = split (/:/,$Line);5 if ($Status) {6 ($T0,$T1) = split (/\./,$Vlan);7 push (@TabVlan, $T1) unless ($T1 > 1000) ;8 # WARNING : vlans greater than 1000 are ignored

!!!9 }

10 }11 Debug (" Liste of VLANs created ;");

Listing 8.1 � PERL : Liste des VLANs actifs

8.2 Adresses MAC

A�n de préciser pour quel VLAN la recherche d'adresses MAC est e�ectuée, ilconvient d'indexer la Community String par le VLAN en question.Si celle-ci est con�guré à � public � par exemple, et que la recherche d'adressesMAC est e�ectuée pour le VLAN 126, la Community String à utiliser est : � pu-blic@126 �.Une interrogation, avec cette Community String, de l'OID : .iso. org. dod. inter-net. mgmt. mib-2. dot1dBridge. dot1dTp. dot1dTpFdbTable. dot1dTpFdbEntry.dot1dTpFdbAddress (.1 .3 .6 .1 .2 .1 .17 .4 .3 .1 .1) retourne toutes les adressesMAC connues de l'équipement pour le VLAN 126.

8.2.1 Getif

L'indexation de la Community String dans l'outil Getif est réalisé dans l'onglet� Parameters � tel que montré dans la �gure 8.2 en page 97.

Figure 8.2 � Getif : Indexation de la Community String

La table des adresses MAC retournées par une requête formulée avec Commu-nity String est représenté par la �gure 8.3 en page 98.


Figure 8.3 � Getif : Table d'adresse MAC pour le Vlan 126

Il convient d'interpréter cette �gure de la sorte :Les adresses MAC suivantes ont été détectées dans le VLAN 126 sur cet équi-pement, l'adresse MAC0 : 0 : 12 : 7 : 172 : 0Base10 est 0 : 0 : c : 7 : ac : 0Base16

0 : 2 : 165 : 139 : 106 : 109Base10 est 0 : 2 : a5 : 8b : 6a : 6dBase16

etc.

8.2.2 CLI

La commande show mac-address-table, initiée depuis la console de l'équipe-ment nous retourne � grosso-modo � la même table, si l'on ne retient que leVLAN 126 en première colonne :

1 sho mac−address−table2 Unicast Entries3 vlan mac address type protocols port4 −−−−−−−+−−−−−−−−−−−−−−−+−−−−−−−−+−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−−−

5 126 0000.0c07.ac00 dynamic ip Port−channel56 126 0002.a58b.6a6d dynamic ip Port−channel57 126 0002.a5e7.881b dynamic ip Port−channel58 126 0002.a5f0.061e dynamic assigned,other Port−channel59 etc

Cette table est à interpréter de la sorte :Dans le VLAN 126, l'adresse MAC 0000.0c07.ac00 à été apprise par le biais del'interface Port-channel5, etc.

8.3. PORTS 99

8.2.3 Perl

La di�culté de traitement de cette requête réside dans le fait que les valeursretournées sont de type octetstr (voir le paragraphe 3.1.1 en page 8), c.à.d. dubinaire qu'il est impossible d'a�cher directement et très di�cile de traiter entant que chaine binaire pure.La nature du type de l'information retournée est obtenue par la connaissancede cette MIB, ou par le lecture du type dans l'outil Getif.

1 foreach $Vlan (@TabVlan) { # Read the MAC address perVLAN

2 $IndexedCS = $community."$Vlan\@";3 @Tabl = ();4 @Tabl = snmpwalk($IndexedCS.$ObjectV2,$Mibdot1dTpFdbAddress); #

Decimal:Hexa5 foreach $Line (@Tabl) { # 0.208.4.226.180.10:HERE IS BINARY6 # All mib variables are indexed by

Decimal7 ($DeciMAC,$HexMAC) = split (/:/, $Line, 2);8 $UMac = $UMac1 = $HEXMAC = "";9 @Table1 = ();

10 $UMac = unpack ’H∗’, $HexMAC;11 @Table1 = $UMac =~ /../g;12 $UMac1 = join (’:’, @Table1);13 $HEXMAC = uc($UMac1);14 $HEXMAC =~ s/^/$Vlan@/; # HEXMAC : Vlan @ Human Readable

Mac_Address in Hex Format15

16 $DECIMAC{$HEXMAC} = $Vlan."@".$DeciMAC;# Vlan @ 0.208.4.226.180.1017 push (@TabHexMac, $HEXMAC);18 }19 $NbMAC = @TabHexMac;20 }

Listing 8.2 � PERL : MAC-Hexa / MAC-Décimal

8.3 Ports

Nous avons à notre disposition, à ce stade de nos requêtes, la liste de toutesles adresses MAC par VLANs. Il convient maintenant de savoir sur quels Portsces adresses ont été apprises. Cette information est (indirectement) accessible eninterrogeant l'OID : iso. org. dod. internet. mgmt. mib-2. dot1dBridge. dot1dTp.dot1dTpFdbPort (1. 3. 6. 1. 2. 1. 17. 4. 3. 1. 2), en conservant la CommunityString indexée.Cette information est indirectement accessible car en e�et, la réponse à cetterequête retourne l'Index du Port par lequel l'adresse MAC a été apprise. Noussavons déjà qu'au mois une requête supplémentaire sera nécessaire a�n d'associerl'Index retourné à une interface qui nous est connue.


8.3.1 Getif

La table des adresses MAC retournées par une requête formulée avec uneCommunity String indexée est représentée par la �gure 8.4 en page 100.

Figure 8.4 � Getif : Table d'adresse MAC par Ports pour le VLAN 126

Qu'il faut interpréter par :l'adresse MAC 0.0.12.7.172.0 a été apprise par le biais du port 645, dans leVLAN 126 (index utilisé pour la Community String indexée), etc.

Il est aussi à noter que c'est la forme décimale de l'adresse MAC qui estindexée, par la forme hexadécimale.

8.3.2 CLI

Il n'y a pas de commande équivalente.

8.3.3 PERL

1 @Tabl_MACPort = snmpwalk($IndexedCS.$Object,$Mibdot1dTpFdbPort); #Decimal:port

2 foreach $Line (@Tabl_MACPort) {3 ($T0,$T1) = split (/:/, $Line);4 $T0 = $Vlan."@".$T0;5 $MACPort{$T0} = $T1; # T0 = [email protected] : T1 = 72

Listing 8.3 � PERL : Table d'adresses MAC par port pour le VLAN 126

8.4. PORT INTERFACE INDEX 101

8.4 Port Interface Index

Il convient à ce stade d'associer une interface physique de l'équipement àl'Index-de-Port retourné par la requête précédente ( Quelle interface estd'Index-de-Port 645 dans l'exemple précédent).Pour ce faire il convient d'utiliser ( à nouveau indirectement) l ?OID : .iso. org.dod. internet. mgmt. mib-2. dot1dBridge. dot1dBase. dot1dBasePortTable.dot1dBasePortEntry. dot1dBasePortIfIndex (.1. 3. 6. 1. 2. 1. 17. 1. 4. 1. 2).

Cet OID va nous permettre d'associer un Index-de-Port à un Index d'In-terface physique.

8.4.1 Getif

La table table corrélant les Index-de-Port aux Index-d'interface est représentéepar la �gure 8.5 en page 101.

Figure 8.5 � Getif : Correspondance Port / Interface

Qu'il faut interpréter par :L' Index-de-Port 1 référence l'Index-d'interface 2L' Index-de-Port 35 référence l'Index-d'interface 36L' Index-de-Port 645 référence l'Index-d'interface 57, etc.

8.4.2 CLI

Il n'y a pas de commande équivalente.


8.4.3 PERL

1 @Tabl = ();2 @Tabl = snmpwalk($IndexedCS.$ObjectV2,$Mibdot1dBasePortIfIndex); #

MACIndex : IfIndex3 foreach $Line (@Tabl) {4 # MACIndex(MAC local Port) = MIB II Index5 ($T0,$T1) = split (/:/, $Line);6 $MACIndex{$T0} = $T1;7 }

Listing 8.4 � PERL : Correspondances Port / Interface

8.5 Interface

A�n de déterminer quelle interface � au sens interface physique, celle qui estcon�guré par nos soins � est indexée par quel Index-d'interface, il convientd'interroger l'OID : .iso. org. dod. internet. mgmt. mib-2. interfaces. ifTable.ifEntry. ifDescr (.1. 3. 6. 1. 2. 1. 2. 2. 1. 2). La table des descriptions donnéespar le fabriquant de l'équipement est retournée.

8.5.1 Getif

La table des descriptions retournées est représentée par la �gure 8.4 en page 100.

Figure 8.6 � Getif : Table des descriptions

Qu'il faut interpréter par :. . .

8.6. EN COMBINANT LE TOUT 103

L' Index 57 référence l'interface Port-channel5etc.

8.5.2 Perl

qqqqqqqqqqqqqqqqqqqqqqqqqqqq

1 @Tabl_Desc = snmpwalk($community.$Object,$MibifDescr);2 %Descr = ();3 foreach $Line (@Tabl_Desc) {4 ($T0,$T1) = split (/:/,$Line);5 $Descr{$T0} = $T1;6 Debug (" Index $T0 is $T1 \n");7 }

Listing 8.5 � PERL : Table des descriptions

qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq

8.6 En combinant le tout

Toutes les étapes précédentes combinées entre-elles retournent la même infor-mation que la commande sho mac-address-table (voir le chapitre 8.2.2 enpage 98) à savoir que l'adresse MAC 0000.0c07.ac00 est connue dans le VLAN126 par le biais de l'interface Port-channel5.

Le cheminement pour y parvenir peut paraître laborieux, il n'en demeurepas moins simple et très facilement automatisable. C'est le nombre d'étapes àe�ectuer qui pourrait rebuter, non leurs complexité. Le genre de travail à lachaine duquel l'informatique s'occupe à merveille.


Chapitre 9

Considérations

supplémentaires

Ces considérations supplémentaires concernent les adresses MAC.

L'accès à des données �ables concernant les adresses MAC, telles que :

� l'adresse MAC 0102.0304.0506 est connectée au Switchabch01.mydomain.com sur le port FastEthernet0/21

est dans certains cas d'une importance capitale. Ceci est particulièrement vraidès que le réseau à superviser est quelque peu étendu et que la connexiond'appareils au réseau (aux switchs) n'est pas à 100% sous votre contrôle � Sivous croyez avoir ce contrôle à 100%, comment le véri�ez-vous ?

Exploiter des informations issues de l'analyse des tables d'adresses MACnécessite une con�ance importante en ces données et donc une �abilité quasisans faille des données contenues dans ces tables. Cette �abilité peut di�ci-lement être acquise si les informations contenues dans cette table sont lue àintervalle régulier, quand bien même cet intervalle de temps serait faible, ilintroduit des incertitudes.

Le plus haut degré de �abilité de ces données est obtenu lorsque l'équi-pement de réseau auquel est connecté/déconnecté un appareil est capabled'informer � par Trap � la station de supervision qui tient à jour la base dedonnées des adresses MAC. L'outil de supervision Jmon utilise cette possibilitédisponible sur les équipements Cisco . Lorsque cette fonctionnalité n'est pasutilisable, la collecte des adresses MAC doit être réalisée en interrogeant tel quedécrit dans le chapitre précédent, tous les équipements réseau auxquels il estpossible de connecter un appareil (principalement les switchs). Les paragraphessuivants de ce chapitre se rapportent exclusivement à cette forme de collecte.

105

106 CHAPITRE 9. CONSIDÉRATIONS SUPPLÉMENTAIRES

Jmon réalise cette collecte une fois par semaine. La durée de cette collecte, surun réseau similaire au réseau décrit au chapitre 7 en page 73 est de l'ordre de200 minutes.

9.1 Quand collecter ces informations

De toute évidence cette collecte doit avoir lieu aux moments durant lesquelsles appareils sont connectés au réseau. En e�et, sur les équipements Cisco, leparamètre mac-adress-table aging-time est par défaut positionner à la valeur 400(ou 300 selon les équipements et Version d'IOS). Ceci signi�e qu'après 400 (ou300) secondes après le dernier paquet vu avec cette adresse MAC, l'équipemente�ace cette adresse de sa table d'adresses MAC.Si la collecte des adresse MAC à lieu durant la nuit, il est fort probable quebeaucoup d'appareils � même non débranchés � aient été silencieux depuis plusde 400 (ou 300) secondes, et donc que leurs adresses MAC aient disparues de latable d'adresses MAC des équipements interrogés. Il est à noter aussi, que mêmeen pleine journée de travail, des appareils peuvent rester � silencieux � durantplus de 400 (ou 300) secondes. C'est le cas des imprimantes en particulier.

9.2 Quelles informations stocker

Le but de la table des adresses MAC est de savoir sur quel équipement etquelle interface un appareil est connecté. Le but n'est pas de stocker tous leséquipements et toutes les interfaces ayant connaissance de cette adresse MAC.En e�et, considérons le schéma suivant :

Figure 9.1 � un appareil branché sur un switch

L'information qu'il convient de stocker est que � Appareil � est connecté à l'in-terface Fa0/25 du Switch B, dans le Vlan X. Or de par l'implémentation duprotocole ARP et de la manière dont un switch Cisco emplit sa table d'adresseMAC, le Routeur, le SwitchA et le Switch B du schéma ci-dessus disposent d'uneentrée dans leur table d'adresses MAC concernant � Appareil �.

9.2.1 Exemple

Dans le cas du schéma précèdent, prenons l'exemple ou nous cherchons� Appareil � connaissant son adresse MAC : 00 08.74ed.acb2. Supposons aussi

9.2. QUELLES INFORMATIONS STOCKER 107

que nous sachions que cet appareil est connecté au réseau, dans la �liale abc.

Routeur

Il est logique d'interroger en premier lieu la table des adresses MAC du Routeurde la �liale abc, qui est toujours le � point d'entrée � dans une �liale. Cetteadresse MAC doit lui être connue (un ping depuis le routeur envers l'adresseIP de � Appareil � peut être nécessaire) :

Routeur#sho mac-address-table | incl 0008.74ed.acb2308 0008.74ed.acb2 DYNAMIC Gi1/0/1

L'adresse MAC recherchée est connue du Routeur par le biais de son interfaceGi1/0/1 dans le Vlan 308.

L'interface Gi1/0/1 est con�gurée de la sorte :

interface GigabitEthernet1/0/1description Switch-A Gi 0/1switchport trunk encapsulation dot1qswitchport trunk allowed vlan 1-1024switchport mode trunkmls qos trust dscp

Grâce aux Best Practices concernant les descrition des interfaces énoncées auparagraphe 5.1.4 en page 40, nous savons de suite que � Appareil � n'est pasconnecté à cette interface, mais qu'il s'agit d'un lien vers le Switch A.Si ces Best Practices ne sont pas (encore) appliquées, la commande show cdp

neighbors permet de trouver cette information :

Routeur#sho cdp neighbors...Device ID Local Intrfce...Switch-A.mydomain.com Gig 1/0/1......

Bien sûr cela n'est possible qui si CDP (ou équivalent) est autorisé sur leséquipements. Si cela n'est pas le cas, il ne reste plus qu'à espérer que ladocumentation soit à jour. . .

Dans tous les cas, il convient de ne pas de stocker dans la base de don-nées des adresses MAC le triplet [Vlan, Switch, interface] suivant : [308,Routeur, Gi1/0/1].

Il convient de réitérer ces mêmes interrogations sur le Switch-A .


Switch A

Switch-A#sho mac-address-table | incl 0008.74ed.acb2308 0008.74ed.acb2 DYNAMIC Gi0/2

Switch-A #sho run int Gi0/2...interface GigabitEthernet0/2description Switch-B Gi 0/1switchport trunk encapsulation dot1qswitchport trunk allowed vlan 1-1024switchport mode trunkmls qos trust dscp

Switch-A #sho cdp neighbors...Device ID Local Intrfce...Switch-B.mydomain.com Gig 0/2......

Les mêmes considérations que précédemment nous amènent à ne pas stockerdans la base de données des adresses MAC le triplet [VLAN, Switch, interface]suivant : [308, Switch-A, Gi0/2] et à réitérer ces mêmes interrogations sur leSwitch-B.

9.2.2 Switch B

Switch-B#sho mac-address-table | incl 0008.74ed.acb2308 0008.74ed.acb2 DYNAMIC Fa0/25Switch-B#sho run int Fa0/25 ...interface FastEthernet0/25switchport trunk encapsulation dot1qswitchport trunk native vlan 308switchport trunk allowed vlan 308,309,800,826switchport mode trunkspeed 100duplex fullsnmp trap mac-notification addedsnmp trap mac-notification removedno mdix autono cdp enablespanning-tree portfast trunkspanning-tree bpduguard enableservice-policy input policy-QoS

Cette interface est une interface de connexion d'appareils, � Appareil � y estconnecté. Il convient de stocker dans la base de données des adresses MAC le

9.3. AUTOMATISATION 109

triplet [Vlan, Switch, interface] suivant : [308, Switch-B, Fa0/25].

9.3 Automatisation

L'exemple précédant est un bel exemple pédagogique. Comment associerautomatiquement dans la base de données des adresses MAC le triplet [308,Switch-B, Fa0/25] à l'adresse MAC 0008.74ed.acb2, en n'ayant à notre disposi-tion que des informations collectées par SNMP et la connaissance du réseau àsuperviser.

Cette connaissance du réseau à superviser nous apporte la connaissanceque la Best Practice suivante a été mise en ÷uvre :

Best Practice :

Ne pas utiliser le VLAN 1 pour y connecter des appareils. Mettre en÷uvre au moins 2 VLANS :Un Vlan � Données � pour les appareilsUn Vlan de management pour adresser les équipements réseau

9.3.1 Native Vlan


Table des �gures

3.1 Le modèle architectural de SNMP selon RFC 1157 . . . . . . . . 83.2 Structure arborescente des OIDs . . . . . . . . . . . . . . . . . . 113.3 Représentation de l'arborescence par Getif . . . . . . . . . . . . 113.4 Exemple d'OID . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.5 Encapsulation des messages SNMP . . . . . . . . . . . . . . . . 153.6 Dé�nition des 5 di�érents PDUs par la RFC 1157 . . . . . . . . 173.7 Échanges de PDUs entre la station de management et l'équipe-

ment supervisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.8 Structure des 5 di�érents PDUs par la RFC 1157 . . . . . . . . 193.9 Structure des Traps-PDUs . . . . . . . . . . . . . . . . . . . . . 213.10 Getif sur mgth03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.11 Traces Wireshark du lancement de Getif sur mgth03 . . . . . . . 233.12 Traces Wireshark du lancement de Getif sur mgth03 - détails . . 243.13 Traces Wireshark de la réponse de mgth03 . . . . . . . . . . . . 25

4.1 COBIT -extrait- . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.1 � Réseau Type �supervisé . . . . . . . . . . . . . . . . . . . . . . 375.2 Équipements à inventorier . . . . . . . . . . . . . . . . . . . . . 425.3 CLI : show version . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4 Première collecte d'information par Net : :SNMP . . . . . . . . 435.5 Première collecte d'information par Getif . . . . . . . . . . . . . 445.6 Cisco MIB browser pour la MIB CISCO-STACK-MIB, Object =

chassisModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.7 Cisco MIB browser pour la MIB CISCO-STACK-MIB, Object =

chassisSerialNumber . . . . . . . . . . . . . . . . . . . . . . . . . 455.8 Cisco MIB browser pour la MIB CISCO-STACK-MIB, Object =

modulSwVersion . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.9 Accès au modèle de switch et au numéro de série . . . . . . . . . 465.10 Accès à la version logicielle . . . . . . . . . . . . . . . . . . . . . 475.11 Premières valeurs dans la base de données Jmon . . . . . . . . . 485.12 Résultat du programme PERL collectant ces 1eres informations 505.13 Exemple de Baseline Monitoring . . . . . . . . . . . . . . . . . . 515.14 Paramètres minima à mesurer . . . . . . . . . . . . . . . . . . . 52

111

112 TABLE DES FIGURES

5.15 MIB ifInOctets : Nombre d'octets reçus . . . . . . . . . . . . . . 535.16 MIB ifOutOctets : Nombre d'octets émis . . . . . . . . . . . . . 545.17 MIB cpmCPUTotal5minRev : Utilisation CPU . . . . . . . . . . 545.18 MIB ifInErrors : Erreurs en entrée . . . . . . . . . . . . . . . . . 555.19 MIB ifOutErrors : Erreurs en Sorties . . . . . . . . . . . . . . . 555.20 Intranet groupant des informations . . . . . . . . . . . . . . . . 565.21 Exemple de dé�nition de compteur . . . . . . . . . . . . . . . . 585.22 Dérives de temps de transit . . . . . . . . . . . . . . . . . . . . . 59

6.1 Indexation simple . . . . . . . . . . . . . . . . . . . . . . . . . . 646.2 MIB ifDescr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.3 Schématisation de l'indexation . . . . . . . . . . . . . . . . . . . 676.4 Table ITF de Jmon . . . . . . . . . . . . . . . . . . . . . . . . . 686.5 Switch port pour voix sur IP . . . . . . . . . . . . . . . . . . . . 69

7.1 Taille d'un réseau moyen vu par l'outil Jmon . . . . . . . . . . 737.2 Période de polling et pro�l de tra�c . . . . . . . . . . . . . . . . 757.3 Trace Wireshark du timeout et retries sur une requête SNMP . 767.4 Timeout et retry sur une requête SNMP - Récapitulatif . . . . . 777.5 Trace Wireshark de la requête de tous les alias par snmpwalk . . 807.6 Traces Wireshark de la requête des Alias - Récapitulatif . . . . . 817.7 Trace Wireshark de la requête de tous les alias par GetBulk . . 827.8 Traces Wireshark de la 4e et dernière requête des Alias par Get-

Bulk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.9 Branche 1.3.6.1.2.1.31 sur le switch pris en exemple . . . . . . . 847.10 Traces Wireshark de la requête des Alias par GetBulk - Récapi-

tulatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857.11 Traces Wireshark de toutes les requêtes par GetBulk optimisé . 887.12 Traces Wireshark de toutes les requêtes par GetBulk optimisé -

Récapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.13 Tra�c SNMP � entrant � sans puis avec requêtes GetBulk . . . 907.14 Tra�c SNMP � sortant � sans puis avec requêtes GetBulk . . . 91

8.1 Getif : Table de l'état des Vlans . . . . . . . . . . . . . . . . . . . 968.2 Getif : Indexation de la Community String . . . . . . . . . . . . . 978.3 Getif : Table d'adresse MAC pour le Vlan 126 . . . . . . . . . . . 988.4 Getif : Table d'adresse MAC par Ports pour le VLAN 126 . . . . 1008.5 Getif : Correspondance Port / Interface . . . . . . . . . . . . . . 1018.6 Getif : Table des descriptions . . . . . . . . . . . . . . . . . . . . 102

9.1 un appareil branché sur un switch . . . . . . . . . . . . . . . . . 106

Liste des tableaux

4.1 ITIL - Services Support . . . . . . . . . . . . . . . . . . . . . . . 304.2 ITIL - Services Delivery . . . . . . . . . . . . . . . . . . . . . . . 31

7.1 Les index des 38 interfaces dont les alias sont requis . . . . . . . 83

113

114 LISTE DES TABLEAUX

Listings

8.1 PERL : Liste des VLANs actifs . . . . . . . . . . . . . . . . . . . 978.2 PERL : MAC-Hexa / MAC-Décimal . . . . . . . . . . . . . . . . 998.3 PERL : Table d'adresses MAC par port pour le VLAN 126 . . . 1008.4 PERL : Correspondances Port / Interface . . . . . . . . . . . . . 1028.5 PERL : Table des descriptions . . . . . . . . . . . . . . . . . . . 103

115

Documents

La supervision de réseau par SNMPjmjmon.fr/LaSupervisionDeReseau/FR/LaSupervisiondeReseau.pdfréseau par SNMP , ainsi que de délivrer des Best-Practices basées sur plus de quinze