Administration Service

Administration des
Services Réseaux Présentation de l’administration réseau
Chapitre
Présentation de l’administration réseau
Dr. H. Zerrouki
UABBT, Faculté de Technologie, Département de Télécommunications
Le terme administration de réseaux recouvre l'ensemble des fonctions qui sont nécessaires pour
l'exploitation, la sécurité, le suivi et l'entretien du réseau. II est nécessaire de pouvoir initialiser de
nouveaux services, installer de nouvelles stations raccordées au réseau, superviser l'état du réseau global
et de chacun de ses sous ensembles, suivre de manière fine l'évolution des performances, évaluer et
comparer diverses solutions, mettre fin à des situations anormales.
I.1 INTRODUCTION
L'administration réseau est le processus permettant le CONTROLE d'un réseau de données pour en
assurer l'efficacité et la productivité. Le but final de l'administration réseau est d'aider à maîtriser la
complexité des réseaux de données et d'assurer que les données transitent sur le réseau avec le
maximum d'efficacité et de transparence aux utilisateurs.
Figure I.1 – Principe général d’un système d’administration réseau.
L'administration des réseaux informatiques évolue sans cesse et elle s'affirme aujourd'hui comme une
activité clé de toute entreprise. En plus d'être constamment en évolution, ses outils d'échange de
données et de partage d'information en temps réel doivent être en mesure d'offrir une confidentialité
maximale et une sécurité à toute épreuve.
L’administration des réseaux informatiques implique le développement et la mise en place d'outils de

gestion ayant pour but de tirer le maximum d'Internet, tout en mettant l'accent sur l'aspect sécurité de
l'utilisation de cet outil maintenant indispensable.
En jouant un rôle de tout premier plan dans la gestion, l'échange et la transmission de l'information,
l’administration des réseaux informatiques prend une importance capitale pour un nombre croissant
d'entreprises. Bien au fait des produits et des services offerts dans le domaine et constamment à l'affût
des innovations.
. © Auteur : Dr. H. Zerrouki
Un réseau comporte un grand nombre de composants (objets) que le système d’administration

Auteur : Dr. H. Zerrouki
surveille. Dans chaque objet, un programme en tâche de fond (Daemon) transmet régulièrement, ou
sur sollicitation, les informations relatives à son état (Figure I.2).
Les échanges s’effectuent à deux niveaux : entre le composant administré (Processus agent) et sa base
d’information (MIB, Management Information Base) d’une part, et d’autre part, entre le composant et
le programme d’administration (Processus manager).
2
Administration des
Figure I.2 – La structure fonctionnelle d’un système d’administration.
I.2 OBJECTIFS ET ROLE DE L’ADMINISTRATION RESEAU
I.2.1 L’administrateur réseau
L’administrateur réseau est responsable de ce qui peut se passer à partir du réseau administré.
L'administrateur réseau est chargé de la gestion des comptes et des machines du réseau informatique
d'une organisation. Il est souvent assisté d'un ingénieur qui conçoit l'architecture du réseau.
L'administration réseau est une discipline de l'informatique qui peut s'étendre à la téléphonie.
L'administrateur réseau est parfois également administrateur système, il gère alors aussi les postes de
travail et les serveurs de l'entreprise.
L'administrateur d'aujourd'hui doit arriver à déjouer des envahisseurs virtuels qui disposent de
nouvelles armes de plus en plus sophistiquées.
L'utilisation du matériel informatique et des logiciels doit se faire en fonction de l'environnement

informatique actuel de chaque entreprise et avec deux mots d'ordre en tête : compatibilité et
homogénéité. Outre les diverses installations à coordonner, il faut aussi s'assurer d'effectuer les mises
à jour des manufacturiers sur une base constante. C'est ce qui nous donne l'assurance de profiter
d'une performance et d'une sécurité optimale.
La continuité des activités d'une entreprise dépend essentiellement de la qualité de son système
d'information, qui repose en grande partie sur l'efficacité avec laquelle est géré son réseau.
Pare-feu, antivirus, gestion des courriers électroniques ; voilà autant de produits et de services qui
doivent être analysés avant d'être mis en place.
Le rôle d’un administrateur réseau consiste (entre autre) à :

• Mettre en place et maintenir l’infrastructure du réseau (organisation, . . .).

• Installer et maintenir les services nécessaires au bon fonctionnement du réseau.
• Assurer la sécurité des données internes au réseau
• S’assurer que les utilisateurs n’outrepassent pas leurs droits.
• Gérer les “logins” (i.e. noms d’utilisateurs, mot de passe, droits d’accès, permissions
particulières, . . .).
• Le trafic des données qui circulent sur le réseau (Supervision).
• La sauvegarde des données.
3
Administration des
• la politique de sécurité régissant tous les types d'accès au réseau (accès interne, accès à
distance et interconnexion avec des tierces parties).
• la surveillance et l'assurance de la fiabilité générale du réseau.
I.2.2 Rôle de l'administration réseau
Le rôle de l'administration du réseau est indissociable de la structure d'organisation de l'entreprise. Les

fonctions assurées par un groupe d'utilisateurs (micro -ordinateurs, robots,...) sont de première
importance dans la définition du service qui doit leur être fourni. L'administration du réseau doit
posséder une bonne connaissance des entités réseau qu'il contrôle et une compréhension claire de la
manière dont le réseau local est utilisé. Cette connaissance est nécessaire pour permettre des actions
efficaces : réponses rapides aux questions posées par les utilisateurs, suivi précis de l'utilisation
effective du réseau, évolution des logiciels, matériels, protocoles, applications.
La qualité de l’administration du réseau peut généralement être jugée en fonction de la disponibilité

(i.e. durée de fonctionnement sans interruption) et du temps de réponse.
Pour effectuer une bonne administration, l’administrateur a besoin de procédures d'interventions et

d'outils adaptés aux conditions d'exploitation du réseau. Dans un environnement réseau les
procédures les plus fréquemment citées sont :
• Sauvegardes
• Gestion de l’espace disque
• Implantation de logiciel
• Implantation de nouvelles versions
• Modification de configuration
• Rechargement de fichier
• Gestion des droits d’accès
L'administrateur a besoin de trois grands types d'actions pour agir et suivre son réseau :
Des actions en temps réel pour connaître l'état de fonctionnement de son réseau (surveillance et
diagnostic des incidents, mesure de la charge réelle, maintenance, contrôle, information aux
utilisateurs,...) et agir sur celui-ci (réparation, ajout de nouveaux utilisateurs, retraits,...), assurer la
sécurité (contrôler les accès, créer/retirer des droits d'accès,...).
Des actions différées pour planifier, optimiser, quantifier et gérer les évolutions du réseau
(statistiques, comptabilité, facturation, prévention, évaluation de charges,...).
Des actions prévisionnelles qui lui permettent d'avoir une vision à moyen et long terme, d'évaluer
des solutions alternatives, de choisir les nouvelles générations de produits, d'envisager les
configurations, de décider du plan d’extension, de vérifier la pertinence de la solution réseau pour un
problème donné…
L'ensemble de ces objectifs ne peut être satisfait par un outil unique. Il est nécessaire de faire appel à
plusieurs techniques de l'informatique et des mathématiques pour répondre à ces divers besoins.
Nous distinguerons les fonctions liées à la gestion au jour le jour du réseau, communément appelées
outils d'administration les outils de configuration et les outils d'analyse et de mesure.
I.2.3 Objectifs de l'administration réseau
Alors qu'un réseau évolue et s'étend, il devient une ressource de plus en plus cruciale et indispensable
pour l'organisation.
4
Administration des
À mesure que des ressources réseau sont mises à la disposition des utilisateurs, le réseau devient plus
complexe et sa gestion devient plus compliquée. La perte de ressources réseau et les mauvaises
performances sont les conséquences de cette augmentation de la complexité et ne sont pas
acceptables pour les utilisateurs.
L'administrateur doit gérer activement le réseau, diagnostiquer les problèmes, empêcher certaines
situations de survenir et fournir les meilleures performances réseau possibles aux utilisateurs. Il arrive
un moment où les réseaux deviennent trop étendus pour être administrés sans outils de gestion
automatiques.
Les forces qui dirigent l'administration réseau sont présentées et expliquées ci-dessous :
• Contrôle des ressources de l'entreprise – Si les ressources réseau ne sont pas gérées de
façon efficace, elles n'offrent pas les résultats exigés par une bonne administration.
• Contrôle de la complexité – Avec la croissance massive du nombre de composants réseau,

d'utilisateurs, d'interfaces, de protocoles et de constructeurs, la perte de contrôle du réseau et
de ses ressources constitue une menace pour l'administration.
• Amélioration du service – Les utilisateurs attendent des services similaires ou améliorés

lorsque le réseau s'étend et que les ressources deviennent plus dispersées.
• Équilibrage des divers besoins – Diverses applications doivent être mises à la disposition des
utilisateurs à un niveau donné de support, avec des exigences spécifiques en termes de
performances, de disponibilité et de sécurité.
• Réduction des temps d'arrêt – Assurer la haute disponibilité des ressources au moyen d'une
conception redondante adéquate.
• Contrôle des coûts – Surveillance et contrôle de l'utilisation des ressources, de manière à

satisfaire l'utilisateur pour un coût raisonnable.
I.3 OSI ET LE MODELE D'ADMINISTRATION RESEAU
L'organisme international de normalisation ISO (International Standards Organization) a créé un comité

visant à produire un modèle pour l'administration réseau, sous la direction du groupe de modèle OSI.
Ce modèle se décline en quatre parties (Figure I.3):
• Le modèle d’organisation
• Le modèle d’informations
• Le modèle de communication
• Le modèle fonctionnel
Figure I.3 – Modèle d'administration réseau.

5
Administration des
Ceci constitue une vue du haut en bas de l'administration réseau, divisée en quatre sous-modèles et
reconnue par la norme OSI.
Le modèle d'organisation ou architectural (MSA, Managed System and Agents) qui organise la
gestion OSI et décrit les composants de l'administration réseau, par exemple administrateur, agent, et
ainsi de suite, avec leurs relations. La disposition de ces composants mène à différents types
d'architecture, décrits plus loin dans les chapitres suivants.
Le modèle d’informations est relatif à la structure et au stockage des informations d'administration

réseau. Ces informations sont stockées dans une base de données, appelée base d'informations de
management (MIB, Management Information Base). L'ISO a établi la structure des informations
d'administration (SMI, Structure of Management Information) pour définir la syntaxe et la sémantique
des informations d'administration stockées dans la MIB. Les MIB et les SMI sont étudiées en
profondeur ultérieurement (Chapitre II).
Le modèle de communication traite de la manière dont les données d'administration sont transmises
entre les processus agent et administrateur. Il est relatif au protocole d'acheminement, au protocole
d'application et aux commandes et réponses entre égaux.
Le modèle fonctionnel concerne les applications d'administration réseau qui résident sur la station
d'administration réseau (NMS, Network Management Systems). Le modèle d'administration OSI
compte cinq domaines (aires) fonctionnels (figure I.4), parfois appelés le modèle FCAPS (Fault,
Configuration, Accounting, Performance, Security) :
• Les erreurs
• La configuration
• La comptabilité
• Les performances
• La sécurité
Figure I.4 – Les aires fonctionnelles de la gestion ISO.
Ce modèle d'administration réseau a largement été adopté par les constructeurs au titre de méthode
utile de description des besoins de n'importe quel système d'administration réseau.
I.3.1 Les différents modèles

a) Le modèle architectural
Le modèle architectural définit trois types d’activité : la gestion du système (System Management), la
gestion de couche (Layer management) et les opérations de couche (Layer Operation).
La gestion du système (SMAE, System Management Application Entity) met en relation deux processus:
un processus gérant et un processus agent. L’agent gère localement un ensemble de ressources
locales (équipements, protocoles ...) sous le contrôle de l’agent gérant (Figure I.5).
6
Administration des
Figure I.5 – Le modèle architectural de l’ISO.
La gestion système repose sur des échanges verticaux entre couches (CMIS, Common Management
Information Service). CMIS définit les primitives d’accès aux informations. Ces primitives assurent le
transfert d’information vers les applications de gestion (SMAP, System Management Application
Process) non spécifiées par l’ISO.
La gestion de couche, ou protocole de gestion de couche, fournit les moyens de transfert des
informations de gestion entre les sites administrés, c’est un dialogue horizontal (CMIP, Common
Management Information Protocol). Les opérations de couche (N), ou protocole de couche (N),
supervisent une connexion de niveau N. Ces opérations utilisent les protocoles OSI classiques pour le
transfert d’information. CMIP utilise les primitives de service suivantes (CMISE, Common Management
Information Service Element) :
• Get, cet élément de service est utilisé par le gérant pour lire la valeur d’un attribut ;
• Set, fixe la valeur d’un attribut ;
• Event, permet à un agent de signaler un événement ;
• Create, génère un nouvel objet ;
• Delete, permet à l’agent de supprimer un objet.
b) Le modèle informationnel
Le standard OSI décrit une méthode de définition des données d’administration qui modélise la
représentation des informations et qui fournit un ensemble de directives pour garantir la cohérence de
la base (SMI, Structure of Management Information).
La représentation des éléments gérés (objets gérés) est orientée objet, les classes et occurrences
d’objets sont représentées selon un arbre. Les classes sont rattachées à un arbre dit d’héritage
(Inheritance tree), les occurrences d’objets à un arbre dit de contenance (Containment tree). Un objet
est décrit par sa classe d’appartenance, son nom, ses attributs et les types d’opération qu’il supporte.
L’ensemble des objets gérés constitue la MIB. La MIB contient toutes les informations administratives
sur les objets gérés (ponts, routeurs, cartes...). La norme ne spécifie aucune organisation particulière
des données. Celles-ci peuvent y être organisées selon une structure en ligne, une base de données...
7
Administration des
Seul, le processus agent a accès à la MIB. Le processus manager accède aux données via le processus
agent.
c) Le modèle fonctionnel
Ce modèle, plus concret que les précédents, définit des domaines fonctionnels d’administration et
leurs relations. Cinq domaines ou fonctions (aires fonctionnelles) y sont décrits (SMFA, Specific
Management Function Area).
Gestion des anomalies
La gestion des anomalies (Fault management) est une fonction dominante. En effet, l’objectif
essentiel d’une administration de réseaux est l’optimisation des ressources et des moyens. Il
importe donc d’être en mesure de diagnostiquer rapidement toute défaillance du système, que
celle-ci soit d’origine externe (ex. : coupure d’un lien public) ou interne au système (ex. : panne
d’un routeur). La gestion des anomalies comporte notamment :
• La surveillance des alarmes (filtre, report...),

