JMJ La supervision de réseau par SNMP · JMJ Reference SNMP_Mon Page 3/124 JMJ Historique du...

JMJ La supervision de réseau par

SNMP 0.00

Auteur(s): JMJ Date: 01 décembre 2011 Version: 0.00 Statut: Draft Référence: SNMP_Mon

Liste d’approbation et de distribution

Approbation Nom/Fonction Date Fonction Nom

Fonction Nom

Fonction Nom

Liste de distribution Nom/Fonction Date Fonction Nom

JMJ Reference SNMP_Mon

/124

JMJ

Historique du document Version Date Raison du changement 0.00 01 décembre 2011 Version initiale


/124

JMJ

Table des matières

1 GLOSSAIRE ........................................................................................................ 10

2 CONVENTION DE STYLE ..................................................................................... 11

3 OBJECTIFS ........................................................................................................ 11

4 AUDIENCE .......................................................................................................... 12

4.1 PRÉ REQUIS ............................................................................................................... 12

5 OPINIONS ........................................................................................................... 12

6 INTRODUCTION .................................................................................................. 13

7 LA THÉORIE ....................................................................................................... 13

7.1 EN RÉSUMÉ ............................................................................................................... 13 7.2 HISTORIQUE .............................................................................................................. 14 7.3 ARCHITECTURE .......................................................................................................... 15 7.4 INFORMATION DE MANAGEMENT ..................................................................................... 16

7.4.1 Représentation ............................................................................................. 16 7.4.1.1 OIDs ......................................................................................................... 18

7.4.2 MIB .............................................................................................................. 19 7.4.2.1 RFC 1156 ................................................................................................. 19

7.5 PROTOCOLE ............................................................................................................... 22 7.5.1 Versions ....................................................................................................... 22 7.5.2 Community String ........................................................................................ 23 7.5.3 Protocol Data Unit (PDU) .............................................................................. 23

7.5.3.1 Structure de ces PDUs .............................................................................. 24 7.5.3.2 Traps ........................................................................................................ 26

7.6 SYNTHÈSE DU CHAPITRE .............................................................................................. 28 7.6.1 Requête ........................................................................................................ 28 7.6.2 Réponse ....................................................................................................... 29

8 LE NETWORK OPERATING CENTER .................................................................... 31

8.1 POURQUOI SUPERVISER UN RÉSEAU ............................................................................... 31 8.2 MISSIONS DU NOC ..................................................................................................... 31

8.2.1 Le NOC et ITIL / COBIT ................................................................................ 31 8.2.1.1 Service Support ........................................................................................ 32 8.2.1.2 Service Delivery ......................................................................................... 32

8.3 LES OUTILS DU NOC ................................................................................................... 33 8.4 SYNTHÈSE DU CHAPITRE .............................................................................................. 34

9 LE « RÉSEAU TYPE » SUPERVISÉ ........................................................................ 35

9.1 CONFIGURATION DES ÉQUIPEMENTS SUPERVISÉS .............................................................. 36 9.1.1 Sécurité ........................................................................................................ 36 9.1.2 Définition de la Station de Management ........................................................ 37 9.1.3 Autres paramètres SNMP .............................................................................. 37 9.1.4 Autres paramètres généraux ......................................................................... 37

9.2 QUELLES VARIABLES COLLECTER ? ................................................................................ 39 9.2.1 Inventaire ..................................................................................................... 39

9.2.1.1 CLI : Sho ver ............................................................................................. 40 9.2.1.2 Linux et Getif ............................................................................................ 40

9.2.2 Baseline monitoring ...................................................................................... 46 9.2.2.1 Variables .................................................................................................. 48


/124

JMJ

9.2.2.2 ifInOctets – ifOutOctets – CPU - Errors ...................................................... 50 9.3 COMPTEURS .............................................................................................................. 53

9.3.1 Compteurs CLI ............................................................................................. 53 9.3.2 Compteurs SNMP ......................................................................................... 54 9.3.3 « Bouclage » des compteurs ........................................................................... 55

9.4 SYNTHÈSE DU CHAPITRE .............................................................................................. 55

10 SNMP ET L’INDEXATION .................................................................................. 56

10.1 INDEXATION SIMPLE ................................................................................................. 56 10.2 INDEXATION MULTIPLE .............................................................................................. 64

11 QUELQUES CHIFFRES ET CALCULS ÉLÉMENTAIRES ....................................... 66

11.1 POLLING ................................................................................................................. 66 11.2 TIMEOUT ET RETRIES ................................................................................................ 68 11.3 COLLECTE D’INFORMATION ........................................................................................ 70

11.3.1 Alias ............................................................................................................. 70 11.3.2 SNMP V2c et Getbulk ................................................................................... 72

11.3.2.1 Optimisation maximale .......................................................................... 77 11.3.2.2 Limitations et putting all toghether ........................................................ 79

11.4 DNS ..................................................................................................................... 80 11.5 SYNTHÈSE DU CHAPITRE ........................................................................................... 80

12 LECTURE D’UNE TABLE D’ADRESSE MAC PAR SNMP ...................................... 82

12.1 VLANS ................................................................................................................... 82 12.1.1 Getif ............................................................................................................. 82 12.1.2 CLI ............................................................................................................... 82 12.1.3 PERL ............................................................................................................ 84

12.2 ADRESSE MAC ....................................................................................................... 84 12.2.1 CLI ............................................................................................................... 85 12.2.2 PERL ............................................................................................................ 85

12.3 PORTS ................................................................................................................... 85 12.3.1 Getif ............................................................................................................. 86 12.3.2 CLI ............................................................................................................... 86 12.3.3 PERL ............................................................................................................ 86

12.4 PORT INTERFACE INDEX ............................................................................................ 86 12.4.1 Getif ............................................................................................................. 87 12.4.1 CLI ............................................................................................................... 87 12.4.2 PERL ............................................................................................................ 87

12.5 INTERFACE ............................................................................................................. 87 12.5.1 Getif ............................................................................................................. 88 12.5.2 PERL ............................................................................................................ 88

12.6 EN COMBINANT LE TOUT ............................................................................................ 88

13 CONSIDÉRATIONS SUPPLÉMENTAIRES CONCERNANT LES ADRESSES MAC. ... 89

13.1 QUAND COLLECTER CES INFORMATIONS ....................................................................... 89 13.2 QUELLES INFORMATIONS STOCKER .............................................................................. 89

13.2.1 Exemple ....................................................................................................... 90 13.2.1.1 Routeur ................................................................................................. 90 13.2.1.2 Switch-A ................................................................................................ 91 13.2.1.3 Switch-B ............................................................................................... 91

13.3 AUTOMATISATION ..................................................................................................... 92 13.3.1 Native Vlan ................................................................................................... 92 13.3.2 Trunk Port Synamic Status .......................................................................... 93

13.4 PROGRAMME PERL .................................................................................................. 94

14 TRUNKING PROTOCOL .................................................................................... 95

14.1 INTERFACES ET PORTS .............................................................................................. 95 14.2 VLANS ó PORTS .................................................................................................... 96

14.2.1 Getif ............................................................................................................. 97


/124

JMJ

14.2.2 PERL ............................................................................................................ 97 14.3 VLAN NATIF ........................................................................................................... 97 14.4 TRUNKS ................................................................................................................. 97 14.5 VLANS AUTORISÉS .................................................................................................. 98

14.5.1 Getif ............................................................................................................. 99 14.5.2 PERL ............................................................................................................ 99

15 SPANNING TREE PROTOCOL ......................................................................... 101

15.1 PERL .................................................................................................................. 102

16 CDP ............................................................................................................... 103

17 ARP ............................................................................................................... 104

18 GETIF ............................................................................................................ 105

1 CISCO SYSTEM OBJECT IDS ............................................................................ 107

2 QUELQUES MESURES ....................................................................................... 110

2.1 GETMAC ................................................................................................................ 110 2.1.1 Avec Get Bulk : ........................................................................................... 110

2.2 COLLECTOBJECTINFO.PL ........................................................................................... 110

3 OBTENIR LES INDEX SNMP D’UN ÉQUIPEMENT CISCO ..................................... 111

4 GETMAC.PL ...................................................................................................... 112

5 GETVTP.PL ....................................................................................................... 119


/124

JMJ

Table des figures

FIGURE 1: HIERARCHISATION DU MENU .................................................................. 11

FIGURE 2: LE MODELE ARCHITECTURAL DE SNMP SELON RFC 1157 ..................... 15

FIGURE 3: REPRESENTATION DE L’ARBORESCENCE PAR GETIF .............................. 18

FIGURE 4: EXEMPLE D’OID ...................................................................................... 21

FIGURE 5: ENCAPSULATION DES MESSAGES SNMP .................................................. 22

FIGURE 6: ECHANGES DE PDUS ENTRE LA STATION DE MANAGEMENT ET L’EQUIPEMENT SUPERVISE ...................................................................................... 24

FIGURE 7: GETIF SUR MGTH03 ................................................................................ 28

FIGURE 8: TRACES WIRESHARK DU LANCEMENT DE GETIF SUR MGTH03 ............... 28

FIGURE 9: TRACES WIRESHARK DU LANCEMENT DE GETIF SUR MGTH03 - DETAILS29

FIGURE 10: TRACES WIRESHARK DE LA REPONSE DE MGTH03 .............................. 30

FIGURE 11: COBIT – EXTRAIT .................................................................................. 31

FIGURE 12: « RESEAU TYPE » SUPERVISE ................................................................ 35

FIGURE 13: EQUIPEMENTS A INVENTORIER ............................................................ 39

FIGURE 14: PREMIERE COLLECTE D’INFORMATION PAR GETIF ............................... 41

FIGURE 15: ACCES AU MODELE DE SWITCH ET AU NUMERO DE SERIE ................... 43

FIGURE 16: ACCES A LA VERSION LOGICIELLE ........................................................ 43

FIGURE 17: PREMIERES VALEURS DANS LA BASE DE DONNEES JMON .................... 44

FIGURE 18: RESULTAT DU PROGRAMME PERL COLLECTANT CES 1ERES INFORMATIONS ........................................................................................................ 46

FIGURE 19: EXEMPLE DE BASELINE MONITORING AVEC L’OUTIL JNET2 BASE SUR MRTG ....................................................................................................................... 48

FIGURE 20: PARAMETRES MINIMA A MESURER ....................................................... 49

FIGURE 21: EXEMPLE D’INTRANET DONNANT UN APERÇU RAPIDE DE LA SANTE DU RESEAU VERS UNE FILIALE ..................................................................................... 52

FIGURE 22: INDEXATION SIMPLE ............................................................................. 56

FIGURE 23: IFDESCR ................................................................................................ 57

FIGURE 24: SCHEMATISATION DE L‘INDEXATION .................................................... 58

FIGURE 25: TABLE „ITF“ DE JMON .......................................................................... 63

FIGURE 26: SWITCH PORT POUR VOIP ..................................................................... 64

FIGURE 27: TAILLE D’UN RESEAU MOYEN VU PAR L’OUTIL JMON ............................ 66

FIGURE 28: PERIODE DE POLLING ET PROFIL DE TRAFIC ....................................... 67

FIGURE 29: TRACES WIRESHARK DU TIMEOUT ET RETRY SUR UNE REQUETE SNMP68

FIGURE 30: TIMEOUT ET RETRY SUR UNE REQUETE SNMP - RECAPITULATIF ......... 69

FIGURE 31: TRACES WIRESHARK DE LA REQUETE DES ALIAS ................................ 71

FIGURE 32: TRACES WIRESHARK DE LA REQUETE DES ALIAS - RECAPITULATIF .... 71

FIGURE 33: TRACES WIRESHARK DE LA 1ERE REQUETE DES ALIAS PAR GETBULK 72


/124

JMJ

FIGURE 34: TRACES WIRESHARK DE LA 4E ET DERNIERE REQUETE DES ALIAS PAR GETBULK ................................................................................................................. 73

FIGURE 35: 1.3.6.1.2.1.31.1.2.1.3.0.1 EST L’OID INTERROGEABLE SUIVANT POUR CET EQUIPEMENT .................................................................................................... 74

FIGURE 36: REQUETES PAR GETBULK – RECAPITULATIF ........................................ 75

FIGURE 37: TRACES WIRESHARK D’UNE REQUETE PAR GETBULK OPTIMISE .......... 76

FIGURE 38: TRACES WIRESHARK DE TOUTES LES REQUETES PAR GETBULK OPTIMISE ................................................................................................................. 78

FIGURE 39: TRACES WIRESHARK DE TOUTES LES REQUETES PAR GETBULK OPTIMISE – RECAPITULATIF .................................................................................... 78

FIGURE 40: BANDE PASSANTE „ENTRANTE“ UTILISEE PAR SNMP AVEC ET SANS REQUETES GETBULK ............................................................................................... 79

FIGURE 41: GETIF : TABLE DE L’ETAT DES VLANS .................................................. 82

FIGURE 42: GETIF: TABLE D’ADRESSE MAC POUR LE VLAN 126 .............................. 84

FIGURE 43: GETIF: TABLE D’ADRESSE MAC PAR PORT POUR LE VLAN 126 ............. 86

FIGURE 44: GETIF: CORRESPONDANCE PORT – INTERFACE .................................... 87

FIGURE 45: GETIF: CORRESPONDANCE INDEX – INTERFACE ................................... 88

FIGURE 46: INFORMATIONS VTP ............................................................................... 95

FIGURE 47: CISCO STACK MIB : VLAN INDEX ........................................................... 96

FIGURE 48: GETIF : ASSOCIATION VLAN ó PORTS .................................................. 97

FIGURE 49: CISCO STACK MIB : VLAN ENABLED ...................................................... 98

FIGURE 50: GETIF : VLANS ENABLED (ALLOWED) ..................................................... 99

FIGURE 51: REPRESENTATION DES VLANS ALLOWED SOUS *NIX .......................... 100

Table des tableaux

TABLE 1: IFOPERSTATUS ......................................................................................... 20

TABLE 2: DEFINITION DES 5 DIFFERENTS PDUS PAR LA RFC 1157 ......................... 24

TABLE 3: STRUCTURE DES 5 DIFFERENTS PDUS PAR LA RFC 1157 ........................ 25

TABLE 4: EXEMPLE DE BULKGET ............................................................................ 26

TABLE 5: STRUCTURE DES TRAPS-PDUS .................................................................. 27

TABLE 6: SERVICE SUPPORT SELON ITIL ................................................................. 32

TABLE 7: SERVICE DELIVERY SELON ITIL ............................................................... 32

TABLE 8: ACCESS LIST POUR ACCES SNMP ............................................................ 36

TABLE 9: CONFIGURATION DE SNMP-SERVER .......................................................... 37

TABLE 10: SNMP-LOCATION ET CONTACT ................................................................ 37

TABLE 11: AUTRES PARAMETRES GENERAUX ......................................................... 38

TABLE 12: SHO VER ................................................................................................. 40

TABLE 13: PREMIERE COLLECTE D’INFORMATION PAR NET ::SNMP ........................ 40


/124

JMJ

TABLE 14: CISCO MIB BROWSER POUR LA MIB CISCO-STACK-MIB, OBJECT = CHASSISMODEL ....................................................................................................... 41

TABLE 15: CISCO MIB BROWSER POUR LA MIB CISCO-STACK-MIB, OBJECT = CHASSISSERIALNUMBER ......................................................................................... 42

TABLE 16: CISCO MIB BROWSER POUR LA MIB CISCO-STACK-MIB, OBJECT = MODULSWVERSION .................................................................................................. 42

TABLE 17: EXEMPLE DE PROGRAMME PERL COLLECTANT CES 1ERES INFORMATIONS ........................................................................................................ 46

TABLE 18: CISCO MIB BROWSER POUR LA MIB IF-MIB, OBJECT = IFINOCTETS ...... 50

TABLE 19: CISCO MIB BROWSER POUR LA MIB IF-MIB, OBJECT = IFOUTOCTETS ... 50

TABLE 20: CISCO MIB BROWSER POUR LA MIB CISCI-PROCESS-MIB, OBJECT = CPMCPUTOTAL5MINREV .......................................................................................... 51

TABLE 21: CISCO MIB BROWSER POUR LA MIB IF-MIB, OBJECT = IFINERRORS ...... 51

TABLE 22: CISCO MIB BROWSER POUR LA MIB IF-MIB, OBJECT = IFOUTERRORS ... 52

TABLE 23: EXEMPLE DE COMPTEURS ACCESSIBLES PAR CLI ................................. 53

TABLE 24: EXEMPLE DE DEFINITION DE COMPTEUR .............................................. 54

TABLE 25: SNMPGET EN CONNAISSANT L’INDEX ..................................................... 57

TABLE 26: SNMPWALK EN CONNAISSANT L’INDEX ................................................... 58

TABLE 27: EXEMPLE DE PROGRAMME PERL DE COLLECTE D’INFORMATIONS ....... 62

TABLE 28: CONFIGURATION D’UN PORT DE SWITCH CISCO POUR LA VOIP ............. 64

TABLE 29: TABLE DES ADRESSE MAC D’UN PORT DE SWITCH « VOIP » ................... 64

TABLE 30: DETERMINATION GROSSIERE D’UN TEMPS DE REPONSE ....................... 68

TABLE 31: PERL : TABLE D’ADRESSE MAC PAR PORT POUR LE VLAN 126 .............. 86

TABLE 32: PERL : CORRESPONDANCE PORT – INTERFACE ...................................... 87

TABLE 33: PERL : CORRESPONDANCE INDEX – INTERFACE .................................... 88


/124

JMJ

1 Glossaire

Adresse IP Identificateur numérique de chaque équipement réseau, au niveau IP. Adresse MAC Identificateur unique, utilisé par le niveau 2 de l’OSI. Identifie

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 dans l’internet.

Obsolète Equipement réseau Un appareil connectés au réseau : Switch, routeur, téléphone,… FQDN Fully qualified Domain Name IETF Internet Engineering Task Force : Un groupe auto-organisé de

personnes travaillant ensemble dans le but d’améliorer la technologie de l’Internet voir http://www.ietf.org/

IP Internet Protocol MAC Media Access Control. Sous-couche basse du niveau 2 de l’OSI. MIB Management Information Base : RFC 1156 qui décrit les objets

managés de la MIB OSI Open Systems Interconnection SMI Structure of Management Information : RFC 1155 qui décrit comment

les objets managés de la MIB sont définis. SNMP Simple Network Management Protocole : RFC 1157 qui définit le

protocole utilisé pour manager les objets définis dans la MIB. RFC Request For Comments : Ces documents sont les produits officiels de

l’IETF. Ils sont gratuits, disponibles sur l’Internet. WAN Wide Area Network


/124

JMJ

2 Convention de style

Texte en italique : Terme utilisé appartenant au « vocabulaire » de SNMP et dont la définition est donnée dans ce document. Texte sur fond grisé : élément(s) (un ou plusieurs) du menu d’une application – celle citée dans le contexte- traduisant la hiérarchie de ce menu. Par exemple Entity/Add/Object signifie la sélection au niveau 1 du menu de Entity, puis de Add dans le niveau 2 de ce même menu, puis de Object dans le niveau 3 de ce même menu.

Figure 1: Hiérarchisation du menu

3 Objectifs

Le but du présent document est de donner un aperçu pratique du protocole SNMP, de décrire comment s’en servir activement et efficacement pour superviser un réseau TCP/IP. Vous n’échapperez pas bien sûr à un peu de théorie, le minimum requis, afin de vous permettre de comprendre et surtout de savoir ou rechercher lorsque vous rencontrerez un obstacle. Il s’agit de décrire comment lire des informations relatives aux équipements réseau par SNMP, ainsi que de délivrer des « Best-Practices » basés sur plus de 12 ans d’expérience dans la supervision de réseau dans des entreprises de taille nationale et internationale, à plusieurs milliers d’équipements actifs (switchs, routeurs, acces-points,…). Ce document doit être considéré comme un livre de recettes concernant SNMP, pas un cours sur SNMP. D’autres ouvrages le feront bien mieux que celui-ci. Les exemples seront basés, d’une part sur des équipements de réseau du fabricant Cisco, et d’autres par, sur des outils, tous gratuits et disponibles sur l’Internet. Quelques programmes en PERL seront proposés dans diffé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’explication. En particulier ne seront pas traduits les termes propres à SNMP. Toute la théorie, les RFC et autres standards sont disponibles sur Internet et ne seront que très rapidement rappelés ici.


/124

JMJ

4 Audience

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

4.1 Pré requis Une bonne connaissance de la supervision de réseau est un plus. Des notions de configuration d’équipement réseau par CLI, permettront de mieux comprendre certains chapitres. Des notions de programmation PERL permettront d’adapter à votre propre réseau les exemples joints.

5 Opinions

Je n’ai aucun lien, aucun intérêt avec un fabricant quelconque, que ce soit d’é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 reposent sur 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 avis teinté de l’aspect opérationnel, du côté d’un utilisateur. Il ne s’agit pas d’une synthèse toute théorique de « data sheets », mais d’un avis personnel et en tant que tel, subjectif.


/124

JMJ

6 Introduction

SNMP n’est pas l’acronyme de la Société Nationale des Moniteurs de Plongée. SNMP est l’acronyme de Simple Network Management Protocol. Simple : Le protocole est simple – même si cela ne saute pas spontanément aux yeux-, la représentation des données est parfois déroutante de même que les corrélations nécessaires de plusieurs informations de base, pour construire une information pertinente pour celui qui veut l’exploiter : la construction de la table de routage d’un routeur, de la table des Address MAC d’un Switch,…, nécessitent de mettre en corrélation beaucoup d’informations Simples. Network Management : C’est donc pour gérer un réseau que l’on utilise SNMP. Sa puissance fait qu’actuellement beaucoup d’autres équipements sont gérables pas SNMP (serveurs, imprimantes, …). Protocol : Un protocole de communication défini le comment : Comment accéder à l’information, comment transmettre une information, que représente cette information.

7 La théorie

7.1 En résumé Avec l’apparition de réseaux de plus en plus étendus et par la même de plus en plus compliqués et surtout interconnectés et hétérogènes, est apparue la nécessité fondamentale de pouvoir gérer ces réseaux de manière distante sans utiliser une technologie «propriétaire», dépendante d’un constructeur. L’IETF, a eu l’intelligence de définir en même temps comment construire un réseau TCP/IP et comment le gérer. Ces définitions sont publiques – accessibles gratuitement à 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 différents. Pas d’interdépendance entre l’outil de gestion et l’équipement gérer.

Ø Universellement supportée : Tous les composants d’un réseau TCP/IP sont tenus de

supporter SNMP. Ses possibilités font que SNMP se répand aux imprimantes, aux téléphones, ….

Ø Portable : non limité à une architecture, un langage de programmation un système

d’exploitation. Ø Extensible pour pouvoir évoluer en même temps que le réseau et ses composants. Ø Distribuée : La supervision du réseau peut être partagée de manière géographique ou

fonctionnelle. Il n’y à, aujourd’hui, pour certaines opérations nécessaires à la gestion d’un réseau, aucune alternative à SNMP.


/124

JMJ

7.2 Historique A mon sens, le succès mondial de l’Internet est en majeure partie dû au fait que ses spécifications techniques soient issues du travail d’un groupe indépendant de tout constructeur, sans membre, sans adhésion, et ouvert à tout un chacun : l’Internet Engineering Task Force (IETF) dont le soucis permanent est l’amélioration de l’Internet. Par Engineering il est entendu que l’IETF ne prend en considération que les aspects 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 une centaine de groupes de travail qui se partagent les travaux techniques, dont les résultats sont principalement les Request For Comments (RFC) qui « recommandent » comment concevoir, utiliser et superviser l’Internet. L’un des comités de l’IETF est l’Internet Architecture Board (IAB), en charge des orientations à long termes de l’Internet. Parmi les rares recommandations émises par l’IAB figure, dès 1988, la RFC 10521 : « IAB Recommendations for the Development of Internet Network Management Standards », c'est-à-dire « Recommandations pour le développement des normes de gestion du réseau Internet ». Cette RFC défini une stratégie de management à court terme basée sur SNMP (RFC 10982) et une stratégie à long terme basée sur CMIS/CMIP « Common Management Information Service and Protocol » de l’OSI qui a donné CMOT « CMIS Over TCP/IP » (RFC 1095). En même temps, les informations de gestion ainsi que leur structure étaient définies de manière à être compatibles à la fois avec SNMP et l’OSI dans deux RFC :

RFC 10653 : « Structure and Identification of Management Information for TCP/IP-based internets », appelée aussi SMI RFC 10664 : « Management Information Base for Network Management of TCP/IP-based internets », appelée aussi MIB.

