Administration

des réseaux
SNMP
CMIP

1 [Link]

mercredi 17 octobre 2012

 Plan

Généralités
Principe
L’administration et l’ISO
L’administration et TCP/IP

2 [Link]

mercredi 17 octobre 2012

 Généralités

 La stratégie générale d’une entreprise résulte de nombreux

facteurs internes et externes.
 La pertinence du Système d’Information et les moyens d’y accéder
sont parmi les composants majeurs du système décisionnaire.

• Administration: Ensemble des moyens mis en œuvre pour :

• Superviser le fonctionnement du S.I. et des réseaux
• Optimiser l’utilisation des ressources
• Détecter voire prévenir les erreurs
• Signaler les pannes
• Disposer de données statistiques
• Disposer de données de facturation.
 Objectif de Réactivité et Proactivité dans la gestion des réseaux.

3 [Link]

mercredi 17 octobre 2012

 Généralités

 Complexité et hétérogénéité des réseaux et systèmes;

 Les méthodes ad hoc ne suffisent pas à assurer le suivi:
 ping, traceroute, netstat
 telnet, interface web sur les matériels
 whois, . . .

→ besoins des standards pour d’aide à la gestion

4 [Link]

mercredi 17 octobre 2012

Principe

 L’administration d’un réseau suppose l’existence d’une base

d’information décrivant l’ensemble des objets administrés.

Station
d’administration
Ensemble des
objets gérés

Base
d’information

5 [Link]

mercredi 17 octobre 2012

 Principe
Objet Station
administré d’administration

Processus Processus
Agent Manager

Nb collisions =
Nb erreurs CRC =
Nb total de paquets Protocole de
IP reçus =
Gestion
Nb d’erreurs de
ré-assemblage =
.......

6 [Link]

mercredi 17 octobre 2012

 Gérer quoi?

• Des équipements (commutateur, routeur, …)

• Des réseaux (Ethernet, ATM,…)
• Des services (Web, messagerie,…)
• Des applications (SGBD, Système d’information,
…)
• Des utilisateurs (identification, privilèges, …)

7 [Link]

mercredi 17 octobre 2012

 Etat des lieux

Deux standards:
 Common Information Management Protocol
(CMIP):
protocole OSI
peu utilisé
Simple Network Management Protocol:
très répandu car très simple à mettre en œuvre
actuellement version 3

8 [Link]

mercredi 17 octobre 2012

 Généralités
Principe
L’administration et l’ISO
L’administration et TCP/IP
Etude de SNMP

9 [Link]

mercredi 17 octobre 2012

Généralités
 L’ISO, en partenariat avec l’UIT-T, spécifie un cadre
architectural : OSI Management Framework (ISO 10040).
 Cette administration s’appuie sur trois modèles :
 Un modèle organisationnel
 Un modèle informationnel
 Un modèle fonctionnel

10 [Link]

mercredi 17 octobre 2012

 Modèle organisationnel

 Fournit les moyens de transfert des informations de gestions

entre les objets administrés.
 Définit un dialogue (le CMIP : Common Management
Information Protocol ISO 9596), lequel utilise les primitives
suivantes :
 Get : élément de service utilisé par le gérant pour lire la valeur d’un
attribut
 Set : fixe la valeur d’un attribut
 Event : permet à un agent de signaler un événement
 Create : génère un nouvel objet
 Delete : permet à l’agent de supprimer un objet

11 [Link]

mercredi 17 octobre 2012

 Modèle informationnel
 Identification et représentation du QUOI?
• Il définit et normalise :
 les objets administrés
 leur nom
 leur fonction
 leurs relations
 leurs attributs
 les actions qui leurs sont applicables
 L’ensemble des éléments gérés est orienté objet et constitue une
MIB (Management Information Base : ISO 10165) qui contient toutes
les informations administratives sur ces objets :
 Ponts
 Routeurs
 Cartes
 ....

12 [Link]

mercredi 17 octobre 2012

 Modèle Fonctionnel

 Ce modèle définit des domaines fonctionnels d’administration et

leurs relations.
 Quelles fonctions doit couvrir l’administration : pourquoi gérer ?
 On retrouve 5 domaines, (ou 5 SMFA Specific Management
Function Area) :
 La gestion des fautes
 La gestion des configurations
 La gestion des performances
 La gestion de la sécurité
 La gestion de la comptabilité

13 [Link]

mercredi 17 octobre 2012

Gestion des fautes

 Optimisation des ressources et des moyens.

 Diagnostic rapide de toute défaillance (externe, coupure d’un
lien public, ou interne, panne d’un routeur).
 On retrouve aussi :
 Surveillance et traitement des alarmes
 Localisation et diagnostic des incidents
 Mémorisation des anomalies (journalisation)
 Définition des opérations curatives

14 [Link]

mercredi 17 octobre 2012

 Gestion de la configuration
 Maintenir un inventaire précis des ressources matérielles
(type, équipement,. . .) et logicielles (version, fonction,. . .).
 Connaître la répartition géographique des équipements gérés
(localisation), leurs configurations logicielles et matérielles et
leurs états (on, off, stand-by, busy, listen…)
 manipuler les configurations
 Démarrer, initialiser, arrêter le système

15 [Link]

mercredi 17 octobre 2012

 Gestion des performances
 Mettre en œuvre des moyens permettant d’évaluer le