• Le traitement de celles-ci,
• La localisation et le diagnostic des incidents,
• La mémorisation des anomalies (journalisation),
• La définition des opérations curatives...
Gestion de la comptabilité
La gestion des éléments comptables (Accounting management) permet d’évaluer les coûts et de
les imputer aux utilisateurs selon l’usage réel des moyens. Ces informations autorisent la
répartition des coûts selon les centres de frais de l’entreprise (comptabilité analytique). La
comptabilité comporte les tâches suivantes :
• Définition des centres de coût,

• Mesure des dépenses de structure (coûts fixes) et répartition,
• Mesure des consommations par service,
• Imputation des coûts.
Gestion de la configuration et des noms
La gestion de la configuration (Configuration management) consiste à maintenir un inventaire

précis des ressources matérielles (type, équipement...) et logicielles (version, fonctions...) et d’en
préciser la localisation géographique. La gestion de la configuration associe, à chaque objet géré
(chaque objet de l’inventaire), un nom qui l’identifie de manière unique.
Gestion des performances
La gestion des performances (Performance management) met en œuvre les moyens qui
permettent d’évaluer le comportement des objets gérés. L’évaluation des performances nécessite
la collecte d’information statistique afin de déterminer, en permanence, si le réseau est apte à

satisfaire les besoins de communication des utilisateurs. La mesure de la dégradation des
performances permet d’anticiper les défaillances et de programmer les évolutions du système. La
gestion des performances comprend notamment :
• La collecte d’information (mesure du trafic, temps de réponse, taux d’erreur...),

• Le stockage (archivage...),
• L’interprétation des mesures (calcul de charge du système...).
8
Administration des
La gestion des performances nécessite de disposer d’outil de modélisation et de simulation pour

évaluer l’impact, sur l’ensemble du système, de la modification de l’un de ses paramètres.
Gestion de la sécurité
Afin d’assurer l’intégrité des informations traitées et des objets administrés, la gestion de la
sécurité (Security management) couvre tous les domaines de la sécurité. L’ISO a défini cinq
services de sécurité :
• Les contrôles d’accès au réseau,

• La confidentialité qui consiste à s’assurer que les données ne sont communiquées qu’aux
personnes, ou processus autorisés,
• L’intégrité qui s’assure que les données n’ont pas été accidentellement ou volontairement
modifiées ou détruites,
• L’authentification qui garantit que l’entité participant à la communication est bien celle
déclarée,
• Le non-désaveu, mécanisme qui interdit, à une entité participant à la communication, de nier
d’avoir participé à celle-ci.
Pour cela l’ISO utilise les mécanismes d’encryptage, l’authentification des extrémités (source et
destinataire) et le contrôle des accès aux données.
I.4 RESEAU CLIENTS - SERVEURS
I.4.1 Introduction
Dans l’informatique moderne, de nombreuses applications fonctionnent selon un environnement

client-serveur; cette dénomination signifie que des machines clientes (faisant partie du réseau)
contactent un serveur - une machine généralement très puissante en termes de capacités d’entrées-
sorties - qui leur fournit des services. Nous allons voir comment cette technologie permet d’exploiter
au mieux les réseaux, et permet un haut niveau de coopération entre différentes machines sans que
l’utilisateur se préoccupe des détails de compatibilité.
I.4.2 Définition du modèle client/serveur
Le modèle client-serveur s'articule autour d'un réseau auquel sont connectés deux types
d'ordinateurs le serveur et le client. Le client et le serveur communiquent via des protocoles. Les
applications et les données sont réparties entre le client et le serveur de manière à réduire les coûts.
Le client-serveur représente un dialogue entre deux processus informatiques par l’intermédiaire d’un
échange de messages. Le processus client sous-traite au processus serveur des services à réaliser. Les
processus sont généralement exécutés sur des machines, des systèmes d’exploitation (OS, Operation
System) et des réseaux hétérogènes.
Figure I.6 – Le modèle client/serveur.
9
Administration des
On distingue alors les deux composantes suivantes :
• Le client, qui envoie ses requêtes au serveur ;

• Le serveur, dont la tâche est d’attendre les requêtes du client, avant de les traiter et de lui
envoyer une réponse.
Les services sont exploités par des programmes, appelés programmes clients, s'exécutant sur
les machines clientes. On parle ainsi de client (client FTP, client de messagerie, etc.) lorsque l'on
désigne un programme tournant sur une machine cliente, capable de traiter des informations qu'il
récupère auprès d'un serveur (dans le cas du client FTP il s'agit de fichiers, tandis que pour le client de
messagerie il s'agit de courrier électronique).
I.4.3 Caractéristiques des systèmes client serveur
Les éléments qui caractérisent une architecture client serveur sont :
• Service : Le modèle client serveur est une relation entre des processus qui tournent sur des
machines séparées. Le serveur est un fournisseur de services. Le client est un consommateur de
services ;
• Partage de ressources : Un serveur traite plusieurs clients et contrôle leurs accès aux ressources ;
• Protocole asymétrique : Conséquence du partage de ressources, le protocole de communication

est asymétrique le client déclenche le dialogue ; le serveur attend les requêtes des clients ;
• Transparence de la localisation : L’architecture client serveur doit masquer au client la

localisation du serveur (que le service soit sur la même machine ou accessible par le réseau).
Transparence par rapport aux systèmes d’exploitation et aux plates-formes matérielles.
Idéalement, le logiciel client serveur doit être indépendant de ces deux éléments ;
• Message : Les messages sont les moyens d’échanges entre client et serveur ;
• Encapsulation des services : Un client demande un service. Le serveur décide de la façon de le

rendre une mise à niveau du logiciel serveur doit être sans conséquence pour le client tant que
l’interface message est identique ;
• Evolution : Une architecture client serveur doit pouvoir évoluer horizontalement (évolution du
nombre de clients) et verticalement (évolution du nombre et des caractéristiques des serveurs).
I.4.4 La répartition des tâches
Dans l’architecture client/serveur, une application est constituée de trois parties :
• L’interface utilisateur
• La logique des traitements

• La gestion des données
Le client n'exécute que l'interface utilisateur (souvent un interfaces graphique). Ainsi que la logique
des traitements (formuler la requête), laissant au serveur de bases de données la gestion complète
des manipulations de données. La liaison entre le client et le serveur correspond a tout un ensemble
complexe de logiciels appelé middleware qui se charge de toues les communication entre les
processus.
10
Administration des
I.4.5 Les différents modèles de client/serveur
En fait, les différences sont essentiellement liées aux services qui sont assurés par le serveur. On
distingue couramment:
a) Le client -serveur de donnée
Dans ce cas, le serveur assure des taches de gestion, stockage et de traitement de donnée .c'est le cas
le plus connu de client - serveur est utilisé par tous les grands SGBD :
La base de données avec tous ses outils (maintenance, sauvegarde….) est installée sur un poste
serveur. Sur les clients, un logiciel d'accès est installé permettant d'accéder à la base de données du
serveur. Tous les traitements sur les données sont effectués sur le serveur qui renvoie les informations
demandées par le client.
b) Le client -serveur de présentation
Dans ce cas la présentation des pages affichées par le client est intégralement prise en charge par le
serveur. Cette organisation présente l'inconvénient de générer un fort trafic réseaux.
c) Le client –serveur de traitement
Dans ce cas, le serveur effectue des traitements a la demande du client .Il peut S'agir de traitement
particulier sur des données, de vérification de formulaire de saisie, de traitements d'alarmes. Ces
traitements peuvent être réalisés par des programmes installés sur des serveurs mais également
intégrés dans des bases de données, dans ce cas, la partie donnée et traitement sont intégrés.
I.5 LA NOTION DE PORT ET DE SERVICES
I.5.1 Notion de port
Lors d'une communication en réseau, les différents ordinateurs s'échangent des informations qui sont
généralement destinées à plusieurs applications (vous pouvez par exemple ouvrir plusieurs navigateurs
simultanément ou bien naviguer sur des pages HTML tout en téléchargeant un fichier par FTP).
Seulement ces informations transitent par la même passerelle. Il faut donc savoir pour quelle
application telle information est destinée.
Ainsi, pour faciliter ce processus, chacune de ces applications se voit attribuer une adresse unique sur
la machine, codée sur 16 bits: un port (la combinaison adresse IP + port est alors une adresse unique
au monde, elle est appelée socket).
L'adresse IP sert donc à identifier de façon unique un ordinateur sur le réseau tandis que le numéro de
port indique l'application à laquelle les données sont destinées. De cette manière, lorsque l'ordinateur
reçoit des informations destinées à un port, les données sont envoyées vers l'application
correspondante. S'il s'agit d'une requête à destination de l'application, l'application est appelée
application serveur. S'il s'agit d'une réponse, on parle alors d'application cliente.
Il existe des milliers de ports (ceux-ci sont codés sur 16 bits, il y a donc 65536 possibilités), c'est
pourquoi une assignation standard a été mise au point par l'IANA (Internet Assigned Numbers
Authority), afin d'aider à la configuration des réseaux.
• Les ports 0 à 1023 sont les ports reconnus ou réservés (Well Known Ports). Ils sont, de
manière générale, réservés aux processus système (démons) ou aux programmes exécutés par
des utilisateurs privilégiés. Un administrateur réseau peut néanmoins lier des services aux ports
de son choix.
11
Administration des
• Les ports 1024 à 49151 sont appelés ports enregistrés (Registered Ports).
• Les ports 49152 à 65535 sont les ports dynamiques et/ou privés (Dynamic
Dynamic and/or Private
Ports).
Voici certains des ports reconnus les plus couramment utilisés :
Port Service ou Application

21 FTP (File Transfert Protocol )
23 Telnet
25 SMTP (Simple Mail Transfer Protocol)
53 DNS (Domain Name System)
63 Whois
70 Gopher
79 Finger
80 HTTP (Hyper Texte Transfert Protocol)
110 POP3
119 NNTP
Ainsi, un serveur (un ordinateur que l'on contacte et qui propose des services tels que FTP, HTTP,
Telnet,, ...) possède des numéros de port fixes auxquels l'administrateur réseau a associé des services.
Ainsi, les ports d'un serveur sont généralement compris entre 0 et 1023 (fourchette de valeurs
associées à des services connus).
Du côté du client,, le port est choisi aléatoirement parmi ceux disponibles par le système d'exploitation.
Ainsi, les ports du client ne seront jamais compris entre 0 et 1023 car cet intervalle de valeurs
représente les ports connus.
I.5.2 LES SERVICES DE LA COUCHE APPLICATION
Pour réaliser la transmission des données par Internet, la simple possibilité des les adresser à
l'ordinateur contacté est naturellement insuffisante. Il faut également que l'ordinateur expédiant les
le
données et celui qui les reçoit s'accordent sur la manière dont la transmission des données doit se
dérouler.
Figure I.6 – Les protocoles de chaque couche du modèle OS.
12
Administration des
Un protocole est une série d'étapes à suivre pour permettre une communication harmonieuse Entre
plusieurs ordinateurs.
Toutes les applications Internet complexes utilisent des protocoles de transmission spécifiques, qui
viennent se greffer sur les protocoles TCP/IP. Ces protocoles sont définis en fonction de leurs
applications (services) respectives.
a) Le protocole HTTP(S) :
L'HyperText Transfer Protocol, plus connu sous l'abréviation HTTP - littéralement protocole de transfert
hypertexte - est un protocole de communication client-serveur développé pour le World Wide Web.
HTTPS (avec S pour Secured, soit sécurisé) est la variante du HTTP sécurisée par l'usage des protocoles
SSL ou TLS.
HTTP est un protocole de la couche application. Il peut fonctionner sur n'importe quelle connexion
fiable, dans les faits on utilise le protocole TCP comme couche de transport. Un serveur HTTP utilise
alors par défaut le port 80 (443 pour HTTPS).
Les clients HTTP les plus connus sont les navigateurs Web permettant à un utilisateur d'accéder à un
serveur contenant les données. Il existe aussi des systèmes pour récupérer automatiquement le
contenu d'un site tel que les aspirateurs de site Web ou les robots d'indexation.
Il sert à transmettre des documents au format (HTM, STM, SSI, etc.) HTML ou autres sources
d'informations demandées au serveur par le navigateur.
b) Le protocole FTP
" File Transfert Protocol " est le fondement de l'une des applications traditionnelles d'Internet. Le
transfert tous azimuts de fichiers est l'une des principales vocations du réseau. Contrairement à HTTP,
FTP vous offre le contrôle global de la connexion établie avec un système distant. La connexion doit
être établie par un login, qui peut exiger de vous un nom d'utilisateur ainsi qu'un mot de passe.
Pendant la session FTP, vous disposez de nombreuses commandes permettant d'accéder au système
de fichiers de la machine distante.
Vous pouvez ouvrir des listes de fichiers, effacer ou copier des fichiers, créer ou supprimer des
dossiers, vous pouvez donc effectuer quasiment toutes les manipulations que vous pourriez
entreprendre sur votre propre ordinateur. Les responsables des serveurs FTP sont habilités à
restreindre la possibilité de telles manipulations. En général, les droits d'accès via FTP anonyme sont
limités au téléchargement de fichiers. Le numéro de port donnant accès aux serveurs FTP est le 21.
TFTP (Trivial File Transfer Protocol) ce protocole est un service non orienté connexion qui utilise le
protocole UDP. Il est utilisé sur le routeur pour transférer des fichiers de configuration et des images
IOS Cisco, il s'exécute plus rapidement que le protocole FTP dans un environnement stable. Le numéro
de port donnant TFTP est le 69.

