Protocoles d’application réseaux

Stéphane Kouamo

[email protected]

Ecole Nationale Supérieure des Postes, des Télécommunications et des

Techniques de l’Information

Yaoundé – Cameroun
OBJECTIFS DU COURS

 OBJECTIFS GENERAUX
Amener l’apprenant à se familiariser avec :
o
 Les protocoles de communication réseaux
 Les protocoles de gestion du réseau selon les modèles OSI et TCP/IP
 Un environnement de développement des outils de gestion du réseau.
 OBJECTIFS SPECIFIQUES
o Rappeler à l’apprenant les concepts fondamentaux de fonctionnement d’un réseau
informatique ;
o Rappeler les notions de la gestion d’un réseau informatique;
o Imprégner l’apprenant sur les spécificités des protocoles de gestion du réseau ;
o Imprégner l’apprenant sur la configuration des protocoles de gestion de réseau;
o Présenter les différentes versions des protocoles de gestion réseau.

 PREREQUIS :
o Avoir des connaissances basiques sur la configuration des réseaux informatiques (LAN et
WAN) ; connaitre le matériel de base utilisé pour mettre en place un réseau informatique ;
avoir des notions sur les protocoles réseaux des différentes couches.

DEBOUCHES

 Différents secteurs d’activités où l’apprenant peut être employé :

o La téléphonie mobile ou fixe, le développement d’application, transport aérien, la gestion
tramways, le domaine de l’économie nouvelle, la banque, système de gestion des données, etc.
 Listes d’entreprises, organismes nationaux ou internationaux :
o Téléphonie mobile/fixe : Camtel, Mtn, Orange, Nexttel ;
o Développement d’application : Ubisoft, Philips (Douala), Vodafone, etc.;
o Transport aérien : ASECNA, Camair-Co
o Gestion des tramways: Camrail, Sobeltra, CamTrade, Sitracel ;
o Economie nouvelle : DSX (bourse de Douala, etc.), Beac ;
o Banque : Bicec, SCB, SGBC, Afriland First Bank, CCA, Ecobank, Banque Atlantique, UBA,
etc.

1
 o Système de Gestion des données issues d’une collecte : INS, MINADER, MINEPIA,
BUCREP, etc.

APPROCHE PEDAGOGIQUE

 Méthodologie
o Cours magistraux dictés et écrits ;
o Séance de travaux dirigés (5 séances de 2h chacune) ;
o Séance de travaux pratiques (3séances de 2h chacune)
 Supports
o Pas de support de cours.

2
PLAN DU COURS (Table de matières)

PARTIE THEORIQUE

CHAPITRE I : Rappel sur la gestion des réseaux informatiques

 Généralités
 Typologie des réseaux
 Composition d’un réseau informatique
 Gestion d’un réseau informatique.
CHAPITRE II : Protocoles pour la gestion des réseaux dans le modèle OSI

 Généralités
 Architecture et Caractéristiques des protocoles dans le modèle OSI;
 Modèle d’architecture;
 Modèle d’information;
 Modèle fonctionnel ;
 CMIS/CMIP ;
CHAPITRE III : Protocoles pour la gestion des réseaux dans le modèle TCP/IP

 Généralités (concepts fondamentaux)

 Architecture des protocoles dans le modèle TCP/IP;
 Modèle d’information;
 Description du protocole SNMP;
 Sécurité dans les versions de SNMP.

3
Introduction

Les réseaux informatiques ont aujourd'hui autant d'importance que les ordinateurs eux
mêmes, au point que la plupart de nos activités ne pourraient plus être envisagées sans
la mise en place de ces réseaux. On assiste à leur déploiement à tous les niveaux de la
société, dans les entreprises, au niveau national et international, y compris dans les
domiciles des usagers. Quant aux entreprises, ces réseaux leur apportent un moyen
efficace pour mettre en œuvre un travail coopératif, pour faire communiquer des
ordinateurs distants, pour partager des données, mais aussi pour imprimer à distance,
envoyer des messages, et accéder à des bases de données délocalisées.

Le réseau n'est pas une entité statique. Il subit des évolutions. Son évolution a mis en jeu
bien des aspects technologiques. On peut même parler de mutation au vu des progrès
fulgurants qu'il a enregistrés depuis ces débuts. A savoir les matériels d'infrastructure
réseaux (commutateur, répétiteur, routeur, modem, serveur etc.) ont de capacité de
traitement importante et offrent des fonctionnalités de plus en plus complexes. Le débit,
qui permet de caractériser la rapidité avec laquelle on communique au travers du
réseau, est passé d'un facteur de 1 à un facteur de millions de millions (gigabits). Une
autre évolution importante tient à la transformation de réseau physique câblé en un
réseau sans fils potentiellement présent n'importe où dans le monde, y compris dans les
endroits les plus reculés où il n'existe pas d'infrastructure physique. Cette évolution
concerne également le type d'information véhiculé. Alors qu'à ses débuts, le réseau était
principalement utilisé pour transmettre du texte ou des données, grâce aux nouvelles
vitesses de transmission et aux nouvelles techniques de codage, il se transforme peu à
peu en réseau multimédia capable de faire transiter, en plus des données, de la voix, et
de la vidéo. Cette capacité va ouvrir de nouvelles perspectives notamment en termes
d'applications interactives voix-données. C'est ce développement que l'on observe
actuellement avec les nouvelles normes de réseaux mobiles telles que les cas chez nous
aujourd'hui le réseau GPRS avec les sociétés de télécommunication en place.

L'évolution de réseau dont nous venons de parler pose un problème majeur : la manière
dont ceux-ci sont pratiquement gérés. En effet, avec la multiplication des machines qui
ne cessent d'être fabriquent des jours aux jours, la complexification des architectures
qui s'en suivent, et leur possible éclatement géographique, il devient évidement difficile
de gérer un réseau.

A cette difficulté s'ajoute aussi le problème d'hétérogénéité des technologies sous-

jacentes et celle d'offrir une vu unifiée du réseau à l'administrateur et, d'autre part, la
distribution et la grande quantité d'informations à collecter et à traiter.

Une autre contrainte de la gestion est la dépendance de service : Les activités des
entreprises deviennent aussi dépendantes du fonctionnement de ce moyen de
communication. Aussi est-il donc crucial que les services de communications du réseau
soient disponibles en permanence. Les éventuels dysfonctionnements ou pannes doivent
être détectés le plus rapidement possible et traités dans un délai compatible avec les
activités de l'entreprise. C'est en cette activité de surveillance du réseau et des services
qu'il offre que consiste, précisément, la gestion de réseau. Cette dernière couvre
différentes tâches qui doivent être réalisées dans des échelles de temps plus ou moins
importantes. Les cinq activités principalement reconnues en sont la gestion de la
configuration, la gestion des fautes, la gestion des performances, la gestion de la sécurité
4
et enfin la gestion des comptabilités. Ces activités peuvent être plus ou moins
importantes selon l'activité de l'entité qui met en place le réseau.

Nous l'avons dit précédemment, le matériel d'infrastructure réseau est de plus en plus
sophistiqué et permet d'être contrôlé en distance : c'est là un des points fondamentaux
de la gestion réseau, il est aujourd'hui nécessaire, étant donné l'étendue et la complexité
des réseaux, de pouvoir le gérer à distance depuis son poste de travail et n'avoir qu'à se
déplacer qu'en derniers recours, lors qu'une opération physique est nécessaire.

Comme son nom l'indique le protocole SNMP, simple network management protocole
(protocole de gestion de réseau simplifié) que nous allons étudier plus en détails au
cours de ce travail à pour rôle exclusif la gestion de réseau, il à été développé pour
apporter des moyens simple d'administration en distance aux administrateurs.

Le but de cette étude consistera dans un premier temps de comprendre le principe de ce

protocole, son fonctionnement, et son apport dans la tâche de l'administration et dans le
second temps, exploiter le langage de programmation java pour implémenter une
application de gestion de réseau basé sur ce protocole.

Notre motivation n'est pas de donner aux lecteurs de ce présent travail une liste en tous
points exhaustive d'informations sur tous les concepts, toutes les architectures et plates-
formes existant dans la gestion de réseau (nombre de publications y pourvoient : livres,
articles, normes, etc.), mais un ensemble d'informations techniques à partir desquelles le
lecteur, qu'il soit étudiant, technicien, ingénieur, administrateur réseau ou architecte
réseau, puisse rapidement comprendre le concept de base du protocole SNMP et cela au
travers une application informatique concret.

Pour l'élaboration de ce présent travail, nous avons procédé d'abord par une lecture
approfondie des ouvrages de référence à la matière en vue de bien assimiler le concept
théorique de base qui régit l'administration réseau, le protocole SNMP et la
programmation en java. Mais aussi par des entretiens réguliers avec les professionnels
qualifier à la matière et nos différents encadreurs.

Ce travail comporte 3 chapitres brièvement décrits comme suivent :

 Le chapitre 1 est une introduction aux concepts de base de la gestion de réseau ; il

permet de comprendre les enjeux stratégiques de la gestion et de se familiariser
avec ses activités. Il présente une méthode qui permet à l'administrateur réseau
de concevoir une architecture de gestion.
 Le chapitre 2 décrit le protocole SNMP. Il explique le fonctionnement, les
différentes composantes d'une architecture de gestion basée sur SNMP et montre
les échanges entre la station de gestion et les agents SNMP à des fins de
surveillance.
 Le chapitre 3 traite l'implémentation de l'application en java. Il montre pas à pas
comment ont peut mettre au point une application de gestion en se base sur le
protocole SNMP en java.

5
Chap. 1 : Rappel sur la gestion des réseaux informatiques

La gestion de réseau est la tâche quotidienne de tout administrateur réseau. Il s'agit

entre autre d'assurer le suivi du réseau, de définir des procédures et de les faire
connaître aux utilisateurs, de gérer les mots de passe, de prendre en charge le suivi des
sauvegardes et résoudre les éventuels incidents qui peuvent survenir. Au-delà, anticipé
les évolutions technologiques et intégrer de nouveaux outils de gestions. Vérifier le
fonctionnement optimal de chaque matériel, paramétrer celui-ci, ou de le mettre à jour
régulièrement. Ainsi, dans les réseaux informatiques d'aujourd'hui, la gestion est un
problème de tous les jours. Le recours à des techniques d'administration efficace est
important pour une bonne gestion économique des moyens de communication dont on
dispose, mais aussi pour avoir une vue d'ensemble des équipements et des systèmes de
communication utilisés par l'entreprise. C'est à niveau qu'intervient l'administration
réseau.