comportement des objets gérés.
 Déterminer si la QoS est rendue aux utilisateurs.
 On retrouve :
 La collecte d’information (audit)
 Mesure de trafic
 Temps de réponse
 Taux d’erreurs
 Le stockage (archivage)
 L’interprétation des mesures (calcul de charge)
 Capacité du réseau
 Trafic temps réel
 Débit par application
 Goulots d’étranglement
 Mesure des variations de temps de réponse = gigue

16 [Link]

mercredi 17 octobre 2012

 Gestion de la sécurité

 Regroupe tous les domaines de la sécurité afin d’assurer

l’intégrité des informations traitées et des objets administrés :
 Contrôle d’accès au réseau
 Confidentialité des données
 Intégrité des données
 Authentification des utilisateurs
 Visualiser, modifier et supprimer une politique de sécurité
 Compte-rendu des événements relatifs à la sécurité

17 [Link]

mercredi 17 octobre 2012

 Gestion de la comptabilité
 Cette fonction permet essentiellement d’imputer les coûts du
réseau à ses utilisateurs selon l’usage réel des moyens.
 On retrouve :
 Génération des rapports
 Mesure des dépenses (structure) et répartition
 Mesure des consommations par service
 Tarification
 Ressources consommées
 Pourcentage d’utilisation des ressources
 Statistique des applications
 Charge des serveurs

18 [Link]

mercredi 17 octobre 2012

 Administration OSI

 Ambition de couvrir tous les domaines de l’administration

  Extrêmement complexe

19 [Link]

mercredi 17 octobre 2012

 Généralités
Principe
L’administration et l’ISO
L’administration et TCP/IP
Historique
Généralités

20 [Link]

mercredi 17 octobre 2012

Historique

 Début des 80 : Différents fournisseurs de ressources réseaux

(machines, passerelles, ponts, périphériques divers tels les imprimantes
ou les scanners)
 Prolifération de réseaux d'interconnexion de machines.
 Outils propres d'administration
 Chaque type d’équipement devait être
configuré par une méthode propriétaire.
 Très vite, est apparu qu'une méthode simple et unifiée d'administration
des ressources distribuées sur un réseau s'avérait nécessaire, afin de
diminuer la charge et la complexité de l'administration réseau.
  Le besoin d’outils de gestion du réseau Internet

21 [Link]

mercredi 17 octobre 2012

Historique

o En 1987, trois voies indépendantes se sont créées pour répondre à

ce besoin. Il s'agissait de :
o HEMP : High-level Entity Management Protocol
o SGMP : Simple Gateway Monitoring Protocol
o CMOT : Common Management Information Protocol over TCP

22 [Link]

mercredi 17 octobre 2012

Historique

 SGMP était plus simple à implémenter que CMOT,

 CMOT, basé sur CMIP, d'architecture OSI, était considéré
comme supérieur.
  Peu de tentatives d'implémentation de CMIP
 SGMP continuait à être développé en vue d'obtenir une
implémentation efficace et utilisable à court terme, tandis que
parallèlement, la recherche autour de CMOT devait
permettre d'aboutir à une solution finale pour le long terme. .
 Mais, CMOT/CMIP est toujours très peu implanté,

23 [Link]

mercredi 17 octobre 2012

Historique
 SGMP: créé uniquement pour gérer l'augmentation des passerelles qui
interconnectent différents réseaux TCP/IP.
 Les premières idées concernant SGMP sont apparues en [Link], il était
implémenté sur de nombreuses plateformes.
 En 1988, l’IETF (Internet Engineering Task Force) a créé un protocole pour
résoudre le problème de la coexistence des trois protocoles d'administration
de réseaux.
  Le groupe de travail proposa d'abandonner HEMP, et de faire évoluer
SGMP en donnant à ses nouvelles versions le nom de Simple Network
Management Protocol (SNMP)
 Objectifs de SNMP :
 Fédérer en un standard unique des protocoles multiples liés aux équipementiers.
 Déploiement rapide et à moindre coût.
 Ainsi, SGMP a pu évoluer sous les formes SNMPv1, puis SNMP Security aussi
SNMPv2 et enfin SNMPv3, protocoles implémentés par de nombreux
constructeurs

24 [Link]

mercredi 17 octobre 2012

 Historique
HEMP CMOT SGMP
1987
1988
SNMPv1
1989

1992
1993 SNMP Security
1994 SNMPv2

1997
1998 SNMPv3

25 [Link]

mercredi 17 octobre 2012

Généralités

 L’environnement SNMP répond à trois objectifs :

 Permettre la configuration des éléments d’un réseau
 Détecter et analyser les fautes d’un réseau
 Surveiller les performances d’un réseau

26 [Link]

mercredi 17 octobre 2012

Le modèle d ’administration

 Une administration SNMP est composée de trois types

d'éléments :
 des agents chargés de superviser un équipement. On parle d'agent SNMP installé sur
tout type d'équipement.
 une ou plusieurs stations de gestion capables d'interpréter les données
 une MIB (Management Information Base) décrivant les informations gérées (objets
administrés).
 Un protocole permettant la supervision, le contrôle et la
modification des paramètres des éléments du réseau.

27 [Link]

mercredi 17 octobre 2012

 Les nœuds administrés

 Les nœuds administrés contiennent un agent SNMP (ou

compatible SNMP).
 Ils fournissent des informations à partir d’une base de données
dont les éléments reflètent l’état de l’objet qu’ils représentent.

28 [Link]

mercredi 17 octobre 2012

 La station d’administration

 La station d’administration ou NMS (Network Management

Station) est un applicatif pour la surveillance et le contrôle
du réseau.

La station
d’administration

29 [Link]