c) Courrier E-MAIL
Le système E-Mail est moins uniforme que les autres services Internet, le " Mailing " fait appel à toute
une série des protocoles d’applications distinctes. Il faut ici différencier les protocoles utilisés pour le
transfert de courriers électroniques entre deux serveurs E-Mail, de ceux qui permettent à l'utilisateur
d'accéder à ses boites postales sur un serveur E-Mail.
13
Administration des
Le protocole SMTP (Simple Mail Transfer Protocol) est utilisé parmi d'autre dans le cadre du transfert
entre serveurs faisant office de bureau de poste électronique. Son numéro de port est le 25.
En ce qui concerne l'accès de l'utilisateur à sa boite postale, les protocoles POP2 (port 109) et POP3
(port 110) sont fréquemment utilisés. POP (Post Office Protocol) est un protocole qui permet de
récupérer les courriers électroniques situés sur un serveur de messagerie électronique.
d) Le protocole TELNET
A supposer que vous disposiez les droits d'accès correspondants, vous pouvez manipuler via FTP les
fichiers disponibles sur les supports de données du système distant.
Avec Telnet, vous pouvez lancer, à l'aide d'un client Telnet, des sessions de terminal sur un système
distant, puis exploiter pleinement celui-ci. Une fois que vous êtes connecté, tous les programmes et
commandes contenu dans le système distant sont mis à votre disposition.
De nombreux navigateurs Web sont également en mesure de gérer des sessions Telnet. Le numéro
de port donnant accès aux serveurs Telnet est le 23.
e) Les serveurs DNS
Les adresses IP dont il est question sur le lien URL IP sont des suites abstraites de nombres et ne sont
pas très pratiques pour l'utilisateur, c'est la raison pour laquelle, en plus des adresses IP, on attribue
aussi des noms aux ordinateurs.
Bien entendu, pour que l'on puisse identifier des ordinateurs à partir de ces noms, il faut que ces
derniers soient également attribués de manière à écarter toute possibilité de confusion. C'est dans ce
but que l'on à une fois de plus, imaginé un système hiérarchisé. Toutefois, sur le plan de la signification
de chaque niveau de la hiérarchie, ce système épouse moins strictement l'anatomie topographique du
réseau que celui des adresses IP. Cependant, leur hiérarchie est inversée, la partie située à l'extrémité
gauche des adresses IP représente le niveau hiérarchique le plus élevé, dans le cas de nom de
domaine. Celle-ci figure complètement à droite.
Le premier élément de chaque nom désigne un ordinateur, le second désigne un petit secteur
cohérent au sein d'Internet, dont fait partie l'ordinateur en question et cela continu ainsi jusqu'à la
dernière partie du nom, qui représente le secteur de coordonnée le plus vaste.
Aujourd'hui, le niveau le plus élevé de la hiérarchie contenu dans cet ultime élément du nom
correspond au pays dans lequel se trouve l'ordinateur. Cela n'est toutefois pas valable pour les
ordinateurs domiciliés dans le pays qui a vu naître Internet : les Etats Unis. Dans ce pays, Internet a été
divisé en six secteurs distincts, dès le début de son développement.
Les éléments utilisés pour le classement dans l'un de ces six domaines sont les suivants :
Nom de domaine Signification

COM " Commercial " Serveurs gérés par des entreprises commerciales
EDU " Éducationnel " Serveur gérés par des écoles et universités
GOV (GOUV) " Gouvernemental " Serveur gérés par les autorités gouvernementales
MIL " Militaire " Serveur gérés dans le cadre d'une installation militaire
ORG " Organisation " Serveur gérés par des associations privées à but non lucratif
NET " Réseau " Serveur gérés par des organismes responsables de la gestion ou
de l'organisation de réseaux informatique
DZ Serveurs dépendants de l’Algérie
FR Serveurs dépendants de la France
14
Administration des
Les demandes adressés aux Name Servers sont transmises à d'autres Name Servers, conformément à
la hiérarchie des éléments du nom de domaine indiqué. Ce processus relativement plus complexe est
appelé " Domain Name Lookup ".
f) Autre protocoles applicatifs :
NFS (Network File System) : ce protocole est un ensemble de protocoles pour systèmes de fichiers
distribués, développé par Sun Microsystems, permettant un accès aux fichiers d'un équipement de
stockage distant, tel qu'un disque dur.
SNMP (Simple Network Management Protocol) : est un protocole qui facilite l'échange d'information
de gestion entre les équipements du réseau. Il permet aux administrateurs réseau de gérer les
performances du réseau, de diagnostiquer et de résoudre les problèmes.
DHCP (Dynamic Host Configuration Protocol) : est un protocole réseau dont le rôle est d’assurer la
configuration automatique des paramètres IP d’une station, notamment en lui affectant
automatiquement une adresse IP et un masque de sous-réseau. DHCP peut aussi configurer l’adresse
de la passerelle par défaut, des serveurs de noms DNS et des serveurs de noms NBNS (connus sous le
nom de serveurs WINS sur les réseaux de la société Microsoft).
15
Administration des
Services Réseaux Le Service SNMP
Chapitre
Le Service SNMP
(Simple Network Management Protocol)
Dr. H. Zerrouki
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.1 PRESENTATION DU PROTOCOLE SNMP
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 les routeurs et les 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 permettent 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 : garantie 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 une importante garantie (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) :
Application
Présentation
SNMP
Session
Transport UDP
Réseau
Liaison
Physique
Figure II.1 – Le SNMP dans la hiérarchie des couches du modèle OSI.
12
Administration des
II.2 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 (NMS : network management system) : 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é.
Les tables MIB (Management Information Base): C’est une base de données maintenue par
l’agent qui contient les informations sur les transmissions de données et sur les composantes de
la station ou du routeur, etc. (ex : UPtime, configuration du routage, état du disque et du port
série, nombre de paquets reçus et envoyées, combien de paquets erronés reçus, etc.). Elles
contiennent l’ensemble des variables TCP/IP de la station. Ce sont les informations contenues
dans ces tables qui sont demandées par la station de gestion afin d’effectuer son travail.
Entité
d'administration
NMS
Agent Agent Agent
Base de Base de Base de

données données données

d'administration d'administration d'administration
Dispositifs administrés
Figure II.2 – Schémas de gestion de réseau avec SNMP.
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
13
Administration des
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.
II.3 LA STRUCTURE DE DONNEES (MIB)
L’élément le plus important dans le protocole SNMP est probablement qu’il a permis de décrire un
grand nombre de composants (réseaux ou autres) de façon standard. Cette description est faite dans
la MIB (Management Information Base), qui regroupe les informations d’intérêt pour les
administrateurs. On y retrouve toute l’expérience des spécialistes qui ont établi les modèles
concernant les sujets qu’ils maîtrisent, ce qui en fait tout l’intérêt pour les administrateurs réseau.
Le modèle n’est pas un modèle objet : les entités modélisées ne sont pas des objets au sens
informatique du terme, mais plutôt un ensemble de variables typées qui peuvent être lues ou mises à
jour. Un certain nombre d’astuces sont utilisées ensuite pour permettre de définir des opérations
complexes sur ces objets.
II.3.1 Nommage des objets
Chaque objet de la MIB est identifié par un nom et un OID (Object Identifier) qui le décrit de manière
unique dans un espace de nommage global et hiérarchique. Ce dernier est représenté par un arbre
inversé, dans lequel chaque bifurcation représente un objet.
Figure II.3 – Représentation de la MIB.
14
Administration des
Chaque objet possède un numéro unique qui le situe par rapport au nœud père, ainsi qu’un nom
symbolique. Le chemin suivi pour aller de la racine à l’objet constitue l’OID de celui-ci.
Exemple : sur la figure II.3, l’objet décrivant le nom d’une machine s’appelle sysName et a un OID
défini de la manière suivante :
sysName OBJECT IDENTIFIER ::= { iso org(3) dod(6) internet(1)

mgmt(2) mib-2(1) system(1) sysName(5)}
ou encore, s’il est défini à partir de son père :
sysName OBJECT IDENTIFIER ::= { system 5 }
En abrégé, il est noté .1.3.6.1.2.1.1.5
De fait, l’arbre de nommage de la figure II.3 est infini. Dans l’espace de nommage, seule la partie située
sous 1.3.6 (dod) est utilisée par SNMP. La partie supérieure est gérée par l’ISO, qui a prévu un espace
de nommage pour le DoD (Département de la Défense américain), organisme à l’origine d’Internet.
II.3.2 Modules de MIB
Les objets sont décrits par ensembles qu’on appelle «modules de MIB ». Par abus de langage, on les
appelle les MIB. Ils sont classés dans l’espace de nommage sous la branche «internet »:
- « mgmt(2)» contient tous les modules de MIB standard établis par l’IETF ;
- « expérimental(3)» contient les modules de MIB établis de manière expérimentale par
l’IETF (sachant qu’on les retrouvera sous leur forme définitive dans des sous-arborescences de
« mgmt », plus ou moins modifiés, après aboutissement du standard) ;
- « private(4)» contient les modules de MIB développés en dehors des standards IETF, par
exemple par des entreprises ou des centres de recherche. Les modules de MIB développés
sous cette arborescence sont communément appelés «MIB privées ».
Les modules de MIB IETF sont standardisés selon un processus décrit dans la RFC 2438 (Advancement
of MIB specifications on the IETF Standards Track), qui indique les critères qui permettent de savoir si les
implémentations sont multiples, indépendantes et interopérables, ce qui permet de faire évoluer la
RFC vers l’état de «proposed standard ».
II.3.2.1 MIB-2
La RFC 1213 (STD 17) décrit le module mib-2 qui recense les objets devant absolument être présents
sur un agent SNMP si les protocoles correspondants le sont (tableau II.1).
Groupe OID Description

system { mib-2 1 } Système géré: son nom, le type d’équipement, etc.
interface { mib-2 2} Interfaces réseau. La table ifTable contient la description, l’état et les
statistiques des interfaces.
at { mib-2 3 } Address Translation : atTable contient la table des adresses MAC (Media
Access Control) et réseau. Ce groupe est peu utilisé (deprecated) car

remplacé par les équivalents spécifiques à un protocole réseau.
ip { mib-2 4 } IP : configuration générale, statistiques, table des adresses (ipTable), de
routage (ipRouteTable), table ARP (Address Resolution Protocol) (ipNet-
ToMediaTable). ipRouteTable (21) est en principe remplacée par
ipForward (24) (défini dans la RFC 1354) car indexée par l’adresse
destination et donc ne supportant pas les routes multiples.
icmp { mib-2 5 } ICMP (Internet Control Message Protocol) : statistiques.
15
Administration des
tcp { mib-2 6 } TCP : configuration, statistiques générales et table des connexions (tcp-
Conn Table).
udp { mib-2 7 } UDP : statistiques et table des listeners (udpTable).
egp { mib-2 8 } EGP (Exterior Gateway Protocol) : statistiques et table des voisins (egpNei-
ghTable).
cmot { mib-2 9 } CMIP over TCP/IP : obsolète. Seul l’OID est réservé dans mib-2.
transmission { mib-2 10 } Ce groupe est prévu pour «raccrocher» d’autres modules de MIB qui
concernent des médias de transmission plus spécifiques qui viennent
compléter les informations contenues dans le groupe interface.
Par exempte : dot3 (7) décrit le média Ethernet, tandis que dot5 (9) décrit
Token-ring.
snmp { mib-2 11 } SNMP : statistiques.
Tableau II.1 – Groupes mib-2.
II.3.2.2 Extensions relatives aux interfaces
a) Média
Les objets spécifiques à un média sont définis dans un module de MIB spécifique, sous la branche de
MIB mib-2.transmission (tableau II.2). On retrouve en particulier dans ces modules des tables qui
complètent la table des interfaces ifTable avec des objets spécifiques au média (par exemple, collisions
pour Ethernet).
OID RFC Média
lapb(16) RFC 1381 X25 trame-LAPB
x25 (5) RFC 1382 X25 packet
dot3(7) RFC 2665 ethernet-like
dot5(9) RFC 1748 token-ring
fddi(15) RFC 1285 FDDI
ds1(18) RFC 1406 DS1/E1
isdnMib(20) RFC 2127 ISDN
ppp(23) RFC 1471 PPP
ds3(30) RFC 1407 DS3/E3
sip(31) RFC 1694 SONET IP
frame-relay(32) RFC 2115 Frame Relay DTE
rs232(33) RFC 1659 RS-232-like
para(34) RFC 1660 Parallel-printer
miox(38) RFC 1461 IP over X.25
LAPB : Link Access Protocol Balanced
DS : Digital Signal
ISDN : Integrated Services Digital Network
PPP : Point-to-Point Protocol
SONET : Synchronous Optical Network
Tableau II.2 – Exemples de branches de MIB sous mib-2.transmission.
b) Interface Group MIB

Le module «Interface Group MIB » (RFC 2233), dont l’OID est {mib-2 31}, étend et reprend les
définitions du groupe interface de mib-2. Il ne définit que des objets applicables, quel que soit le
média.
Les définitions des objets de la table d’interfaces ifTable sont précisées pour lever les ambiguïtés :
- les interfaces représentent des entités logiques (couches de protocole par exemple) ou
physiques ;
- les compteurs comptent les nombres délivrés au niveau supérieur ;
16
Administration des
- selon le type d’interface, tous les objets ne sont pas supportés (interfaces orientées caractère,
paquet ou bits), ce qui est défini à l’aide de conformance statements :
ifGeneralInformationGroup, ifPacketGroup, ifFixedLengthGroup ;
- pour ifNumber et ifIndex, il y a possibilité de «trous » dans la numérotation et possibilité
de changement de ifIndex après un boot.
La table ifXTable étend la table des interfaces et prend en compte les statistiques et définitions
d’interfaces en compteurs 64 bit (High Capacity Counters), pour les médias qui le nécessitent. Elle
permet aussi au manager SNMP de donner un alias aux interfaces, qui gardera sa valeur, contrairement
aux numéros d’interface. Il peut ainsi plus aisément retrouver les instances d’interface lors des boots.
Enfin, l’objet ifLinkUpDownTrapEnable permet de déterminer la remontée ou non de traps lors
des changements d’état, interface par interface.
II.3.2.3 Variables MIB Catégorie Signification
sysUpTime : Système Durée écoulé depuis dernier démarrage