Ces RFC recevant de l’IAB le statut de « Recommanded », il est attendu que tous les réseaux TCP/IP construits à partir de ce moment adoptent et implémentent ces spécifications. En d’autres termes d’être gérables par SNMP, SMI et MIB. A ce jour, il est attendu que la RFC 1052 soit respectée par la mise en œuvre des : RFC 1155 (SMI ex-1065), RFC 1156 (MIB ex 1066) et RFC 1157 (SNMP ex- 1098) Nous avons donc : Un protocole qui nous permet de manager des objets (SNMP = Le « Comment »), ces objets sont décrits dans les MIB (Le « Quoi »), la structure de ces objets est définie par la SMI (Le « C’est Quoi »). J’ai essayé de mentionner dans ce document les versions les plus à jour des RFC. 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.

1 Voir : http://tools.ietf.org/html/rfc1052 2 Voir http://rfc-ref.org/RFC-TEXTS/1098/index.html. Rendue obsolète par RFC 1157 3 Voir http://tools.ietf.org/html/rfc1065. Rendue Obsolète par RFC 1155 4 Voir http://tools.ietf.org/rfc/rfc1066.txt Rendue Obsolète par RFC 1156


/124

JMJ

7.3 Architecture C’est la RFC 1157 qui définit le modèle architectural de SNMP :

Ø 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 de

management- d’effectuer les fonctions de management requises par la station de management. C’est un modèle (certes inhabituel) client-serveur, la station de management est le client, les agents sur les équipements de réseau sont les serveurs.

Ø Un protocole – SNMP – est utilisé pour échanger des informations de management

entre la station de management et les agents des équipements réseau.

Réseau TCP/IP

ServeurVoIP

Station de management

Imprimante

Ca ta lyst 3560 SERIES

SYST

MODE

SPEEDDUPLX

POE

STAT

RPS1 X

1 8 X

1 7 X

1 6 X2 X

1 5 X 3 1 X

3 2 X 3 4 X

3 3 X 4 7 X

4 8 X

11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 481 2 3 4 5 6 7 8 9 10

1

PoE-48

3

2 4

Switch

CISCO S YSTEMS

Catalyst 2900 Se ries

Routeur

MIB Agent

Elément réseau

Figure 2: Le modèle architectural de SNMP selon RFC 1157

La station de management et les équipements réseau supervisés par cette dernière sont appelés la community (communauté). SNMP minimise explicitement le nombre et la complexité des fonctions de management réalisées par l’agent tout en restant suffisamment extensible pour pouvoir supporter des aspects non entrevus de la gestion et de l’opération du réseau. Dans la suite du document nous nous plaçons du point de vue de la station de management.


/124

JMJ

7.4 Information de management

7.4.1 Représentation Les informations de management échangées par le protocole SNMP sont représentées conformément au langage ASN.15 (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 et le langage d’implémentation peuvent être différents. ASN.1 n’est ni plus ni moins qu’un langage de définition (pas de l’implémentation) : 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 langage de programmation. Un sous ensemble des BER (Basic Encoding Rules Recommandation X.690) est utilisé pour « compiler » l’ASN.1 en un flux d’octets transmissibles sur une ligne de communication. Ceci rend encore une fois SNMP indépendant d’un constructeur qui souhaiterait 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’équipement réseau, quel qu’en soit le constructeur, pour savoir « Combien d’octets ont transités par le lien Numéro 1 », par exemple. En particulier sont définies les règles de nommage des informations permettant une identification sans ambigüité de celle-ci par l’assignation d’un Object IDentifier (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 de donné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 Table 1: ifOperStatus) peut prendre les valeurs 1,2 ou 3, pas 0,1 ou 2)

Ø OCTET STRING : Chaine de caractères encodée sur 0 ou plusieurs octets. Attention

est aussi utilisé pour représenter des adresses MAC, auquel cas ce ne sont pas des caractères ASCII qui sont retournés, mais du binaire.

Ø OBJECT IDENTIFIER : voir page7.4.1.118 : chapitre 7.4.1.1OIDs. Ø 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

5 http://www.itu.int/ITU-T/asn1/ et l’excellent http://www.oss.com/asn1/resources/books-whitepapers-pubs/dubuisson-asn1-book.PDF


/124

JMJ

Et le types suivants

Ø NetworkAddress : Une adresse de l’un des protocoles possibles. Aujourd’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 OCTET STRING de

longueur 4.

Ø Counter : Nombre entier de 32 bits (0 – 232-1) qui ne peut que croitre avec 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 compteurs par 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é en 100emes de

secondes depuis une référence. C’est la description du type de l’objet qui définit la référence. Souvent la référence est le démarrage de l’agent.

Ø Opaque : Ce type permet le passage d’une syntaxe ASN.1 encodée comme une

OCTET STRING, en tant que paramètre. A noter : Il n’est demandé à une implémentation conforme de la RFC, que d’accepter et de reconnaî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 exemples pour apporter un peu de lumière :

Ø Le nombre d’octets reçus ou émis, le nombre d’erreurs sur une interface sont des Counters, dont on ne peut tirer un enseignement que si l’on procède par Deltas successifs et réguliers : savoir que sur une interface il y a eu 100 000 erreurs en soit n’apporte que guère d’information si l’on ne sait pas si ces erreurs ont eu lieu depuis les 2 ans que l’équipement fonctionne, ou si ces erreurs ont eu lieu dans les 5 minutes qui viennent de s’écouler.

Ø Le nombre de connections TCP est par contre un objet dont la valeur actuelle, la

mesure instantanée, est importante, pas leur cumul : c’est le type Gauge qui convient ici.

De plus amples renseignements sur ASN.1 et BER peuvent être trouvées ici : http://luca.ntop.org/Teaching/Appunti/asn1.html


/124

JMJ

7.4.1.1 OIDs Comme nous l’avons vu, les règles de nommage reposent sur une structure arborescente. La racine (ou le tronc) n’est pas nommée, 3 «branches » : iso, ccitt, et join-iso-ccitt sont immédiatement accessibles, ainsi que : internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } Ce qui implique que les OIDs de la branche internet commencent tous par 1.3.6.1 selon le schéma suivant :

iso ccitt join-iso-ccitt

.1 .2 .3

org.3

.6

dod

internet.1

directory mgt experimental private

.1 .4.3.2

Racine / Tronc, non nommé

mib-2

Tous les OIDs utilisés dans ce document se situent sous ce niveau et donc commencent tous par .iso.org.dod.internet [.1.3.6.1]

Réservé- OSI Réservé- IAB.1

IANA => Constructeurs

Structure arborescente des OIDs Une autre façon de représenter cette arborescence est donné par l’outil Getif6

Figure 3: Représentation de l’arborescence par Getif

6 Voir annexes


/124

JMJ

7.4.2 MIB Maintenant que nous avons vu comment accéder à une information, voyons quelles informations sont accessibles. C’est ici que l’on commence à rencontrer quelques difficultés. En effet, si de nombreuses informations sont accessibles à partir de la branche iso.org.dod.internet.mgt dont la nature est parfaitement documentée dans la RFC 1156, encore plus d’informations sont accessibles à partir de la branche « private », dont le développement est laissé libre aux constructeurs et dont la définition 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 MIBs soient accessibles au plus grand nombre, d’autres constructeurs, dont un français dont je tairai le nom, conservent la définition de leurs « MIBs Constructeurs » bien secrète. Néanmoins, les MIBs définies par la RFC 1156 seront toujours définies comme suit et permettent déjà beaucoup d’opérations de supervision.

7.4.2.1 RFC 1156 La RFC 1156 défini 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’un groupe s’applique à une implémentation, alors elle doit implémenter tous les objets de ce groupe». En d’autres termes, toutes les branches ne sont pas explorables : Le groupe EGP ne doit être implémenté que si le protocole EGP est implémenté. (Cela n’a aucun sens de chercher [de fournir] des informations sur quelque chose qui n’existe pas). Chacun de ses groupes seront explorés en détail dans les paragraphes suivants. Pour bien illustrer l’importance de comprendre comment une MIB est décrite, attardons-nous un moment sur un objet de cette MIB, par exemple ifOperStatus. La RFC 1156 nous présente cet objet de la sorte

OBJECT: ------- ifOperStatus { ifEntry 8 } Syntax: INTEGER { up(1), -- ready to pass packets down(2), testing(3) -- in some test mode } Definition: The current operational state of the interface. The testing(3) state indicates that no operational packets can be passed. Access:


/124

JMJ

read-only. Status: mandatory.

Table 1:ifOperStatus Ce qui peut être traduit de la sorte : L’objet (comprendre ici l’information) a pour nom ifOperStatus ifOperStatus est la 8eme branche sous la branche ifEntry (elle-même définie plus haut dans la RFC) Cet objet est représenté par un entier qui peut prendre les valeurs 1 signifiant up 2 signifiant down 3 signifiant testing La définition 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 de modifier cet objet. L’implémentation de cet objet est obligatoire.

Un administrateur réseau pourra donc, en lisant cette variable pour une interface donnée, savoir si un équipement est branché à cette interface. Il ne pourra pas, par SNMP, « débrancher le câble ». Dans l’exemple ci-dessous, avec l’outil Getif, nous lisons, sur le switch nommé mgth03, le statut opérationnel des interfaces de ce switch. 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 différentes définitions données par la RFC. Le lien entre les valeurs lues et les ports physiques du switch sera explicité dans un paragraphe ultérieur.


/124

JMJ

Figure 4: Exemple d’OID

Les OIDs sont donc une espèce de jeu de piste dont la syntaxe ne devrait pas être étrangère au programmeur d’un langage orienté objet.


/124

JMJ

7.5 Protocole La RFC 1157 défini aussi la communication entre la station de management et les équipements de réseau. Cette communication repose sur l’échange de messages. Chacun de ces messages est entièrement et indépendamment contenu dans un datagramme UDP unique utilisant les BER d’ASN.1 Ces messages sont transportés sur TCP/IP en utilisant le protocole UDP, donc moins fiable 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. Tous les messages sont reçus sur le port UDP 161 à l’exception des Traps qui le sont sur le port UDP 162. Un message est formé d’ :

Ø Un identifiant de version Ø Une Community String Ø Un Protocol Data Unit (PDU)

Figure 5: Encapsulation des messages SNMP

7.5.1 Versions SNMP version 1 noté aussi SNMPv1 est l’implémentation initiale de SNMP telle que décrite dans la RFC 1157. C’est le standard recommandé et le plus utilisé. 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 version 2 est scindé en SNMPv2p (RFC 1441) et SNMPv2u (User-based security RFC 1909, RFC 1910) SNMPv2* (User-based Security + nouvelles fonctions RFC 1901), peut être vu comme le meilleur de SNMPv2p et SNMPv2u). Deux standards SNMP ne pouvant coexister, l’IETF trouve un consensus uniquement 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 versions précédentes en termes de sécurité. De par sa complexité et son statut expérimental, 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 ne mettez pas en œuvre SNMPv3, et vous recommanderont de le faire. Dans le chapitre 9.1.1 Sécurité page 36 seront présentées des recommandations en termes de sécurité.

Trame Ethernet Paquet IP Datagramme UDP Message SNMP


/124

JMJ

7.5.2 Community String Comme défini en page 15, la community est un domaine de management, regroupant la station de management et les équipements réseau managés par celle-ci. La Community String est une forme de mot de passe assurant une protection rudimentaire de la communication entre les différents membres de la Community contre des accès non autorisés. La valeur par défaut est « public » pour les lectures et « private » pour les écritures. Best Practice N’autorisez jamais la connexion d’un équipement sans avoir modifié les valeurs des Community String « Read » et « Write ».

7.5.3 Protocol Data Unit (PDU) Ce sont les données transmises dont le format dépend du message envoyé. Le protocole défini 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’ordre lexical. Est

utilisé pour traverser toute une table de la MIB, ou toute la structure arborescente de la MIB.

Ø GetResponse-PDU. Retourne la réponse d’une requête « Get » ou sert d’acquittement

d’une requête « Set ». Ø SetRequest-PDU. Fixe la valeur d’un ou plusieurs objets (variables). Très rarement

utilisé. Ø Trap-PDU. Notification non sollicitée (c’est le seul message provenant de

l’équipement supervisé qui ne soit pas une réponse à une requête de la station de management) de l’agent à la station de management.

RFC1157-SNMP DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks FROM RFC1155-SMI; -- top-level message Message ::= SEQUENCE { version -- version-1 for this RFC INTEGER { version-1(0) }, community -- community name OCTET STRING, data -- e.g., PDUs if trivial ANY -- authentication is being used } -- protocol data units PDUs ::= CHOICE { get-request GetRequest-PDU, get-next-request GetNextRequest-PDU,


/124

JMJ

get-response GetResponse-PDU, set-request SetRequest-PDU, trap Trap-PDU } -- the individual PDUs and commonly used -- data types will be defined later END

Table 2: Définition des 5 différents PDUs par la RFC 1157

Figure 6: Echanges de PDUs entre la station de management et l’équipement supervisé

7.5.3.1 Structure de ces PDUs La RFC 1157 défini la structure de ces PDUs de la manière suivante :

-- request/response information RequestID ::= INTEGER

Réseau TCP/IP


Catalyst 3560 SERIES SYST

MODE SPEED DUPLX POE STAT RPS 1X

18X 17X 16X 2X 15X 31X

32X 34X 33X 47X 48X 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 1 2 3 4 5 6 7 8 9 10

1 PoE-48 3

2 4

Switch

MIB Agent

Trap

temps

Réseau TCP/IP


Catalyst 3560 SERIES SYST

MODE SPEED DUPLX POE STAT RPS 1X

18X 17X 16X 2X 15X 31X

32X 34X 33X 47X 48X 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 1 2 3 4 5 6 7 8 9 10

1 PoE-48 3

2 4

Switch

MIB Agent

Requête

Réponse

temps


/124

JMJ

ErrorStatus ::= INTEGER { noError(0), tooBig(1), noSuchName(2), badValue(3), readOnly(4) genErr(5) } ErrorIndex ::= INTEGER -- variable bindings VarBind ::= SEQUENCE { name ObjectName, value ObjectSyntax } VarBindList ::= SEQUENCE OF VarBind

Table 3: Structure des 5 différents PDUs par la RFC 1157 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 variable) existant dans la MIB de l’équipement supervisé.

Ø 3 badValue : Tentative d’assignement d’une valeur inconsistante à un objet

Ø 4 readOnly : Lecture seule. Non utilisé suite à une erreur d’édition. Le code (2)

noSuchName est retourné en cas de tentative d’écriture d’un objet accessible en lecture-seule.

Ø 5 genErr : La valeur d’un objet (d’une variable) ne peut être déterminée et la cause de

cette indétermination n’est pas couverte par les cas d’erreur précédents. ErrorIndex : Fourni des informations supplémentaires (quelle variable dans une liste) dans le cas d’une réponse avec erreur. VarBind (Variable Binding) : Couple formé par le nom d’une variable et sa valeur. VarBindList : Liste de VarBinds


/124

JMJ

Une amélioration sensible apportée par SNMPv2c (et v3) est la requête « GetBulk » 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à dans SNMPv1de demander plusieurs OIDs dans la VarBindList, la réponse de l’agent est limitée en taille. Il est impossible de demander une réponse qui excèderait la taille maximale du message de l’agent, sans obtenir en réponse l’erreur « tooBig ». Avec GetBulk, il est demandé à l’agent de « remplir » son message de réponse jusqu’à la taille maximale de celui-ci, même si ce message ne contient pas la totalité de la réponse. La station de management demandera la suite des informations 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.à.d le nombre de variable (OIDs) pour lesquelles un GetNext sera fait (par l’agent). M : Max-repetitions : le nombre de GetNext réalisés par l’agent pour chacun des OIDs restants. Voici un exemple utilisant Net-Snmp sur une distribution Linux Fedora Core 12 :

# /usr/bin/snmpbulkget mgth03 -c MyCommunity -v2c -Cn1 -Cr5 sysLocation ifdescr ifType ifInOctets .1.3.6.1.2.1.1.6.0 = STRING: R34.FLR01 Verteiler .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.2.10002 = STRING: FastEthernet0/2 .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.2.10003 = STRING: FastEthernet0/3 .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 Bleu-clair,Violet,bleu-foncé se répètent 5 fois (option –Cr5)

Table 4: Exemple de bulkGet Dans cet exemple, une requête retourne 16 VarBinds dans une réponse. Une transaction unique (2 messages) au lieu d’une transaction par variable: l’utilisation du réseau et celle du CPU de l’agent sont optimisées.(voir aussi le chapitre 11.3.2


/124

JMJ

SNMP V2c et Getbulk page 72).

7.5.3.2 Traps Une Trap est un message non sollicité (Ce n’est donc pas une réponse à une requête) envoyé par l’agent à la station de management. Il s’agit en principe d’un évènement important détecté par l’équipement supervisé et dont le l’occurrence doit être signalée. Le type d’évènement générant une Trap est configuré - par la station de management ou autrement - sur l’équipement supervisé. Les Traps suivantes (et les évènements associés) sont définies par la RFC 1157 :

Trap-PDU ::= [4] IMPLICIT SEQUENCE { enterprise -- type of object generating -- trap, see sysObjectID in [5] OBJECT IDENTIFIER, agent-addr -- address of object generating NetworkAddress, -- trap generic-trap -- generic trap type INTEGER { coldStart(0), warmStart(1), linkDown(2), linkUp(3), authenticationFailure(4), egpNeighborLoss(5), enterpriseSpecific(6) }, specific-trap -- specific code, present even INTEGER, -- if generic-trap is not -- enterpriseSpecific time-stamp -- time elapsed between the last TimeTicks, -- (re)initialization of the network -- entity and the generation of the trap variable-bindings -- "interesting" information VarBindList }

Table 5: Structure des Traps-PDUs Les évènements suivants génèrent, si l’équipement supervisé est ainsi configuré, une Trap, appelée generic-trap :

Ø 0 coldStart : Réinitialisation telle que la configuration de l’agent peut être altérée. En général, une mise sous tension.

Ø 1 warmStart : Réinitialisation telle que la configuration de l’agent n’est pas altérée.

En principe, un « reboot » ou un « reload ».

Ø 2 linkDown : Défaut/panne sur un des liens de communication connu de l’agent.

Ø 3 linkUp : Un des liens de communication connu de l’agent est disponible.


/124

JMJ

Ø 4 authenticationFailure : Défaut d’authentification. En général, une requête

effectué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 enterpriseSpecific : Un évènement spécifique au constructeur de l’objet supervisé

est survenu.


/124

JMJ

7.6 Synthèse du chapitre Pour illustrer le chapitre qui s’achève, voyons ce qui se passe sur le réseau lorsque le programme Getif est démarré pour un switch Cisco 3560 24 ports nommé mgth03 : (la Community String ainsi que le nom de domaine ont été masqués) Une fois le champ « Host Name » renseigné, Getif recherche des informations par SNMP sur cet équipement afin d’afficher l’écran suivant:

Figure 7: Getif sur mgth03

En sniffant avec Wireshark les transactions SNMP entre le PC hébergeant Getif et le switch mgth03 les deux messages suivant sont observées :

Figure 8: Traces Wireshark du lancement de Getif sur mgth03

7.6.1 Requête Nous voyons un premier message, issu du PC (Adresse IP Source = 169.134.127.22) à destination du switch mgth03 (Adresse IP Destination = 169.233.2.3) de type get-request :


/124

JMJ

Figure 9: 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 Ethernet (2e ligne), transportant de l’IP (3e ligne) entre le PC et le switch mgth03 (ce sont leurs adresses IP), véhiculant un datagramme UDP (4e ligne) à destination du 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’identifiant de la requête est 9786 (Ligne 10), soit 0x262A (positions 0x44 et 0x45), message sans erreur. La VarBindList contient 8 éléments (lignes 14 à la fin, soient les positions 0x50 à la fin) :

La première valeur demandée est le « sysDescr » dont l’OID est 1.3.6.1.2.1.1.1.0 et 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 les premiers « 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 » des VarBinds est « unspecified », ceci afin que la syntaxe et l’encodage ASN.1 soient respectée. Et ainsi de suite . . .

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


/124

JMJ

Le message de réponse est construit de la même manière que la requête, intéressons-nous au protocole SNMP :

Figure 10: 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 VarBindList. 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 7: Getif sur mgth03).


/124

JMJ

8 Le Network Operating Center

8.1 Pourquoi superviser un réseau La supervision du réseau n’est pas une fin en soi. La seule et unique raison pour laquelle un réseau est supervisé est que dans le monde actuel, chaque interruption de réseau à un coût et ce coût peut croitre à une vitesse vertigineuse selon l’activité de votre entreprise. Ce peut être un coût imputable à :

