The Simple Network Managment Protocol (SNMP)

(1)

26/01/2002 − v1.0 [email protected] 1

The Simple Network

Managment Protocol (SNMP)

Nicolas Sayer

Plan

1: Introduction;

2: SMI, MIB and OIDs;

3: Commandes SNMP;

4: Exemples d’agents et de requêtes;

5: Plus de SNMP.

(3)

1: Introduction

(4)

Définition (général)

Les systèmes de gestion de réseau (Network Managment Systems (NMS)) possèdent deux éléments de bases:

Des "Manager" qui permettent aux gestionnaires du réseau de contrôler ce dernier et réaliser des

actions sur ce réseau;

Des "Agents" qui sont l’interface entre les objets des périphériques gérés et le Manager.

SNMP permet aux "Managers" de

communiquer aux "Agents" en leurs donnant

accès à ces objets.

(5)

Définition (SNMP)

SNMP est un protocole permettant de gérer les éléments d’un réseau IP;

SNMP existe sur beaucoup de types de périphériques différents (routeurs, switchs, rack de modems, imprimante, PC, UPS)...

SNMP permet de vérifier l’état de ces périphériques IP, mais il peut aussi permettre de suivre leur utilisation dans le temps et observer l’état général de santé de son réseau (@large).

SNMP offre la possibilité d’observer des données assez standard comme le trafic réseau passant à travers un routeur, l’état de ces interfaces; mais il peut être étendu pour transmettre des valeurs plus spécifique au matériel utilisé: la température d’un switch; la quantité de café disponible dans la machine...

(6)

Grace à SNMP

Monitor: Suivre l’état de son réseau dans le temps;

Control: Être alerté des pannes et défauts apparut dans le réseau;

Manage (gérer): Modifier des paramètres

de fonctionnement du réseau, de façon

manuelle ou automatique.

(7)

Histoire

SGMP (Simple Gateway Monitoring Protocol), crée durant le développement de SNMP par le Networking Group de l’IETF;

SNMP arrive en 1988; annoncé comme

le standard pour gérer des périphériques

IP.

(8)

SNMP versions

SNMPv1: RFC 1157 (1990) standard:

Sécurité basée sur les communautées (texte en claire);

SNMPv2c: RFC 1905, RFC 1906, RFC 1907 (1996) experimental

SNMPv3: RFC 1905 à 1907 et RFC 2571 à 2575 (1999) proposed

Authentification forte, utilisation de clefs,

bulkget, acquittement des traps.

(9)

Protocole SNMP

SNMP utilise un protocole de communication ultra−simplifié:

port 161/UDP (trap: 162/UDP);

Détection des pannes assurées par des timeout (temps max. sans réponse);

L’agent ne conserve aucun état (stateless), n’utilise pas de mémoire de stockage.

L’intelligence réside dans le NMS et le

protocole.

(10)

Architecture

Network Managment System Network Managment System

Network

SNMP MIB

Agent Device

SNMP MIB

Agent Device SNMP MIB

Agent Device

(11)

Architecture (détail)

Network Managment System

SNMP MIB

Agent Device

R e q u ê t e ( g e t ) Réponse Alerte (trap)

(12)

Agent

Accède aux données de management, comme défini dans la MIB, en lecture et en écriture;

Peut envoyer un événement au "manager" de façon asynchrone (trap);

Peut être un proxy pour un élément du réseau n’implantant pas SNMP;

Implante l’intégralité du protocole SNMP;

L’agent peut être un logiciel comme un daemon ou service sous NT. Il peut aussi faire partie intégrante d’un OS (Cisco IOS) voir même être implanté directement au niveau matériel (HP gCard);

L’agent est très simple à implanter (c’est le Simple de SNMP). Il est stateless, ne stock aucune donnée.

(13)

Le Manager

Généralement implanté comme station de management réseau (NMS);

Peut:

Faire des requêtes aux agents;

Recevoir les réponses des agents;

Modifier des valeurs dans les agents;

Recevoir des événements asynchrones des agents (trap).

Généralement le NMS déclenche des alertes en fonction des réponses obtenues (alarme sonore et visuel, pager, SMS...)

Quelques NMS connus:

− Hewlett Packard: OpenView ;

− IBM NetView/6000 ;