mercredi 17 octobre 2012

 Le protocole réseau

 Le protocole réseau est le protocole de communication entre

la NMS et le MN (Network Management Station et Managed
Node).
 Deux stratégies de collecte d’information de gestion existent
entre le gestionnaire et l’agent :
 Mécanisme de scrutation
 Mécanisme événementiel

30 [Link]

mercredi 17 octobre 2012

 Architecture protocolaire

7
SNMP

ASN
6 1
SNMP

UDP
4

3
IP

2
LAN
1

31 [Link]

mercredi 17 octobre 2012

 Principe
L’administration et l’ISO
L’administration et TCP/IP

32 [Link]

mercredi 17 octobre 2012

 Structure of Management Information (SMI)

• Ensemble de règles pour identifier d’une manière unique

les objets gérés.

•Définir la structure logique de la base informationnelle MIB

(Management Information Base)

•Deux versions: SMI 1 et SMI 2

33 [Link]

mercredi 17 octobre 2012

 Structure of Management Information
(SMI)
Les objets du réseau gérés sont accessibles de deux
manières:
Physiquement: Accès direct à l’information (@IP,
nombre de paquets, état de l’interface, etc.)(depuis
OS)
Logiquement: Les informations sont dans la MIB
pour être consultés et modifiés.
SMI est responsable de l’organisation logique
de ses informations.

34 [Link]

mercredi 17 octobre 2012

 Structure of Management Information
(SMI)
Avec SMI chaque objet géré doit posséder:
•Un nom: un identifiant unique (OID: Object
IDentifier )
•Une syntaxe: type de données (integer, string, etc.)
 Langage ASN.1
•Un codage: représentation binaire pour la
transmission sur le réseau  Codage BER

35 [Link]

mercredi 17 octobre 2012

 Principe
L’administration et l’ISO
L’administration et TCP/IP
Etude de SNMP

36 [Link]

mercredi 17 octobre 2012

Historique
•1984 : apparition du premier standard
•1994 : évolution majeure des réseaux (débits importants, nouveaux
alphabets…) mène à l’évolution de ASN.1
•La couche présentation est complètement normalisée:
Les deux organismes de normalisation internationale (ITU-T
Inter. Telecom Union - Telecom Sector et ISO) ont proposé des
textes communs décrivant:

• l’accès aux services fournis par la couche présentation ainsi

que le protocole de cette couche,
•et une notation de syntaxe abstraite et une syntaxe de
transfert (règles de codage).

37 [Link]

mercredi 17 octobre 2012

 Différentes normes

38 [Link]

mercredi 17 octobre 2012

 Rôle
•La couche présentation se charge de la représentation
des informations échangées entre systèmes ouverts.
•La couche présentation offre plusieurs fonctionnalités,
parmi lesquelles les plus caractéristiques sont :

•la préservation de la sémantique des données échangées,

•la négociation des syntaxes de transfert,
•l'accès des applications aux services de la couche session.

39 [Link]

mercredi 17 octobre 2012

Préservation de la sémantique

• Signifie qu’il n’est pas obligatoire que la représentation

(syntaxe) des données soit préservée, tant que la sémantique
reste inchangée.

• En effet, les applications désirant communiquer, peuvent fonctionner

sur des équipements informatiques :
•de constructeurs différents (environnement matériel différent) ;
• gérés de façon différentes (systèmes d’exploitation différents) ;
•de niveaux de complexité différents (processeurs différents) ;
•les applications peuvent avoir été développés à l’aide de langages de
programmation différents.

40 [Link]

mercredi 17 octobre 2012

 POURQUOI ASN.1
•La diversité des architectures machines;

• La rapidité des échanges et l’explosion de leur nombre ne

signifient pas que les structures des informations échangées soient
simplifiées;

• Les réseau et les terminaux constituent un mode hétérogène.

41 [Link]

mercredi 17 octobre 2012

 POURQUOI ASN.1
•Deux représentations différentes co-existent dans les années 50-
début 60:
• Le code ASCII (American Standard Code for Information
Interchange) connu sous la dénomination de ANSI X3.4;
• Le code EBCDIC (Extended Binary Coded Decimal
Interchange Code) recommandé par IBM dans les années
50-60, abandonné depuis…

42 [Link]

mercredi 17 octobre 2012

POURQUOI ASN1
• L’ordonnancement des octets dans lequel les données sont stockées
dans la mémoire, ou échangés, peut être effectué :
•big endian : les octets sont numérotés de gauche à droite
•little endian : les octets sont numérotés de droite à gauche

•Des manufacturiers « little endian » et des manufacturiers « big

endian »
•Technique de représentation des nombres entiers :
•représentation binaire en complément à 1, ou complément à 2,
DCB, etc.
•Technique de représentation des nombres réels :
•Virgule flottante, mantisse + exposant, base décimale ou
binaire, etc.

43 [Link]

mercredi 17 octobre 2012

 Syntaxes

Trois types:
syntaxe concrète ou réelle.
syntaxe abstraite.
syntaxe de transfert.

44 [Link]

mercredi 17 octobre 2012

 Syntaxe concrète ou réelle
• Représentation dans un langage donné des structures de
données à transférer;

•Il s’agit d’une syntaxe car elle respecte les règles lexicales et
grammaticales d’un langage (exemple C);

• Cette syntaxe est concrète car elle a à voir avec la machine, ses
restrictions.

45 [Link]

mercredi 17 octobre 2012

 Syntaxe abstraite
•Est indépendante du langage de programmation;

•Dispose d’une grammaire devant être respectée par les données