L'administration réseau met en œuvre des moyens humains, techniques, et financières

de contrôle, de coordination et de surveillance des diverses ressources mise en œuvre
en respectant les contraintes de coûts et de qualité. Avec objectif, de maintenir le service
et de permettre l'évolution du système.

I.2 Ressource à gérer

Plusieurs niveaux de gestion doivent être distingués, dont il est nécessaire de

comprendre l'utilité. Un bon critère de différenciation peut être appliqué à partir des
éléments constitutifs du réseau, soit des équipements réseau, des ordinateurs, des
logiciels, ou des utilisateurs. À titre d'exemple :

 La gestion de l'infrastructure réseau : elle concerne la gestion de tous les

éléments du réseau et des logiciels embarqués qui constituent les différents
réseaux de l'entreprise. On désigne par élément du réseau chacun des
équipements qui sont branchés au réseau, ainsi que les logiciels y résidant. Les
routeurs, les concentrateurs, les répéteurs, les passerelles, les modems, la
connectivité, sont les éléments qui constituent l'infrastructure du réseau.
 La gestion des ordinateurs : elle concerne tous les aspects relatifs à la gestion des
points d'accès au réseau. Elle englobe la gestion des stations terminales, ainsi que
de tous les logiciels supportés par ces stations : système d'exploitation réseau, les
applications et les services de communication mis à la disposition des usagers.

L'administrateur réseau est celui qui est chargé, de la lourde tâche de s'occuper du
réseau. Son travail regroupe beaucoup de chose. A cet égard l'ISO (International
standard organization) l'organe habileté à standardiser les normes de réseau à définit
l'étendue du travail d'administration est à retenue cinq domaine fonctionnels de gestion
suivant :

 La gestion des configurations

 La gestion des fautes
 La gestion de performances
 La gestion des sécurités
 La gestion des coûts ou la gestion des comptabilités

6
I.3.1 La gestion de la configuration

La gestion de la configuration permet de désigner et de paramétrer différents objets.

Une configuration peut être faite manuellement par un opérateur (via l'interface
graphique) ou par téléchargement complet (lors d'une réinitialisation d'un équipement
par exemple).

Procédure

Les procédures requises pour gérer une configuration sont :

 La collecte d'informations ;
 Le contrôle de l'état du système ;
 Et enfin la sauvegarde de l'état dans un historique.

Figure 1-1 Gestion de la configuration

La gestion de la configuration couvre l'ensemble des fonctionnalités suivantes :

Démarrage, initialisation des équipements ;

 Positionnement des paramètres ;

 Cueillette des informations d'état et intervention dans les paramètres ;
 Modification de la configuration du système ;
 Association des noms aux objets gérés ;
 Changement de l'adresse IP d'une machine ;
7
  Changement de l'adresse IP d'un routeur ;
 Changement de la table de routage.

I.3.2 La gestion des fautes

Ce domaine recouvre la détection, l'isolement et la correction des pannes survenant sur

un équipement. L'action curative qui en découle peut être faite à distance (si
l'équipement répond) ou par un contact humain qui agira sur l'équipement. Un
historique des évènements est également disponible

Figure 1-2 Gestion des fautes

Type de panne

Les pannes peuvent être d’origine interne, à caractère permanent (composant en

pannes) ou externes (goulets d'étranglement, trafic intense, etc.), Cette dernière est plus
difficile à détecter, car elle est à caractère aléatoire.

La gestion de faute couvre l'ensemble des fonctionnalités suivantes :

 La détection des fautes : elle comprend la préparation de rapports d'incidents de

fonctionnement, la gestion de compteurs ou des seuils d'alarme, le filtrage
d'événements par filtrage en amont des informations, l'affichage des
dysfonctionnements.
 La localisation : on y procède au moyen de rapports d'alarme, de mesures et de
tests.

8
  La réparation : elle consiste à prendre les mesures correctives (réaffectation de
ressources, routages, limitation du trafic par filtrage, maintenance), ou encore à
rétablir le service (tests de fonctionnement, gestion de systèmes de secours, etc.).
 L'enregistrement des historiques d'incidents et statistiques : la gestion des fautes
ne peut se limiter à ces actions ponctuelles, nécessaires mais insuffisantes pour
donner le service attendu.

C'est la raison pour laquelle elle comporte aussi, d'une part, l'enregistrement
d'historiques d'incidents et la compilation de statistiques qui peuvent porter sur la
probabilité des pannes, leur durée, les délais de réparation et, d'autre part, un rôle
d'interface avec les usagers qui consiste à les informer des problèmes réseau et à leur
donner la possibilité de signaler eux-mêmes des incidents telle que :

 La déconnexion d'un câble ;

 Une mauvaise configuration d'un équipement ;
 Une interface défectueuse d'un routeur ;
 La réinitialisation accidentelle

I.3.3 La gestion de la performance

Ce domaine comprend la collecte des données et l'analyse statistique permettant la

création de tableaux de bord. Ce domaine est essentiellement lié à l'évolution du réseau
(permet de planifier les changements à apporter afin d'améliorer les performances du
réseau).

L'objectif est d'établir des statistiques à partir des paramètres du réseau.

 Débit ;
 Temps de réponse ;

9
  Taux d'erreur ;
 Temps d'établissement des connexions
 Elle fournit des fonctions qui permettent à des fins de planification des
ressources du réseau :
 De recueillir des données statistiques (taux d'erreurs, temps de transit, débit,
etc.) ;
 De maintenir et analyser des journaux sur l'historique de l'état du système
(événements). Les informations obtenues serviront à l'analyse et à la
planification du réseau. On peut diviser cette partie en deux : l'une traitant de la
gestion de la performance en temps réel et l'autre en temps différé. Pour gérer la
performance d'un réseau en temps réel, il faut mettre en place les fonctionnalités
suivantes :
 Enregistrements des mesures de performance : cela passe par l'établissement et
la mise à jour des critères et des conditions de mesure, la gestion de la collecte
d'informations, le filtrage, la compilation de statistiques, l'adoption de mesures à
la demande ou encore la gestion des fichiers de collecte.
 Surveillance de l'activité du réseau par visualisation de l'utilisation des
ressources, le signalement des dépassements de seuils et l'analyse de la
performance : cela implique une visualisation du fonctionnement du réseau (avec
comme variables pertinentes par exemple la répartition de la charge, les
différents débits, les temps de réponse ou encore la disponibilité) et une analyse
des causes possibles de dépassement de seuil par corrélation avec les pannes
d'équipements, au moyen de divers indicateurs.
 Changement de configuration proactive et réactive : le fait de gérer la
performance en temps réel suppose que l'on soit capable de prendre des mesures
correctives (ou réactives) et préventives (ou proactives). La gestion réactive vise
à établir lors de la détection d'un problème de performance des mesures de
réaffectation des ressources par modification des paramètres de configuration ou
par redistribution du trafic. Ces mesures, de par leurs natures, sont prises afin de
répondre à un problème déjà existant. La gestion proactive consiste à prendre
des mesures initiales permettant d'éviter d'arriver à une situation critique. Cette
tâche est effectuée en temps différé et comporte quant à elle un ensemble de
sous-tâches :

· L'analyse des informations par la compilation de statistiques, d'historiques ou encore

d'indicateurs de qualité du service ;

· L'édition de tableaux de bord et de rapports, qu'ils soient périodiques ou qu'ils soient

effectués à la demande ;

· Une certaine forme d'analyse prévisionnelle par la constitution de matrices de trafic,

par la détection de risques de saturation ou d'engorgement, par des simulations de
scénarios, par le suivi de la gestion corrective, et enfin par la planification et le
dimensionnement du réseau.

Exemples

 Relevé des pertes de connexions entre deux routeurs.

 Relevé des temps de réponse entre deux sites.

10
I.3.4 La gestion de la comptabilité

La gestion de la comptabilité permet de connaître les charges des objets gérés, les coûts
de communication, etc. Cette évaluation est établie en fonction du volume et de la durée
de la transmission.

Figure 1-4 Gestion de la Comptabilité

Elle couvre l'ensemble des fonctionnalités suivantes :

 les mesures sur l'utilisation des ressources, et leur enregistrement en vue

d'obtenir des historiques ;
 le contrôle des quotas par utilisateur en faisant des mises à jour des
consommations courantes et en vérifiant les autorisations de consommation ;
 le suivi et le contrôle des dépenses par stockage et mise à jour des tarifs des
opérateurs, par gestion des tickets de taxation, par évaluation en temps réel de la
consommation courante, par vérification des factures, et enfin par suivi des coûts
d'exploitation et de matériels (investissement, amortissement et maintenance) ;

 La gestion financière : bien évidemment, on retrouve dans la gestion comptable

une
 Partie financière qui consiste à ventiler les coûts (par service, par utilisateur ou
encore par application), à analyser et prévoir les dépenses et enfin à étudier les
possibilités de réduction des coûts ;

11
  La facturation : finalement, l'activité de gestion comptable aboutit à une
facturation interne, ce qui implique la gestion des clients et des trafics, la
production de tickets de taxation et de factures, le contrôle de la facturation et
enfin le stockage des historiques.

Exemples

Coût d'utilisation d'un réseau RNIS.

I.3.5 La gestion de la sécurité

La gestion de la sécurité est une fonction de gestion qui concerne le contrôle et la

distribution des informations utilisées pour la sécurité. Elle englobe le cryptage et la
liste des droits d'accès.

Figure 1-4 Gestion de la Sécurité

À l'appui des politiques de réseau, la gestion de réseau consiste à collecter les

informations de gestion et à les interpréter. Voici les fonctionnalités qui doivent être
mises en œuvre :

 Dans ce contexte, il faut dans un premier temps assurer la sécurité relative à

l'administration de réseau elle-même, c'est-à-dire gérer les droits d'accès aux
postes de travail, gérer les droits liés aux attentes des opérateurs, et enfin les
autorisations d'accès aux informations de gestion.
12
  Ensuite, il faut garantir la sécurité des accès au réseau géré ; pour cela, il faut
mettre en place des mécanismes qui impliquent des fonctions telles que la
définition des conditions d'utilisation, l'activation ou la désactivation des
mécanismes, la modification de certains paramètres ou encore la gestion des
listes d'autorisation (aux machines, à différents services ou à divers éléments de
réseau) ; il faut évidemment en outre effectuer un contrôle des accès (identités,
horaires, temps de connexion, destination) et une détection des tentatives d'accès
frauduleuses (enregistrement, compilation de statistiques et déclenchement
d'alarmes si nécessaire).
 Enfin, il faut garantir la sécurité de l'information par la gestion de mécanismes de
protection, de cryptage et de décryptage, et par la détection d'incidents et de
tentatives de fraude. Voici les fonctions de gestion de sécurité qui doivent être
mises en œuvre pour supporter cette activité :

 Soutien à l'authentification.
 Contrôle et maintenance des autorisations.
 Contrôle et maintenance des commandes d'accès.
 Gestion des clés.
 Maintenance et examen des fichiers de sécurité.

Exemples

 Détection d'intrusions.
 Détection d'une attaque par IP Flooding.
 Détection de virus.

1.4 Organisation d'une administration

Il existe différents types de décision d'administration :

 Décisions opérationnelles : décision à court terme, concernant l'administration au

jour le jour et opérations temps réel sur le système ;
 Décisions tactiques : décision à moyen terme concernant, l'évolution du réseau et
l'application des politiques de long terme ;
 Décisions stratégiques : décision de long terme concernant les stratégies pour le
futur en exprimant les nouveaux besoins et désirs des utilisateurs.
 Ces types déterminent différents niveaux d'administration:
 Le contrôle opérationnel réseau pour les décisions Opérationnelles
 La gestion réseau pour les décisions tactiques
 L'analyse de réseau pour les décisions tactiques et stratégiques
 La planification pour les décisions stratégiques

1.5 Les systèmes de gestion de réseau

Un système de gestion réseau est une collection d'outils pour contrôler et gérer le réseau
qui comprend :

 Une interface pour opérateur avec un ensemble de commandes pour exécuter la

plupart des tâches d'administration de réseaux.
 Un minimum d'équipements supplémentaire intégré au système existant
13
I.6 Modèle de gestion

La mise en œuvre de la gestion se fait à travers le modèle d'administration suivante :

 Le modèle Informationnel ;
 Le modèle Organisationnel ;
 Le modèle Fonctionnel ;
 Le modèle de communication.
 L'administration dans le réseau IP utilise seulement deux modèles à savoir :
 Le modèle Informationnel
 Le modèle de communication.

Le modèle Informationnel

Il permet de définir les objets administrés (nom, fonction, relations et attributs divers).
La base de données ainsi constituée est appelée MIB. Cette base est organisée de
manière hiérarchique sous forme d'arbre. La description des objets dans la MIB est faite
en utilisant la syntaxe ASN1 (Abstract Syntax Notation one).

Le modèle de communication

Ce modèle sous entend, un protocole dédié aux échanges de gestion, des messages de
commandes/réponse et des messages de notification.

I.7 Principe général d'administration

Sur le point de l'administration, un système de réseau informatique se compos d'un

ensemble d'objets qu'un système d'administration surveille et contrôle. Chaque objet est
géré localement par un processus appelé agent qui transmet régulièrement ou sur
sollicitation les informations de gestion relatives à son état et aux événements qui le
concernent au système d'administration.

Le système d'administration comprend un processus (manager ou gérant) qui peut

accéder aux informations de gestion de la MIB locale via un protocole d'administration
qui le met en relation avec les divers agents.

Le principe se repose donc sur les échanges :

 D'une part, entre une base d'informations appelée MIB (Management Information
Base) et l'ensemble des éléments administrés (objets) ;
 D'autre part, entre les éléments administrés et le système d'administration.

14
Figure 1-5 processus agent/gérant

I.8 Architecture d'administration

L'architecture classique d'administration la plus utilisée est le modèle Gérant/ Agent

(Manager/Agent).comme nous l'avons montré dans le principe d'administration. Le
système est composé d'une entité d'administration et des entités de gestion (NME) qui
sont géré par cette entité et un protocole pour la gestion

Chaque entité dans le réseau a un Agent pour l'opération de gestion, une base de
données stockées dans MIB et assume les travaux ci-dessous :

Collecter des informations statistiques concernant à la communication, les opérations de

réseau.

Stocker les informations localement dans les MIBs Répondre les commandes de l'entité
de contrôle de réseau, inclus : Transmet des informations statistiques à l'entité
d'administration de réseau, modifie les paramètres, donne des informations d'état...

L'entité d'administration a une entité de gestion (NME) et aussi un logiciel pour gérer le
réseau appelé NMA (Network Management Application). NMA contient une interface
permettant l'administrateur fait des opérations de gestion.

15
Ou :
NMA : Network Management Application
NME : Network Management Entity
Appl : Application
Comm : Communication Software
OS : Operating System

Conclusion

Ce chapitre nous a permis de présenter les concepts de base de la gestion de réseau pour
aider l'administrateur dans sa tâche de conception d'un système de gestion optimal en
fonction des objectifs de l'entreprise. Le chapitre suivant sera consacré à l'étude du
protocole SNMP qui est une solution de gestion envisagé dans cette étude.

16
Chapitre II : Protocoles pour la gestion des réseaux dans le modèle OSI

Protocole de l'information de gestion commune (CMIP) est un protocole d'OSI utilisé

avec les services d'information de gestion commune (CMIS), supporte l’échange de
l'information entre les applications de gestion de réseau et les agents de gestion. CMIS
définit un système des services d'information de gestion de réseau. CMIP supporte une
interface qui fournit les fonctions qui peut être utilisé à supporter pour le modèle OSI.
Les spécifications de CMIP pour des réseaux de TCP/IP s'appellent CMOT (CMIP au-
dessus de TCP) et la version pour IEEE 802 LAN s'appelle CMOL (CMIP au-dessus de
LLC). On propose CMIP/CMIS en tant que protocole de concurrence à SNMP dans la suite
de TCP/IP.
CMIP n'indique pas la fonctionnalité de l'application de gestion de réseau, il définit
seulement le mécanisme d'échange de l'information des objets contrôlés et n’indique
pas comment l'information doit être employée ou interprétée.
Le protocole CMIP pour le modèle OSI se base sur trois modèles suivants:
- Modèle d’architecture MSA (Managed System and Agents) qui définit
l’architecture de la gestion du protocole CMIP et la notion de systèmes gérés et
gérants.
- Modèle d’information qui définit le modèle de représentation des l informations
de gestion,
- Modèle fonctionnel SMFA (Specific Management Function Area) qui définit des
domaines fonctionnels d’administration et leurs relations.