− SunConnect SunNet Manager ;

− Spectrum (??? find from who).

NMS non−SNMP (mais qui possèdent généralement des modules pour l’implanter):

− BMC: Patrol ;

− BigBrother.

(14)

RMON (Remote Monitoring)

RMON est un ajout dans la MIB−II de SNMP;

Il permet de collecter de façon central des informations sur l’état d’un réseau (Ethernet), sa charge et l’évolution de son utilisation;

RMON n’est PAS un protocole ! C’est

une MIB !

(15)

2: SMI, MIB et OID

(16)

MIB (généralités)

Les MIB (Management Information Database) définissent les objets pour lesquels ils connaissent une valeur ; L’agent et le NMS doivent posséder une copie de la MIB ; Les MIB ont un format standard: Structure of Management Information (SMI) (RFC1065) donnant pour chaque objet:

Pour chaque objets sont définis:

Un nom (HR): "sysContact", un identifiant numérique (4);

Une syntaxe: entier, string...

Un type d’accès: read−only/read−write ; Une description: "Cet objet sert à cela".

Il faut voir une MIB comme une base de donnée stockant une liste d’objets et leurs définitions. Le format de la SMI peut paraître un peu complexe à première vu, mais il est extrêmement claire et extensible. Ce format n’est pas spécifique aux MIB de SNMP.

La RFC SNMP spécifie que l’agent, comme le client doivent posséder une copie de la MIB. Ceci n’est pas entièrement vrai. La majorité des clients étant capable de faire des requêtes SNMP seront capable de faire une requête en utilisant uniquement l’identifiant numérique. Cependant l’agent, lui, doit obligatoirement avoir une table, il serait incapable de savoir quel valeur utiliser et avec quel "type"

la formater.

(17)

MIB (II)

La MIB−II (RFC1213) défini un certain nombre d’objets de base devant être supporté par tout agent SNMP.

Exemple: Nom de l’administrateur, localisation, liste des interfaces réseau, vitesse, octets transmit...

Il existe d’autres MIB standard pour des besoins plus spécifiques: ATM MIB (RFC2515), BGB4 MIB

(RFC1657), Mail Monitoring MIB (RFC2249), DNS Server MIB (1611)...

Les constructeurs ont la liberté de créer leurs propres MIBs selon leurs besoins spécifiques (températures, ACL...). Elles apparaissent dans l’arborescence

"private").

S’il y a une MIB−II, il existait évidement une MIB−I, mais celle−ci à été remplacée durant les premiers âges de SNMP.

La MIB−II doit OBLIGATOIREMENT être supporté par tout agent SNMP. Elle défini des éléments génériques comme la localisation de l’équipement, le nom de la personne à contacter pour l’administration. Elle défini toute les informations réseau de base. S’il y a SNMP, il y a au moins une interface réseau sachant transmettre des informations.

Comme les mondes du réseau et du système sont de plus en plus liés; il existe une MIB spécifique aux systèmes d’exploitation (Host Resources MIB (RFC2790)).

Celle−ci gère un certains nombres d’objets génériques au différents systèmes

(18)

Structure de l’arborescence SMI

root (.) iso(1)

ccitt(0) joint(2)

org (3) dod(6) internet(1)

directory(1) mgmt(2) experimental(3) private(4) enterprises(1) mib−2(1)

cisco(9) system(1) interfaces(2)

sysDescr(1) sysContact(4) .1.3.6.1.4.1.9.

.1.3.6.1.2.1.1.4.0