échangées;

•Offre un formalisme riche au niveau du typage : elle offre la possibilité

de définir des données simples et complexes;

•Est formelle ce qui permet de prévenir les ambigüités;

•Définit la structure des données mais pas la sémantique :

l’interprétation des données est effectuée par l’application.

46 [Link]

mercredi 17 octobre 2012

 Syntaxe de transfert
•Est un ensemble de règles de codage (et de décodage) permettant de générer
un flot d’octets (ou binaire) à partir d’une syntaxe réelle ou abstraite.

• Cette dernière définit la représentation des données échangées entre

deux machines (par exemple l’ordre)

• Elle est fortement liée à la syntaxe abstraite;

•Plusieurs syntaxes de transfert peuvent être associées à une syntaxe

abstraite.

•Le codage de base d’ASN.1 (BER) est une syntaxe de transfert.

47 [Link]

mercredi 17 octobre 2012

 Définition d’ASN.1
• ASN.1 est un langage pour décrire de manière abstraite les
données échangées par des applications de communication.

•Il est indépendant des applications, des systèmes d’exploitation et

des processeurs.
•ASN.1 est un ensemble de types de données de base pouvant être
réutilisés pour en construire d’autres.
•Et un ensemble de règles de construction permettant de définir
de nouveaux types de données.
•Et également, c’est un ensemble d’opérateurs de construction
utilisés pour définir de nouveaux types.

48 [Link]

mercredi 17 octobre 2012

 Types de données ASN.1
• ASN.1 utilise deux types de données:
•Primitive: type simple (INTEGER, OCTET STRING, REAL, etc.);
•Constructeur: combinaison de types simple (listes ou des
tableaux).

49 [Link]

mercredi 17 octobre 2012

 Types de données ASN.1
•SMI utilise un sous-ensemble des types simples de ASN.1(RFC1155- 1990):
• INTEGER
•OCTET STRING
•OBJECT IDENTIFIER
•NULL

50 [Link]

mercredi 17 octobre 2012

 Convention de lexique ASN.1
Terme Description
.. Intervalle
::= Affectation
| Alternative
-- Commentaire
{} Début et fin de listes
- nombre signé
[] Début et fin de tag
() Début et fin de sous-type

51 [Link]

mercredi 17 octobre 2012

 Conventions ASN.1
ASN.1 fait la différence entre minuscules et majuscules.

Terme Convention
Types 1er caractère en Majuscule
Values 1er caractère en Minuscule
Macros tous les caractères en Majuscule
Modules 1er caractère en Majuscule
Mots réservés tous les caractères en Majuscule

52 [Link]

mercredi 17 octobre 2012

 Types de données ASN.1
• Chaque objet possède un type et une valeur.
• Règle de déclaration de type
•[nom du type] ::= [définition du type]
• Règle de déclaration de variable
• [nom de la valeur] [nom du type] ::= [définition de la
valeur]

53 [Link]

mercredi 17 octobre 2012

 Types de données ASN.1
•Exemple de type simple
•Salaire::= INTEGER
• sMIC Salaire::= 1800
• Age ::=INTEGER (0..100)
• ageRetraite Age ::= 65
•phrase OCTET STRING ::= ”blabla blabla"

54 [Link]

mercredi 17 octobre 2012

 Octet string
