M3108 Cours

Module M3108
Supervision des réseaux

IUT de Villetaneuse
Département Réseaux et Télécommunications
Année 2019-2020
http://www.lipn.univ-paris13.fr/~evangelista/cours/M3108
Contenu du module 2/60
M3108 — Supervision des réseaux

http://www.lipn.univ-paris13.fr/~evangelista/cours/M3108
I Volume horaire :
I 2×3h de Cours/TDs
I 5×3h de TPs
I 1h + 2h de contrôles
I Évaluation :
I TPs notés
I 2 contrôles
Plan 3/60
1. Introduction à la supervision des réseaux
2. SNMP : protocole de supervision
3. Éléments de qualité de service et de statistiques

Supervision des réseaux — Une définition 4/60
Ensemble des techniques permettant de s’assurer

du bon fonctionnement des éléments d’un réseau.
I superviser ⇔ surveiller
I tâche dévolue à l’administrateur du réseau
I éléments d’un réseau :
I switchs, routeurs
I ordinateurs
I imprimantes
I services (HTTP, FTP, DHCP, . . . )
...
I En gros, tout équipement qui a une @IP (plus éventuellement un port).
Pourquoi superviser ? 5/60
I Assurer la continuité des services.

I Détecter les pannes pour remettre les équipements en service
I Mesurer les performances du réseau
I Assurer une qualité de service
I Analyser le trafic (reporting)
I Détecter/prévenir les attaques (voir module de sécurité en S4)
Exemples d’application de la supervision 6/60
1. Surveillance d’un serveur de mail

I Un processus vérifie périodiquement l’état du disque dur du serveur de mail.
I espace disque libre < 1Go ⇒ il envoie un mail aux utilisateurs pour leur
demander de faire le ménage dans leurs mails
2. Surveillance d’une imprimante
I Toutes les 10 sec. on envoie un ping à une imprimante.
I 5 pings successifs négatifs ⇒ mail envoyé à l’administrateur
3. Blocage d’un attaquant
I Sur la passerelle d’accès au réseau on journalise les tentatives de connexion
SSH.
I Un processus inspecte périodiquement le journal.
I Il bloque les @IP (via l’ajout d’une règle de pare-feu) qui apparaissent trop
fréquemment (p.ex., plus de 100 tentatives de connexion en une minute).
4. Prévision du trafic
I On enregistre dans une base de données les dates des requêtes envoyées au
serveur Web.
I On peut ensuite en extraire des statistiques pour prévoir les pics d’affluence.
Comment superviser ? 7/60
I Outils généralistes
I ping
I traceroute
I iperf
I netstat
I wireshark
...
I Protocoles de supervision
I CMIP (Common Information Management Protocol)
I normalisé par l’OSI, peu utilisé
I SNMP? (Simple Network Management Protocol)
I simple à mettre en œuvre ⇒ très répandu
I Outils dédiés
I Nagios?
I Centreon
I Zabbix
...
? : vu dans ce module
Avant la supervision 8/60
I La surveillance est utilisée une fois le réseau déployé.

I D’autres techniques doivent être utilisées en amont, par exemple :
I Sauvegardes
I Ex : copier périodiquement les données d’un serveur NFS sur un autre serveur.
I Répartition de charges (load balancing)
I principe : un répartiteur redistribue les requêtes sur un ensemble de serveurs
requêtes HTTP
répartiteur
I Redondance des équipements

I principe : doubler les équipements
S1 S2 Si S1 tombe en panne,
S2 prend le relai.
Un outil de supervision : Nagios 9/60
https://www.nagios.com/
I logiciel libre
I première version en 1996
I 2 composants :
I un moteur qui exécute périodiquement des tâches de supervision ;
I et une interface web pour visualiser les résultats collectés par le moteur.
I quelques fonctionnalités importantes :
I possibilité de superviser
I des équipements (p.ex., vérifier qu’une machine répond au pings)
I des services (p.ex., vérifier qu’apache est actif sur un PC)
I des ressources (espace disque, charge du processeur, . . . )
I cartographie du réseau
I mise en places d’alerte (envoi de mail/SMS en cas de problème)
I possibilité de développer des plugins réalisant des tâches de supervision
I plusieurs forks : icinga, shinken, naemon
Plus de détails en TP.
Interface web de Nagios 10/60
Vue en temps réel des services disponibles ou à l’arrêt.
Source : https://fr.wikipedia.org/wiki/Nagios, consultée le 31/08/2018.