2.1. Modèle d’architecture

Ce modèle définit une structure en couches comprenant trois activités de gestion :

 La gestion système (Systems-Management),
 La gestion de couches (Layer Management),
 La gestion d’opérations de couche (Layer Operation).

Le modèle repose essentiellement sur les échanges des informations de gestion

concernant les ressources (objets gérés) du réseau entre système au niveau de la couche
application (gestion système) via un protocole de gestion système SMP (System
Management Protocol).
La couche application du modèle OSI est constituée d’un ensemble de processus
applicatifs AP qui regroupe des éléments nécessaires à son bon déroulement,
notamment le processus SMAP (System Management Application Process) qui prend en
charge la gestion du système. On distingue deux types de processus applicatifs : Le
gérant (manager) sur les systèmes d’administration et l’agent sur les systèmes
administrés. L’entité d’application SMAE (Application Entity) est l’élément qui prend en
charge la gestion de la communication pour le processus applicatifs SMAP en faisant
quatre éléments de services d’application (ASE, Application Service Element), en
particulier CMIS (Common Management Information Service).

Il s’agit de faire remonter toutes les informations de gestion concernant une ressource
(routeur, pont, commutateur, protocole,…) gérée par un processus agent dans le SMAP
(System Management Application Process). Et ce, par l’intermédiaire du SMAE (System
Management Application Entity). Le transfert d’information vers le processus gérant est
17
assuré par un ensemble de primitives d’accès aux informations défini par CMIS via le
protocole CMIP (Common Management Information Protocol).

Le modèle repose aussi sur les échanges horizontaux entre couches d’éléments
administrés différents (gestion de couches) soit via le protocole de gestion de réseau
CMIP en utilisant un protocole OSI classique pour le transfert d’information spécifique à
la couche

2.2. Modèle d’information

2.2.1 Concept d’objet

Dans le protocole CMIP, toutes les informations gérées sont organisées comme des
objets. Au niveau le plus fondamental, chaque objet administré peut inclure :
• Des Attributs : que contiennent les valeurs décrivant l'état de l'objet, ou les objets
contenus cette par référence.
• Des comportements : représenter les types de comportement que l'objet contrôlé
montrera. Ceci est actuellement exprimé en directives pour la définition des
objets contrôlés comme texte. Le dispositif contrôlé mettra en application
typiquement ceci de la façon appropriée à son rôle dans le système.
• Actions : les services sont fournis par l'objet contrôlé qui peut être activé sur la
demande du système de gestion.
• Avis : messages qui peuvent être lancés par l'objet contrôlé sur l'occurrence des
événements critiques de système.
• Paquets : collections d'attributs, de comportements, d'actions, et d'avis qui
peuvent être groupés dans une ou plusieurs caractéristiques contrôlées de classe
d'objet.

18
2.2.2 Concept d’organisation

Comme dans n'importe quel système intensif de données, l'information doit être
maintenue dans un certain schéma avec lequel les utilisateurs (typiquement systèmes
de gestion) peuvent accéder à l'information. Dans le schéma de gestion d'OSI, il y a trois
types de rapports entre les objets contrôlés, incluant :
• Arbre d’héritage: définit la classe contrôlée d'objet superbe et des sous-classes,
comme C++, les classes dérivées sont reliées. Quand une classe est héritée d'une
classe superbe, elle possède toutes les caractéristiques de la superbe-classe, avec
les attributs, les comportements et les actions additionnels.
• L'arbre de contenance: définit les objets qui sont contenu dans d'autres objets
contrôlés. Par exemple, un sous-réseau peut contenir plusieurs éléments
administrés.
• L’arbre de Nomination : définit la manière dans laquelle différents objets sont mis
en référence dans les contraintes de l'architecture de gestion.
•
Comme dans le cas d'autres systèmes orientés, l’héritage fournit une capacité de définir
l'information générale et commune dans les classes basses, et définissent des
comportements et des attributs plus spécifiques dans les classes dérivées. Par exemple,
une connexion multipoints peut ajouter l'information décrivant les points spécifiques de
connexion étant incluse dans la connexion.