• Une séquence (chaînes d'octets ) de zéro ou plusieurs
octets.
•Trois cas spéciaux de type OCTET STRING:
•DisplayString: tous les caractères sont imprimables (ASCII);
•Bitstring: suite de bits (SMI2);
•PhysAddress: représente une adresse physique(MAC address)

55 [Link]

mercredi 17 octobre 2012

 OBJECT IDENTIFIER
•Identificateur d'objets : chaîne d'entiers déduites de l'arbre
d'enregistrement, utilisée pour identifier de manière unique un objet
•Il permet d’organiser l’arbre SMI.
• Exemples:
•internet OBJECT IDENTIFIER ::= {iso org(3) dod(6) 1}
• mgmt OBJECT IDENTIFIER ::= {internet 2}
• mib-2 OBJECT IDENTIFIER ::= {mgmt 1}
•system OBJECT IDENTIFIER ::= {mib-2 1}
• sysDescr OBJECT IDENTIFIER ::= {system 1}

56 [Link]

mercredi 17 octobre 2012

 Types de données SNMP
•Quelques types simples de données, spécifiques aux applications
SNMP, ont été rajoutées aux primitives de base.

Type Définition

Counter entier qui s'incrémente jusqu'à une valeur maximum et se

réinitialise à zéro
Gauge entier qui peut s’incrémenter ou se décrémenter

TimeTicks Temps en centième de seconde

IpAddress Adresse IP

NetworkAddress Adresse réseau

Opaque C'est un flux d'octets banalisés qui permet d'encoder tout

ce qui ne relève pas des types précédents.

57 [Link]

mercredi 17 octobre 2012

 Types de données SNMPv2
•Quelques types simples considérés pour SNMPv2 (RFC 2578- 1999) :

•BITSTRING : chaînes de bits;

• Integer32 : entier compris entre -231 et 231-1

• Counter32 : comme counter, mais compris 0 et 232-1

•Gauge32 : comme gauge, mais compris entre 0 et 232-1

• Counter64 : comme counter, mais compris 0 et 264

• Uinteger32 : entier non signé, compris entre 0 et 232-1

58 [Link]

mercredi 17 octobre 2012

 Construction de nouveaux types
• La notation de syntaxe ASN.1 définit deux
méthodes pour construire des types nouveaux :

•par étiquetage de types existants, qu’ils soient

de base ou non ;

•par utilisation d’outils de construction.

59 [Link]

mercredi 17 octobre 2012

 Types complexes ASN.1
• Deux types complexes pour définir des tableaux:

•SEQUENCE OF : liste ordonnées de valeurs de

même type.

•SEQUENCE : liste ordonnées fixe de valeurs

de type différents.

60 [Link]

mercredi 17 octobre 2012

 SEQUENCE
• Permet de créer une structure de données dont chaque élément
peut être soit une structure complexe, soit une donnée simple et pour
laquelle l’ordre des éléments est fondamental

•Exemple:
•IpRoutingTableLine ::= SEQUENCE {
ipRouteDest IpAddress,
ipRouteNextHop IpAddress,
metric INTEGER}
passerelle IpRoutingTableLine ::= {[Link], [Link], 0}

61 [Link]

mercredi 17 octobre 2012

 SEQUENCE OF
•liste ordonnées de valeurs de même type
•Exemple:
TableRoutage ::= SEQUENCE OF IpRoutingTableLine
routeur TableRoutage::= { {[Link], [Link],
3}, {[Link], [Link], 20} }

ipRouteDest ipRouteNextHop metric

[Link] [Link] 3

[Link] [Link] 20

62 [Link]

mercredi 17 octobre 2012

 Accès dans une table
•Principe général:
•Un seul indice:

X . C . I

OID table Nom Colonne Index

•Deux indices:
X. C. I1 . I2

OID table Nom Colonne Index1 Index2

63 [Link]

mercredi 17 octobre 2012

 Accès dans une table
•Exemple: RouteTable(5)

Index1 Index2

Destination (1) Metric(2) NextHop(3)

[Link] 1 [Link]
[Link] 3 [Link]
[Link] 2 [Link]
[Link] 1 [Link]
[Link] 1 [Link]

[Link].23.24.1 [Link]

64 [Link]

mercredi 17 octobre 2012

 SEQUENCE OF
•Les indices.
•Exemple:
TableRoutage ::= SEQUENCE OF IpRoutingTableLine
routeur TableRoutage::= { {[Link], [Link], 3},
{[Link], [Link], 20} }

ipRouteDest ipRouteNextHop metric

[Link] [Link] 3

[Link] [Link] 20

65 [Link]

mercredi 17 octobre 2012

 Macro
•Une macro permet de déclarer un type autre que
ceux utilisés de base.

•Déclaration d’une macro ASN.1:

<macro name> MACRO ::= BEGIN
TYPE NOTATION ::= <user-defined type notation>
VALUE NOTATION ::= <user-defined value notation>
<supporting syntax>
END

66 [Link]

mercredi 17 octobre 2012

 Macro OBJECT-TYPE
•OBJECT-TYPE permet une extension du SMI:
OBJECT-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::=
"SYNTAX" type(ObjectSyntax)
"ACCESS" Access
"STATUS" Status
DescrPart
VALUE NOTATION ::= value (VALUE Object IDENTIFIER)
Access ::= "read-only "
| "read-write"
| "write-only »
| "not-accessible "
Status ::= "mandatory »
| "optional"
| "obsolete"
| "deprecated"
DescrPart ::="DESCRIPTION" value (description DisplayString)
| empty
END [Link]

mercredi 17 octobre 2012

 Macro OBJECT-TYPE
• SYNTAX : Type de données
•ACCESS: droits d’accès
• read-only, read-write, not-accessible
• not-accessible est utilisé pour les tables et les lignes de tables
•STATUS:
• mandatory, optional, deprecated, ou obsolete.
• Obsolete est utilisé pour les objets qui ne sont plus supportés
• Deprecated : pour les objets qui sont remplacés par d’autres
objets compatibles
• DESCRIPTION: définition textuelle de l’objet
• REFERENCE: définition textuelle d’un autre objet de référence défini
dans une autre MIB
• INDEX: décrit l’ordre de parution des champs d’un tableau (colonnes).
•DEFVAL:Valeur par défaut des champs d’une ligne (Tableau)

68 [Link]

mercredi 17 octobre 2012

 Macro OBJECT-TYPE : Exemple
sysDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION “A textual description of the entity. This value
should include the full name and version identification of the
system’s hardware type, software operating-system, and
networking software.“
::= { system 1 }

69 [Link]

mercredi 17 octobre 2012

 Déclaration d’un objet dans la MIB
tcpInSegs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { tcp 10 }

La déclaration précédente signifie que:

• tcpInSegs est un objet qui contient des informations de type Counter.
•tcpInSegs est en lecture seule
• tcpInSegs doit être présent dans les systèmes gérés qui supporte son parent
[Link]
• tcpInSegs est placé dans la position 10 dans le group tcp.

70 [Link]

mercredi 17 octobre 2012

Déclaration d’un objet dans la MIB SMI2
• Opérations autorisées sur les objets En SMIv1:
• read-only, read- write, write-only et not-accessible ;
• elles sont décrites dans la clause ACCESS.

•En SMIv2, les opérations possibles ont été modifiées et sont

décrites dans la clause MAX-ACCESS
• les valeurs possibles:
• not-accessible, accessible-for-notify, read-only, read-write, read-
create.
•read-create : permet l’ajout et le retrait de lignes dans les
tableaux, qui n’étaient pas standardisées en SMIv1.
•La clause STATUS n'inclut plus les catégories optionnel et
obligatoire: current, obsolete, deprecated.
71 [Link]

mercredi 17 octobre 2012

 Modules

• ASN.1 regroupe les déclarations d’objet dans des listes appelées: module

•Les règles d’implémentation des modules définissent ce qui doit être supporté
par les agents

•La déclaration d’un module commence par le nom du module suivit de

DEFINITIONS

•BEGIN et END englobent le corps du module

•IMPORTS peut être utilisé pour faire référence à des types et valeurs déclarés
dans d’autres modules

72 [Link]

mercredi 17 octobre 2012

 Modules: exemple
RMON-MIB DEFINITIONS ::=
BEGIN
IMPORTS
Counter FROM RFC1155-SMI
DisplayString FROM RFC1158-MIB
mib-2 FROM RFC1213-MIB
OBJECT-TYPE FROM RFC-1212
TRAP-TYPE FROM RFC-1215;
--Remote Network Monitoring MIB
rmon OBJECT IDENTIFIER ::= { mib-2 16 }
--textual conventions
...

73
END [Link]

mercredi 17 octobre 2012

 Définition de groupes d’objets

•Permet de définir un groupe d’objets qui vont logiquement ensemble

System OBJECT-GROUP
OBJECTS {sysDescr, sysObjectID, sysUPTime…}
STATUS current
DESCRIPTION “ Contient les infos sur le système”
::={mib-2 1}

74 [Link]

mercredi 17 octobre 2012

 Définition de modules, de groupes et d’objets

75 [Link]

mercredi 17 octobre 2012

 Principe

L’administration et l’ISO

L’administration et TCP/IP

Etude de SNMP

Abstract Syntax Notation Number 1

Management Information Base

76 [Link]

mercredi 17 octobre 2012

 Management Information Base

•Représente la base de données des objets gérés par un

agent;

•Peut être supervisée et modifiée par la plate-forme

d’administration;

•MIB : définit l’ensemble des variables permettant de gérer

la pile protocolaire TCP/IP

77 [Link]

mercredi 17 octobre 2012

 Nommage des objets

• Les objets (variables) gérés par les MIB sont désignés selon
une hiérarchie définie par l'ISO dite arbre de nommage.

•Dans cet arbre chaque organisme de normalisation

dispose d'une entrée au niveau 1.

• Les différentes branches permettent de nommer

un objet de manière unique.

78 [Link]

mercredi 17 octobre 2012

 Nommage des objets

•Les noms sont utilisés pour identifier les objets gérés.

•Chaque objet possède un identificateur d'objet qui lui est
propre.

•Ce dernier a une structure hiérarchique, arborescente.

•C'est une séquence de nombres entiers qui

parcourent un arbre.

79 [Link]

mercredi 17 octobre 2012

 Nommage des objets

80 [Link]

mercredi 17 octobre 2012

 Nommage des objets

•L'IETF (Internet Engineering Task Force) utilise l'arbre

d'enregistrement de l’ISO.
•Cet arbre est composé d'une racine à laquelle sont
liés tous les nœuds.
•Le nœud-racine de l'arbre n'est pas indiqué, mais il
possède trois fils,
•l'ITU-T marqué ccitt(0),
• le second administré par l'ISO et marqué iso(1)
•et iso-ccitt(2) administré par les deux à la fois.

81 [Link]

mercredi 17 octobre 2012

 Nommage des objets
•Sous le nœud de l’ISO, un sous arbre est prévu pour d'autres
organisations,
•l'une d'elle est le département de la défense US (dod).
•La RFC 1155 gère le sous arbre du dod alloué à l'IAB (Internet Activity
Board).