Plan 11/60

Plan 12/60

2.1 Introduction à SNMP
2.2 Les MIBs
2.3 La boı̂te à outils net-snmp
2.4 Structure des messages SNMP
2.5 De SNMPv1 à SNMPv3
Présentation de SNMP 13/60
I SNMP = Simple Network Management Protocol

I protocole défini par l’IETF
I 3 versions définies dans différentes RFCs :
v1 RFCs 1065–1067 (1988) — toujours utilisée
v2c RFCs 1441–1452 (1993) — version la plus répandue
(Plusieurs v2 ont été définies : v2u, v2p, . . . v2c est celle utilisée
actuellement.)
v3 RFC 3410 (2002)
I SNMP s’appuie sur UDP.
I Ports utilisés :
I 161 pour les requêtes et réponses
I 162 pour les traps
I Dans ce cours, on se basera sur la v2c.
(cf. section 2.5 pour une description des différences entre les trois versions)
Terminologie 14/60
I SNMP fait intervenir :

I un NMS (Network Management System) — la plate-forme de supervision ;
I et des agents — processus s’exécutant sur les équipements supervisés.
I Chaque agent a en mémoire un ensemble d’objets qui peuvent être
lus/modifiés par le NMS.
I Ces objets donnent des informations sur l’état de l’équipement sur lequel
s’exécute l’agent et peuvent être utilisés pour sa supervision.
I Ils forment une MIB : une Management Information Base.
I Les objets de cette MIB sont décrits dans le langage SMI (cf. les exemples
dans la suite).
SMI = Structure of Management Information
I Exemples d’objets :
I états des interfaces réseau (activée/désactivée)
I température interne
I espace disque libre
L’architecture SNMP 15/60
NMS
MIB MIB MIB

agent agent agent
SNMP est mis en œuvre sur la plupart des équipements réseau (routeurs,
switchs, . . . ) et systèmes d’exploitation.
Les opérations SNMP 16/60
I les requêtes
requête
NMS Agent
réponse
I permet de lire/modifier la (les) valeur(s) d’un (de plusieurs) objet(s)
I les notifications (ou traps)
notification
NMS Agent
I permet de prévenir le NMS d’un événement particulier

Exemple : l’OS va s’arrêter.
I pas d’acquittement
I les informs
inform
NMS Agent
acquittement
I notification avec acquittement
Les requêtes SNMP 17/60
I getRequest
récupère la valeur d’un (de plusieurs) objet(s)
I setRequest
modifie la valeur d’un (de plusieurs) objet(s)
I getNextRequest
récupère la valeur de l’objet suivant dans la MIB
I getBulkRequest
récupère les valeurs d’un groupe d’objets consécutifs de la MIB
Les communautés SNMP 18/60
I Une communauté désigne un ensemble d’agents/NMS auxquels sont

associés des droits.
I communauté ≈ mot de passe
I Trois types de droits sont associés à une communauté :
I readOnly — droit en lecture sur les objets de la MIB
I readWrite — droit en lecture/écriture sur les objets de la MIB
I trap — droit d’envoyer des traps
I Une communauté peut avoir accès à certaines parties de la MIB et pas à
d’autres.
I La communauté est présente dans tous les messages SNMP.
I L’échange se fait en clair (non chiffré) sur le réseau.
⇒ En voyant passer des messages SNMP on peut découvrir les
communautés.
⇒ à changer régulièrement
Plan 19/60

2.2 Les MIBs
Structure des MIBs 20/60
I MIB = base de données d’objets présente sur un équipement supervisé par