2.2.3 Structure des informations d’administration

En complément du standard MIB qui définit les informations spécifiques

d’administration réseaux et leur signification, un standard séparé spécifie l’ensemble
des règles utilisées pour définir et identifier les variables MIB. Ce sont les règles de
gestion des informations d’administration, SMI (Structure of Management Information).
Pour que le protocole d’administration de réseaux reste simple, SMI pose des
restrictions sur les types de variables autorisées dans la MIB, spécifie les règles de
nommage de ces variables et crée les règles de définition des types de variables.

Par exemple: SMI comprend des définitions de termes comme IpAddress (défini comme
une chaîne de 4 octets) et Counter (entier appartenant à l’intervalle [0 ; 232-1] et indique
que ce sont les termes utilisés pour définir les variables MIB. De plus, SMI décrit la façon
dont la MIB référence les tables de valeurs (les tables de routage IP, par exemple).

Définitions formelles utilisant ASN.1

Le standard SMI indique que toutes les variables MIB doivent être définies et
référencées à l’aide de la notation ISO de syntaxe abstraite ASN.1 (Abstract Syntax
Notation 1). ASN.1 est un langage formel qui présente 2 caractéristiques principales: une
notation utilisée dans les documents manipulés par les humains et une représentation
codée et concise de la même information, utilisée dans les protocoles de communication.
Dans les 2 cas, la notation formelle élimine toutes les ambiguïtés possibles, tant du point
de vue de la représentation que de la signification. Au lieu de dire par exemple, qu’une
variable contient une valeur entière, un concepteur qui utilise ASN.1 doit définir la
forme exacte et le domaine des valeurs prises par cet entier.
19
Les messages

Le format et la longueur des messages CMIP sont variables et relativement complexes.

On utilise ASN.1 pour décrire la structure des messages CMIP. Voici un exemple
d’utilisation d’ASN.1 décrivant la structure d’une trame Ethernet :

Ethernet-Frame::= SEQUENCE
{
destAddr OCTET STRING (SIZE(6)),
srcAddr OCTET STRING (SIZE(6)),
etherType INTEGER (1501..65535),
data ANY (SIZE(46-1500)),
crc OCTET STRING (SIZE(4))
}

Dans ce cas, il sert à attribuer à la variable de gauche la définition du membre de droite.

SEQUENCE représente une liste ordonnée d’éléments. Cette liste ordonnée contient les
champs d’une trame Ethernet, notamment l’adresse de destination, l’adresse source, le
type d’Ethernet, les données et le CRC.
Le type d’un champ est spécifié à la suite du nom. Par exemple, destAddr et srcAddr sont
déclarés comme étant de type OCTET STRING, définissant une variable de 0 ou plusieurs
octets. La valeur de chaque octet est comprise entre 0 et 255. La taille de la chaîne
obtenue est placée après la déclaration de la chaîne OCTET STRING. Ethertype est défini
en tant que INTEGER, à savoir une valeur entière de taille et de précision arbitraire. Le
(1501..65535) situé juste après permet de définir sa plage de valeur. Le champ de
donnée est de type ANY et sa taille varie de 46 à 1500 octets. En utilisant la notation
ASN.1.
Les messages SNMP prennent le format suivant :

SNMP-message::= SEQUENCE
{
version INTEGER {version-1(1)},
community OCTET STRING,
data ANY
}

2.3. Modèle fonctionnel

L’OSI a regroupé les activités d’administration en cinq groupes fonctionnels :

• La gestion des anomalies ( Fault Management) dont l’objectif est le diagnostic
rapide de toute défaillance interne ou externe du système, tout
dysfonctionnement (panne d’un routeur) ;
• La gestion de la configuration (Configuration Management), consiste à identifier
de manière unique chaque objet administré par un nom ou un identificateur
d’objet (OID, Object Identifier). Il s’agit également de gérer la configuration
matérielle et logicielle et de préciser la localisation géographique.

20
 • La gestion des performances (Performance Management) consiste à contrôler, à
évaluer la performance et l’efficacité des ressources, à savoir le temps de
réponse, le débit, le taux d’erreur par bit, la disponibilité (aptitude à écouler du
trafic et à répondre aux besoins de communication pour lequel la ressource a été
mise en service).
• La gestion de la sécurité (Security Management) concerne le contrôle d’accès au
réseau, la confidentialité des données qui y transitent, leur intégrité et leur
authentification (l’entité participant à la communication est bien celle qui a été
éclairée).
• La gestion de la comptabilité (Accounting Management) consiste à gérer la
consommation réseau par abonné, de relever les informations permettant
d’évaluer les coûts de communication. La comptabilité est établie en fonction du
volume et de la durée des transmissions.

2.4. CMIS/CMIP

CMIS/CMIP est au cœur du modèle d’administration OSI en mettant en œuvre les

demandes d’informations nécessaires à l’administration d’un réseau. CMIS définit un
système de services de communication d’informations de gestion fournissant les
moyens d’échanger des informations entre un processus gérant et un processus agent, et
entre entités d’application SMAE ( System Management Application Entity) de processus
agents différents via le protocole CMIP. CMIP définit le mécanisme permettant
d’effectuer les échanges des informations de gestion.

CMIS définit plusieurs services dont :

• Des services de demande d’un gérant à un agent pour la création (M-CREATE) ou
la destruction (M-DELETE) d’informations concernant des objets de gestion,
signalisation faite par un agent à un gérant par rapport aux changements d’état
d’un objet (M-EVENT-REPORT), mettre à jour une information (M-SET), obtenir
une valeur (M-GET).
• Des services concernant les mises en relation entre SMAE pour l’échange
d’informations notamment l’initialisation (M-INITIALIZE), la fermeture
MTERMINATE).
• Des services d’annulation (M-ABORT)…

21
CHAPITRE III : Protocoles pour la gestion des réseaux dans le modèle
TCP/IP

SNMP (Simple Network Management Protocol) a été défini par l'IETF (Internet
Engineering Task Force) en 1989. Depuis, il est devenu un standard pour la gestion de
réseaux. Il permet de faciliter l'échange d'information d'administration entre différentes
entités d'un réseau pour disposer d'une cartographie du réseau, fournir un inventaire
précis de chaque entité, gérer les Performances, détecter et résoudre des problèmes.

II.2 Présentation du protocole

SNMP est un protocole de la famille TCP/IP (Transport control prototcol, Internet

protocol), Etant un protocole Internet, il est compatible à toutes plateformes
hétérogènes et est installé sur la plupart des matériels réseaux tels que routeurs et
commutateurs et peut donc être utilisé sur tous les réseaux de type Internet. Il exploite
les capacités du protocole de transport UDP :

 Chaque trame possède une adresse source et une adresse destination qui permet
aux protocoles de niveaux supérieurs comme SNMP de pouvoir adresser leurs
requêtes.
 Le protocole UDP peut utiliser un checksum optionnel qui couvre l'en-tête et les
données de la trame. En cas d'erreur, la trame UDP reçue est ignorée : gage de
fiabilité.

Le protocole UDP fonctionne en mode non connecté, c'est-à-dire qu'il n'existe pas de lien
persistant entre la station d'administration et l'agent administré. Cela oblige les deux
parties à s'assurer que leurs messages sont bien arrivés à destination, ce qui apporte
également un important gage de fiabilité pour la gestion réseau.

Deux ports sont désignés pour l'utilisation de SNMP :

 Port 161 pour les requêtes à un agent SNMP.

 Port 162 pour l'écoute des alarmes destinées à la station d'administration.

Cette technologie se situe entre la couche 4 (Transport) et la couche 7 (application)

Figure 2-1 Le snmp dans la hiérarchie des couches iso.

22
Les Proxy

L'utilisation de SNMP nécessite que tous les agents supportent un protocole commun, tel
que UDP et IP, ce qui va limiter l'utilisation à certaines machines en excluant les PC et les
stations de travail, ces dernières pouvant implémenter TCP/IP mais pour lesquelles il
serait indésirable d'ajouter SNMP.
Pour résoudre ce problème, le concept de proxy a été développé. Ces proxies suppléent
les machines inadaptées car ils connaissent les objets de la MIB nécessaires pour la
gestion du système mandaté. La communication entre le proxy et la machine suppléée
ne peuvent pas utiliser SNMP pour dialoguer et il faut donc, pour le proxy, s'adapter aux
protocoles connus par la seconde machine, c'est ce qui est illustré par la figure ci-
dessous

Fig : Gestion des machines ne supportant pas SNMP.

Les systèmes de gestion de réseau (network management systems : NMS)

SNMP a été créé pour être une couche utilisant TCP/IP à un niveau supérieur. Le
protocole d'administration opère en accord avec UDP (User Datagram Protocol) et IP. A
chaque action de la station d'administration, le processus de contrôle accède à la MIB et
avertit l'utilisateur par l'intermédiaire d'une interface graphique.

23
Chaque agent administratif doit lui aussi implémenter SNMP et UDP/IP afin de pouvoir
interpréter les requêtes qui permettent à la machine d'administration d'accéder sa MIB.
SNMP étant relié à UDP qui est un protocole sans connexion, il est lui aussi sans
connexion, c'est pourquoi les connexions entre station d'administration et agents
administratifs ne sont jamais maintenues.

II.3 Les composants de base de SNMP

Un réseau administré par SNMP dispose de trois composants clé : les dispositifs
administrés, les agents et les systèmes d'administration réseau (NMS, Network
Management System).