ifNumber : Interfaces Nombre d'interfaces réseau
ifMtu : Interfaces MTU d'une interface particulière
ipDefaultTTL : Valeur utilisée dans le champ TTL
TIPE : Les protocoles pour la gestion des réseaux informatiques
Nguyen M_nh T_ng : Promotion 10 26
icmpInEchos : Nombre de demandes d'écho ICMP reçues
tcpInSegs : Nombre de segments reçus par TCP
udpInDatagrams : Nombre 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.
II.3.2.4 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 qui se passe et que
l'administrateur pourra interroger pour avoir des informations sur les collisions, les débits à un endroit
précis.
II.4 DESCRIPTION DES OBJETS : (SMI)
La structure SMI (Structure of Management Information) 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).
17
Administration des
Les objets définis avec ASN.1 peuvent être :
- des types, avec des types simples comme INTEGER ou BOOLEAN, et des types construits
permettant de définir des listes (SEQUENCE) et des tableaux (SEQUENCE OF) ;
- des valeurs, c’est-à-dire des objets ayant un type précédemment défini ;
- des macros, qui permettent d’étendre les définitions et définir de nouveaux types.
Par convention, les types commencent par une majuscule, les valeurs par une minuscule et les macros
sont tout entières en majuscules. Les commentaires sont précédés de deux tirets.
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).
•
32
Counter : entier de 32 bits non signé qui s'accroît de 0 à (2 -1) puis revient à 0.
• TimeTicks : compteur de temps sur 32 bits non signé en 1/100 de s.
II.4.1 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.
II.4.2 Syntaxe des objets
La MIB SNMP est composée de différents objets :
- objets partiels, qui servent à construire l’arborescence de la MIB. Ils n’ont pas de type, mais un
OID. Par exemple, l’objet system OBJECT IDENTIFIER ::= { mib-2 1 } groupe les objets de ma
mib-2 qui permettent d’identifier un agent SNMP ;
- objets scalaires, c’est-à-dire qu’ils ont une instance unique. Ils auront un type simple (faisant
partie de la syntaxe de base ASN.1), ou un type défini dans SMIv1 ou SMIv2 ;
- objets tabulaires : une table est décrite comme une séquence de lignes qui sont elles-mêmes
une séquence d’objets.
II.5 LES OPERATIONS SNMP
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 :
II.5.1 Lire les informations (GET)
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.
18
Administration des
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é. L'agent répond toujours par GetResponse. Toutefois si la variable demandée n'est pas
disponible, le GetResponse sera accompagné d'une erreur noSuchObject. Ils ont chacun une
signification bien distincte :
GetResponse : 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.
GetBulkRequest : (version 2 et version 3) Cette requête est une amélioration du SNMP, elle permet
aux stations de gestion (manager) d'interroger les objets gérés et les variables de la MIB des
agents. Il permet à la station de gestion de récupérer efficacement des grandes données.
gest_response
gest_response
set_next
set_next
event
event
get
set
get
set
Figure II.4 – Requêtes SNMP.
II.5.2 Modifier les informations (SET)
SetRequest : Cette requête permet aux stations de gestion de modifier une valeur de la MIB ou d'une
variable et de lancer des périphériques. Elle permet par exemple à un manager de mettre à jour
une table de routage. SetRequest provoque aussi le retour de GetResponse.
II.5.3 Type de non sollicités

Les alarmes TRAP : Lorsqu’un périphérique entre dans un état anormal, l’agent SNMP prévient le
gestionnaire SNMP par le biais d’un Trap SNMP. Les messages Trap peuvent être Link Up ou
Link Down (lorsque l’interface devient active ou au contraire passive), cold start (démarrage à
froid), warm start (démarrage à chaud), réinitialisation de l’agent SNMP, authentication failure
(échec d’authentification, lorsqu’un nom de communauté incorrect est spécifié dans une
requête), loss of EGP Neighbor (perte de voisin EGP).
19
Administration des
InformRequest : (version 2 et version 3) Le but de l'InformRequest-PDU est réellement de faciliter la

communication d'information entre les stations de gestion de réseau. L'agent SNMP sur un NMS
peut choisir d'informer des autres d'une certaine information en envoyant une InformRequest-
PDU à cet autre l'agent de SNMP.
Réseau IP
X Liaison hors service

Nom de communauté
Agent
= "poseid"
SNMP Agent
Gestionnaire SNMP
Trap : " liaison hs" Requète SNMP
SNMP
(public) Nom de
communauté = "Public"
Trap :
" Authentification failure "
Interrupteur
d'alimentation
Agent
SNMP
Trap : " démarrage à froid "
Figure II.5 – Les alarmes TRAP.
II.6 DESCRIPTION DU PROTOCOLE SNMP
II.6.1 Format des PDUs (messages) SNMP
Une requête SNMP est construite de la façon suivante :

Figure II.6 – Format des PDUs (messages) SNMP.
20
Administration des
• Version : Version de SNMP.

• Community : Nom de la communauté (agit comme un mot de passe).
• Request-id : Utilisé pour différencier les messages.
• Error-status : Utilisé pour signaler une erreur (0 si pas d'erreur).
• Error-index : Indique la sous-catégorie d'erreur.
• Variablebindings : Nom des variables avec leurs valeurs.
• Enterprise : Type de l'objet générant l'alarme.
• Agent-addr : Adresse de l'émetteur de l'alarme.
• Generic-trap : Identificateur de l'alarme.
• Specific-trap : Identificateur d'alarme spécifique.
• Time-stamp : Temps écoulé depuis la dernière réinitialisation de l'entité.
II.6.2 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, d'autres en
lecture/écriture (RW : Read/Write), d'autres encore en lecture seule (RO : Read Only), mais sur certaines
branches seulement. Chaque groupe devra disposer d'une sorte de mot de passe, appelé
"Community". Donc il existe deux communautés par défaut :
public : droit de lecture des informations de la MIB (RO);

private : droit de lecture et d'écriture (RW).
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.6.3 Envoie d’un message
Pour envoyer un message, l'agent de SNMP doit exécuter des procédures suivantes :
1. Utilise ASN.1 pour créer un PDU.

2. Ce PDU est émis à un service d'authentification, avec des adresses de destination, et de la
source et du nom de la communauté, le service d'authentification va alors exécuter leurs
opérations et les opérations de cryptage.
3. Le message est construit à partir du PDU avec l'ajout du nom de la communauté et la version
de SNMP.
4. Ce nouvel objet ASN.1, est enfin codé en utilisant BER et envoyé au service de transport.
II.6.4 Réception d’un message
Pour envoyer un message, l'agent de SNMP doit exécuter des procédures suivantes :
1. Le message est reçu et se voit opérer une vérification syntaxique. Si le message est défectueux,
il est ignoré.
2. Le numéro de version est vérifié, s'il n'est pas conforme, le message est ignoré.
3. Le nom d'utilisateur, le PDU, l'adresse de source et de destination au niveau transport, sont
émis à un service d'authentification.
• Si l'authentification échoue, le service prévient l'entité transport de SNMP, laquelle
envoie une alarme et ignore le message.
21
Administration des
• Si l'authentification réussit, le service renvoie un PDU de la forme d'un objet ASN.1 qui
se conforme à la norme RFC 1157.
4. L'entité du protocole va vérifier la syntaxe de message (sous la forme ASN.1). Si le message est
échoue, le message est ignoré. En revanche, le politique d'accéder SNMP est choisi et PDU est
traité continûment.
II.6.5 Interaction avec la couche transport UDP
Quelques rappels sur UDP

• Les trames UDP sont véhiculées dans les paquets IP comme étant des données.
• Chaque trame possède une adresse de source et une adresse de destination qui
permettent aux protocoles de niveau 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.
Il y a deux ports désignés pour l'utilisation de SNMP : le numéro 161pourles requêtes standard
et le numéro 162 pour l'écoute des alarmes destinées à la station d'administration.
Cas de perte PDU
UDP est un protocole qui n'est pas fiable à 100% et la perte de trames est donc possible. Or
rien n'empêche UDP de perdre un trame contenant un message SNMP. Dans ce cas, plusieurs
cas s'offrent à nous :
• Le paquet perdu est du type Get ou une réponse d'un agent administré. Cela provoque un
manque d'information au niveau de la station d'administration qui n'est pas important :
Voyant la réponse ne pas arriver, la station d'administration peut décider d'elle même de
renvoyer sa requête. L'identificateur de requête étant identique, il n'y a pas de risque de
recevoir plusieurs réponses dues à des questions dupliquées. En cas de non-réponse
permanent, cette station peut déclarer ce périphérique muet comme défaillant.
• Le paquet perdu est du type Set. Il est alors plus judicieux de faire un Get sur cette entrée
afin de savoir si c'est la requête qui a été perdue ou alors sa réponse.
• C'est une alarme qui a été perdue. Comme aucun acquittement n'est nécessaire suite à une
alarme, la station d'administration ne sera jamais avertie par le signal. Il est donc nécessaire
que la station d'administration scrute régulièrement l'état de ses agents pour se mettre au
courant des éventuels changements pour lesquels il n'aurait pas reçu d'alarme.
II.7 LES DIFFERENTES 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 : 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,
22
Administration des
des nouvelles opérations, des nouveaux types de données. La sécurité est basée sur les groupes de
SNMPsec.
SNMPv2c : 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 : 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* : 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*.
23
Administration des
Services Réseaux Les services annuaires
Chapitre
Les services annuaires
(DNS, DHCP et LDAP)
Dr. H. Zerrouki
Un service d’annuaire est un service réseau qui identifie toutes les ressources d’un réseau et met ces
informations à la disposition des utilisateurs ainsi que des applications. Les services d’annuaires sont
importants, car ils fournissent un moyen cohérent de nommer, décrire, localiser, administrer et sécuriser
les informations relatives à ces ressources et d’y accéder. Lorsqu’un utilisateur recherche un dossier
partagé sur le réseau, le service d’annuaire identifie la ressource et fournit l’information à l’utilisateur.
III.1 INTRODUCTION
Les particuliers et les entreprises ont de plus en plus recours aux réseaux pour accéder à des
applications distribuées et à des ressources partagées (sites web, serveurs d’applications, serveurs de
fichiers, etc.).
Ces applications et ces ressources doivent interagir avec des ordinateurs situés dans le même réseau
local, à travers l’intranet de l’entreprise, ou plus généralement au travers de l'Internet. Cela nécessite a
priori la connaissance des adresses de ces différentes machines. Or, dans la très grande majorité des
cas, on n'utilise jamais les adresses réelles des machines ; on utilise des noms.
Prenons des exemples simples. L’accès à un site web se fera par l’intermédiaire d’un nom désignant le
site. L’accès à une imprimante se fera également par l’intermédiaire d’un nom désignant l’imprimante.
Ces informations vont être gérées dans une base de données spéciale appelée annuaire. L’annuaire va
permettre de transformer le nom du site ou le nom de l’imprimante en une adresse physique
permettant aux protocoles de communication d’accéder aux équipements concernés.
De nombreux outils d’annuaires ont donc vu le jour au fil des années, offrant des services divers et
variés ; certains ont périclité, d’autres sont devenus immédiatement des standards incontournables, tel
DNS (Domain Name System).
Depuis quelques années maintenant, est apparu un nouveau standard, lui-même en passe de devenir
absolument indispensable connu sous le sigle LDAP (Lightweight Directory Access Protocol). Ce
standard ne remplacera pas DNS, ce n’est pas sa vocation, mais il permet d’unifier certains besoins tels
que ceux d’annuaires de type pages blanches, d’annuaires de type NIS (Network Information Service),
d’authentification, etc.
III.2 LES ANNUAIRES
III.2.1 Qu’est-ce qu’un annuaire ?
Un annuaire électronique peut être vu comme une base de données spécialisée, dont la fonction
première est de retourner un ou plusieurs attributs d'un objet grâce à des fonctions de recherche
multicritères.
28
Administration des
Les objets peuvent être de nature très diverse. Par exemple, un objet de l’annuaire peut représenter
une personne et les attributs de cet objet seront alors son nom, son prénom, son numéro de
téléphone, etc. Donnons un autre exemple (déjà évoqué plus haut) : un objet représentera une
imprimante et les attributs de l’objet seront alors les différents noms de cette imprimante, son adresse
réseau, sa situation géographique, etc.
La figure ci-dessous illustre l'implantation d'un service d'annuaires type. Les clients se connectent au
service d'annuaire pour interroger la base de données du service. Certains services d'annuaires
peuvent échanger des informations avec d'autres.
Se
rv
ic
ed
'a
n nu
ai
re
Figure III.1 – Exemple d’implantation d'un service d'annuaires.
Un annuaire électronique va centraliser des informations et les rendre disponibles, via le réseau, à des
applications, des systèmes d’exploitation ou des utilisateurs. Il va généralement s’appuyer sur les
éléments suivants :
Un protocole : échange des données proprement dit et indication des opérations à effectuer
sur ces dernières.
Un modèle fonctionnel : description de la nature des opérations que l'on peut effectuer,
comme par exemple une recherche, ou une modification.
Un modèle de nommage : identification des données ; organisation des différentes entrées

de l’annuaire.
Un modèle d'information : nature des données pouvant être enregistrées (des chaînes de
caractères, des nombres, des numéros de téléphone...).
Un modèle de sécurité : description des services de sécurité permettant d’assurer par

exemple le chiffrement des données transférées ou bien l’authentification du client vis-à-vis du

serveur.
Un modèle de distribution : création et gestion de serveurs secondaires dans un but de

sauvegarde ou de répartition de charge, création et gestion de liens spéciaux (referrals, méta-
annuaires) pointant vers des annuaires responsables d’une partie des données de l’entreprise
ou vers des annuaires complètement différents.
29
Administration des
III.2.1 Différences avec une base de données
Bien qu’un annuaire soit comparable à une base de données pour un grand nombre de
fonctionnalités, il en diffère en de nombreux points.
1. Un annuaire est très performant en consultation (c’est-à-dire en lecture ou en recherche ; la

lecture n’étant qu’une recherche particulière). Par contre, un annuaire n’est pas très adapté
pour des mises à jour fréquentes (autrement dit en écriture). Les données contenues dans un
annuaire sont en effet beaucoup plus pérennes, et il est donc totalement inutile d’optimiser les
fonctions de mise à jour.
Un annuaire doit, à l’opposé, supporter un nombre important de consultations simultanées.
L’exemple le plus évident est l’annuaire électronique téléphonique. L'optimisation de la
fonction « lecture » est donc à privilégier dans ce contexte.
2. Une base de données doit, par contre, généralement supporter des applications qui la
remettent constamment à jour. Cela signifie que la fonctionnalité « écriture » dans une base
de données est importante et doit par conséquent être optimisée. Parmi les exemples les plus
classiques de bases de données, on trouve :
• un système de réservation de billets d’avion ;

• un système de gestion des stocks d’une grande surface de distribution ;
• un gestionnaire de comptes bancaires.
3. Dans le cas d’un annuaire, par contre, l’accès en écriture est généralement réservé aux
administrateurs de l’annuaire ou bien aux propriétaires des informations. Il n'est donc pas
nécessaire que la fonction « écriture » soit optimisée ; ce type d'opération sera beaucoup plus
épisodique que la lecture.
4. Un annuaire ne supporte pas bien les transactions. Une transaction est caractérisée par
différentes propriétés que l’on peut résumer grâce à l’acronyme ACID : Atomicité, Cohérence,
Isolation et Durabilité.
a. Atomicité : une transaction doit être entièrement effectuée ou pas du tout (par
exemple, lors de la mise à jour de n éléments d’une table).
b. Cohérence : la cohérence entre tables d’une même base doit être respectée, même en
cas d’incident.
c. Isolation : pendant une transaction complexe, les autres transactions voient la totalité
des données à modifier dans l’état antérieur au démarrage de la transaction jusqu’à son
achèvement. Les résultats partiels ne sont donc pas accessibles, exceptées par les
opérations elles-mêmes.
d. Durabilité : lorsque la transaction est achevée, les modifications sont définitives, même
en cas d’incident.
Le plus souvent, l’isolation n’est pas du tout garantie dans le cas d’un annuaire. On peut, par exemple,
lancer une opération de modification composée de plusieurs requêtes, suivie d’une opération de
recherche sur les mêmes données. Les résultats de la recherche correspondront aux données en cours
de modification, et non pas avant la modification.
Ceci étant posé, il est évident que pour des raisons de facilité de mise en œuvre, les différents produits
existant sur le marché vont le plus souvent faire appel à des outils de base de données pour
matérialiser la base de l’annuaire proprement dit, plutôt que de mettre en œuvre un outil spécifique
pour gérer cette dernière.
30
Administration des
Partie I : Domain Name System (DNS)