•Directory(1): Réservé pour l’ISO, ne contient actuellement aucune

sous-branche et reste réservée pour des applications futures.

•mgmt(2): L'administration de ce sous arbre est délégué à l'IANA

(Internet Assigned Numbers Authority).

82 [Link]

mercredi 17 octobre 2012

 Nommage des objets

•Experimental(3): contient exclusivement les MIBs en expérimentation

pour tester de nouveaux objets. Délégué à l'IANA.

•Private(4): Sous arbre des délégations privées contient le sous-arbre

Entreprise.

•Elle est réservée aux organisations qui souhaitent développer des extensions à
la MIB standard.
•C'est un moyen pour les constructeurs de définir des objets qui sont
propres à leurs équipements : ce sont les MIBs privées.
• Enregistrement auprès de l'IANA qui affecte un numéro d'entreprise
permettant de définir un sous-arbre spécifique à l'entreprise.

83 [Link]

mercredi 17 octobre 2012

 Nommage des objets
•La branche MANAGEMENT est celle qui contient les objets
« standard » au travers la sous-branche : MIB I et MIB II qui sont les
deux versions de la MIB.

•Les RFC 1156 définit la MIB I (plus de 110 objets);

•et RFC 1213 définit la MIB II (plus de 170 objets);

•Les OIDs standards sont placés sous le nœud nommé mib-2(1).

•Un objet SNMP est désigné par une suite d'entiers : OID (Object
IDentifier) en parcourant l’arbre de nommage depuis la racine.

84 [Link]

mercredi 17 octobre 2012

 Nommage des objets MIB1

Syst
1
Interface
1 2
UIT STD Directory Addr. Trans.
0 0 1
2 3 1-
Mgmt 2-
Internet MIB I IP
ISO 1 3 2 3-
1 1 4
1 Experim. 4-
ICMP 5-
4 3
2 2 5 6-
2
Private
TCP 7-
ORG 3 4
5 6 8-
2
3 9-IpInDelivers
DoD UDP
6 4 7
EGP
8