• Un dispositif administré est un nœud réseau qui contient un agent SNMP et qui
réside sur un réseau administré. Les dispositifs administrés collectent et
conservent des informations d'administration, et rendent ces informations
disponibles aux NMS à l'aide de SNMP. Les dispositifs administrés, parfois
appelés « éléments réseau », peuvent être des routeurs, des serveurs d'accès, des
commutateurs, des ponts, des hubs, des hôtes ordinateurs ou des imprimantes.
• Un agent est un module logiciel d'administration réseau qui réside sur un
dispositif administré. Un agent possède une connaissance locale des informations
d'administration et traduit celle-ci en un format compatible avec SNMP.
• Un NMS Les systèmes de gestion de réseau (network management system notés
NMS): C'est-à-dire une console au travers de laquelle les administrateurs peuvent
réaliser des tâches d'administration, exécutent des applications qui surveillent et
contrôlent des dispositifs administrés. Un NMS fournit l'essentiel des ressources
de traitement et mémoires nécessaires à l'administration réseau. Il doit y avoir
un ou plusieurs NMS sur un réseau administré.

SNMP est un protocole d'administration distribuée. Un système peut opérer soit comme
un NMS, soit comme un agent, ou les deux à la fois. Lorsqu'un système fonctionne
comme NMS et agent, un autre NMS est susceptible d'exiger que le système interroge
des dispositifs administrés qui fournissent un résumé des informations apprises ou
rapportent les informations d'administration conservées en local.

Figure : schéma de gestion de réseau avec snmp

24
II.4 Les opérations

Le protocole SNMP supporte trois types de requêtes : GET, SET et TRAP. Il utilise alors
les opérations suivantes pour la gestion du réseau :

GetRequest : Cette requête permet aux stations de gestion (manager) d'interroger les
objets gérés et les variables de la MIB des agents. La valeur de l'entrée de la MIB (nom)
est passée en paramètre. Elle permet d'accéder à une variable précise.

GetNextRequest : Cette requête permet aux stations de gestion de recevoir le contenu de

l'instance qui suit l'objet nommé (passé en paramètre) dans la MIB. Cette commande
permet en particulier aux stations de gestion de balayer les tables des MIB. Elle permet
d'accéder à plusieurs variables simultanément.

GetResponse: A chaque envoie d'un message à l'exception de TRAP, un message de

réponse est retourné. Ils ont chacun une signification bien distincte :

GET-response : tout s'est bien passé, l'information est transmise.

NoSuchObject' : aucune variable n'a été trouvée.

NoAccess : vous ne disposez pas des bons droits d'accès.

Figure : Requête snmp

Une requête SNMP est construite de la façon suivante :

V: version SNMP (v1, v2, v3)

C : type de communauté (public ou private)
D : donnée (requête: GET, GET_NEXT, TRAP ...)

Communauté

Un agent SNMP est plus ou moins finement paramétrable, suivant le système. Il est
possible, par exemple de créer des groupes de sécurité qui auront accès en lecture seule,

25
d'autres en lecture/écriture, d'autres encore en lecture seule, mais sur certaines
branches seulement...

Chaque groupe devra disposer d'une sorte de mot de passe, appelé "community". En
général, la communauté "public" est celle qui a le droit de lecture sur les informations
non sensibles.

Nous avons donc des informations à consulter, des paramètres à modifier et des alarmes
à émettre. Tout cela, en principe, de façon indépendante du matériel et du logiciel. Il faut
donc que SNMP permette de retrouver ces informations et d'agir sur les paramètres.
Pour cela SNMP utilise le Mib.

II.5 Structure SMI (Structure Of Management Information)

La structure SMI décrit les règles de description de l'information et permet d'identifier

de façon unique un objet de la MIB géré par un agent SNMP. Chaque objet possède donc
un identificateur unique ou OID (Object ID).

SMI s'intéresse aussi à la représentation des données (et leur type) pour chaque objet de
la MIB. Un objet de la MIB est déclaré et défini en langage ASN.1 (Abstract Syntax
Notation 1 : langage de représentation de donnée).

SNMP n'utilise qu'une petite partie du langage ASN.1. Au niveau des types, seuls
quelques uns sont utilisés comme :

 INTEGER : valeur entière sur 32 bits en complément à 2.

 OCTET STRING : chaîne de caractères.
 IpAddress : adresse IP.
 PhysAddress : adresse MAC (6 octets pour un réseau de type Ethernet).
 Counter : entier de 32 bits non signé qui s'accroît de 0 à (2exp32 -1) puis revient
à 0.
 TimeTicks : compteur de temps sur 32 bits non signé en 1/100 de s.

II.6 La structure de données MIB

La MIB est une base de données gérée par un agent SNMP regroupant les objets gérés en
respectant les règles SMI. Elle possède une structure d'arbre similaire à celui employé
dans le DNS (Domain Name System). On retrouve une racine non nommée à partir de
laquelle on référencie de façon absolue un objet par son OID (nœud de l'arbre).

Un objet administré (parfois appelé un objet MIB, un objet ou une MIB) est l'une des
nombreuses caractéristiques possibles d'un dispositif administré. Des objets
administrés sont composés d'une ou plusieurs instances d'objets, lesquelles sont
essentiellement des variables.

Il existe deux types d'objets administrés : scalaire et tabulaire. Des objets scalaires
définissent une seule instance d'objet. Des objets tabulaires définissent plusieurs
instances liées d'objets, et celles-ci sont regroupées dans des tables MIB.

26
Un exemple d'objet administré est atInput, un objet scalaire qui contient une seule
instance d'objet, à savoir la valeur de l'entier qui indique le nombre total de paquets
AppleTalk entrant sur l'interface d'un routeur.

Un identificateur d'objet (ou ID d'objet) identifie de manière unique un objet administré

dans la hiérarchie de la MIB. La hiérarchie de la MIB peut être décrite comme un arbre
dont la racine n'a pas de noms et dont les niveaux sont attribués par différentes
organisations.

Figure 2-4 Représentation de la MIB

Les ID d'objets des niveaux supérieurs appartiennent à différentes organisations de

standards, tandis que les ID d'objets des niveaux inférieurs sont attribués par des
organisations associées.

Les vendeurs peuvent définir des branches privées qui incluent des objets administrés
pour leurs propres produits. Les MIB non standardisées sont normalement placées dans
la branche expérimentale.

L'objet administré atInput peut être définit de manière unique soit par le nom d'objet
(iso.identifiedorganization.dod.internet.private.entreprise.cisco.temporary
variables.Apple-Talk.atInput), soit de façon équivalente, par le descripteur de l'objet
(1.3.6.1.4.1.9.3.3.1).

27
Les tables Mib : ces sont des tables contenant les informations de l'élément du réseau.
Ces Informations sont hiérarchisées sous forme d'arbre comme nous illustrer ci-haut :

System : Description de toutes les entités gérées

Interfaces : Interface de données dynamiques ou statiques
at. (adresse translation) : Table d'adresses IP pour les correspondances d'adresses MAC
Ip : Statistiques du protocole IP, adresse cache et table de routage
Icmp : Statistiques du protocole ICMP
Tcp : Paramètres TCP, statistiques et table de connexion
Udp : Statistiques UDP
Egp : Statistiques EGP, table d'accessibilité
Snmp : Statistiques du protocole SNMP
Examinons quelques éléments de données de la MIB pour en clarifier le contenu.

Variables MIB Catégorie Signification

sysUpTime système Durée écoulé depuis dernier démarrage

fNumber interfaces Nombre d'interfaces réseau
ifMtu interfaces MTU d'une interface particulière
ipDefaultTTL ip Valeur utilisée dans le champ TTL
icmpInEchos icmp Nbre de demandes d'echo ICMP reçues
tcpInSegs tcp Nbre de segments reçus par TCP
udpInDatagrams udp Nbre de datagrammes UDP reçus

Les valeurs des éléments de chacune des variables ci-dessus peuvent être enregistrées
au moyen d'un seul entier. Toutefois, la MIB permet également de définir des valeurs
plus complexes, comme par exemple la variable ipRoutingTable qui fait référence à la
table de routage d'un routeur.

Extension de la Mib

Au bout d'un moment, les variables choisies pour la Mib (puis la mib-2) se sont avérées
insuffisantes pour plusieurs applications. On va donc trouver deux autres types de Mib
que sont les private Mib et les Mib R-MON (Remote network Monitoring).

Les privates Mib , représentées en 1.3.6.1.4 dans la structure SMI, permettent aux
entreprises de rajouter des variables pour une implémentation particulière des agents
SNMP. Cela leur permet d'ajouter de nouvelles variables en fonctions des applications
qu'elles veulent.

Les Mib R-MON permettent par exemple de placer des agents SNMP sur des supports
physiques. Sur un câble, on peut connecter une sonde R-MON qui va enregistrer tout ce

28
qui se passe et que l'administrateur pourra interroger pour avoir des informations sur
les collisions, les débits à un endroit précis.

II.7 Les différentes versions de SNMP

Plusieurs version du protocole on vue le jour à savoir :

SNMPv1 : Ceci est la première version du protocole, tel que définie dans le RFC 1157. La
sécurité de cette version est triviale, car la seule vérification qui est faite est basée sur la
chaîne de caractères " community ". SNMPsec Cette version ajoute de la sécurité au
protocole SNMPv1. La sécurité est basée sur des groupes. Très peu ou aucun
manufacturier n'a utilisé cette version qui est maintenant largement oubliée.

SNMPv2p (historique) : Beaucoup de travaux on été exécutés pour faire une mise à jour
de SNMPv1. Ces travaux ne portaient pas seulement sur la sécurité. Le résultat est une
mise à jour des opérations du protocole, des nouvelles opérations, des nouveaux types
de données. La sécurité est basée sur les groupes de SNMPsec.

SNMPv2c (expérimental): Cette version du protocole est appelé " community

stringbased SNMPv2 ". Ceci est une amélioration des opérations de protocole et des
types d'opérations de SNMPv2p et utilise la sécurité par chaîne de caractères "
community " de SNMPv1.

SNMPv2u (expérimental): Cette version du protocole utilise les opérations, les types de
données de SNMPv2c et la sécurité basée sur les usagers.

SNMPv2* (expérimental): Cette version combine les meilleures parties de SNMPv2p et

SNMPv2u. Les documents qui décrivent cette version n'ont jamais été publiés dans 12
les RFC. Des copies de ces documents peuvent être trouvées sur le site web et SNMP
Research (un des premiers à défendre de cette version).

SNMPv3 (standard actuel): Cette version comprend une combinaison de la sécurité

basée sur les usagers et les types et les opérations de SNMPv2p, avec en plus la capacité
pour les " proxies ". La sécurité est basée sur ce qui se trouve dans SNMPv2u et
SNMPv2*.