Dans le monde de l'Internet, les machines du réseau sont identifiées par des adresses IP. Néanmoins, ces
adresses ne sont pas très agréables à manipuler, c'est pourquoi, on utilise les noms. L'objectif a alors été
de permettre la résolution des noms de domaines qui consiste à assurer la conversion entre les noms
d'hôtes et les adresses IP. La solution actuelle est l'utilisation des DNS (Domain Name System).
III.3 SYSTEME DE NOM DE DOMAINE (DNS)
III.3.1 Historique
Jusqu'en 1984, sur la suite des protocoles TCP/IP, la transcription de noms d'hôtes en adresses Internet
s'appuyait sur une table de correspondance maintenue par le Network Information Center (NIC), et ce
dans un fichier .txt, lequel était transmis par FTP à tous les hôtes. Il n'était à l'époque pas compliqué
de stocker les adresses puisque le nombre de machines était très réduit. Par ailleurs, avec la croissance
exponentielle d'Internet il a fallu trouver une autre solution, car les problèmes se sont multipliés :
• La mise à jour des fichiers : En effet il fallait retransmettre le fichier de mise à jour à tous les
hôtes, ce qui encombrait fortement la bande passante du NIC.
• L'autonomie des organismes : Avec l'évolution de l'Internet, les architectures ont été
transformées, ainsi des organismes locaux ont eu la possibilité de créer leur propres noms et
adresses, et ils étaient alors obligés d'attendre que le NIC prenne en compte leurs nouvelles
adresses avant que les sites ne puissent être visibles par tous sur Internet. Le souhait était alors
que chacun puisse gérer ses adresses avec une certaine autonomie.
Tous ces problèmes ont fait émerger des idées sur l'espace des noms et sa gestion. Les propositions
ont été diverses, mais l'une des tendances émergentes a été celle d'un espace de noms hiérarchisé, et
dont le principe hiérarchique s'appuierait autant que possible sur la structure des organismes eux-
mêmes, et où les noms utiliseraient le caractère "." pour marquer la frontière entre deux niveaux
hiérarchiques.
En 1983-1984, Paul Mockapetris et John Postel proposent et développent une solution qui utilise des
structures de base de données distribuée : les Domain Name System devenue obsolète. Les
spécifications des DNS ont été établies en 1987.
III.3.2 Définition de DNS
DNS (Domain Name System, système de noms de domaine) est une base de données distribuée
hiérarchisée qui contient les mappages de noms d’hôtes DNS à des adresses IP. Le système DNS est
utilisé dans les réseaux TCP/IP tels qu'Internet pour localiser des ordinateurs et des services à l'aide de
noms conviviaux.
Lorsqu'un utilisateur entre un nom DNS dans une application, les services DNS peuvent résoudre ce
nom en une autre information qui lui est associée, par exemple une adresse IP.
DNS permet également de découvrir des services réseau comme des serveurs de messagerie et des
contrôleurs de domaine dans le service d’annuaire Active Directory.
31
Administration des
III.3.3 Fonction de DNS
DNS est à la base du système de noms Internet, mais aussi du système de noms de domaine Active
Directory d’une organisation. Il prend en charge l’accès aux ressources à l’aide de noms
alphanumériques. Sans DNS, vous devriez trouver les adresses IP des ressources pour accéder à ces
ressources. Comme les adresses IP des ressources peuvent changer, il serait difficile d’en tenir à jour
une liste exacte. Au lieu de cela, DNS permet aux utilisateurs de faire appel à des noms
alphanumériques, lesquels restent assez stables dans une organisation.
Avec DNS, les noms d’hôtes résident dans une base de données qui peut être distribuée entre
plusieurs serveurs, ce qui diminue la charge de chaque serveur et permet d’administrer le système de
noms par partitions. DNS prend en charge des noms hiérarchiques et permet d’inscrire divers types de
données en plus du mappage de noms d’hôtes à adresse IP qui est utilisé dans les fichiers Hosts.
Comme la base de données DNS est distribuée, sa taille est illimitée et l’ajout de serveurs ne dégrade
guère ses performances.
L'illustration suivante représente une utilisation élémentaire de DNS qui consiste à trouver l'adresse IP
d'un ordinateur à partir de son nom.
Figure III.2 – Exemple d’une utilisation élémentaire de DNS.
Dans cet exemple, un ordinateur client interroge un serveur DNS pour lui demander l'adresse IP d'un
troisième ordinateur configuré pour utiliser le nom de domaine DNS www.ft.univ-tlemcen.dz. Le
serveur DNS étant en mesure de répondre à cette requête en interrogeant sa base de données locale,
il renvoie une réponse qui fournit l'information demandée, c'est-à-dire un enregistrement de ressource
A (adresse d'hôte) contenant l'adresse IP correspondant à www.ft.univ-tlemcen.dz.
Cet exemple illustre une requête DNS simple entre un client unique et un serveur DNS. En pratique,
les requêtes DNS sont souvent plus complexes que celle-ci et comprennent des étapes
supplémentaires.
III.4 ESPACE DE NOMS DE DOMAINES
III.4.1 Noms de domaines DNS
Le système de nom de domaine (DNS, Domain Name System) a été initialement défini dans les RFC
(Request For Comments) 1034 et 1035. Ces documents spécifient les éléments communs à toutes les
implémentations des logiciels DNS, qui comprennent entre autres :
• Un espace de noms de domaines DNS, qui définit une structure hiérarchique des domaines
permettant d'organiser les noms.
• Des enregistrements de ressources, qui mappent les noms de domaines DNS sur un type
spécifique d'informations de ressources et sont utilisés lorsque le nom est inscrit ou résolu
dans l'espace de noms.
• Des serveurs DNS, qui stockent les requêtes de noms portant sur des enregistrements de
ressources et y répondent.
32
Administration des
• Des clients DNS, également appelés solveurs, qui demandent aux serveurs de rechercher et
de convertir les noms en un type d'enregistrement de ressource spécifié dans la requête.
III.4.2 Présentation de l'espace de noms de domaines DNS
L'espace de noms de domaines DNS, illustré dans la figure ci-dessous, repose sur le concept
d'arborescence des domaines nommés. Chaque niveau de l'arborescence représente une branche ou
une feuille de cet arbre. Une branche est un niveau dans lequel plusieurs noms sont utilisés pour
identifier un ensemble de ressources nommées. Une feuille représente un nom unique utilisé une seule
fois à ce niveau pour identifier une ressource spécifique.
Figure III.3 – Structure arborescente de l'espace de noms de domaines DNS.
La figure précédente montre de quelle manière les serveurs racine Internet confèrent à Microsoft
l'autorité sur sa propre partie de l'arborescence des espaces de noms de domaines sur Internet. Les
clients et les serveurs DNS utilisent des requêtes pour convertir les noms de l'arborescence en types
spécifiques d'informations de ressources. Ces informations sont fournies par les serveurs DNS dans les
réponses aux requêtes des clients DNS, qui extraient ensuite ces informations et les transmettent à un
programme demandeur pour résoudre le nom faisant l'objet de la requête.
Dans le processus de résolution d'un nom, n'oubliez pas que les serveurs DNS fonctionnent souvent
comme des clients DNS qui interrogent d'autres serveurs afin de résoudre complètement une requête
de nom.
III.4.3 Structure arborescente de l'espace de noms
L'espace de nom est une arborescence de nœuds. Elle permet l'indexation sur les noms de domaines.
La racine de cet arbre est noté « . », nommé dot. Les nœuds situés à la profondeur 1 de l'arbre sont
appelés les domaines Top-Level Domain (ou root-level) : les TLDs. On distingue à ce niveau deux
groupes :
• un groupe dit de forward mapping qui met en correspondance les noms d'hôtes avec les
adresses IP. Ce groupe est représenté par des fichiers de données appelés fichier de forward
zone.
• un groupe de reverse mapping qui associe les adresses IP aux noms de machine. Ce groupe
est représenté par des fichiers de reverse zone.
33
Administration des
Figure III.4 – Hiérarchie du DNS, domaines et zones.
Le DNS utilise la gestion hiérarchique des noms, et pour des raisons essentiellement historiques, On
distingue deux domaines pour le classement des noms.
a) Les domaines géographiques
En général les domaines géographiques sont directement maintenus par des organismes
nationaux, l'AFNIC pour : USA (us), Royaume Uni (uk), la France (fr), Chine (cn) et l’Algérie (dz)
par exemple.
b) Les domaines génériques
Cette liste est définie par la Rfc 1591 - Domain Name System Structure and Delegation
.com - Commerciaux
.edu - Organismes d'éducation américaine
.net - Organismes de gestion de réseaux
.org - Organismes non-commerciaux
.int - Organismes internationaux
.gov - Organismes gouvernementaux USA
.mil - Organismes militaires USA
.arpa - Transition ARPAnet-> Internet + traduction inverse
Chaque nœud est étiqueté par un composant du nom de domaine, avec les règles suivantes :
Un nom de domaine est limité à 63 caractères au maximum.
• a priori insensible à la casse, cependant les implémentations ont tendance à tenir