Exemple dans la MIB I l’OID de IpInDelivers:

85 [Link]

mercredi 17 octobre 2012

 Nommage des objets MIB2

86 [Link]

mercredi 17 octobre 2012

 Objets de la MIB
•system { mib-2 1 } :
• Système géré : son nom, le type d’équipement, etc.

•interfaces { mib-2 2}
• Interfaces réseau : contient la description, l’état et les statistiques des interfaces.

•at { mib-2 3 } Address Translation :

• atTable contient la table des adresses MAC (Media Access Control) et réseau.

•ip { mib-2 4 } :
•configuration générale, table des adresses (ipTable), de routage (ipRouteTable), table ARP
(Address Resolution Protocol)...

87 [Link]

mercredi 17 octobre 2012

 Nommage des objets

•icmp { mib-2 5 } (Internet Control Message Protocol) : Données ICMP

•tcp { mib-2 6 } : configuration, statistiques générales et table des connexions .

•udp { mib-2 7 } : statistiques et table UDP.

•egp { mib-2 8 } EGP (Exterior Gateway Protocol) : statistiques et table des voisins.

•cmot { mib-2 9 } CMIP over TCP/IP : obsolète. Seul l’OID est réservé dans mib-2.

•transmission { mib-2 10 } Ce groupe est prévu pour « raccrocher » d’autres modules de

MIB qui concernent des médias de transmission plus spécifiques qui viennent compléter
les informations contenues dans le groupe interface.

•snmp { mib-2 11 } SNMP : statistiques messages SNMP.

88 [Link]

mercredi 17 octobre 2012

 Groupe System(1)

MIB-2 (1)

System(1)

1 SysDescr

2 SysObjectID

3 SysUpTime

4 SysContact

5 SysName

6 SysLocation

7 SysServices

89 [Link]

mercredi 17 octobre 2012

 sysDescr

Cet objet est une chaîne de caractères fournissant une description de l’agent. Cette
information peut inclure le nom complet de l’agent, sa version d’identification, le type de
matériel et de logiciel d’exploitation.

sysDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A textual description of the entity. This value should include the full name and
version identification of the system's hardware type, software operating-system, and networking
software. It is mandatory that this only contain printable ASCII characters."
::= { system 1 }

Exemple:
sysdescr.0 : Cisco Internetwork Operating System Software IOS 2500 Software RELEASE
SOFTWARE Copyright (c) 1986-1999 by cisco Systems, Inc.

90 [Link]

mercredi 17 octobre 2012

 SysObjectID
•Cet objet est un Object Identifier permettant au constructeur de positionner l’agent
dans l’arbre de sa MIB propriétaire.