• Perte de productivité (nombre de collaborateurs affectés x cout horaire x 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’instant seule la supervision de multiples paramètres permet d’ une part d’observer l’état de santé du réseau (pro-actif), d’autre part de diagnostiquer finement pour rendre rapidement le réseau disponible.

8.2 Missions du NOC

8.2.1 Le NOC et ITIL / COBIT Dans le cadre de ITIL et/ou de COBIT, les missions du NOC s’inscrivent pleinement dans « Délivrer et Supporter ».

Figure 11: COBIT – extrait

Pour pouvoir définir ce qu’il y a à faire, il faut définir de quoi le NOC est responsable, quels services sont sous sa responsabilité. Si nous prenons le réseau type tel que décrit au paragraphe 9


/124

JMJ

Le « réseau type » supervisé 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 filiales : WAN Access. • De l’accès au réseau dans fil : WiFI Access.

Et voyons ce que l’ITIL définit dans le Service Support et le Service Delivery

8.2.1.1 Service Support Le domaine « Service Support » s'attache au fonctionnement et au support de l'infrastructure technologique. Il est décomposé selon les 6 processus suivants :

Processus Objectifs

Gestion des configurations Gérer l'infrastructure technologique en faisant un état des lieux de l'existant afin de mieux le gérer et le faire évoluer.

Gestion des incidents

Mieux détecter les incidents, améliorer le délai de résolution des incidents selon leur criticité sur le fonctionnement de l'entreprise.

Gestion des problèmes

Mieux gérer les problèmes récurrents et mettre en œuvre des solutions de prévention afin de réduire leur occurrence, voire les supprimer.

Gestion des changements Mettre en œuvre des démarches de conduite du changement afin d'anticiper les effets de bord.

Gestion des mises en œuvre S'assurer de l'adéquation du service avec les besoins métiers.

Gestion de la disponibilité Assurer un niveau de disponibilité suffisant à un coût raisonnable.

Table 6: Service Support selon ITIL

8.2.1.2 Service Delivery Le domaine « Service Delivery » s'attache la planification et l’amélioration à long terme de la fourniture de services liés à l'infrastructure technologique. Il est 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 service renégociés périodiquement.

Gestion des capacités et performances Vérifier l'adéquation des capacités et performances avec les exigences actuelles et à venir.

Gestion de la continuité des services IT Définir et mettre en œuvre des délais contractuels pour la reprise après incident.

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

Table 7: Service Delivery selon ITIL Parmi les missions principales d’un NOC on peut donc citer :

• Améliorer/maintenir la disponibilité du réseau. • Superviser les équipements du réseau afin de garantir qu’aucune panne n’est due à

un équipement ayant atteint ses limites de performances.


/124

JMJ

• Garantir que les informations de configurations 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 qui synthétisent ce

qui se passe sur le réseau.


/124

JMJ

8.3 Les outils du NOC Pour remplir ses missions, l’un des principaux outils du NOC, si ce n’est Le principal outil du NOC est la station de management telle que définie page 15 chapitre 7.3 Architecture. Cette station de management est avant tout un SNMP-Collector, c'est-à-dire une machine qui, par SNMP, va collecter un nombre impressionnant d’informations sur les équipements réseau, et présenter une synthèse –de préférence graphique- de cette collecte. Malgré tout ce que vous pourrez entendre des zélés commerciaux ou lire sur les pages WEB éditées par des marqueteurs géniaux, l’outil unique « qui fait tout et tout seul – yaka clicker…» n’existe pas. Tenez-vous le pour dit. Il existe néanmoins quelques outils –très peu en fait- qui sont universellement reconnus et dont la qualité des informations fournies et la fiabilité de fonctionnement sont largement reconnues, à juste titre à mon avis. Ce sont :

• Hewlett Packard Open View Network Node Manager, qui permet une représentation graphique de la topologie et de l’état de santé de votre réseau. En en seul coup d’œil vous savez si c’est « OK » ou non. Il ne supervise « 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’entend mais impose « sa » vision basée sur une topologie et une hiérarchie définies. 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 de qualité exceptionnelle sur la « santé » de votre réseau. Il s’agit plutôt ici de Baseline Monitoring couplé à une base de données qui rend des diagnostics d’une redoutable précision. Les coûts d’achats et de maintenance 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 solution beaucoup trop chère, mais l’aspect professionnel (pas meilleur) des graphes générés par rapport aux mêmes graphes générés par MRTG peut séduire ou rassurer. De toute façon, ce ne sont en final que des variables SNMP qui sont représentées graphiquement.

• Micromuse Netcool, en tant que « concentrateur d’évènements ». Les coûts d’achats

et de maintenance sont élevés. Outils à éviter : Les outils Cisco. Tous. Définitivement… . 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 différentes variables et en particulier de n’importe quelle valeur accessible par SNMP – mais pas seulement- , sur n’importe quel équipement réseau.

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


/124

JMJ

Mes 3 philosophies de travail :

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

2. Il faut investir dans les personnes, pas dans les outils. Il vaut mieux un ou 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 des outils à 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 – Bell Labs

8.4 Synthèse du chapitre Dans toutes les entreprises et partout dans le monde, la recherche d’une solution à un problème « informatique » débute toujours par le réseau, car les personnes en charge de celui-ci sont capables de fournir des rapports étayés de toutes les mesures nécessaires, les disculpant – la plupart du temps- de toute responsabilité dans le problème détecté. Le problème est ensuite transmis aux personnes du « Système », qui s’en tirent nettement moins bien, mais – la plupart du temps aussi- arrivent à se disculper. Enfin le problème arrive aux « Applications ». . . Il convient donc pour le NOC d’être en mesure de donner le plus rapidement possible tous les détails caractérisant le réseau, avant l’apparition d’un problème (changement de hardware, changement de configuration, traps, mesures de performance, historique (Baseline monitoring), etc etc). Pour ma part, je privilégie pour un outil donné, la facilité d’utilisation aux fonctionnalité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 Euros la 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’autres mots était indispensables et demain cela en sera d’autres. Par contre le travail du NOC est resté sensiblement identique par-delà ces « générations » de solutions techniques. Ne vous attendez pas à ce que quelque machine virtuelle et « cloudisée » n’égale jamais un bon ingénieur connaissant « son » réseau. La solution mise en œuvre doit donc être capable de fournir des données et des rapports ayant un sens (cela peut paraître trivial), faciles de lecture et d’interprétation, sous forme graphique. Il est de la responsabilité du NOC de définir, avec ses « clients » et ses fournisseurs, les SLA (Service Level Agrement), définissant les durées acceptées de 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. Une personne seule, pour un service 7x7 sera d’astreinte tous les week-ends…Si les outils ne permettent pas un accès distant, cette personne devra se rendre sur son lieu de travail à toute heure du jour et de la nuit pour effectuer un diagnostic. Enfin il est aussi de la responsabilité du NOC de savoir s’il vaut mieux s’occuper du problème de la Filiale A, ou 250 collaborateurs sont bloqués suite à un dysfonctionnement, ou si la lenteur du poste de travail du directeur financier 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 le problème est annoncé par le directeur informatique qui est en ce moment même en réunion avec ce directeur chez qui « A la maison, le Wifi marche mieux qu’ici… ». Cela dépend de la culture de votre entreprise. . . Cela dépend de vous.


/124

JMJ

9 Le « réseau type » supervisé

Le schéma ci-dessous représente le réseau type qui sera 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, interconnectant en étoile, un Centre de Calcul (CdC) à de nombreuses filiales distribuées géographiquement au niveau national ou international. Les puristes me pardonneront de mélanger les niveaux 2 et 3 de l’OSI, c’est purement dans un but pédagogique. Ce réseau comprend un centre de calcul (CdC) hébergeant tous les serveurs utilisés par les applications s’exécutant dans les N filiales. Le LAN de ce centre de calcul est segmenté en plusieurs VLANs : Serveurs WEB, Serveurs Base De Données, etc, etc, Vlans transportés sur plusieurs switchs. L’accès au backbone est assuré par un fournisseur. Pour des raisons de redondance, une double connexion est assurée en utilisant 2 technologies différentes, une Principale et une Backup, sans partage de charge (Wan_P et 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- le centre de calcul dispose de deux routeurs. Le même concept est mis en œuvre dans les filiales, le seul changement notable est le nombre de connexions possibles (ordre de grandeur : plusieurs milliers dans le centre de calcul, jusqu’à quelques centaines dans une filiale), ainsi que le découpage fonctionnel des VLANS. Dans une filiale seront plutôt définis les VLANs Bureautique, Téléphonie, WiFi, etc etc.

Figure 12: « Réseau Type » supervisé


/124

JMJ

9.1 Configuration 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équence des commandes IOS. Pour de plus amples détails : www.cisco.com.

9.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 toujours utiliser deux Community Strings différentes en lecture et en écriture et surtout pas 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 », ils ne seront pas encryptés, mais ce « malveillant » ne pourra émettre de requêtes, ni pour lire une valeur, ni pour en modifier une : Votre réseau est préservé. Best Practices Community String Read-Only différente de Community String Read-Write et diffé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 » sur cet équipement snmp-server community MailleCSRide RO 1 La Community String en lecture seule est MailleCSRide et l’ACL 1 s’applique snmp-server community MailleCSWraite RW 1 La Community String en lecture/écriture est MailleCSWraite et l’ACL 1 s’applique

Table 8: Access List pour accès SNMP


/124

JMJ

9.1.2 Définition de la Station de Management Les équipements réseau doivent aussi « savoir » à qui envoyer les Traps, et quels sont les évènements générant ces Traps. Une Community String spécifique dédiée aux Traps est aussi définie. 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 Traps est MailleTraps snmp-server enable traps snmp Seules les Traps SNMP (RFC 1157) sont autorisées.

Table 9: Configuration de Snmp-Server

9.1.3 Autres paramètres SNMP Le paramètre snmp-server location permet de saisir un texte d’une longueur maximale de 255 caractères. Il est judicieux d’y mettre une description de la localisation géographique de cet équipement à l’intérieur de la filiale. Ceci vous permettra d’orienter une personne dans la filiale, afin d’y réaliser une action, sans avoir à vous rendre vous-même sur place. Très utile… croyez moi. Best Practices Toujours renseigner et tenir à jour les paramètres snmp-server location et snmp-server contact. Exemple :

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

Table 10: Snmp-location et contact

9.1.4 Autres paramètres généraux

Best Practices Date et Heure : Synchroniser par NTP vos équipements. Dans un environnement

international utilisez partout le même fuseau horaire et de préférence UTC. Heure d’été / Heure d’hiver : ayez vos équipement « à la même heure » que

vous-même, cela vous aidera à analyser les logs. Hostname : Donner un nom, selon vos propres règles de nommage à vos équipement

et surtout étiquetez vos équipements avec ce nom, de manière à ce que l’étiquette soit lisible même quand l’équipement est fixé dans un rack avec un autre équipement dessus et dessous. Cela encore une fois, vous orientera ou vous permettra d’orienter quelqu’un. Attention à la longueur du nom, sur un switch 48 ports, la place pour une étiquette est restreinte.

Loopback : Si possible, toujours définir une interface Loopback dans vos

équipements et en faire la source des Traps émises par l’équipement Banner exec : A utiliser pour afficher des informations pertinentes.(voir exemple)


/124

JMJ

Interface : Utiliser la « description » d’une interface pour noter ce qui y est connecté, si ce qui y est connecté est supervisé ou sous votre responsabilité.

Exemple :

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

Table 11: Autres paramètres généraux


/124

JMJ

9.2 Quelles variables collecter ? Nous l’avons vu plus précédemment, une station de management est avant tout un SNMP-Collector. Que faut-il collecter et à quelle fréquence ? C’est ce que les chapitres 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’avoir chargé 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 en exemple.

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.

9.2.1 Inventaire Un inventaire exhaustif des équipements à superviser est indispensable pour administrer et gérer l’environnement. Sur la partie détaillée du réseau pris en exemple, il y a déjà 12 équipements à inventorier (en admettant que votre fournisseur vous donne un accès SNMP -même si ce n’est qu’en lecture seule- sur ses é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 point d’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, comprenant le type d’équipement, la version logicielle, le numéro de série, etc, etc, si les valeurs adéquates sont stockées et accessibles d’une manière ou d’une autre (dans une base de données, flat file,…).

Figure 13: Equipements à inventorier


/124

JMJ

9.2.1.1 CLI : Sho ver La commande sho ver permet une représentation «humainement–lisible de ces paramètres : Les paramètres surlignés en jaune sont considérés dans cet exemple comme de première importance : le type d’équipement, son numéro de série, sa version logicielle.

mgth03#sho ver . . . Lignes supprimées . . . 512K bytes of flash-simulated non-volatile configuration memory. Base ethernet MAC Address : 00:19:30:2E:E4:80 Motherboard assembly number : 73-9673-09 Power supply part number : 341-0029-05 Motherboard serial number : CAT105255A0 Power supply serial number : DTH1052C2Y0 Model revision number : P0 Motherboard revision number : A0 Model number : WS-C3560-24PS-S System serial number : CAT1052ZM4D Top Assembly Part Number : 800-25861-04 Top Assembly Revision Number : B0 Version ID : V06 CLEI Code Number : COM1X00ARC Hardware Board Revision Number : 0x01

Switch Ports Model SW Version SW Image ------ ----- ----- ---------- ---------- * 1 26 WS-C3560-24PS 12.2(25)SEE2 C3560-IPBASE-M . . .

Table 12:Sho ver

9.2.1.2 Linux et Getif

# snmpwalk -c n0cRead_n0c mgth03 system .1.3.6.1.2.1.1.1.0 = STRING: Cisco IOS Software, C3560 Software (C3560-IPBASE-M), Version 12.2(25)SEE2, RELEASE SOFTWARE (fc1) Copyright (c) 1986-2006 by Cisco Systems, Inc. Compiled Fri 28-Jul-06 07:19 by yenanh .1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.9.1.563 .1.3.6.1.2.1.1.3.0 = Timeticks: (1022322149) 118 days, 7:47:01.49 .1.3.6.1.2.1.1.4.0 = STRING: NOC 061 686 17 50 .1.3.6.1.2.1.1.5.0 = STRING: mgth03. mondomain.com .1.3.6.1.2.1.1.6.0 = STRING: R34.FLR01 Verteiler .1.3.6.1.2.1.1.7.0 = INTEGER: 6 .1.3.6.1.2.1.1.8.0 = Timeticks: (0) 0:00:00.00

Table 13: Première collecte d’information par Net ::SNMP


/124

JMJ

Figure 14: Première collecte d’information par Getif

En analysant la ligne correspondant à la lecture de sysDescr, il est possible de connaître le type de switch : C3560, malheureusement pas suffisamment 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 - PERL par exemple- et n’est pas satisfaisant. La description des Mibs mentionnées ci-dessous s’obtient via le lien suivant :

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en Il est possible d’obtenir directement pas SNMP ces informations en interrogeant la MIB : .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 WS-C3560-24PS. Le lien ci-dessus nous informe que cet objet correspond au : « The manufacturer's model number for the chassis. »

Specific Object Information

Object chassisModel

OID 1.3.6.1.4.1.9.5.1.2.16

Type DisplayString

Permission read-only

Status current

MIB CISCO-STACK-MIB ; - View Supporting Images

Description The manufacturer's model number for the chassis.

Table 14: Cisco MIB browser pour la MIB CISCO-STACK-MIB, Object = chassisModel

La MIB .iso.org.dod.internet.private.enterprises.cisco.workgroup.ciscoStackMIB.chassisGrp.chassisSerialNumber ou .1.3.6.1.4.1.9.5.1.2.17 nous permet d’accéder au numéro de série du switch : CAT1052ZM4D


/124

JMJ

Le lien ci-dessus nous informe que cet objet correspond au : « The serial number of the chassis in a numeric format… », que cet object est obsolète et remplacé par entPhysicalSerialNum dans la ENTITY-MIB. Nous ignorerons cet avertissement pour l’instant. Specific Object Information

Object chassisSerialNumber

OID 1.3.6.1.4.1.9.5.1.2.17

Type INTEGER


Status deprecated

Range 0 - 999999999


Description "The serial number of the chassis in a numeric format. If the chassis uses an alphanumeric serial number, this MIB object will return 0. This object is deprecated and replaced by entPhysicalSerialNum in ENTITY-MIB."

Table 15: Cisco MIB browser pour la MIB CISCO-STACK-MIB, Object = chassisSerialNumber

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 Le lien ci-dessus nous informe que cet objet correspond au : « The serial number of the chassis in a numeric format… » Specific Object Information

Object moduleSwVersion

OID 1.3.6.1.4.1.9.5.1.3.1.1.20

Type DisplayString


Status current


Description The software version of the module.

Table 16: Cisco MIB browser pour la MIB CISCO-STACK-MIB, Object = modulSwVersion

En regardant attentivement la Figure 16: Figure 16: Accès à la version logicielle en page 43, 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


/124

JMJ

• modulSwVersion • modulSerialNumberString

Nous remarquons que dès que nous quittons les MIBs définies par les RFC pour interroger les MIBs Constructeurs, nous pouvons trouver la même information en plusieurs endroits, qui peuvent être obsolète, et cela en fonction de l’équipement réseau (différents équipement du même constructeur réagissent diffé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 connaissance de ces MIBs Constructeurs.

Figure 15: Accès au modèle de switch et au numéro de série

Figure 16: Accès à la version logicielle


/124

JMJ

Remarque : L’indexation des MIBs (telle que dans la table ci-dessus – le .1 à la fin des OIDs-) sera explicitée ultérieurement. Le sysObjectID, d’une valeur de 5637 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 équipement est «up». Utile en cas de recherche de cause de problème. La valeur retournée par sysLocation est aussi à stocker en BdD car il est fort probable que le jour où vous en aurez besoin, l’équipement sera hors service et non interrogeable. Nous avons ainsi collecté les premières informations à stocker dans la BdD. L’outil Jmon stocke ces valeurs dans la table nommée « Obj » de la sorte :

Figure 17: Premières valeurs dans la base de données Jmon

Il ne reste plus qu’à répéter cette collecte pour tous les équipements supervisés. Enfin, ces variables étant relativement statiques (en principe un switch est rarement renommé ou déplacé ou remplacé), la fréquence de collecte de ces informations est relativement basse, de l’ordre de 1 à 2 fois par jour. Un extrait du programme PERL Jmon, sur la façon dont celui-ci collecte ces valeurs est donné ci-dessous, il est assumé que les équipements à superviser sont nommés dans le tableau (au sens PERL) Table_Objects :

#!/usr/bin/PERL use MRTG_lib ; use SNMP_Session ; use BER ; use SNMP_util ; use Socket; #---------------------------------------------------------------------- sub Debug { # Print all parameter received for debug purpose if ($debug) { foreach $para (@_) { 7 Voir annexes

/124

JMJ

print "$para"; } } } ## ------------------ MIB Definition ------------------------------------- $Msystem = ".1.3.6.1.2.1.1"; $M_sysDescr = "1.0"; $M_sysObjectID = "2.0"; $M_sysUpTime = "3.0"; $M_sysContact = "4.0"; $M_sysName = "5.0"; $M_sysLocation = "6.0"; $CiscoChassisModel = ".1.3.6.1.4.1.9.5.1.2.16.0"; $CiscoChassisSN = ".1.3.6.1.4.1.9.5.1.2.19.0"; $CiscoModulSWVersion = ".1.3.6.1.4.1.9.5.1.3.1.1.20"; $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"; # For APs : $CiscoceAssetSerialNumber = ".1.3.6.1.4.1.9.9.92.1.1.1.2.1"; $CiscoceAssetTag = ".1.3.6.1.4.1.9.9.92.1.1.1.13.1"; $CiscoImageString = ".1.3.6.1.4.1.9.9.25.1.1.1.2.5"; #for4948 Switchs $CiscoceAssetOrderablePartN = ".1.3.6.1.4.1.9.9.92.1.1.1.3.1000"; $CiscoceAssetSerialNumber4948 = ".1.3.6.1.4.1.9.9.92.1.1.1.2.1000"; $Def_Community = "MyCommunity"; # $community = $Def_Community."@"; OBJECT: foreach $Object (@Table_Objects) { print " \nPolling Entity (managed interfaces only) : $Object ($Obj_FQDN / $Obj_IPAddr) \n"; @Tab_System = snmpwalk ($community.$Object,$Msystem); if (defined($Tab_System[0]) ) { $ObjIsSNMP = 1; foreach $Line (@Tab_System) { next if ($Line =~ /^9/); $Line =~ s/\r\n/--/g; $Clef = substr $Line, 0,3; $Data = substr $Line, (index($Line,':') $Data =~s/^://; $Data =~s/'/_/; $System{$Clef} = $Data ; } Debug ( " Sys Descr = $System{$M_sysDescr } \n"); Debug ( " Sys Obj ID = $System{$M_sysObjectID } \n"); Debug ( " Sys Up Time = $System{$M_sysUpTime } \n"); Debug ( " Sys Contact = $System{$M_sysContact } \n"); Debug ( " Sys Name = $System{$M_sysName } \n"); Debug ( " Sys Location= $System{$M_sysLocation } \n"); if ( ($System{$M_sysObjectID} =~/685$/ ) || ($System{$M_sysObjectID} =~/626$/ ) ) { $ObjIsAP = 1; } if ( $ObjIsAP ) { $CiscoChassisModel = $CiscoceAssetTag; } # AP if ($System{$M_sysObjectID} =~/626/ ) { $CiscoChassisModel = $CiscoceAssetOrderablePartN; }

/124

JMJ

$TabChassisModel = snmpget($community.$Object,$CiscoChassisModel); if( (defined ($TabChassisModel) ) && (length($TabChassisModel) > 2 ) ) { @Temp = split (/:/,$TabChassisModel); $ChassisModel = $Temp[-1]; Debug ( " Cisco Model = $ChassisModel \n") unless ($Mode != 1); } $TabModuleSWVersion = snmpget ($community.$Object,$CiscoImageString); # CW_VERSION$12.4(10b)JDA3$ if( defined ($TabModuleSWVersion)) { @Temp = split (/\$/,$TabModuleSWVersion); $ModuleSWVersion = $Temp[-1]; Debug ( " Cisco SWVer = $ModuleSWVersion \n") unless ($Mode != 1); } if ( $ObjIsAP ) { $CiscoChassisSN = $CiscoceAssetSerialNumber; } if ($System{$M_sysObjectID} =~/626/ ) { $CiscoChassisSN = $CiscoceAssetSerialNumber4948 ; } $TabChassisSN = snmpget($community.$Object,$CiscoChassisSN); if( ( defined ($TabChassisSN)) && (length($TabChassisSN) > 2 ) ) { @Temp = split (/:/,$TabChassisSN); $ChassisSN = $Temp[-1]; Debug ( " Cisco SN = $ChassisSN \n") unless ($Mode != 1); } } else { next OBJECT; } $community = $Community = " Unknown ; }

Table 17: Exemple de programme PERL collectant ces 1eres informations

Le résultat de l’exécution de ce programme est le suivant :

Figure 18: Résultat du programme PERL collectant ces 1eres informations

9.2.2 Baseline monitoring Certaines des missions du Noc énoncées au paragraphe 8.2 Missions du NOC en page 31 telles que :


/124

JMJ

• Superviser les équipements du réseau afin de garantir qu’aucune panne n’est due à un équipement ayant atteint ses limites de performances.

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

nécessitent d’une part de réaliser des mesures de certains paramètres (nous verrons lesquels par la suite) et aussi de disposer des résultats de ces mesures dans le passé, afin de connaître les tendances de variations et savoir si les valeurs actuelles sont « normales » ou nécessitent une intervention. Le Baseline Monitoring nous permet de définir, par comparaison avec les mesures passées, comment il y a lieu de réagir par rapport aux valeurs des mesures qui viennent d’être effectuées. Une représentation graphique de ces valeurs facilite grandement l’interprétation des mesures et la prise de décision. MRTG est excellent pour réaliser de tels graphes.


/124

JMJ

Figure 19:Exemple de Baseline monitoring avec l’outil Jnet2 basé sur MRTG

9.2.2.1 Variables Les variables pour lesquelles il me semble indispensable de disposer d’un Baseline Monitoring sont :

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


/124

JMJ

• Charge CPU et utilisation mémoires (CPU et I/O) des équipements supervisés

Sur la partie détaillée du réseau pris en exemple, en ce qui concerne les débits, il y a déjà 20 liens/interfaces à mesurer dans les 2 directions et 12 équipements à mesurer en ce qui concerne la charge CPU et l’utilisation mémoire (en admettant que votre fournisseur vous donne un accès SNMP -même si ce n’est qu’en lecture seule- sur ses équipements,).

Figure 20: Paramètres minima à mesurer Les erreurs sur les liens pour lesquels une mesure de débit est effectuée ainsi que les latences entre le Centre de Calcul et les routeurs des différentes filiales sont des mesures supplémentaires très utiles aussi pour le dépannage. Best Practices Au minimum il convient d’avoir un Baseline Monitoring pour : Débits : Les débits entrant et sortant sur les liens WAN et les liens entre Switchs. CPU - Memory : La charge CPU et l’utilisation mémoire des équipements 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.

In / out

CPU/Mem


/124

JMJ

9.2.2.2 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 ou 1.3.6.1.2.1.2.2.1.10 Specific Object Information

Object ifInOctets

OID 1.3.6.1.2.1.2.2.1.10

Type Counter32


Status current

MIB IF-MIB ; - View Supporting Images

Description "The total number of octets received on the interface, including framing characters. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime."

Table 18: Cisco MIB browser pour la MIB IF-MIB, Object = ifInOctets .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifOutOctets ou 1.3.6.1.2.1.2.2.1.16 Specific Object Information

Object ifOutOctets

OID 1.3.6.1.2.1.2.2.1.16

Type Counter32


Status current


Description "The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime."

Table 19: Cisco MIB browser pour la MIB IF-MIB, Object = ifOutOctets CPU : La mesure de la charge CPU des équipements est une tache relativement non aisée qui dépend de vos équipements, de la version logicielle dont ils sont munis. Je recommande d’utiliser ce qui suit dans la mesure du possible. .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoProcessMIB.ciscoProcessMIBObjects.cpmCPU ou 1.3.6.1.4.1.9.9.109.1.1.1.1.8


/124

JMJ

Specific Object Information

Object cpmCPUTotal5minRev

OID 1.3.6.1.4.1.9.9.109.1.1.1.1.8

Type Gauge32


Status Current

Units Percent

Range 0 – 100

MIB CISCO-PROCESS-MIB ; - View Supporting Images

Description "The overall CPU busy percentage in the last 5 minute period. This object deprecates the object cpmCPUTotal5min and increases the value range to (0..100)."

More Information • How to Collect CPU Utilization on Cisco IOS Devices Using SNMP

Table 20: Cisco MIB browser pour la MIB CISCI-PROCESS-MIB, Object = cpmCPUTotal5minRev

.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifInErrors ou .1.3.6.1.2.1.2.2.1.14 Specific Object Information

Object ifInErrors

OID 1.3.6.1.2.1.2.2.1.14

Type Counter32


Status current


Description "For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol. For character- oriented or fixed-length interfaces, the number of inbound transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime."

Table 21: Cisco MIB browser pour la MIB IF-MIB, Object = ifInErrors .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifOutErrors ou .1.3.6.1.2.1.2.2.1.20 Specific Object Information

Object ifOutErrors

OID 1.3.6.1.2.1.2.2.1.20


/124

JMJ

Type Counter32


Status current


Description "For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime."

Table 22: Cisco MIB browser pour la MIB IF-MIB, Object = ifOutErrors Il peut être judicieux par la suite de grouper toutes les informations concernant une filiale sur un même rapport permettant une analyse extrêmement rapide en cas 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 du management. Tout changement dans l’enveloppe d’une des courbes représentées devra immédiatement être analysée et trouver une explication.

Figure 21: Exemple d’intranet donnant un aperçu rapide de la santé du réseau vers une filiale

/124

JMJ

9.3 Compteurs Parmi les variables qu’il convient de collecter, les compteurs occupent une place de choix. Il est indispensable de « compter » si l’on veut :

• Superviser les performances : erreurs ; utilisation/activité • Dépanner • Planifier • Facturer

Il convient de bien comprendre ce que sont ces compteurs, pourquoi et en quoi ils diffèrent des compteurs accessibles par CLI.

9.3.1 Compteurs CLI Exemple :

sho int Gi1/0/1 GigabitEthernet1/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/2 MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 3/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive not set Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX SFP Media-type configured as connector input flow-control is off, output flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last 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: 0 Queueing strategy: fifo Output 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 counters etherchannel Show interface etherchannel counters protocol interface protocol counters trunk Show interface trunk counters | Output modifiers <cr> sho int Gi1/0/1 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize Gi1/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

Table 23:Exemple de compteurs accessibles par CLI


/124

JMJ

Un compteur CLI compte des variables définies par le constructeur de l’équipement, les valeurs de ces compteurs sont formatées pour être compréhensibles directement. Leur remise à zéro est possible.

9.3.2 Compteurs SNMP Les compteurs SNMP ont une définition standardisée (par l’IETF, par l’IEE, par certains constructeurs). Ils sont indépendants de type d’équipement et/ou du constructeur et ont une taille spécifié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. Exemple : Specific Object Information

Object ifHCOutOctets

OID 1.3.6.1.2.1.31.1.1.1.10

Type Counter64


Status Current


Description "The total number of octets transmitted out of the interface, including framing characters. This object is a 64-bit version of ifOutOctets. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime."

Table 24:Exemple de définition de compteur Si des mesures précises de temps entre polling sont nécessaires, il est préférable d’utiliser la variable sysUpTime de l’équipement lui-même, plutôt qu’un temps défini par la station de management, afin d’éviter les dérives de temps de transit. Ex :

temps Poll t0 Poll t1

Transit = 10 ms

Transit = 8 ms

Transit total = 18 ms

Transit = 8 ms

Transit = 3 ms

Transit total = 11 ms

Gigue = 7 ms


/124

JMJ

Pour des compteurs sans indicateurs de discontinuity, le sysUpTime permet de savoir si le compteur a été réinitialisé et évite d’afficher des fausses valeurs de deltas calculés.

9.3.3 « Bouclage » des compteurs Un compteur SNMP étant de taille fixe (32 ou 64 bits), quand la valeur de celui-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 la période de polling. Interface Compteur 32 bits Compteur 64 bits 10 Mb/s ~3436 s ~ 57,26 minutes 100 Mb/s ~343 s ~ 5,72 minutes 1000 Mb/s ~34 s ~ 4680 ans 1 Tb/s ~ 4,6 ans Poller un compteur 32bits relatif à une interface à 1 Gb/s à une période supérieure à 34 secondes peut conduire à une lecture erronée de variables.

9.4 Synthèse du chapitre La supervision des variables mentionnées dans ce chapitre doit être considérée comme un minimum. Il ne faut pas non plus tomber dans l’excès inverse et croire que le meilleur outil de supervision est celui qui supervise le plus de variables, qui collecte le maximum d’information, qui produit le plus de rapport, 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 il s’est engagé, de définir les paramètres et les variables à superviser, de même que 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 primordiale. En effet, si le réseau transporte principalement de la voix ou de la vidéo, des mesures de jitter et de latences peuvent s’avérer indispensables, si la QoS (Quality of Service) est mise en œuvre sur le réseau, des mesures de trafic par classe de service pourront être les bienvenues, si les SLA définissent une valeurs pour les latences ou classe de service.


/124

JMJ

10 SNMP et l’indexation

La collecte des premières valeurs effectuée au paragraphe 9.2.1 Inventaire en page 39 est simple et ne pose pas de difficulté particulière, ni d’accès ni d’interprétation. Ces valeurs sont uniques pour l’équipement réseau. (On supposera cela vrai à ce stade du document).

10.1 Indexation simple Sur un équipement réseau, la plupart des variables qu’il est possible de chercher par SNMP ne sont pas unique et existent pour toutes les interfaces de l’équipement. Par exemple l’Administrative Status (l’interface est-elle en mode shutdown ou non), ou le In Octets (le nombre d’octets reçus par le cette interface) sont des variables qui sont définies et maintenues à jour à tout moment pour chaque interface. Si nous voulons savoir, sur notre switch nommé mgth03, si le port 3 de ce switch est 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 sur le 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 (1.3.6.1.2.1.2.2.1.7) Et .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifInOctets (1.3.6.1.2.1.2.2.1.10), or une requête sur cette dernière donne le résultat suivant :

Figure 22: 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 variables lues 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 : 1ere ligne : Le nombre d’octet reçus par l’interface dont l’Index est 1 est 1590218 2eme ligne : Le nombre d’octet reçus par l’interface dont l’Index est 2 est 1730096653


/124

JMJ

Etc etc La lecture de l’Administrative Status nous retourne un tableau construit de la même manière. Si nous parvenons à savoir quel Index est à utiliser pour référencer l’interface FastEthernet0/3 qui nous préoccupe, il nous sera possible d’accéder aux informations 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 10003 a pour description FastEthernet0/3. (En toute rigueur il faut 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 sens du constructeur de l’équipement réseau et non la description qui est laissée libre à l’utilisateur lors de la configuration des interfaces. Cette dernière est retournée par l’OID : 1.3.6.1.2.1.31.1.1.1.18

Figure 23: 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

Table 25: Snmpget en connaissant l’Index

• soit par snmpwalk qui nous retournera l’ensemble des valeurs pour toutes les interfaces et nous ne retiendrons que la valeur de l’Index qui nous préoccupe (1003).


/124

JMJ

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

Table 26: Snmpwalk en connaissant l’index Et enfin répéter ces requêtes pour l’Administrative Status. En résumé quand une MIB retourne des variables indexées, elle doit aussi permettre la lecture d’une OIDs qui permet l’association entre l’Index et une variable de degré d’abstraction moindre (ici une interface car nous sommes au niveau interface : .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifIndex ). Cet Index reste constant (heureusement) dans cette branche de la MIB. (Attention la persistance dans le temps n’est pas garantie en cas de redémarrage de l’équipement ou en cas de modification matérielle : ajout/suppression d’interface) Ceci peut être représenté de la sorte :

Figure 24: Schématisation de l‘indexation

/124

JMJ

ifDescr nous indique que l’index 10003 référence l’interface FastEthernet0/3. Toutes les OIDs de cette branche de la MIB, indexées par 10003 fournissent des informations relatives à l’interface FastEthernet0/3 Exemple de programme PERL de collecte de quelques-unes des informations nécessaires à la supervision d’un équipement

#!/usr/bin/PERL use MRTG_lib ; use SNMP_Session ; use BER ; use SNMP_util ; use Socket; #---------------------------------------------------------------------- sub Debug { # Print all parameters received for debug purpose if ($debug) { foreach $para (@_) { print "$para"; } } } $CiscoModulSWVersion = ".1.3.6.1.4.1.9.5.1.3.1.1.20"; $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"; # For APs : $CiscoceAssetSerialNumber = ".1.3.6.1.4.1.9.9.92.1.1.1.2.1"; $CiscoceAssetTag = ".1.3.6.1.4.1.9.9.92.1.1.1.13.1"; $CiscoImageString = ".1.3.6.1.4.1.9.9.25.1.1.1.2.5"; #for4948 Switchs $CiscoceAssetOrderablePartN = ".1.3.6.1.4.1.9.9.92.1.1.1.3.1000"; # "WS-C4948" ZZZ To be done with snmpget . Index may change $CiscoceAssetSerialNumber4948 = ".1.3.6.1.4.1.9.9.92.1.1.1.2.1000"; # FCZ111681GQ ZZZ To be done with snmpget . Index may change $MifIndex = "1.3.6.1.2.1.2.2.1.1"; $MifName = "1.3.6.1.2.1.31.1.1.1.1"; $MifDescr = "1.3.6.1.2.1.2.2.1.2"; $MifType = "1.3.6.1.2.1.2.2.1.3"; $MifAdStat = "1.3.6.1.2.1.2.2.1.7"; $MifOpStat = "1.3.6.1.2.1.2.2.1.8"; #$MipAdEntAdr = "1.3.6.1.2.1.4.20.1.1"; $MipAdEntIfIndex = "1.3.6.1.2.1.4.20.1.2"; $MipAdEntNetMask = "1.3.6.1.2.1.4.20.1.3"; $MifAlias = "1.3.6.1.2.1.31.1.1.1.18"; OBJECT: foreach $Object (@Table_Objects) { $NbSnmpIndex = $NbSnmpDescr = $NbSnmpifName = 0; $NbSnmpAdStat= $NbSnmpOpStat= 0; @Tabl_ifName = @Tabl_Index = @Tabl_Desc = undef ; Debug (" SNMP Interfaces \n") unless ($Mode != 1); @Tabl_Index = snmpwalk($community.$Object,$MifIndex); %Index = (); foreach $Line (@Tabl_Index) { @Temp = split (/:/,$Line); if (defined ($Temp[1] ) ) { $Index{$Temp[0]} = $Temp[1]; $NbSnmpIndex++; } else { Debug ( "$Object ($Line) : No ($NbSnmpIndex) Index returned, Skipping...") unless ($Mode != 1) ;

/124

JMJ

next OBJECT; } } Debug (" -- Gathering Description \n") unless ($Mode != 1); @Tabl_Desc = snmpwalk($community.$Object,$MifDescr); %Descr = (); foreach $Line (@Tabl_Desc) { @Temp = split (/:/,$Line); if (defined ($Temp[1] ) ) { $Descr{$Temp[0]} = $Temp[1]; $NbSnmpDescr++; } else { Debug ( "$Object ($Line) : No ($NbSnmpDescr) Descr returned, Skipping...") unless ($Mode != 1); next OBJECT; } } Debug ( " -- Gathering Aliases \n") unless ($Mode != 1); @Tabl_Alias = snmpwalk($community.$Object,$MifAlias); %Alias = (); foreach $Line (@Tabl_Alias) { @Temp = split (/:/,$Line); if (!defined ($Temp[1] ) ) { $Temp[1] =""; } $Temp[1] =~ s/'/_/g; # MySQL does not like ' $Alias{$Temp[0]} = substr $Temp[1],0,50; } Debug ( " -- Gathering Virtual Addresses \n") unless ($Mode != 1); @Tabl_VirtualIpAddr = snmpwalk($community.$Object,$CiscoMIbcHsrpGrpVirtualIpAddr); %IndexDotGroup = (); foreach $Line (@Tabl_VirtualIpAddr) { @Temp = split (/:/,$Line); if (defined ($Temp[1] ) ) { $IndexDotGroup{$Temp[1]} = $Temp[0]; } } Debug ( " -- Gathering Standby State \n") unless ($Mode != 1); @Tabl_StandbyState = snmpwalk($community.$Object,$CiscoMIbcHsrpGrpStandbyState); %StandbyState = (); foreach $Line (@Tabl_StandbyState) { @Temp = split (/:/,$Line); if (defined ($Temp[1] ) ) { $StandbyState{$Temp[0]} = $Temp[1]; } } Debug (" -- Gathering IP Adresses \n") unless ($Mode != 1); @Tabl_AdrIf = snmpwalk($community.$Object,$MipAdEntIfIndex); %AdrIf = (); %IndexOfAddr = (); foreach $Line (@Tabl_AdrIf) { @Temp = split (/:/,$Line); if (defined ($Temp[1] ) ) { if (!defined($IndexDotGroup{$Temp[0]}) ) { $AdrIf{$Temp[1]} = $Temp[0]; } #One (the last) not virtual IP address of the interface is given $IndexOfAddr{$Temp[0]} = $Temp[1]; } } Debug ( " -- Gathering Admin Status \n") unless ($Mode != 1); @Tabl_AdIfStat = snmpwalk($community.$Object,$MifAdStat); %AdIfStat = ();

/124

JMJ

foreach $Line (@Tabl_AdIfStat) { @Temp = split (/:/,$Line); $AdIfStat{$Temp[0]} = $Temp[1]; $NbSnmpAdStat++; } Debug ( " -- Gathering Op. Status \n") unless ($Mode != 1); @Tabl_OpIfStat = snmpwalk($community.$Object,$MifOpStat); %OpIfStat = (); foreach $Line (@Tabl_OpIfStat) { @Temp = split (/:/,$Line); $OpIfStat{$Temp[0]} = $Temp[1]; $NbSnmpOpStat++; } Debug( " -- Gathering IF Name \n") unless ($Mode != 1); @Tabl_ifName = snmpwalk($community.$Object,$MifName); %ifName = (); foreach $Line (@Tabl_ifName) { @Temp = split (/:/,$Line); if (defined ($Temp[1] ) ) { $ifName{$Temp[0]} = $Temp[1]; $NbSnmpifName++; } elsif ( $System{$M_sysDescr } =~/Cisco/i ) { Debug ( "$Object ($Line) : No ($NbSnmpifName) ifName returned, Exiting ...") unless ($Mode != 1); next OBJECT; } } Debug ( " -- Gathering Net Mask \n") unless ($Mode != 1); @Tabl_NetMask = snmpwalk($community.$Object,$MipAdEntNetMask); %NetMask = (); foreach $Line (@Tabl_NetMask) { @Temp = split (/:/,$Line); if (defined ($Temp[1] ) ) { $NetMask{$Temp[0]} = $Temp[1]; } } Debug ( " -- Gathering IF Type \n") unless ($Mode != 1); @Tabl_ifType = snmpwalk($community.$Object,$MifType); %ifType = (); foreach $Line (@Tabl_ifType) { @Temp = split (/:/,$Line); if (defined ($Temp[1] ) ) { $ifType{$Temp[0]} = $Temp[1]; } } if ( $System{$M_sysDescr } =~/Cisco/i ) { $t1 = @Tabl_Index; $t2 = @Tabl_Desc; $t3 = @Tabl_ifName; if ( ($t1 != $t2) || ($t1 != $t3) || ($t1 != $NbSnmpOpStat) || ($t1 != $NbSnmpAdStat) ) { Debug ( "$Object SNMP Error.Exiting ... ") unless ($Mode != 1); next OBJECT; } } ################# Write/Update Data Base ############################## foreach (sort (values (%Index) ) ) { # For all Indexes ( will not have all the IP addresses )////////////// $Index = $_; etc etc } foreach (sort (keys (%IndexOfAddr) ) ) { # For each IP ADDRESS


/124

JMJ

etc etc } }