un agent SNMP
I Les MIBs ont une structure arborescente.
I Cette structure est normalisée (en partie) et extensible (en partie).
I Un objet est un nœud de l’arbre.
I Chaque objet a
I un nom symbolique (unique dans tout l’arbre) ;
I et un numéro.
I Pour désigner un objet dans l’arbre on peut utiliser son nom ou son OID.
I OID d’un objet O = liste des numéros des objets sur le chemin de la racine
à O séparés par des ’.’
I Les agents ne possèdent pas tous la même MIB !
Représentation d’une MIB 21/60
racine
ccitt iso iso - ccitt

0 1 2
org
3
dod
6
internet
1
directory mgmt experimental private

1 2 3 4
mib-2 enterprises
1 1
system interfaces ip ibm cisco nokia

1 2 4 1 9 94
OID = 1.3.6.1.2.1.1
La branche mib-2 22/60
mib-2
1.3.6.1.2.1
system interfaces ip icmp tcp udp snmp

1 2 4 5 6 7 11
branche normalisée et présente sur tous les agents SNMP (en théorie !)
I system (1.3.6.1.2.1.1)
informations générales sur l’équipement sur lequel se trouve l’agent
I interfaces (1.3.6.1.2.1.2)
informations sur les interfaces réseau (ex : statuts des interfaces)
I ip (1.3.6.1.2.1.4)
informations sur la pile IP (ex : contenu de la table de routage)
I tcp (1.3.6.1.2.1.6), udp (1.3.6.1.2.1.7), snmp (1.3.6.1.2.1.11)
statistiques TCP, UDP et SNMP (ex : connexions TCP ouvertes)
La branche system 23/60
system
1.3.6.1.2.1.1
sysDescr sysUpTime sysContact sysName sysLocation sysServices

1 3 4 5 6 7
I sysDescr (1.3.6.1.2.1.1.1)
description textuelle
I sysUpTime (1.3.6.1.2.1.1.3)
1
temps (exprimé en 100 de sec.) depuis lequel l’équipement est en marche
I sysContact (1.3.6.1.2.1.1.4)
adresse mail de l’administrateur de l’équipement
I sysName (1.3.6.1.2.1.1.5)
nom de l’équipement
I sysLocation (1.3.6.1.2.1.1.6)
emplacement physique de l’équipement
I sysServices (1.3.6.1.2.1.1.7)
services rendus par l’équipement
La branche enterprises 24/60
enterprises
1.3.6.1.4.1
ibm cisco novell sun snmpResearch intel

2 9 23 42 99 343
I Branche dans laquelle les entreprises peuvent insérer des objets spécifiques
à leurs équipements.
I Chaque objet fils de enterprises est géré par la compagnie correspondante.
I Ces MIBs sont dites privées.
La branche snmpTraps 25/60
snmpTraps
1.3.6.1.6.3.1.1.5
coldStart warmStart linkDown linkUp authenticationFailure

1 2 3 4 5
branche contenant la définition des notifications SNMPv2c standard

(Les notifications sont aussi définies comme des objets de la MIB.)
I coldStart (1.3.6.1.6.3.1.1.5.1)
redémarrage de l’agent
I warmStart (1.3.6.1.6.3.1.1.5.2)
redémarrage de l’agent sans changement de configuration
I linkDown (1.3.6.1.6.3.1.1.5.3)
interface désactivée
I linkUp (1.3.6.1.6.3.1.1.5.4)
interface activée
I authenticationFailure (1.3.6.1.6.3.1.1.5.5)
pb. d’authentification (p.ex., requête reçue avec une mauvaise communauté)
Le langage de description SMI — Exemple 1 26/60
Définition de l’objet system.