II.7.1 SNMP Version 1

SNMP version 1 (SNMPv1) est la première implémentation du protocole SNMP. Elle est
écrite dans le RFC (Request For Comments) 1157 et fonctionne dans le cadre des
spécifications de SMI (Structure of Management information). SNMPv1 opère sur des
protocoles, tels qu’UDP (User Datagram Procol), IP (Internet Protocol), OSI CLNS
(ConnectionLess Network Service), AppleTalk DDP (Datagram-Delivery Protocol) et
Novell IPX (Internetwork Packet Exchange). SNMPv1 est largement utilisé et fait office
de protocole de facto pour l'administration réseau dans la communauté internet.

SNMPv1 et SMI

La structure des informations d'administration, ou SMI (Structure of Management

Information), définit les règles de description des informations d'administrations à
29
l'aide de ASN.1. La norme SMI de SNMPv1 est définie dans la RFC 1155. La SMI définit
trois spécifications clés : les types de données ASN.1, les types de données spécifiques à
SMI et les tables MIB de SNMP.

SNMPv1 et les types de données ASN.1

La norme SMI de SNMPv1 spécifie que tous les objets administrés disposent d'un sous-
ensemble de types de données ASN.1 qui leur est associé. Trois types de données ASN.1
sont exigées : le nom, la syntaxe et le codage. Le nom sert d'identificateur d'objet (ID
d'objet). La syntaxe définit le type de données de l'objet (par exemple, entier ou chaîne).
La norme SMI sert d'un sous-ensemble des définitions des syntaxes ASN.1. Les données
de codage décrivent la manière dont les informations associées à un objet administré
sont formatées sous la forme d'une série d'éléments de données pour une transmission
sur le réseau.

SNMPv1 et les types de données spécifiques à SMI

La norme SMI de SNMPv1 spécifie l'utilisation de plusieurs types de données spécifiques

à SMI, qui sont divisés en deux catégories : les types de données simples et les types de
données de portée application (application-wide data type).

Ø Trois types de données simples sont définis dans la SMI de SNMPv1 ; chacun d'entre
eux représente une valeur unique : les entiers, les chaines d'octets et les ID d'objets.

· Le type de données entier est un entier signé compris dans l'intervalle - 2 147 483 648
à 2 147 486 647.

· Les chaînes d'octets sont des séquences ordonnées de 0 à 65535 octets.

· Les ID d'objets proviennent de l'ensemble de tous les identificateurs d'objets alloués

conformément aux règles spécifiées dans ASN.1.

 Sept types de données de portée d'application sont définies dans la SMI de

SNMPv1 : adresses réseau, compteurs (counter), gauges, time ticks, opaques,
entiers et entiers non signés.

· Le type adresses réseau représente une adresse d'une famille de protocoles

particulière. SNMPv1 ne supporte que des adresses IP sur 32 bits.

· Les compteurs sont des entiers non négatifs dont la valeur augmente jusqu'à ce qu'elle
atteigne un maximum puis revienne à zéro. Dans SNMPv1, il est spécifié une taille de
compteur sur 32 bits.

· Les gauges sont des entiers non négatifs qui peuvent croître ou décroître, mais qui
conservent la valeur maximale atteinte.

· Les times ticks représentent le nombre de centièmes de secondes écoulés depuis un

évènement.

30
· Un opaque représente un codage arbitraire qui est utilisé pour transmettre des chaînes
d'informations arbitraires non strictement conformes au typage de données de SMI.

· Un entier représente des informations dont la valeur se présente sous forme d'entiers.
Ce type de données redéfinit le type de donnée entier qui a une précision arbitraire dans
ASN.1, mais une précision bornée dans la norme SMI.

· Un entier non signé représente des informations dont la valeur se présente sous la
forme d'entiers non signés, ce qui est utilise quand les valeurs sont toujours négatives.
Ce type de données redéfinit le type de données entier qui a une précision arbitraire
dans ASN.1, mais une précision bornée dans la norme SMI.

Les tables MIB de SNMPv1

La norme SMI de SNMPv1 définit des tables hautement structurées qui sont utilisées
pour regrouper des instances d'un objet tabulaire (c'est-à-dire un objet qui contient
plusieurs variables). Les tables sont composées de zéro ou plusieurs lignes qui sont
indexées de telle manière que SNMP puisse récupérer ou modifier une ligne entière avec
une seule commande Get, GetNext ou Set.

Les opérations du protocole SNMPv1

SNMP est un protocole simple de type requête/réponse. Le système d'administration

réseau émet une requête, et les dispositifs administrés retournent des réponses. Ce
comportement est implémenté à l'aide de l'une des quatre opérations de protocole : Get,
GetNext, Set et Trap.

 L'opération Get est utilisée pour la NMS pour récupérer la valeur d'une ou
plusieurs instances d'objets à partir d'un agent. Si l'agent qui répond à l'opération
Get ne peut pas fournir des valeurs pour toutes les instances des objets d'une
liste, il ne fournit aucune valeur.
 L'opération GetNext est utilisée par le NMS pour récupérer la valeur de la
prochaine instance des objets d'une table ou d'une liste dans un agent.
 L'opération Set est utilisée par le NMS pour définir les valeurs des instances des
objets dans un agent.
 L'opération Trap est utilisée par des agents pour informer de manière
asynchrone le NMS de la survenue d'un événement significatif.

II.7.2 SNMP Version 2

SNMP version 2 (SNMPv2) est une évolution de la version initiale, SNMPv1. A l'origine,
en 1993, SNMPv2 a été publié sous la forme d'un ensemble de propositions de standards
Internet ; actuellement, il s'agit d'un avant projet de standard. A l'instar de SNMPv1,
SNMPv2 fonctionne dans le cadre des spécifications de SMI. En théorie, SNMPv2 offre
plusieurs améliorations par rapport à SNMPv1 et notamment des opérations de
protocole supplémentaires.

SNMPv2 et SMI

31
La structure des informations d'administration, ou SMI (Structure of Management
Information), définit les règles de description des informations d'administration à l'aide
de ASN.1.

La norme SMI de SNMPv2 est définie dans le RFC 1902. Elle comprend des ajouts et des
améliorations par rapport aux types de données spécifiques a SMI SNMPv1, par exemple
les chaînes de bits (bit string), les adresses réseau et les compteurs. Les chaînes de bits
ne sont définies que dans SNMPv2 ; elles se composent de zéro ou plusieurs bits
nommés qui spécifient une valeur. Les adresses réseau représentent une adresse en se
référant à une famille de protocoles déterminée. Si SNMPv1 ne supporte que des
adresses sur 32bits, SNMPv2 peut supporter d'autres types d'adresses. Les compteurs
sont des entiers non négatifs dont la valeur augmente jusqu'à ce qu'ils atteignent une
valeur maximale pour retourner ensuite un zéro. Dans SNMPv1, il est spécifié un
compteur sur 32 bits, alors que dans SNMPv2 il est défini des compteurs sur 32 et 64
bits.

Les modules d'information SMI

La norme SMI de SNMPv2 spécifie également des modules d'informations qui spécifient
un groupe de définition liées. Il existe trois types de modules d'informations SMI : des
modules SMI, des instructions de compatibilité (compliance statements) et des
instructions de capacité (capability statements).

 Les instructions de compatibilité fournissent une manière systématique de

décrire un groupe d'objets administrés qui doivent être implémentés pour la
conformité à un standard.
 Les instructions de capacité sont utilisées pour indiquer le niveau précis de
support qu'un agent réclame compte tenu d'un groupe SMI. Un NMS peut adapter
son comportement à l'égard des agents en fonction des instructions de capacités
associées à chaque agent.

Les opérations du protocole SNMPv2

Les opérations Get, GetNext et Set utilisés dans SNMPv2 sont exactement les mêmes que
celles de SNMPv1. Cependant, SNMPv2 ajoute et améliore certaines opérations de
protocole. C'est ainsi que l'opération Trap, par exemple, réalise la même fonction que
dans SNMPv1, mais elle se sert d'un format de message différent et est conçue pour
remplacer l'opération Trap de SNMPv1.

SNMPv2 définit aussi de nouvelles opérations de protocole : GetBulk et inform.

 L'opération GetBulk est employée par le NMS pour récupère de manière efficace
de gros blocs de données, tels que plusieurs lignes d'une table. GetBulk remplit
un message de réponse avec autant de données demandées que celui-ci peut en
contenir.
 L'opération Inform permet à un NMS d'envoyer des informations Trap à un autre
NMS et de recevoir ensuite une réponse.

Dans SNMPv2, si l'agent qui répond aux opérations GetBulk ne peut pas fournir de
valeurs pour toutes les variables d'une liste, il fournit des résultats partiels.
32
II.7.3 L'interopérabilité de SNMP

Dans l'état actuel des spécifications, SNMPv2 est incompatible avec SNMPv1 dans deux
domaines clés : les formats des messages et les opérations de protocole. Les messages
SNMPv2 utilisent des formats d'en-tête de PDU (Protocol Data Unit) différents de ceux
des messages SNMPv1. SNMPv2 emploie aussi deux opérations de protocole non
spécifiées dans SNMPv1. En outre, le RFC 1908 définit deux stratégies de coexistences
SNMPv1/SNMPv2 : les agents proxy et les systèmes d'administration réseau bilingues.

Le format des messages SNMPv1

Les messages SNMPv1 sont composés de deux parties : un en-tête de message et une
PDU (Protocol Data Unit)

En-tête de message PDU

L'en-tête des messages SNMPv1

Les en-têtes des messages SNMPv1 contiennent deux champs : Numéro de version et
Nom de la communauté (Community Name). Voici la description de ces champs :

 Numéro de version. Spécifie la version de SNMP

 Nom de la communauté. Définit un environnement d'accès pour un groupe de
NMS. Les NMS de la communauté sont dits exister à l'intérieur du même domaine
administratif. Les noms de la communauté font office de forme faible
d'authentification, car les dispositifs qui ne connaissent pas le nom correct de la
communauté sont exclus des opérations SNMP.

Les PDU SNMPv1

Les PDU de SNMPv1 contiennent une commande spécifique (Get, Set, etc.) et des
opérandes qui indiquent les instances d'objet impliquées dans la transaction. Les
champs des PDU sont variables en longueur, comme prescrit par ASN.1.