Table 27: Exemple de programme PERL de collecte d’informations A noter : les ifIndex ne sont pas tenus d’être éternellement relatifs à une interface/un port donné. La seule règle prévalant est qu’un ifIndex ne peut être ré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 figer 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 modifient toutefois relation ifIndex ó Interface/port : Ajout/suppression d’interface physique Ré adressage d’interface8

8 Voir Annexes


/124

JMJ

Pour l’interface de management du switch mgth03 – exemple pris car il est doté d’une adresse IP- et pour le port « Fa0/1 doté d’une Description (au sens Cisco IOS) ces informations sont stockées de la sorte dans Jmon:

Figure 25: Table „Itf“ de Jmon


/124

JMJ

10.2 Indexation multiple Comme nous venons de le voir, le principe d’indexation permet de spécifier pour quelle interface, par le biais de l’index, se rapporte une valeur lue dans une table de valeurs. Il est donc possible par ex. de lire la table du nombre d’octets émis pour toutes les interfaces de l’équipement interrogé puis d’affecter grâce à l’index chaque ligne à une interface de l’Objet, car pour cette table, l’index se rapporte une interface. Certaines valeurs qu’il peut être intéressant de lire se rapportent à plus d’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 configuré 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 figure suivante :

Figure 26: Switch port pour VoIP Le port 12 de ce switch est configuré de la sorte :

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

Table 28: Configuration d’un port de switch Cisco pour la VoIP La consultation de la table MAC pour le port 12 de ce switch nous donne :

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

Table 29: Table des adresse MAC d’un port de switch « VoIP » Le téléphone est vu dans les 2 VLANs : tant que le MAC Aging Timer ne s’est pas é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 :

IP Phone MAC : 00:80:9F:62:65:4F

Switch B

Appareil MAC : 00:15:C5:A5:35:CA

port 12


/124

JMJ

Une indexation par interfaces (« Toutes les adresses MAC pour toutes les interfaces ») nous retournerait toutes les adresses MAC, mais impossible de lier ce couple [adresse MAC, Interface] à un VLAN. Une indexation par VLAN (« Toutes les adresses MAC pour tous les VLANs ») nous retournerait toutes les adresses MAC, mais impossible de lier ce couple [adresse MAC, VLAN] à une Interface. La solution est une deuxième indexation qui permet de demander « Toutes les adresses MAC pour tous les interfaces, pour un 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 134 serait transmise en utilisant la community string « public@134 ». Un exemple détaillé est donné dans le chapitre 12.2 : Adresse MAC en page 84.


/124

JMJ

11 Quelques chiffres et calculs élémentaires

Dans le chapitre qui suit , nous considérerons un réseau de taille moyenne constitué de près de 700 switchs (presque exclusivement des switchs à 48 ports), des routeurs, 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 etc…), répartis géographiquement sur 60 filiales, chacune adressée dans un sous réseau différent (Masque réseau 255.255.0.0), et dans chacune de ces filiales, une vingtaine de VLANs partagent logiquement le sous réseau assigné à cette filiale. Ce réseau se résume comme suit (vu depuis l’outil Jmon) :

Figure 27: Taille d’un réseau moyen vu par l’outil Jmon Soient : 2938 équipements à superviser. Ces équipement engendrent 68413 interfaces en tout, dont 10252 sont des interfaces dotées d’une adresse IP. Dans sa configuration actuelle Jmon supervise tous ces équipements, 44291 interfaces de ceux-ci, dont 9405 interfaces dotées d’une adresse IP. Ce réseau interconnecte 15792 éléments et équipements. Le dimensionnement du réseau permet de définir certains paramètres fondamentaux de la supervision de réseau, tels que ceux abordés dans les paragraphes suivants.

11.1 Polling La détermination de la période d’interrogation – polling – des informations SNMP est un paramètre important dont la valeur relève beaucoup plus de bon sens et d’expérience que de savantes formules. Dans une première approche il peut être tentant d’interroger les équipements aussi souvent que possible, afin d’être en possession des informations les plus à jour possible et de d’interroger un maximum, sinon tous les interfaces – au sens « Cisco »-, cela peut toujours être utile… Cette approche, impacte immédiatement :

1. 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 finalement qu’à transporter des données destinées à se superviser lui-même, au détriment des


/124

JMJ

données « utiles ». L’overhead due à la supervision doit rester dans un domaine acceptable, utilisant quelques pourcents au maximum de la bande passante. La consommation de la bande passante par SNMP est un paramètre qu’il est toujours intéressant de surveiller, certains outils commerciaux sont générateurs de trafic SNMP intense (Cisco Works, Cisco WLSE,…)

2. Les équipements supervisés eux-mêmes. Là encore, les équipements mis en œuvre n’ont pas pour fonction première d’être supervisés, mais assurent une fonction au sein du réseau. Les requêtes SNMP sont assez gourmandes en ressource CPU, même si au niveau du système d’exploitation de ces équipements, la gestion des requêtes SNMP est une tache de bas niveau ayant une priorité d’exécution faible.

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

Nous avons vu au paragraphe 9.2.1.2 Linux et Getif page 40, que certaines variables 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éseau tels que switchs, routeurs, access-points. Il est parfois souhaité de détecter plus rapidement la défaillance de certains éléments critiques au fonctionnement du réseau, dont on peut alors tester la présence à une période pouvant aller jusqu’à quelques secondes. La collecte des informations requises pour le Base Line monitoring est généralement aussi effectuée avec une résolution de 5 minutes. La période de polling détermine ici effectivement la résolution car si l’on sait par exemple qu’entre t0 et t0+5 par une interface donnée, 100 kbit sont passés, il est impossible 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. Un meilleur profil de trafic n’est pas décidable.

t0 + Compteur Par Minute

t0 + Compteur Par Minute 0 1230

0 1230

1 1253 23

1 1230 0 2 1267 14

2 1230 0

3 1291 24

3 1330 100 4 1315 24

4 1330 0

5 1330 15

5 1330 0 Total 100

Total 100

Figure 28: Période de polling et profil de trafic

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


/124

JMJ

Dans l’exemple ci-dessus, si une action doit être déclenchée à partir de 50 kbits par minute, il est évident qu’une période de polling de 5 minutes est inadéquate pour détecter ce dépassement de seuil.

11.2 Timeout et retries Dans notre exemple, le réseau est constitué de 2838 équipements et 9405 adresses IP. Ces équipements sont de toute évidence, d’une par testés pour leur accessibilité (ping ICMP ou UDP echo) et d’autre part accédés via SNMP. Il est relativement aisé de définir une approximation même grossière du temps de transit d’un paquet à l’aide d’outil simple, tels que la commande ping par exemple

ping zler02 PING 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 ms 64 bytes from zler02 (10.185.2.2): icmp_seq=2 ttl=249 time=14.3 ms 64 bytes from zler02 (10.185.2.2): icmp_seq=3 ttl=249 time=24.8 ms 64 bytes from zler02 (10.185.2.2): icmp_seq=4 ttl=249 time=14.7 ms 64 bytes from zler02 (10.185.2.2): icmp_seq=5 ttl=249 time=14.8 ms 64 bytes from zler02 (10.185.2.2): icmp_seq=6 ttl=249 time=14.7 ms 64 bytes from zler02 (10.185.2.2): icmp_seq=7 ttl=249 time=15.1 ms 64 bytes from zler02 (10.185.2.2): icmp_seq=8 ttl=249 time=15.6 ms ^C --- 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

Table 30: Détermination grossière d’un temps de réponse Soient environ 14 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 car au lieu d’obtenir la réponse en environ 14 ms, le requête SNMP par exemple va attendre un timeout généralement fixé à 2 secondes, et être réitérée un nombre de fois défini par le paramètre retries généralement fixé à trois ou quatre. Dans l’exemple ci-dessous une requête est issue avec une Community String inadéquate, pour illustrer une non-réponse à une requête SNMP, simulant un équipement défectueux.

Figure 29: Traces Wireshark du Timeout et retry sur une requête SNMP

Le test d’accessibilité à l’équipement (ligne 1 et 2) est assuré en environ 15 ms. L’échec de la requête SNMP n’est établi qu’après huit secondes (colonne « Time » : 15:28:55 – 15:28:47).


/124

JMJ

Figure 30: Timeout et retry sur une requête SNMP - Récapitulatif

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

Dans le cas où tous les équipements répondent à cette Community String : 2938 x (14 + 14) ms = 82,264 secondes, moins d’une minute et demie Dans le cas où tous les équipements ne répondent pas à cette Community String : 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.