L’arbre "enterprises" contient une liste de constructeurs sous laquelle, chacun de ces constructeurs pourront définir leur propre MIB. La liste de correspondance OID <−> Constructeur est maintenu par l’IANA (

ftp://ftp.isi.edu/in−notes/iana/assignements/enterprise−numbers). N’importe qui à le droit de demander d’être identifier sous l’arborescence "enterprises" à partir du moment où ils ont réalisés un développement SNMP notable.

(19)

Syntaxe des Object IDentifiers (OID)

INTEGER: un nombre 32bits. Souvent utilisé pour donner un état. Par exemple l’état de l’interface d’un routeur: 1=up, 2=down, 3=testing. 0 n’est

généralement pas utilisé;

OCTET STRING: Une suite de 0 ou + d’octets: (texte, adresse MAC);

COUNTER: nombre 32bits, ne peut q’être incrémenté, repasse à zéro quand il dépasse (2³²−1);

OBJECT IDENTIFIER: un autre objet;

IpAddress;

Il n’existe pas dans la MIB−II de champs d’adresse IP spécifique à IPv6. Le groupe de travail SMING de l’IETF travail sur ce sujet.

Il faut bien faire la différence entre le fonctionnement des variables GAUGE, COUNTER, etc... Celle−ci seront très visibles lors de l’utilisation de ces variables dans un NMS ou un logiciel de Graph comme MRTG ou Cricket.

(20)

Syntaxe des Object IDentifiers (OID) (2)

Gauge: nombre de 32bits. Possède une valeur min. et max. (vitesse d’un port ethernet);

TimeTicks: nombre sur 32bits, mesure le temps en centièmes de secondes (uptime);

DISPLAY STRING: Chaîne de caractères (max. 255).

Counter64: Comme un compteur 32, sauf qu’il est sur 64bits;

Il en existe beaucoup d’autres... Bon nombres de nouveaux ont été ajoutés dans la v2 de SMI.

(21)

Groupes d’arbres définis dans la MIB−II (RFC1213)

(1.3.6.1.2.1)

system: Défini des objets donnant des indications sur le système: UpTime, Description, Fonction, Contact system...

interfaces: Donne des informations sur les interfaces réseau du système: état, trafic, erreurs...

at: Translation d’adresse (legacy);

ip: Information sur la pile IP, en l’occurrence le routage;

icmp;

tcp: État des connexions TCP (closed, listen, synSent...);

Il en existe quelques autres, mais généralement peu utilisés.

(22)

Groupes d’arbres définis dans la MIB−II (RFC1213)

(1.3.6.1.2.1)

udp: Statistiques UDP (datagram envoyés, reçus...);

egp: État de l’EGP (Exterior Gateway Protocol);

snmp: Informations sur l’état et le

fonctionnement de l’agent SNMP du

système.

(23)

Les indexes

Les objets simples ont toujours un index fixé à .0

On utilise les indexes quand il y a plusieurs instances du même type de périphérique (plusieurs cartes réseaux, par exemple):

interfaces.ifTable.ifEntry.ifDescr.1 = lo0 interfaces.ifTable.ifEntry.ifDescr.2 = eth0

Il existe toujours une variable donnant le nombres d’éléments dans l’index:

interfaces.ifNumber.0 = 2

L’utilisation des indexes peut devenir compliqué quand on possède un grand nombre de ports sur un switch par exemple. Certains constructeurs font attention à utiliser des indexes linéaires: 1,2,3,4,5... au détriment d’une certaine logique dans la numérotation des ports. D’autres utilisent le même numéro pour l’indexe et le port, mais dans ce cas les indexes ne sont plus linéaires...: 1,4,24,532...

(24)

Les indexes (2)

Si l’incrément des indexes n’est pas linéaire, il doit exister une table linéaire, pointant sur chaque éléments de la table non−linéaire:

.ifNumber.0 = 2 .ifIndex.1 = 3 .ifIndex.2 = 47

.ifTable.ifEntry.ifDescr.3 = eth3 .ifTable.ifEntry.ifDescr.47 = ge47

(25)

3: Commandes SNMP

(26)

Types de commandes

Il existe trois types de commandes en SNMP, certains types possèdent des sous−variantes:

GET: Le manager émet une requête vers le client pour interroger une variable, celui−ci renvoi une réponse à cette commande;

GET−NEXT: Comme GET, sauf que l’agent répond avec l’OID suivant dans l’arbre. Permet de "Walker" la MIB.

GET−BULK (v2): Permet de faire de requête sur des

"branches" complètes de l’arbre.

SET: Le manager émet une requête de modification sur un élément, l’agent répond par un ACK.

TRAPs: L’agent émet spontanément une information à destination d’un NMS.

(27)

GET

Le NMS envoi une requête GET avec un OID à l’agent:

GET gw.inria.fr public .1.3.6.1.2.1.1.6.0

L’agent répond avec un GET−RESPONSE, avec la valeur correspondant à l’OID demandé.

system.sysLocation.0 =

"INRIA Rocquencourt / Bat 7/25"

SNMP MIB

Agent Device

R e q u ê t e ( g e t ) Get−Réponse

(28)

GET−NEXT

Le NMS envoi une requête GET avec un OID à l’agent:

GET−NEXT gw.inria.fr public

system.sysContact.0

L’agent répond avec un GET−RESPONSE, avec la valeur correspondant à l’OID placé APRÈS l’OID demandé.

system.sysName.0 =

"gw.inria.fr"

SNMP MIB

Agent Device

R e q u ê t e (

g e t ) Get−Réponse

C’est le GET−NEXT qui est utilisé pour "Walker" la MIB. L’agent ne conservant aucun historique des requêtes reçus, il est incapable de savoir ce que le NMS à demandé plus tôt.

(29)

SET

Le NMS envoi une requête SET avec un OID à l’agent:

SET gw.inria.fr private

system.sysContact.0 s

"Nicolas"

L’agent répond avec un GET−RESPONSE, avec un code de retour

(OK/KO).

SNMP MIB

Agent Device

R e q u ê t e ( s e t ) getResponse

(30)

TRAP

L’agent envoie une exception (trap) avec un TrapID et un OID:

0−coldStart, 1−

warmStart, 2−

linkDown, 3−linkUp...

En SNMPv2 et v3, le NMS peut acquitter les traps.

SNMP MIB

Agent Device

Trap

En SNMP, il y a deux moyens de savoir si quelque chose ne fonctionne plus:

− En faisant des GET régulier sur l’information en question (pooling), ceci engendre de la charge inutile, et ne permet pas d’avoir l’information immédiatement;

− En utilisant les TRAPS, beaucoup plus joli, cependant les TRAPS sont des événements asynchrones et ne sont pas acquittés!

(31)

Les Communautés (SNMPv1)

Il existe deux types de communautés:

read−only: public

read−write: private

L’authentification en SNMPv1 fonctionne grâce à ces communautés;

La communauté (rw) est la première chose à changer!

Il existe d’autres mécanismes de sécurités:

ACLs, communautés multiples, clefs (v3)...

(32)

Nouveaux PDU (Protocol Data Units) v2 et v3

Notification: Standardise les TRAP pour avoir un format cohérent avec les GET et SET;

Inform: Mécanisme de communication NMS à NMS;]