Type de la ID de la Statut de Indice de Liaison des

PDU requête l'erreur l'erreur variables

Les champs de la PDU de SNMPv1, présentés sont les suivants :

 Type de la PDU. Spécifie le type de la PDU transmise.

 ID de la requête (request ID). Associe des requêtes SNMP à des réponses.
 Statut de l'erreur. Indique une des erreurs et des types d'erreurs. Seules les
opérations de réponses définissent ce champ.

33
  Indice de l'erreur. Associe une erreur à une instance d'objet particulière. Seules
les opérations de réponse définissent ce champ. Les autres opérations définissent
ce champ à zéro.
 Liaison des variables. Sert de champ de données à la PDU SNMPv1. Chaque liaison
de variable associe une instance d'objet particulière a sa valeur courante (a
l'exception des requêtes Get et GetNext pour lesquelles la valeur est ignorée).

Le format de la PDU Trap

Entreprise Adresse de Type de trap Code de trap Indication Liaison des

l'agent générique spécifique d'heure variables

Les champs de la PDU Trap sont les suivants :

 Entreprise. Identifie le type de l'objet administré qui génère le message trap.

 Adresse de l'agent. Fournit l'adresse de l'objet administré qui génère le message
trap
 Type de trap générique. Contient un entier représentant l'une des valeurs de trap
prédéfinit en standard (ou trap générique) pour SNMP.
 Code de trap spécifique. Contient un entier représentant l'une des valeurs de trap
pour un constructeur ou une entreprise particulière (ou trap spécifique).
 Indication d'heure. Spécifie la quantité de temps qui s'est écoulée entre la
dernière réinitialisation réseau et la génération du trap
 Liaison des variables. Le champ donné du PDU Trap de SNMPv1. Chaque liaison
de variable associe une instance d'objet particulière à sa valeur courante.

Le format des messages SNMPv2

Les messages SNMPv2 sont composés d'un en-tête et d'une PDU.

En-tête de message PDU

L'en-tête des messages SNMPv2

Les en-têtes des messages SNMPv2 contiennent deux champs : Numéro de version et
Nom de la communauté (Community Name). Voici la description de ces champs :

 Numéro de version. Spécifie la version de SNMP

 Nom de la communauté. Définit un environnement d'accès pour un groupe de
NMS. Les NMS de la communauté sont dits exister à l'intérieur du même domaine
administratif. Les noms de la communauté font office de forme faible
d'authentification, car les dispositifs qui ne connaissent pas le nom correct de la
communauté sont exclus des opérations SNMP.

34
Les PDU SNMPv2

SNMPv2 spécifie deux formats de PDU selon l'opération de protocole de SNMP. Les
champs des PDU sont variables en longueur, comme prescrit par ASN.1.

Type de la PDU ID de la requête Non repeaters Liaison des variables

Les champs de la PDU de SNMPv2 sont les suivants :

 Type de la PDU. Spécifie le type de la PDU transmise (Get, GetNext, Inform,

Response, Set ou Trap).
 ID de la requête. Associe des requêtes SNMP à des réponses.
 Statut de l'erreur. Indique une des erreurs et des types d'erreurs. Seules les
opérations de réponse définissent ce champ.
 Indice de l'erreur. Associe une erreur à une instance d'objet particulière. Seules
les opérations de réponse définissent ce champ. Les autres opérations définissent
ce champ à zéro.
 Liaison des variables. Sert de champ de données de la PDU SNMPv2. Chaque