La connaissance de ces valeurs et de la stabilité du réseau (nombre d’équipements 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 retries. Ceci peut être envisagé si le comportement du réseau est bien connu et maitrisé. Dans le cas d’un réseau international, à longue distance (liaison satellites 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 recommandés pour un réseau national occidental.


/124

JMJ

11.3 Collecte d’information Prenons l’exemple d’un outil de supervision de ce réseau nécessitant pour chacun des équipements supervisés, les informations suivantes afin de représenter l’état de 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 ?

L’interrogation d’un équipement commencera par l’établissement de la liste des interfaces de l’équipement. 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";

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

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

11.3.1 Alias L’obtention des Alias sera l‘exemple pris dans ce qui suit. Cette obtention est réalisée par une requête snmpwalk sur 1.3.6.1.2.1.31.1.1.1.18 (Alias) commençant par un GetNextRequest-PDU (longueur = 97 octets) GetResponse-PDU vient pour 1.3.6.1.2.1.31.1.1.1.18.1 (longueur 108 Octets) Le prochain GetNextRequest-PDU est pour 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, 878 paquets et 88170 octets sont échangés, soient 114 paquets par seconde pour des paquets de taille moyenne de 100 octets (voir Figure 31: Traces Wireshark de la requête des Alias et Figure 32: Traces Wireshark de la requête des Alias - Récapitulatif).


/124

JMJ

Figure 31:Traces Wireshark de la requête des Alias

Figure 32: Traces Wireshark de la requête des Alias - Récapitulatif


/124

JMJ

11.3.2 SNMP V2c et Getbulk Avec le changement suivant le module PERL mis en œuvre (SNMP_util.pl) va utiliser SNMP-V2c et GetBulk pour obtenir les Objets.

$Equipement = $Equipement.":::::2";

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

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

L’obtention des Alias est réalisée par une requête sur 1.3.6.1.2.1.31.1.1.1.18 (Alias) commence par un getbulkrequest- (longueur = 96 octets) Un GetResponse-PDU vient (voir Figure 33: Traces Wireshark de la 1ere requête des Alias par GetBulk) pour 1.3.6.1.2.1.31.1.1.1.18.1, 1.3.6.1.2.1.31.1.1.1.18.300 1.3.6.1.2.1.31.1.1.1.18.303 1.3.6.1.2.1.31.1.1.1.18.304 1.3.6.1.2.1.31.1.1.1.18.308 1.3.6.1.2.1.31.1.1.1.18.309 1.3.6.1.2.1.31.1.1.1.18.301 1.3.6.1.2.1.31.1.1.1.18.320 1.3.6.1.2.1.31.1.1.1.18.321 1.3.6.1.2.1.31.1.1.1.18.322 1.3.6.1.2.1.31.1.1.1.18.323 1.3.6.1.2.1.31.1.1.1.18.330 soient 12 objets retournés dans la VarBindList, tels que demandées dans la requête (c’est la valeur par défaut du paramètre Max-repetitions) et un paquet d’une taille de 428 octets.

Figure 33: Traces Wireshark de la 1ere requête des Alias par GetBulk


/124

JMJ

Le second getbulkrequest est pour 1.3.6.1.2.1.31.1.1.1.18.330 qui répond 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 est pour 1.3.6.1.2.1.31.1.1.1.18.5001 qui répond par 12 objets retournés dans la VarBindList, 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 requis ce qui est le cas pour cet équipement qui est doté des 38 interfaces suivants: +--------------+ | Itf_MifIndex | +--------------+ | 1 | | 300 | | 303 | | 304 | Retournés par la 1ere réponse | 308 | | 309 | | 310 | | 320 | | 321 | | 322 | | 323 | | 330 | | 331 | | 332 | | 800 | | 804 | | 826 | Retourné par la 2e réponse | 849 | | 850 |

| 851 | | 853 | | 854 | | 857 | | 5001 | | 5013 | | 10101 | | 10102 | | 10103 | | 10104 | | 10105 | Retourné par la 3e réponse | 10106 | | 10107 | | 10108 | | 10109 | | 10110 | | 10111 | | 10112 | | 14501 | +--------------+ 38 rows in set

Figure 34: Traces Wireshark de la 4e et dernière requête des Alias par GetBulk


/124

JMJ

Le quatrième getbulkrequest est pour 1.3.6.1.2.1.31.1.1.1.18.10111 qui répond par 12 objets retournés dans la VarBindList de 1.3.6.1.2.1.31.1.1.1.18.10112 et 14501 tels qu’attendu, puis retourne les objets pour 1.3.6.1.2.1.31.1.2.1.3.0.1 vide, 10101, 10102, 10103, 10104, 10105, 10106, 10107, 10108, 10109). Soient bien 12 objets retournés au total. Pourquoi 1.3.6.1.2.1.31.1.2.1.3.0.1 ? Car c’est la prochaine 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).

Figure 35:1.3.6.1.2.1.31.1.2.1.3.0.1 est l’OID interrogeable suivant pour cet équipement Il en ira de même pour toutes les autres tables, on s’attend donc à une division par un peu moins de 12 (toutes les requêtes ne vont pas bénéficier du GetBulk) du nombre de paquets transmis (878 paquets / 12 ~= 73).


/124

JMJ

Figure 36: Requêtes par GetBulk – Récapitulatif L’obtention de toutes les informations dure 1,1 secondes, 94 paquets et 20874 octets sont échangés, soient 86 paquets par seconde pour des paquets de taille moyenne de 222 octets. Il est immédiatement remarquable que :

• Le nombre de paquet transmis est environ 9,3 fois moins important. • Le nombre d’octets échangés pour transmettre exactement la même information est

divisé par environ 4,2. • La durée requise pour transmettre la même information est divisée par environ 7.

En optimisant :

@Tabl_Alias = snmpwalk($community.$JMJObject,0,38,$MifAlias);

Il n’y a plus qu’une réponse concernant les Alias, retournée dans un paquet d’une taille de de 1102 octets. Cette optimisation n’est possible que si le nombre de varbinds à retourner est connu apriori.


/124

JMJ

Figure 37: Traces Wireshark d’une requête par GetBulk optimisé


/124

JMJ

11.3.2.1 Optimisation maximale En regardant de près les valeurs requises par l’outil de supervision il apparait que 2 groupes peuvent être formés afin d’optimiser les requêtes Getbulk : Informations relatives aux interfaces Information relatives aux adresses IP. L’interrogation d’un objet commencera par l’établissement de la liste des interfaces de l’objet.

• 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 elle virtuelles (HSRP Address) ? • Les adresses IP allouées sont Standby Master ?

$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";

L’interrogation d’un équipement qui commence par l’établissement de la liste des interfaces de l’équipement délivrera le nombre d’interfaces de l‘équipement considéré, et ce nombre sera utilisé dans le Get-Bulk suivant en tant que paramètre „Max-Répetition“. Il en va de même pour les adresses IP.

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

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

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

Idem pour les adresses IP :

@Tabl_AdrIf = snmpwalk($community.$Equipement,$MipAdEntIfIndex); $MR = @Tabl_AdrIf; # Max repetition @Tabl_NetMask = snmpgetbulk($community.$Equipement,0,$MR,$MipAdEntNetMask);


/124

JMJ

Figure 38: Traces Wireshark de toutes les requêtes par GetBulk optimisé L’obtention de toutes les informations dure 0,62 secondes, 44 paquets et 14658 octets sont échangés, soient 70 paquets par seconde pour des paquets de taille moyenne de 333 octets.

Figure 39: Traces Wireshark de toutes les requêtes par GetBulk optimisé – récapitulatif

/124

JMJ

11.3.2.2 Limitations et putting all toghether L’utilisation de l’exemple ci-dessus peut conduire à ce que le paquet retourné ait la taille maximale du paquet, sans pour autant transmettre toutes les informations nécessaires. Par exemple un équipement doté de 100 interfaces, ne pourra retourner dans un paquet de taille maximale que les données relatives à une 40aine d’interfaces. Il convient au niveau de la station de management de détecter cette incomplétude et de réitérer les requêtes – à partir du dernier index retourné- tant que toutes les informations désirées n’ont pas été transférées. Un exemple PERL complet synthétisant tout cela est donné ci-dessous

Debug (" -- Gathering Description \n") unless ($Mode != 1); $RestaFaire = $MR ; # $MR = @Tabl_Index lue précedemment $MIB = $MifDescr; $Split = $MIB."."; %Descr = (); while ($RestaFaire > 0) { @Tabl = snmpgetbulk($community.$ObjectV2,0,$RestaFaire,$MIB); $LgRetTable = @Tabl; $RestaFaire = $RestaFaire - $LgRetTable; # Reste a faire = depart - fait foreach $Line (@Tabl) { @Temp = split (/$Split/,$Line); @Temp = split (/:/,$Temp[-1]); if (defined ($Temp[1] ) ) { $Descr{$Temp[0]} = $Temp[1]; } else { Debug ( "$Object ($Line) : No Descr returned, Skipping...") unless ($Mode != 1); exit(); } } $MIB = $MIB.".$Temp[0]"; # Rebuild last OID }

Impact sur l’utilisation du réseau

Figure 40:Bande passante „entrante“ utilisée par SNMP avec et sans requêtes GetBulk


/124

JMJ

Bande passante „sortante“ utilisée par SNMP avec et sans requêtes GetBulk

11.4 DNS Il est très probable que la station de management ait, pour chaque équipement supervisé, à résoudre un nom en adresse IP ou une adresse IP en nom. Elle utilisera pour ce faire le service DNS de l’entreprise. Même si la résolution de nom (ou d’adresse IP) est rapide, la durée de cette résolution s’exprime en milli-secondes et des milli-secondes multipliées par des milliers d’équipement de transforment très vite en secondes. Ces secondes sont perdues à chaque période de polling. Pour ne plus les perdre, il suffit que la résolution des noms ou adresses IP se fasse en local sur la station de management : Best Practices Quand cela est possible, configurer le service de résolution de noms de la station de management de sorte à utiliser en priorité un fichier local, et mettre ce fichier local à jour quand le fichier central est altéré : Sous *nix : le fichier est /etc/hosts, l’ordre de recherche est défini dans /etc/resolv.conf ou /etc/host.conf

11.5 Synthèse du chapitre Collecter des informations SNMP ponctuellement est une tâche très simple. Exploiter ces informations requiert une connaissance un peu plus poussée de SNMP et des diffé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 utilisateur requiert de bien maitriser les deux points ci-dessus cités, de savoir quelles informations sont pertinentes pour la supervision du réseau et des connaissances poussé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 sniffer le trafic généré par une station de management et de l’analyser, afin de se faire une idée du niveau de maturité des logiciels mis en œuvre et du niveau des notions de supervision de réseau disponibles au sein de l’équipe de développement desdits logiciels.


/124

JMJ

De même, le paramétrage d’un logiciel de supervision, la définition opportune des périodes de polling, des variables supervisées, des seuils d’alarme, etc etc né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’il transporte. « 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 de celui-ci.


/124

JMJ

12 Lecture d’une table d’adresse MAC par SNMP

Comme mentionné au paragraphe 10.2 Indexation multiple page 64, une adresse MAC sur un équipement est associée d’une part à l’interface physique de l’équipement par laquelle cette adresse MAC est apprise, et d’autre part le VLAN configuré pour cette interface. Il y est également mentionné que la requête à formuler est «Toutes les adresses Mac pour toutes les interfaces et pour tous les VLANs ».

12.1 Vlans Il convient d’établir la liste de tous les VLANS actifs sur cet équipement. Cette table est retournée par l’OID : .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoVtpMIB.vtpMIBObjects.vlanInfo.vtpVlanTable.vtpVlanEntry.vtpVlanState (.1.3.6.1.4.1.9.9.46.1.3.1.1.2)

12.1.1 Getif

Figure 41: Getif : Table de l’état des Vlans

12.1.2 CLI La commande ci-après retourne la même table :

sho vlan VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1 default active Gi1/2, Gi1/3, Gi1/4, Gi1/5, Gi1/7, Gi1/9, Gi1/10, Gi1/11, Gi1/12, Gi1/13, Gi1/14, Gi1/15, Gi1/16, Gi1/17, Gi1/19 Gi1/20, Gi1/21, Gi1/22, Gi1/23, Gi1/24, Gi1/25, Gi1/26, Gi1/27, Gi1/28, Gi1/29, Gi1/30, Gi1/31, Gi1/33 2 VLAN0002 active Gi1/6, Gi1/18, Gi1/37, Gi1/38, Gi1/41, Gi1/44 126 VLAN0126 active Gi1/1, Gi1/34, Gi1/35, Gi1/36 232 VLAN0232 active 702 VLAN0702 active 703 VLAN0703 active


/124

JMJ

705 VLAN0705 active Gi1/8 706 VLAN0706 active 707 VLAN0707 active 708 VLAN0708 active 709 VLAN0709 active 710 VLAN0710 active 711 VLAN0711 active 712 VLAN0712 active 713 VLAN0713 active 802 VLAN0802 active 803 VLAN0803 active Gi1/42, Gi1/43 804 VLAN0804 active 805 VLAN0805 active 806 VLAN0806 active 807 VLAN0807 active Gi1/32 808 VLAN0808 active 809 VLAN0809 active 810 VLAN0810 active 812 VLAN0812 active 842 VLAN0842 active 1002 fddi-default act/unsup 1003 token-ring-default act/unsup 1004 fddinet-default act/unsup 1005 trnet-default act/unsup VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 ---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------ 1 enet 100001 1500 - - - - - 0 0 2 enet 100002 1500 - - - - - 0 0 126 enet 100126 1500 - - - - - 0 0 232 enet 100232 1500 - - - - - 0 0 702 enet 100702 1500 - - - - - 0 0 703 enet 100703 1500 - - - - - 0 0 705 enet 100705 1500 - - - - - 0 0 706 enet 100706 1500 - - - - - 0 0 707 enet 100707 1500 - - - - - 0 0 708 enet 100708 1500 - - - - - 0 0 709 enet 100709 1500 - - - - - 0 0 710 enet 100710 1500 - - - - - 0 0 711 enet 100711 1500 - - - - - 0 0 712 enet 100712 1500 - - - - - 0 0 713 enet 100713 1500 - - - - - 0 0 802 enet 100802 1500 - - - - - 0 0 803 enet 100803 1500 - - - - - 0 0 804 enet 100804 1500 - - - - - 0 0 805 enet 100805 1500 - - - - - 0 0 806 enet 100806 1500 - - - - - 0 0 807 enet 100807 1500 - - - - - 0 0 808 enet 100808 1500 - - - - - 0 0 809 enet 100809 1500 - - - - - 0 0 810 enet 100810 1500 - - - - - 0 0 812 enet 100812 1500 - - - - - 0 0 842 enet 100842 1500 - - - - - 0 0 1002 fddi 101002 1500 - - - - - 0 0 1003 tr 101003 1500 - - - - - 0 0 1004 fdnet 101004 1500 - - - ieee - 0 0 1005 trnet 101005 1500 - - - ibm - 0 0 Remote SPAN VLANs ------------------------------------------------------------------------------ Primary Secondary Type Ports ------- --------- ----------------- ------------------------------------------


/124

JMJ

12.1.3 PERL

### Get Active VLANS @Tabl = snmpwalk($community.$Object,$MibVtpVlanState); foreach $Line (@Tabl) { ($Vlan,$Status) = split (/:/,$Line); if ($Status) { ($T0,$T1) = split (/\./,$Vlan); push (@TabVlan, $T1) unless ($T1 > 1000) ; # WARNING : vlans greater than 1000 are ignored !!! } } Debug (" Liste of VLANs created ;");

12.2 Adresse MAC Afin de préciser pour quel VLAN la recherche d’adresses MAC est effectuée, il convient d’indexer la Community String par le VLAN en question. Si celle-ci est configuré à “public” et que la recherche d’adresse MAC est effectuée pour le VLAN 126, la Community String à utiliser est : “public@126”.

Getif: Community String indexée Une interrogation, avec cette Community String, de l’OID : .iso.org.dod.internet.mgmt.mib-2.dot1dBridge.dot1dTp.dot1dTpFdbTable.dot1dTpFdbEntry.dot1dTpFdbAddress

(.1.3.6.1.2.1.17.4.3.1.1) retourne :

Figure 42: Getif: Table d’adresse MAC pour le Vlan 126


/124

JMJ

Ce qui signifie que les adresses MAC suivantes ont été détectées dans le VLAN 126 sur cet équipement : L’adresse MAC 0:0:12:7:172:0 Base10 est 0:0:c:7:ac:0 Base 16 – Hex Etc Etc

12.2.1 CLI Cette valeur est bien sûr aussi disponible par la commande suivante

sho mac-address-table Unicast Entries vlan mac address type protocols port -------+---------------+--------+---------------------+-------------------- 126 0000.0c07.ac00 dynamic ip Port-channel5 126 0002.a58b.6a6d dynamic ip Port-channel5 126 0002.a5e7.881b dynamic ip Port-channel5 126 0002.a5f0.061e dynamic assigned,other Port-channel5 Etc etc

12.2.2 PERL En PERL cette interrogation qui retourne des données typées « octetstr » (voir chapitre 7.4.1 Représentation page 16)