sysObjectID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The vendor's authoritative identification of the network management subsystem contained in the
entity. This value is allocated within the SMI enterprises subtree ([Link].4.1) and provides an easy and unambiguous means for
determining `what kind of box' is being managed. For example, if vendor `Flintstones, Inc.' was assigned the subtree
[Link].4.1.4242, it could assign the identifier [Link].4.1.4242.1.1 to its `Fred Router'."
::= { system 2 }

Exemple: sysObjectID.0 : cisco.1.17

91 [Link]

mercredi 17 octobre 2012

 SysUpTime

Cet objet fournit le temps écoulé en centièmes de second depuis l’initialisation de l’agent.

sysUpTime OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION "The time in hundredths of a second since the network
management portion of the system was last re-initialized."
::= { system 3 }

92 [Link]

mercredi 17 octobre 2012

 SysContact

•Cet objet est une chaîne de caractères fournissant le nom du responsable de

l’équipement. Cette valeur est initialisée par l’administrateur du réseau

sysContact OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The textual identification of the contact person for this managed node, together with
information on how to contact this person."
::= { system 4 }

•Exemple :
•sysContact.0: Mr. ALLALI all@[Link]

93 [Link]

mercredi 17 octobre 2012

 SysName
•Cet objet est une chaîne de caractères fournissant le nom de
l’équipement. Cette valeur est initialisée par l’administrateur du réseau.

sysName OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"An administratively-assigned name for this managed node. By
convention, this is the node’s fully-qualified domain name."
::= { system 5 }

Exemple:
sysName.0 : Switch F1

94 [Link]

mercredi 17 octobre 2012

 SysLocation

•Cet objet est une chaîne de caractères fournissant la localisation de l’équipement.

Cette valeur est préalablement initialisée par l’administrateur du réseau.

sysLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The physical location of this node (e.g., telephone closet, 3rd floor')."
::= { system 6 }

Exemple:
sysLocation.0 : 1er étage Immeuble 5

95 [Link]

mercredi 17 octobre 2012

 SysServices

Cet objet est un entier fournissant à travers un algorithme le niveau de

fonctionnalité de l’équipement.

sysServices OBJECT-TYPE
SYNTAX INTEGER (0..127)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A value which indicates the set of services that this entity primarily offers.
The value is a sum. This sum initially takes the value zero,Then, for each layer, L, in the range
1 through 7, that this node performs transactions
for, 2 raised to (L - 1) is added to the sum. For example, a node which performs primarily routing
functions would have a value of 4 (2^(3-1)). In contrast, a node which is a host offering
application services would have a value of 72 (2^(4-1) + 2^(7-1)). Note that in the context of
the Internet suite of protocols, values should be calculated accordingly:
layer functionality
1 physical (e.g., repeaters)
2 datalink/subnetwork (e.g., bridges)
3 internet (e.g., IP gateways)
4 end-to-end (e.g., IP hosts)
7 applications (e.g., mail relays)
For systems including OSI protocols, layers 5 and 6 may also be counted."
::= { system 7 }

96 [Link]

mercredi 17 octobre 2012

 SysServices

•Le tableau suivant permet de donner cette valeur.

•Si l’équipement est un répéteur, la valeur est 1 (physique).

•Si l’équipement est un pont (bridge), la valeur est 2 (donnée).

•Si l’équipement est un routeur, la valeur est 4 (réseau).

•Si l’équipement est un pont, routeur, la valeur est 2 + 4 = 6.

Service Niveau Valeur

Application 7 64
Transport 4 8
Réseau 3 4
Liaison de données 2 2
Physique 1 1

97 [Link]

mercredi 17 octobre 2012

 Groupe Interface

•Les différentes interfaces réseau d'une machine (nombre d'interface, type des interfaces et
nom du fabricant, vitesse des interfaces, nombre de paquets entrants, sortants, en erreur,...)

MIB-2 (1)

Interfaces(1)

ifNumber(1)

ifTable(2)

ifEntry(1)

ifIndex(1)

ifDescr(2)

ifType(3)

ifMtu(4)

ifSpeed(5)

98 [Link]

mercredi 17 octobre 2012

 Groupe AT

•Conservé pour des raisons de compatibilité avec MIB-I. Ce groupe est en

(deprecated).
•Gère une table de translation entre des adresses réseau de niveau logique (IP) et
adresses spécifiques ( Ethernet).
•Equivalent à la table ARP.

MIB-2 (1)

Address translation (3)

iatTable(1)

atEntry(1)

atIfIndex(1)

atPhysAddress(2)

atNetAddress(3)

99 [Link]

mercredi 17 octobre 2012

 Groupe IP

•Les différents paramètres:

•durée de vie par défaut des paquets IP,
•nb de paquets reçus ou envoyés,
•nb de paquets réassemblés avec succès
ainsi que le nb de fragments crées,
•la table de routage si elle existe,
•le masque sous-réseau,
•l'adresse physique, etc.
•la partie de la MIB la plus important.

100 [Link]

mercredi 17 octobre 2012

 Groupe icmp

•représente la liste des variables liées au

protocole ICMP (Internet Control Message
Protocol).
•Contient 26 compteurs :
•pour chaque message icmp, 2 compteurs
pour compter les messages reçus et émis

101 [Link]

mercredi 17 octobre 2012

 Groupe tcp

•Rend compte des connexions TCP en cours et

des paramètres de type nombre max de
connexions simultanées permises, nombre
d'ouverture active,...et l'état de chaque connexion
(écoute, time-wait,...).

102 [Link]

mercredi 17 octobre 2012

 Groupe udp

• 4 compteurs renseignent sur le

nombre de datagramme UDP
envoyés, reçus, en erreur, ...
•la table gère la liste des applications
utilisant UDP ainsi que le port
correspondant

103 [Link]

mercredi 17 octobre 2012

 Groupe egp

•gère le protocole egp (External

gateway protocol)(routage des
paquets entre routeurs). on a le
nombre de paquets entrants,
sortants, en erreur, la table des
routeurs adjacents, des infos sur les
routeurs...

104 [Link]

mercredi 17 octobre 2012

 Groupe transmission

•Contient :
•type Object Identifier ::={transmission
number}
•qui permet d'identifier le type de media utilisé
pour la transmission.
•Par exempte : dot3 (7) décrit le média
Ethernet, tandis que dot5 (9) décrit Token-ring.

105 [Link]

mercredi 17 octobre 2012

 Groupe snmp

•requis pour chaque entité mettant en œuvre le protocole SNMP.

•contient le nombre de message SNMP entrants et sortants,
•le nombre de mauvaises versions reçues ou de nom de communauté
invalide,
•la répartition du type de requêtes reçues et envoyées (get, get_next,
set et trap)

106 [Link]

mercredi 17 octobre 2012

MIB Privée : Exemples

PRIVATE ENTERPRISE NUMBERS

Codes:Prefix:[Link] ([Link].4.1)
0 Reserved Joyce K. Reynolds jkrey@[Link]
1 NxNetworks Michael Kellen [Link]@[Link]
2 IBM Bob Moore remoore@[Link]
3 Carnegie Mellon Mark Poepping host-master@[Link]
4 Unix Keith Sklower sklower@[Link]
5 ACC Art Berggreen art@[Link]
6 TWG John Lunny jlunny@[Link]
7 CAYMAN Beth Miaoulis beth@[Link]
8 PSI Marty Schoffstahl schoff@[Link]
9 ciscoSystems Dave Jones davej@[Link]
10 NSC John Lyman lyman@[Link]
11 Hewlett-Packard Harry Lynch [Link]@[Link]
12 Epilogue Karl Auerbach karl@[Link]
…

[Link]

107 [Link]

mercredi 17 octobre 2012

MIB Privée

ibmResearch
2
Directory
1
ibm6611
IBM ibmAgent
Mgmt 2
Internet 2 3
2
1 Netwiev/6000SubAgent
Experim. 3
Entreprise CISCO ibmProd
3
1 9 6
Private
H.P.
4 2 11

DEC
36

SUN
42
108 [Link]

mercredi 17 octobre 2012

 Principe
L’administration et l’ISO
L’administration et TCP/IP
Etude de SNMP
Abstract Syntax Notation Number 1
Management Information Base

109 [Link]

mercredi 17 octobre 2012