compte de la casse.
• constitués de caractères alphanumériques et du - (tiret [hyphen]).
Les nœuds d'un même niveau doivent être uniques (sauf au niveau des feuilles), ce qui garantit un
espace sans collision. Enfin, les feuilles (nœuds terminaux) sont elles aussi étiquetées par des noms de
domaines (bien que souvent qualifiés de nom d'hôte).
34
Administration des
Un nom de domaine totalement qualifié (FQDNs : Fully-Qualified Domain Names) est la concaténation
des nœuds constituant un chemin dans l'arbre, d'origine une feuille et d'extrémité la racine. Chaque
composant est séparé de l'autre par un point (« . »).
III.4.3 Mode d'organisation de l'espace de noms de domaines DNS
Tout nom de domaine DNS utilisé dans l'arborescence est du point de vue technique un domaine.
Cependant, les noms sont généralement identifiés de cinq manières, selon leur niveau et leur mode
d'utilisation courant. Par exemple, le nom de domaine DNS inscrit au nom de Microsoft
(microsoft.com) est appelé un domaine de second niveau. En effet, ce nom est formé de deux parties
(appelées étiquettes) qui indiquent que le domaine est situé deux niveaux en dessous de la racine ou
du premier niveau de l'arborescence. La plupart des noms de domaines DNS comporte deux étiquettes
ou plus, chacune indiquant un niveau de l'arborescence. Les points sont utilisés pour séparer les
étiquettes.
Figure III.5 – Exemple de mode d'organisation de l'espace de noms.
Outre les domaines de second niveau, d'autres termes utilisés pour décrire les noms de domaines DNS
par leur fonction dans l'espace de noms sont décrits comme suite :
III.4.3.1 La racine du domaine
Il s'agit de la cime de l'arborescence, représentant un niveau non nommé. Elle est parfois
affichée sous la forme de deux guillemets vides (""), indiquant une valeur nulle. Lorsqu'elle est
utilisée dans un nom de domaine DNS, elle est indiquée par un point à droite (.) nommé dot,
pour indiquer que le nom est situé à la racine ou niveau supérieur de la hiérarchie du domaine.
Le nom de domaine DNS est alors considéré comme complet et désigne un emplacement exact
de l'arborescence des noms. Les noms exprimés de cette manière sont appelés des noms de
domaines complets (FQDN, Fully Qualified Domain Names). Un point (.) utilisé seul ou à la fin
d'un nom, tel que dans « ft.univ-tlemcen.dz. ».
III.4.3.2 Domaine de premier niveau
Nom de deux ou trois lettres utilisé pour indiquer un pays/une région ou le type d'organisation
utilisant un nom. « .dz », qui indique un nom inscrit au nom d'une entreprise pour une
utilisation commerciale sur Internet.
III.4.3.3 Domaine de second niveau
35
Administration des
Noms de longueur variable inscrits au nom d'un individu ou d'une organisation pour une
utilisation sur Internet. Ces noms sont toujours associés à un domaine de premier niveau
approprié, selon le type d'organisation ou l'emplacement géographique dans lequel un nom est
utilisé. « univ-tlemcen.dz », qui est le nom de domaine de second niveau inscrit au nom de
Microsoft par le Registre des noms de domaines DNS d'Internet.
III.4.3.3.4 Sous-domaine
Noms supplémentaires pouvant être créés par une organisation et associés au nom de domaine
de second niveau inscrit. Ils comprennent les noms ajoutés pour développer l'arborescence DNS
des noms dans une organisation et la diviser en services ou en emplacements géographiques.
« ft.univ-tlemcen.dz. », qui est un sous-domaine fictif défini par Microsoft pour être utilisé
dans les exemples de noms de la documentation.
III.4.3.5 Nom d'hôte ou de ressource
Noms qui représentent une feuille de l'arborescence DNS des noms et identifient une ressource
spécifique. Généralement, l'étiquette la plus à gauche d'un nom de domaine DNS identifie un
ordinateur spécifique du réseau. Par exemple, si un nom situé à ce niveau est utilisé dans un
enregistrement de ressource (RR) hôte (A), il doit être utilisé pour rechercher l'adresse IP de
l'ordinateur en fonction de son nom d'hôte. « www.ft.univ-tlemcen.dz. », où la première
étiquette (« www ») est le nom d'hôte DNS d'un ordinateur spécifique du réseau.
III.4.4 Type de serveurs et autorités
Par le découpage en zone on a donc trois types de serveurs de noms.
III.4.4.1 Le serveur primaire
Le serveur primaire est serveur d'autorité sur sa zone : il tient à jour un fichier appelé "fichier de zone",
qui établit les correspondances entre les noms et les adresses IP des hosts de sa zone. Chaque
domaine possède un et un seul serveur primaire.
III.4.4.2 Le serveur secondaire
Un serveur de nom secondaire obtient les données de zone via le réseau, à partir d'un autre serveur de
nom qui détient l'autorité pour la zone considérée. L'obtention des informations de zone via le réseau
est appelé transfert de zone. Il est capable de répondre aux requêtes de noms IP (partage de charge),
et de secourir le serveur primaire en cas de panne. Le nombre de serveurs secondaires par zone n'est
pas limité. Ainsi il y a une redondance de l'information. Le minimum imposé est un serveur secondaire
et le pré requis mais pas obligatoire est de le situer sur un segment différent du serveur primaire.
Un serveur qui effectue un transfert de zone vers un autre serveur est appelé serveur maître. Un
serveur maître peut être un serveur primaire ou un serveur secondaire. Un serveur secondaire peut
disposer d'une liste de serveurs maîtres (jusqu'à dix serveurs maîtres). Le serveur secondaire contacte
successivement les serveurs de cette liste, jusqu'à ce qu'il ait pu réaliser son transfert de zone.
III.4.4.3 Le serveur cache
Le serveur cache ne constitue sa base d'information qu'à partir des réponses des serveurs de noms. Il
inscrit les correspondances nom / adresse IP dans un cache avec une durée de validité limitée (TTL) ; il
n'a aucune autorité sur le domaine : il n'est pas responsable de la mise à jour des informations
contenues dans son cache, mais il est capable de répondre aux requêtes des clients Dns.
36
Administration des
De plus on peut distinguer les serveurs racine : ils connaissent les serveurs de nom ayant autorité sur
tous les domaines racine. Les serveurs racine connaissent au moins les serveurs de noms pouvant
résoudre le premier niveau (.com, .edu, .fr, etc.) C'est une pierre angulaire du système DNS : si les
serveurs racine sont inopérationnels, il n'y a plus de communication sur l'Internet, d'où multiplicité des
serveurs racines (actuellement il y en a 14). Chaque serveur racine reçoit environ 100 000 requêtes par
heure.
Un serveur de nom, en terme de physique, peux très bien jouer le rôle de plusieurs de ces fonctions.
On trouvera par exemple, beaucoup d'entreprise qui héberge leurs domaines sur le serveur DNS
primaire servant aussi de cache pour les requêtes sortantes des utilisateurs interne.
III.4.5 La diffusion des modifications " Le transfert de zones "
Pour chaque zone DNS, le serveur servant de référence est le DNS maître ou DNS primaire. Les DNS
esclaves ou secondaires servant cette zone vont récupérer les informations du DNS maître. Cette
récupération d'information est appelée transfert de zone. Seuls les DNS secondaires ont besoin d'être
autorisés à effectuer cette opération, mais assez souvent aucune restriction n'est présente. Ceci
permettant à n'importe qui de se connecter via nslookup et d'utiliser l'argument ls -d permettant
l'affichage du contenu d'une zone.
Lorsque des changements apparaissent sur une zone, il faut que tous les serveurs qui gèrent cette
zone en soient informés. Les changements sont effectués sur le serveur principal, le plus souvent en
éditant un fichier. Après avoir édité le fichier, l'administrateur signale au serveur qu'une mise à jour a
été effectuée, le plus souvent au moyen d'un signal (SIGINT). Les serveurs secondaires interrogent
régulièrement le serveur principal pour savoir si les données ont changé depuis la dernière mise à jour.
Ils utilisent un numéro constitué de la date au format américain: année, mois, jour; version du jour, il
est donc toujours incrémenté.
III.4.6 Les pannes
Lorsqu'un serveur primaire est indisponible, le serveur secondaire ne reçoit pas de réponse à ses
interrogations sur le numéro de version du fichier de zone. Il continue ses tentatives jusqu'à expiration
de la validité des enregistrements de son fichier de zone ('Expire Time'). Lorsqu'un serveur primaire
redevient disponible, aucun mécanisme de synchronisation entre le fichier de zone des serveurs
secondaires et celui du serveur primaire n'a été normalisé.
III.5 RECHERCHE DE RESSOURCES
III.5.1 Les Résolveurs
Les "résolveurs" sont des programmes qui interfacent les applications utilisateur aux serveurs de noms
de domaines. En effet, ce n'est pas l'utilisateur qui effectue les requêtes directement. Dans le cas le
plus simple, un résolveur reçoit une requête provenant d'une application (ex., Applications de courrier
électronique, Telnet, FTP) sous la forme d'un appel d'une fonction de bibliothèque, d'un appel système
etc., et renvoie une information sous une forme compatible avec la représentation locale de données
du système.
Le résolveur est situé sur la même machine que l'application recourant à ses services, mais devra par
contre consulter des serveurs de noms de domaines sur d'autres hôtes. Comme un résolveur peut
avoir besoin de contacter plusieurs serveurs de noms, ou obtenir les informations directement à partir
37
Administration des
de son cache local, le temps de réponse d'un résolveur peut varier selon de grandes proportions,
depuis quelques millisecondes à plusieurs secondes.
L'une des raisons les plus importantes qui justifient l'existence des résolveurs est d'éliminer le temps
d'acheminement de l'information depuis le réseau, et de décharger simultanément les serveurs de
noms, en répondant à partir des données cachées en local. Il en résulte qu'un cache partagé entre
plusieurs processus, utilisateurs, machines, etc., sera incomparablement plus efficace qu'une cache non
partagé.
III.5.2 Les Requêtes DNS
La principale activité d'un serveur de noms est de répondre aux requêtes standards. La requête et sa
réponse sont toutes deux véhiculées par un message standardisé. La requête contient des champs
QTYPE, QCLASS, et QNAME, qui décrivent le(s) type(s) et les classes de l'information souhaitée, et quel
nom de domaine cette information concerne. Les requêtes sont des messages envoyés aux serveurs de
noms en vue de consulter les données stockées par le serveur. Par exemple avec Internet, on peut
utiliser aussi bien UDP que TCP pour envoyer ces requêtes.
III.5.2.1 Structure des requêtes
Parmi les champs fixes on trouve 4 bits très importants appelé code d'opération (OPCODE). Le code
d'opération permet de donner des informations sur la nature du message (requête, réponse, ...). Les
quatre possibilités sont :
Question, Contient la question (nom d'hôte ou de domaine sur lequel on cherche des
renseignements et type de renseignements recherchés).
Answer, Contient les RRs (Ressource Records) qui répondent à la question.
Authority, Contient des RRs qui indiquent des serveurs ayant une connaissance complète de
cette partie du réseau.
Additional, Contient des RRs supplémentaires pouvant être utiles pour exploiter les
informations contenues dans les autres sections.
Voici un exemple de requête où l'on souhaite connaître le nom du serveur de courrier s'occupant de
frameip.com :
Header OPCODE=SQUERY
Question QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX
Answer vide
Authotity vide
Additionnal vide
38
Administration des
La réponse obtenue est :
Header OPCODE=SQUERY, RESPONSE, AA

Question QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX
Answer ISI.EDU MX 10 VENERA.ISI.EDU MX 10 VAXA.ISI.EDU
Authotity vide
VENERA.ISI.EDU A 128.9.0.32 A 10.1.0.52 VAXA.ISI.EDU A
Additionnal
10.2.0.27 A 128.9.0.33
III.5.2.2 Le mode Itératif
Ce mode est le plus simple du point de vue du serveur. Les serveurs répondent directement à la
requête sur la base seule de ses informations locales. La réponse peut contenir la réponse demandée,
ou bien donne la référence d'un autre serveur qui sera "plus susceptible " de disposer de l'information
demandée. Il est important que tous les serveurs de noms puissent implémenter ce mode itératif et
désactive la fonction de récursivité.
Les avantages d'une résolution itérative :

• Dans le cas d'une implémentation simplifiée d'un résolveur qui ne sait exploiter d'autres
réponses qu'une réponse directe à la question.
• Dans le cas d'une requête qui doit passer à travers d'autres protocoles ou autres "frontières" et
doit pouvoir être envoyée à un serveur jouant le rôle d'intermédiaire.
• Dans le cas d'un réseau dans lequel intervient une politique de cache commun plutôt qu'un
cache individuel par client.
39
Administration des
Le service non-récursif est approprié si le résolveur est capable de façon autonome de poursuivre sa
recherche et est capable d'exploiter l'information supplémentaire qui lui est envoyée pour l'aider à
résoudre son problème.
Figure III.6 – Le mode Itératif.
III.5.2.3 Le mode Récursif
Le mode récursif une fois est plus simple du point de vue du client. Dans ce mode, le premier serveur
prend le rôle de résolveur.
Figure III.7 – Le mode Récursif.
40
Administration des
L'utilisation du mode récursif est limitée aux cas qui résultent d'un accord négocié entre le client et le
serveur. Cet accord est négocié par l'utilisation de deux bits particuliers des messages de requête et de
réponse :
Le bit RA (Récursion Admissible), est marqué ou non par le serveur dans toutes les réponses. Ce bit est
marqué si le serveur accepte à priori de fournir le service récursif au client, que ce dernier l'ait
demandé ou non. Autrement dit, le bit RA signale la disponibilité du service plutôt que son utilisation.
Les requêtes disposent d'un bit RD (pour "Récursion Désirée"). Ce bit indique que le requérant désire
utiliser le service récursif pour cette requête. Les clients peuvent demander le service récursif à
n'importe quel serveur de noms, bien que ce service ne puisse leur être fourni que par les serveurs qui
auront déjà marqué leur bit RA, ou des serveurs qui auront donné leur accord pour ce service par une
négociation propriétaire ou tout autre moyen hors du champ du protocole DNS.
Le mode récursif est mis en œuvre lorsqu'une requête arrive avec un bit RD marqué sur un serveur
annonçant disposer de ce service, le client peut vérifier si le mode récursif a été utilisé en constatant
que les deux bits Ra et Rd ont été marqués dans la réponse.
Notez que le serveur de noms ne doit pas utiliser le service récursif s'il n'a pas été explicitement
demandé par un bit RD, car cela interfère avec la maintenance des serveurs de noms et de leurs bases
de données. Lorsque le service récursif est demandé et est disponible, la réponse récursive à une
requête doit être l'une des suivantes :
• La réponse à la requête, éventuellement préfacée par un ou plusieurs RR CNAME qui

indiquent les alias trouvés pendant la recherche de la réponse.
• Une erreur de nom indiquant que le nom demandé n'existe pas. Celle-ci peut inclure des
RR CNAME qui indiquent que la requête originale pointait l'alias d'un nom qui n'existe pas.
• Une indication d'erreur temporaire.
Si le service récursif n'est pas requis, ou n'est pas disponible, la réponse non-récursive devra être l'une
des suivantes :
• Une réponse d'erreur "autorisée" indiquant que le nom n'existe pas.

• Une indication temporaire d'erreur.
• Une combinaison :
- Des RR qui répondent à la question, avec indication si les données sont extraites d'une
zone ou d'un cache.
- D'une référence à un serveur de noms qui gère une zone plus "proche" du nom demandé
que le serveur qui a été contacté.
Les RR que le serveur de nom pense être utile au requérant pour continuer sa recherche.
III.5.2.4 Exemple de résolution de noms
Nous allons voir avec un exemple comment se fait le parcours de l'arborescence pour la résolution de
noms. On prend par exemple l'adresse suivante : www.univ-tlemcen.dz Il faut alors :
• Trouver le NS de la racine
• Interroger pour trouver le NS des .dz
• Poser la question finale au NS de univ-tlemcen.dz qui identifiera l'entrée www
41
Administration des
III.5.3 Les Requêtes inverses
III.5.3.1 Fonctionnement
Dans le cas d'une requête inverse, le solveur envoie une demande à un serveur de noms afin que celui-
ci renvoie le nom d'hôte associé à une adresse IP connue. C'est utile surtout pour des questions de
sécurité, pour savoir avec qui on échange. La mise en place de la résolution inverse est un peu plus
compliquée, car l'adressage par nom est basé sur la notion de domaine qui souvent n'a rien à voir avec
la structure des adresses IP. Par conséquent, seule une recherche approfondie portant sur tous les
domaines peut garantir l'obtention d'une réponse exacte. Deux moyens existent pour convertir une
adresse IP en nom d'hôte : l'usage de requêtes Dns inversées (Au sens Opcode=Iquery où Iquery = 1)
ou les requêtes Dns de type PTR (Classe IN et Opcode=Query).
En effet, dans le premier cas, on envoie un message Dns contenant une réponse et on demande toutes
les questions pouvant conduire à cette réponse, alors que les requêtes PTR posent la question de
façon explicite : Qui est l'adresse a.b.c.d ?
Une requête DNS inversée a la particularité d'avoir le champ Question vide, et de contenir une entrée
dans le champ Answer. Pour que le serveur DNS comprenne le sens de la requête, le champ Opcode
des en-têtes du message DNS doit être à la valeur Iquery. Voici une représentation :
Header OPCODE=IQUERY, ID=997

Question "EMPTY"
Answer "ANYNAME" A IN 10.1.0.52
Authotity "EMPTY"
Additionnal "EMPTY"
Pour répondre aux requêtes inverses en évitant des recherches exhaustives dans tous les domaines, un
domaine spécial appelé in-addr.arpa a été créé. Une fois le domaine in-addr.arpa construit, des
enregistrements de ressources spéciaux sont ajoutés pour associer les adresses IP aux noms d'hôte qui
leur correspondent. Il s'agit des enregistrements pointeurs (PTR), ou enregistrements de références.
Par exemple pour connaître le nom de la machine dont l'adresse est 137.194.206.1, on envoie une
requête dont la question contient QNAME=1.206.194.137.IN-ADDR.ARPA.
Exp. : Ligne de commande permettant d'établir la requête.

42
Administration des
Capture du datagramme Query
Capture du datagramme Answer :
III.6 FORMAT D'UN MESSAGE DNS
III.6.1 Le transport
a) Utilisation d'UDP
Le port serveur utilisé pour l'envoi des datagrammes en UDP est 53. Les datagrammes DNS en
UDP sont limités à 512 octets (valeur représentant les données sans l’entête UDP et IP). Les
datagrammes plus longs doivent être tronqués à l'aide du champ TC.
L'utilisation d'UDP n'est pas recommandée pour les transferts de zone, mais uniquement pour les
requêtes standards.
43
Administration des
b) Utilisation de TCP
Le port serveur utilisé pour l'envoi des datagrammes en TCP est 53. Le datagramme inclus alors
un champ de deux octets nommé "longueur", il permet de spécifier la longueur totale des
données indépendamment de la fragmentation. La longueur est calculée sans les 2 octets de ce
même champ.
Header
Question
Answer
Authority
additional
Figure III.8 – Format d'un message DNS
Nous décrivons l'entête dans la figure III.9. Les quatre sections suivantes ne contiennent pas
nécessairement de données.
• Pour les requêtes seules la section Question en possède.