foreach $Vlan (@TabVlan) { # Read the MAC address per VLAN # All mib variables are indexed by Decimal ($DeciMAC,$HexMAC) = split (/:/, $Line,2); $UMac = $UMac1 = $HEXMAC = ""; @Table1 = (); $UMac = unpack 'H*', $HexMAC; @Table1 = $UMac =~ /../g; $UMac1 = join (':', @Table1); $HEXMAC = uc($UMac1); }

12.3 Ports En conservant la Community String indexée, il convient d’interroger l’équipement pour connaître maintenant sur quel port quelle adresse MAC a été vue.


/124

JMJ

12.3.1 Getif

Figure 43: Getif: Table d’adresse MAC par port pour le VLAN 126 Ce qui signifie que l’adresse MAC 0.0.12.7.172.0 a été apprise par le biais du port 645, dans le VLAN 126 (index utilisé pour la Community String indexée).

12.3.2 CLI Il n’y a pas de commande équivalente.

12.3.3 PERL

@Tabl_MACPort = snmpwalk($IndexedCS.$Object,$Mibdot1dTpFdbPort); # Decimal:port foreach $Line (@Tabl_MACPort) { ($T0,$T1) = split (/:/, $Line); $T0 = $Vlan."@".$T0; $MACPort{$T0} = $T1; # T0 = [email protected] : T1 = 72 }

Table 31: PERL : Table d’adresse MAC par port pour le VLAN 126

12.4 Port Interface Index Il convient à ce stade d’associer le port d’index 645 à une interface physique de l’équipement. Pour ce faire il convient d’utiliser l’OID: .iso.org.dod.internet.private.enterprises.cisco.workgroup.ciscoStackMIB.portGrp.portTable.portEntry.portIfIndex (.1.3.6.1.4.1.9.5.1.4.1.1.11) Ou, pour certains équipements ne répondant pas à cet OID (tels que Cisco Access Points, Cisco Switch 4948,…) il convient d’utiliser : .iso.org.dod.internet.mgmt.mib-2.dot1dBridge.dot1dBase.dot1dBasePortTable.dot1dBasePortEntry.dot1dBasePortIfIndex (.1.3.6.1.2.1.17.1.4.1.2)


/124

JMJ

12.4.1 Getif

Figure 44: Getif: Correspondance Port – Interface Ce qui signifie que le port d’index 645 fait référence à l’interface d’index 57.

12.4.1 CLI Il n’y a pas de commande équivalente.

12.4.2 PERL

####################### Ports #################### @Tabl = snmpwalk($community.$Object,$MibPortIfIndex); # x.y:z 1.10:10008 Port of Index 1.10 refers interface 10008 if (!defined $Tabl[0] ) { print "Obj=$Object;No SNMP response to Port Queries ($MibPortIfIndex)\n"; # Cisco AP ie # Cisco 4500 and 4948 does not answer to this Query also => try Mibdot1dBasePortIfIndex # Trying Mibdot1dBasePortIfIndex print " Trying $Mibdot1dBasePortIfIndex \n"; @Tabl = snmpwalk($community.$Object,$Mibdot1dBasePortIfIndex); # 645:57 # 647:58 } %PortIfIndex = (); foreach $Line (@Tabl) { ($T0,$T1) = split (/:/,$Line); $PortIfIndex{$T1} = $T0; # ATTENTION } @Tabl = snmpwalk($community.$Object,$MibPortVLAN); # 1.8 : 1 ( Trunk) or 1.12:804 %PortVLAN = (); foreach $Line (@Tabl) { ($T0,$T1) = split (/:/,$Line); $PortVLAN{$T0} = $T1; }

Table 32: PERL : Correspondance Port – Interface

12.5 Interface


/124

JMJ

Afin de déterminer de quelle interface il s’agit, il convient d’interroger l’OID: .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifDescr (.1.3.6.1.2.1.2.2.1.2)

12.5.1 Getif

Figure 45: Getif: Correspondance Index – Interface L’interface d’index 57 est le Port-Channel5 configuré sur l’équipement.

12.5.2 PERL

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

Table 33: PERL : Correspondance Index – Interface

12.6 En combinant le tout Toutes les étapes précédentes combinées entre-elles retournent la même information que :

bazh17#sho mac-address-table Unicast Entries vlan mac address type protocols port -------+---------------+--------+---------------------+-------------------- 126 0000.0c07.ac00 dynamic ip Port-channel5 126 0002.a58b.6a6d dynamic ip Port-channel5 126 0002.a5e7.881b dynamic ip Port-channel5 Etc etc


/124

JMJ

13 Considérations supplémentaires concernant les adresses MAC.

L’accès à des données fiables concernant les adresses MAC, telles que l’adresse MAC 12.34.56 est connectées au Switch abch01.mydomain.com sur le port FastEthernet0/21 est dans certains cas d’une importance capitale. Ceci est particulièrement vrai dès que le réseau à supperviser est quelque peu étendu et que la connection d’appareils au réseau (aux switchs) n’est pas à 100 % sous votre contrôle – Si vous croyez avoir ce contrôle à 100%, comment le verifiez-vous ?-. Quelques uns des bénéfices obtenus par la disposition d’une table fiable d’adresses MAC sont décrits dans le document JMon-ManuelOperatoire-Vxx. (xx étant l’indice le plus élevé de la version). Il n’aura pas échappé au lecteur assidu, l’accent mis sur la fiabilité des données contenues dans cette table des adresses MAC. Le plus haut degré de fiabilité de ces données est obtenu lorsque l’équipement de réseau auquel est connecté / deconnecté un appareil est capable d’informer – par Trap – la station de supervision qui tient à jour la base de données des adresses MAC. Jmon utilise cette possibilité disponible sur les équipements Cisco9. Lorsque cette fonctionalité n’est pas utilisable, la collecte des adresses MAC doit être réalisée en interrogeant tel que décrit dans le chapitre 12 : Lecture d’une table d’adresse MAC par SNMP page 82, tous les équipements réseau auxquels il est possible de connecter un appareil (principalement les switchs). Les paragraphes suivants de ce chapitre se rapportent exclusivement à cette forme de collecte. Jmon réalise cette collecte une fois par semaine. La durée de cette collecte, sur un réseau similaire au réseau décrit au chapitre 11 : Quelques chiffres et calculs élémentaires page 66 est de l’ordre de 200 minutes.

13.1 Quand collecter ces informations De toute évidence cette collecte doit avoir lieu aux moments durant lesquels les appareils sont connectés au réseau. En effet, sur les équipements Cisco, le paramètre mac-adress-table aging-time a par défaut la valeur 400 (ou 300 selon les équipements et Version d’IOS). Ceci signifie qu’après 400 (ou 300) secondes après le dernier paquet vu avec cette adresse MAC, l’équipement efface cette adresse de sa table d’adresses MAC. Si la collecte des adresse MAC à lieu durant la nuit, il est fort probable que beaucoup d’appareils – même non débranchés- aient été silencieux depuis plus de 400 (ou 300) secondes, et donc que leur adresse MAC ait disparue de la table d’adresses MAC des équipements interrogés. Il est à noter aussi, que même en pleine journée de travail, des apareils peuvent rester « silencieux » durant plus de400 (ou 300) secondes. C’est le cas des imprimantes en particulier.

13.2 Quelles informations stocker Le but de la table des adresses MAC est de savoir sur quel équipemet et quelle 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 effet, considérons le schéma suivant :

9 Voir à ce sujet le document JMon-NAC-Vxx


/124

JMJ

L’information qu’il convient de stocker est que « Appareil » est connecté à l’interface Fa0/25 du Switch B, dans le Vlan X. Or de part l’implémentation du protocole ARP et de la manière dont un switch Cisco emplit sa table d’adresse MAC, le Routeur, le SwitchA et le Switch B – du schéma ci-dessus- dispose d’une entrée dans leur table d’adresses MAC concernant « Appareil ».

13.2.1 Exemple Dans le cas du schéma précedant, prenons l’exemple ou nous cherchons « Appareil » connaissant son adresse MAC : 00 08.74ed.acb2. Supposons aussi que nous sachions que cet appareil est connecté au réseau, dans la filiale abc.

13.2.1.1 Routeur Il est logique d’interroger en premier lieu le Routeur de la filiale abc, qui est toujours le « point d’entée » dans une filiale :

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

L’adresse MAC recherchée est connue sur l’interface Gi1/0/1 dans le Vlan 308. L’interface Gi1/0/1 est configurée de la sorte :

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

Grace aux Best Practices énnoncées au paragraphe 9.1.4 : Autres paramètres généraux page 37, nous savons de suite que « Appareil » n’est pas connecté à cette interface, mais qu’il s’agit su Switch A. Si ses Best Practices ne son pas (encore) appliquées, la commande suivante permet de trouver cette information :

Routeur#sho cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone Device ID Local Intrfce Holdtme Capability Platform Port ID Etc Switch-A.mydomain.com Gig 1/0/1 165 S I WS-C3560-2Gig 0/1 etc

Bien sur 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 la documentation soit à jour… Dans tous les cas, il convient de ne pas de stocker dans la base de données des adresses MAC le triplet [Vlan, Switch, interface] suivant : [308, Routeur, Gi1/0/1].

Routeur Switch A Switch B Appareil Fa0/25

Filiale abc


/124

JMJ

Il convient de réiterer ces mêmes interrogations sur le Switch-A :

13.2.1.2 Switch-A

Switch-A#sho mac-address-table | incl 0008.74ed.acb2 308 0008.74ed.acb2 DYNAMIC Gi0/2 Switch-A #sho run int Gi0/2 Building configuration... Current configuration : 182 bytes ! interface GigabitEthernet0/2 description Switch-B Gi 0/1 switchport trunk encapsulation dot1q switchport trunk allowed vlan 1-1024 switchport mode trunk mls qos trust dscp end Switch-A #sho cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone Device ID Local Intrfce Holdtme Capability Platform Port ID Etc Switch-B.mydomain.c Gig 0/2 178 S I WS-C3560-4Gig 0/1 etc

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

13.2.1.3 Switch-B

Switch-B#sho mac-address-table | incl 0008.74ed.acb2 308 0008.74ed.acb2 DYNAMIC Fa0/25 Switch-B#sho run int Fa0/25 Building configuration... Current configuration : 394 bytes ! interface FastEthernet0/25 switchport trunk encapsulation dot1q switchport trunk native vlan 308 switchport trunk allowed vlan 308,309,800,826 switchport mode trunk speed 100 duplex full snmp trap mac-notification added snmp trap mac-notification removed no mdix auto no cdp enable spanning-tree portfast trunk spanning-tree bpduguard enable service-policy input policy-QoS end

Cette interface est une interface de connection d’appareils, « Appareil » y est connecté, il convient de stocker dans la base de données des adresses MAC le triplet [Vlan, Switch, interface] suivant : [308, Switch-B, Fa0/25].


/124

JMJ

13.3 Automatisation L’exemple précédant est un bel exemple pédagogique. Comment associer automatiquement 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 disposition que des informations collectées par SNMP et la connaissance du réseau à superviser. Cette connaissance du réseau à superviser nous apporte la connaissance que la Best Practice suivante à été mise en œuvre : Best Practices Ne pas utiliser le VLAN 1 pour y connecter des appareils. Mettre en œuvre au moins 2 VLANS : Un Vlan « Donnéees » pour les appareils Un Vlan de management pour adresser les équipements réesau

13.3.1 Native Vlan Sachant que cette Best Practice à été mise en œuvre, la première information qu’il vient à l’idée d’exploiter est d’ignorer les adresses MAC connues de port dont le VLAN natif est égal à 1. La MIB CISCO-VTP-MIB nous donne accès à cette information :

Une interrogation du Routeur retourne les informations suivantes (l’interface Gi1/0/1 est d’index 10101):


/124

JMJ

Une interrogation du Switch-A retourne aussi que l’interface Gi0/2 à pour VLAN natif le Vlan 1. Une interrogation du Switch-B retourne les informations suivantes :

La règle parait vérifiée tant que l’interface considérée est en mode Trunk (cela n’a pas de sens de définir un VLAN natif si l’interface n’est pas dans ce mode). Quelle valeur est retournée en réponse à une requête relative à un port configuré en mode Access ? Pour un port en mode accès, la même interrogation retourne la valeur 1, interdisant d’appliquer la règle simple d’ignorer les adresses MAC connues de port dont le VLAN natif est égal à 1 : En effet, une adresse MAC apprise sur un port configuré en mode Acces doit être associée dans la base de données des adresses MAC à cette interface.

13.3.2 Trunk Port Synamic Status La règle précédente convient d’être complétée de la sorte afin de conserver les adresses MAC connues de ports en mode Access: ignorer les adresses MAC connues de port dont le VLAN natif est égal à 1 ET dont le port est en mode Trunk. L’information Trunk ou non est obtenue par la MIB CISCO-VTP-MIB:


/124

JMJ

13.4 Programme PERL En annexe se trouve le listing complet du programme PERL GetMAC.pl, utilisé par Jmon pour collecter les adresses MAC du réseau supervisé. L’exécution de ce programme en mode « debug » produit les traces suivantes, récapitulant les paragraphes ci-dessus.

[jur466@nocu07 bin]$ ./GetMAC.pl -debug -o myswitch.mydomain.com Connection to Data Bank : - Object = myswitch.mydomain.com - ForIndex = 0 Active Vlan:1 Active Vlan:300 Active Vlan:304 Active Vlan:308 . . . . Lignes supprimées . . . . List of active VLANs created ; Native Vlan of 10001= 300 Native Vlan of 10002= 300 Native Vlan of 10003= 300 Native Vlan of 10004= 300 Native Vlan of 10005= 300 . . . . Lignes supprimées . . . . Native Vlan of 10047 = 308 Native Vlan of 10048= 1 Native Vlan of 10101= 1 Native Vlan of 10102= 1 Native Vlan of 10103= 1 Native Vlan of 10104= 1 List of Native VLANs per port created ; Processing VLAN:1; 300; 304; 308; 309; 310; 322; 330; 332; 333; 800; 801; 804; 826; 849; 850; 851; 853; 854; 857; 243 MAC Addresses invalidated for myswitch.mydomain.com (`Mac_IsPartOf` = ' myswitch.mydomain.com') Skipping [email protected] / 10101 => Native Vlan = 1 (GigabitEthernet0/1) Skipping [email protected] / 10101 => Native Vlan = 1 (GigabitEthernet0/1) Skipping [email protected] /10101 => Native Vlan = 1 (GigabitEthernet0/1) . . . . Lignes supprimées . . . . MAC Address already in DB (295306) Validating MAC Addresses 00:1B:0C:FC:98:2A for myswitch.mydomain.com', 300, 10005 Skipping [email protected] / 10101 => Native Vlan = 1 (GigabitEthernet0/1) Skipping [email protected] / 10101 => Native Vlan = 1 (GigabitEthernet0/1) Skipping [email protected] /10101 => Native Vlan = 1 (GigabitEthernet0/1) MAC Address already in DB (295308) Validating MAC Addresses 00:1B:0C:FC:98:AA for myswitch.mydomain.com', 300, 10003 . . . . Lignes supprimées . . . .


/124

JMJ

14 Trunking Protocol

Dans un environnement comprenant beaucoup de Vlans, chaque port (ou groupe de ports) d’un switch peut être configuré différemment des autres ports (ou groupe de ports) de ce même switch. La séparation fonctionnelle et logique recherchée par la création de vlan fait qu’une interface de switch peut être : En mode access ou en mode trunk Seuls quelques VLANS peuvent être autorisés ou tous, en mode trunk (Vlan allowed) L’accès à ces information (informations relatives au Trunking Protocol) sans avoir à se connecter au switch et à en lire sa configuration peut se révéler d’une grande importance : un service de l’entreprise tel que le « Help-Desk », qui pour des raisons de sécurité et de confidentialité n’a pas accès aux switchs ni à leurs configurations, peut avoir accès à ces informations et peut renseigner un partenaire externe amené à connecter des équipements sur le réseau.

Figure 46: Informations VTP

14.1 Interfaces et ports La représentation ci-dessus nécessite de connaître toutes les interfaces du switch ainsi que leur description. Il sera procédé comme déjà mentionné à plusieurs reprise en utilisant les


/124

JMJ

MIBs .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifIndex (.1.3.6.1.2.1.2.2.1.1) et .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifDescr (.1.3.6.1.2.1.2.2.2). Comme pour les adresses MAC, les informations VTP sont relatives à des ports, il convient de faire l’association Ports ó Interfaces telle que déjà réalisée pour les adresses MAC, à savoir en utilisant les MIBs .iso.org.dod.internet.private.enterprises.cisco.workgroup.ciscoStackMIB.portGrp.portTable.portEntry.portIfIndex (1.3.6.1.4.1.9.5.1.4.1.1.11)

14.2 VLANs ó Ports La MIB .iso.org.dod.internet.private.enterprises.cisco.workgroup.ciscoStackMIB.vlanGrp.vlanPortTable.vlanPortEntry.vlanPortVlan (1.3.6.1.4.1.9.5.1.9.3.1.3) nous permet de connaître à quel VLAN un port appartient.

Figure 47: Cisco Stack MIB : Vlan index


/124

JMJ

14.2.1 Getif

Figure 48: Getif : Association VLAN ó Ports

14.2.2 PERL

$MibPortVLAN = "1.3.6.1.4.1.9.5.1.9.3.1.3"; @Tabl_PortVLAN = snmpwalk($community.$ObjectV2,$MibPortVLAN); %PortVLAN = (); %IsAccess = (); foreach $Line (@Tabl_PortVLAN) { ($T0,$T1) = split (/:/,$Line); $PortVLAN{$T0} = $T1; if ($T1 # We assume that > 1 is a VLAN $IsAccess{$PortToIndex{$T0}} = 1; } }

14.3 VLAN natif Telle que déjà vu précédemment, la MIB .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoVtpMIB.vtpMIBObjects.vlanTrunkPorts.vlanTrunkPortTable.vlanTrunkPortEntry.vlanTrunkPortNativeVlan (.1.3.6.1.4.1.9.9.46.1.6.1.1.5) nous permet de connaître quel (index de) VLAN natif est assigné à un port.

14.4 Trunks La liste des ports configurés en mode trunks est obtenue, telle que déjà vu précédemment, la MIB, par le biais de la MIB .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoVtpMIB.vtpMIBObjects.vlanTrunkPorts.vlanTrunkPortTable.vlanTrunkPortEntry.vlanTrunkPortDynamicStatus (.1.3.6.1.4.1.9.9.46.1.6.1.1.14


/124

JMJ

14.5 VLANs autorisés Les paragraphes précédents de ce chapitre n’apportent pas vraiment d’information supplémentaire par rapport aux exemples précédemment cités. La lecture des VLANs autorisés par port est par contre très intéressante de par la façon dont cette information est transmise par SNMP. La MIB nous permettant d’accéder à cette information est : .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoVtpMIB.vtpMIBObjects.vlanTrunkPorts.vlanTrunkPortTable.vlanTrunkPortEntry.vlanTrunkPortVlansEnabled (.1.3.6.1.4.1.9.9.46.1.6.1.1.4).

Figure 49: Cisco Stack MIB : Vlan Enabled

La valeur retournée est une chaine d’octets dont chaque bit est représentatif d’un VLAN. Le rang du bit est le rang (de l’index) du VLAN. La valeur « 1 » indique que ce VLAN ( le VLAN dont l’index est…) est autorisé. Si un ou plusieurs VLANs de rang supérieur à 1023 sont configurés il conviendra d’utiliser les MIBs suivantes : .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoVtpMIB.vtpMIBObjects.vlanTrunkPorts.vlanTrunkPortTable.vlanTrunkPortEntry.vlanTrunkPortVlansEnabled2k (.1.3.6.1.4.1.9.9.46.1.6.1.1.17) pour un rang compris entre 1024 et 2047, .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoVtpMIB.vtpMIBObjects.vlanTrunkPorts.vlanTrunkPortTable.vlanTrunkPortEntry.vlanTrunkPortVlansEnabled3k (.1.3.6.1.4.1.9.9.46.1.6.1.1.18) pour un rang compris entre 2048 et 3071, .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoVtpMIB.vtpMIBObjects.vlanTrunkPorts.vlanTrunkPortTable.vlanTrunkPortEntry.vlanTrunkPortVlansEnabled4k (.1.3.6.1.4.1.9.9.46.1.6.1.1.19) pour un rang compris entre 3072 et 4095.


/124

JMJ

14.5.1 Getif

Figure 50: Getif : Vlans Enabled (Allowed)

Cette représentation par Getif n’est pas satisfaisante, loin de là.

14.5.2 PERL Analysons plus en détail les valeurs retournées, par exemple pour une interface configurée de la sorte :

interface FastEthernet0/8 description IP_Telefon_1750 switchport trunk encapsulation dot1q switchport trunk native vlan 134 switchport trunk allowed vlan 134,827 switchport mode trunk etc etc . . .

Comme nous l’avons vu, il est impossible de représenter ici la valeur directement retournée par une interrogation de la MIB .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoVtpMIB.vtpMIBObjects.vlanTrunkPorts.vlanTrunkPortTable.vlanTrunkPortEntry.vlanTrunkPortVlansEnabled, cette valeur étant une chaine de bit, par conséquent non imprimable. Sous *nix la commande suivante nous retourne :

snmpwalk -c MailleCommunity MySwitch .1.3.6.1.4.1.9.9.46.1.6.1.1.4 .1.3.6.1.4.1.9.9.46.1.6.1.1.4.10001 = Hex-STRING: 7F FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF


/124

JMJ

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF . . . . Lignes supprimées . . . . .1.3.6.1.4.1.9.9.46.1.6.1.1.4.10008 = Hex-STRING: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16 octets par ligne 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8 Lignes

Figure 51: Représentation des VLANs allowed sous *nix Nous nous intéressons à l’interface d’Index 10008, car cet Index référence l’interface qui nous préoccupe. Cette représentation n’est guère plus satisfaisante que celle proposée par Getif. Elle va néanmoins nous permettre de vérifier que nous avons bien compris la représentation utilisée pour nous signifier qu’un VLAN est “allowed” La valeur retournée est de longueur 16 [octets/ligne] x 8 [lignes] x 8 [bits/octet] = 1024 bits. Chaque bit représentant un VLAN, la valeur retournée représente bien les 1024 premiers VLANs. La première ligne est représentative des VLANs 0 à 127. L’écriture du premier octet de la deuxième ligne – de valeur 0210- est :

2e ligne (binaire) 0 0 0 0 0 0 1 0 rang du VLAN 128 129 130 131 132 133 134 135

Le rang du premier bit à “1” est 134 => le premier VLAN “allowed” est le VLAN 134. De même pour la valeur 10, le rang du bit à “1” est 827. Nous retrouvons bien par cette requête la configuration de l’interface Fa0/8 relative au “allowed vlan”, sans avoir une représentation plus utile de cette configuration que celle obtenue par les outils utilisés jusqu’à présent. Un peu de programmation PERL sera nécessaire pour rendre la valeur retournée plus rapidement lisible.

@Tabl_VlansEnabled = snmpwalk($community.$ObjectV2,$MibVtpvlanTrunkPortVlansEnabled); foreach $Line (@Tabl_VlansEnabled) { ($Index,$str) = split (/:/,$Line); $bits = unpack 'B*', $str ; my @ones_offsets; push @ones_offsets, $-[1] while $bits =~ m{(1)}xmsg; $NbVlans = @ones_offsets; print "No one bits found" unless @ones_offsets; print "$Object $Descr{$Index} (Is Trunk : $IsTrunk{$Index} Native Vlan = $NativeVlan{$Index}): the allowed vlans are : "; if ($NbVlans == 1023) { print "All VLANS allowed on Interface $Descr{$Index} (No Vlan allowed statement)"; } else { foreach $BitOffset (@ones_offsets) { print "$BitOffset "; } } print "\n"; }

En annexe se trouve le listing complet du programme PERL GetVTP.pl, utilisé par Jmon pour afficher les VLANs « allowed ».


/124

JMJ

L’exécution de ce programme produit les traces suivantes, récapitulant les paragraphes ci-dessus.

./GetVTP.pl -o MySwitch . . . . Lignes supprimées . . . . MySwitch FastEthernet0/8 (Is Trunk : 1 Native Vlan = 134): the allowed vlans are : 134 827 . . . . Lignes supprimées . . . .

15 Spanning Tree Protocol

Dans une architcture de réseau redondante, un accès synthétique aux informations du Spanning Tree Protocol est d’une grande utilité. Jmon, en utilisant uniquement SNMP permet d’afficher les informations suivantes:

Figure 52: SNMP et Panning Tree Protocol

La MIB utilisée pour afficher ces informations est la Bridge-Mib (1.3.6.1.2.1.17):

Figure 53: Bridge-MIB


/124

JMJ

Figure 54: Bridge-MIB par Getif

A ce stade du document, l’interprétation de cette MIB ne devrait plus poser de problème et nous n’expliquerons pas ici tous les OIDs utilisés. L’extrait du programme PERL ci-dessous devrait être suffisamment explicite.

15.1 PERL Ci-dessous un extrait de programme PERL exploitant la MIB Bridge-MIB afin d’afficher les informations relatives au Spanning Tree Protocol.

$Mibdot1dTpFdbPort = "1.3.6.1.2.1.17.4.3.1.2"; $Mibdot1dBasePort = "1.3.6.1.2.1.17.1.4.1.1"; $Mibdot1dBasePortIfIndex = "1.3.6.1.2.1.17.1.4.1.2"; $Mibdot1dTpFdbAddress = "1.3.6.1.2.1.17.4.3.1.1"; $Mibdot1dStpPrority = "1.3.6.1.2.1.17.2.2"; $Mibdot1dStpRootCost = "1.3.6.1.2.1.17.2.6"; $Mibdot1dStpRootPort = "1.3.6.1.2.1.17.2.7"; $Mibdot1dStpPortPriority = "1.3.6.1.2.1.17.2.15.1.2"; $Mibdot1dStpPortState = "1.3.6.1.2.1.17.2.15.1.3"; $Mibdot1dStpPortPathCost = "1.3.6.1.2.1.17.2.15.1.5"; ######################### STP INFO ######################################### @Tabl_dot1dBasePort = snmpwalk($community.$ObjectV2,$Mibdot1dBasePort); foreach $Line (@Tabl_dot1dBasePort) { } @Tabl_PortIfIndex = snmpwalk($community.$ObjectV2,$Mibdot1dBasePortIfIndex); # 645:57 # 647:58 %PorttoIndex = (); foreach $Line (@Tabl_PortIfIndex) { ($T0,$T1) = split (/:/,$Line); #$PortIfIndex{$T1} = $T0; # ATTENTION $PortToIndex{$T0} = $T1; print "- 2 - If Index of Port: $T0 is $T1 ($Descr{$T1}) \n"; } @Tabl_dot1dStpPrority = snmpwalk($community.$ObjectV2,$Mibdot1dStpPrority); foreach $Line (@Tabl_dot1dStpPrority) { ($T0,$T1) = split (/:/,$Line); print "- 3 - Bridge Identifier has priority : $T1 \n"; }


/124

JMJ

@Tabl_dot1dStpRootCost = snmpwalk($community.$ObjectV2,$Mibdot1dStpRootCost); foreach $Line (@Tabl_dot1dStpRootCost) { ($T0,$T1) = split (/:/,$Line); print "- 4 - Bridge Cost of Root Path : $T1 \n"; } @Tabl_dot1dStpRootPort = snmpwalk($community.$ObjectV2,$Mibdot1dStpRootPort); foreach $Line (@Tabl_dot1dStpRootPort) { ($T0,$T1) = split (/:/,$Line); print "- 5 - Bridge Root Port : $T1 ($Descr{$PortToIndex{$T1}}) \n"; } @Tabl_dot1dStpPortPathCost = snmpwalk($community.$ObjectV2,$Mibdot1dStpPortPathCost); foreach $Line (@Tabl_dot1dStpPortPathCost) { ($T0,$T1) = split (/:/,$Line); print "- 6 - Port Path cost of $T0 ($Descr{$PortToIndex{$T0}}) = $T1 \n"; } $MR = @Tabl_dot1dStpPortPathCost; # Max repetition ## GetBulk To be corrected : MTU @Tabl_dot1dStpPortPriority = snmpgetbulk($community.$ObjectV2,0,$MR,$Mibdot1dStpPortPriority); foreach $Line (@Tabl_dot1dStpPortPriority) { @Temp = split (/\./,$Line); # To be equivalent to snmpwalk get all after last "." (dot) ($T0,$T1) = split (/:/,$Temp[-1]); # To be equivalent to snmpwalk and split it by ":" print "- 7 - Port Priority of $T0 ($Descr{$PortToIndex{$T0}}) = $T1 \n"; } @Tabl_dot1dStpPortState = snmpgetbulk($community.$ObjectV2,0,$MR,$Mibdot1dStpPortState); foreach $Line (@Tabl_dot1dStpPortState ) { @Temp = split (/\./,$Line); # To be equivalent to snmpwalk get all after last "." (dot) ($T0,$T1) = split (/:/,$Temp[-1]); # To be equivalent to snmpwalk and split it by ":" print "- 8 - Port State of $T0 ($Descr{$PortToIndex{$T0}}) = $TablPortState[$T1] \n"; }

16 CDP

Cisco Discovery Protocol (CDP) est un protocol propriétaire developpé par Cisco permettant d’échanger des informations entre deux équipements Cisco directement connectés. Un équipement Cisco émet une annonce CDP toute les 60 secondes par toutes les interfaces connectées, en admettant que CDP soit autorisé sur cette interface. Tout équipement Cisco supportant CDP mémorise les informations recues des équipements voisins. L’accès à ces informations est effectué soit par CLI, soit par SNMP La nature du contenu de ces annonces CDP varie fortement en foncion des équipements et des versions logicielles. Principalement sont véhiculées des informations relatives à : Nom et adresse IP Interface par lequel l’annonce est émise Type d’équipement Modèle Dupplex Domaine VTP VLAN natif Consommation électrique (pour les èquipement POE) Ne pas oublier : ces informations se rapportent à l’éméteur.

16.1 CLI La commande suivante permet d’afficher une partie de ces informations :

bazr02#sho cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone Device ID Local Intrfce Holdtme Capability Platform Port ID bazh04.mydomain.com Gig 1/0/5 167 S I WS-C3750G Gig 1/0/11


/124

JMJ

ip-man-ch-bsk-r-006 Gig 2/0/3 153 R S I ME-C3750- Gig 1/0/1 ip-man-ch-bsk-r-008 Gig 2/0/4 171 R 7204VXR Fas 0/0 bazr05.mydomain.com Gig 1/0/6 130 R S I WS-C6509- Gig 2/4 bazr05.mydomain.com Gig 1/0/3 140 R S I WS-C6509- Gig 1/4 mgtr12.mydomain.com Gig 1/0/1 127 R S I WS-C6509 Gig 6/2 bazr03.mydomain.com Gig 1/0/12 137 R S I WS-C3750G Gig 1/0/12 yyyr02.mydomain.com Gig 1/0/4 124 R S I WS-C3560- Gig 0/1

Nous informant que l’équipemet bazr02 est connectés via son interface Gi1/0/5 à l’équipement bazh04.MyDomain.com via l’interface Gig1/0/11 de celui-ci. De plus l’équipement bazh04.MyDomain.com est un WS-C3750G.

17 ARP


/124

JMJ

18 Getif

Dans getif expliquer le chargement des Mibs et ce que cela apporte dans le champ « description »


/124

JMJ

Annexes


/124

JMJ

1 Cisco system Object IDs

Series;Device;ID Cisco 3800 Series Integrated Services Routers;3825;1.3.6.1.4.1.9.1.543 Cisco 3800 Series Integrated Services Routers;3845;1.3.6.1.4.1.9.1.544 Cisco MC3810 Multiservice Access Concentrators;MC3810;1.3.6.1.4.1.9.1.157 Cisco MC3810 Multiservice Access Concentrators;Mc3810V3;1.3.6.1.4.1.9.1.286 Cisco 3700 Series Multiservice Access Routers;3725;1.3.6.1.4.1.9.1.414 Cisco 3700 Series Multiservice Access Routers;3745;1.3.6.1.4.1.9.1.436 Cisco 3600 Series Multiservice Platforms;3620;1.3.6.1.4.1.9.1.122 Cisco 3600 Series Multiservice Platforms;Pro3620;1.3.6.1.4.1.9.1.123 Cisco 3600 Series Multiservice Platforms;3631Co;1.3.6.1.4.1.9.1.425 Cisco 3600 Series Multiservice Platforms;3640;1.3.6.1.4.1.9.1.110 Cisco 3600 Series Multiservice Platforms;Pro3640;1.3.6.1.4.1.9.1.124 Cisco 3600 Series Multiservice Platforms;SC3640;1.3.6.1.4.1.9.1.189 Cisco 3600 Series Multiservice Platforms;3660;1.3.6.1.4.1.9.1.205 Cisco 3600 Series Multiservice Platforms;3661Ac;1.3.6.1.4.1.9.1.338 Cisco 3600 Series Multiservice Platforms;3661Dc;1.3.6.1.4.1.9.1.339 Cisco 3600 Series Multiservice Platforms;3662Ac;1.3.6.1.4.1.9.1.340 Cisco 3600 Series Multiservice Platforms;3662Dc;1.3.6.1.4.1.9.1.341 Cisco 3600 Series Multiservice Platforms;3662AcCo;1.3.6.1.4.1.9.1.342 Cisco 3600 Series Multiservice Platforms;3662DcCo;1.3.6.1.4.1.9.1.343 Cisco 2800 Series Integrated Services Routers;2801;1.3.6.1.4.1.9.1.619 Cisco 2800 Series Integrated Services Routers;2811;1.3.6.1.4.1.9.1.576 Cisco 2800 Series Integrated Services Routers;2821;1.3.6.1.4.1.9.1.577 Cisco 2800 Series Integrated Services Routers;2851;1.3.6.1.4.1.9.1.578 Cisco 2600 Series Multiservice Platforms;2610;1.3.6.1.4.1.9.1.185 Cisco 2600 Series Multiservice Platforms;2610M;1.3.6.1.4.1.9.1.418 Cisco 2600 Series Multiservice Platforms;2610XM;1.3.6.1.4.1.9.1.466 Cisco 2600 Series Multiservice Platforms;2611;1.3.6.1.4.1.9.1.186 Cisco 2600 Series Multiservice Platforms;2611M;1.3.6.1.4.1.9.1.419 Cisco 2600 Series Multiservice Platforms;2611XM;1.3.6.1.4.1.9.1.467 Cisco 2600 Series Multiservice Platforms;2612;1.3.6.1.4.1.9.1.187 Cisco 2600 Series Multiservice Platforms;2613;1.3.6.1.4.1.9.1.195 Cisco 2600 Series Multiservice Platforms;2620;1.3.6.1.4.1.9.1.208 Cisco 2600 Series Multiservice Platforms;2620XM;1.3.6.1.4.1.9.1.468 Cisco 2600 Series Multiservice Platforms;2621;1.3.6.1.4.1.9.1.209 Cisco 2600 Series Multiservice Platforms;2621XM;1.3.6.1.4.1.9.1.469 Cisco 2600 Series Multiservice Platforms;2650;1.3.6.1.4.1.9.1.319 Cisco 2600 Series Multiservice Platforms;2650XM;1.3.6.1.4.1.9.1.470 Cisco 2600 Series Multiservice Platforms;2651;1.3.6.1.4.1.9.1.320 Cisco 2600 Series Multiservice Platforms;2651XM;1.3.6.1.4.1.9.1.471 Cisco 2600 Series Multiservice Platforms;2691;1.3.6.1.4.1.9.1.413 Cisco 1800 Series Integrated Services Routers;1801;1.3.6.1.4.1.9.1.638 Cisco 1800 Series Integrated Services Routers;1811;1.3.6.1.4.1.9.1.641 Cisco 1800 Series Integrated Services Routers;1812;1.3.6.1.4.1.9.1.642 Cisco 1800 Series Integrated Services Routers;1841;1.3.6.1.4.1.9.1.620 Cisco 1800 Series Integrated Services Routers;1861BCueK9;1.3.6.1.4.1.9.1.902 Cisco 1800 Series Integrated Services Routers;1861FCueK9;1.3.6.1.4.1.9.1.903 Cisco 1800 Series Integrated Services Routers;18612Bri;1.3.6.1.4.1.9.1.904 Cisco 1800 Series Integrated Services Routers;18614Fxo;1.3.6.1.4.1.9.1.905 Cisco 1700 Series Modular Access Routers;1701 ADSL;1.3.6.1.4.1.9.1.550 Cisco 1700 Series Modular Access Routers;1710;1.3.6.1.4.1.9.1.200 Cisco 1700 Series Modular Access Routers;1711;1.3.6.1.4.1.9.1.538 Cisco 1700 Series Modular Access Routers;1712;1.3.6.1.4.1.9.1.539 Cisco 1700 Series Modular Access Routers;1720;1.3.6.1.4.1.9.1.201 Cisco 1700 Series Modular Access Routers;1721;1.3.6.1.4.1.9.1.444 Cisco 1700 Series Modular Access Routers;1750;1.3.6.1.4.1.9.1.216 Cisco 1700 Series Modular Access Routers;1751;1.3.6.1.4.1.9.1.326


/124

JMJ

Cisco 1700 Series Modular Access Routers;1760;1.3.6.1.4.1.9.1.416 Cisco 800 Series Routers;801;1.3.6.1.4.1.9.1.212 Cisco 800 Series Routers;802;1.3.6.1.4.1.9.1.213 Cisco 800 Series Routers;802J;1.3.6.1.4.1.9.1.295 Cisco 800 Series Routers;803;1.3.6.1.4.1.9.1.214 Cisco 800 Series Routers;804;1.3.6.1.4.1.9.1.215 Cisco 800 Series Routers;804J;1.3.6.1.4.1.9.1.296 Cisco 800 Series Routers;805;1.3.6.1.4.1.9.1.245 Cisco 800 Series Routers;806;1.3.6.1.4.1.9.1.384 Cisco 800 Series Routers;811;1.3.6.1.4.1.9.1.395 Cisco 800 Series Routers;813;1.3.6.1.4.1.9.1.396 Cisco 800 Series Routers;826;1.3.6.1.4.1.9.1.322 Cisco 800 Series Routers;826QuadV;1.3.6.1.4.1.9.1.321 Cisco 800 Series Routers;827;1.3.6.1.4.1.9.1.284 Cisco 800 Series Routers;827H;1.3.6.1.4.1.9.1.446 Cisco 800 Series Routers;827QuadV;1.3.6.1.4.1.9.1.270 Cisco 800 Series Routers;828;1.3.6.1.4.1.9.1.382 Cisco 800 Series Routers;831;1.3.6.1.4.1.9.1.497 Cisco 800 Series Routers;836;1.3.6.1.4.1.9.1.499 Cisco 800 Series Routers;837;1.3.6.1.4.1.9.1.495 Cisco 800 Series Routers;871;1.3.6.1.4.1.9.1.571 Cisco 800 Series Routers;877;1.3.6.1.4.1.9.1.569 Cisco 800 Series Routers;878;1.3.6.1.4.1.9.1.570 Cisco Catalyst 6500 Series Switches;6506;1.3.6.1.4.1.9.1.282 Cisco Catalyst 6500 Series Switches;6509;1.3.6.1.4.1.9.1.283 Cisco Catalyst 6500 Series Switches;6509-NEB;1.3.6.1.4.1.9.1.310 Cisco Catalyst 6500 Series Switches;6509-NEBA;1.3.6.1.4.1.9.1.534 Cisco Catalyst 6500 Series Switches;WSC6513;1.3.6.1.4.1.9.1.400 Cisco Catalyst 6500 Series Switches;WSC6503;1.3.6.1.4.1.9.1.449 Cisco Catalyst 6500 Series Switches;WSC6504E;1.3.6.1.4.1.9.1.657 Cisco ME 4900 Series Ethernet Switch;Me492410GE;1.3.6.1.4.1.9.1.788 Cisco Catalyst 4500 Series Switches;4500;1.3.6.1.4.1.9.1.14 Cisco Catalyst 4500 Series Switches;Pro4500;1.3.6.1.4.1.9.1.66 Cisco Catalyst 4500 Series Switches;4503;1.3.6.1.4.1.9.1.503 Cisco Catalyst 4500 Series Switches;4506;1.3.6.1.4.1.9.1.502 Cisco Catalyst 4500 Series Switches;4507;1.3.6.1.4.1.9.1.501 Cisco Catalyst 4500 Series Switches;4510;1.3.6.1.4.1.9.1.537 Cisco Catalyst 4000 Series Switches;4948;1.3.6.1.4.1.9.1.626 Cisco Catalyst 4000 Series Switches;4948-10GE;1.3.6.1.4.1.9.1.659 Cisco Catalyst 4000 Series Switches;4908gL3;1.3.6.1.4.1.9.1.298 Cisco Catalyst 4000 Series Switches;4908gL3Dc;1.3.6.1.4.1.9.1.387 Cisco Catalyst 3750 Series Switches;371098HP001;1.3.6.1.4.1.9.1.625 Cisco Catalyst 3750 Series Switches;3750GE-12SF;1.3.6.1.4.1.9.1.530 Cisco Catalyst 3750 Series Switches;3750G-16TD;1.3.6.1.4.1.9.1.591 Cisco Catalyst 3750 Series Switches;3750-24;1.3.6.1.4.1.9.1.511 Cisco Catalyst 3750 Series Switches;3750-24T;1.3.6.1.4.1.9.1.514 Cisco Catalyst 3750 Series Switches;3750-24TS;1.3.6.1.4.1.9.1.513 Cisco Catalyst 3750 Series Switches;3750-48;1.3.6.1.4.1.9.1.512 Cisco Catalyst 3750 Series Switches;3750-stack;1.3.6.1.4.1.9.1.516 Cisco Catalyst 3750 Series Switches;WS-C3750G-24PS;1.3.6.1.4.1.9.1.747 Cisco Catalyst 3750 Metro Series Switches;ME-C3750-24TE-M;1.3.6.1.4.1.9.1.574 Cisco Catalyst 3560 Series Switches;3560-24PS;1.3.6.1.4.1.9.1.563 Cisco Catalyst 3560 Series Switches;3560-24TS;1.3.6.1.4.1.9.1.633 Cisco Catalyst 3560 Series Switches;3560-48PS;1.3.6.1.4.1.9.1.564 Cisco Catalyst 3560 Series Switches;3560G-24PS;1.3.6.1.4.1.9.1.614 Cisco Catalyst 3560 Series Switches;3560G-24TS;1.3.6.1.4.1.9.1.615 Cisco Catalyst 3560 Series Switches;3560G-48PS;1.3.6.1.4.1.9.1.616 Cisco Catalyst 3560 Series Switches;3560G-48TS;1.3.6.1.4.1.9.1.617 Cisco Catalyst 3550 Series Switches;3550-24;1.3.6.1.4.1.9.1.366 Cisco Catalyst 3550 Series Switches;3550-48;1.3.6.1.4.1.9.1.367 Cisco Catalyst 3550 Series Switches;3550-12G;1.3.6.1.4.1.9.1.431 Cisco Catalyst 3550 Series Switches;3550-12T;1.3.6.1.4.1.9.1.368


/124

JMJ

Cisco Catalyst 3550 Series Switches;3550-24Dc;1.3.6.1.4.1.9.1.452 Cisco Catalyst 3550 Series Switches;3550-24Mmf;1.3.6.1.4.1.9.1.453 Cisco Catalyst 3550 Series Switches;3550-24-PWR;1.3.6.1.4.1.9.1.485 Cisco Catalyst 2970 Series Switches;2970-24;1.3.6.1.4.1.9.1.527 Cisco Catalyst 2970 Series Switches;2970G-24TS-E;1.3.6.1.4.1.9.1.561 Cisco Catalyst 2960 Series Switches;2960-24;1.3.6.1.4.1.9.1.694 Cisco Catalyst 2960 Series Switches;2960-48;1.3.6.1.4.1.9.1.695 Cisco Catalyst 2960 Series Switches;2960G-24;1.3.6.1.4.1.9.1.696 Cisco Catalyst 2960 Series Switches;2960G-48;1.3.6.1.4.1.9.1.697 Cisco Catalyst 2960 Series Switches;2960-8TC;1.3.6.1.4.1.9.1.798 Cisco Catalyst 2960 Series Switches;2960G-8TC;1.3.6.1.4.1.9.1.799 Cisco Catalyst 2960 Series Switches;2960-24TT;1.3.6.1.4.1.9.1.716 Cisco Catalyst 2960 Series Switches;2960-48TT;1.3.6.1.4.1.9.1.717 Cisco Catalyst 2955 Series Switches;2955C-12;1.3.6.1.4.1.9.1.489 Cisco Catalyst 2955 Series Switches;2955S-12;1.3.6.1.4.1.9.1.508 Cisco Catalyst 2955 Series Switches;2955T-12;1.3.6.1.4.1.9.1.488 Cisco Catalyst 2950 Series Switches;2950-12;1.3.6.1.4.1.9.1.323 Cisco Catalyst 2950 Series Switches;2950-24;1.3.6.1.4.1.9.1.324 Cisco Catalyst 2950 Series Switches;2950C-24;1.3.6.1.4.1.9.1.325 Cisco Catalyst 2950 Series Switches;2950G-12;1.3.6.1.4.1.9.1.427 Cisco Catalyst 2950 Series Switches;2950G-24;1.3.6.1.4.1.9.1.428 Cisco Catalyst 2950 Series Switches;2950G-48;1.3.6.1.4.1.9.1.429 Cisco Catalyst 2950 Series Switches;2950G-24-DC;1.3.6.1.4.1.9.1.472 Cisco Catalyst 2950 Series Switches;2950S-24;1.3.6.1.4.1.9.1.430 Cisco Catalyst 2950 Series Switches;2950SX-24;1.3.6.1.4.1.9.1.480 Cisco Catalyst 2950 Series Switches;2950SX-48;1.3.6.1.4.1.9.1.560 Cisco Catalyst 2950 Series Switches;2950T-24;1.3.6.1.4.1.9.1.359 Cisco Catalyst 2950 Series Switches;2950T-48;1.3.6.1.4.1.9.1.559 Cisco Catalyst 2950 LRE Series Switches;2950-G-24-LRE;1.3.6.1.4.1.9.1.484 Cisco Catalyst 2950 LRE Series Switches;2950-ST-8-LRE;1.3.6.1.4.1.9.1.483 Cisco Catalyst 2950 LRE Series Switches;2950-ST-24-LRE;1.3.6.1.4.1.9.1.482 Cisco Catalyst 2950 LRE Series Switches;2950-ST-24-LRE-997;1.3.6.1.4.1.9.1.551 Cisco Catalyst 2940 Series Switches;2940-8TF;1.3.6.1.4.1.9.1.542 Cisco Catalyst 2940 Series Switches;2940-8TT;1.3.6.1.4.1.9.1.540 Cisco Catalyst 2900 Series Switches;2948G-L3;1.3.6.1.4.1.9.1.275 Cisco Catalyst 2900 Series Switches;2948G-L3DC;1.3.6.1.4.1.9.1.386 Cisco 500 Series LRE CPE Devices;CS500;1.3.6.1.4.1.9.1.9 Cisco 500 Series Content Engines;CE-510;1.3.6.1.4.1.9.1.505 Supervisor Engine 720;WS-SUP720;1.3.6.1.4.1.9.1.557 Cisco Catalyst 6000 Series Module Switch Feature Card (MSFC);WS-F6K-MSFC2;1.3.6.1.4.1.9.1.301 Cisco Catalyst 6000 Series Module Switch Feature Card (MSFC);WS-F6KMSFC;1.3.6.1.4.1.9.1.258 Cisco 2600 Series Content Engine Module;CE2636;1.3.6.1.4.1.9.1.454 Cisco Unity Express Network Module;NM-CUE;1.3.6.1.4.1.9.1.622 Cisco Unity Express Advanced Integration Module;AIM-CUE;1.3.6.1.4.1.9.1.623 Cisco Aironet Access Point Series;350 IOS;1.3.6.1.4.1.9.1.552 Cisco Aironet Access Point Series;1100;1.3.6.1.4.1.9.1.507 Cisco Aironet Access Point Series;1130;1.3.6.1.4.1.9.1.618 Cisco Aironet Access Point Series;1200;1.3.6.1.4.1.9.1.474 Cisco Aironet Access Point Series;1210;1.3.6.1.4.1.9.1.525 Cisco Aironet Access Point Series;1240;1.3.6.1.4.1.9.1.685 Cisco Wireless LAN Controllers;440x;1.3.6.1.4.1.14179.1.1.4.3 Cisco Wireless LAN Controllers;C2006;1.3.6.1.4.1.14179.1.1.4.2 Cisco Wireless LAN Controllers;2106;1.3.6.1.4.1.9.1.828


/124

JMJ

2 Quelques mesures

2.1 GetMAC

[root@nocu07 bin]# time ./GetMAC.pl -o bash02.mydomain.com Processing VLAN:1; 300; 304; 308; 332; 800; 801; 804; 826; 849; 850; 851; 853; 854; 857; real 0m13.298s user 0m0.952s sys 0m0.155s @Tabl = snmpwalk($community.$SObject,{ "use_getbulk" },$MibifIndex); @Tabl_Desc = snmpwalk($community.$SObject,$MibifDescr); @Tabl = snmpwalk($community.$SObject,$MibPortIfIndex); @Tabl = snmpwalk($community.$SObject,$Mibdot1dBasePortIfIndex); @Tabl = snmpwalk($community.$SObject,$MibPortVLAN); @Tabl = snmpwalk($community.$SObject,$MibVlanTrunkPortDynamicStatus); @Tabl = snmpwalk($community.$SObject,$MibVtpVlanState); @Tabl = snmpwalk($community.$SObject,$MibVlanTrunkPortNativeVlan); @Tabl = snmpwalk($IndexedCS.$SObject,$Mibdot1dTpFdbAddress); @Tabl = snmpwalk($IndexedCS.$SObject,$Mibdot1dTpFdbPort); @Tabl = snmpwalk($IndexedCS.$SObject,$Mibdot1dBasePortIfIndex);

11 SNMPwalk parcourants 8 Tables « simples » + 3 Tables indexées par 14 Vlans = 50 Tables au total

2.1.1 Avec Get Bulk :

[root@nocu07 bin]# time ./GetMAC.pl -o bash02. mydomain.com Processing VLAN:1; 300; 304; 308; 332; 800; 801; 804; 826; 849; 850; 851; 853; 854; 857; real 0m11.488s user 0m0.757s sys 0m0.171s

2.2 CollectObjectInfo.pl

[root@nocu07 bin]# time ./CollectObjectInfo.pl -debug -o mgth03 real 0m0.907s user 0m0.336s sys 0m0.041s @Tab_System = snmpwalk ($community.$Object,$Msystem); $TabChassisModel = snmpget($community.$Object,$CiscoChassisModel); $TabModuleSWVersion = snmpget ($community.$Object,$CiscoImageString); @TabModuleSWVersion = snmpwalk($community.$Object,$CiscoModulSWVersion); $TabChassisSN = snmpget($community.$Object,$CiscoChassisSN); @Tabl_Index = snmpwalk($community.$Object,$MifIndex); @Tabl_Desc = snmpwalk($community.$Object,$MifDescr); @Tabl_Alias = snmpwalk($community.$Object,$MifAlias); @Tabl_VirtualIpAddr = snmpwalk($community.$Object,$CiscoMIbcHsrpGrpVirtualIpAddr); @Tabl_StandbyState = snmpwalk($community.$Object,$CiscoMIbcHsrpGrpStandbyState); @Tabl_AdrIf = snmpwalk($community.$Object,$MipAdEntIfIndex); @Tabl_AdIfStat = snmpwalk($community.$Object,$MifAdStat); @Tabl_OpIfStat = snmpwalk($community.$Object,$MifOpStat); @Tabl_ifName = snmpwalk($community.$Object,$MifName); @Tabl_NetMask = snmpwalk($community.$Object,$MipAdEntNetMask); @Tabl_ifType = snmpwalk($community.$Object,$MifType);

15 Tables lues pour un switch.

Idem sur un routeur


/124

JMJ

3 Obtenir les index SNMP d’un équipement Cisco

basr02#sho snmp mib ifmib ifindex GigabitEthernet1/0/1: Ifindex = 10101 GigabitEthernet1/0/10: Ifindex = 10110 GigabitEthernet1/0/11: Ifindex = 10111 GigabitEthernet1/0/12: Ifindex = 10112 GigabitEthernet1/0/2: Ifindex = 10102 GigabitEthernet1/0/3: Ifindex = 10103 GigabitEthernet1/0/4: Ifindex = 10104 GigabitEthernet1/0/5: Ifindex = 10105 GigabitEthernet1/0/6: Ifindex = 10106 GigabitEthernet1/0/7: Ifindex = 10107 GigabitEthernet1/0/8: Ifindex = 10108 GigabitEthernet1/0/9: Ifindex = 10109 Loopback0: Ifindex = 5049 Null0: Ifindex = 14501 Port-channel1: Ifindex = 5001 Vlan1: Ifindex = 1 Vlan300: Ifindex = 300 Vlan303: Ifindex = 303 Vlan304: Ifindex = 304 Vlan308: Ifindex = 308 Vlan309: Ifindex = 309 Vlan310: Ifindex = 310 Vlan320: Ifindex = 320 Vlan321: Ifindex = 321 Vlan322: Ifindex = 322 Vlan323: Ifindex = 323 Vlan330: Ifindex = 330 Vlan331: Ifindex = 331 Vlan332: Ifindex = 332 Vlan800: Ifindex = 800 Vlan801: Ifindex = 801 Vlan804: Ifindex = 804 Vlan826: Ifindex = 826 Vlan849: Ifindex = 849 Vlan850: Ifindex = 850 Vlan851: Ifindex = 851 Vlan853: Ifindex = 853 Vlan854: Ifindex = 854 Vlan857: Ifindex = 857 basr02#

/124

JMJ

4 GetMAC.pl

#!/usr/bin/PERL $| = 1; use FindBin; use lib "${FindBin::Bin}"; use lib "${FindBin::Bin}/../lib"; use SNMP_util "0.86"; use DBI; use Net::Ping; #--------------------------------------------------------------------------- sub Debug # Print all parameters received for debug purpose { if ($debug) { foreach $para (@_) { print "$para "; #print " "; } # Next param } #No debug => end } #End Sub #--------------------------------------------------------------------------- sub Extract # Divide the line in fields (separed by separator) { # Returns the "offset"th element my ($lin,$separator,$offset) = @_; my (@Fields)=split(/$separator/,$lin); # Split the line by separator chomp($Fields[$offset]); # In case of "\n" return ($Fields[$offset]); } #-------------------------------------------------------------------------------- sub PingTest { my ($target ) = @_; $P = Net::Ping->new(""); if ($P->ping($target,2) ) { $Status = 1; } else { $Status = 0; } $P->close; return ($Status); } #---------------------------------------------------------------------------- sub Logue { $LogDate = `date`; chomp ($LogDate); open (LOGFILE, ">>$LogFile") || warn "could not open logfile $LogFile\n"; flock (LOGFILE, $ExclusiveLock); print LOGFILE "\n$LogDate:"; foreach $para (@_) { print LOGFILE "$para "; } # Next param close (LOGFILE); flock (LOGFILE, $Unlock); } #---------------------------------------------------------------------- sub GetCS { my ($Mode,$Param) = @_; my $WHERE = ""; if ($Mode = 1) { # By FQDN $WHERE = "Òbj_FQDN` =\"$Param\""; } elsif ($Mode = 2) { # By UID $WHERE = "Òbj_UID` =\"$Param\""; } $sth = $dbh -> prepare ( "SELECT Òbj_ComString`

/124

JMJ

FROM Obj WHERE $WHERE " ) or die "cannot prepare SQL statement : $DBI::errstr\n'"; $sth -> execute(); $CS = $sth -> fetchrow_array(); if (length($CS) < 2) { #read default $sth = $dbh -> prepare ( "SELECT `Def_CS` FROM Def " ) or die "cannot prepare SQL statement : $DBI::errstr\n'"; $sth -> execute(); $CS = $sth -> fetchrow_array(); } return($CS); } ################################################################ ## Fills the Jmon_DB MAC Table with the SNMP get MAC Info ## ## CRON Job running once a week over all Locations ## ## Monday or Tuesday or wednesday => based on Loc. Name ## ## JMJ 25/08/2010 ## ## 20-09-2010 : skip APs and 2940 (Cisco ID = 685 and 540) ## ## 19-01-2011 : called when an Update of MAC requested (WEB) ## ## 10-03-2011 : Skip all MAC addresses learned from Up_Links ## ## (Trunk Ports AND Native_Vlan < 2) ## ## ## ## Can be also called from WEB when updating MAC Addresses ## ################################################################ $ThisIs = "GetMAC"; $a = $Mode = 0; $syntax = 0; $Usage = $ThisIs.".pl [-debug] [-h] -o ObjectName || -All || -Loc LocName -i ItfIndex \n"; $Object = $Loc = ""; $ForIndex = 0; # Index 0 never given ( Hope so !) $LogFile = "/opt/Jmon-0.0/Logs/GetMac.log"; $MibifIndex = "1.3.6.1.2.1.2.2.1.1"; $MibifDescr = "1.3.6.1.2.1.2.2.1.2"; $MibifPhysAddr = "1.3.6.1.2.1.2.2.1.6"; $Mibdot1dTpFdbPort = "1.3.6.1.2.1.17.4.3.1.2"; $Mibdot1dBasePortIfIndex = "1.3.6.1.2.1.17.1.4.1.2"; $Mibdot1dTpFdbAddress = "1.3.6.1.2.1.17.4.3.1.1"; $MibPortIfIndex = "1.3.6.1.4.1.9.5.1.4.1.1.11"; $MibPortVLAN = "1.3.6.1.4.1.9.5.1.9.3.1.3"; $MibVtpVlanState = "1.3.6.1.4.1.9.9.46.1.3.1.1.2"; $MibVlanTrunkPortNativeVlan = "1.3.6.1.4.1.9.9.46.1.6.1.1.5"; $MibVlanTrunkPortDynamicStatus = "1.3.6.1.4.1.9.9.46.1.6.1.1.14"; #$MibVmMembershipSummaryMemberPorts = "1.3.6.1.4.1.9.9.68.1.2.1.1.2"; $debug = 0; $ExclusiveLock = 2; $Unlock = 8; foreach $arg (@ARGV) { if ($arg eq "-debug") { $debug = 1; } if ($arg eq "-h") { print $Usage; exit(); } if ($arg eq "-o") { $Object = $ARGV[$a+1] ; $syntax++; $Mode = 1; } if ($arg eq "-All") { $Mode = 2; $syntax++; } if ($arg eq "-i") { $ForIndex = $ARGV[$a+1]; } if ($arg eq "-Loc") { $Loc = "$ARGV[$a+1]" ; $syntax++; $Mode = 3;} $a++; } if ($syntax != 1) {


/124

JMJ

print $Usage; exit (); } Logue (" Entering GetMac.pl $Object / $ForIndex "); Debug ("Connection to Data Bank : "); $dbh = DBI->connect("DBI:mysql:database=JMon_DB;host=localhost","Jnet"); if ($dbh !~/DBI::/) { print "Unable to connect to $DBI::errstr Exiting...\n"; die "cannot connect: $DBI::errstr\n"; } if ($Mode == 1) { $sth = $dbh -> prepare ( "SELECT Òbj_FQDN`, Òbj_MsysObjectID` FROM Obj WHERE Òbj_IsMoni` = \"1\" AND Òbj_IsSNMP` = \"1\" AND Òbj_FQDN` = \"$Object\" " ) or die "cannot prepare SQL statement : $DBI::errstr\n'"; $sth -> execute(); @Value = $sth -> fetchrow_array(); if (length($Value[0]) >4 ) { push (@Table_Objects, $Value[0]); # -o => only one object in Table_Objects } else { print "Unable to find $Object. (FQDN ?): Exiting \n"; exit(); } } elsif ($Mode >= 2) { # -A -> Poll all monitored objects in DB # Skip C-2940 (540) and C-1240 (685) $sth = $dbh -> prepare ( "SELECT Òbj_FQDN` FROM Obj WHERE Òbj_IsMoni` = \"1\" AND Òbj_IsSNMP` = \"1\" AND Òbj_MsysObjectID` NOT LIKE \"%685\" AND Òbj_MsysObjectID` NOT LIKE \"%540\" " ) or die "cannot prepare SQL statement : $DBI::errstr\n'"; $sth -> execute(); while (my (@Value) = $sth -> fetchrow_array() ) { if ($Mode == 3) { next if ($Value[0] !~ /^$Loc/); } push (@Table_Objects,$Value[0]); } $sth -> finish(); } foreach $Object (@Table_Objects) { $ObjectV2 = $Object.":::::2c"; $community = &GetCS(1,$Object); $community = $community."@"; @TabVlan = @Tabl_Desc = (); Debug ("-- Object = $Object -- ForIndex = $ForIndex \n"); $Ping = &PingTest($Object); if (!$Ping) { @Ping = `ping -c 3 $Object`; if ($Ping[-2] =~ /100\% packet loss,/) { # For devices not answering to tcp ping, or behind FW,... print "Obj=$Object;Not pingable;\n"; next; } } # end of if not pingable ####################### Interfaces #################### @Tabl = (); @Tabl = snmpwalk($community.$ObjectV2,$MibifIndex); # Test if Is SNMP


/124

JMJ

if (!defined $Tabl[0] ) { print "Obj=$Object;No SNMP response;\n"; next; } @Tabl_Desc = snmpwalk($community.$ObjectV2,$MibifDescr); %Descr = (); foreach $Line (@Tabl_Desc) { ($T0,$T1) = split (/:/,$Line); $Descr{$T0} = $T1; } ####################### Ports #################### @Tabl = (); @Tabl = snmpwalk($community.$ObjectV2,$MibPortIfIndex); # x.y:z 1.10:10008 Port of Index 1.10 refers interface 10008 if (!defined $Tabl[0] ) { print "Obj=$Object;No SNMP response to Port Queries ($MibPortIfIndex)\n"; # Cisco AP ie # Cisco 4500 and 4948 does not answer to this Query also => try Mibdot1dBasePortIfIndex # Trying Mibdot1dBasePortIfIndex print " Trying $Mibdot1dBasePortIfIndex \n"; @Tabl = snmpwalk($community.$ObjectV2,$Mibdot1dBasePortIfIndex); } %PortIfIndex = (); foreach $Line (@Tabl) { ($T0,$T1) = split (/:/,$Line); $PortIfIndex{$T1} = $T0; # ATTENTION } @Tabl = (); @Tabl = snmpwalk($community.$ObjectV2,$MibPortVLAN); # 1.8 : 1(Trunk) or 1.12:804 %PortVLAN = (); foreach $Line (@Tabl) { ($T0,$T1) = split (/:/,$Line); $PortVLAN{$T0} = $T1; } ############# Trunks ################################# @Tabl = (); @Tabl = snmpwalk($community.$ObjectV2,$MibVlanTrunkPortDynamicStatus); %PortDynamicStatus = (); foreach $Line (@Tabl) { ($T0,$T1) = split (/:/,$Line); $PortDynamicStatus{$T0} = $T1; } ############# MAC Address ############################ ### Get Active VLANS @Tabl = (); @Tabl = snmpwalk($community.$ObjectV2,$MibVtpVlanState); foreach $Line (@Tabl) { ($Vlan,$Status) = split (/:/,$Line); if ($Status) { ($T0,$T1) = split (/\./,$Vlan); push (@TabVlan, $T1) unless ($T1 > 1 # WARNING : vlans greater than 1000 are ignored ! Debug (" Active Vlan:$T1\n"); } } Debug (" List of active VLANs created ;"); @Tabl = (); @Tabl = snmpwalk($community.$ObjectV2,$MibVlanTrunkPortNativeVlan); %NativeVlan=(); foreach $Line (@Tabl) { ($Index,$NatVlan) = split (/:/,$Line); $NativeVlan{$Index} = $NatVlan ; Debug (" Native Vlan of $Index= $NatVlan");


/124

JMJ

} Debug (" List of Native VLANs per port created ;"); Debug ( "\n"); # Problem with HSRP Adresses : Only last Info is recorded as the key is the MAC Address @TabHexMac = %MACPort = %MACIndex = %NbMAC = %Interface = %DejaVuMac = %MACVlan = (); ## Not Only the MAC address is used as key but the MAC Address AND the VLAN print " Processing VLAN:"; foreach $Vlan (@TabVlan) { # Read the MAC address per VLAN ############################## print "$Vlan; "; $IndexedCS = $community."$Vlan\@"; @Tabl = (); @Tabl = snmpwalk($IndexedCS.$ObjectV2,$Mibdot1dTpFdbAddress); # Decimal:Hexa foreach $Line (@Tabl) { # 0.208.4.226.180.10:�É�� # All mib variables are indexed by Decimal ($DeciMAC,$HexMAC) = split (/:/, $Line, 2); $UMac = $UMac1 = $HEXMAC = ""; @Table1 = (); $UMac = unpack 'H*', $HexMAC; @Table1 = $UMac =~ /../g; $UMac1 = join (':', @Table1); $HEXMAC = uc($UMac1); $HEXMAC =~ s/^/$Vlan@ # HEXMAC : Vlan @ Human Readable Mac_Address in Hex Format $DECIMAC{$HEXMAC} = $Vlan."@".$DeciMAC; # Vlan @ 0.208.4.226.180.10 push (@TabHexMac, $HEXMAC); } @Tabl = (); @Tabl = snmpwalk($IndexedCS.$ObjectV2,$Mibdot1dTpFdbPort); # Decimal:port foreach $Line (@Tabl) { ($T0,$T1) = split (/:/, $Line); $T0 = $Vlan."@".$T0; $MACPort{$T0} = $T1; } @Tabl = (); @Tabl = snmpwalk($IndexedCS.$ObjectV2,$Mibdot1dBasePortIfIndex); # MACIndex : IfIndex foreach $Line (@Tabl) { # MACIndex(MAC local Port) = MIB II Index ($T0,$T1) = split (/:/, $Line); $MACIndex{$T0} = $T1; } } # All Vlans done ## ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ # Set all existing MAC Addresses of this object to Not_Valid for all or only requested interface $WHEREQuery = "`Mac_IsPartOf` = '$Object'"; if ($ForIndex != 0) { $WHEREQuery = $WHEREQuery." AND `Mac_MifIndex` = '$ForIndex' "; } $sth = $dbh -> prepare ( " UPDATE `Mac` SET `Mac_IsValid` = '0' WHERE $WHEREQuery " ) or die "cannot prepare SQL statement : $DBI::errstr\n'"; $sth -> execute(); $NbRows = $sth -> rows;

/124

JMJ

$sth -> finish(); Debug ( "\n$NbRows MAC Addresses invalidated for $Object ($WHEREQuery)\n"); $DBDate =`date +%F%t%T`; # For Jmon chomp $DBDate; $UTime = time(); ## +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ foreach $HexAdd (@TabHexMac) { # VLAN @ Hex MAC $DecAdd = $DECIMAC{$HexAdd}; # VLAN @ Deci MAC $DBIndex = $MACIndex{$MACPort{$DecAdd}}; $DBNatVlan = $NativeVlan{$DBIndex}; if ( ($DBNatVlan < 2) && ($PortDynamicStatus{$DBIndex} == 1) ) { # MAC Addresses learned on Up-Link ( Native Vlan == 1 AND Port is Trunk) ## This skips also Ports in Trunk Modus on VMWare Machines as no Native Vlan is not defined. Debug (" Skipping $DecAdd / $DBIndex => Native Vlan = 1 ($Descr{$DBIndex}) \n"); next; } if (!defined ($MACIndex{$MACPort{$DecAdd}}) ) { # Some MAC address are not Indexed ( HSRP,...) Debug (" Skipping $DecAdd / $DBIndex => Object's own MAC Address \n"); $DBIndex = 0; next; # Skip Own MAC Addresses ( Port Index = 0) } if ( ($ForIndex != 0) && ($DBIndex != $ForIndex) ) { # Skip if not relevant to requested Index next; } ($DBVlan, $DBHexAdd) = split (/@/, $HexAdd); $DBDescr = $Descr{$DBIndex}; ################ Work with DB ############### # Does this MAC_Address already exist in DB for the same Object and same Vlan and same Interface ? $sth = $dbh -> prepare ( " SELECT `Mac_uid`, `Mac_IsPartOf`, `Mac_Vlan`, `Mac_MifIndex` FROM Mac WHERE `Mac_Addr` = \"$DBHexAdd\" AND `Mac_Vlan` = $DBVlan AND `Mac_MifIndex` = $DBIndex AND `Mac_IsPartOf` = \"$Object\" " ) or die "cannot prepare SQL statement : $DBI::errstr\n'"; $sth -> execute(); $NbRows = $sth -> rows; ($InDB_Uid, $InDB_IsPartOf, $InDB_Vlan, $InDB_MifIndex) = $sth -> fetchrow_array(); $sth -> finish(); ## ----------------------------------------------------------------------------- if ($NbRows == 0) { Debug( "Inserting New MAC Address $DBHexAdd for $Object : Index $DBIndex\t: VLAN $DBVlan ; NativeVlan : $DBNatVlan ; Desc :$DBDescr\t; $DBDate ; $UTime \n"); Logue( "$Object /$DBIndex\t: Insert. $DBHexAdd: VLAN $DBVlan ; NativeVlan : $DBNatVlan ; Desc :$DBDescr\t; $DBDate ; $UTime "); $sth1 = $dbh -> prepare ( " INSERT INTO `Mac` (`Mac_uid`, `Mac_Addr`, `Mac_IsPartOf`, `Mac_Vlan`, `Mac_MifIndex`, `Mac_MifDescr`, `Mac_IsValid`, `Mac_FirstSeen`, `Mac_FirstSeenU`, `Mac_LastSeen`, `Mac_LastSeenU`, `Mac_NativeVlan` ) VALUES ('', '$DBHexAdd', '$Object', '$DBVlan', '$DBIndex', '$DBDescr', '1',


/124

JMJ

'$DBDate', '$UTime', '$DBDate', '$UTime', '$DBNatVlan' ) " ) or die "cannot prepare SQL statement : $DBI::errstr\n"; $sth1 -> execute(); print "$DBI::errstr"; $sth1 -> finish(); ## ----------------------------------------------------------------------------- } else { Debug(" MAC Address already in DB ($InDB_Uid) "); # Update Date and IsValid Flag $sth1 = $dbh -> prepare ( " UPDATE `Mac` SET `Mac_IsValid` = '1', `Mac_LastSeen` = '$DBDate', `Mac_LastSeenU` = '$UTime' WHERE `Mac_uid` = '$InDB_Uid' " ) or die "cannot prepare SQL statement : $DBI::errstr\n'"; $sth1 -> execute(); $NbRows = $sth -> rows; Debug ( "Validating MAC Addresses $DBHexAdd for $InDB_IsPartOf, $InDB_Vlan, $InDB_MifIndex \n"); Logue ( " - Validating MAC Addresses $DBHexAdd for $InDB_IsPartOf, $InDB_Vlan, $InDB_MifIndex \n"); $sth1 -> finish(); } # End of Else MAC_Address exist in DB } # End of foreach $HexAdd (@TabHexMac) { # Hex MAC } # All Objects done


/124

JMJ

5 GetVTP.pl

#!/usr/bin/PERL $| = 1; use FindBin; use lib "${FindBin::Bin}"; use lib "${FindBin::Bin}/../lib"; use lib "/opt/Jnet-2.0/lib"; #use MRTG_lib "2.090017"; #use SNMP_Session "0.86"; #use BER "0.86"; use SNMP_util "0.86"; use DBI; use Net::Ping; #------------------------------------------------------------------------ sub Debug # Print all parameters received for debug purpose { if ($debug) { foreach $para (@_) { print "$para "; } # Next param } #No debug => end } #End Sub #------------------------------------------------------------------------ sub Extract # Divide the line in fields (separed by separator) { # Returns the "offset"th element my ($lin,$separator,$offset) = @_; my (@Fields)=split(/$separator/,$lin); # Split the line by separator chomp($Fields[$offset]); # In case of "\n" return ($Fields[$offset]); } #-------------------------------------------------------------------------- sub PingTest { my ($target ) = @_; $P = Net::Ping->new(""); if ($P->ping($target,2) ) { $Status = 1; } else { $Status = 0; } $P->close; return ($Status); } #-------------------------------------------------------------------- sub Logue { $LogDate = `date`; chomp ($LogDate); open (LOGFILE, ">>$GetMacLog") || warn "could not open logfile $InformLog\n"; flock (LOGFILE, $ExclusiveLock); print LOGFILE "\n$LogDate:"; foreach $para (@_) { print LOGFILE "$para "; } # Next param flock (LOGFILE, $Unlock); } #---------------------------------------------------------------------- sub GetCS { my ($Mode,$Param) = @_; my $WHERE = ""; if ($Mode = 1) { # By FQDN $WHERE = "`Obj_FQDN` =\"$Param\""; } elsif ($Mode = 2) { # By UID $WHERE = "`Obj_UID` =\"$Param\"";

/124

JMJ

} $sth = $dbh -> prepare ( "SELECT `Obj_ComString` FROM Obj WHERE $WHERE " ) or die "cannot prepare SQL statement : $DBI::errstr\n'"; $sth -> execute(); $CS = $sth -> fetchrow_array(); if (length($CS) < 2) { #read default $sth = $dbh -> prepare ( "SELECT `Def_CS` FROM Def " ) or die "cannot prepare SQL statement : $DBI::errstr\n'"; $sth -> execute(); $CS = $sth -> fetchrow_array(); } return($CS); } #---------------------------------------------------------------------- ################################################################ ## Finds out via SNMP which Vlans are enabled on a port : ## ## Finds out via SNMP the Vlan allowed statement ## ## Only vlans < 1024 are considered (1k OID) ## ## Only TRUNK ports are analysed ( uses VTP MIB Info) => ## ## Ports in "mode Access" are nor displayed ## ## JMJ 20/09/2010 ## ################################################################ $ThisIs = "GetVTP"; $a = $Mode = 0; $syntax = 0; $Usage = $ThisIs.".pl [-debug] [-h] -o ObjectName -i ItfIndex -All \n"; $Object = ""; $ForIndex = 0; # Index 0 never given ( Hope so !) $MibifIndex = "1.3.6.1.2.1.2.2.1.1"; $MibifDescr = "1.3.6.1.2.1.2.2.1.2"; $MibifPhysAddr = "1.3.6.1.2.1.2.2.1.6"; $Mibdot1dTpFdbPort = "1.3.6.1.2.1.17.4.3.1.2"; $Mibdot1dBasePortIfIndex = "1.3.6.1.2.1.17.1.4.1.2"; $Mibdot1dTpFdbAddress = "1.3.6.1.2.1.17.4.3.1.1"; $MibPort = "1.3.6.1.4.1.9.5.1.9.3.1.2"; $MibPortVLAN = "1.3.6.1.4.1.9.5.1.9.3.1.3"; $MibPortIfIndex = "1.3.6.1.4.1.9.5.1.4.1.1.11"; $MibVlanPortIslOperStatus = ".1.3.6.1.4.1.9.5.1.9.3.1.8" ; $MibVtpVlanState = "1.3.6.1.4.1.9.9.46.1.3.1.1.2"; $MibVlanTrunkPortNativeVlan = "1.3.6.1.4.1.9.9.46.1.6.1.1.5"; $MibVtpvlanTrunkPortVlansEnabled = "1.3.6.1.4.1.9.9.46.1.6.1.1.4"; $MibVtpvlanTrunkPortDynamicState = "1.3.6.1.4.1.9.9.46.1.6.1.1.13"; $MibVtpvlanTrunkPortDynamicStatus = "1.3.6.1.4.1.9.9.46.1.6.1.1.14"; #$MibVmMembershipSummaryMemberPorts = "1.3.6.1.4.1.9.9.68.1.2.1.1.2"; $MibVlanPortIslOperStatus = ".1.3.6.1.4.1.9.5.1.9.3.1.8" ; @TabConvDecHex = qw(0 1 2 3 4 5 6 7 8 9 A B C D E F); $debug = 0; $ExclusiveLock = 2; $Unlock = 8; foreach $arg (@ARGV) { if ($arg eq "-debug") { $debug = 1; } if ($arg eq "-h") { print $Usage; exit(); } if ($arg eq "-o") { $Object = $ARGV[$a+1] ; $syntax++; $Mode = 1; } if ($arg eq "-All") { $Mode = 2; $syntax++; } if ($arg eq "-i") { $ForIndex = $ARGV[$a+1]; } $a++; }


/124

JMJ

if ($syntax != 1) { print $Usage; exit (); } Debug ("Connection to Data Bank : "); $dbh = DBI->connect("DBI:mysql:database=JMon_DB;host=localhost","Jnet"); if ($dbh !~/DBI::/) { print "Unable to connect to $DBI::errstr Exiting...\n"; die "cannot connect: $DBI::errstr\n"; } if ($Mode == 1) { # OBJECT $sth = $dbh -> prepare ( "SELECT Òbj_FQDN`, Òbj_MsysObjectID` FROM Obj WHERE Òbj_IsMoni` = \"1\" AND Òbj_IsSNMP` = \"1\" AND Òbj_FQDN` = \"$Object\" " ) or die "cannot prepare SQL statement : $DBI::errstr\n'"; $sth -> execute(); @Value = $sth -> fetchrow_array(); if (length($Value[0]) >4 ) { push (@Table_Objects, $Value[0]); # -o => only one object in Table_Objects } else { print "Unable to find $Object. (FQDN ?): Exiting \n"; exit(); } } elsif ($Mode >= 2) { # -A -> Poll all monitored objects in DB $sth = $dbh -> prepare ( "SELECT Òbj_FQDN` FROM Obj WHERE Òbj_IsMoni` = \"1\" AND Òbj_IsSNMP` = \"1\" AND Òbj_MsysObjectID` NOT LIKE \"%685\" AND Òbj_MsysObjectID` NOT LIKE \"%540\" " ) or die "cannot prepare SQL statement : $DBI::errstr\n'"; $sth -> execute(); while (my (@Value) = $sth -> fetchrow_array() ) { push (@Table_Objects,$Value[0]); } $sth -> finish(); } foreach $Object (@Table_Objects) { next if ($Object =~ /^...r101*/); next if ($Object =~ /^...r102*/); $community = &GetCS(1,$Object); $community = $community."@"; @Tabl_Index = @Tabl_PortIfIndex = @Tabl_PortVLAN = @Tabl_ActiveVlans = @Tabl_NativeVLAN = @Tabl_VlansEnabled = (); Debug ("-- Object = $Object -- ForIndex = $ForIndex \n"); $Ping = &PingTest($Object); if (!$Ping) { # &NotReachableObj($Object) ; print "Obj=$Object;Not pingable;\n"; next; } # end of if not pingable @Tabl_Index = (); %Vlans = (); $ObjectV2 = $Object.":::::2"; ####################### Interfaces #################### @Tabl_Index = snmpwalk($community.$ObjectV2,$MibifIndex); # Test if Is SNMP if (!defined $Tabl_Index[0] ) { print "Obj=$Object;No SNMP response;\n"; next;


/124

JMJ

} @Tabl_Desc = snmpwalk($community.$ObjectV2,$MibifDescr); %Descr = (); foreach $Line (@Tabl_Desc) { ($T0,$T1) = split (/:/,$Line); $Descr{$T0} = $T1; } ####################### Ports #################### @Tabl_PortIfIndex = snmpwalk($community.$ObjectV2,$MibPortIfIndex); # x.y:z 1.10:10008 Port of Index 1.10 refers interface 10008 if (!defined $Tabl_PortIfIndex[0] ) { print "Obj=$Object;No SNMP response to Port Queries ($MibPortIfIndex) => trying $Mibdot1dBasePortIfIndex\n"; # Cisco AP ie # Cisco 4500 and 4948 does not answer to this Query also => try Mibdot1dBasePortIfIndex # Trying Mibdot1dBasePortIfIndex @Tabl_PortIfIndex = snmpwalk($community.$ObjectV2,$Mibdot1dBasePortIfIndex); } %PortIfIndex = (); foreach $Line (@Tabl_PortIfIndex) { ($T0,$T1) = split (/:/,$Line); #$PortIfIndex{$T1} = $T0; # ATTENTION $PortToIndex{$T0} = $T1; } @Tabl_PortVLAN = snmpwalk($community.$ObjectV2,$MibPortVLAN); %PortVLAN = (); %IsAccess = (); foreach $Line (@Tabl_PortVLAN) { ($T0,$T1) = split (/:/,$Line); $PortVLAN{$T0} = $T1; if ($T1 >1) { # We assume that >1 is a VLAN $IsAccess{$PortToIndex{$T0}} = 1; } } ############# Native Vlan ############################ @Tabl_NativeVLAN = snmpwalk($community.$ObjectV2,$MibVlanTrunkPortNativeVlan); %NativeVlan=(); foreach $Line (@Tabl_NativeVLAN) { ($Index,$NatVlan) = split (/:/,$Line); $NativeVlan{$Index} = $NatVlan ; } Debug ( "\n"); ### Get Ports configured as Trunk ################ @Tabl_TrunkPortIndex = snmpwalk($community.$ObjectV2,$MibVtpvlanTrunkPortDynamicStatus); %IsTrunk = (); foreach $Line (@Tabl_TrunkPortIndex) { ($T0,$T1) = split (/:/,$Line); $IsTrunk{$T0} = $T1 ; # 1 = Trunking, 2 = not Trunking } ### Get Enabled Vlans ############################ @Tabl_VlansEnabled = snmpwalk($community.$ObjectV2,$MibVtpvlanTrunkPortVlansEnabled); foreach $Line (@Tabl_VlansEnabled) { ($Index,$str) = split (/:/,$Line); $bits = unpack 'B*', $str ; my @ones_offsets; push @ones_offsets, $-[1] while $bits =~ m{(1)}xmsg; $NbVlans = @ones_offsets; print "No one bits found" unless @ones_offsets; print "$Object $Descr{$Index} (Is Trunk : $IsTrunk{$Index} Native Vlan = $NativeVlan{$Index}): the allowed vlans are : "; if ($NbVlans == 1023) {


/125

JMJ

print "All VLANS allowed on Interface $Descr{$Index} (No Vlan allowed statement)"; } else { #print "1 bit at offset $_ \n" for @ones_offsets; foreach $BitOffset (@ones_offsets) { print "$BitOffset "; } } print "\n"; } } # All Objects done


/126

JMJ

JMJ La supervision de réseau par SNMP · JMJ Reference SNMP_Mon Page 3/124 JMJ Historique du...

Documents

Transcript of JMJ La supervision de réseau par SNMP · JMJ Reference SNMP_Mon Page 3/124 JMJ Historique du...