iso OBJECT IDENTIFIER ::= { 1 }
org OBJECT IDENTIFIER ::= { iso 3 }
dod OBJECT IDENTIFIER ::= { org 6 }
internet OBJECT IDENTIFIER ::= { dod 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
system OBJECT IDENTIFIER ::= { mib-2 1 }
Définition de l’objet sysUpTime, fils n°3 de l’objet system.

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-i nitializ ed ."
::= { system 3 }
Définition de l’objet sysContact, fils n°4 de l’objet system.

sysContact OBJECT−TYPE
SYNTAX DisplayString ( SIZE (0..255) )
ACCESS read-write
STATUS mandatory
DESCRIPTION
" The textual i dentifi cation of the contact person
for this managed node , together with information
on how to contact this person ."
::= { system 4 }
Définition de la notification coldStart, fils n°1 de l’objet snmpTraps.

coldStart NOTIFICATION−TYPE
STATUS current
DESCRIPTION
" A coldStart trap signifies that the SNMP entity ,
supporting a notification originator application , is
rein itializi ng itself and that its configuration may
have been altered ."
::= { snmpTraps 1 }
Plan 30/60

2.2 Les MIBs
Présentation de net-snmp 31/60
I boite à outils linux permettant d’effectuer des opérations SNMP

I principales commandes :
I snmpset, snmpget, snmpgetnext et snmpbulkget : envoi de requêtes
I snmptrap : envoi de notifications
I snmpinform : envoi de informs
I snmpwalk et snmpbulkwalk : exploration d’une branche de la MIB
I Options requises par toutes les commandes :
I -v V
version de SNMP utilisée (V = 1, 2c ou 3)
I -c COMMUNAUTE
communauté utilisée
Utilisation de snmpset et snmpget 32/60
Pour récupérer la valeur de sysName :

$ snmpget - v2c - cpublic localhost . 1 . 3 . 6 . 1 . 2 . 1 . 1 . 5 . 0
SNMPv2 - MIB :: sysName .0 = STRING : localhost . localdomain
Pour modifier sa valeur :

$ snmpset - v2c - cprivate localhost . 1 . 3 . 6 . 1 . 2 . 1 . 1 . 5 . 0 s " pc - de - sami "
SNMPv2 - MIB :: sysName .0 = STRING : pc - de - sami
La valeur de certains objets n’est pas modifiable (p.ex., sysDescr) :

$ snmpset - v2c - cprivate localhost . 1 . 3 . 6 . 1 . 2 . 1 . 1 . 1 . 0 s " pc - de - sami "
Error in packet .
Reason : notWritable ( That object does not support modification )
Failed object : SNMPv2 - MIB :: sysDescr .0
On peut aussi récupérer (ou modifier) plusieurs objets avec une seule requête.
$ snmpget - v2c - cpublic localhost . 1 . 3 . 6 . 1 . 2 . 1 . 1 . 4 . 0 . 1 . 3 . 6 . 1 . 2 . 1 . 1 . 6 . 0
SNMPv2 - MIB :: sysContact .0 = STRING : sami . e v a n g e l i s t a@ i u t v . univ - paris13 . f
SNMPv2 - MIB :: sysLocation .0 = STRING : IUTV ( O108 )
Utilisation de snmpgetnext et snmpwalk 33/60
Avec un getNextRequest, on récupère l’objet suivant dans la MIB (via un

parcours de l’arbre) :
$ snmpgetnext - v2c - cpublic - On localhost .1.3.6.1
.1.3.6.1.2.1.1.1.0 = STRING : Linux localhost . localdomain 4.17.19 -200. fc
$ snmpgetnext - v2c - cpublic - On localhost . 1 . 3 . 6 . 1 . 2 . 1 . 1 . 3 . 0
.1.3.6.1.2.1.1.4.0 = STRING : sami . e v a n g e l i s t a @ i u t v . univ - paris13 . fr
snmpwalk permet de retrouver tous les objets dont l’OID est prefixé par un
OID donné en argument :
$ snmpwalk - v2c - cpublic localhost .1.3 .6.1.2.1 .1
. 1 . 3 . 6 . 1 . 2 . 1 . 1 . 1 . 0 = STRING : Linux localhost . localdomain 4.17.19 -200. fc
. 1 . 3 . 6 . 1 . 2 . 1 . 1 . 2 . 0 = OID : . 1 . 3 . 6 . 1 . 4 . 1 . 8 0 7 2 . 3 . 2 . 1 0
. 1 . 3 . 6 . 1 . 2 . 1 . 1 . 3 . 0 = Timeticks : (661096) 1:50:10.96
. 1 . 3 . 6 . 1 . 2 . 1 . 1 . 4 . 0 = STRING : sami . e v a n g e l i s t a @ i u t v . univ - paris13 . fr
. 1 . 3 . 6 . 1 . 2 . 1 . 1 . 5 . 0 = STRING : pc - de - sami
...
Plan 34/60

2.2 Les MIBs
Le schéma d’encodage TLV 35/60
I schéma d’encodage utilisé pour tous les messages SNMP

I Tout champ est décomposé en trois parties :
Type Length Value
1 o. 1 o. N o.
I Type (1 o.) = type du champ (code normalisé)
I Length (1 o.) = nb. d’octets dans la partie Value
I Value (N o.) = valeur réelle du champ
Les types primitifs 36/60
I type primitif ⇔ Le champ Value ne peut pas être redécomposé en

sous-champs.
Type Code hexadécimal
Integer 0x02
String 0x04
Null 0x05
OID 0x06
IpAddress 0x40
Counter 0x41
Gauge 0x42
TimeTicks 0x43
Exemples
I 02 01 04 = un entier (02) codé sur un octet (01) et valant 4
I 04 02 79 6F = une chaı̂ne de caractères (04) de deux (02) octets valant
“yo” (79 6F en ASCII)
Les types composite 37/60
I type composite ⇔ Le champ Value est une suite de sous-champs

(eux-mêmes encodés en TLV).
Type Code hexadécimal
sequence 0x30
getRequest 0xA0
getNextRequest 0xA1
response 0xA2
setRequest 0xA3
getBulkRequest 0xA5
informRequest 0xA6
trap 0xA7
I Le contenu d’un message est donc encodé en TLV.
Exemple
I 30 07 02 01 04 04 02 79 6F = une séquence (30) de 7 octets
contenant l’entier 4 et la chaı̂ne de caractères “yo”
Encodage des OIDs 38/60
Règle de codage des 2 premiers nombres de l’OID

I Les deux premiers nombres x.y d’un OID sont codés sur 1 octet valant
40x + y .
I Exemples : la valeur de l’OID 1.3.4.5 sera : 2B 04 05
I 2B = 2 × 16 + 11 = 43 = 40 × 1 + 3
Règle de codage des grands nombres (> 127)

I Problème : comment coder 400 dans un OID ?
I 400 est codé sur deux octets : 01 90 en hexadécimal.
I Or 01 90 pourrait être interprété comme deux nombres : 1.144.
I Solution utilisée :
I Seuls les 7 bits de poids faible sont utilisés pour coder les nombres.
I Le 8ème bit (de poids fort) restant vaut
I 0 si l’octet est le dernier apparaissant dans le nombre
I 1 si l’octet suivant fait aussi partie du nombre.
I Exemple : 400 = 11 00100002
⇒ 400 sera codé 10000011 00010000 en binaire, soit 83 10 en hexa.
Structure générique 39/60
I Les messages SNMP ont tous la même structure.

I Tous les champs sont encodés selon le schéma TLV.
I Un message est encodé comme une séquence (au sens TLV) de 3 éléments.
sequence
Version Community PDU
I Version = 0 pour SNMPv1, 1 pour SNMPv2c, 3 pour SNMPv3

I Community = chaı̂ne de caractères contenant la communauté.
I PDU = contenu du message
Le PDU SNMP 40/60
I Structure du PDU identique quel que soit le type du message.

I On utilise les types composite getRequest, setRequest, . . . pour déterminer
le type du message.
getRequest, setRequest, . . .
RequestID ErrorCode ErrorIndex VariableList
I RequestID = identifiant de requête

I choisi aléatoirement par l’émetteur de la requête
I et recopié dans la réponse
I ErrorCode = code d’erreur
I toujours à 0 (pas d’erreur) dans une requête
I ErrorIndex = numéro de l’OID dans VariableList qui a causé l’erreur (si
ErrorCode 6= 0)
I VariableList = séquence de couples (OID, valeur)
Encodage de la liste d’objets 41/60
I Un message SNMP contient toujours une liste (séquence) d’OIDs avec

leurs valeurs.
I Chaque couple (OID, valeur) est lui-même encodé comme une séquence.
sequence
sequence sequence
OID1 Value1 . . . OIDn Valuen
Valeurs associées aux objets envoyés

I Dans les requêtes set, les valeurs sont celles que la requête tente d’affecter
aux objets.
I Dans les requêtes get, les valeurs sont toujours vides (type Null).
I Dans les réponses (qu’elle que soit la requête envoyée) les valeurs sont
celles des objets de la requête (après modification dans le cas d’un set).
Codes d’erreur 42/60
0x00 pas d’erreur

0x01 réponse trop longue pour être transportée
0x02 objet demandé non présent dans la MIB
0x03 le type de la donnée demandée ne correspond pas à celui de la
MIB
0x04 tentative de modification d’une variable accessible en lecture
seule
0x05 erreur générale
0x06 accès non authorisé
Exemple de message getRequest 43/60
I message getRequest envoyé par la commande :

$ snmpget - v2c - ccommRO 192.16 8.15.10 0 \
1.3.6.1.2.1.1.4.0 \
1.3.6.1.2.1.1.6.0
I getRequest ⇒ Les objets apparaissant dans le message ont la valeur Null.

Exemple de message setRequest 44/60
I message setRequest envoyé par la commande :

$ snmpset - v2c - ccommRW 192.16 8.15.10 0 \
1 . 3 . 6 . 1 . 2 . 1 . 1 . 4 . 0 s admin@ici . fr \
1 . 3 . 6 . 1 . 2 . 1 . 1 . 6 . 0 s IUTV
Encodage des notifications 45/60
I Quand un agent envoie une notification, la liste d’objets contient toujours :

I objet n°1 : OID = 1.3.6.1.2.1.1.3 (sysUpTime)
temps depuis lequel l’équipement est en marche
I objet n°2 : OID = 1.3.6.1.6.3.1.1.4.1 (snmpTrapOID)
OID de la notification envoyée
I L’agent peut aussi placer dans la notification d’autres objets pouvant
donner des informations utiles au NMS.
Par exemple :
I sysName pour avoir le nom de l’équipement
I sysContact pour avoir l’adresse éléctronique de l’administrateur
I nom de l’interface désactivée dans le cas d’une notification linkDown
Exemple de notification 46/60
I 1er objet : (sysUpTime, 625508)

⇒ équipement démarré depuis 625508 centièmes de seconde
I 2ème objet : (snmpTrapOID, 1.3.6.1.6.3.1.1.5.3)
⇒ notification de type linkDown (1.3.6.1.6.3.1.1.5.3, voir diapo 25).
⇒ notification envoyée suite à la désactivation d’une interface réseau
Plan 47/60

2.2 Les MIBs
Différences entre SNMPv1 et SNMPv2c 48/60
I nouveau type de requête : getBulkRequest

I Avec la v1, pour récupérer plusieurs objets consécutifs de la MIB : plusieurs
getNextRequest consécutifs (⇒ nombreux aller-retours).
I Un getBulkRequest permet d’en demander plusieurs en même temps.
I nouveau type de message : inform
I possibilité de communiquer entre NMS
I structure des messages de notification simplifiée
Pas de modifications importantes entre la v1 et la v2c.
Différences entre SNMPv2c et SNMPv3 49/60
I Architecture peer-to-peer
I plus de NMS et d’agents
I que des entités SNMP
I une entité = le noyau SNMP + des applications (envoi/réception de
notifications, envoi/réception de commandes, . . . )
I Mécanismes de sécurité ajoutés
I authentification
I chiffrement des données
Plan 50/60

Qualité de service (QoS) — Une définition 51/60
Capacité d’un réseau à véhiculer des flux dans de bonnes conditions.
I flux = séquence de paquets d’une source vers une destination

I Critères de QoS : fiabilité, délai, gigue, bande passante.
Critères de QoS 52/60
Soit un flux entre deux points A et B du réseau.

Fiabilité
I Taux d’erreur tolérable du flux.
Délai (ou latence)

I Temps mis par un paquet pour traverser le réseau de A à B.
I Principales causes :
I temps de traversée des équipements (routeurs)
I temps de propagation (élevé pour les réseaux longues distances)
Gigue
I Variation dans les délais d’acheminement.
I utilisation de la variance statistique
I gigue = 0 ⇔ délai d’acheminement constant
Bande passante
I Débit max. de bout en bout entre A et B.
Exigences de QoS selon le type d’application 53/60
Application Fiabilité Délai Gigue BP

Mail Haute Faible Faible Faible
FTP Haute Faible Faible Moyenne
Web Haute Moyenne Faible Moyenne
VoIP Faible Haute Haute Faible
Conf. vidéo Faible Haute Haute Haute
Le SLA (Service Level Agreement) 54/60
I Contrat passé entre

I un fournisseur de service (p.ex., un fournisseur d’accès à Internet)
I et un client (p.ex., une entreprise)
et définissant
I le type de service fourni
I et les exigences de QoS attendues.
I Les exigences de QoS peuvent être fournies sous forme de métriques.
Par exemple :
I Bande passante garantie de 100 Mb/s.
I Taux de perte de paquets < 0.001.
I Délai max de bout en bout < 100ms.
...
Les métriques IPPM 55/60
I IPPM = IP Performance Measurement

I Groupe de l’IETF chargé de la définition
I de métriques réseau pour les réseaux IP ;
I et de méthodes de calcul de ces métriques.
I Quelques métriques :
I RFC 2679 : A One-way Delay Metric for IPPM
mesure du délai d’acheminement
I RFC 2680 : A One-way Packet Loss Metric for IPPM
mesure du taux de perte (dans un seul sens)
I RFC 2681 : A Round-trip Delay Metric for IPPM
mesure du délai aller-retour
Fonctions statistiques — Moyenne, variance et écart-type 56/60
Une série statistique X est une suite de valeurs X1 , . . . , Xn .

Moyenne
n
1X
X = Xi
n
i=1
Variance
n
1X
V (X ) = (Xi − X )2
n
i=1
(moyenne des carrés des écarts à la moyenne)

Écart-type p
σ(X ) = V (X )
Moyenne mobile de coefficient α
X α = X n,α avec X n,α = α × Xn + (1 − α) × X n−1,α
(moyenne pondérée avec un coeff. de α pour Xn , α × (1 − α) pour Xn−1 ,

α × (1 − α)2 pour Xn−2 , . . . )
Fonctions statistiques — Percentiles 57/60
Soit X = X1 , . . . , Xn une série statistique.

I EDF (Empirical Distribution Function) mesure la proportion des valeurs de
la série inférieures ou égales à un y donné.
nb de valeurs dans la série ≤ y
F (y ) =
n
I I ème percentile = plus petite valeur xi de la série telle que F (xi ) ≥ I %.
Exemple
I Soit X = 1, 4, −5, 12, −7, 5, 4, 22
I On a :
y -20 -5 4 6 20 100
1 5 3
F (y ) 0 4 8 4 1 1
I 25ème percentile de X = −5
I 50ème percentile de X = 4
Définition des métriques IPPM 58/60
I La plupart des métriques IPPM sont dépendantes du type de paquet.

I protocole de transport
I ports source et destination
I taille du paquet
I Quand une métrique est spécifique à un type de paquet, son nom est
préfixé par typePaquet.
⇒ Le nom de la métrique est alors typePaquet-metrique.
I Lors de la réalisation d’une mesure on doit préciser le type de paquet utilisé.
Par exemple : typePaquet → TCP-src1550-dst80-size800
(paquet TCP de 800 octets envoyé du port 1550 au port 80)
Exemple de métrique IPPM — Le One-Way-Delay (1/2) 59/60
One-Way-Delay = délai dans un seul sens

I Le One-Way-Delay donne une indication plus fine que le Round-Trip-Delay
(délai aller-retour).
I Possibilité de routage asymètrique.
I Pour de nombreuses applications (p.ex., streaming multimedia), on
s’intéresse au délai dans un seul sens.
I Mesure le temps passé par le paquet sur le réseau :
source
destination
one-way-delay
I Nécessite une synchronisation des horloges (via GPS, par exemple).

Exemple de métrique IPPM — Le One-Way-Delay (2/2) 60/60
Quelques métriques One-Way-Delay

I typePaquet-One-Way-Delay(Src, Dst, T)
delai entre Src et Dst pour un paquet émis à l’instant T
I typePaquet-One-way-Delay-Percentile(T, I)
Ième percentile d’une série de délais T
I typePaquet-One-Way-Delay-Inverse-Percentile(T, S)
pourcentage des valeurs de la série T dont la valeur est ≤ au seuil S
Exemple
Soit une série de délais observés
T = 100ms, 90ms, 150ms, 80ms, 130ms, 120ms.
I typePaquet-One-Way-Delay-Percentile(T,50) = 100ms
I typePaquet-One-Way-Delay-Inverse-Percentile(T,90ms) = 33.3%

M3108 Cours

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

M3108 Cours

Transféré par

Droits d'auteur :

Formats disponibles

Module M3108

Supervision des réseaux

M3108 — Supervision des réseaux

1. Introduction à la supervision des réseaux

2. SNMP : protocole de supervision

3. Éléments de qualité de service et de statistiques

Ensemble des techniques permettant de s’assurer

I Assurer la continuité des services.

1. Surveillance d’un serveur de mail

I La surveillance est utilisée une fois le réseau déployé.

I Redondance des équipements

Vue en temps réel des services disponibles ou à l’arrêt.

Source : https://fr.wikipedia.org/wiki/Nagios, consultée le 31/08/2018.

1. Introduction à la supervision des réseaux

2. SNMP : protocole de supervision

3. Éléments de qualité de service et de statistiques

2. SNMP : protocole de supervision

I SNMP = Simple Network Management Protocol

I SNMP fait intervenir :

MIB MIB MIB

I permet de prévenir le NMS d’un événement particulier

I Une communauté désigne un ensemble d’agents/NMS auxquels sont

2. SNMP : protocole de supervision

I MIB = base de données d’objets présente sur un équipement supervisé par

ccitt iso iso - ccitt

directory mgmt experimental private

system interfaces ip ibm cisco nokia

system interfaces ip icmp tcp udp snmp

sysDescr sysUpTime sysContact sysName sysLocation sysServices

ibm cisco novell sun snmpResearch intel

coldStart warmStart linkDown linkUp authenticationFailure

branche contenant la définition des notifications SNMPv2c standard

Définition de l’objet system.

Définition de l’objet sysUpTime, fils n°3 de l’objet system.

Définition de l’objet sysContact, fils n°4 de l’objet system.

Définition de la notification coldStart, fils n°1 de l’objet snmpTraps.

2. SNMP : protocole de supervision

I boite à outils linux permettant d’effectuer des opérations SNMP

Pour récupérer la valeur de sysName :

Pour modifier sa valeur :

La valeur de certains objets n’est pas modifiable (p.ex., sysDescr) :

Avec un getNextRequest, on récupère l’objet suivant dans la MIB (via un

2. SNMP : protocole de supervision

I schéma d’encodage utilisé pour tous les messages SNMP

I type primitif ⇔ Le champ Value ne peut pas être redécomposé en

I type composite ⇔ Le champ Value est une suite de sous-champs

I Le contenu d’un message est donc encodé en TLV.

Règle de codage des 2 premiers nombres de l’OID

Règle de codage des grands nombres (> 127)

I Les messages SNMP ont tous la même structure.

I Version = 0 pour SNMPv1, 1 pour SNMPv2c, 3 pour SNMPv3

I Structure du PDU identique quel que soit le type du message.

I RequestID = identifiant de requête

I Un message SNMP contient toujours une liste (séquence) d’OIDs avec

Valeurs associées aux objets envoyés

0x00 pas d’erreur

I message getRequest envoyé par la commande :

I getRequest ⇒ Les objets apparaissant dans le message ont la valeur Null.

I message setRequest envoyé par la commande :

I Quand un agent envoie une notification, la liste d’objets contient toujours :

I 1er objet : (sysUpTime, 625508)

2. SNMP : protocole de supervision

I nouveau type de requête : getBulkRequest