• Les réponses aux requêtes de type A, PTR, CNAME figurent dans la section Answers
• Les réponses aux requêtes de type NS figurent dans la section Authority
• Enfin, les autres informations sont dans la section Additional.
III.6.2 L'entête d'un message DNS
Voici la structure de l'entête DNS basé sur 12 octets.
1 8 16
ID Number
QR Opcode AA TC RD RA Z Rcode
QDcount
ANcount
NScount
ARcount
Figure III.9 – Format de l'entête d'un message DNS.
ID : Codé sur 16 bits, doit être recopié lors de la réponse permettant à l'application de départ de
pouvoir identifier le datagramme de retour.
QR : Sur un 1 bit, ce champ permet d'indiquer s'il s'agit d'une requête (0) ou d'une réponse (1).
Opcode : Sur 4 bits, ce champ perme de spécifier le type de requête :
0 - Requête standard (Query)

1 - Requête inverse (Iquery)
2 - Status d'une requête serveur (Status)
3-15 - Réservé pour des utilisations futurs
44
Administration des
AA : Le flag Aa, sur un bit, signifie "Authoritative Answer". Il indique une réponse d'une entité
autoritaire.
TC : Le champ Tc , sur un bit, indique que ce message a été tronqué.
RD : Le flag Rd, sur un bit, permet de demander la récursivité en le mettant à 1.
RA : Le flag Ra, sur un bit, indique que la récursivité est autorisée.

Z : Le flag Z, sur trois bits, est réservé pour une utilisation futur. Il doit être placé à 0 dans tout les cas.
Désormais, cela est divisé en 3 bits : 1 bit pour Z, 1 bit pour AA (Authentificated Answer) qui indique si
la réponse et authentifiée, et 1 bit NAD (Non-Authenticated Data) qui indique si les données sont non-
authentifiées.
Rcode : Le champ Rcode, basé sur 4 bits, indique le type de réponse.

0 - Pas d'erreur
1 - Erreur de format dans la requête
2 - Problème sur serveur
3 - Le nom n'existe pas
4 - Non implémenté
5 - Refus
6-15 - Réservés
QDcount : Codé sur 16 bits, il spécifie le nombre d'entrée dans la section "Question".
ANcount : Codé sur 16 bits, il spécifie le nombre d'entrée dans la section "Réponse".
NScount : Codé sur 16 bits, il spécifie le nombre d'entrée dans la section "Autorité".
ARcount : Codé sur 16 bits, il spécifie le nombre d'entrée dans la section "Additionnel".
III.6.3 Les RR " Ressource Record"
La base de données des serveurs de noms (fichier de domaine et fichiers de résolution inverse) est
constituée "d'enregistrements de ressources", "Ressource Records" (RRs). Ces enregistrements sont
répartis en classes. La seule classe d'enregistrement usuellement employée est la classe Internet (IN).
L'ensemble d'informations de ressources associé à un nom particulier est composé de quatre
enregistrements de ressources séparés (RR).
1 8 16
Nom
Type
Classe
TTL
Longueur
Données
Figure III.10 – Format de l'entête RR (N octets).
Voici les différents champs d'un RR :
Nom : identifie l'entité, un hôte ou bien un domaine, que l'enregistrement décrit. Il doit commencer en
première colonne. Les noms sont soit absolus, soit relatifs. Les noms absolus se terminent par un point
45
Administration des
[dot] ; ils sont complets. En interne les programmes ne manipulent que des noms absolus, si un nom
ne se termine par un point il est complété avec le domaine courant et terminé par un point. Cela
permet d'utiliser les noms courts mais attention aux erreurs !
Type : Ce champ type, codé sur 16 bits, spécifie quels types de données sont utilisés dans le RR. Ils
sont cependant classifiables en 4 groupes :
• Zone : identification du/des domaine(s) et NS associés.

• Basic : les correspondances noms/adresses et routage de mail.
• Security : ajout de l'authentification et signature des fichiers de zone.
• Option : informations supplémentaires sur les hôtes et les domaines.
Classe : Une valeur encodée sur 16 bits identifiant une famille de protocoles ou une instance d'un
protocole. Voici les classes de protocole possible :
- In 01 Internet
- Cs 02 Class Csnet (obselete)
- Ch 03 Chaos (chaosnet est un ancien réseau qui historiquement a eu une grosse influence sur
le développement de l'Internet, on peut considérer à l'heure actuelle qu'il n'est plus
utilisé)
- Hs 04 Hesiod
TTL : C'est la durée de vie des RRs (32 bits, en secondes), utilisée par les solveurs de noms lorsqu'ils
ont un cache des RRs pour connaître la durée de validité des informations du cache.
Longueur : Sur 16 bits, ce champ indique la longueur des données suivantes.
Données : Données identifiant la ressource, ce que l'on met dans ce champ dépend évidemment du
type de ressources que l'on décrit.
A : Pour la classe IN, une adresse IP sur 32 bits. Pour la classe CH, un nom de domaine suivi
d'une adresse octale Chaotique sur 16 bits.
Cname : un nom de domaine.
MX : une valeur de préférence sur 16 bits (la plus basse possible) suivie d'un nom d'hôte
souhaitant servir d'échangeur de courrier pour le domaine de l'owner.
PTR : Une adresse IP sous forme d'un nom.
NS : Un nom d'hôte.
SOA : Plusieurs champs.
Voici un exemple montrant les différents champs saisies par Ethereal :

46
Administration des
47
Administration des
Partie II : Dynamic Host Configuration Protocol (DHCP)
Le protocole DHCP (Dynamic Host Configuration Protocol) est une extension de BOOTP, il fournit une
configuration dynamique des adresses IP et des informations associées aux ordinateurs configurés pour
l'utiliser (clients DHCP). Ainsi chaque hôte du réseau obtient une configuration IP dynamiquement au
moment du démarrage, auprès du serveur DHCP. Le serveur DHCP lui attribuera notamment une
adresse IP, un masque et éventuellement l'adresse d'une passerelle par défaut. Il peut attribuer beaucoup
d'autres paramètres IP notamment en matière de noms (l'adresse des serveurs DNS, l'adresse des
serveurs WINS).
III.7 SYSTEME DHCP
III.7.1 Définition
Un serveur DHCP (Dynamic Host Configuration Protocol ou protocole de configuration dynamique) a

pour rôle de distribuer des configurations IP à des clients d'une manière dynamique pour une durée
déterminée.
Au lieu d'affecter manuellement à chaque hôte une adresse statique, ainsi que tous les paramètres tels
que (serveur de noms, l'adresse de passerelle par défaut, @ip du réseau), un serveur DHCP alloue à un
client, un bail d'accès au réseau, pour une durée déterminée (durée du bail). Le serveur passe en param
ètres au client toutes les informations dont il a besoin.
Ce processus est mis en œuvre quand vous ouvrez une session chez un fournisseur d'accès Internet
par modem. Le fournisseur d'accès, vous alloue une adresse IP de son réseau le temps de la liaison.
Cette adresse est libérée, donc de nouveau disponible, lors de la fermeture de la session.
III.7.2 Avantages de DHCP dans l'administration d'un réseau
• Configuration fiable et simple : Le protocole DHCP offre une configuration de réseau TCP/IP
fiable et simple, empêche les conflits d'adresses et permet de contrôler l'utilisation des
adresses IP de façon centralisée. Ainsi, si un paramètre change au niveau du réseau, comme,
par exemple l'adresse de la passerelle par défaut, il suffit de changer la valeur du paramètre au
niveau du serveur DHCP, pour que toutes les stations aient une prise en compte du nouveau
paramètre dès que le bail sera renouvelé. Dans le cas de l'adressage statique, il faudrait
manuellement reconfigurer toutes les machines.
• Configuration sûre : DHCP évite les erreurs de configuration dues au besoin de taper
manuellement des valeurs sur chaque ordinateur. De plus, DHCP permet d'empêcher les
conflits d'adresses causés par une adresse IP affectée précédemment et réutilisée pour
configurer un nouvel ordinateur sur le réseau.
• Economie d'adresse : ce protocole est presque toujours utilisé par les fournisseurs d'accès
Internet qui disposent d'un nombre d'adresses limité. Ainsi grâce à DHCP, seules
les machines connectées en ligne ont une adresse IP.
En effet, imaginons un fournisseur d'accès qui a plus de 1000 clients. Il lui faudrait 5 réseaux
de classe C, s'il voulait donner à chaque client une adresse IP particulière. S'il se dit que
47
Administration des
chaque client utilise en moyenne un temps de connexion de 10 mn par jour, il peut s'en sortir
avec une seule classe C, en attribuant, ce que l'on pourrait appeler des "jetons d'accès" en
fonction des besoins des clients.
• Réduction de la gestion de la configuration : Les serveurs DHCP peuvent considérablement

diminuer le temps passé à configurer et reconfigurer les ordinateurs de votre réseau. Les
serveurs peuvent être configurés pour fournir une plage complète de valeurs de configuration
supplémentaires lors de l'affectation des baux d'adresses. Ces valeurs sont affectées à l'aide
des options DHCP.
Remarques
1. L'administrateur de réseau contrôle le mode d'attribution des adresses IP en spécifiant une

durée de bail qui indique combien de temps l'hôte peut utiliser une configuration
IP attribuée, avant de devoir solliciter le renouvellement du bail auprès du serveur DHCP.
2. L'adresse IP est libérée automatiquement, à l'expiration du bail.
III.7.3 Inconvénient de DHCP
Le client utilise des trames de broadcast pour rechercher un serveur DHCP sur le réseau, cela charge
le réseau. Si vous avez une entreprise avec plusieurs centaines de personnes qui ouvrent leur session le
matin à 8 h ou l'après midi à 14 h, il peut s'en suivre de graves goulets d'étranglement sur le réseau.
L'administrateur devra donc réfléchir sérieusement à l'organisation de son réseau.
III.8 PROTOCOLE DHCP
III.8.1 Fonctionnement de DHCP
Un client DHCP est un ordinateur qui demande une adresse IP à un serveur DHCP. Comment, alors, un
client DHCP, qui utilise le protocole TCP/IP mais qui n'a pas encore obtenu d'adresse IP par le serveur,
peut-il communiquer sur le réseau ?
Les choses se passent avec le peu de moyens dont vous disposez :
• Votre "MAC Address" que vous ne perdez jamais, puisqu'elle est écrite "en dur" dans votre
Interface Ethernet.
• Le "Broadcast" ou "Diffusion" qui permet d'envoyer des trames à toutes les machines du
réseau physique.
a) Création d'un bail DHCP
Le protocole DHCP utilise un processus en quatre étapes pour louer des informations d'adressage IP
aux clients DHCP. Ces quatre étapes sont nommées en fonction des types de paquets DHCP.
• Découverte DHCP
•
Offre DHCP
• Requête DHCP
• Accusé de réception DHCP ou accusé de réception DHCP négatif
Le processus de création d'un bail DHCP est le processus permettant au client DHCP de recevoir des
données de configuration d'adresse IP du serveur DHCP. Le dialogue est décrit de la manière suivante
(figure III.11) :
48
Administration des
Figure III.11 – Le processus de création d'un bail DHCP.
1. Lorsque le client DHCP démarre, il n'a aucune connaissance du réseau, du moins, en principe.
Il envoie donc une trame "DHCPDISCOVER", destinée à trouver un serveur DHCP. Cette trame
est un "broadcast", donc envoyé à l'adresse 255.255.255.255. N'ayant pas encore d'adresse IP,
il adopte provisoirement l'adresse 0.0.0.0. Comme ce n'est pas avec cette adresse que le DHCP
va l'identifier, il fournit aussi sa "MAC Address".
2. Le, ou les serveurs DHCP du réseau qui vont recevoir cette trame vont se sentir concernés et
répondre par un "DHCPOFFER".Cette trame contient une proposition de bail et la "MAC
Address" du client, avec également l'adresse IP du serveur. Tous les DHCP répondent et le
client normalement accepte la première réponse venue. Le "DHCPOFFER" sera un broadcast
(Ethernet) ou non, suivant le serveur DHCP utilisé.
3. Le client sélectionne la première adresse IP (s'il y a plusieurs serveurs DHCP) reçue et

diffuse un datagramme dans le réseau. Ce datagramme contient l'adresse IP choisi et
l'adresse IP du serveur choisi. Cette requête (DHCPREQUEST) à deux objectifs :
a) 1. Demander au serveur l'attribution de l'adresse IP proposée et les autres
paramètres de configuration (l'@IP passerelle, @IP réseau, le masque, @ de serveur
du nom, ...).
b) 2. informer les autres serveurs DHCP du réseau ayant fait une offre que le client ne
donne pas suite, ce qu'il libère les adresses IP proposées par ces serveurs.
4. Le serveur DHCP concerné répond définitivement par un DHCPACK qui constitue une
confirmation du bail comportant l'adresse IP et le masque de réseau (@IP de passerelle,@ de
serveur du nom) attribués au client. Trois autres champs sont ajoutés :
• La durée d'allocation de l'adresse.
• La date de demande de renouvellement.
• La période durant laquelle le client peut à nouveau diffuser des recherches DHCP (en
absence de réponse du serveur DHCP).
L'adresse du client est alors marquée comme utilisée et ne sera plus proposée à un autre client
pour toute la durée du bail.

b) Renouvellement d’un bail DHCP
Le processus de renouvellement d’un bail DHCP est le processus permettant au client DHCP de
renouveler ou de mettre à jour ses données de configuration d’adresse IP à l’aide du serveur DHCP.
49
Administration des
Le client DHCP renouvelle ses données de configuration IP avant l’expiration du bail. Si le bail expire
avant leur renouvellement, ces données sont perdues et il doit recommencer le processus de création
d’un bail DHCP.
Figure III.12 – Le processus de renouvellement d’un bail DHCP.
Un client DHCP tente automatiquement de renouveler son bail lorsque sa durée a expiré de 50 %. Il
essaie également de renouveler son bail d’adresse IP à chaque redémarrage de l’ordinateur. Pour
renouveler un bail, le client DHCP envoie un paquet DHCPREQUEST directement au serveur DHCP
duquel il a obtenu ce bail.
Si le serveur DHCP est disponible, il renouvelle le bail et envoie au client un paquet DHCPACK
contenant la durée du nouveau bail et les paramètres de configuration mis à jour. Le client met à jour
sa configuration lorsqu’il reçoit l’accusé de réception. Si le serveur DHCP n’est pas disponible, le client
continue à utiliser ses paramètres de configuration en cours.