Report (unused): permet aux NMS

d’informer d’autres NMS de problemes

de communication SNMP.

(33)

4: Implantations SNMP

4.1: Des Agents

(34)

Cisco’s IOS (agent)

snmp−server engineID local 000000012345678901234567 snmp−server community public lecture 1300

snmp−server community private ecriture 1300 snmp−server location Salle Machine

snmp−server host 128.93.23.181

(35)

Net−SNMP SNMPd (Agent)

# Standard

syslocation INRIA/Rocq Bat. 25

syscontact Nicolas Sayer <[email protected]>

# Propritaire NET−SNMP (NET−SNMP−MIB) proc snmpd

exec echotest /bin/echo hello world disk / 10000

disk /dev disk /usr disk /u1

load 12 14 14

(36)

4.2: Exemples de requêtes

(Net−SNMP)

(37)

snmpget

[nick]$ snmpget xxx.xxx.xxx.xxx public system.sysDescr.0

system.sysDescr.0 = Linux xxxx.inria.fr 2.4.6_1.4_VTHD #1 SMP Mon Jul 16 11:53:55 CEST 2001 i686

[nick]$ snmpget −On xxx.xxx.xxx.xxx public system.sysContact.0 .1.3.6.1.2.1.1.4.0 = "Nicolas Sayer <[email protected]>"

[nick]$ snmpget xxx.xxx.xxx.xxx public interfaces.ifNumber.0 interfaces.ifNumber.0 = 2

[nick@]$ snmpget xxx.xxx.xxx.xxx public interfaces.ifTable.ifEntry.ifDescr.2 interfaces.ifTable.ifEntry.ifDescr.2 = eth0

[nick]$ snmpget xxx.xxx.xxx.xxx public interfaces.ifTable.ifEntry.ifInOctets.2

interfaces.ifTable.ifEntry.ifInOctets.2 = Counter32: 2210757931

(38)

snmpwalk (1) (Net−SNMP)