liaison de variable associe une instance d'objet particulière à sa valeur courante
(à l'exception des requêtes Get et GetNext pour lesquelles la valeur est ignorée).

Le format de la PDU GetBulk

Type de la PDU ID de la requête Non repeaters Liaison des variables

Les champs de la PDU GetBulk de SNMPv2 sont les suivants :

 PDU type. Identifie la PDU comme étant une opération GetBulk.

 Request ID. Associe des requêtes SNMP à des réponses.
 Non repeaters. Spécifie le nombre d'instances d'objet du champ Liaisons de
variables qui ne doivent pas être récupérées plusieurs fois à partir du début de la
requête. Ce champ est utilisé lorsque certaines des instances d'objets scalaires ne
comprennent qu'une variable.
 Max répétitions. Définit le nombre maximal de fois où d'autres variables situées
au-delà de celle spécifiées dans le champ Non repeaters doivent être récupérées.
 Liaison des variables. Sert de champ de données de la PDU SNMPv2. Chaque
liaison de variables associe une instance d'objet particulière à sa valeur courante
(à l'exception des requêtes Get et GetNext pour lesquelles la valeur est ignorée).

II.8 La Sécurité

SNMP manque de fonctionnalités en matière d'authentification, ce qui le rend vulnérable

à un grand nombre de menaces, notamment l'usurpation d'identité (masquerading), la

35
modification d'informations, les modifications de numéros de séquences des messages
ou des dates et la divulgation.

Il y a usurpation lorsqu'une entité non autorisée tente de réaliser des opérations

d'administration en se faisant passer pour une entité autorisée. La modification
d'informations implique la tentative d'une entité non autorisée de modifier un message
généré par une entité autorisée de manière que le message final traduise des opérations
de comptabilisation ou de configuration erronées.

Les modifications des numéros de séquences ou des dates des messages se produisent
lorsqu'une entité non autorisée réordonne, retarde, copie ou émet de nouveau un
message généré par une entité autorisé. Etant donné que SNMP n'implémente pas
l'authentification, plusieurs vendeurs n'implémentent pas les opérations Set, ce qui
réduit SNMP à ses fonctions de surveillance.

Dans la version SNMPv1, la sécurité a comme on pourrait dire, été oublié. Tous les
messages passent en clair sur le réseau. Cela veut dire qu'avec n'importe quel outil
d'écoute (sniffer) nous sommes capables d'intercepter tout le trafic. En SNMPv2 on peut
fixé des listes de contrôle d'accès ACLs qui sont censées améliorer la sécurité. Le vrai
progrès se fait avec la dernière version où la plupart des messages passeront en crypté
sur le réseau. Beaucoup de composants réseau exploitent encore la version 1 ou 2. Cela
représente un danger potentiel pour les infrastructures. Il faut savoir que sur Internet, la
plupart des entités réseau sont administrable par SNMP.

Un exemple d'application simple de composant administrable : Le modem câble ou ADSL

très souvent, les fournisseurs d'accès contrôle votre débit en bridant votre modem (c'est
surtout valable pour les modems câble) en utilisant cette technologie. Très souvent
aussi, ces modems sont très mal protégés (pas de mot de passe, acl nulles...). Le
propriétaire du modem, en utilisant les outils adéquats seraient donc capable de fixer
ses propres débits et bien plus encore. Ici ce qu'on essaye de mettre en évidence se sont
surtout les mécanismes d'authentification qui sont manquants dans les 2 premières
version.

La SNMPv3

Il est vrai que SNMPv3 introduit des notions de sécurité comme :

 Authentification / intégrité basé sur du DES et clef secrète

 Confidentialité des données
 Contrôle d'accès par la MIB

Mais il est encore expérimental.

II.9 Le SNMP et d'autre protocoles

Le WMI

Contrairement aux autres protocoles, WMI qui signifie Windows Management

Instrumentation, n'est compatible qu'avec le système d'exploitation Windows. Il permet
à tout administrateur de contrôler, gérer, d'installer, collecter des informations
36
localement comme à distance. De manière générale, il étend les possibilités de base
d'administration de Windows. Cependant, bien qu'il puisse faire office d'outil de
monitoring il n'est pas recommandé pour cet usage. Ce protocole peut se montrer assez
gourmand quand il s'agit de capturer (snapshot).

Le CMIP

CMIP ou Common Management Information Protocol, un standard OSI qui est utilisé
avec le protocole CMIS, Common Management Information Services pour le monitoring
and les contrôles de réseaux hétérogènes. CMIP a été proposé comme remplacement au
protocole beaucoup moins sophistiqué qu'était SNMP mais n'a pas rencontré un franc
succès. CMIP a la particularité d'offrir une meilleure sécurité et est capable de reporter
des conditions inhabituelles d'un réseau.

II.10 Avantages et inconvénients

Nous l'avons vu, le protocole SNMP a de nombreux avantages en tant qu'outil de gestion
réseau :

 Accès centralisé : la gestion réseau s'effectue depuis une machine centrale sans
soucis, et c'est même préférable pour la sécurité.
 Sécurité : la sécurité s'est accrue au cours des différentes versions, jusqu'à
respecter la plupart des contraintes imposées.
 Fiabilité : le protocole utilisé permet de s'assurer que les requêtes sont bien
arrivées à destination et qu'elles ont été correctement interprétées.
 Gestion de la diversité : l'utilisation d'une interface standard à tous les matériels
permet de contrôler de la même manière tous les équipements réseaux, ce qui a
des avantages indéniables lorsque l'on dispose d'un parc informatique très
diversifié.

Les protocoles réseaux

Qu'est-ce qu'un protocole et à quoi sert-il ?

Un protocole de communication est un ensemble de règles et de procédures permettant

de définir un type de communication particulier. Les protocoles sont hiérarchisés en
couches, pour décomposer et ordonner les différentes tâches. Il existe plusieurs familles
de protocoles ou modèles, chaque modèle étant une suite de protocoles entre diverses
couches. Parmi ces modèles on trouve l’OSI et le TCP/IP.

Les modèles OSI et TCP/IP

Le modèle OSI ou Open Systems Interconnexion, créé en 1978 par l’organisation

internationale de normalisation (ISO), a pour objectif de constituer un modèle de
référence d'un réseau informatique et ceci dans le but de permettre la connexion entre
les architectures propriétaires hétérogènes qui existaient. Ce modèle est constitué de
sept couches dont chacune correspond à une fonctionnalité particulière d'un réseau. Les
quatre premières couches dites basses, assurent l'acheminement des informations entre
les extrémités concernées et dépendent du support physique. Les trois autres couches,
37
 dites hautes, sont responsables du traitement de l'information relative à la gestion des
échanges entre systèmes informatiques. Le modèle TCP/IP, inspiré du modèle OSI,
reprend le système de couches mais n'en contient que cinq. Le modèle TCP/IP l'emporte
sur le modèle OSI du fait que ce dernier est trop complexe pour être efficacement
implémenté à l'inverse du TCP/IP qui est beaucoup plus optimisé et efficace.

Exemples de
Modèle
Couche Modèle OSI Description protocoles du
TCP/IP
modèle TCP/IP

FTP, SSH, SFTP, DNS,

Elle assure l'interface avec les
HTTP, H323, IMAP,
couche Couche applications. Il s'agit donc du niveau
7 NFS,POP3, Samba,
application application le plus proche des utilisateurs, géré
SNMP, JXTA, RIP,
directement par les logiciels.
SMTP, Telnet, FIX

couche
6
présentation

couche
5
session

Elle est chargée du transport des

données, de leur découpage en
paquets et de la gestion des
Couche
couche de éventuelles erreurs de transmission.
4 Transport TCP, UDP, RTP
transport Les protocoles de transport
(TCP)
déterminent aussi à quelle
application chaque paquet de
données doit être délivré.

Elle permet de gérer l'adressage et le

routage des données, c'est-à-dire
leur acheminement via le réseau. Elle
Couche permet l'acheminement des
couche de
3 Internet datagrammes (paquets de données) IP, ICMP, IGMP, ARP
réseau
(IP) vers des machines distantes ainsi
que de la gestion de leur
fragmentation et de leur assemblage
à réception.

38
 Elle spécifie comment les paquets
sont transportés sur la couche
Couche physique, et en particulier les
couche de
accès séquences particulières de bits qui Ethernet, ATM, Token
2 liaison des
réseau marquent le début et la fin des ring, SLIP
données
ou liaison paquets (le tramage). Cette couche
est parfois subdivisée en deux sous
couches nommées LLC et MAC.

Elle décrit les caractéristiques

physiques de la communication
comme les conventions à propos de
la nature du medium utilisé pour les
communications (les câbles, les liens
couche Couche par fibre optique ou par radio), et électronique, radio,
1
physique physique tous les détails associés comme les laser
connecteurs, les types de codage ou
de modulation, le niveau des signaux,
les longueurs d'ondes, la
synchronisation et les distances
maximales.

Encapsulation des données

Lors d'une transmission, les données traversent chacune des couches au niveau de la
machine émettrice. A chaque couche, une information est ajoutée au paquet de données,
il s'agit d'un en-tête, ensemble d'informations qui garantit la transmission. Au niveau de
la machine réceptrice, lors du passage dans chaque couche, l'en-tête est lu, puis
supprimé. Ainsi, à la réception, le message est dans son état originel.

39
Exemple d'une communication réseau HTTP

A l'aide de l'analyseur de protocole réseau "Ethereal" j'ai pu sniffer les informations qui
arrivent sur le réseau. Je montre ici une communication HTTP, le chargement de la page
web http://www.zeitoun.net.

On distingue clairement les différentes couches du modèle TCP/IP, expliquées plus haut
dans le document.

Au niveau de la couche "accès réseau"

Nous observons le protocole Ethernet dont les deux attributs importants sont les
adresses physiques (MAC) des cartes réseaux.

Ethernet II, Src: AsustekC_c9:f7:78 (00:11:d8:c9:f7:78), Dst: 3com_44:8c:88

(00:0a:5e:44:8c:88)
Destination: 3com_44:8c:88 (00:0a:5e:44:8c:88)
Source: AsustekC_c9:f7:78 (00:11:d8:c9:f7:78)
Type: IP (0x0800)

Au niveau de la couche "Internet"

Nous observons le protocole IP dont les deux attributs importants sont les adresses IP
source et destination.

Internet Protocol, Src: 192.168.0.70 (192.168.0.70), Dst: 213.251.133.196

(213.251.133.196)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 500
Identification: 0x4152 (16722)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: TCP (0x06)
Header checksum: 0xdb03 [correct]
40
 Source: 192.168.0.70 (192.168.0.70)
Destination: 213.251.133.196 (213.251.133.196)

Au niveau de la couche "transport"

Nous observons le protocole TCP qui contient les informations des ports de la
connexion.

Transmission Control Protocol, Src Port: 33276 (33276), Dst Port: www (80), Seq: 1,
Ack: 1, Len: 448
Source port: 33276 (33276)
Destination port: www (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 449 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 32 bytes
Flags: 0x0018 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 5840 (scaled)
Checksum: 0x1e95 [incorrect, should be 0x989d]
Options: (12 bytes)
NOP
NOP
Time stamp: tsval 36207655, tsecr 148502841

Au niveau de la couche "application"

Nous observons le protocole HTTP : un client web tente de se connecter sur le site web
www.zeitoun.net en utilisant la méthode GET.

Hypertext Transfer Protocol

GET / HTTP/1.1\r\n
Request Method: GET
Request URI: /
Request Version: HTTP/1.1
Host: www.zeitoun.net\r\n
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716
Firefox/1.0.6\r\n
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,imag
e/png,*/*;q=0.5\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
41
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
Cookie: PHPSESSID=cd212b11276ada1bfa58dce3090575c2\r\n
\r\n

0000 00 0a 5e 44 8c 88 00 11 d8 c9 f7 78 08 00 45 00 ..^D.......x..E.
0010 01 f4 41 52 40 00 40 06 db 03 c0 a8 00 46 d5 fb ..AR@[email protected]..
0020 85 c4 81 fc 00 50 a5 a7 3d 4f 24 7a 52 71 80 18 ...P..=O$zRq....
0030 05 b4 1e 95 00 00 01 01 08 0a 02 28 7c 27 08 d9 ...........(|'..
0040 f9 39 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 .9GET / HTTP/1.1
0050 0d 0a 48 6f 73 74 3a 20 77 77 77 2e 7a 65 69 74 ..Host: www.zeit
0060 6f 75 6e 2e 6e 65 74 0d 0a 55 73 65 72 2d 41 67 oun.net..User-Ag
0070 65 6e 74 3a 20 4d 6f 7a 69 6c 6c 61 2f 35 2e 30 ent: Mozilla/5.0
0080 20 28 58 31 31 3b 20 55 3b 20 4c 69 6e 75 78 20 (X11; U; Linux
0090 69 36 38 36 3b 20 65 6e 2d 55 53 3b 20 72 76 3a i686; en-US; rv:
00a0 31 2e 37 2e 31 30 29 20 47 65 63 6b 6f 2f 32 30 1.7.10) Gecko/20
00b0 30 35 30 37 31 36 20 46 69 72 65 66 6f 78 2f 31 050716 Firefox/1
00c0 2e 30 2e 36 0d 0a 41 63 63 65 70 74 3a 20 74 65 .0.6..Accept: te
00d0 78 74 2f 78 6d 6c 2c 61 70 70 6c 69 63 61 74 69 xt/xml,applicati
00e0 6f 6e 2f 78 6d 6c 2c 61 70 70 6c 69 63 61 74 69 on/xml,applicati
00f0 6f 6e 2f 78 68 74 6d 6c 2b 78 6d 6c 2c 74 65 78 on/xhtml+xml,tex
0100 74 2f 68 74 6d 6c 3b 71 3d 30 2e 39 2c 74 65 78 t/html;q=0.9,tex
0110 74 2f 70 6c 61 69 6e 3b 71 3d 30 2e 38 2c 69 6d t/plain;q=0.8,im
0120 61 67 65 2f 70 6e 67 2c 2a 2f 2a 3b 71 3d 30 2e age/png,*/*;q=0.
0130 35 0d 0a 41 63 63 65 70 74 2d 4c 61 6e 67 75 61 5..Accept-Langua
0140 67 65 3a 20 65 6e 2d 75 73 2c 65 6e 3b 71 3d 30 ge: en-us,en;q=0
0150 2e 35 0d 0a 41 63 63 65 70 74 2d 45 6e 63 6f 64 .5..Accept-Encod
0160 69 6e 67 3a 20 67 7a 69 70 2c 64 65 66 6c 61 74 ing: gzip,deflat
0170 65 0d 0a 41 63 63 65 70 74 2d 43 68 61 72 73 65 e..Accept-Charse
0180 74 3a 20 49 53 4f 2d 38 38 35 39 2d 31 2c 75 74 t: ISO-8859-1,ut
0190 66 2d 38 3b 71 3d 30 2e 37 2c 2a 3b 71 3d 30 2e f-8;q=0.7,*;q=0.
01a0 37 0d 0a 4b 65 65 70 2d 41 6c 69 76 65 3a 20 33 7..Keep-Alive: 3
01b0 30 30 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 00..Connection:
01c0 6b 65 65 70 2d 61 6c 69 76 65 0d 0a 43 6f 6f 6b keep-alive..Cook
01d0 69 65 3a 20 50 48 50 53 45 53 53 49 44 3d 63 64 ie: PHPSESSID=cd
01e0 32 31 32 62 31 31 32 37 36 61 64 61 31 62 66 61 212b11276ada1bfa
01f0 35 38 64 63 65 33 30 39 30 35 37 35 63 32 0d 0a 58dce3090575c2..

42
Conclusion

Ce document définit ce qu'est un protocole en informatique, et décrit le fonctionnement

de deux familles de protocoles le modèle OSI et le modèle TCP/IP. Le modèle OSI étant
très complexe et inadapté aux communications entre ordinateurs, est amené à
disparaître au profit de TCP/IP. C'est pour cette raison que dans ce document, j'ai
majoritairement parlé du modèle TCP/IP et de ses cinq couches. J'ai ainsi montré, et cela
à l'aide d'un analyseur de protocole réseau, l'encapsulation des données.

BIBLIOGRAPHIE

Ouvrages

[1]. DOUDOUX (Jean ), Développons en java, Février 2003

[2]. TAHE (Serge), Apprentissage du langage java, Juin 2002, pp 246-248

[3]. NAZIM AGOULMINE (Omar cherkaoui), Pratique de la gestion de réseau, Groupe

Eyrolles 2003, pp 2-22

Cours

[4]. KABEYA. D, Télématique, cours 3e Dép. Math-Info, Univ. Kinsjasa 2007

[5]. KASSORO, Programmation Orienté Object, cours 3e Dép. Math-Info, Univ. Kinsjasa
2007

Reference Web

[6]. http://www.adventnet.com (consulté le mardi 20 novembre 2007, 23 :20 :20 :07)

43