Si le client DHCP ne parvient pas à renouveler son bail la première fois, il diffuse un paquet
DHCPDISCOVER pour mettre à jour son bail d’adresse lorsque 87,5 % de sa durée actuelle a expiré. À
ce stade, le client DHCP accepte un bail émis par n’importe quel serveur DHCP.
50
Administration des
c) Autre requêtes DHCP
DHCPDecline : Diffusion par un client DHCP vers un serveur DHCP, pour informer le serveur
que l'adresse IP proposée a été refusée car elle semble être en cours d'utilisation par un autre
ordinateur.
DHCPRelease : Envoyé par un client DHCP vers un serveur DHCP, de renoncer à une adresse IP
et l'annulation du bail en cours. Il s'agit de monodiffusion vers le serveur qui a fourni le bail.
DHCPInform : Envoyés à partir d'un client DHCP vers un serveur DHCP, vous demandant
uniquement pour les paramètres de configuration locaux supplémentaires ; le client a déjà une
adresse IP configurée. Ce type de message est également utilisé par les serveurs DHCP
exécutant Windows serveur pour détecter les serveurs DHCP non autorisés.
III.8.2 Etendue DHCP
a) Une étendue Simple
Une étendue est une plage d’adresses IP valides disponibles pour les baux ou l’attribution à des
ordinateurs clients sur un sous-réseau spécifique. Vous configurez une étendue sur le serveur DHCP
pour déterminer le pool d’adresses IP que le serveur peut attribuer aux clients DHCP.
Les étendues déterminent les adresses IP allouées aux clients. Vous devez définir et activer une
étendue avant que les clients DHCP puissent utiliser le serveur DHCP pour la configuration dynamique
du protocole TCP/IP. Vous pouvez configurer plusieurs étendues sur un serveur DHCP pour votre
environnement réseau.
Chaque sous-réseau possède une étendue DHCP unique contenant une plage d’adresses IP unique et
permanente. Des adresses ou des groupes d’adresses spécifiques peuvent être exclus de la plage
spécifiée par l’étendue DHCP. En général, une seule étendue peut être attribuée à un sous-réseau. Si
plusieurs étendues sont requises dans un sous-réseau, elles doivent d’abord être créées puis associées
dans une étendue globale.
b) Une étendue globale
Les étendues globales ou encore super étendues permettent d’attribuer des adresses IP de plusieurs
sous réseaux logiques à des clients DHCP se situant sur le même segment physique.
Les étendues globales sont utiles dans les cas suivants :
• Lorsque que vous n’avez plus assez d’adresses disponibles pour un sous réseau et que des
stations doivent être installées sur le même segment physique.
• Utilisation sur un même segment physique de plusieurs adresses réseau logique (multinet).
• Migration de clients DHCP dans une nouvelle étendue.
La suppression d’une étendue globale ne supprime pas les étendues qui la composent.
III.8.3 Relais DHCP
Lorsque le serveur DHCP et son client sont sur des réseaux disjoints distants de plusieurs routeurs. La
diffusion de la recherche DHCP aux autres réseaux s'effectue par les routeurs. Ces routeurs joueront le
rôle de relais DHCP.
51
Administration des
Le relais (le routeur) écoute les diffusions envoyées par les clients, lorsqu'un datagramme est reçu il est
retransmis vers le serveur DHCP du réseau voisin et lorsqu'il reçoit des datagrammes à partir d'un
serveur il diffuse sur le réseau du client DHCP.
Un agent de relais DHCP est un ordinateur ou un routeur configuré pour écouter les messages DHCP
des clients DHCP et les transmettre aux serveurs DHCP sur différents sous-réseaux. Les agents de relais
DHCP font partie des normes DHCP, et fonctionnent en conformité avec les documents RFC qui
décrivent le rôle du protocole et le comportement associé.
L'agent de relais DHCP prend en charge le processus de création d'un bail entre le client et le serveur
DHCP lorsqu'ils sont séparés par un routeur. Cela permet au client DHCP de recevoir une adresse IP du
serveur DHCP.
Un agent relais relaie les messages DHCP diffusés sur l'une des interfaces physiques qui lui sont
connectées, telle une carte réseau, vers d'autres sous-réseaux à distance auxquels il est connecté par
d'autres interfaces physiques. La figure suivante montre comment le Client DHCP du Sous-réseau A
obtient un bail d'adresse DHCP auprès du Serveur DHCP du Sous-réseau B.
Figure III.13 – Fonctionnement des agents relais.
1. Le Client C DHCP diffuse un message de découverte DHCP (DHCPDISCOVER) sur le Sous-

réseau A, en tant que datagramme UDP (User Datagram Protocol) qui utilise le port de serveur
UDP connu 67 (numéro de port réservé et partagé pour les communications des serveurs
BOOTP et DHCP).
2. L'agent relais, ici un routeur activé en tant que relais DHCP, examine le champ d'adresse IP de
la passerelle, qui figure dans l'en-tête du message DHCP. Si l'adresse IP de ce champ est
0.0.0.0, l'agent place dans ce champ l'adresse IP de l'agent relais ou du routeur et transmet le
message au Sous-réseau B où se trouve le serveur DHCP.
52
Administration des
3. Lorsque le Serveur DHCP du Sous-réseau B reçoit le message, il examine le champ d'adresse IP

de la passerelle pour trouver une étendue DHCP que le serveur DHCP peut utiliser pour fournir
un bail d'adresse IP.
4. Si le Serveur DHCP dispose de plusieurs étendues DHCP, l'adresse qui figure dans le champ
d'adresse IP de la passerelle (GIADDR) identifie l'étendue DHCP d'où il peut proposer un bail
d'adresse.
Par exemple, si le champ d'adresse IP de la passerelle (GIADDR) contient l'adresse IP

20.20.20.1, le serveur DHCP vérifie dans ses étendues d'adresses disponibles s'il trouve une
plage d'adresses d'étendue qui correspond au réseau IP de classe A contenant l'adresse de
passerelle en tant qu'hôte. Dans ce cas, le serveur DHCP vérifie s'il trouve des adresses
d'étendue situées entre 20.20.20.1 et 20.20.20.254. Lorsque le serveur DHCP trouve une
étendue qui correspond, il sélectionne une adresse disponible dans cette étendue et l'utilise
dans une réponse d'offre de bail d'adresse IP au client.
5. Lorsque le Serveur DHCP reçoit de le message DHCPDISCOVER, il traite et envoie une offre de
bail d'adresse IP (DHCPOFFER) directement à l'agent relais identifié dans le champ d'adresse IP
de la passerelle (GIADDR).
6. Le routeur relaie ensuite l'offre de bail d'adresse (DHCPOFFER) jusqu'au client DHCP. L'adresse
IP du client est toujours inconnue et doit donc être diffusée sur le sous-réseau local. De la
même façon, un message de demande (DHCPREQUEST) est relayé du client au serveur, et un
message d'accusé de réception (DHCPACK) est relayé du serveur au client.
III.8.4 Les messages DHCP
a) Dialogue avec le serveur
Les messages DHCP sont transmis via UDP. Bien que peu fiable, ce protocole suffit au transport des
paquets simples sur réseau local, et surtout il est très léger, donc intéressant pour les petits systèmes
(du genre le micro bout de programme qui fait la requête DHCP lorsque le PC se met en route). De
facto, DHCP fonctionne en mode non connecté. Le client n'utilise que le port 68 pour envoyer et
recevoir ses messages et le serveur envoie et reçoit ses messages sur un seul port, le port 67.
b) Format de la trame DHCP
La trame DHCP a le format suivant (les chiffres entre parenthèses indiquent la taille du champ en
octets) :
Figure III.14 – Format de la trame DHCP.
53
Administration des
− op : (opération) indique le type de message général. Vaut 1 pour BOOTREQUEST (requête

client), 2 pour BOOTREPLY (réponse serveur).
− htype : type de l'adresse hardware, identifie le type de matériel utilisé sur le réseau. Par
exemple, 1 correspond à Ethernet (adresse MAC, par exemple), 15 à un relais de trames et 20 à
une ligne série.
− hlen : longueur de l'adresse hardware (en octet). C'est 6 pour une adresse MAC.
− hops : (Sauts) contrôle le transfert des messages. Défini sur 0 par le client avant la transmission
d'une requête. Peut être utilisé par des relais DHCP.
− xid : (Identificateur de transaction) nombre aléatoire choisi par le client pour mettre en
correspondance la demande avec les réponses reçues des serveurs DHCP.
− secs : le temps écoulé (en secondes) depuis que le client a commencé sa requête ou de
renouvellement d'un bail par un client.
− flags : (Indicateurs) utilisés par un client qui ne connaît pas son adresse IPv4 lorsqu'il envoie une
requête.
− ciaddr : Adresse IP du client, champ utilisé par un client pendant le renouvellement de bail
lorsque l'adresse du client est valide et utilisable, mais pas au cours du processus d'acquisition
d'une adresse.
− yiaddr : Votre adresse IP, champ utilisé par le serveur pour attribuer une adresse IPv4 au client.
− siaddr : Adresse IP du prochain serveur : champ utilisé par le serveur pour indiquer l'adresse du
serveur que le client doit utiliser pour l'étape suivante du processus d'amorçage.
− giaddr : adresse IP du relais (passerelle par exemple) lorsque la connexion directe client/serveur
n'est pas possible.
− chaddr : adresse hardware du client, spécifie la couche physique du client.
− sname : (Nom du serveur) champ utilisé par le serveur envoyant un message DHCPOFFER ou
DHCPACK. Le serveur peut éventuellement saisir son nom dans ce champ.
− ile : Nom du fichier de démarrage (boot), champ facultatif utilisé par un client pour demander
un type particulier de fichier de démarrage dans un message DHCPDISCOVER.
− options : (Options DHCP) comprend les options DHCP, notamment plusieurs paramètres requis
pour le fonctionnement de base de DHCP.
Dans une précédente RFC, la taille de ce champ était limitée (limité à 64 octets par exemple pour la
première version de Bootp) ; maintenant, il n'y a plus de limitation.
Dans tous les cas, un client DHCP doit être prêt à recevoir au minimum 576 octets, mais la possibilité
lui est offerte de demander au serveur de restreindre la taille de ses messages.
c) Messages de détection et d'offre DHCPv4
• Message de détection : Le client DHCP envoie une diffusion IP dirigée avec un paquet
DHCPDISCOVER.
54
Administration des
• Dans cet exemple, le serveur DHCP se trouve sur le même segment et recueille cette requête.
Le serveur note que le champ GIADDR est vide, ce qui signifie que le client est sur le même
segment. Le serveur note également l'adresse matérielle du client dans le paquet de requête.
Figure III.15 – Message de détection DHCP.
• Message d'offre DHCP : Le serveur DHCP choisit une adresse IP dans le pool disponible de ce
segment, ainsi que l'autre segment et les paramètres globaux. Le serveur DHCP les place dans
les champs appropriés du paquet DHCP. Le serveur DHCP utilise ensuite l'adresse matérielle
de A (dans CHADDR) pour former une trame appropriée à renvoyer au client.
Figure III.15 – Message d’offre DHCP.
55

Administration Service

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

Administration Service

Transféré par

Droits d'auteur :

Formats disponibles

Administration des

Services Réseaux Présentation de l’administration réseau

Figure I.1 – Principe général d’un système d’administration réseau.

L’administration des réseaux informatiques implique le développement et la mise en place d'outils de

Un réseau comporte un grand nombre de composants (objets) que le système d’administration

Figure I.2 – La structure fonctionnelle d’un système d’administration.

I.2 OBJECTIFS ET ROLE DE L’ADMINISTRATION RESEAU

I.2.1 L’administrateur réseau

L'utilisation du matériel informatique et des logiciels doit se faire en fonction de l'environnement

Le rôle d’un administrateur réseau consiste (entre autre) à :

• Mettre en place et maintenir l’infrastructure du réseau (organisation, . . .).

I.2.2 Rôle de l'administration réseau

Le rôle de l'administration du réseau est indissociable de la structure d'organisation de l'entreprise. Les

La qualité de l’administration du réseau peut généralement être jugée en fonction de la disponibilité

Pour effectuer une bonne administration, l’administrateur a besoin de procédures d'interventions et

I.2.3 Objectifs de l'administration réseau

• Contrôle de la complexité – Avec la croissance massive du nombre de composants réseau,

• Amélioration du service – Les utilisateurs attendent des services similaires ou améliorés

• Contrôle des coûts – Surveillance et contrôle de l'utilisation des ressources, de manière à

I.3 OSI ET LE MODELE D'ADMINISTRATION RESEAU

L'organisme international de normalisation ISO (International Standards Organization) a créé un comité

Ce modèle se décline en quatre parties (Figure I.3):

Figure I.3 – Modèle d'administration réseau.

Le modèle d’informations est relatif à la structure et au stockage des informations d'administration

Figure I.4 – Les aires fonctionnelles de la gestion ISO.

I.3.1 Les différents modèles

Figure I.5 – Le modèle architectural de l’ISO.

Gestion des anomalies

• La surveillance des alarmes (filtre, report...),

• Définition des centres de coût,

Gestion de la configuration et des noms

La gestion de la configuration (Configuration management) consiste à maintenir un inventaire

Gestion des performances

la collecte d’information statistique afin de déterminer, en permanence, si le réseau est apte à

• La collecte d’information (mesure du trafic, temps de réponse, taux d’erreur...),

La gestion des performances nécessite de disposer d’outil de modélisation et de simulation pour

• Les contrôles d’accès au réseau,

I.4 RESEAU CLIENTS - SERVEURS

Dans l’informatique moderne, de nombreuses applications fonctionnent selon un environnement

I.4.2 Définition du modèle client/serveur

Figure I.6 – Le modèle client/serveur.

On distingue alors les deux composantes suivantes :

• Le client, qui envoie ses requêtes au serveur ;

I.4.3 Caractéristiques des systèmes client serveur

Les éléments qui caractérisent une architecture client serveur sont :

• Protocole asymétrique : Conséquence du partage de ressources, le protocole de communication

• Transparence de la localisation : L’architecture client serveur doit masquer au client la

• Encapsulation des services : Un client demande un service. Le serveur décide de la façon de le

I.4.4 La répartition des tâches

Dans l’architecture client/serveur, une application est constituée de trois parties :

• La logique des traitements

• La gestion des données

I.4.5 Les différents modèles de client/serveur

a) Le client -serveur de donnée

b) Le client -serveur de présentation

c) Le client –serveur de traitement

I.5 LA NOTION DE PORT ET DE SERVICES

I.5.1 Notion de port

Voici certains des ports reconnus les plus couramment utilisés :

Port Service ou Application

I.5.2 LES SERVICES DE LA COUCHE APPLICATION

Figure I.6 – Les protocoles de chaque couche du modèle OS.

de port donnant TFTP est le 69.