[nick]$ snmpwalk localhost system

system.sysDescr.0 = Linux xxxxx.inria.fr 2.4.6_1.4_VTHD #1 SMP Mon Jul 16 11:53:55 CEST 2001 i686

system.sysObjectID.0 = OID:

enterprises.ucdavis.ucdSnmpAgent.linux

system.sysUpTime.0 = Timeticks: (201463445) 23 days, 7:37:14.45

system.sysContact.0 = "Nicolas Sayer"

system.sysName.0 = rocq−vthd−demof.inria.fr system.sysLocation.0 = "Bat 7 VTHD"

system.sysORLastChange.0 = Timeticks: (0) 0:00:00.00 (...)

(39)

snmpwalk (2) −> Cisco Cat6.5K

[nick]$ snmpwalk gateway public | less

system.sysDescr.0 = Cisco Internetwork Operating System Software

IOS (tm) MSFC Software (C6MSFC−IS−M), Version 12.0(7)XE1, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

TAC:Home:SW:IOS:Specials for info

Compiled Fri 04−Feb−00 00:

system.sysObjectID.0 = OID: enterprises.9.1.258

system.sysUpTime.0 = Timeticks: (52728446) 6 days, 2:28:04.46 system.sysContact.0 =

system.sysName.0 = xxxx.inria.fr

system.sysLocation.0 = Batiment 0x − Salle Machine system.sysServices.0 = 6

system.sysORLastChange.0 = Timeticks: (0) 0:00:00.00 interfaces.ifNumber.0 = 7

interfaces.ifTable.ifEntry.ifIndex.2 = 2 interfaces.ifTable.ifEntry.ifIndex.3 = 3 interfaces.ifTable.ifEntry.ifIndex.4 = 4 interfaces.ifTable.ifEntry.ifIndex.5 = 5 interfaces.ifTable.ifEntry.ifIndex.6 = 6 interfaces.ifTable.ifEntry.ifIndex.7 = 7 interfaces.ifTable.ifEntry.ifIndex.8 = 8 interfaces.ifTable.ifEntry.ifDescr.2 = Null0 interfaces.ifTable.ifEntry.ifDescr.3 = Loopback1 interfaces.ifTable.ifEntry.ifDescr.4 = Vlan3 interfaces.ifTable.ifEntry.ifDescr.5 = Vlan4 interfaces.ifTable.ifEntry.ifDescr.6 = Vlan230 interfaces.ifTable.ifEntry.ifDescr.7 = Vlan591 interfaces.ifTable.ifEntry.ifDescr.8 = Vlan592 interfaces.ifTable.ifEntry.ifType.2 = other(1)

interfaces.ifTable.ifEntry.ifType.3 = softwareLoopback(24) interfaces.ifTable.ifEntry.ifType.4 = ethernetCsmacd(6)

(40)

5: Plus de SNMP / Biliographie.

(41)

HP−OV Network Node

Manager

http://openview.hp.com

(42)

MRTG / Cricket

http://people.ee.ethz.ch/~oetiker/webtools/mrtg

http://cricket.sourceforge.net

MRTG et Cricket sont des outils différents. Cependant ils sont basés sur le même moteur de stockage et de "graphage": Les sublimes RRD Tool !

(43)

Tk MIB

http://net−snmp.sourceforge.net

Tkmib est livré avec Net−SNMP. Il est écrit en Perl/Tk. Il nécessite donc: Perl, les modules Perl/Tk, et les modules SNMP de Perl (http://www.cpan.org).

(44)

autres...

SCLI: Client "user−friendly" SNMP (

http://www.ibr.cs.tu−bs.de/projects/scli/

);

Tkined / Scotty (

http://wwwhome.cs.utwentw.nl/~schoenw/scotty/

);

NetCol, NetSaint (http://www.netsaint.org), Perl SNMP modules (http://www.cpan.org);

Spectrum (http://www.aprisma.com ), Netcool (

http://www.micromuse.com

), eEMU

(http://www.eemuconcept.com).

SCLI est tout bonnement génial, un outil de ce genre manquait cruellement au monde SNMP. Il permet d’offrir une interface simple et standard pour faire des requêtes vers des périphériques SNMP−enabled. SCLI possède des fonctions très pratique comme un ‘top‘ SNMP.