Installer Et Configurer Un Routeur

CISCO
Installer et configurer un routeur
André VAUCAMPS
Résumé
Ce livre sur les routeurs Cisco s’adresse à tous les techniciens et ingénieurs concernés par le déploiement, la configuration et la maintenance
de routeurs dans les réseaux informatiques.
Après avoir resitué le contexte des protocoles et services de la couche réseau, l’auteur pose les fondements du routage. Les problèmes
d’adressage sont également approfondis, l’ouvrage montre comment satisfaire les besoins d’une topologie en utilisant les masques de longueur
variable VLSM (Variable Length Subnet Mask). L’ouvrage s’intéresse ensuite au composant matériel routeur proprement dit et décrit son objet,
sa nature ainsi que son fonctionnement. Le lecteur est invité à prendre en main l’interface en ligne de commande CISCO (CLI – Command Line
Interface), interface commune à l’ensemble des produits CISCO. L’auteur propose au lecteur de maîtriser les fondements d’une méthode de
configuration cohérente. Le système d’exploitation CISCO IOS qui équipe les routeurs n’est pas oublié : la séquence d’amorçage, le nommage
des versions et la mise à jour de l’IOS sont décrits.
L’ouvrage se veut pratique, il s'agit de prendre en mains le routeur dans les différentes phases de sa vie en production et ce, dès sa sortie du
carton. Une place importante est accordée à la réalisation d’ateliers dans des environnements simulés ou émulés que le lecteur pourra
reproduire sur son PC (fichiers disponibles en téléchargement sur www.editions-eni.fr.
Les chapitres du livre :

Avant-propos - Le routage, initiation - Les routeurs - Tâches de configuration des routeurs - Gestion de la plate-forme logicielle CISCO IOS -
Exercices corrigés - Annexes
L'auteur
Ancien Responsable de Formation en Centre AFPA, André VAUCAMPS enseigne aujourd'hui dans les sections de Techniciens Supérieurs
en Réseaux Informatiques et Télécommunications d'Entreprise. Il est l'auteur des livres de préparation à la certification CCNA 640-802 aux
Editions ENI.
Ce livre numérique a été conçu et est diffusé dans le respect des droits d’auteur. Toutes les marques citées ont été déposées par leur éditeur respectif. La loi du 11 Mars
1957 n’autorisant aux termes des alinéas 2 et 3 de l’article 41, d’une part, que les “copies ou reproductions strictement réservées à l’usage privé du copiste et non destinées
à une utilisation collective”, et, d’autre part, que les analyses et les courtes citations dans un but d’exemple et d’illustration, “toute représentation ou reproduction intégrale,
ou partielle, faite sans le consentement de l’auteur ou de ses ayants droit ou ayant cause, est illicite” (alinéa 1er de l’article 40). Cette représentation ou reproduction, par
quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles 425 et suivants du Code Pénal. Copyright Editions ENI
Ce livre numérique intègre plusieurs mesures de protection dont un marquage lié à votre identifiant visible sur les principales images.
© ENI Editions - All rigths reserved - Moha Anisa - 1-

Avantpropos
Cet ouvrage n’estil qu’un livre de plus sur les réseaux ? C’est bien sûr la question qui taraude sans doute tout auteur
d’ouvrage technique, partagé entre une nécessaire humilité et le désir de faire œ uvre utile et différente. Remarquons
d’abord que l’abondance est surtout anglosaxonne et que les ouvrages rédigés en français et non traduits sont plutôt
rares. La seconde distinction vient de mon passé (et présent) de formateur de la formation professionnelle. Dans mon
activité quotidienne, je fais toujours suivre mes cours de nombreux ateliers dans lesquels mes élèves sont invités à
mettre en œ uvre et donc à vérifier ce qui a été affirmé pendant la partie théorique. Il est rare que l’objectif fixé soit
atteint au premier jet et la démarche que doivent alors adopter mes élèves s’approche de celle qu’il faudrait adopter
en vraie grandeur quand un sinistre se produit. L’apprenti administrateur devient enquêteur et la recherche de
solutions aux dysfonctionnements observés mobilise toutes ses ressources de logique. Ce modèle pédagogique a fait
ses preuves, l’apprentissage est ludique et la conclusion bien connue de mes élèves : « dans 99 % des cas, le
problème se situe entre le clavier et le dossier de la chaise !».
Ce qui distingue donc cet ouvrage, c’est d’avoir reproduit ce modèle en permettant le même type d’apprentissage, mais
cette fois délocalisé (en dehors de tout organisme de formation), en clair « à la maison ». Pour ce faire, l’ouvrage
progresse sur deux fronts, les exposés théoriques sont toujours accompagnés ou suivis de près par des vérifications
dans des contextes reconstitués presque réels. Observons qu’il n’aurait pas été possible de concevoir un tel ouvrage
dans les années 1980 ni même dans les années 1990. Ce n’est que depuis une époque récente, que puissance de
calcul, mémoire, génie logiciel se conjuguent pour rendre possible l’existence d’outils tels que VMware, Packet Tracer ou
GNS3. Avec de tels outils, il devient presque inutile de travailler au pied du matériel pour apprendre à s’en servir.
Le lecteur profitera au mieux de l’ouvrage s’il maîtrise le modèle de référence OSI en couches. De plus, le lecteur est
supposé averti des fondamentaux de l’adressage IP et notamment des modes d’obtention d’une adresse IP. En effet,
même si cet ouvrage comporte une partie dédiée à l’adressage, il s’agit plus de présenter les concepts de l’adressage
sans classe CIDR et du masque de longueur variable VLSM que d’initier à l’adressage.
Le premier chapitre balaye de façon large les services de la couche réseau. Les concepts fondamentaux du routage
sont passés en revue. Le lecteur est invité à réaliser une partition de bloc d’adresse en utilisant des masques de
longueur variable. Des mises en situation sont proposées en environnement simulé Packet Tracer. Les chapitres
suivants ambitionnent d’aider à installer, configurer et vérifier le fonctionnement d’un routeur. Les considérations
physiques (matériel, cartes, interfaces, câbles, alimentations…) ne sont pas escamotées. Des liens aident à retrouver
l’information utile dans la considérable documentation en ligne CISCO. La prise en main de l’interface en ligne de
commande, commune à tous les produits CISCO occupe bien sûr une place importante dans l’ouvrage. L’administrateur
doit connaître ses capacités d’édition, être familiarisé à l’utilisation de l’aide ainsi qu’à l’historique des commandes. Il
doit également être capable de retrouver une description exhaustive de toute commande de l’IOS sur le site CISCO
« CLI Command Lookup ». Il doit être capable enfin de structurer sa méthode de configuration, l’ouvrage pose les
jalons d’une telle méthode à la recherche de cohérence et de systématicité.
Un dernier chapitre est consacré au système d’exploitation CISCO IOS. Le maquis du nommage des versions est
défriché. La séquence de démarrage, l’influence du registre de configuration, les systèmes d’exploitation alternatifs
ROMMON et RxBoot sont examinés. Les mises en situation sont bâties pour acquérir de vrais savoirfaire tels la mise à
jour d’une image IOS ou le recouvrement de mots de passe perdus.
Les objectifs d’apprentissage seront atteints par toute personne motivée et pugnace qui dispose de cet ouvrage, d’un
PC suffisamment puissant et d’une connexion à Internet. Je prends cet engagement : à la fin de l’ouvrage, le lecteur
qui a réalisé l’ensemble des exercices et ateliers proposés dispose sans conteste de bases solides qui aideront à faire
de lui un administrateur réseau à prendre au sérieux quand il s’agit de mettre en service un routeur puis de le
configurer. Ce livre s’adresse donc autant à l’administrateur réseau qui doit déployer et configurer des routeurs CISCO
qu’à l’étudiant engagé dans un processus de certification professionnelle. Il sera utile enfin à toute personne
intéressée par une vraie pratique des matériels routeurs CISCO.
Le livre CISCO Protocoles, concepts de routage et sécurité dans la collection Certifications aux Éditions ENI inclut des
chapitres et ateliers supplémentaires afin d’optimiser une préparation à la Certification au CCNA 640802.

Le protocole IP
RFC utiles :
● RFC791 Internet Protocol Septembre 1981 ;
● RFC1122 Requirements for Internet Hosts Communication Layers Octobre 1989.
IP est le protocole de la couche Internet, c’est même le seul protocole de couche 3 utilisé sur Internet et le cursus CCNA
n’en étudie pas d’autre, se contentant de citer quelques protocoles de couche 3 assurant un service équivalent :
● IPX, Internetwork Packet eXchange, le protocole de la firme Novell pour son réseau Netware.
● Appletalk, longtemps utilisé par les ordinateurs Macintosh de la firme Apple.
Ces deux protocoles, qui offraient pourtant des solutions techniques intéressantes, ont été remplacés par IP dans un
mouvement de convergence que nous avions appelé « IP Everywhere ».
L’UIT (Union Internationale des Télécommunications) a développé ses propres spécifications : le service CLNS (Connection
Less Network Service) est implémenté dans le protocole de couche réseau CLNP (Connection Less Network Protocol) et
utilisé par le protocole de transport TP4 (Transport Protocol Class 4). L’avantage de CLNP est de proposer un espace
d’adressage plus large que IPv4 avec des adresses exprimées sur 20 octets et nous l’avions déjà cité dans l’historique
d’IPv6 puisqu’il avait servi de base à la proposition TUBA candidate à la succession de IPv4. Il est à peu près évident
que ces protocoles en resteront à tout jamais au stade des spécifications.
La fonction essentielle assurée par IP est l’acheminement au travers du réseau maillé, activité indissociable de
l’adressage. IP fonctionne en mode non connecté et assure un service de remise des datagrammes de type « Best
effort », il fait « de son mieux » pour assurer sa mission, il n’a pas la capacité de gérer des paquets non délivrés,
dupliqués, déséquencés ou corrompus. Si IP avait été conçu fiable, tous les échanges qui transitent sur le réseau
l’auraient été également au prix d’un alourdissement des entêtes et d’une plus grande complexité supportée par les
routeurs. Or, tous les transports ne nécessitent pas cette fiabilité, les transports de flux en temps réel (voix, vidéo) ont
d’autres exigences (délai, bande passante) pour lesquelles cette recherche de fiabilité serait même contreproductive.
Le vocable « datagramme » utilisé pour désigner le paquet IP rappelle cette non fiabilité, c’est le choix des concepteurs
d’Internet que de reporter la recherche de fiabilité sur les hôtes aux extrémités et donc sur la couche Transport dans ce
que nous avons appelé le contrôle de bout en bout. Chaque datagramme est acheminé dans le réseau
indépendamment des autres, ceci est possible parce que le datagramme porte à la fois les adresses source et
destination.
IP s’appuie sur les réseaux existants, faire transiter le paquet sur le média choisi incombe à la couche Liaison. À
nouveau, le principe d’indépendance des couches semble respecté mais il y a pourtant un accroc : la trame de la couche
Liaison ne peut pas accepter n’importe quelle taille de paquet (MTU). De la même façon que « la palette s’adapte au
véhicule Poids lourd », la couche Réseau doit s’adapter à la capacité de la couche Liaison et apprendre cette information
MTU :
Ainsi, dans l’exemple cidessus, parce que le MTU de la liaison entre routeurs est inférieur à celui des réseaux locaux
supportant les PC, IP du routeur R1 fragmente les données issues de PC1 ou PC2 lorsqu’elles sont destinées à PC3 ou
PC4. De la même façon, IP du routeur R2 fragmente les données issues de PC3 ou PC4 lorsqu’elles sont destinées à
PC1 ou PC2.
Ce qu’il faut en retenir :
IP fournit un service de remise :

● en mode non connecté ;
● dont l’unité de données, appelée datagramme, est associée à un format de paquet ;
● dont l’activité principale consiste à acheminer les paquets, c’est une activité distribuée puisque chaque nœ ud du
réseau (routeur) tente de rapprocher le datagramme de sa destination ;
● encadré par un certain nombre de règles (le liant…) qui précisent le comportement des hôtes et des routeurs
dans le traitement des paquets : génération de messages d’erreur, action « poubelle »…
1. Le datagramme IP
Voici le détail des différents champs, les champs à connaître dans le cadre du cursus sont accompagnés d’une mention
(→ champ clé)…
a. Champ Version
Seul champ qui occupe la même position dans le format IPv4 et le format IPv6, le numéro de version du protocole IP
est 4 ou 6 exprimé sur 4 bits.
b. Champ IHL (Internet Header Length)
Longueur de l’entête du paquet IP, requis parce qu’il existe un champ Options de longueur variable. À l’aide du
champ IHL, IP peut déterminer où se termine l’entête et où commencent les données. Attention, la valeur est
exprimée en unités de 32 bits ce qui entraîne que la longueur de l’entête est nécessairement multiple de 32, voir
aussi le champ Bourrage. La longueur de l’entête minimum s’établit à 20 octets (zéro option). La valeur contenue
dans le champ IHL étant limitée à 15 (4 bits), la longueur maximale de l’entête égale 60 octets (40 octets d’options).
Au final, la valeur du champ IHL est donc comprise entre 5 et 15.
c. Champ TOS (Type Of Service) (→ champ clé)
Attention, beaucoup de documents circulent avec une définition de ce champ qui n’a plus cours. En effet, le champ
TOS a déjà connu trois versions proposées dans les RFC suivants :
● la version du RFC791 décrivant le protocole IP ;
- 2- © ENI Editions - All rigths reserved - Moha Anisa

● RFC2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers Décembre
1998 ;
● RFC3168 The Addition of Explicit Congestion Notification (ECN) to IP Septembre 2001.
Ce champ existe également dans l’entête IPv6 mais devient le champ Classe de trafic.
Le contenu de ce champ tel qu’il était défini dans le RFC791 :
L’illustration suivante montre le contenu actuel de l’octet TOS :
Que se passetil lorsqu’un routeur ne parvient pas à écouler les paquets qu’il reçoit ? En temps normal, il peut se
produire des salves de paquets dont le rythme dépasse la capacité de traitement du routeur, ces paquets sont
placés en file d’attente et le routeur vient les chercher en séquence et à son rythme. Bien sûr, le système a une
limite et un flot d’entrée trop important peut provoquer la saturation de ces files d’attente, ce phénomène est appelé
congestion. Inévitablement, le routeur est amené à supprimer des paquets, il peut le faire de façon aléatoire (c’est
la notion du « Best effort »), mais à l’aide du champ DS (Differentiated Services), il devient possible de le faire de façon
plus intelligente. L’idée est de créer des classes de trafic caractérisées par une probabilité de rejet, les classes les
plus élevées correspondant aux probabilités de rejet les plus faibles.
Le RFC2474 définit la notion de PHB (Per Hop Behaviour), difficile à traduire mais il s’agit de définir un comportement
du routeur dans l’acheminement des paquets, selon la valeur de priorité DSCP (Differentiated Services Code Point)
contenue dans le champ DS. La valeur DSCP 000000 n’assure rien de plus que le comportement par défaut de type
« Best Effort ».
Pour les paquets nécessitant un traitement plus « Best » (« tous les hommes seront égaux mais ça ne sera pas
facile. Y’en a même qui seront …. Et pour eux, ça sera très dur », dixit le célèbre amuseur), les RFC 2597 et 2598
fournissent des valeurs de DSCP pour deux types de comportements :

● Le PHB « Expedited Forwarding » (traitement accéléré) défini dans le RFC 2598 puis 3246 offre une bande
passante garantie avec taux de perte, délai et gigue faibles, soit un service similaire à une réservation de
ressources (en bref, un circuit !). Ce PHB est destiné aux applications temps réel type téléphonie sur IP. Le
DSCP prend la valeur 46.
● Le groupe PHB « Assured Forwarding » (acheminement assuré) défini dans le RFC 2597, offre quatre classes
de service et trois niveaux de priorité (« precedence ») qui permettent de composer douze PHB différents. Un
fournisseur d’accès peut ainsi offrir différents niveaux de service définis par la bande passante allouée ainsi
que le volume des files d’attente. Les paquets conformes au groupe PHB AF sont affectés à une ou plusieurs
classes par le client ou le fournisseur d’accès selon le contrat de prestation souscrit. À l’intérieur d’une
classe, le paquet est à nouveau marqué par une priorité parmi trois, priorité qui est mise à profit en cas de
congestion dans la classe en question en arbitrant les suppressions de paquets.
Le tableau suivant regroupe les valeurs DSCP recommandées du groupe PHB AF :
La figure suivante illustre un exemple d’utilisation des PHBs AF pour le déploiement d’une offre « Triple Play » sur
ADSL :
Observez que les valeurs DSCP choisies n’interfèrent ni avec l’ancienne valeur de priorité 000 du champ TOS (« Best
effort »), ni avec les anciennes valeurs de priorité 11x correspondant à la gestion de réseau. Ceci permet aux
anciens routeurs « TOScapable » encore présents sur le réseau de continuer à fonctionner.
Le champ ECN (Explicit Congestion Notification) n’est apparu dans l’octet TOS que lors de sa dernière révision
proposée par le RFC3168. L’idée est de prévenir un émetteur que son émission en cours contribue à la formation
d’une congestion, ce avant que le rejet de paquets ne se produise. De plus, l’émetteur est prévenu à l’aide de
drapeaux positionnés dans les acquittements qu’il doit normalement recevoir, il n’y a pas de création de flux
supplémentaires pour alerter cet émetteur. Le pire serait en effet de créer un dispositif qui contribue à transformer le
risque de congestion en congestion effective.
Un routeur mesure le risque de congestion au remplissage de ses files d’attente. Lorsqu’un routeur utilisant ECN
veut prévenir une congestion (le remplissage moyen a dépassé un seuil), il marque les paquets qui sont « ECN
capable » c’estàdire les paquets qui portent un label certifiant que l’émetteur comprendra le marquage. Le
RFC3168 fournit la table suivante :
ECN Description
00 Non ECT (ECN Capable Transport), paquet non ECN
01 ECT(1) : paquet ECN pas encore marqué

10 ECT(0) : paquet ECN pas encore marqué
normalement mis à profit par TCP
11 CE (Congestion Experienced), paquet ECN marqué
Difficile d’aller plus avant dans la description de ce mécanisme car il faudrait disposer de solides connaissances sur le
protocole de transport TCP et aborder quelques notions quant aux stratégies possibles de gestion des files
d’attente.
d. Champ Total Length
Taille du paquet IP, entête + données, exprimée en octets. Le champ étant exprimé sur 16 bits, la longueur
maximale s’établit à 65535 octets mais il est probable qu’aucun hôte ni aucun réseau ne seraient en mesure de
traiter de tels datagrammes. Le RFC 791 précise, et le RFC 1122 le rappelle, que tout hôte doit pouvoir accepter des
datagrammes dont la longueur atteint 576 octets, que ces datagrammes arrivent en entier ou par fragments. Par
ailleurs, un hôte ne devrait émettre un datagramme de longueur supérieure à 576 octets que s’il a la certitude que
l’hôte distant peut l’accepter. On touche ici un point délicat qui pourrait faire l’objet d’un chapitre entier, d’autres
précisions sont fournies dans l’étude du protocole de transport TCP.
e. Champ Identification
Lorsque, pendant l’acheminement, un processus IP est contraint de fragmenter un paquet pour prendre en
compte le MTU du prochain saut, le processus IP destinataire final devra accomplir la tâche supplémentaire qui
consiste à réassocier les différents fragments afin de reconstituer le paquet initial. Il est aidé en cela par le champ
Identification (un « tag ») dont la valeur est générée aléatoirement dans le paquet initial, puis copiée dans chacun
des fragments.
f. Champ Drapeaux
Le bit de poids fort n’est pas utilisé et reste à 0. Les deux autres bits interviennent dans le processus de
fragmentation :
● Bit DF (Don’t Fragment) : positionné à 1, indique que le datagramme ne doit pas être fragmenté. Un routeur
qui n’aurait pas d’autre choix détruira le paquet tout en générant un message ICMP de compte rendu de
destination inaccessible ;
● Bit MF (More Fragment) : positionné à 1, indique que le datagramme n’est qu’une partie du datagramme
initial. Positionné à 0 avec une valeur de champ Fragment offset différente de 0, indique que le datagramme
est la dernière partie du datagramme initial.
g. Champ Fragment Offset (→ champ clé)
Sur 13 bits, permet le réassemblage d’un paquet fragmenté en fournissant la position dans le datagramme initial.
Hors entête, la position exprimée en octets est égale à 8 fois la valeur contenue dans le champ Fragment Offset
(Déplacement).
Exemple : soit à acheminer 1400 octets de données sur une liaison de MTU 620.
Le datagramme initial a été émis sur un LAN de MTU 1500. En admettant que l’entête IP ne comporte pas d’options,
chaque datagramme émis sur la liaison MTU 620 peut porter 620 20 = 600 octets de données.
● le premier datagramme porte le premier fragment de 600 octets, il en reste 800 ;
● le second datagramme porte le second fragment de 600 octets, il en reste 200 ;
● le troisième datagramme porte le dernier fragment de 200 octets.
Les valeurs correspondantes du champ Fragment Offset et du bit MF sont :
Numéro de fragment Données transportées Fragment Offset Bit MF

1 600 0 1
2 600 600/8 = 75 1
3 200 75 + 75 = 150 0
On identifie un datagramme non fragmenté lorsque bit MF et valeur de déplacement sont tous deux à 0.
h. Champ TTL ( → champ clé)
Sur 8 bits, durée de vie du datagramme dans le réseau exprimée en secondes. Chaque routeur qui fait transiter le
paquet décrémente la durée de vie d’au moins un quel que soit le temps inférieur à un passé dans le routeur. En
pratique, ce champ est donc plutôt à considérer comme un nombre de sauts maximum qui limite la portée du paquet
mais surtout qui permet d’éliminer un datagramme qui « errerait » dans le réseau sans jamais atteindre son
destinataire (boucle de routage).
i. Champ Protocol ( → champ clé)
Sur 8 bits, le champ Protocol contient le NSAP de couche 3, c’estàdire l’information qui permet au processus IP
destinataire de remettre la charge utile au protocole de couche 4 convenable. Ce mécanisme est appelé
démultiplexage de protocole :
Les numéros alloués sont bien connus et donc gérés par l’autorité IANA, on en trouve la liste sur le site :
http://www.iana.org/assignments/protocolnumbers/protocolnumbers.xhtml
Il est indispensable de connaître quelques valeurs telles ICMP → 1, TCP → 6 ou UDP → 17.
j. Champ Header checksum
La somme de contrôle de l’entête, exprimée sur 16 bits, permet de s’assurer de l’intégrité de l’entête du
datagramme IP. Un routeur qui reçoit un datagramme calcule cette somme puis la compare à la somme reçue. Si les
valeurs diffèrent, le paquet est détruit et le routeur génère un message ICMP. Si les valeurs sont identiques, le
routeur décrémente la valeur TTL ce qui l’oblige à recalculer une somme de contrôle qui vient remplacer la somme
reçue avant l’émission du paquet vers le routeur suivant. Le procédé de calcul est le suivant :

1) Mettre checksum à 0.
2) Calculer somme des mots de 16 bits qui composent l’entête.
3) Ajouter retenue1 à somme1.
4) Ajouter retenue2 à somme2.
5) Complémenter à 1 somme3 → on obtient la valeur recherchée.
k. Champ Adresse Source (→ champ clé)
L’adresse Source identifie l’expéditeur du datagramme et n’est pas modifiée par les routeurs, elle reste donc
inchangée pendant l’acheminement du paquet.
l. Champ Adresse Destination (→ champ clé)
L’adresse Destination identifie le destinataire final du datagramme et n’est pas modifiée par les routeurs, elle reste
donc inchangée pendant l’acheminement du paquet (sauf à nouveau s’il y a translation d’adresses).
m. Champ Options
La présence d’options est signalée par une valeur du champ IHL supérieure à cinq. Les options sont normalement
destinées à effectuer des tests pendant des phases de mise au point. L’organisation des options rappelle celle de la
zone vendeur de BOOTP : chaque option présente comporte un code option sur un octet suivi d’un champ longueur
et des données propres à l’option :

À titre d’exemple, l’option Enregistrement de route comporte une liste vide d’adresses IP lors de son émission par la
source. Puis chaque routeur qui fait progresser le datagramme ajoute son adresse IP à la liste, le champ Pointeur lui
permet de déterminer le prochain emplacement libre dans le champ Données de l’option.
n. Champ Padding (Bourrage)
Le champ IHL exprime la longueur de l’entête en unités de 32 bits, le champ Bourrage permet d’atteindre une
longueur multiple de 32 bits quand elle ne l’est pas naturellement. En l’absence d’options par exemple, le champ
Bourrage n’est pas nécessaire, la longueur de l’entête s’établissant alors à 5 x 4 octets.

La problématique du routage
RFC utiles :
● RFC791 Internet Protocol Septembre 1981 ;
● RFC823 DARPA Internet Gateway Septembre 1982.
Site utile : http://technet.microsoft.com/frfr/library/bb878104(enus).aspx
1. Prérequis indispensables
PC11 souhaite communiquer avec PC22, de quelles informations doitil disposer ?
En premier lieu, des informations le concernant :
● son adresse IP ;
● son masque réseau.
L’adresse IP répond à la question « Qui suisje ? ». Un ET logique entre l’adresse IP et le masque réseau fournit
l’adresse réseau et répond à la question « à quel groupe j’appartiens ? ». Ces deux informations font partie de la
configuration IP de la machine.
En second lieu, PC11 doit connaître l’adresse IP de PC22.
2. Le routage, une succession de sauts
Un acheminement consiste en une succession de sauts, chaque routeur qui fait transiter le paquet doit connaître une
route vers le réseau de destination :

1. Le processus IP de PC11 détermine que l’adresse de destination est extérieure. Il remet le datagramme à R11 via
10.0.11.1.
2. R11 connaît la route vers 10.0.22.0/24 via 10.0.8.8.
5. R22 connaît le réseau 10.0.22.0/24 puisqu’il lui est directement connecté et peut donc remettre le datagramme
directement à PC22.
On peut classer cette séquence de sauts en trois parties :
● Trouver le bon routeur de sortie (étape 1).
● Trouver le routeur destinataire (étapes 2, 3 et 4).
● Trouver la machine finale (étape 5).
3. Trouver le routeur de sortie
L’adresse de destination estelle locale ?
Par locale, on entend ici « appartientelle à la machine ? ». PC11 demande à son processus IP d’expédier un
datagramme. Le processus IP examine l’adresse de destination et le premier test consiste à vérifier que cette
adresse est bien extérieure à la machine. Dans le cas contraire, le datagramme passe directement du buffer émission
au buffer réception et n’est pas remis à la couche Liaison :

L’adresse de destination estelle directement connectée ?
Après avoir vérifié que l’adresse de destination n’est pas locale, le second test réalisé par le processus IP est le test
d’adjacence. Il s’agit de déterminer si le destinataire et l’expéditeur partagent le même réseau, autrement dit de
déterminer si le destinataire est directement connecté. Si la réponse est oui, les deux hôtes peuvent communiquer
sans nécessiter de périphérique intermédiaire de couche réseau (sans routeur), il reste pour l’expéditeur à vérifier
qu’il dispose de la correspondance @physique @logique dans son cache ARP, à déclencher une requête ARP pour le
cas où cette correspondance manquerait puis à remettre le datagramme à la couche Liaison.
Le test d’adjacence consiste en deux ET logique successifs :
● le premier ET logique est réalisé entre l’adresse IP de l’expéditeur et son masque, le résultat est l’adresse
réseau de l’expéditeur ;
● le second ET logique est réalisé entre l’adresse IP du destinataire et le masque, le résultat est comparé à
l’adresse réseau de l’expéditeur.
En cas d’égalité, les deux machines sont adjacentes c’estàdire directement connectées.
La figure suivante résume cette séquence d’évènements. PC11 d’adresse 10.0.11.2/24 tente un ping sur l’adresse de
PC15 10.0.11.5 :

L’expéditeur connaîtil une passerelle ?
Dernier scénario pour l’expéditeur, le test d’adjacence a montré que le destinataire n’était pas directement connecté.
La solution consiste alors à confier le datagramme à un périphérique intermédiaire, le routeur, qui fait office de
passerelle vers le réseau qui héberge le destinataire. L’adresse de la passerelle par défaut est un élément clé de la
configuration IP de la machine.
La figure suivante illustre ce scénario. PC11 d’adresse 10.0.11.2/24 tente un ping sur l’adresse extérieure 10.0.22.2.
La configuration IP de PC11 comporte la passerelle par défaut 10.0.11.1 :
L’acheminement de datagramme via la passerelle nécessite que station et passerelle partagent le même
réseau.

Station et passerelle sont directement connectées !
L’acheminement vu par la station, synthèse partielle
Au final, et puisque le cas d’une adresse de destination locale à la machine est avant tout un cas d’administrateur,
émettre un datagramme revient pour la station à se poser une seule question : l’adresse du destinataire estelle
directement connectée ou pas ?
Dans le premier cas, le datagramme est envoyé directement au destinataire. Dans le second cas, il est confié à la
passerelle, charge à elle de le faire progresser vers sa destination. Ce faisant, on a reporté la complexité du routage
et la nécessaire connaissance du réseau sur le routeur, un équipement spécialisé pour cette tâche.
La configuration IP de la machine conditionne le fonctionnement décrit. Les manipulations autour de ces thèmes ont
déjà été réalisées, en forme de rappel donc, la figure suivante montre comment imposer ou vérifier la configuration IP
d’une machine :
Que se passetil quand le réseau de l’émetteur comporte plus d’un routeur ?
Pour chaque station, l’administrateur attribue la fonction passerelle par défaut au routeur le plus approprié parmi les
routeurs présents sur le lien local. Quand ce routeur reçoit un datagramme et constate à l’examen de l’adresse de
destination qu’un autre routeur est plus approprié, il le fait savoir à la station en utilisant un message ICMP de
redirection.
4. Trouver le routeur destinataire, Notion de route
Le routeur passerelle se voit confier les datagrammes dont l’adresse de destination est extérieure au réseau. Charge
à lui de les faire progresser vers leur destination et pour ce faire, le routeur consulte sa table de routage à la
recherche d’une route vers le réseau en question. Comment se présente une route dans cette table de routage ?

A minima, il s’agit d’une correspondance entre un réseau qu’il est possible d’atteindre et l’adresse IP du prochain
routeur à qui il faut confier les datagrammes pour s’approcher de ce réseau ou l’atteindre. Ainsi dans l’exemple ci
dessus, le routeur R11 pour atteindre le réseau 10.0.12.0/24 doit confier les paquets à l’adresse 10.0.8.12. La route
est donc la correspondance 10.0.12.0/24 via 10.0.8.12.
L’apprentissage de cette route et par suite, le remplissage de la table de routage peut être le fait de l’administrateur,
on parle alors de routage statique. Il existe également des protocoles de routage qui, par des échanges réguliers
entre routeurs, permettent à chacun des routeurs de découvrir des informations de route ou de topologie de réseau,
le remplissage de la table de routage est alors automatisé, ce que l’on désigne par routage dynamique.
Sans entrer de route statique et sans avoir mis en œ uvre un quelconque protocole de routage, on pourrait penser
que la table de routage est vide. Mais si l’administrateur a fourni la configuration IP des interfaces du routeur, celuici
déduit de cette configuration les réseaux auxquels il est directement connecté, qui sont autant de routes
immédiatement présentes dans la table de routage :
Toutes les routes n’ont pas le même degré d’acuité. Vous êtes à Bruxelles et vous allez à Marseille. Au premier
croisement, deux routes se présentent : le panneau indicateur de la première indique « Toutes directions », le
panneau de la seconde indique « Marseille ». Vous êtes intrigué mais vous choisissez la seconde. Ainsi, le réseau
10.0.22.0/24 englobe la machine 10.0.22.2 mais le réseau 10.0.16.0/21 englobe le réseau 10.0.22.0/24 et donc la
machine 10.0.22.2. Dans sa table de routage, pour l’adresse de destination 10.0.22.2, le routeur préfèrera la route la
plus spécifique 10.0.22.0/24 à la route la plus générale 10.0.16.0/21 :

Pour trouver la route la plus spécifique, le processus de routage utilise l’algorithme de recherche de correspondance
de préfixe la plus longue (« Longest Match based Forwarding Algorithm »). Si toutes les recherches précédentes ont
échoué, le processus de routage utilise la route par défaut si elle existe. Enfin, pour le cas ultime où le processus de
routage n’a pas trouvé de route et ne dispose pas d’une route par défaut, le datagramme est supprimé
(« dropped », c’est l’action Poubelle) et le routeur génère un message ICMP « Destination Host Unreachable »
destiné à alerter l’émetteur du datagramme supprimé.
Dans ses activités de maintenance ou de mise au point, le contrôle des routes qui composent la table de routage du
routeur fait partie des outils essentiels de l’administrateur. Sur les routeurs CISCO, la commande permettant
d’afficher l’état en cours de cette table est :
Router> show ip route
Il n’y a pas de différence conceptuelle entre le processus de routage d’un routeur et celui d’une machine d’extrémité.
Les deux utilisent une table de routage. L’approche qui consiste à indiquer dans la configuration IP de la station
l’adresse d’un routeur privilégié appelé Passerelle par défaut revient à créer une route par défaut dans la table de
routage de la machine. Pour observer la table de routage de votre PC, en invite de commandes, tapez au choix l’une
des commandes suivantes :
c:\> netstat -r
c:\> route print
Pour PC11, cette route par défaut est 0.0.0.0/0 (le reste du monde) via 10.0.11.1 (la passerelle par défaut).
5. Trouver la machine finale
Le routeur R22 consulte sa table de routage et découvre que l’adresse de destination appartient à un réseau
directement connecté :

6. Travaux pratiques : l’acheminement
Ces notions sont immédiatement vérifiables à l’aide d’une simulation Packet Tracer.
■ Sur le site ENI, téléchargez la mise en situation TP1_9a.pkt. Une aide à l’utilisation de cet outil est fournie au
chapitre Annexes Prise en main de l’outil de Simulation Packet Tracer.
■ Exécutez Packet Tracer et avec lui, ouvrez la simulation.
a. Étape 1 : Visualisation de la table de routage
Seules les interfaces sont configurées sur les routeurs de cette simulation. Par conséquent, les seules routes
connues au démarrage de ce TP sont les réseaux directement connectés.
■ Restez dans le mode Temps réel.
■ Cliquez une fois sur le routeur R11 puis activez l’onglet CLI (Command Line Interface).
■ Appuyez sur la touche [Entrée] jusqu’à voir apparaître le prompt R11>.
■ Tapez la commande : R11> sh ip route
La commande « sh » est l’abrégé de « show ». Vous devriez obtenir :
C 10.0.8.0 is directly connected, FastEthernet0/0
■ Cliquez une fois sur PC11 puis activez l’onglet Desktop et cliquez sur Command Prompt.
Depuis PC11, nous nous proposons de taper plusieurs commandes ping de manière à tester toutes les interfaces
qui séparent PC11 de PC12.

■ Tapez les commandes :
PC> ping 10.0.11.2
PC> ping 10.0.11.1
PC> ping 10.0.8.11
En principe, jusquelà, tout se passe bien. Même la commande ping du réseau extérieur 10.0.8.0/24 réussit car ce
réseau est directement connecté à R11. Continuons…
■ Tapez la commande : PC> ping 10.0.8.12
b. Étape 2 : Ajout d’une route statique sur R12
Cela ne passe plus. N’oubliez pas que dans un échange ping, il y a une requête et un écho. La requête est émise
par PC11 et destinée à une interface extérieure au réseau de PC11, elle est remise à la passerelle R11 qui connaît
le réseau de destination puisqu’il lui est directement connecté. La requête parvient donc à l’interface 10.0.8.12.
Quid de la réponse ? Attention, l’interface 10.0.8.12 appartient au routeur R12 et c’est R12 qui doit émettre l’écho
en retour mais ce routeur disposetil d’une route vers le réseau de PC11 ? Le réseau 10.0.11.0 ne lui est pas
directement connecté, la réponse est NON.
Qu’à cela ne tienne, l’hardi administrateur ajoute une route statique sur R12.
■ Tapez la commande :
R12> en
Cette commande « en » est l’abrégé de « enable » et permet de passer en mode privilégié, prérequis pour
passer ensuite en mode de configuration. Dans la vraie vie, il faudrait montrer « patte blanche » en fournissant
un mot de passe. Observez également que le prompt est devenu « R12# » pour rappeler que CLI est en mode
privilégié.
R12# conf t
Cette commande « conf t » est l’abrégé de « configuration terminal » et permet de passer dans le mode de
configuration. À nouveau, le prompt rappelle l’état de CLI en cours en devenant « R12(config)# ».
R12(config)# ip route 10.0.11.0 255.255.255.0 10.0.8.11
Les informations sont précisées dans l’ordre réseau de destination, masque, adresse du prochain saut.
Traduction dans le cas présent : un datagramme destiné au réseau 10.0.11.0/24 doit être remis à l’interface
10.0.8.11.
R12(config)# exit
R12# sh run
Cette commande permet d’afficher la configuration en cours du routeur, elle le fait par pages. Tant que vous lisez
en bas de la fenêtre More, il suffit d’appuyer sur la barre d’espace pour obtenir la page suivante.

■ Faites défiler les pages du fichier de configuration en cours jusqu’à retrouver l’information de route entrée à
l’instant.
■ Revenu au prompt, tapez la commande :
R12# sh ip route
Vous devriez obtenir :
S 10.0.11.0 [1/0] via 10.0.8.11
La route que nous venons d’ajouter à la table de routage est précédée de la lettre S qui rappelle qu’il s’agit d’une
route statique, autrement dit une route entrée par l’administrateur.
c. Étape 3 : Ajout d’une route statique sur R11
Il reste à reprendre la série de commandes ping là où nous l’avions interrompue.
PC> ping 10.0.8.12
En principe, cela fonctionne, notre intervention sur R12 a été efficace. Continuons…
PC> ping 10.0.12.1
À nouveau c’est un échec et à nouveau l’administrateur doit se poser les deux questions : la requête peutelle
être acheminée ? Puis l’écho peutil être acheminé ? Dans le cas présent, c’est cette fois la requête qui pose
problème car le réseau 10.0.12.0/24 n’est pas directement connecté au routeur R11. Le processus de routage ne
trouve pas de route vers ce réseau dans la table de routage.
L’administrateur propose d’entrer une route statique sur R11.
R11> en
R11# conf t
R11(config)# ip route 10.0.12.0 255.255.255.0 10.0.8.12
Traduction dans le cas présent : un datagramme destiné au réseau 10.0.12.0/24 doit être remis à l’interface
10.0.8.12.
R11(config)# exit
R11# sh ip route
- 10 - © ENI Editions - All rigths reserved - Moha Anisa

Vous devriez obtenir :
S 10.0.12.0 [1/0] via 10.0.8.12
d. Étape 4 : Visualisation de l’action Poubelle
On reprend la série de commandes ping là où nous l’avions interrompue.
PC> ping 10.0.12.1
PC> ping 10.0.12.2
Sauf erreur, PC11 parvient maintenant à joindre PC12, il a fallu pour cela ajouter une route statique sur chacun
des deux routeurs R11 et R12.
■ Passez en mode Simulation.
■ Cliquez sur le bouton Add Simple PDU (l’enveloppe affublée d’un signe +) puis cliquez une première fois sur
PC11 et une seconde fois sur PC22.
Vous avez ainsi préparé une requête ICMP Ping sur PC11 et destinée à PC22, chaque appui sur le bouton
Capture/Forward fait progresser la requête.
■ Cliquez une première fois sur le bouton Capture/Forward, la requête parvient à R11.
Observez que R11 supprime le datagramme et génère un message ICMP (une enveloppe rouge).
■ Cliquez une seconde fois sur le bouton Capture/Forward, le message ICMP est renvoyé à la station PC11 par
R11.
■ Dans la fenêtre Event List, cliquez sur le carré de couleur associé au message ICMP reçu par R11 puis décodez la
couche 3 côté « Out Layer ».
Le routeur R11 ne dispose pas de route pour l’adresse de destination et supprime le datagramme (The routing
table does not have a route to the destination IP address. The router drops the packet.).
■ Dans la fenêtre Event List, cliquez sur le carré de couleur associé au message ICMP reçu par PC11 en retour puis
décodez la couche 3 côté « In Layer ».
Il s’agit d’un message ICMP « Destination injoignable » (The ICMP process received a Host Unreachable
message).
e. Étape 5 : À vous de jouer !
À ce stade, vous devriez pouvoir persévérer de façon autonome dans cette simulation, par exemple en ajoutant les
routes convenables pour que PC22 soit joignable depuis PC21 ou pourquoi pas, en assurant la connectivité de
chacun des quatre PC vers les trois autres. Au pire, si la simulation est détériorée, quittez sans sauvegarder puis
rechargez. En dernier ressort, il reste la possibilité de télécharger à nouveau le fichier de simulation.
Cette séance de travaux pratiques est terminée.
© ENI Editions - All rigths reserved - Moha Anisa - 11 -

Routage statique ou dynamique
1. Routage statique
Les notions découvertes pendant la séance de travaux pratiques sont suffisantes. En résumé, une route statique est
le fait de l’administrateur, il faut l’inscrire manuellement dans la table de routage.
Parmi les inconvénients :
● toute modification de topologie requiert l’intervention de l’administrateur ce qui peut rapidement devenir
pesant ;
● la panne d’un équipement ou d’une interface est une modification de topologie accidentelle, non planifiée. Le
temps d’indisponibilité est fonction du délai de prise en compte du défaut par l’administrateur.
Parmi les avantages :
● Le routeur n’a pas à consacrer une partie de ses ressources à l’entretien d’un protocole de routage (CPU,
mémoire).
Les domaines d’emploi du routage statique sont :
● les petits réseaux ;
● les réseaux privés connectés à l’Internet via un seul fournisseur d’accès.
2. Routage dynamique
À l’aide d’un protocole de routage, un routeur partage des informations concernant les réseaux qu’il connaît avec
d’autres routeurs qui utilisent le même protocole. Chaque correspondance @réseau distant @prochain saut (chaque
route) mentionne le mode d’apprentissage de la route (S pour statique, C pour directement connectée, R pour RIP…).
Les correspondances sont maintenues à jour au fur et à mesure de la vie du réseau. C’est même l’une des
performances attendues d’un protocole de routage que de diminuer autant que faire ce peut le temps qui s’écoule
entre une modification de topologie, planifiée ou accidentelle, et sa prise en compte dans les tables de routages. Ce
délai est appelé « temps de convergence ».
3. La table de routage
Routage statique et dynamique peuvent être utilisés conjointement, la table de routage comporte alors :
● des routes directement connectées ;
● les premières à apparaître dans la table ;
● leur présence est obligatoire (un routeur sans interfaces n’a pas de sens) ;
● une route directement connectée n’apparaît que lorsque l’interface correspondante est active ;
● des routes statiques ;
● des routes dynamiques.
Seules les routes statiques et dynamiques concernent les réseaux distants (non directement connectés).
La table de routage est stockée en mémoire RAM et doit donc être reconstruite à chaque initialisation de l’équipement.

4. Les protocoles de routage
a. Notion de système autonome
Vouloir propager l’information de topologie de chaque routeur sur l’ensemble de la planète est hors de portée
(consommation de bande passante, difficultés de maintenance, sécurité). Le réseau mondial résulte d’un assemblage
de systèmes autonomes. Un système autonome (« AS », Autonomous System) est un ensemble de réseaux et de
routeurs partageant le même protocole de routage et géré par une même autorité administrative.
b. Protocoles de routage internes, externes
Les protocoles mis en œ uvre dans un système autonome appartiennent à la famille des IGP (Interior Gateway
Protocol). Entre systèmes autonomes interviennent les procoles EGP (Exterior Gateway Protocol) mais cette famille se
résume au seul protocole actuellement viable BGP (Border Gateway Protocol).

Les protocoles IGP fondent leurs décisions sur des critères de performances, débit, fiabilité, nombre de sauts… Le
protocole BGP intègre en plus des critères politiques. Imaginons que vous ayez à établir un plan de vol de
Compiègne au nord de Paris à Etampes au sud de Paris, un protocole IGP trace une route directe qui vous fait
survoler Paris. Le protocole BGP vous fera contourner Paris parce que le survol de la capitale est interdit.
La famille des protocoles IGP est une famille nombreuse mais essentiellement fondée sur deux technologies : le
routage à vecteur de distance et le routage à état de liens.
c. Vecteur de distance
Ce sont les chercheurs pères fondateurs de cette technologie qui ont baptisé ainsi leur idée, très simple au
demeurant. Au démarrage, chaque routeur ne connaît que les routes auxquelles il est directement connecté.
L’ensemble des routes est contenu dans la table de routage. Chaque correspondance est associée à une distance
exprimée en nombre de sauts qui sépare le routeur du réseau de destination. Ainsi, la distance associée à une route
directement connectée est 0.
Chaque routeur diffuse périodiquement le contenu de sa table de routage à tout routeur directement connecté.
Chaque routeur qui reçoit des informations de route, met à jour une entrée de la table dans les trois cas suivants :

● la destination était connue mais la route reçue vers cette destination est à distance plus courte ;
● la destination était inconnue ;
● la route vers une destination passe par le routeur R qui informe que la distance a changé.
Dans l’exemple de la figure cidessus, quelques diffusions seront nécessaires avant d’atteindre l’état stable
suivant (le réseau a convergé) :
Observez les valeurs de distance : le routeur R2 annonce à R1 qu’il connaît le réseau Y avec une distance de 0. R1
place dans sa table le réseau Y mais avec une distance de 1 c’estàdire augmentée de la distance qui permet
d’atteindre R2. R2 annonce à R1 qu’il connaît le réseau Z avec une distance de 1. À nouveau R1 place le réseau Z
dans sa table mais avec une distance de 2. Etc.
Les protocoles type « Vecteur de distance », abordés dans le second semestre du cursus CCNA, sont :
● RIP (Routing Information Protocol) :
● La version 1 de ce protocole est définie dans le RFC 1058. Cette version ne supporte pas les
masques de sousréseau, les informations de routes sont envoyées vers l’adresse de diffusion
limitée 255.255.255.255.
● La version 2 de RIP est définie dans le RFC 2453. Chaque route est annoncée avec son masque, les
annonces sont diffusées vers l’adresse de multidiffusion 224.0.0.9.
● IGRP (Interior Gateway Routing Protocol) : protocole propriétaire CISCO, remplacé par EIGRP ;
● EIGRP (Enhanced IGRP) : protocole propriétaire CISCO qui élimine certains défauts de RIP et qui dispose d’un
calcul de distance beaucoup plus élaboré que le simple nombre de sauts, intégrant délai, bande passante,
fiabilité et charge des liens.
d. État de liens
Les protocoles à vecteur de distance souffrent d’un certain nombre de défauts qui limitent leur usage à des réseaux
de petite et moyenne envergure : les messages d’annonces contiennent une annonce par réseau connu et
deviennent rapidement conséquents, les temps de convergence sont également importants.
Une alternative est offerte par les protocoles de type « Etat de lien » également appelés SPF (Shortest Path First).
L’algorithme SPF suppose que chaque routeur participant ait une connaissance complète de la topologie du réseau,
connaissance mémorisée dans une base de données d’état des liens (LSD : Link State Database). Le réseau est vu
comme un graphe composé de nœ uds reliés par des arcs. Il existe un arc entre deux nœ uds si les deux routeurs
correspondants peuvent communiquer directement.

Chaque routeur teste l’état de ses voisins directement accessibles par le biais de messages courts envoyés de façon
régulière (coucou ! ……… coucou ! ………). Les changements d’état actif vers inactif, inactif vers actif s’opèrent de façon
intelligente, il faut plusieurs réponses pour considérer que le lien devient actif, de même, il faut plusieurs messages
sans réponse pour que le lien soit considéré « tombé ».
Chaque routeur informe tous les autres routeurs de l’état de ses liens et c’est en partie là qu’il prend l’avantage sur
un protocole type vecteur de distance. Le volume de ces messages n’est proportionnel qu’au nombre de liens et non
plus au volume de la table de routage.
Chaque routeur qui reçoit un message d’état de liens met à jour sa base de données topologique LSD.
Un routeur qui constate un changement intervenu dans sa base de données LSD, déroule l’algorithme de Dijkstra qui
lui permet de calculer le plus court chemin le séparant de chaque autre routeur du réseau et par la suite de remplir
sa table de routage.
Plusieurs caractéristiques concourent à la fiabilité du protocole. Notamment le fait que les messages d’état de liens
ne sont pas modifiés pendant leur transport, mais aussi le fait que chaque table de routage est le résultat du calcul
du routeur qui la porte, calcul effectué de façon totalement indépendante.
Dans cette famille, le cursus CCNA n’étudie que le protocole OSPF (Open Shortest Path First) défini dans la séquence
de RFC 1583, 2178, 2328. Le RFC 1583 est incontestablement le plus pédagogique car la compréhension de ce
protocole très élaboré est facilitée par la présence de nombreux schémas qui perdent beaucoup de leur intérêt une
fois représentés en mode texte (RFC 2178 et 2328).
Le second protocole de cette famille, ISIS (Intermediate System to Intermediate Sytem), est un protocole de l’ISO
défini dans la norme ISO/IEC 10589 et conforme au modèle OSIRM. Ce n’est donc pas un standard de l’Internet.
L’IETF l’a pourtant transcrit dans le RFC 1142 en guise d’information. ISIS est abordé dans le cursus CCNP.
e. Métrique associée à une route
La traduction Métrique pour le terme anglais « Metric » était jusqu’ici communément acceptée. Assez curieusement,
les documents de la version Exploration du cursus ont préféré le terme « mesure », par trop générique pour être
associé à la notion de distance qui sépare un routeur d’un réseau de destination. L’auteur croit être un ardent
défenseur de la langue française mais pour autant, accepte bien volontiers la création d’un mot nouveau français
lorsqu’il faut désigner une nouvelle notion. Dans le cas contraire, il faudrait par exemple remettre en cause le mot
« ordinateur » (créé en 1955) et revenir au mot calculateur puisqu’il s’agissait de traduire le terme « computer ».
Après tout, quand on mesure un débit, une pression, une température, on n’imagine pas de parler de « mesure »
mais bien de mesure de débit, mesure de pression ou mesure de température.
La métrique donc, est l’une des caractéristiques d’un protocole de routage. La plus simple est sans doute celle du
protocole à vecteur de distance RIP, égale au nombre de sauts. L’une des plus sophistiquées est celle du protocole
propriétaire EIGRP puisqu’elle associe délai, bande passante, fiabilité et charge. La métrique d’OSPF additionne les

coûts des différents liens qui composent la route, le coût d’un lien est fonction de sa bande passante.
L’exemple suivant, classique, montre les absurdités auxquelles peut conduire une métrique rudimentaire :
Si les trois routeurs remplissent leur table de routage avec RIP, un paquet émis par PC11 et destiné à PC22 transite
par une route directe dont certes le nombre de sauts est moindre mais dont la bande passante n’est que le 1/30 de
celle offerte par la route qui transite par R8.
Quel que soit le protocole de routage mis en œ uvre, la meilleure route est celle dont la métrique est la plus faible. Il
arrive qu’un routeur dispose de plusieurs routes pour une même destination. Dans ce cas, il ne place dans sa table
de routage que la route la plus favorable.
À un instant donné, chaque route contenue dans la table de routage est le meilleur chemin parmi les routes
connues vers une destination. Les autres routes sont ignorées.
Attention, ignorées ne signifie pas perdues. Dans le cas où une modification de topologie entraînerait l’indisponibilité
d’une route présente dans la table et dans le cas où cette route résultait d’un choix parmi des routes à métriques
différentes, l’une des routes ignorées jusquelà viendrait se substituer à la route défaillante.
L’exemple cidessus montre la table de routage d’un routeur configuré pour mettre en œ uvre le protocole EIGRP.
Chaque route découverte à l’aide de ce protocole est précédée de la lettre « D » (EIGRP est fondé sur l’algorithme
DUAL, Diffusing Update ALgorithm !). Observez les champs présents immédiatement à droite du réseau de
destination, deux valeurs entre crochets et séparées par un caractère « / » : la première valeur est la distance
administrative, la seconde valeur est la métrique.
Il peut arriver qu’un routeur dispose de deux ou plusieurs routes vers une même destination et avec des métriques
identiques :

Dans l’exemple précédent, le protocole de routage mis en œ uvre est RIP. Parce qu’il existe deux liaisons entre R8 et
R16, R8 inscrit dans sa table de routage deux routes à métriques identiques vers les réseaux 10.0.16.0/24,
10.0.21.0/24 et 10.0.22.0/24. Observez la table de routage, chaque réseau de destination concerné apparaît
associé aux deux sauts possibles.
On parle dans ce cas de chemins à coût égal, seul cas où le routeur ne choisit pas une route mais prend les deux (ou
davantage, jusqu’à quatre) routes en compte pour faire progresser le trafic vers le réseau de destination en le
répartissant sur les deux liens, ce que l’on désigne par Partage de charge à coût égal.
Faire apparaître plusieurs routes de métriques différentes pour une même destination, solution requise (sauf astuce)
pour réaliser un partage de charge à coût inégal, est l’un des avantages revendiqués par le protocole EIGRP, ce
point est abordé dans le cursus CCNP.
f. Notion de distance administrative
Nous avons dit que la métrique est caractéristique du protocole de routage. Comparer deux métriques n’a de sens
que si elles sont issues toutes deux du même protocole de routage. Le plus ordinairement, les routes dynamiques
installées dans la table de routage sont issues d’un unique protocole de routage qui les a choisi parce que, parmi les
routes connues, ces routes avaient la meilleure métrique. Quelques cas rares obligent à configurer plusieurs
protocoles de routage sur un même routeur, ce qui peut se produire lorsqu’un routeur est placé sur la frontière
séparant deux domaines distincts, un protocole de routage distinct étant déployé sur chacun de ces domaines.
Comment le routeur peutil opérer un choix parmi plusieurs routes pour un même réseau de destination quand ces
routes sont issues de protocoles de routage différents ?
Impossible cette fois de comparer les métriques. Le choix qui a été fait est d’associer un degré de confiance à chacun
des protocoles de routage, degré de confiance appelé distance administrative. Sa valeur est comprise entre 0 et
255, le routeur privilégie la route à distance administrative la plus faible.
Il est possible d’utiliser des valeurs autres que celles attribuées par défaut mais il est conseillé de connaître ces
valeurs par défaut :
● Route directement connectée : DA = 0 (une confiance absolue) ;
● Route statique : DA = 1 (c’est l’administrateur qui entre la route, on considère qu’il sait ce qu’il fait) ;
● Route issue de EIGRP : DA = 90 ;
● Route issue de IGRP : DA = 100 (normalement abandonné au profit de EIGRP) ;

● Route issue de OSPF : DA = 110 ;
● Route issue de RIP : DA = 120 ;
● DA = 255 → source non fiable, la route n’est pas installée dans la table de routage.
Revenez un peu plus haut à la figure illustrant les métriques associées aux routes, dans le résultat d’une commande
show ip route. À chaque route sont associées les deux valeurs [DA/Métrique]. Puisqu’il s’agissait du protocole EIGRP,
on retrouve la valeur DA = 90.
5. Le routage, synthèse très partielle
Nous venons d’aborder un point d’étape essentiel, la notion d’acheminement vu comme une succession de sauts dans
la section La problématique du routage Le routage, une successions de sauts de ce chapitre : « Pour aller vers ce
réseau distant, il faut confier les datagrammes à cette interface directement connectée ». Se persuader également
qu’une route telle que nous l’avons défini c’estàdire une correspondance [réseau de destination @du prochain
routeur] ne permet l’acheminement que vers le réseau de destination. Autrement dit, elle ne prévoit pas le retour ! En
phase de mise au point, l’administrateur doit constamment penser à vérifier l’acheminement aller ET l’acheminement
retour. Très sincèrement, l’administrateur imprégné de ces deux notions a compris l’essentiel !
6. Travaux pratiques : routage dynamique
Ces notions sont immédiatement vérifiables à l’aide d’une simulation Packet Tracer. Ce TP suppose que le lecteur est
maintenant familiarisé avec l’utilisation de Packet Tracer, il est par conséquent moins guidé, il offre un cadre, au lecteur
d’adopter un comportement exploratoire (il n’y a pas à hésiter, on ne peut rien casser !).
■ Sur le site ENI, téléchargez la mise en situation TP1_9b.pkt.
L’ensemble des routeurs de la configuration proposée participent au protocole de routage EIGRP. Le fonctionnement
de ce protocole n’est pas l’objet de ce TP. Il a été choisi parce qu’il prend en compte la bande passante des liens
dans le calcul de sa métrique. Les routeurs R8 et R16 sont reliés par deux liens physiques dont un à haut débit
(10.0.1.0/24) mais actuellement hors service.
■ Restez dans le mode Temps réel.
■ Observez les tables de routage des différents routeurs. Il faut évidemment un temps pour que les processus EIGRP
remplissent les tables. À terme, chaque table devrait comporter 7 routes.
■ Observez et notez les valeurs de métriques associées aux routes qui relient le réseau Nord au réseau Sud.
■ Mettez en service le commutateur « Switch3 ».
■ Observez à nouveau les tables de routage des différents routeurs. Il faut évidemment un temps pour que les
processus EIGRP mettent à jour les tables. À terme, chaque table devrait comporter 8 routes (une route
supplémentaire vers le réseau 10.0.1.0/24).
■ Observez à nouveau et notez les valeurs de métriques associées aux routes qui relient le réseau Nord au réseau
Sud.
Les routes du Nord au Sud devraient normalement passer par le lien rapide et ignorer la liaison à bas débit.

Sousréseaux et surréseaux
1. Adressage par sousréseaux
RFC utile :
● RFC950 Internet standard Subnetting Procedure Août 1985.
Internet s’est trouvé un temps menacé par la pénurie d’adresses. Le réseau né dans les années 1980 était alors
confidentiel, l’espace d’adressage paraissait plus que suffisant et on a sans doute à l’époque distribué les blocs
d’adresses avec un peu de légèreté. Le système de classes contribuait au gaspillage, les besoins des entreprises
étant souvent supérieurs à ceux pouvant être satisfaits par la classe C sans toutefois justifier l’attribution d’adresses
de classe B. L’adressage par classes est devenu tout à fait inadapté mais il fallait pourtant tenter de préserver les
attributions déjà réalisées.
Une partie de solution a été adoptée en 1985 en proposant la possibilité de structurer l’espace d’adressage d’un
réseau de classe A, B ou C :
L’idée consiste à « emprunter » un nombre de bits à définir dans l’adresse hôte afin d’en faire une adresse de sous
réseau :
● un bit emprunté permet de définir deux sousréseaux et donc de diviser l’espace de départ en deux parties
égales ;
● deux bits empruntés permettent de définir 4 sousréseaux (cas de l’illustration) ;
● trois bits empruntés permettent de définir 8 sousréseaux et ainsi de suite.
Vu de l’extérieur, l’adresse du réseau est toujours valide, un datagramme destiné à l’une des machines de l’un
quelconque des sousréseaux est toujours transporté par l’Internet en mettant à profit l’adresse réseau, il n’y a donc
pas d’impact sur l’Internet mondial.
En interne par contre, il devient possible pour l’entreprise de mieux structurer son espace d’adressage et cela peut
contribuer à éviter des demandes de blocs d’adresses supplémentaires dont l’objet ne serait pas de pourvoir un
besoin d’adresses mais bien de permettre cette structuration.
C’est à l’administrateur qu’il revient de fixer la frontière entre l’adresse sousréseau et l’adresse hôte selon les
besoins de l’entreprise, chaque bit emprunté supplémentaire multiplie par deux le nombre de sousréseaux et divise
par deux le nombre potentiel de machines à l’intérieur d’un sousréseau. Les critères sont au choix, soit le nombre de
machines qu’il lui faut atteindre dans chaque sousréseau, soit le nombre de sousréseaux qu’il lui faut constituer.
Découpage en sousréseaux d’une adresse réseau de classe B :

Découpage en sousréseaux d’une adresse réseau de classe C :
Exemple : Subnetting
Vous êtes administrateur chez un important opérateur et avez « hérité » de l’adresse de classe C 194.2.16.0/24. On
vous demande de diviser cet espace en 10 sousréseaux différents.
La solution consiste à emprunter 4 bits de l’adresse hôte, ce qui en première approximation, devrait permettre de
créer 16 sousréseaux. En réalité, dans un tel découpage, on évitait d’utiliser le premier ainsi que le dernier sous
réseau. En effet, dans le cas du premier sousréseau, il y a ambiguïté sur son adresse qui, à moins d’y associer le
masque, est identique à l’adresse réseau. Quant au dernier sousréseau créé, c’est son adresse de diffusion qui se
confond avec celle du réseau d’origine.
Une fois le nombre de bits empruntés fixé, il devient possible de déduire le masque de sousréseau :
● Le masque de classe est /24, 4 bits sont empruntés, le masque de sousréseau est /28 ;
● Soit 1111 1111.1111 1111. 1111 1111.1111 0000 ;
● Et en réaffectant les poids 128 64 32 16 8 4 2 1, le masque est 255.255.255.240.
Chaque station d’un sousréseau doit être configurée avec ce masque et non avec le masque de classe afin que le
test d’adjacence soit à même de faire ce pourquoi il est conçu : déterminer si l’adresse de destination est directement
connectée (appartient au même sousréseau) ou pas. Dans le premier cas, le datagramme est envoyé directement au
destinataire (précédée d’une requête ARP si son adresse physique n’est pas connue). Dans le second cas, le
datagramme est remis à la passerelle par défaut.
Ensuite, chaque combinaison de bits empruntés fournit un sousréseau. À l’intérieur de l’une de ces combinaisons :
● tous les bits de l’adresse hôte à zéro fournissent l’adresse de sousréseau ;
● tous les bits de l’adresse hôte à un fournissent l’adresse de diffusion de ce sousréseau.
Par sousréseau, c’est à nouveau deux adresses qui sont perdues. Faisons un bilan dans le cas de cet exemple :
● avant le découpage : un bloc de classe C permet 254 adresses ;
● après le découpage avec emprunt de 4 bits, chaque sousréseau peut comporter 14 machines (2^4 2), il
reste donc 16 x 14 = 224 adresses.
La figure suivante tente de résumer la façon de faire. Que le lecteur se rassure, chaque découpage n’entraînera pas

autant de gaspillage de papier. Mais nous sommes sur un point de compréhension capital et il est impératif que le
lecteur administrateur en devenir soit à l’aise avec ces notions. Il existe bien des « calculettes IP » mais bien sûr,
impossible d’en disposer pendant l’épreuve du CCNA. Vos seuls outils seront alors une planchette type tableau blanc
et un feutre effaçable. Pas de papier, on comprend aisément pourquoi.
Attention, les trois premiers octets sont représentés dans la notion décimale tandis que le quatrième est représenté
en binaire. Voici les deux premiers ainsi que les deux derniers sousréseaux résultant du découpage :
Il est conseillé de reporter les résultats du découpage dans un tableau à raison d’une ligne par sousréseau de la
façon suivante :
Adresse réseau : 194.2.16.0/24
Bits empruntés : 4 Bits de masque : 28 Masque de 255.255.255.240

sousréseau
Nombre de sous 16 Nombre d’hôtes 14

réseaux max par sousréseau
Bitmap du sous (n = network, s = subnet, h = host)

réseau
110nnnnn.nnnnnnnn.nnnnnnnn.sssshhhh
Adresse sous Premier hôte Dernier hôte Adresse de

réseau diffusion
194.2.16.0 194.2.16.1 194.2.16.14 194.2.16.15
194.2.16.16 194.2.16.17 194.2.16.30 194.2.16.31
194.2.16.32 194.2.16.33 194.2.16.46 194.2.16.47
194.2.16.48 194.2.16.49 194.2.16.62 194.2.16.63
194.2.16.64 194.2.16.65 194.2.16.78 194.2.16.79
194.2.16.80 194.2.16.81 194.2.16.94 194.2.16.95
194.2.16.96 194.2.16.97 194.2.16.110 194.2.16.111

194.2.16.112 194.2.16.113 194.2.16.126 194.2.16.127
194.2.16.128 194.2.16.129 194.2.16.142 194.2.16.143
194.2.16.144 194.2.16.145 194.2.16.158 194.2.16.159
194.2.16.160 194.2.16.161 194.2.16.174 194.2.16.175
194.2.16.176 194.2.16.177 194.2.16.190 194.2.16.191
194.2.16.192 194.2.16.193 194.2.16.206 194.2.16.207
194.2.16.208 194.2.16.209 194.2.16.222 194.2.16.223
194.2.16.224 194.2.16.225 194.2.16.238 194.2.16.239
194.2.16.240 194.2.16.241 194.2.16.254 194.2.16.255
2. Travaux pratiques : application du découpage
Ces notions sont immédiatement vérifiables à l’aide d’une simulation Packet Tracer.
■ Sur le site ENI, téléchargez la mise en situation TP1_9c.pkt.
a. Étape 1 : Visualisation des tables de routage
Dans cette simulation, le tableau précédent a été mis à profit et 10 des différents sousréseaux ont été affectés à
10 des liens physiques de notre configuration de TP. Tous les routeurs à l’exception du routeur R0 participent au
protocole EIGRP. La connectivité entre les quatre PC PC11, PC12, PC21 et PC22 devrait être assurée.
● Vérifiez la configuration IP des interfaces de PC11 et R11.
● Vérifiez la table de routage de chacun des routeurs.
● Vérifiez la connectivité de chacun des 4 PC avec les 3 autres.
b. Étape 2 : Ajout de routes statiques
Votre mission, si vous l’acceptez, consiste à ajouter, sur le routeur R0, la ou les routes statiques qui conviennent
afin d’assurer la connectivité de PC0 avec les quatre PC PC11, PC12, PC21 et PC22.
La solution à ce problème est proposée dans le chapitre Corrigés des exercices Solution travaux pratiques :
application du découpage.
3. Masque de longueur variable VLSM
Dans le découpage d’un réseau avec classe, nous avons observé qu’il était possible de fragmenter le réseau initial de
la façon la plus grossière à la façon la plus fine, afin d’épouser au mieux les besoins de structuration d’une
organisation.
Dans le même temps, nous avons observé que, vu de l’extérieur, la route qui menait vers cet ensemble de sous
réseaux n’était pas modifiée par l’opération de découpage. La route devient une « superroute » vers un ensemble
de réseaux ! Nous avons pu mesurer l’intérêt de cette route agrégée sur le volume des tables de routage.

Pourquoi ne pas étendre le procédé audelà de la simple idée de départ qui consistait à offrir un moyen de structurer.
Dans le découpage en sousréseaux, la longueur du préfixe n’est plus imposée par la classe d’adresse mais choisie, à
condition d’être plus long que le préfixe initial de la classe. Pour profiter de cette possibilité d’agréger plusieurs routes
en une seule, l’idée consiste à autoriser toute longueur de préfixe et donc à abandonner le système de classes pour
adopter VLSM (Variable Length Subnet Mask).
Étudions un cas concret afin de mesurer la portée d’une telle décision. L’administrateur de l’entreprise Primevère a
négocié un préfixe suffisant pour attribuer des adresses à un parc de 6000 machines. Le développement régulier de
son entreprise le rend prudent et il a obtenu le préfixe 10.0.0.0/19. Cela signifie qu’il dispose de 13 bits pour l’espace
d’adressage de son entreprise. 13 bits représente 2^13 2 = 8190 adresses potentielles avant structuration.
Première observation : imaginons ce qu’il serait advenu dans l’ancien système d’attribution avec classes. Son besoin
ne pouvait être satisfait qu’en lui attribuant au choix 33 adresses de classe C (8190/254 = 32,xxx) ou une adresse de
classe B, mais dans ce cas, l’Internet mondial se voyait privé de 65534 adresses dont seulement 8190 utiles.
L’entreprise Primevère avant structuration de l’espace d’adressage :
L’entreprise couvre trois sites d’égale importance, l’administrateur décide de créer un quatrième site de réserve et
donc de diviser l’espace initial en quatre parties égales. Pour ce faire, il faut emprunter deux bits au champ de 13 bits
initial, la longueur de préfixe pour chacun des quatre réseaux résultants est /21 :

Le site Nord a immédiatement besoin de trois réseaux d’environ 250 machines. Chacun de ces réseaux nécessite un
préfixe /24 (l’ancien préfixe de la classe C) et puisque le préfixe attribué au site Nord est /21, il est possible d’y créer
8 réseaux /24. D’autres façons de diviser sont envisageables, par exemple toujours en partant du préfixe du site
Nord /21, il serait possible de créer un réseau /22 et quatre réseaux /24. En imaginant que le site Sud ait des besoins
symétriques au site Nord, la structuration résultante est :

Imaginons les conséquences sur le routage :
● Un routeur extérieur à l’entreprise n’a besoin que d’une seule route vers 10.0.0.0/19 pour faire progresser
des datagrammes vers des adresses de l’entreprise.
● Dans l’entreprise :
● Un routeur extérieur au site Nord n’a besoin que de la route vers 10.0.8.0/21 pour faire progresser
les datagrammes vers des adresses de ce site.
● Un routeur extérieur au site Sud n’a besoin que de la route vers 10.0.16.0/21 pour faire progresser
● Un routeur extérieur au site Centre n’a besoin que de la route vers 10.0.0.0/21 pour faire progresser
Comment découper le préfixe attribué initialement ? De la même façon que nous avions découpé un réseau de classe,
ce que résume le tableau suivant (nommons le « tableau VLSM dichotomique », dichotomie vient du grec ancien et
signifie littéralement « couper en deux ») :

Le point de départ est un préfixe /19. On a limité le découpage au préfixe /24 par souci de clarté sur ce support, mais
il était parfaitement possible d’aller audelà pour approcher au plus près les besoins d’adresse de réseaux plus
petits. Le quatrième octet n’est pas montré, le troisième octet est représenté en binaire. Une fois ce tableau
construit, l’administrateur puise les adresses réseau associées à leurs préfixes afin de satisfaire de la façon la plus
précise les besoins d’adresse et de structuration. Il peut aussi décider de déléguer à son tour un préfixe. Le tableau
suivant propose une méthode afin de mémoriser les attributions déjà réalisées (ce n’est pas le cas Primevère) :

Chaque pastille représente un espace délégué (l’administrateur en a confié la responsabilité à un collaborateur) ou
affecté. On pourrait imaginer un code des couleurs selon qu’un espace est délégué, affecté en partie ou affecté
totalement. Dans le cas Primevère, le tableau devient :

La représentation d’une arborescence depuis le préfixe initial n’est pas innocente. En effet, l’agrégation de routes
possible avec VLSM n’est obtenue que si l’administrateur réalise une assignation topologique des blocs d’adresses
issus de la subdivision du préfixe initial. Dans le tableau cidessus, le bloc 10.0.3.0/24 qui appartient au préfixe alloué
au site Centre est disponible. Pas question pourtant de le donner au « petit copain » administrateur du site Nord au
prétexte qu’il manque d’adresses. Ce bloc n’est disponible qu’à l’intérieur du site Centre ! Toute route agrégée vers
le centre ne peut mener qu’à des adresses situées sur ce site.
Le plan d’adressage VLSM est à la fois hiérarchique et topologique.
L’attribution des blocs d’adresses réalisée dans le cas Primevère n’est peutêtre pas optimale :

Par exemple, dans le cas du site Centre de l’entreprise, il eut mieux valu attribuer les blocs 10.0.0.0/24 et 10.0.1.0/24
car il est possible de les agréger en 10.0.0.0/23. À moins que l’attribution réalisée ne réponde à d’autres critères, ce
pourrait être :
● Le besoin de diviser le réseau Centre en 8 espaces d’adresses identiques ;
ou
● Une raison qui n’en est pas une : le besoin de l’auteur de créer une numérotation simple des routeurs et PC
de l’exercice proposé (c’est un aveu).
Exercice 9.1 : découpage VLSM
Allons encore plus avant dans notre scénario. M. COUSIN, administrateur d’un parc de 500 adresses dans le site Nord
se voit déléguer le bloc 10.0.14.0/23. Il peut vouloir l’utiliser en globalité ou à nouveau réaliser un découpage VLSM.
Question 1
Si M. COUSIN utilise le préfixe dans sa globalité, quelles sont les adresses du premier hôte, du dernier hôte, de
diffusion ?
Question 2
Réalisez à votre tour un découpage en tableau « dichotomique » en arrêtant la division au préfixe /28.
La solution de cet exercice est donnée au chapitre Corrigé des exercices Solution exercice 9.1 : découpage VLSM.
4. Travaux pratiques : routes statiques agrégées
Ces notions sont vérifiables à l’aide d’une simulation Packet Tracer.
■ Sur le site ENI, téléchargez la mise en situation TP_9d.pkt.
Soyons ludiques, l’auteur vous lance un défi. Vous disposez d’un capital de 14 routes statiques à répartir sur
l’ensemble des routeurs de cette configuration qui nous est maintenant familière. Chaque route peut être agrégée ou
pas. Seul le lien à haut débit sera utilisé entre les deux routeurs R8 et R16.
Une fois les routes statiques entrées (au plus 14), chacun des quatre PC doit pouvoir communiquer avec les trois
autres, ce dont on s’assurera avec des commandes ping.

La solution à ce problème est proposée dans le chapitre Corrigé des exercices Solution Travaux pratiques : routes
statiques agrégées.
5. Synthèse découpage/agrégation
L’idée d’un préfixe de longueur variable est déjà présente dans le RFC950 en 1985 : « la taille du masque bien que
constante dans un réseau donné, varie d’un réseau à l’autre…. Une caractéristique intéressante de l’autoencodage
est qu’il permet la division de l’espace d’adressage d’un réseau en sousréseaux de différentes tailles… ».
L’IETF a adopté VLSM et le routage sans classe CIDR en 1993 (RFC 1517, 1518, 1519). En guise de synthèse, faisons
l’inventaire des avantages :
● VLSM permet une attribution plus fine des blocs d’adresses, une attribution qui « colle » au besoin ;
● Il devient possible d’agréger les routes et par suite, de réduire le volume des tables de routage (ou de le
contenir). En diminuant le temps de recherche dans les tables, on améliore également les performances du
routage.
et des contraintes…
● L’assignation des préfixes doit être topologique.
● Les informations de route échangées entre routeurs et qui jusquelà ne contenaient que des adresses de
destination connues ont dû être adaptées pour transporter également le masque associé à chaque adresse.
Ceci justifie la version 2 du protocole de routage RIP également en 1993.
● Difficile de changer de fournisseur sans changer d’adresses (il faut changer de branche dans l’arborescence
de préfixes).
● Il a fallu modifier l’algorithme utilisé par le processus de routage implanté dans les routeurs pour adopter
l’algorithme de la correspondance la plus longue (relire si nécessaire la section La problématique du routage
Trouver le routeur destinataire, Notion de route dans ce chapitre).
La compétence qui consiste à diviser un réseau de classe en sousréseaux n’a plus cours. Elle constitue cependant
un bon point de départ pour acquérir la compétence qui consiste à diviser et structurer un préfixe en mettant à profit
des masques de longueur variable VLSM.

Le routeur dans son environnement
Le vocable routeur peut recouvrir des réalités bien différentes selon que l’on a affaire à un routeur d’agence ou de
succursale, un routeur d’entreprise ou de campus ou enfin à un routeur de fournisseur de services. Pour répondre à ces
différents besoins, CISCO a segmenté son offre en trois familles d’équipements :
● « Branch » traduisible par agence, succursale, site distant. Les routeurs proposés par le constructeur pour
répondre aux problèmes spécifiques de l’agence sont dits à services intégrés, ou routeurs ISR (Integrated
Services Routers).
● « WAN » : les routeurs de cette gamme affichent évidemment de grandes ambitions en matière de
performances, d’intégration de la sécurité, de communications temps réel. Le routeur WAN propose bien
davantage que le simple transport de données fiable et peut devenir une plateforme de convergence de la
communication d’entreprise.
● « Service Provider » (Fournisseur de services) : les routeurs de cette gamme, outre des performances
exceptionnelles, doivent également offrir un degré de disponibilité très élevé, une très grande longévité ainsi
que la possibilité de faire évoluer en taille les dispositifs sans remise en question de l’existant.
1. Le routeur d’agence ou de succursale
Un routeur qui se contenterait d’assurer sa fonction première c’estàdire l’acheminement des datagrammes IP, aurait
peu de chances de pouvoir satisfaire les attentes des clients. Le contexte des communications est en mouvance
rapide, accélérée encore par des accès toujours plus fluides vers l’Internet ainsi que par les possibilités toujours
accrues offertes par l’électronique. Ainsi par exemple, un téléphone portable aurait peu de chances de se vendre avec
l’unique fonction téléphone. Il est également devenu lecteur MP3, appareil photo, caméscope, navigateur Web,
support de stockage, dispositif d’authentification et sans doute demain, seratil à même de satisfaire d’autres besoins
que nous n’avons pas encore imaginés.
De même, un ordinateur n’est plus la machine de calcul des temps héroïques mais une machine « World Gate »
ouverte sur le monde, multimédia, capable autant de lire ou d’enregistrer un DVD que de servir de téléphone VoIP, de
TV et presque accessoirement de participer à quelque travail en cours.
De 2006 à 2009, CISCO a écoulé plus de 5 millions de routeurs ISR et doit ce succès à son analyse de ce qu’est
devenue l’activité économique. Une entreprise, ce n’est plus un siège où se concentre l’exécutif et qui pilote de façon
autocratique des sites de production. L’entreprise moderne résulte du maillage de nombreux sites (CorporateBranch
que l’on peut traduire par succursale) et de telles infrastructures sont efficaces à la condition que la prise de décision
puisse être également décentralisée sans perdre la cohérence avec le reste du groupe, ce qui suppose une
architecture réseau disponible et fiable. Après différentes enquêtes menées auprès de ses clients, CISCO recense les
besoins suivants :
● Routage.
● Commutation (switching).
● Connexion sécurisée via VPNs.
● Fonctions de sécurité toujours plus importantes :
● Parefeu.
● Détection/Prévention d’intrusions.
● Atténuation de la gravité des attaques par déni de service distribuées (c’estàdire des attaques par
déni de service dans lesquelles le serveur cible est attaqué de façon simultanée par plusieurs
ordinateurs).
● Protection contre les virus.
● Translation d’adresses.
● Mécanismes permettant de vérifier le respect par les postes clients, des règles de sécurité imposées

par l’entreprise (état de la protection antivirus, mises à jour de sécurité, présence d’un certificat…) et
regroupés dans la notion de contrôle d’accès au réseau (NAC : Network Admission Control).
● Filtrage d’URL...
● Applications dites collaboratives : téléphonie sur IP, intégration voixvidéo, vidéoconférence.
● Optimisation de la bande passante consommée sur le WAN (techniques de compression de la charge utile des
paquets, de multiplexage des sessions TCP, d’élimination de la redondance des entêtes).
● Prise en compte de la mobilité avec les applications sans fil.
Un routeur ISR intègre outre le routage, tout ou partie des fonctions citées. La gamme de routeurs ISR comprend les
séries 800, 1800, 2800, 3200 et 3800. Ce qui est bon pour un routeur d’agence ne l’est pas nécessairement dans le
cadre d’un apprentissage des fondements des réseaux. C’est pourquoi pour le CCNA, CISCO maintient l’usage de
routeurs et commutateurs séparés.
2. Les routeurs WAN
CISCO range dans cette catégorie les routeurs des séries 7200, 7300, ASR1000, 6500 et 7600.
3. Les routeurs « Service Provider »
CISCO classe dans cette catégorie les séries ASR1000, ASR9000, 7600, 10000 et XR12000 ainsi que la plateforme
CRS1 (Carrier Routing System).

Le routeur : un ordinateur spécialisé
1. Architecture
Découvrons les principaux blocs fonctionnels qui constituent un routeur et distribuons les rôles :
Si sur un routeur d’entrée de gamme la plupart des composants sont soudés sur la carte mère, au fur et à mesure que
l’on monte en gamme, la conception est de plus en plus modulaire.
Les interfaces réseau connectent le routeur à différents réseaux. Un trafic entrant par une interface est commuté par
le routeur vers l’interface sortante. CISCO propose évidemment une vaste gamme de types d’interfaces et il est peu
probable qu’un cahier des charges ne puisse être tenu. Le routeur dispose toujours d’un ou deux ports, Ethernet ou
FastEthernet, intégrés mais les autres interfaces, WAN notamment, sont ajoutées par l’intermédiaire de cartes qui
viennent prendre place dans des emplacements appelés slots.
L’unité centrale est basée sur une architecture RISC (Reduced InstructionSet Computer ou microprocesseur à jeu
d’instructions réduit). Classiquement on oppose ce type d’architecture à l’architecture CISC (Complex InstructionSet
Computer) dont les représentants les plus fameux sont les processeurs x86 qui ont équipé nos PC au moins jusqu’à la
génération 486. Un processeur CISC dispose d’un jeu d’instructions que l’on a peutêtre enrichi à l’excès. En effet,
chacune des instructions complexes de ce jeu d’instructions demande plusieurs cycles de lecture de la mémoire ROM
qui contient le microcode (mémoire intégrée sur la puce du processeur). C’est la firme IBM qui en 1975, inventa le
processeur RISC dont le jeu d’instructions était réduit de façon à permettre l’exécution d’une instruction par cycle
d’horloge. Outre cet avantage, le décodage des instructions étant plus simple, il peut être câblé plutôt que microcodé
et ainsi occuper moins d’espace sur la puce. Il semble que la polémique qui oppose les tenants de chacune de ces
architectures soit en passe de s’éteindre, faute de combattants. En effet, à partir du Pentium, INTEL a adopté une
architecture hybride dans laquelle est enfoui un processeur RISC, le fonctionnement CISC étant conservé mais émulé.
CISCO étant peu disert sur le sujet, difficile de savoir quels sont les processeurs adoptés par la firme pour équiper ses
routeurs. Par exemple, sauf erreur, il n’existe aucune commande « show » qui permettrait d’afficher le type de
processeur. Pour les plus curieux, il faut donc se résoudre à ouvrir les boîtiers puis relever les références des circuits
et entamer une recherche patiente sur le net. Ainsi on découvre que le routeur ISR (Integrated Services Router) 2801
embarque un processeur RM5261A250H, processeur RISC 64 bits conforme à l’architecture MIPS (c’estàdire
architecture RISC développée par la compagnie MIPS). Pour l’anecdote, outre les routeurs CISCO, des processeurs
conformes à cette architecture équipent également des consoles de jeux type PlayStation. Les lecteurs insatiables
pourront trouver d’autres détails sur le site :
http://www.pmcsierra.com/products/details/rm5261a/#Features
En fait, le microprocesseur effectue sans doute les tâches génériques car, toujours sur la carte mère du routeur 2801,
on remarque la présence d’un contrôleur de communications de type GT96103A et pour lequel quelques détails sont
fournis sur le site :

http://www.marvell.com/products/communication/horizon/index.jsp
Selon la firme MARVELL qui l’a conçu, ce contrôleur rassemble les fonctionnalités suivantes :
● Routage entre LAN et WAN
● Passerelle Voix sur IP
● Sécurité
● Qualité de service
Que le lecteur se rassure, le passage de l’examen CCNA ne requiert aucune connaissance en la matière. Ceci se
justifie parfaitement, car quel que soit le processeur embarqué, le système d’exploitation reste CISCO IOS et c’est lui
que l’administrateur doit maîtriser.
D’anciens routeurs étaient équipés dans le passé de microcommutateurs qui participaient à la configuration de
l’équipement. CISCO a pérennisé les pratiques acquises alors en remplaçant ces micro commutateurs par un registre
de 16 bits appelé « configregister ». La valeur stockée dans ce registre est maintenue en l’absence d’alimentation.
De plus, la commande qui permet d’écrire dans ce registre n’a pas besoin d’être suivie d’une commande de
sauvegarde. Ce registre intervient notamment dans la séquence de démarrage, son utilité est détaillée dans la
section Gestion de la plateforme logicielle CISCO IOS La séquence de démarrage.
2. Les ports d’administration
Le lecteur peu au fait du standard RS232 ou du mode de fonctionnement asynchrone gagnera à lire la section
Liaisons série synchrone/asynchrone du chapitre Annexes de cet ouvrage.
En dehors des interfaces réseau, le routeur est pourvu de deux interfaces de type série asynchrone, nommées port
console et port auxiliaire et dédiées à l’administration du système. Le port console autorise un accès local et
l’administrateur l’utilisera plutôt pour réaliser la configuration initiale du routeur. En effet, une fois configuré et en
exploitation, le routeur est accessible par le réseau et l’administrateur peut en assurer la gestion à l’aide d’une
session TELNET ou SSH (Secure Shell, version sécurisée destinée à remplacer TELNET). La seconde interface série,
nommée port auxiliaire permet un accès de l’administrateur à distance. Un scénario possible est de reprendre la main
sur l’équipement distant quand l’administrateur n’y parvient plus par le réseau. Pour profiter de cette possibilité, il faut
avoir été prévoyant, c’estàdire avoir installé un modem au voisinage du routeur et avoir amené une ligne du réseau
téléphonique commuté sur ce modem, ce qui revient à attribuer un numéro de téléphone au routeur. Une exception
cependant : les routeurs de la gamme 800 ne disposent que d’un seul port série asynchrone destiné à
l’administration. Appelé « console aux port », ce port est, selon le choix de l’administrateur, tantôt un port console,
tantôt un port auxiliaire.
En fait, il n’y a pas de différence de nature entre le port console et le port aux, les deux ports sont des ports série

asynchrones. La différence vient du câblage qu’en fait CISCO sur la face avant de ses routeurs. S’il avait fallu se
conformer strictement à la norme RS232, le port console aurait dû se présenter sous la forme d’un port DB25 femelle
et l’extrémité être de type ETCD (en anglais DCE) afin de faire face au terminal nécessairement ETTD (DTE). Le port
auxiliaire lui, aurait dû adopter un port DB25 mâle et adopter le type ETTD pour faire face au modem nécessairement
ETCD. C’est ce que CISCO a fait sur certains de ses routeurs, par exemple quelques routeurs de la série 7200 (7200
I/OFE, 7200I/O, 7200I/OFEMII).
Mais CISCO, sur la plupart de ses routeurs, a préféré privilégier la recherche de compacité et les deux ports ont été
câblés sur des sockets RJ45. Sur toute la gamme, il est facile de distinguer les deux sockets grâce à un code de
couleurs : le socket attribué au port console est repérable à sa couleur bleu ciel, le socket attribué au port auxiliaire
est repérable à sa couleur noire.
En dehors de la couleur, les ports console et auxiliaire se distinguent également par les choix qu’a fait le constructeur
quant aux circuits de la norme RS232 présents sur les 8 fils des sockets et quant à l’état de ces circuits, opérationnel
ou forcé. En effet, les contraintes imposées par la liaison avec un terminal ne sont pas les mêmes que celles imposées
par une liaison via modems. À moins d’avoir affaire à un administrateur fou, aucun risque pour que les caractères
frappés au clavier du terminal et donc reçus par le port console ne saturent la capacité de réception du routeur sur ce
port. De la même façon, il est peu probable que les caractères générés par le routeur ne dépassent les capacités
d’affichage à l’écran du terminal (qui dépassent largement les capacités de lecture de l’administrateur et plus encore
ses capacités à interpréter les messages). Le contrôle de flux est donc inutile sur ce port et CISCO n’en prévoit aucun,
ni logiciel (à l’aide des caractères XON/XOFF), ni matériel (fondé sur l’état de l’un des circuits de la jonction). En
revanche, le port auxiliaire dispose des circuits nécessaires à la réalisation d’un contrôle de flux matériel.
CISCO fournit également les cordons et adaptateurs nécessaires à la mise en œ uvre de ces ports. En parcourant les
guides d’installation des différents modèles de la gamme (tous téléchargeables sur le site CISCO), on peut dégager
trois types de packagings :
● Packaging 1 > Concerne les séries 800, 1800 et le routeur 2801. Le routeur est fourni avec :
● Un câble console (RJ45toDE9, couleur bleu ciel) également appelé « management cable ».
● Un adaptateur DE9toDB25.
● Packaging 2 > Concerne les séries 2800 à l’exception du routeur 2801, 3800, 7200, etc. Le routeur est fourni
avec :
● Un câble console (RJ45toDE9, couleur bleu ciel) également appelé « management cable » ou «
console adapter câble ».
● Un câble modem (RJ45toDB25, couleur noir) également appelé « modem adapter cable ».
● Packaging 3 > Concerne les séries 2600, 3600, 3700 et 3800. Le routeur est fourni avec un kit comprenant :
● Un câble inversé (RJ45toRJ45) appelé « rollovercable » dans la documentation CISCO.
● Un adaptateur RJ45toDE9 femelle permettant la connexion du port console au port série d’un PC
émulant le terminal. Cet adaptateur porte la mention « TERMINAL ».
● Un adaptateur RJ45toDB25 femelle permettant la connexion du port console au port série d’un
terminal. Cet adaptateur porte également la mention « TERMINAL ».
● Un adaptateur RJ45toDB25 mâle permettant la connexion du port auxiliaire au port série d’un
modem. Cet adaptateur porte la mention « MODEM ».
La photo cidessous rassemble les éléments du kit fourni avec les séries 2600, 3600, 3700 et 3800 à l’exception de
l’adaptateur modem :

Réglons le cas du câble inversé « rollover » qui fait décidément couler beaucoup d’encre. Ce câble résulte simplement
du fait que CISCO utilise du câble en nappe pour réaliser ses cordons destinés aux ports d’administration. Dans ce
câble en nappe, les 8 fils cheminent de façon parallèle et ne sont pas organisés en paires. Les cordons réalisés avec
une telle nappe ne pourraient supporter les débits des réseaux locaux. Fort heureusement, les débits à supporter
sont ceux d’une liaison série asynchrone RS232 et ne devraient donc jamais dépasser 19200 bits/s (il est possible de
régler la jonction à 115200 bits/s mais c’est hors standard). Il faut observer que le sertissage d’un connecteur RJ45 à
chaque extrémité d’une nappe à 8 fils produit naturellement un câble inversé. Il ne faut pas y voir une volonté
quelconque du constructeur mais simplement une conséquence du choix de la nappe en lieu et place d’un classique
câble à paires torsadées. Si le lecteur dispose d’un câble inversé à proximité, c’est le moment de le vérifier en plaçant
les deux connecteurs RJ45 en visàvis :
Les fils reliés à Pin 1 d’un connecteur et Pin 8 de l’autre connecteur ont même couleur, puis pin 2 et pin 7 et ainsi de
suite. Même s’il ne s’agit que d’un avatar de cordon RJ45toRJ45, l’étudiant ajoutera le câble inversé (rollover) à la
panoplie de types qu’il doit connaître, qui comprenait déjà le câble droit (straightthrough) et le câble croisé (crossover)
car on imagine bien que ce sujet peut faire l’objet de nombreuses questions dans un QCM du CCNA.
Le rétablissement des connexions attendues de façon à relier convenablement deux ETTD (Port console Terminal) ou
un ETTD et un ETCD (Port auxiliaire Modem) incombe à l’adaptateur RJ45toDBxx. Ainsi, l’illustration suivante
inventorie les circuits utilisés dans le cas d’une liaison port console terminal :

Observez que les circuits DTR (Data Terminal Ready) et RTS (Request To Send) du port console restent en permanence
montés. On est ainsi assuré que le terminal, qui reçoit ces états sur ses circuits DSR (Data Set Ready) et CTS (Clear To
Send) est « satisfait » et consentira à afficher les caractères reçus du routeur ainsi qu’à envoyer au routeur les
caractères frappés au clavier.
En final, il ne devrait subsister aucune ambigüité quand il faut relier le PC émulant un terminal au port console, c’est le
câble console RJ45toDE9 qu’il faut utiliser (ou son équivalent reconstitué à l’aide du câble inversé bleu ciel associé à
l’adaptateur RJ45toDE9), ce câble est de couleur bleu ciel, le socket du port console est également de couleur bleu
ciel (le fil bleu sur le bouton bleu...). L’extrémité DE9 du câble console est femelle, le connecteur DE9 du port série du
PC est mâle.
Le placement d’une jonction éclatée à l’extrémité d’un câble console confirme que cette extrémité est bien de type
ETCD. En effet, le voyant associé au circuit RD est allumé et confirme que ce circuit est générateur (au sens électrique),
ce qui est bien le fait d’une jonction ETCD.
Les choses se compliquent à peine quand il faut relier le port auxiliaire à un modem et qu’on a la chance de disposer
du câble modem de couleur noire. Quand ce n’est pas le cas, il faut se résoudre à utiliser soit le câble console associé
à son extrémité DE9 à l’adaptateur DE9toDB25 fourni, soit le câble rollover associé à l’une de ses extrémités à
l’adaptateur RJ45toDB25 mâle marqué modem. La figure suivante recense les différents cas et inventorie des
circuits mis en œ uvre :

Il reste à ajuster les paramètres de la transmission série. Par défaut, le port console est réglé à 9600S81 ce qui
signifie 9600 bits par seconde, sans parité, caractères exprimés sur 8 bits, 1 bit de stop. Ce réglage, noté 9600N81
dans la documentation CISCO (No parity) est modifiable mais il n’y a pas d’intérêt à le faire. Il faut ajuster à égalité les
paramètres de la jonction du terminal ou du PC émulant le terminal. Inutile d’activer un contrôle de flux. Dans de rares
cas, le constructeur préconise 9600N82, qui signifie deux bits de stop, ceci incombant sans doute à un circuit UART un
peu plus ancien et ayant besoin d’un temps de « récupération » plus important entre deux caractères. Quant au port
auxiliaire, il n’y a pas d’autre contrainte que celle qui consiste à le régler à égalité avec la jonction du modem (vitesse
maximale 115200 bits par seconde).
3. Le partitionnement de la mémoire
Le déroulement normal du démarrage d’un routeur doit aboutir au chargement d’un système d’exploitation appelé
CISCO IOS (Internetworking Operating System). Muni de ce système, le routeur est alors capable d’accomplir les
tâches pour lesquelles il a été conçu dont le routage des datagrammes IP. En dehors de ce système d’exploitation
complet, le routeur est également capable de charger d’autres systèmes d’exploitation partiels ou dont la finalité n’est
pas d’assurer le routage.
Ainsi, le système d’exploitation nommé RxBOOT offre un sousensemble des fonctionnalités de l’IOS, suffisant pour
monter les interfaces réseau et permettre la mise à jour des images IOS contenues en mémoire Flash. Il ne concerne
que les routeurs (série 2500) qui exécutent l’IOS directement en mémoire Flash car comment mettre à jour un fichier
en cours d’utilisation ? RxBOOT intervient également en cas de sinistre sur la mémoire Flash : si pendant son
initialisation, le routeur n’est pas parvenu à trouver une image IOS valide et si il dispose d’une image RxBOOT, alors il
tente de charger RxBOOT.
Enfin, le système ROMMON (ROM Monitor) intéresse particulièrement l’expert réseau puisqu’il permet un premier
niveau de débogage, la récupération de mots de passe perdus ou la copie d’un fichier IOS valide en mémoire Flash
quand celleci a été corrompue ou effacée par maladresse. ROMMON équipe tous les routeurs CISCO. Le chargement
de ROMMON intervient :
● Quand l’administrateur interrompt la séquence d’amorçage normale.
● Quand l’administrateur a modifié le contenu du registre de configuration afin d’influer sur cette séquence
d’amorçage.
● En ultime recours quand le routeur a échoué dans ses tentatives de chargement d’un IOS complet puis échoué
également dans le chargement de RxBOOT s’il en dispose.
C’est la mémoire ROM (Read Only Memory) qui contient, outre le programme d’amorçage, ce ou ces systèmes
d’exploitation alternatifs.
La mémoire RAM (Random Access Memory que l’on traduit par Mémoire à accès direct) est une mémoire volatile

accessible à la fois en lecture et en écriture. Comme pour tout ordinateur, la mémoire RAM d’un routeur contient à la
fois le code des applications et les données objet du traitement réalisé par le code. Dans le cas du routeur, le code est
constitué par le système d’exploitation CISCO IOS chargé pendant le démarrage depuis la mémoire Flash ou par un
système d’exploitation alternatif, RxBOOT ou ROMMON, chargé depuis la mémoire ROM. Les données comprennent la
configuration courante du routeur, les structures de données liées aux protocoles de routage telles les tables de
routage, les tables ARP (Address Resolution Protocol, voir ouvrage Cisco Notions de base sur les réseaux dans la
collection Certifications aux Editions ENI), les tampons de paquets associés aux interfaces.
Avant son chargement en mémoire vive, le fichier IOS occupe plusieurs Mégaoctets et est stocké dans une zone de
mémoire semipermanente nommée Flash. Il s’agit d’une zone de mémoire réalisée à l’aide de dispositifs EEPROM
(Electrically Erasable Programmable ReadOnly Memory). Une mémoire PROM peut être lue indéfiniment mais ne peut être
écrite qu’une seule fois. Une mémoire EPROM peut être effacée mais nécessite pour ce faire d’être soumise à un
rayonnement ultraviolet. La mémoire EEPROM est effaçable à l’aide d’un banal courant électrique. Il devient alors
possible de reproduire le fonctionnement d’un disque dur (maintien des données hors alimentation, lecture à volonté,
écriture quasi à volonté) sans l’inconvénient majeur du disque dur, c’estàdire sans pièce mobile.
Ainsi stocké en mémoire Flash, l’IOS peut être mis à niveau (une nouvelle version remplace une version plus ancienne)
ou modifié (une version aux capacités élargies remplace la version existante). Cela a été dit, certains routeurs
permettent l’exécution directe de l’IOS depuis la mémoire Flash, l’espace de mémoire Flash appartient alors à l’espace
adressable par le processeur. Mais le plus ordinairement, l’IOS est chargé en mémoire vive pendant le boot de
l’équipement.
La mémoire NVRAM est une mémoire RAM non volatile, c’estàdire une mémoire dont le contenu est conservé hors
alimentation. CISCO place en NVRAM le fichier de configuration initiale du routeur nommé startupconfig. L’initialisation
normale d’un routeur s’achève avec le chargement de ce fichier en mémoire vive. Une fois chargé, la copie est nommée
runningconfig.
La mémoire Flash offre un emplacement de stockage pour l’IOS. L’administrateur dispose de mécanismes
permettant les mises à jour (téléchargement de nouvelles versions via TFTP). Parmi les quatre partitions de la
mémoire, ROM, RAM, FLASH et NVRAM, trois sont permanentes, c’estàdire conservées hors alimentation. Seul le
contenu de la RAM est perdu lors d’un arrêt ou d’un redémarrage du routeur. CISCO n’utilise aucun dispositif de
mémoire type disque ou disquette sur ses routeurs. La réussite au CCNA suppose de bien connaître l’affectation
des quatre partitions de mémoire.
4. Découverte physique
Chaque modèle de routeur CISCO fait l’objet d’un guide d’installation très complet et qu’il est vivement conseillé de
s’approprier avant de sortir le nouveau routeur de son carton. Si les méandres du site CISCO rebutent le lecteur, il
suffit de laisser faire un quelconque moteur de recherche. Ainsi, la requête « Cisco 2800 Series Routers Hardware
Installation » dans Google fournit en première réponse un lien vers la documentation demandée (186 pages !) qu’il est
possible au choix de consulter en ligne ou de télécharger au format pdf. Nous appuierons notre propos sur le routeur
2801 mais une bonne part des éléments qui suivent est transposable au reste de la gamme :
Ce routeur appartient à la nouvelle génération de routeurs dits à services intégrés, ou routeurs ISR (Integrated
Services Routers).
a. Localisation du numéro de série
Cet identifiant de 11 caractères est situé à l’arrière du châssis dans le cas du 2801, sur la face des interfaces dans le
cas des autres routeurs de cette série :

Il existe un site CISCO qui répertorie pour l’ensemble des produits CISCO, localisation et format du numéro de série :
http://tools.cisco.com/Support/CPI/index.do.
L’accès à cet outil demandera au lecteur de s’enregistrer s’il ne dispose pas encore de compte sur Cisco.com.
b. Les interfaces intégrées
Le tableau suivant inventorie l’ensemble des interfaces disponibles sans qu’il ait fallu ajouter de modules
supplémentaires :
Modèle Ports 100BaseT Ports Ports USB Port Console Port Auxiliaire
Fast Ethernet 1000BaseT (Universal (RJ45) (RJ45)
(FE) RJ45 Gigabit Ethernet Serial Bus)
(GE) RJ45
CISCO 2801 2 1 1 1
CISCO 2811 2 2 1 1
CISCO 2821 2 2 1 1
CISCO 2851 2 2 1 1
c. La mémoire
Les platesformes 2800 disposent des mémoires physiques suivantes :
● DRAM : contient la partition RAM du routeur. La mémoire DRAM est un type de mémoire RAM dont la simplicité
structurelle permet d’obtenir des densités particulièrement élevées. La contrepartie est que cette mémoire
nécessite d’être « rafraîchie » de façon régulière (période de quelques millisecondes). La mémoire SRAM
(Static RAM) ne présente pas cet inconvénient, est plus rapide et consomme moins d’énergie. Mais son prix la
cantonne aux mémoires caches. Le choix de réaliser la mémoire RAM d’un ordinateur à l’aide de DRAM est le
choix le plus fréquent.
● Boot/NVRAM : réalisée à l’aide d’une mémoire Flash interne c’estàdire soudée à la carte mère du routeur.
Contient à la fois les partitions ROM et NVRAM ainsi que le registre de configuration.
● Flash memory : encore une mémoire Flash mais externe cette fois et réalisée à l’aide d’une carte au format
CompactFlash. Ce format de carte mémoire, créé par la firme SanDisk en 1994, est progressivement devenu
le support privilégié des professionnels de la photographie. Son seul défaut résulte de l’usage de broches
pénétrantes qui induisent une certaine fragilité. Mais son utilisation dans un routeur ne devrait pas en
souffrir car la fréquence des connexions/déconnexions reste limitée. Attention au risque de confusion car la
plateforme CCNA évoque cette carte comme étant une carte PCMCIA (Personal Computer Memory Card
International Association). Ce qui s’explique par le fait que la norme CompactFlash est conforme à la norme
PCMCIA, en dehors du connecteur qui ne comporte que 50 broches contre 68 pour le format PCMCIA.
L’auteur confirme donc qu’il s’agit bien d’une carte CompactFlash de type CFI (les CFI font 3,3 mm
d’épaisseur, les CFII font 5 mm d’épaisseur). Cette carte porte la partition nommée Flash du routeur.

Le tableau suivant recense les quantités de mémoire embarquée ainsi que les extensions possibles selon les plates
formes :
Plateforme DRAM Boot/NVRAM Flash Memory
CISCO 2801 Mémoire type SDRAM (Synchronous DRAM). 4 Mo de mémoire Flash Carte CompactFlash.
sur la carte mère.
128 Mo sur la carte mère. 64 Mo par défaut.
Extension possible jusque 384 Mo à l’aide 128 Mo possible.
d’un slot d’extension DIMM (Dual Inline
Memory Module).
CISCO 2811 Mémoire type DDR ECC (Double Data Rate 2 Mo de mémoire Flash Carte CompactFlash.
errorcorrecting code) SDRAM. sur la carte mère.
64 Mo par défaut.
2 slots DIMM, aucune mémoire sur la carte
mère. 128 ou 256 Mo
possible.
Barrettes de 256 ou 512 Mo.
Mémoire par défaut 256 Mo.
Mémoire max 768 Mo.
CISCO 2821 et Idem 2811 sauf mémoire max 1024 Mo.

2851
d. Alimentations
Pour chacun des routeurs de la série 2800, deux ou trois choix d’alimentation sont possibles :
Alimentation Entrée Routeurs concernés
Secteur sans possibilité d’alimenter des 100 240 VAC 2A 2801, 2811
téléphones IP
Secteur sans possibilité d’alimenter des 100 240 VAC 3A 2821, 2851
téléphones IP
Secteur avec alimentation 48VDC 120 W 100 240 VAC 5A 2801 (l’alim. 48V peut fournir 120 W)
pour les téléphones IP
2811 (l’alim. 48V peut fournir 160 W)
2821, 2851 (l’alim. 48V peut fournir
240 W)
DC sans possibilité d’alimenter des 24 60 VDC 8 A 2811

téléphones IP
DC sans possibilité d’alimenter des 24 60 VDC 12 A 2821, 2851

téléphones IP

Signalons également la possibilité d’équiper le châssis d’une alimentation redondante RPS675 (Redundant Power
System).
e. Les voyants LED
Tous les voyants du routeur 2801 sont placés en face avant :
LED Couleur Description
SYS PWR Vert Le routeur a terminé sa séquence d’initialisation et l’IOS est fonctionnel.
Ce voyant clignote pendant le boot ou si le système d’exploitation
chargé est ROMMON.
SYS ACT Vert Clignote chaque fois que des paquets sont émis ou reçus ou en cours de
traitement par le système.
CF Vert Allumé quand la mémoire Flash est occupée. Dans ce cas, il ne faut pas
ôter la carte Compact Flash de son logement.
AUX/PWR Vert/Ambre Allumé, indique la présence du dispositif d’alimentation. Vert, indique le

fonctionnement convenable de cette alimentation. Ambre, indique un
défaut de l’alimentation.
FE x Link Vert Allumé indique que le router est connecté à un LAN Ethernet via le port
Ethernet x.
Fe x 100 Vert Allumé indique un lien fonctionnant au débit de 100 Mbps.

Éteint indique un lien fonctionnant au débit de 10 Mbps.
Fe x FDX Vert Allumé indique un mode de fonctionnement Fullduplex.

Éteint indique un mode de fonctionnement Halfduplex.
AIM 0 Vert Allumé indique la présence d’un module AIM (Advanced Integration
Module) dans le slot AIM 0.
AIM 1 Vert Allumé indique la présence d’un module AIM dans le slot AIM 1.
PVDM 0 Vert Allumé indique la présence d’un dispositif PVDM (Packet Voice Data
Module) dans le slot PVDM 0.
PVDM 1 Vert Allumé indique la présence d’un dispositif PVDM (Packet Voice Data
Module) dans le slot PVDM 1.
Pour les autres châssis de la série, les voyants sont répartis sur la face avant et sur la face arrière :
LED Couleur Description Localisation
SYS PWR Vert fixe Le système est fonctionnel. Face avant
Vert clignotant Boot en cours ou le système d’exploitation chargé

est ROMMON.
Ambre Défaut système.
Éteint Pas d’alimentation ou carte mère défectueuse.
AUX/PWR Vert Si elle est installée, l’alimentation des téléphones

IP est fonctionnelle.
Ou
Si elle est installée, l’alimentation redondante est

fonctionnelle.

Ambre Si elle est installée, l’alimentation des téléphones
IP est en défaut.
Ou
Si elle est installée, l’alimentation redondante est
en défaut.
Éteint L’alimentation des téléphones IP et l’alimentation

redondante ne sont pas installées.
SYS ACT Vert clignotant ou Des transferts de paquets sont en cours.

fixe
CF Vert Allumé quand la mémoire Flash est occupée. Dans

ce cas, il ne faut pas ôter la carte Compact Flash
de son logement.
A (=ACT) Vert clignotant ou Activité sur les ports FE ou GE. Face arrière
fixe
F (=FDX) Vert Indique un fonctionnement en Fullduplex.
Éteint Indique un fonctionnement en Halfduplex.
S (=Speed) 1 flash suivi d’une Débit des interfaces FE et GE à 10 Mbps.

pause
2 flashs suivis Débit des interfaces FE et GE à 100 Mbps.

d’une pause
3 flashs suivis Débit des interfaces GE à 1000 Mbps (ne

d’une pause concerne que les platesformes 2821 et 2851).
L (=Link) Vert Le lien FE ou GE est établi.
PVDM x Vert Un module PVDM est présent dans le slot x et

initialisé.
x = 0, 1 (ou 2 si
2821 ou 2851)
Ambre Un module PVDM est détecté dans le slot x mais

non initialisé.
Éteint Pas de module installé dans le slot x.
AIM x Vert Le module AIM dans le slot x est initialisé.

x = 0, 1
Ambre L’initialisation du module AIM présent dans le slot

x s’est soldée par une erreur.
Éteint Pas de module installé dans le slot AIM x.
f. Horloge Temps réel
Comme tout ordinateur, un routeur est équipé d’un circuit assurant la fourniture de la date et de l’heure au système.
L’important est que ce circuit nécessite toujours une batterie pour assurer son office. Ceci constitue un point de
fragilité et nécessite de la vigilance. Dans le cas des châssis 2811, 2821 et 2851, CISCO a prévu une batterie
montée « à vie », c’estàdire dont l’espérance de vie est identique à celle du routeur. Seul le châssis 2801 est
pourvu d’une batterie lithiumion remplaçable.

g. Exploration du châssis
Observez la face avant du routeur 2801 cidessous :
Repérez les éléments suivants :
● 4 emplacements prévus pour recevoir les cartes d’interface, notés slot 0 à slot 3. Slot 0 est situé à droite :
● Slot 0 peut recevoir exclusivement une carte d’interface prévue pour la voix VIC (Voice Interface Card)
ou VWIC (Voice Wan Interface Card).
● Slot 1 et Slot 3 reçoivent indifféremment tout type de carte d’interface parmi les types WIC (Wan
Interface Card), VIC, VWIC et HWIC (HighSpeed WAN Interface Card).
● Slot 2 reçoit une carte d’interface parmi les types WIC, VIC et VWIC.
● Entre slot 0 et slot 1 (repère 5) ainsi qu’entre slot 2 et slot 3, un guide de carte amovible qu’il faut
ôter pour installer une carte HWICD de largeur double (Doublewide). Il est possible d’installer deux
de ces cartes.
● Slot 1 est dans le cas présent occupé par une carte de type WIC2A/S qui offre deux interfaces WAN
Serial (voir plus avant la section consacrée aux interfaces et à leur nommage).
● Le port console.
● Les ports Fast Ethernet ainsi que leurs voyants associés LINK, 100 et FDX.
● Les voyants système SYS PWR, SYS ACT.
● Le voyant AUX/PWR.
● Le port USB, repère 7.
● Les voyants AIM et PVDM.
● Le port auxiliaire.

● L’emplacement Compact Flash et son voyant CF associé, repère 6.
La face arrière du 2801 est assez dépouillée puisqu’elle ne comporte que le connecteur d’alimentation secteur, un
commutateur de mise sous tension, le numéro de série et une borne destinée à la connexion électrique du châssis
métallique à la terre.
Sur les châssis 2811, 2821 et 2851, les possibilités d’implantation de cartes d’interface étant plus étendues, CISCO a
dû se résoudre à distribuer slots, connecteurs et voyants sur les deux faces avant et arrière des routeurs. Pour
exemple, voici la face arrière du châssis 2821 :
Les ports Ethernet, Gigabit dans cette version du routeur, (repères 1 et 2) ainsi que les slots 0 à 3 des cartes HWIC
(repères 3 à 6) ont été reportés sur cette face. CISCO y a ajouté un slot pour module EVM (Extension Voice Module)
ainsi qu’un slot pour module NME (Network Module Enhanced, repère 8). En fait, ce slot est capable autant de recevoir
un module NM (Network Module) qu’un module NME.
Il est temps de se faire une idée de l’étendue de la gamme de cartes d’interfaces et de modules EVM, NM ou NME
proposés par le constructeur pour la série 2800 :
■ En remplaçant xxxx par la série objet de la recherche, 2800 dans le cas présent, tapez dans un moteur de
recherche : « CISCO xxxx Relevant Interfaces and Modules »
L’une des toutes premières réponses devrait être l’URL du site :

https://www.cisco.com/en/US/products/ps5854/products_relevant_interfaces_and_modules.html
La longueur du lien explique l’intérêt du passage par le moteur de recherche. Impossible de retranscrire la diversité
de l’offre CISCO ici (190 références au moment où ces lignes sont écrites). On découvre ainsi que parmi les offres de
modules NME figurent des modules de commutation jusqu’à 48 ports (Ethernet Switch Modules) ou des modules
permettant le contrôle de plusieurs points d’accès WiFi. Pour chaque référence, le site propose des liens vers une
documentation, des questions/réponses, plus d’information.
h. Repérage des modules à l’intérieur du châssis
La figure ciaprès détaille l’organisation interne :

Ce même routeur mais cette fois photographié :
Repérez les éléments suivants :
● le processeur, le contrôleur de communications ;
● la mémoire RAM soudée à la carte mère sur ce routeur ;
● le connecteur d’extension DIMM repère 12 ;
● l’alimentation repère 13 ;

● deux slots d’extension prévus pour recevoir des modules PVDM.
5. Connecter le routeur à son environnement
Certains ouvrages distinguent deux familles d’interfaces : les interfaces Ethernet et les interfaces série. Même si cette
façon de classer trouve une explication dans le mode de nommage des interfaces adopté par CISCO, c’est assez
gênant. En effet, le mode de transmission parallèle des informations n’existe plus guère qu’entre le processeur et ses
voisins immédiats dont la mémoire. En dehors de ce petit monde, toutes les transmissions se font sous forme série
c’estàdire sous forme d’une succession de bits, cela concerne également Ethernet. Par ailleurs, même si Ethernet
règne sans partage sur le monde des réseaux locaux et a étendu son hégémonie aux réseaux métropolitains, il n’est
pas d’hégémonie qui ne finisse par s’écrouler.
Restons prudents donc en distinguant deux familles d’interfaces, les interfaces LAN et les interfaces WAN.
a. Connecter l’interface LAN d’un routeur
Cas des interfaces Ethernet et Fast Ethernet
Ce sujet a déjà été traité dans l’ouvrage Cisco Notions de base sur les réseaux dans la collection Certifications aux
Editions ENI. En forme de rappel donc, chaque dispositif relié à un segment Ethernet est constitué d’une partie
émission et d’une partie réception. La liaison réalisée doit nécessairement relier la partie émission d’un dispositif à la
partie réception de l’autre dispositif. On parle de croisement et les possibilités pour réaliser ce croisement sont
nombreuses. Un port Ethernet de routeur qui ne dispose pas de la fonction « Auto MDI/MDIX » (détaillée plus avant)
est de type MDI (pas de croisement réalisé par l’équipement). Relier un tel port à un équipement de type MDIX (qui
croise) permet d’utiliser un cordon dit « droit » (Straighttrough), cas normal illustré par la figure cidessous :
Le cas suivant est plus un cas d’école puisqu’il est question de relier directement un PC à un port Ethernet de
routeur, de type MDI. Il peut également s’agir de réaliser une liaison Ethernet entre deux ports MDI de routeurs. Le
cordon doit alors être croisé (Crossovercable), ce qu’illustre la figure suivante :
Il n’est pas conseillé de réaliser un tel cordon « à la main ». En effet, quand les ennuis surviennent, le doute quant
au cordon croisé que vous avez péniblement réussi à confectionner revient de façon obsédante.
Croisement du lien en 1000BaseT
La spécificité de ce standard est d’utiliser les quatre paires du câble réseau :

Le croisement à réaliser est double. Quand il n’est pas réalisé par l’un des deux équipements, le cordon croisé est
plus difficile à confectionner. Dans le but d’éliminer le besoin de câbles croisés entre deux équipements similaires,
l’IEEE propose une configuration MDI/MDIX automatique (section 40.4.4 de la norme 802.32008_section3
disponible en téléchargement sur le site de l’IEEE). Le mécanisme mis en œ uvre intervient en amont de tout autre
mécanisme, dont par exemple celui de l’autonégociation, afin de faciliter la commutation de [DA+, DA] sur [DB+, DB
] ainsi que de [DC+, DC] sur [DD+, DD]. Une extrémité « Auto MDI/MDIX » ou « Auto crossover » détermine de
façon aléatoire une première configuration MDI ou MDIX, adopte cette configuration puis attend un temps suffisant
pour assurer une détection normale des impulsions NLP ou FLP émises par l’autre extrémité. Le temporisateur
correspondant est appelé « Sample_timer » et s’établit à 62 ms. Si le nœ ud reçoit les impulsions émises par le nœ ud
distant, il reste dans la configuration adoptée. Si la partie réception n’a pas détecté les impulsions, l’algorithme
prend une nouvelle décision MDI ou MDIX fondée sur le bit suivant du registre résultat du tirage aléatoire (qui en
comprend 11) puis réarme le temporisateur d’écoute des impulsions. On comprend que l’automatisme fonctionne
autant qu’il y ait une parmi deux ou les deux extrémités capables d’autoconfiguration MDI/MDIX.
L’implémentation de cette possibilité est facultative pour le 1000BaseT mais semble largement adoptée. En fait, c’est
à ce point pratique que certains constructeurs dotent dorénavant les ports Fast Ethernet de cette faculté. Il est
probable qu’à terme, le besoin de cordons croisés disparaisse et avec lui la compétence qui consiste à déterminer le
cordon convenable. Dans le cas du constructeur CISCO, l’adoption de cet automatisme est sans doute appelé à
s’étendre mais ne concerne, au moment où ces lignes sont écrites, qu’une partie des équipements. Ainsi, en
explorant à nouveau le document « Relevant interfaces and modules » de la série 2800, on découvre que les ports
suivants en sont dotés :
● Les ports embarqués Fast Ethernet des routeurs 2801 et 2811.
● Les ports embarqués Gigabit des routeurs 2821 et 2851.
● Les ports Ethernet routés des modules HWIC1FE et HWIC2FE.
● Les ports Ethernet des modules de commutation HWIC4ESW et HWICD9ESW.
Mais on trouve également des ports non encore dotés tels les ports des modules de commutation NME16S, NMEX
23ES, NMEXD24ES (liste non exhaustive).
b. Connecter l’interface WAN d’un routeur
L’entreprise « monosite » a vécu. L’entreprise moderne résulte du maillage de plusieurs sites dont le siège.
Raccorder ces sites entre eux est hors de portée du réseau local. Voilà l’entreprise contrainte d’en passer par des
services de réseau étendu, services fournis par un opérateur de télécommunications. L’opérateur de communications
électroniques est une entreprise qui fournit ou est autorisée à fournir l’accès à un réseau de communications public.
Détailler la diversité des services proposés par les opérateurs sort du cadre de ce chapitre mais quoiqu’il en soit,
l’accès au service se fait systématiquement par l’intermédiaire d’un dispositif nommé selon les cas « boîtier », «
modem » ou « DSU/CSU » (Data Service Unit/Channel Service Unit). Il n’y a pas hélas de terme générique qui permette
de désigner sans ambigüité ce boitier d’interface avec le WAN. C’est que le service de réseau étendu peut recouvrir
des réalités très différentes. De façon globale, le « boîtier » convertit les normes de couche 1 et 2 de l’interface WAN
du routeur en normes de couches 1 et 2 du circuit WAN de l’opérateur. Appuyons notre raisonnement sur la figure ci

dessous :
L’administrateur souhaite relier le site nantais et le site lillois. Il peut ignorer les détails d’implémentation du circuit
WAN, c’est « la tambouille » de l’opérateur. Pour cet administrateur, le lien à établir l’est entre le routeur de Nantes
et le routeur de Lille. Pour ce faire, il faut régler les problèmes de couche physique puis les problèmes de couche
Liaison. En couche physique, le routeur de Nantes est raccordé à un boîtier via une liaison série. De même, le routeur
de Lille est raccordé à son boîtier via une liaison série. Dans chaque cas, il faut réaliser la jonction entre un ETTD
(l’interface WAN du routeur) et un ETCD (l’interface côté client du boîtier). Quelle norme de liaison série supporte le
boîtier ? Cette norme estelle également supportée par l’interface WAN du routeur ?
L’histoire des télécommunications, évidemment liée à l’évolution des technologies, a engendré nombre de normes
différentes dont EIA232, EIA449, EIA530, EIA612/613, V35 ou X21. Le besoin de créer une nouvelle norme de
liaison série ne naît pas suite à la fantaisie ou à une créativité débridée des concepteurs mais peut être dicté par
des besoins non couverts par les normes existantes. À cet égard, l’histoire de la norme V35 est édifiante. En 1968, le
CCITT (Comité Consultatif International Téléphonique et Télégraphique, devenu UIT (Union Internationale des
Télécommunications) en 1992) s’apprête à publier l’avis V35. Cette norme correspond en fait au premier modem
standardisé pour la transmission à très haut débit (48000 bits/s, débit important pour l’époque) sur un canal qui,
dans la hiérarchie analogique d’alors, était appelé groupe primaire et dont la caractéristique essentielle était de
présenter une bande passante s’étendant de 60 à 108 KHz. L’interface numérique EIA232 ne convenant pas à un
tel débit (sic), le CCITT normalisa à la fois le modem (Modulation d’amplitude Bande latérale unique inférieure
Porteuse 100KHz) et son interface numérique. Naturellement le modem est tombé en désuétude, mais pas son
interface que l’on rencontre encore fréquemment.
CISCO s’adapte à cette diversité de normes en équipant ses cartes d’interfaces WAN de ports génériques, c’està
dire capables de supporter plusieurs normes de liaison série. Ainsi sur les platesformes 2500, 2600, 3600, le port
générique est appelé « port 5 en 1 » par CISCO car il admet les cinq normes EIA232, EIA449, V35, X21 et EIA530.
Cette faculté a un prix : il faut que le port physique de la carte WIC comporte suffisamment de broches pour couvrir
les besoins de chacune des cinq normes, ce qui explique qu’il en faille soixante. Ce port équipe par exemple la carte
WIC1T disponible pour les platesformes précitées :
Les explications qui suivent s’appuient pour partie sur un document très complet mis à disposition par CISCO et qui
s’intitule « CISCO Modular Access Router Cable Specifications », document de cinquante pages au moment où ces
lignes sont écrites. Il est possible de télécharger le document :

http://www.cisco.com/en/US/docs/routers/access/hardware/notes/marcabl.pdf
Puisque le port WAN est générique, réaliser la jonction avec le boîtier suppose de choisir le cordon convenable.
Hormis pour la norme EIA530, CISCO prévoit systématiquement deux types de cordons, l’un fournit une extrémité
ETTD (DTE), l’autre fournit une extrémité ETCD (DCE). Pour EIA530, CISCO ne prévoit que le seul cordon de type
ETTD (DTE). Le point commun de ces neuf cordons est d’avoir une extrémité WIC (« WIC end ») destinée à être
connectée au port WAN côté routeur, désigné DB60. L’autre extrémité (« network end ») de chacun de ces cordons
utilise le connecteur physique le plus communément rencontré pour la norme considérée. Ainsi, dans le cas d’EIA
232, l’extrémité réseau du cordon utilise un port DB25M (M pour mâle) quand le cordon est de type ETTD, DB25F (F
pour femelle) quand le cordon est de type ETCD.
Pour chacune des cinq normes, CISCO fournit le plan de câblage du cordon. Observez par exemple le circuit
« Emission de données » de la jonction, désigné le plus souvent par TxD (« Transmit Data »). En EIA232 (page 22
du document) il correspond à la broche J141 du port DB60. En EIA449, X21 et EIA530, il est véhiculé par une paire
depuis les broches J111 et J112 du connecteur DB60. En V35 enfin, il est véhiculé par une paire depuis les broches
J118 et J117 du connecteur DB60. En fait, il y a autant de solutions différentes que de normes électriques. EIA
449, X21 et EIA530 utilisent les normes électriques EIA422 et EIA423 (respectivement V11 et V10 à l’UIT) mais
EIA232 tout comme V35, couvrent à la fois les aspects fonctionnels et électriques de la liaison. Estil possible de
concevoir un port WAN plus compact ? Oui à la condition de réduire le nombre de broches. Et pour ce faire, chaque
broche, ou chaque paire de broches dans le cas d’un signal véhiculé par une paire, doit pouvoir commuter d’une
norme électrique à une autre en fonction de la norme de liaison série choisie. Le connecteur en devient « intelligent »
et c’est pourquoi CISCO a baptisé son nouveau connecteur « Smart Serial ». Ce connecteur comporte 26 broches,
conserve la forme en D, et équipe par exemple la carte WIC2A/S (deux ports WAN Asynchrones ou Synchrones)
objet de l’illustration ciaprès :
La carte de type WIC2A/S est d’encombrement identique à la carte WIC1T précédente mais la compacité du
connecteur Smart Serial a permis d’y loger deux ports. En puisant à nouveau dans la documentation « CISCO Modular
Access Router Cable Specifications », observez le même circuit Emission de données pour chacune des cinq normes de
liaison série. Pour toutes les normes hormis EIA232, le transport s’effectue en mode symétrique (balanced, nécessite
une paire par circuit), le signal est véhiculé par une paire depuis les broches J101 et J114. EIA232 utilise un mode
asymétrique (unbalanced, signal entre un fil et la masse), le signal est véhiculé par un circuit correspondant à la
broche J101 du connecteur SS (Smart Serial). Observez également que les broches J101 et J114 se trouvent être
en visàvis sur les deux rangées de broches du connecteur, ceci afin d’éviter au mieux les couplages entre paires et
donc la diaphonie. La figure cidessous fournit les références des câbles CISCO dans le cas le plus normal, c’està
dire lorsque l’on souhaite une extrémité réseau de type ETTD (DTE) :

Il existe une variante de la norme EIA530 nommée EIA530A. La principale différence concerne les circuits de gestion
du modem. En EIA530, tous les circuits de la jonction sont en mode symétrique (balanced). En EIA530A, les circuits
DTR (Data Terminal Ready), DSR (Data Set Ready) et DCD (Data Carrier Detect) sont asymétriques (unbalanced). Ceci
porte à six le nombre de câbles prévus par CISCO pour fournir une extrémité ETTD. Il faut encore y ajouter quatre
câbles prévus lorsque l’on souhaite une extrémité réseau de type ETCD (DCE). Pour EIA232, V35, EIA449 et EIA
X21, remplacez les lettres « MT » de la référence par les lettres « FC » pour obtenir le cordon à extrémité ETCD (DCE)
correspondant. Le connecteur de l’extrémité réseau est un connecteur femelle. Il n’existe pas de cordon EIA530 à
extrémité ETCD.
Il reste à traiter un cas peu utile dans le monde professionnel mais très utile en situation de TP ou de test pratique
lors d’épreuves visant une certification, ce qu’il faut appeler un cas d’école, celui de la simulation d’un lien WAN sans
faire appel aux services d’un opérateur. Parvenir à simuler un lien WAN nécessite de résoudre un problème d’horloge
que l’on pouvait ignorer (mais mieux vaut le connaître) dans le monde réel. Resituons d’abord le contexte d’une
transmission numérique synchrone réelle sur un lien WAN :
Parmi tous les circuits de jonction, la figure précédente ne représente que les circuits de données ainsi que les
circuits d’horloge. Pour être concret, on a imaginé que les ETCD de cet exemple étaient dotés d’un port série
conforme à la norme EIA232. Les cordons utilisés pour relier chaque ETTD à l’ETCD correspondant sont donc de
référence CABSS232MT. Mais le raisonnement qui suit ne dépend pas de la norme de liaison série choisie.

Appuyons notre propos sur le flux de données émis par l’ETTD11 et destiné à l’ETTD21. Chaque octet à émettre est
présenté sur les entrées parallèles du registre à décalage. Rythmé par une horloge, ce registre présente les bits de
l’octet un à un sur sa sortie. L’ETCD12 reçoit ces bits mais a besoin de l’horloge qui les cadence pour les exploiter.
Qui fournit cette horloge ? Deux solutions s’offrent généralement :
1) On confie la fourniture de l’horloge à ETTD11. L’équipement est donc placé sur son réglage « Horloge interne ».
L’horloge H11 dont il est équipé lui sert à cadencer le registre de sérialisation. De plus, cette horloge est mise à
disposition de ETCD12 via le circuit HET (Horloge Emission Terminal). ETCD12 est placé sur son réglage « Horloge
externe » et met à profit cette horloge pour exploiter les bits reçus. Le flux de données codé, et éventuellement
modulé, est placé sur la ligne (le réseau étendu). Il porte l’horloge H11 en son sein. ETCD22 ne peut démoduler et
décoder que s’il dispose de l’horloge. Sa première tâche consiste à extraire l’horloge du flux reçu, horloge qu’il met à
disposition de la circuiterie de démodulation/décodage mais également à disposition de ETTD21 via le circuit HRM
(Horloge Réception Modem), ce afin que ETTD21 puisse comprendre et exploiter les bits reçus sur le circuit RD.
2) On préfère confier la fourniture de l’horloge à ETCD12, dont le réglage d’horloge est placé cette fois sur « Horloge
interne ». Cette horloge H12 est également mise à disposition de ETTD11 via le circuit HEM (Horloge Emission Modem).
Pour le reste, rien ne change.
Il est vraiment important de comprendre que ce choix d’horloge ne concerne que la partie émission. En effet, en
réception, il n’y a aucun choix possible. Le flux de données arrive porteur de l’horloge. Le second point important
consiste à observer que si l’ETTD est réglé en « Horloge interne », l’ETCD est obligatoirement réglé en horloge
externe et des deux circuits HET et HEM, seul le circuit HET est utile. Si l’on préfère régler l’ETCD en horloge interne,
alors l’ETTD est réglé sur « Horloge externe » et seul le circuit HEM est utile. Il se trouve que CISCO sur les interfaces
WAN de ses routeurs, ne donne pas le choix et préfère laisser la responsabilité de la fourniture de l’horloge aux
ETCD. L’interface WAN d’un routeur est par conséquent toujours en horloge externe, l’horloge est récupérée sur le
circuit HEM.
La partie émission d’un ETTD doit nécessairement être reliée à la partie réception de l’autre ETTD, c’est la notion de
croisement déjà explicitée lorsqu’il a fallu connecter l’interface LAN du routeur. Observez que dans cette configuration
de transmission numérique sur un lien WAN, c’est précisément la partie réseau étendu (la partie ligne) qui assure le
croisement : l’émetteur côté WAN de ETCD12 est relié au récepteur de ETCD22 et vice versa.
En situation de TP, à moins d’être très richement doté, il faut simuler le lien WAN sans avoir recours à des boîtiers,
modems ou DSU/CSU. Fort heureusement, CISCO met à disposition des cordons à extrémité ETCD (DCE). Simuler un
lien WAN nécessite de relier les deux interfaces WAN des deux routeurs via deux cordons, l’un à extrémité ETTD,
l’autre à extrémité ETCD. Ce qu’illustre la figure cidessous en conservant la norme de liaison série EIA232 :
À nouveau, seuls les circuits de données et d’horloge sont représentés. Le flux de ETTD11 vers ET_D21 transite par
[ETTD11J101 → ED → DB25broche 2 → RD → J105ET_D21] grâce au croisement introduit par le cordon CABSS
232FC. Ce flux est cadencé par une horloge qui transite via le circuit [ETTD11J102 → HET → DB25broche 24 → HRM
→ J104ET_D21]. Le flux de ET_D21 vers ETTD11 transite par des circuits symétriques.
Il subsiste cependant un problème : ETTD11 est toujours en horloge externe et attend le cadencement sur son
circuit HEM. CISCO résout ce problème de façon assez particulière en plaçant ET_D21 sur une configuration « Horloge
interne » puis en connectant cette horloge au circuit HEM qui devient par conséquent une sortie (un générateur
électrique). Ce circuit n’est pas croisé par le cordon CABSS232FC et parvient directement à l’entrée HEM de ETTD11.

Ainsi, l’interface WAN du routeur de droite n’est ni ETTD (le circuit HEM qui « sort » caractérise un ETCD) ni ETCD (le
circuit HET qui sort caractérise un ETTD), c’est pourquoi l’auteur l’a désigné « ET_D21 ».
Sur ET_D21, le passage en horloge interne ainsi que la fourniture de l’horloge sur le circuit HEM est provoqué par
l’instruction « clockrate » en configuration d’interface WAN, ceci sera réexpliqué dans les paragraphes qui suivent.
L’important est que ET_D21 associé à son cordon de type ETCD et convenablement configuré simule une interface
WAN de type ETCD en horloge interne. On désigne souvent l’association de deux cordons ETTD et ETCD par câbles «
backtoback » (littéralement dos à dos).
Hors cadre CCNA et pour être complet, citons la norme de liaison série HSSI (High Speed Serial Interface) développée
conjointement par les firmes CISCO et T3+ networking et depuis intégrée dans les standards de l’EIA. Cette
technologie répond à un besoin de bande passante qui couvre les débits atteints par les liens WAN T3 (44,736
Mbps) et E3 (34,368 Mbps).
HSSI est une spécification ouverte et opère sur la couche physique du modèle OSI. HSSI définit à la fois les
caractéristiques physiques (EIA613) et électriques (EIA612) de l’interface. Pour atteindre de tels débits, le mode de
transmission est bien sûr différentiel mais HSSI s’octroie le renfort d’une technologie particulière, dite ECL (Emitter
Coupled Logic), pour laquelle l’état saturé des transistors est remplacé par un état intermédiaire non saturé. La
vitesse y gagne au détriment de la consommation. Le connecteur utilisé est le même que celui utilisé par la norme
SCSI2. Le câble enfin doit utiliser des paires torsadées d’impédance caractéristique 110 Ω. Saluons le souci des
concepteurs d’éviter le besoin en adaptateurs mâlefemelle en imposant que les cordons HSSI soient
systématiquement pourvus de connecteurs mâles.
c. Connecter un PC en émulateur de terminal au port console
Pour les ateliers de cet ouvrage, on se propose d’utiliser l’émulateur de terminal PuTTY bien connu des
professionnels. L’avantage de cet outil est qu’il permet autant l’émulation d’un terminal que l’établissement d’une
connexion Telnet ou SSH via le réseau. Au moment où ces lignes sont écrites, le logiciel en est à la version 0.6. Le
fichier d’installation « putty0.60installer.exe » pèse 1719 Ko. Le logiciel, une fois installé, occupe 3,23 Mo sur le
disque dur.
Lien vers le site de téléchargement de PuTTY :

http://www.chiark.greenend.org.uk/~sgtatham/putty/
Une fois installé et exécuté, il reste à configurer PuTTY pour un accès via un port série, le plus probablement COM1 :

Bien sûr, encore fautil avoir la chance de disposer d’un PC équipé d’un port série EIA232. Quand c’est le cas, il reste
à connecter le port console du routeur au port série du PC à l’aide du câble console :
Quand PuTTY est prêt, quand le port console du routeur est relié au port série du PC, il reste à lancer le terminal
émulé en cliquant sur le bouton Open puis, si ce n’est déjà fait, à mettre le routeur sous tension. En supposant que
le routeur était effectivement hors tension, son démarrage s’accompagne de l’émission de différents messages vers
le port console. On peut ainsi suivre l’ensemble de la séquence de démarrage sur l’écran du terminal :

La séquence de démarrage fait l’objet d’une description complète au chapitre Gestion de la plateforme logicielle
CISCO IOS, la capture cidessus correspond au démarrage d’un routeur dont le fichier de configuration startupconfig
n’est pas vide. Autrement dit, un administrateur a déjà configuré, peutêtre partiellement, ce routeur. La séquence
s’achève alors par le message « Press RETURN to get started! ». Si l’administrateur frappe la touche [Entrée] du
terminal à ce moment, et sauf configuration particulière, l’interface ILC passe dans le mode utilisateur.
Que faire quand le PC que l’on a l’intention d’utiliser pour émuler un terminal n’est pas équipé d’un port série ? La
solution la plus évidente est d’acquérir un convertisseur USB EIA232.
Une fois le précieux convertisseur connecté sur son port USB et le pilote convenable installé, encore fautil identifier
le port série associé au convertisseur. Attention, débrancher le convertisseur d’un port USB pour le rebrancher sur un
autre port USB de la même machine et voilà que le numéro de port COM associé change. Le plus simple quand on
utilise régulièrement ce succédané de port série est encore de le connecter de façon systématique sur le même port
USB. Sur un poste de travail Windows XP ou 7 :
■ Effectuez un clic droit sur Poste de travail dans le cas de Windows XP (sur Ordinateur dans le cas de Windows 7)
puis dans le menu contextuel qui s’affiche, choisissez Gérer.
■ Ceci provoque l’ouverture d’une console MMC (Microsoft Management Console) équipée du composant logiciel
enfichable Gestion de l’ordinateur. Dans le volet gauche, déployez le nœ ud Gestionnaire de périphériques. Dans

le volet central, déployez Ports (COM et LPT). Le port COM affecté par Windows au convertisseur apparaît ici,
COM3 dans le cas présent :
■ De retour dans la fenêtre de configuration de PuTTY, sélectionnez le nœ ud Serial dans le volet Category puis
remplacez COM1 par COM3 dans le champ Serial line to connect to.
Ces convertisseurs ne gèrent généralement que les circuits Emission de données et Réception de données, les
circuits qui permettraient de gérer un modem par exemple sont absents. Mais ce n’est gênant en rien dans le cas
présent.
6. L’IOS
Comme tout ordinateur, un routeur ou un commutateur ne peuvent fonctionner sans système d’exploitation. Dans le
cas des équipements CISCO, le constructeur le désigne par IOS (Internetworking Operating System) et il est embarqué
sur la plupart des matériels du constructeur indépendamment de leur taille ou de leur type.
L’IOS CISCO est un système d’exploitation très puissant et très complexe associé à un langage de configuration tout
aussi complexe. Beaucoup de commandes, beaucoup d’options et à chaque nouvelle commande entrée, le risque de
compromettre le bon fonctionnement du réseau, cela peut aller jusqu’à isoler votre entreprise du reste du monde. Ce
n’est évidemment pas l’objet de cet ouvrage, mais même à concevoir un ouvrage de mille cinq cent pages, il est peu
probable qu’il parvienne à couvrir l’ensemble des fonctionnalités de l’IOS. Il faut donc accepter de ne pas pouvoir être
exhaustif et s’en tenir à de la méthode.
Pour le configurer, l’exploiter ou en assurer sa maintenance, l’administrateur accède à l’IOS via une interface en ligne
de commande (ILC ou CLI : Command Line Interface). Les commandes accessibles varient évidemment selon la version
d’IOS ainsi que selon la fonction de l’équipement considéré, routeur, commutateur ou encore point d’accès sans fil.
L’IOS est stocké dans la partition mémoire Flash. Pendant le démarrage du routeur, l’IOS est chargé en mémoire vive.
Ce point fait l’objet d’un développement complet dans le chapitre Gestion de la plateforme logicielle CISCO IOS.
7. Les interfaces et leur nommage
Premier point agréable : CISCO IOS emploie de façon systématique le terme interface, ce qui rend les commandes de
configuration à connaître transposables d’une plateforme à une autre. Le nommage d’une interface respecte la forme
générale suivante :

interface type-interface numéro
(Attention, le caractère « » matérialise l’espace afin de supprimer toute ambiguïté).

Parmi les interfaces LAN ne subsistent guère actuellement que les interfaces Ethernet mais l’évolution technologique
se poursuit et le nom attribué par CISCO IOS rappelle toujours le plus haut débit possible :
Quand il s’agit de l’Ethernet historique à 10 Mbps.

interface ethernet numéro
interface fastethernet numéro Interface capable des débits 10 et 100 Mbps, débit auto
négocié.
interface gigabitethernet numéro Interface capable des débits 10, 100 et 1000 Mbps, débit
auto négocié.
Le nommage d’une interface WAN fait abstraction de la technologie employée en couche physique et de
l’encapsulation mise en œ uvre par la couche liaison :
interface serial numéro
Hélas, cette belle recherche de systématicité se brise un peu quand on passe au numéro. En effet, la façon de
numéroter les interfaces d’un routeur dépend de la série et du modèle dans la série. Il faut donc se référer au guide
d’installation cité un peu plus haut. Le numéro peut être composé de un, deux ou trois chiffres séparés par des
caractères « / » :
● Pour les petits routeurs, l’interface peut être désignée par un numéro composé d’un seul chiffre.
● Quand le numéro d’interface est composé de deux chiffres, le chiffre de poids fort désigne par exemple le
numéro de connecteur (« slot ») qui reçoit la carte d’interface sur la carte mère, le chiffre de poids faible
désigne le numéro de port sur cette carte d’interface.
● Enfin, les configurations les plus importantes nécessitent une profondeur d’arborescence à 3 niveaux. Le
chiffre de poids fort peut désigner un module, le chiffre intermédiaire peut désigner une carte fille, un
adaptateur de ports, un sousmodule, un slot. Le lecteur notera avec soulagement que l’on peut parfaitement
ignorer les détails physiques qui justifient cette arborescence à deux ou trois niveaux.
Selon que l’interface est embarquée sur la carte mère du routeur ou sur un module inséré dans le routeur, elle peut
être désignée par un numéro à deux ou à trois chiffres. Quel que soit le chiffre considéré, la numérotation débute à
zéro. Le tableau suivant fournit quelques exemples de nommage, corrects sur au moins un modèle de routeur CISCO,
ainsi que, en référence avant puisque l’interface en ligne de commande fait l’objet du paragraphe suivant, la notation
abrégée de ces mêmes noms d’interface :
interface ethernet 0 int e0
interface fastethernet 0/1 int fa0/1
interface gigabitethernet 0/0 int gi0/0
Reprenons en exemple le cas de la série 2800. CISCO nous explique que le format du numéro est châssis/slot/port.
Pour le routeur 2801, châssis prend toujours la valeur 0 car tous les slots sont construits dans le châssis. Quant aux
routeurs 2811, 2821 et 2851, certains slots appartiennent au châssis et dans ce cas, le chiffre châssis prend la valeur
0. D’autres appartiennent au module NM(E) ou au module EVM et dans ce cas, le chiffre châssis prend respectivement
la valeur 1 ou la valeur 2.
Pour ancrer ces notions dans le concret, le lecteur pourra se reporter au chapitre Annexes section Numérotation des
interfaces des routeurs de la série 2800 qui fournit une liste exhaustive des numéros d’interface de ce routeur.

La configuration du routeur
1. Sources de configuration, fichiers de configuration
Pour résumer de façon lapidaire, l’IOS CISCO peut faire, mais sans fichier de configuration ne saurait quoi faire.
L’administrateur lui dicte ses tâches à l’aide de commandes regroupées dans des fichiers de configuration toujours au
nombre de deux :
● Le fichier runningconfig (fichier run de façon abrégée) est le fichier de configuration courante que le routeur
utilise pendant son fonctionnement.
● Le fichier startupconfig (fichier start de façon abrégée), placé en NVRAM, sauvegarde la configuration du
routeur en l’absence d’alimentation.
Le fichier runningconfig est obtenu par copie (clonage) du fichier startupconfig, copie réalisée pendant le démarrage
du routeur. Lorsque l’administrateur modifie la configuration du routeur par ajout ou suppression de lignes de
commande, c’est le fichier de configuration courante qui est modifié. Les modifications apportées prennent effet
immédiatement, on parle de configuration incrémentale.
Entre deux démarrages de routeur, les modifications apportées au fichier de configuration courante sont perdues car
celuici n’existe qu’en mémoire vive. Si l’administrateur souhaite sauvegarder les modifications apportées et donc le
nouvel état du fichier de configuration, il doit copier le fichier de configuration courante vers le fichier de sauvegarde à
l’aide d’une commande :
Router# copy running-config startup-config
Ou de façon abrégée :
Router# copy run start
L’administrateur peut visualiser indifféremment le contenu de chacun de ces fichiers à l’aide de commandes show.
Ainsi, pour visualiser le fichier de configuration courante :
Router#show running-config
Qu’il est possible d’abréger en :
Router#sh run
Pour visualiser le fichier de configuration de sauvegarde :

Router#show startup-config
Qu’il est possible d’abréger en :
Router#sh start
2. L’interface en ligne de commande ILC
L’interface en ligne de commande (ILC en français, CLI en anglais) est la cabine de pilotage du routeur. À l’aide d’ILC,
l’administrateur peut ajouter ou supprimer des lignes de commande aux fichiers de configuration. Il peut aussi vérifier
le fonctionnement attendu du routeur ou du réseau. À partir de l’ILC d’un routeur, il peut ouvrir d’autres sessions ILC
sur d’autres routeurs via Telnet ou SSH.
Cela a été dit dans la section Le routeur : un ordinateur spécialisé Les ports d’administration, l’administrateur accède
à l’interface ILC soit de façon locale via le port console, soit par le réseau via une session Telnet ou SSH. Au premier
abord, une telle interface peut sembler désuète. La plupart des configurations actuelles sacrifient à la mode des «
cliquodromes » : des fenêtres, des onglets, des cases à cocher, des boutons radio... Ces environnements,
évidemment attrayants dans un premier temps, ne présentent pas que des avantages. Demandez à un administrateur
système rompu à l’usage de l’interface Windows XP ce qu’il a pensé de la nouvelle interface de Windows Vista. Une
bonne part des savoirfaire perdus de façon instantanée alors qu’ils n’avaient été acquis qu’au prix d’une longue
pratique.
L’administrateur avisé, plutôt que de privilégier le côté attrayant d’une interface, doit s’interroger sur la pérennité des
savoirfaire qu’il doit acquérir. Et de ce point de vue, l’ILC sort gagnante. Car les mécanismes mis en œ uvre sont peu
ou prou les mêmes pour toutes les gammes de routeurs mais aussi pour toutes les gammes de commutateurs CISCO.
Mieux, l’usage de cette interface s’est tellement répandu qu’il arrive à des constructeurs tiers de proposer leurs
matériels dotés d’interfaces « CISCO like ».

L’interface ILC de l’exemple cidessus a été ouverte via le port console.
3. Les modes du routeur
C’est une façon de protéger l’équipement, mais aussi de rassurer la personne qui est en face de la console ILC, toutes
les commandes de configuration ne sont pas immédiatement accessibles. L’IOS prévoit trois contextes, appelés modes
par CISCO, et qui laissent plus ou moins de latitudes à l’administrateur :
Mode utilisateur (User mode) : l’administrateur accède au routeur sans risque de corrompre son fonctionnement ou
celui du réseau. En effet, ce mode n’autorise aucun changement dans la configuration et permet essentiellement
l’affichage d’informations élémentaires. Au démarrage de la connexion et sauf configuration particulière, l’ensemble
des moyens d’accès à l’interface ILC, Console, Aux et Telnet/SSH placent l’interface ILC dans ce mode. L’invite de
commande rappelle que l’interface ILC est dans le mode utilisateur de la façon suivante :
Mode privilégié (Privileged mode) : également appelé mode enable du nom de la commande qui permet d’y entrer, ce
mode offre l’accès à des commandes qui peuvent remettre en question le fonctionnement du routeur ou du réseau.
Quelques exemples de commandes critiques : la commande reload qui provoque un redémarrage du routeur ; la
commande debug utile au dépannage ou à la compréhension de phénomènes complexes mais qui mal utilisée, peut
consommer de la ressource processeur au point d’empêcher l’équipement d’assurer ses tâches normales. Si
l’administrateur peut s’interroger sur l’utilité d’un mot de passe qui protégerait l’accès au mode utilisateur, le doute
n’est plus permis dans le cas du mode privilégié. L’invite de commande reflète le passage au mode privilégié de la
façon suivante :

Les deux modes utilisateur et privilégié sont parfois appelés mode EXEC utilisateur et mode EXEC privilégié (mal
traduits par mode d’exécution), ce qui rappelle simplement que l’IOS exécute les commandes saisies dans l’interface
ILC puis y affiche des messages qui rendent compte des résultats.
Mode de configuration globale (Global config mode) : aucun des deux modes utilisateur et privilégié ne permet de
modifier la configuration de l’équipement. Il faut en passer par le mode de configuration globale ou l’un de ses sous
modes. Comme son nom l’indique, ce mode accepte des commandes de configuration et ces commandes affectent le
fonctionnement du routeur dans son entier. La configuration finale d’un routeur nécessitera la saisie de nombreuses
commandes de configuration, chaque commande saisie prend immédiatement effet dès la validation par la touche
[Entrée]. On désigne par configuration incrémentale cette façon de progresser vers la configuration définitive.
L’ensemble des commandes saisies dans le mode de configuration globale ou dans l’un de ses sousmodes modifie le
fichier de configuration courante runningconfig.
Chaque commande et donc également chaque commande de configuration prend effet dès la validation par la
touche [Entrée], voilà de quoi inciter l’administrateur à la prudence !
À nouveau, l’invite de commande reflète le passage au mode de configuration globale :
Observez au passage la possibilité offerte à l’administrateur d’utiliser des commandes abrégées. Dans l’exemple ci
dessus, l’administrateur provoque deux fois le passage en mode de configuration globale. La première fois, il le fait en
utilisant la commande complète. La seconde fois, il obtient le même effet en utilisant la commande abrégée. Une
commande abrégée comporte suffisamment de caractères pour permettre à l’IOS de reconnaître la commande sans
ambigüité. Par exemple, la séquence de caractères « con » ne peut pas abréger la commande configure car 44
commandes d’IOS (version de l’IOS 12.4T) débutent par cette séquence (configure, connect, controller…). De la
même façon, il existe 14 commandes qui débutent par la séquence « conf » avec 7 motsclés différents : conference-
join, conference-leave, config-cli, config-register, configuration, configure et confreg. En revanche, une seule
commande débute par le motclé configure suivi du motclé terminal qu’il devient possible d’abréger en conf t.
Sousmodes de configuration : à partir du mode de configuration globale, il devient possible d’accéder à de multiples
sousmodes, chacun de ces sousmodes limite le périmètre de configuration à un champ particulier, ce peut être par
exemple une interface, un protocole de routage ou une méthode d’accès au routeur. Les sousmodes correspondants
sont respectivement les sousmodes interface, router et line. En segmentant ainsi la configuration, l’interface ILC se
veut structurante, l’objectif étant bien évidemment d’aider l’administrateur dans sa tâche. À ce sujet, le comportement
de l’aide fournie par l’interface ILC est édifiant. À tout moment, l’administrateur peut solliciter de l’aide de la façon la
plus simple qui soit, en tapant un point d’interrogation. La réponse de l’interface ILC limite toujours l’aide fournie au
contexte en cours.
Commentons la séquence de commandes ciaprès, ligne par ligne, afin de synthétiser ces notions de mode. À
nouveau, il s’agit d’un routeur « sorti du carton » et l’administrateur a connecté un terminal au port console :

1. Un appui sur la touche [Entrée] immédiatement après la connexion physique du terminal au port console provoque
le passage en mode utilisateur, ce que rappelle l’invite de commande Router>.
2. La commande enable fait passer l’interface ILC dans le mode privilégié, l’invite de commande devient Router#.
3. La commande abrégée conf t fait passer l’interface ILC dans le mode de configuration globale, l’invite de
commande devient Router(config)#.
4. L’interface ILC génère un message invitant à entrer les commandes de configuration à raison d’une commande par
ligne et rappelant que la séquence de touches [Ctrl] Z fait sortir du mode de configuration.
5. La commande de configuration hostname est utilisée pour attribuer le nom Nantes au routeur en cours de
configuration. Il n’y a pas d’obligation en la matière, mais cela va sans dire, organiser le réseau, cela commence en
nommant chaque routeur de ce réseau à l’aide d’un nom unique et qui obéisse à une loi de nommage universellement
acceptée dans l’entreprise. Le lecteur en recherche dans ce domaine pourra utilement se reporter au RFC1178 intitulé
« Choosing a name for your computer ». Observez l’effet immédiat de la commande, l’invite de commande devient
Nantes(config)#.
6. La commande line console 0 fait entrer dans un sousmode de configuration dont l’objet est la configuration de
l’accès à l’interface ILC via le port console, l’invite de commande devient Nantes(config-line)#.
7. La commande password eni protège l’accès à l’interface ILC et puisque le sousmode de configuration est celui qui
règle l’accès via le port console, c’est cet accès qui dorénavant ne sera possible qu’en fournissant le mot de passe eni.
8. La commande exit fait remonter au mode de configuration globale.
9. La commande interface fastethernet 0/0 fait passer l’interface ILC dans un sousmode de configuration dont
l’objet est le réglage de tout ce qui à trait à l’unique interface LAN fastethernet 0/0. L’invite de commande devient
Nantes(config-if)#.
10. La commande ip address affecte à l’interface l’adresse IPv4 172.32.1.1/24. La commande no shutdown active
l’interface.
11. En supposant que la configuration soit momentanément suspendue, l’administrateur revient directement au mode
privilégié à l’aide de la combinaison de touches [Ctrl] Z.
12. Observez une première manifestation de SYSLOG dont l’objet est de générer des messages d’information ou
d’avertissement. Un paragraphe de ce chapitre fournit quelques détails complémentaires. Bornonsnous à l’essentiel, il
s’agit d’un message de niveau 5 (%SYS5, normal mais important) qui peut paraître ambigu puisque le terme console
revient deux fois. En fait, la première occurrence « from console » fait référence à l’interface ILC, la seconde
occurrence « by console » fait référence à la méthode ou au port utilisé pour se connecter à l’interface ILC, dans le cas
présent, le port console.
13. L’administrateur, consciencieux, sauvegarde ensuite son travail de configuration en copiant le fichier de
configuration courante vers le fichier de sauvegarde startupconfig placé en NVRAM.
14. Fin provisoire.
4. Limitation de l’accès aux routeurs, les mots de passe
Au sortir du carton, le routeur n’est protégé par aucun mot de passe ce qui ne signifie pas qu’il ne soit pas déjà
protégé. En effet, par défaut, seul le port console permet l’accès à l’interface ILC et à ses différents modes utilisateur
puis privilégié et enfin de configuration. Les autres accès Aux et Telnet ne deviennent possibles qu’après leur avoir
associé un mot de passe, ce qui nécessite de la configuration. Ceci est cohérent avec l’idée que, puisqu’un accès
physique est nécessaire, la personne qui a obtenu cet accès (il a fallu entrer dans un local technique protégé puis
connecter le terminal au port console) est également qualifiée et responsable et que par conséquent, tout lui est
permis sur le routeur.
Charge à cet administrateur, ce devrait être sa première tâche, de configurer les trois mots de passe qui protégeront
les trois accès Console, Aux et Telnet puis de configurer le mot de passe qui protégera le passage au mode privilégié.
Ce mot de passe est particulier puisqu’il en existe deux déclinaisons, l’une qui apparaît en clair dans le fichier de
configuration, l’autre qui est chiffrée par l’IOS. En excluant SSH qui mérite un paragraphe à lui seul, ceci porte à cinq le
nombre de mots de passe qu’il est possible de configurer sur le routeur dont quatre servent à un instant donné.
a. Protection de l’accès via le port console

Dans le sousmode de configuration de ligne, la commande login permet d’activer le test du mot de passe lors de
l’ouverture de session via le port console. Quand cette commande login est tapée dans paramètre supplémentaire
comme c’est le cas ici, le mot de passe est spécifié à l’aide de la commande password dans le même sousmode.
Mettons à profit la capture d’écran cidessus pour observer une faculté intéressante de l’interface ILC que l’on
pourrait nommer « auto complétion » : si au cours de la frappe d’une commande, le nombre de caractères entrés est
suffisant pour que l’IOS reconnaisse le motclé en cours de frappe sans ambigüité, alors la frappe de la touche [Tab]
provoque l’affichage de ce motclé dans son entier. Le motclé peut être la commande proprement dite ou seulement
un paramètre associé à la commande. Dans le cas présent, l’administrateur a entré les caractères pass puis frappé la
touche [Tab], l’IOS a reconnu la commande password et l’a affiché. Il a resté à l’administrateur à entrer le mot de
passe désiré. Voilà un procédé très commode, non pas pour aller vite ce qui est l’objet des commandes abrégées,
mais pour se rassurer pendant l’apprentissage de certaines commandes.
b. Protection de l’accès via le port AUX
Rappelons d’abord que si aucun mot de passe n’est associé au port aux, l’ouverture d’une session via ce port est
impossible. Si l’administrateur n’a pas l’intention de mettre le port aux en service, alors autant ne pas aller plus loin,
cet accès est d’emblée protégé. Lorsqu’on configure un mot de passe sur ce port, l’objectif réel est de permettre
l’accès tout en le protégeant.
c. Protection de l’accès via Telnet
Un accès via Telnet implique de disposer d’une interface LAN ou WAN active. La configuration suivante provoque
l’activation de l’interface LAN Fa1/0 et lui affecte l’adresse 172.31.1.1/24 :
À ce stade, imaginons tenter un accès Telnet via l’interface LAN 172.31.1.1 depuis la station d’adresse

172.31.1.104/24 directement connectée au réseau 172.31.1.0/24 :
Ainsi, comme dans le cas du port aux, l’ouverture de session est impossible par défaut. L’administrateur, de retour
sur la session ILC ouverte via le port console, ajoute les lignes suivantes :
La commande line vty 0 4 provoque le passage dans le sousmode de configuration de ligne :
● Le motclé vty rappelle qu’il s’agit de l’accès Telnet (Virtual Teletype).
● Les deux arguments 0 4 indiquent que les ports 0 à 4 (soit cinq ouvertures de session simultanées
possibles) sont l’objet de cette configuration.
Dans un but didactique et afin de démontrer qu’il ne suffit pas d’activer ces ports pour rendre l’accès possible,
l’administrateur a d’abord entré la commande login. L’IOS se manifeste en prévenant que, faute de mot de passe,
l’accès restait impossible sur les lignes 2 à 6 (la ligne 0 est occupée par le port console, la ligne 1 est occupée par le
port aux, les ports virtuels vty démarrent par conséquent au numéro de ligne 2). Si la commande password était
intervenue avant la commande login, il n’y aurait pas eu de messages d’avertissement.
Tentons à nouveau un accès via Telnet depuis la station 172.31.1.104/24 :
Cette fois, la tentative aboutit. Observez que, une fois le mot de passe accepté, la session ouverte l’est dans le
mode utilisateur. Mais une tentative pour passer dans le mode privilégié échoue :
Ceci confirme que le mode privilégié n’est accessible par défaut que depuis une session ouverte via le port console.
Pour rendre possible le passage au mode privilégié quel que soit le canal d’accès à l’interface ILC, port console, port
aux ou port vty, il faut créer le mot de passe « enable » dont l’objet est de protéger ce passage.

d. Protection du passage au mode privilégié
Une première méthode consiste à créer ce mot de passe en clair à l’aide de la commande enable password :
Mais puisque ce mot de passe est critique, il est sans doute préférable qu’il n’apparaisse pas en clair dans les fichiers
de configuration. La commande enable secret apporte la solution en permettant la saisie en clair d’un mot de passe
qui apparaîtra ensuite chiffré dans le fichier de configuration courante. Attention car une fois la commande validée, ce
mot de passe vient se substituer au mot de passe entré à l’aide de la commande enable password. Au prochain
passage au mode privilégié, c’est ce mot de passe qu’il faudra entrer :
À ce stade, tentons à nouveau un accès Telnet via l’interface LAN 172.31.1.1 depuis la station d’adresse
172.31.1.104/24 directement connectée au réseau 172.31.1.0/24 :
Le premier mot de passe saisi est « eni », qui autorise l’accès à l’interface ILC via le port VTY. Le second mot de
passe saisi est « cisco ». Il échoue puisque la commande enable secret s’est substituée à la commande enable
password. Le troisième mot de passe saisi est « ccna », il provoque le passage de l’interface ILC dans le mode
privilégié.
L’administrateur en profite pour lancer une commande show running-config dont l’objet est d’afficher le contenu du
fichier de configuration courante. Cette commande pourrait être abrégée en sh run. Quand l’affichage dépasse la
capacité de l’écran, l’IOS emplit l’écran puis suspend et affiche le message --More--. L’administrateur peut alors au
choix, frapper la touche [Entrée] pour obtenir l’affichage de la ligne suivante ou frapper la touche [Espace] pour
obtenir l’affichage de l’écran suivant, ce tant qu’il reste des commandes du fichier de configuration non encore
affichées.

Observez les deux lignes enable password et enable secret présentes dans ce fichier de configuration. Ainsi, quand
elles sont présentes ensemble, le seul mot de passe enable actif est celui saisi à l’aide de la commande enable
secret et qu’il est désormais impossible de déchiffrer. L’algorithme utilisé par l’IOS pour crypter le mot de passe est
MD5 (Message Digest 5), ce que rappelle le chiffre 5 placé immédiatement avant la séquence chiffrée dans le fichier de
configuration. MD5 est utilisé en cryptographie pour obtenir une signature numérique à partir d’un fichier.
Lorsqu’il est utilisé pour protéger les fichiers, on sait aujourd’hui que MD5 présente des failles. Mais dans le cas
présent, il s’agit de ne pas pouvoir retrouver le mot de passe à partir de la séquence cryptée. Alors MD5 présentetil
une fiabilité suffisante ?
L’auteur a téléchargé sur le site http://www.oxid.it/cain.html Caïn & Abel, l’un des nombreux logiciels destinés à
casser les mots de passe puis y a entré la séquence chiffrée contenue dans le fichier de configuration du routeur
Nantes :
Il n’aura fallu que quelques secondes au logiciel pour trouver le mot de passe « ccna » correspondant à la séquence
chiffrée en MD5. Mais que le lecteur ne cède pas à la panique et ne se précipite pas sur le téléphone pour exiger des
explications du constructeur. L’algorithme utilisé par le logiciel Caïn & Abel est confondant de simplicité. Il explore
toutes les combinaisons de caractères et pour chacune d’elles, calcule la séquence MD5 correspondante jusqu’à
trouver la séquence objet de la recherche. Cet algorithme est entamé avec une longueur supposée de 1 caractère
(a, b, c...) puis se poursuit avec deux caractères (aa, ab, ac... ba, bb, bc...) et ainsi de suite. Ce type d’attaque est
appelé « attaque par force brute » et n’a de chances d’aboutir que si le mot de passe est simple et court.
Imaginons un mot de passe sur 4 caractères entrés en minuscule parmi les caractères de l’alphabet. L’attaque par
force brute doit au pire explorer 264 =456976 combinaisons. À raison de 4000 par seconde, performance observée
sur la machine de l’auteur au moment où ces lignes sont écrites, moins de deux minutes suffisent pour parvenir à la
solution.
Mais mettons en place une politique de sécurité et imposons une longueur minimale de 9 caractères choisis parmi les
caractères affichables de la table ASCII. Cette table comporte 128 caractères mais les caractères 0 à 31 ainsi que le
caractère 127 sont dits non visualisables. Il reste 95 caractères possibles. L’attaque par force brute ignore la
longueur du mot de passe et il lui faut explorer la longueur 1 puis la longueur 2 et ainsi de suite. Calculons le temps
à passer si la machine est capable de 4000 essais par seconde. Rien que pour la longueur 9, il existe
95 9 = 630249409724609375 combinaisons qui réclameront
années !
Hélas par souci de commodité (qui n’a pas craint un jour d’oublier un mot de passe ?), de nombreuses personnes
utilisent des mots du langage courant pour créer leur mot de passe. L’attaque par dictionnaire met ce constat à
profit et teste une série de mots de passe potentiels contenue dans une liste. De telles listes existent évidemment
sur Internet, enrichies avec les mots de passe observés sur la planète. Pour contrer ces attaques, l’administrateur
doit cette fois imposer des règles de complexité : le mot de passe doit contenir lettres et chiffres, mixer minuscules et
majuscules, utiliser des caractères spéciaux, éviter les mots du dictionnaire, « saler » les mots utilisés s’il y en a
(c’estàdire concaténer le mot utilisé avec un mot qui lui fait perdre son sens premier sans toutefois perdre l’intérêt
de pouvoir être retenu facilement), remplacer certains caractères par leur correspondance dans l’alphabet « Leet
» (exemples : la lettre M peut être remplacée par la séquence (V), la lettre U par la séquence (_)...).
En final et à moins que demain, la puissance des processeurs ne permette des calculs beaucoup plus rapides, le mot
de passe construit en s’imposant de telles règles a encore de beaux jours devant lui.
e. Lisibilité de l’ensemble des mots de passe
Citons cette possibilité offerte par l’IOS pour mieux l’évacuer. Par défaut et hormis le mot de passe enable secret,
les différents mots de passe apparaissent en clair dans les fichiers de configuration. Il est possible de provoquer de
façon globale leur chiffrement à l’aide de la commande de configuration globale service passwordencryption.
Observez les captures ciaprès réalisées avant, pendant et après la mise en place du service :

Le mot de passe enable password affiché en clair « ccna » a été remplacé par la séquence « 020507550A », l’IOS
nomme mode 7 ce chiffrement ce que rappelle le chiffre 7 placé immédiatement avant la séquence chiffrée (le chiffre 5
rappelait lui un chiffrement MD5).
Hélas, il ne s’agit pas à proprement parler d’un chiffrement mais d’une simple logique combinatoire, comme le
démontre l’usage de l’outil Getpass (téléchargeable et gratuit), qui affiche les lettres du mot de passe en clair au fur
et à mesure que l’on tape la séquence chiffrée. Le seul intérêt de cette commande est de protéger les mots de
passe des regards indiscrets pardessus l’épaule de l’administrateur lorsque celuici provoque l’affichage du fichier de
configuration à l’aide d’une commande show run ou show start.
Un mot de passe, une fois chiffré par le service password-encryption ne sera plus jamais affiché en clair dans le
fichier de configuration. L’effet d’une commande no service password-encryption se borne à désactiver le service et
donc le chiffrement de tout nouveau mot de passe entré.
En tout état de cause, l’administrateur avisé se gardera de stocker ou de transmettre des fichiers de configuration
d’IOS sans précaution. Une mesure sage peut consister à purger toute commande de mot de passe chiffré ou non, le
fichier résultant permettant malgré tout de configurer un matériel identique de façon quasi instantanée,
l’administrateur complétant ensuite la configuration en rétablissant les mots de passe appropriés.
f. Combien de ports VTY ?
Beaucoup de notions erronées circulent au sujet de la configuration des ports vty sur les routeurs CISCO. D’abord,
même si les ports 0 à 4 sont créés par défaut (une ligne de commande line vty 0 4 existe dans le fichier de
configuration vierge), le nombre de ports n’est absolument pas limité à cinq et dépend de la plateforme. Pour s’en
convaincre, il suffit de demander de l’aide au moment de la saisie du second nombre représentant la butée haute
des ports vty en cours de configuration :
Ainsi, dans le cas d’un routeur 2801 associé à une version 12.4 de l’IOS, on apprend avec surprise qu’il est possible
de configurer 808 ports VTY. C’est probablement très audelà des capacités réelles de la plateforme (au sens
ressources processeur et mémoire) mais aussi très audelà des besoins d’une entreprise normale.
5. Aide
a. Aide contextuelle
L’aide contextuelle, très élaborée, fournie par l’interface ILC contribue à atténuer son austérité. Un peu comme la
canne soutient le vieux monsieur, l’aide contextuelle aide l’administrateur au fur et à mesure qu’il progresse dans la

configuration de l’équipement. Impossible en effet de mémoriser la syntaxe de milliers de commandes, impossible
également de rester connecté en permanence sur le site CISCO pour vérifier la syntaxe de telle ou telle commande.
La touche magique qui permet de demander de l’aide est simplement le point d’interrogation ?, on peut le frapper à
tout moment, le résultat diffère selon le contexte courant de l’interface ILC. Quelques contextes possibles :
Commande Usage
Prompt# help Affiche comment obtenir de l’aide.
Prompt# ? Affiche l’ensemble des commandes admises dans le contexte courant.
Prompt# commande ? Liste de toutes les options admises pour cette commande (ce peut être des
arguments ou des motsclés).
Prompt# abc? Liste de toutes les commandes débutant par la chaîne de caractères abc.
Prompt# abc[Tab] Autocomplétion : complète la commande partielle abc s’il est possible de le
faire. Exemple : l’interface ILC substitue show à la séquence sh [Tab].
Prompt# commande motclé ? Liste de toutes les prochaines options admises pour cette commande
associée à ce motclé.
En résumé, on peut classer l’aide contextuelle en deux catégories :
● D’une part, l’aide type vocabulaire, utile quand un doute subsiste sur le motclé en cours de frappe, est
invoquée à l’aide du point d’interrogation non précédé d’un espace.
● D’autre part, l’aide type syntaxe, utile quand il faut connaître la liste des motsclés ou des arguments admis
dans le contexte, invoquée par le point d’interrogation précédé cette fois d’un espace.
Quand la mention <cr> fait partie des réponses fournies par l’aide (CR signifie Carrier Return ou retour chariot, bref
la touche [Entrée]), cela signifie que la commande en cours d’édition peut déjà être considérée complète (mais elle
ne l’est pas obligatoirement) et que l’une des latitudes de l’administrateur est de frapper la touche [Entrée] pour que
l’IOS exécute la commande. Mais l’édition de la commande en cours reste possible, soit pour y ajouter d’autres
arguments ou options, soit pour corriger ceux déjà entrés.
Comme dans le cas d’une commande show, quand la liste des options proposées par l’aide dépasse la capacité de
l’écran, l’IOS remplit l’écran puis suspend l’affichage de lignes supplémentaires en attente d’une action de
l’administrateur. La dernière ligne affichée est alors More. Deux actions sont possibles dans ce cas :
1. Une action sur la touche [Entrée] provoque l’affichage d’une ligne supplémentaire.
2. Une action sur la barre d’espace provoque l’affichage des lignes supplémentaires jusqu’à ce qu’un nouvel écran
soit rempli.
Ce faisant, l’IOS pagine en quelque sorte l’affichage.
b. Historique de commandes
L’IOS maintient un historique des dernières commandes entrées. Par défaut, les dix dernières commandes sont
conservées, il est possible de modifier cette valeur à l’aide de la commande terminal history size n, où n est le
nombre de commandes maximal que doit conserver l’IOS :
R8#terminal history size ?

<0-256> Size of history buffer
R8#terminal history size 20

R8#
Les touches [Flèche en haut] et [Flèche en bas] permettent de se déplacer dans l’historique des commandes. La
première action sur [Flèche en haut] affiche la commande précédente, chaque nouvelle action affiche la commande
immédiatement antérieure. La touche [Flèche en bas] permet de revenir vers les commandes les plus récentes. Sur
des terminaux qui ne supporteraient pas l’action sur les flèches, il est possible de leur substituer les combinaisons
[Ctrl] N (Next, la prochaine commande) et [Ctrl] P (Previous, la commande précédente). La combinaison de touches
[Echap] < fait revenir au début de l’historique tandis que la combinaison [Echap] > fait repartir à la fin. Pour être
complet, mentionnons la possibilité d’afficher l’ensemble du contenu de l’historique :
R8#show history

copy run start
sh start
show adjacency
show loopback
show access-lists
show aaa
show aaa local
show aaa local user
show aaa local user lockout
show aliases
show cdp
show clock
show buffers
show conf
show controllers
conf t
terminal history size 20
show history
show history all
show history
R8#
c. Aide en ligne
Un doute sur la syntaxe d’une commande et l’aide contextuelle vous a laissé sur votre faim, ou tout simplement le
souhait d’obtenir une information de fond sur une commande de l’IOS, alors rendezvous sur le site « CLILookup »
de CISCO. Il faut disposer d’un compte, si ce n’est pas le cas, la page d’accueil propose de le créer :
1. Rendezvous sur le site : https//tools.cisco.com/support/CLILookup/
2. Identifiezvous ou créez un compte.
3. Sélectionnez IOS.
4. Sélectionnez la version IOS concernée.
5. Entrez un ou plusieurs motsclés de la commande recherchée.

6. Confirmez.

7. Parmi les résultats proposés, sélectionnez un résultat qui semble pertinent.
8. Le site affiche les détails de la commande recherchée. Le bouton View/Print permet d’afficher le résultat dans
une nouvelle page, la présentation des différentes rubriques est toujours la même, ce qui, avec un peu d’habitude,
rend l’exploitation du résultat plus efficace :

6. Les capacités d’édition de l’interface ILC
Puisque nous ne sommes pas dans une interface graphique, l’interface ILC aide l’administrateur à éditer des
commandes en se dotant d’un certain nombre de raccourcis clavier. Les pages qui précèdent ont déjà offert l’occasion
de vérifier l’effet de la commande exit ou de la combinaison de touches [Ctrl] Z. Pour mémoire, quel que soit le mode
courant, utilisateur, privilégié, de configuration, sousmode de configuration, la commande exit fait remonter d’un
niveau, la combinaison [Ctrl] Z fait sortir directement de tout mode ou sousmode de configuration pour revenir au
mode privilégié.
À condition de les mémoriser, les raccourcis suivants, dédiés aux déplacements dans la ligne en cours d’édition,
peuvent également se révéler utiles :
Combinaison de touches Action résultante

[Ctrl] B Déplace le curseur d’un caractère vers la gauche (B = Backward).
[Ctrl] F Déplace le curseur d’un caractère vers la droite (F = Forward).
[Echap] B Amène le curseur sur la première lettre du mot courant.
[Echap] F Amène le curseur immédiatement après le dernier caractère du mot courant.
[Ctrl] A Amène le curseur en début de ligne (At first).
[Ctrl] E Amène le curseur immédiatement après le dernier caractère de la ligne (End).
Les raccourcis suivants effacent un caractère ou une partie de mot ou une partie de ligne :
Combinaison de touches Action résultante
[Ctrl] D Supprime le caractère situé sous le curseur (Delete).
[Ctrl] H Supprime le caractère qui précède le curseur, même effet que la touche [Retour
arrière].
[Ctrl] W Supprime tous les caractères du mot courant qui précèdent le curseur.
[Echap] D Supprime tous les caractères du mot courant qui suivent le curseur ainsi que le
caractère situé sous le curseur.
[Ctrl] K Supprime la totalité des caractères situés entre le curseur et la fin de ligne,
caractère situé sous le curseur inclus.
[Ctrl] U Supprime la totalité des caractères situés entre le curseur et le début de ligne.
Les caractères sont placés dans un tampon qu’il est possible de rappeler à l’aide

de la combinaison [Ctrl] Y.
7. Atelier : Prise en main de l’interface ILC
a. Définition d’un contexte d’atelier
Dès le premier ouvrage de cette série, le souci de l’auteur a été de permettre à l’étudiant de progresser chez lui avec
ses moyens propres. Les ateliers proposés dans l’ouvrage Cisco Notions de base sur les réseaux dans la collection
Certifications aux Editions ENI faisaient un abondant usage de VMware Workstation. Pour mémoire, VMware installé
sur une machine hôte, permet d’y créer autant de machines virtuelles que nécessaire et que peut en supporter
l’hôte. Chaque machine virtuelle est un espace clos dans lequel il est possible d’installer la plupart des systèmes
d’exploitation que connaît le PC (l’éditeur en revendique deux cent). Si la machine hôte dispose de plusieurs
processeurs (cas des machines « dual core » et « quad core », alors il est possible de configurer la machine virtuelle
pour qu’elle profite d’un, de deux ou de quatre processeurs, cela n’a évidemment d’intérêt que si le système
d’exploitation installé sur la machine virtuelle est conçu pour tirer parti de plusieurs processeurs (Windows 2000
Professionnel ou Windows XP par exemple peuvent mettre à profit deux processeurs, mais il faut se tourner vers des
versions Serveur pour en supporter davantage). La quantité de mémoire disponible sur la machine hôte est
déterminante mais si le système d’exploitation, comme c’est encore le plus souvent le cas au moment où ces lignes
sont écrites, est une version 32 bits, alors le PC hôte embarque au maximum 232 =4 Go de RAM, limite qui ne sera
franchie qu’avec l’adoption des systèmes d’exploitation 64 bits.
L’essentiel est encore à venir : chaque machine virtuelle peut être dotée d’un ou plusieurs adaptateurs réseaux
virtuels. L’administrateur décide ensuite de connecter chacun de ces adaptateurs à l’un des concentrateurs virtuels,
VMware Workstation en fournit dix notés VMnet0 à VMnet9. Chacun de ces concentrateurs peut être à son tour relié
à un adaptateur réseau virtuel installé cette fois dans la machine hôte (noté « VMware virtual ethernet adapter for
VMnetx ». Parmi les nombreuses autres possibilités, notons celle qui consiste à établir un lien de type pont
(« bridge ») entre l’adaptateur réseau physique de la machine hôte et l’un des concentrateurs virtuels VMnetx. En
final, toute configuration de réseau local mêlant machines virtuelles et la machine physique est donc facile à réaliser.
Quant aux routeurs, le premier ouvrage proposait des mises en situation réalisées à l’aide de cet excellent outil
proposé par CISCO et nommé Packet Tracer. Mais il ne s’agissait que de simulations et l’étudiant lecteur engagé
dans le cursus CISCO pouvait regretter de devoir patienter jusqu’à une mise en situation réelle proposée par
l’organisme de formation pour prendre la main sur des routeurs physiques. Ce second ouvrage propose de passer
de la simulation à l’émulation à l’aide de l’outil GNS3 (Graphical Network Simulator) qu’il est possible de télécharger sur
le site : http://www.gns3.net/
GNS3 se définit comme un simulateur de réseau graphique, mais en réalité, il s’agit plutôt d’une interface qui facilite
la mise en œ uvre de Dynamips, logiciel qui permet d’émuler un routeur physique. Dynamips est au routeur ce que
VMware est au PC. VMware permet de créer une machine virtuelle dans laquelle l’administrateur installe un système
d’exploitation comme il le ferait sur un PC réel. De la même façon, Dynamips permet de créer un routeur virtuel sur
lequel l’administrateur charge l’image IOS convenable comme il le ferait sur un routeur réel. Et c’est là tout l’intérêt
pédagogique. Apprendre sur un PC virtuel émulé dans VMware crée les mêmes savoirfaire qu’apprendre sur un PC
physique. De façon analogue, un routeur émulé à l’aide de Dynamips se comporte strictement comme le routeur
physique porteur de la même image IOS, les apprentissages sont donc les mêmes mais il devient possible de les
délocaliser. C’est un peu comme si on permettait à l’étudiant d’emmener le bundle (ensemble de matériels CISCO
que doit acquérir tout organisme de formation qui adhère à l’académie CISCO) sous le bras ! Merci donc à son
créateur M. Christophe FILLOT de l’Université de Technologie de Compiègne.
Dynamips est associé à Dynagen, une interface écrite dans le langage de programmation Python et qui facilite
l’interconnexion de plusieurs machines émulées d’une même topologie. GNS3, également écrit en langage Python,
fournit une interface utilisateur graphique facilitant l’exploitation de Dynamips/Dynagen. Dynamips est capable
d’émuler actuellement les platesformes 1700, 2600, 3600, 3700 et 7200.
L’ensemble des ateliers de cet ouvrage a été réalisé sur un portable équipé d’un processeur Intel T9600 Dual Core
cadencé à 2,8 GHz et qui embarquait 4 Go de RAM. Le système d’exploitation hôte a été Windows 7 en version
d’évaluation 7100. VMware Workstation était en version 6.5 (une version 7 est disponible). GNS3 pour Windows était
en version 0.6.1.
Le routeur émulé résulte de l’association de Dynamips et d’une image IOS valide. Si cela ne pose aucune difficulté
pour un client CISCO, il en va en principe autrement pour l’étudiant administrateur en devenir. Sans intention de

vouloir encourager l’utilisation de licences illégitimes, l’auteur rappelle qu’aucune des machines virtuelles, PC ou
routeur, de cet ouvrage ne sera jamais une machine de production. Tout au plus une construction didactique
éphémère, support d’apprentissage.
b. Préparation des machines virtuelles VMware
Les machines virtuelles préparées par l’auteur afin de servir de cadre aux ateliers de cet ouvrage sont inventoriées
dans le tableau cidessous :
VMSRV01 VMWKS02 VMWKS03 PC8, 11, 12, 21, 22 si

Windows
PCL8, 11, 12, 21, 22 si
Linux
Nombre processeurs 1 2 1 1
Mémoire vive 384 Mo 1024 Mo 128 Mo 64 Mo si W2000

48 Mo si Linux
Disque 8 Go 6 Go 6 Go 6 Go
Nombre Adaptateurs 1 5 1 1
réseau
Système d’exploitation W2000 SRV XP Prof SP3 W2000 Prof SP4 W2000 Prof SP4
Ou Ubuntu
Logiciels notables Services GNS3 Serveur SYSLOG PuTTY

réseau (Kiwi)
Wireshark
Serveur RADIUS
(RADL)
Chacun des ateliers proposés ensuite ne nécessitera pas d’activer ensemble toutes ces machines fort
heureusement. À chaque instant, le souci doit être d’économiser la quantité de mémoire affectée aux différentes
machines. C’est ainsi que les machines PC8, PC11, PC12, PC21, PC22 qui ne servent qu’à tester la connectivité
doivent être des machines « Weight Watchers ». N’hésitez pas à désactiver des services inutiles (dans ce contexte)
tels que :
● Client de suivi de lien distribué.
● Mises à jour automatiques.
● Planificateur de tâches.
● Agent de stratégie Ipsec.
À ce sujet, l’auteur utilise depuis peu les services de TuneUp 2010 sur la machine hôte. Il a ainsi été très facile de
désactiver tout ce qui ne sert que l’apparence au profit d’une machine devenue très fluide, il faut savoir ce que l’on
veut.
PC11, PC12, PC21 et PC22 peuvent être obtenus très simplement par clonage de la machine PC8. De plus, parmi les
options proposées lors du clonage, l’une d’elles permet, en conservant un lien avec la machine d’origine, d’obtenir
une nouvelle machine avec très peu d’espace disque consommé :

Les férus de Linux gagneront sans doute à reproduire ces mises en situation sous leur système d’exploitation
préféré. Pour sa part, l’auteur avoue une certaine réticence, toujours gêné par le militantisme, quelquefois assez peu
professionnel, des porteurs de la bonne nouvelle du manchot. Mais la recherche d’efficacité et de compacité prime.
C’est pourquoi nous avons placé en téléchargement sur le site ENI une machine virtuelle prête à l’emploi (merci à
Gaëtan d’avoir préparé cette machine) dans l’archive wm_ubuntu.zip. Une documentation est incluse au format pdf.
Sous VMware, ouvrez cette machine Ubuntu puis clonezla afin de produire les machines PCL8, PCL11, PCL12, PCL21
et PCL22. Pour chacune des machines, voici la séquence de commandes nécessaires afin d’adapter la machine au
contexte :
Login : ubuntu
Mot de passe : sunrise
$ ifconfig a
L’invite de commandes (le « prompt ») est matérialisé par le symbole $. Le système renvoie la liste des interfaces
réseau qu’il connaît, notez le numéro d’ordre affecté à l’interface Ethernet, par exemple eth4.
$ sudo nano /etc/network/interfaces
Nano est un éditeur de texte. Sudo informe le système d’exploitation qu’il doit exécuter la commande avec le niveau
de privilège root (administrateur). Le mot de passe root est également sunrise. Le fichier ouvert contient la
configuration courante des interfaces. Sous le label # The primary network interface, remplacez les deux
occurrences ethx par eth4 puis adaptez la configuration IP. Sortez par [Ctrl] X, Y pour yes et validez par la touche
[Entrée]. Redémarrez la partie réseau afin de rendre effective la nouvelle configuration à l’aide de la commande :
$ sudo /etc/init.d/networking restart
Le système répond :
* Reconfiguring network interfaces - [OK]
Voilà votre machine prête à l’emploi. Attention à la commande ping qui, à la différence des systèmes Windows,
génère des requêtes de façon continue (une commande ping t provoquerait le même effet sous Windows) et dont
on sort à l’aide de la combinaison de touches [Ctrl] C. Attention également au fait que les outils de VMware (« VM
Tools ») ne sont pas installés sur cette machine. Par conséquent, une fois que la fenêtre correspondante à cette
machine a le focus, la seule façon d’en sortir est la combinaison de touches [Ctrl][Alt]. La barre d’état de VMware
rappelle cette particularité.
À l’inverse des machines PC8 à PC22 (ou PCL8 à PCL22), la machine virtuelle nommée VMWKS02 accueille
GNS3/Dynamips et a l’ambition de parvenir à faire fonctionner des topologies comprenant jusqu’à 6 routeurs. Ceci
justifie une configuration plus musclée : 1 Go de RAM et deux processeurs. La machine VMWKS03 ne sera activée que
pendant les ateliers organisés autour de SYSLOG (journalisation d’évènements) et RADIUS (authentification des
utilisateurs). Enfin, la machine VMSRV01 héberge un Windows 2000 Server, ce qui peut s’avérer utile s’il fallait mettre
en place un quelconque service réseau (DHCP, DNS...).

Nous ne détaillerons pas toutes les étapes nécessaires à la préparation d’un tel ensemble de machines, l’aide
fournie par VMware est très complète. Il peut être agréable d’ouvrir plusieurs instances de VMware, c’est le cas
quand on a la chance de disposer de plusieurs écrans sur la même machine hôte. Ceci s’opère à l’aide de la
commande de menu VMware File New Window. Ainsi, dans l’exemple cidessous, une instance est ouverte sur
une topologie de routeurs créée dans GNS3 hébergé par la machine virtuelle VMWKS02, l’autre instance de VMware
est ouverte sur une équipe (« team ») composée des machines PC8, PC11, PC12, PC21 et PC22 :
Rassembler plusieurs machines virtuelles dans une équipe procure un certain nombre d’avantages :
● L’administrateur peut provoquer le démarrage de l’équipe par une seule action. L’ordre de démarrage des PC
dans l’équipe est prédéterminé. De plus, l’administrateur peut ajuster le temps qui s’écoule entre le
démarrage d’un PC et le démarrage du PC suivant (10 secondes par défaut).
● Les machines virtuelles d’une équipe peuvent être connectées à un segment LAN dont l’administrateur peut
à la fois régler la bande passante et le taux d’erreur !
● Le focus est porté sur une machine de l’équipe mais les autres machines apparaissant sous forme de
vignettes qui représentent l’activité réelle de l’écran.
c. Préparation des réseaux virtuels VMware
Il s’agit d’assurer la connectivité convenable des machines virtuelles entre elles, des machines virtuelles avec la
machine hôte voire des machines virtuelles avec le ou les adaptateurs réseau physique qui équipent la machine
hôte. Le tableau cidessous tente d’inventorier les connexions établies, il semblera probablement nébuleux au
lecteur, mais il prendra du sens à mesure de l’avancée dans l’atelier :
Hôte VMSRV01 VMWKS02 VMWKS03 PC8 PC11 PC12 PC21 PC22
VMnet0 BRIDGE
VMnet1 NIC11 NIC11
VMnet2 NIC12 NIC12
VMnet3 NIC21 NIC21
VMnet4 NIC22 NIC22
VMnet5

VMnet6
VMnet7
VMnet8 NIC8 NIC8 NIC8
VMnet9
Chacune des cinq machines PC(L)x est reliée à la machine qui héberge GNS3. Les noms donnés aux adaptateurs
réseau (NIC : Network Interface Card) le sont au sein du système d’exploitation qui équipe la machine
correspondante. Dans la machine VMWKS02, il est conseillé d’ajouter un seul adaptateur réseau à la fois. Détaillons
la procédure d’ajout d’un adaptateur réseau dans la machine VMWKS02 :
■ La machine virtuelle VMWKS02 est active. Commençons par un état des lieux. Effectuez un clic droit sur l’onglet de
la machine virtuelle puis sélectionnez Settings :
■ Dans la fenêtre Virtual Machine Settings, sélectionnez l’élément Network Adapter. Faisons le choix de connecter
cette carte virtuelle au réseau physique de la machine hôte en sélectionnant le bouton radio Bridged.
■ Sur le bureau de la machine virtuelle, effectuez un clic droit sur l’icône Favoris réseau et sélectionnez Propriétés :
■ Renommez l’adaptateur réseau BRIDGE (effectuez un clic droit sur l’adaptateur puis sélectionnez Renommer) afin
d’éviter de confondre cet adaptateur existant avec les adaptateurs à venir.
■ Revenez aux réglages de la machine virtuelle et cliquez sur Add. Ajoutez un adaptateur réseau virtuel et
connectezle au concentrateur VMnet1 :

■ Revenez au bureau de la machine virtuelle, effectuez un clic droit sur l’icône Favoris réseau et sélectionnez
Propriétés. Renommez l’adaptateur ajouté en NIC11 :
■ Renouvelez l’ensemble de la séquence jusqu’à ce que la machine VMWKS02 dispose de ses cinq adaptateurs
NIC11, NIC12, NIC21, NIC22 et NIC8, chaque adaptateur étant connecté au concentrateur VMnet convenable,
selon le tableau d’affectation des VMnet fourni en début de paragraphe :
■ Depuis le menu Démarrer de la station hôte, lancez l’application Virtual Network Editor de VMware. Attention, si
la station hôte est sous Windows Vista ou Windows 7, ce lancement doit s’opérer en mode administrateur ce qui
est obtenu en effectuant un clic droit sur le raccourci de l’application :

■ De la fenêtre Virtual Network Editor, sélectionnez l’onglet NAT et désactivez toute translation d’adresses NAT :
Il est possible d’établir une connexion réseau entre la machine hôte et un ou plusieurs des concentrateurs virtuels
VMnet. Par exemple, imaginons que l’on souhaite établir un lien avec VMnet8 :
■ De la fenêtre Virtual Network Editor, sélectionnez l’onglet Host Virtual Adapters. Cliquez sur Add. Sélectionnez
VMnet8 dans la liste déroulante puis confirmez et appliquez :

■ De retour à la machine hôte, effectuez un clic droit sur l’icône Réseau ou Favoris réseau et sélectionnez
Propriétés. Constatez la création du nouvel adaptateur et renommezle en NIC8 afin de ne pas le confondre avec
d’autres adaptateurs à venir :
■ Adaptez la configuration IP de NIC8 aux tests en cours. Imaginons par exemple qu’il faille ouvrir une session
Telnet sur un routeur émulé dans GNS3 et dont le port f0/0 d’adresse IP 10.0.8.1/24 soit connecté à VMnet8. Dans
ce cas, il faut affecter l’une des adresses du réseau 10.0.8.0/24 à l’adaptateur NIC8 de la machine hôte.
■ Ouvrez à nouveau Virtual Network Editor, sélectionnez l’onglet Host Virtual Adapters et constatez que
l’adaptateur virtuel New device est devenu l’adaptateur NIC8. Sélectionnez l’onglet DHCP. Otez tout réseau
virtuel, cliquez sur Stop pour arrêter le service puis confirmez en cliquant sur Appliquer :

■ Fermez l’application Virtual Network Editor.
d. Préparation du contexte GNS3/Dynamips
■ Si ce n’est déjà fait, téléchargez PuTTY sur le site : http://www.chiark.greenend.org.uk/~sgtatham/putty/
■ Installez PuTTY sur la machine virtuelle VMWKS02. VMware offre deux possibilités quand il faut copier des fichiers
depuis la machine hôte vers une machine virtuelle :
1. Partager un répertoire de la machine hôte que la machine virtuelle voit comme un lecteur réseau. Cette
fonctionnalité, appelée Shared folders dans VMware, s’active depuis l’onglet Options de la fenêtre Virtual
Machine Settings.
2. Si les outils VMware (« VM Tools ») ont été installés sur la machine virtuelle, alors l’opération GlisserDéposer
fonctionne entre la machine hôte et les machines virtuelles.
■ Téléchargez GNS3 sur le site : www.gns3.net (GNS30.6.1win32allinone.exe 11309 Ko au moment où ces

lignes sont écrites). Installez GNS3 sur la machine virtuelle VMWKS02. Une fois l’installation terminée, GNS3 vous
propose de régler immédiatement un certain nombre de paramètres qu’il est possible de retrouver ensuite via la
commande de menu Editer Préférences :

■ La commande pour le terminal (point 3) permet de substituer PuTTY au Telnet intégré du système d’exploitation.
Les différents répertoires GNS3_Project, GNS3_IOS, GNS3_Work ont été créés au préalable. Respectez bien les
noms proposés afin de conserver la cohérence avec la suite de l’ouvrage (points 5, 6 et 8). En final, cliquez sur le
bouton Tester pour vérifier le lancement de Dynamips. GNS3 doit répondre Dynamips successfully started.
■ L’installation de GNS3 propose ensuite de renseigner l’image IOS à utiliser pour chaque plateforme qu’il lui est
possible d’émuler. Différez ce paramétrage, nous y reviendrons ultérieurement car il reste accessible via la
commande de menu Editer Images IOS et hyperviseurs.
■ Sur la machine hôte, vous êtes parvenu à récupérer une image CISCO IOS valide. Il est utile d’en vérifier les
fonctionnalités à l’aide de l’outil Cisco Feature Navigator (à entrer dans un moteur de recherche pour trouver le
lien) :
■ Parmi les caractéristiques fournies, l’une intéresse le fonctionnement de Dynamips : il s’agit de la quantité de
mémoire RAM nécessaire pour assurer le bon fonctionnement de l’IOS en question. Dans l’exemple cidessus,
l’image IOS est c2600ik9smz.12240a.bin destinée à faire fonctionner un routeur émulé de type 2621. L’outil
CISCO Feature Navigator informe que la plateforme doit disposer de 48 Mo de RAM.
■ Placez la précieuse image dans le répertoire GNS3_IOS de la machine virtuelle VMWKS02. Revenez à GNS3 et

lancez la commande de menu Editer Images IOS et hyperviseurs. Paramétrez GNS3 afin qu’il utilise par défaut
cette image pour la plateforme 2600 et en lui affectant 48 Mo de mémoire vive :
■ Ouvrez le gestionnaire de symboles via la commande de menu Editer Gestionnaire de symboles. Dans les
symboles disponibles, sélectionnez Computer et transférez ce symbole du côté Nœuds personnalisés. Double
cliquez sur Computer du côté Nœ uds personnalisés (au point 4) puis remplacez le type Nœud décoratif par le
type Nuage de la liste déroulante. Appliquez et fermez :
■ Créez un nouveau projet via la commande de menu Fichier Nouveau Projet de GNS3. Nommez votre premier
projet Atelier1a, veillez à bien cocher les cases Sauver les nvrams et autres disques (recommandé) ainsi que
Exporter les fichiers de configuration des routeurs. Confirmez. Quand le projet est ouvert et à chaque fois que la
topologie ou la configuration d’un routeur ont fait l’objet de modifications, il est possible de sauvegarder
l’ensemble en un seul clic sur le bouton étiqueté 2 :

■ Glissez/déposez un routeur C2600 sur la zone centrale de GNS3, zone destinée à recevoir votre topologie. Le
routeur est numéroté automatiquement R0. Effectuez un clic droit sur R0 et sélectionnez Configurer. Dans la
fenêtre Configurateur de nœuds, observez sans modifier l’onglet Mémoires et disques et notamment le
dimensionnement des deux partitions RAM et NVRAM du routeur. Dans l’onglet Slots, observez que par défaut, le
seul slot occupé l’est par une carte à deux ports Fast Ethernet. Nous aurons besoin également de ports WAN.
Dans la sousfenêtre WICs, ajoutez une carte WIC2T (deux ports de type « serial »). Appliquez et fermez :
■ Glissez/déposez un PC sur la topologie. Pour GNS3, il s’agit d’un nuage (Cloud) ce qui explique qu’il soit numéroté
C0. Effectuez un clic droit sur C0 et sélectionnez Configurer. Dans la fenêtre Configurateur de nœuds,
sélectionnez l’onglet NIO Ethernet. Déroulez la liste des adaptateurs réseau portés par la machine virtuelle
VMWKS02. Vous devez y retrouver les adaptateurs précédemment créés, c’estàdire NIC8, NIC11, NIC12, NIC21,
NIC22. Sélectionnez NIC8 puis cliquez sur Ajouter. Ainsi, ce nuage sera désormais connecté à l’adaptateur virtuel
NIC8 et donc au concentrateur VMnet8. Appliquez et fermez :

■ Cliquez sur le bouton de barre d’outils Ajouter un lien. Dans le menu contextuel qui s’affiche, sélectionnez Manual.
Le curseur devient une croix et le bouton de barre d’outils reste rouge pour indiquer que GNS3 est en mode
d’édition de liens. Cliquez sur R0 et sélectionnez le port Ethernet f0/0. Une connexion apparaît depuis R0.
Emmenez cette connexion jusqu’à C0. Parvenu à C0, GNS3 propose l’unique port affecté à ce nuage. Sélectionnez
le port proposé. Une connexion Ethernet est maintenant établie entre VMnet8 et f0/0 de R0. Cliquez à nouveau
sur le bouton de la barre d’outils Ajouter un lien afin de sortir du mode édition de liens :
■ Effectuez un clic droit sur R0 et sélectionnez Changer le nom d’hôte. Renommez R0 en R8. Faites de même afin de
renommer C0 en PCL8. Observez également qu’il est possible de modifier la position des étiquettes afin d’éviter le
chevauchement avec des liens. En final, vous devriez parvenir à une topologie comparable à celle proposée au
point 5 de la figure ciaprès :

■ Mettez en service puis réduisez en barre des tâches le Gestionnaire de tâches de Windows afin de surveiller
l’activité du processeur de la machine virtuelle VMWKS02 :
■ Il est temps de provoquer le démarrage de notre nouveau routeur sorti du carton. Effectuez un clic droit sur R8 et
sélectionnez Démarrer. Ne faites rien pendant quelques instants. Il est probable que ce démarrage consomme la
plus grande partie des ressources de votre machine. Une bizarrerie de programmation fait que Dynamips réclame
l’exclusivité du processeur tant qu’aucune valeur « temps mort » n’a été calculée. Effectuez un clic droit à nouveau
sur R8 et sélectionnez IdlePC. Dynamips se lance dans une surveillance de l’activité du processeur jusqu’à
détecter des boucles de programmation où le processeur est consommé « à vide ». De cette surveillance,
Dynamips déduit un certain nombre de valeurs temporelles (point 6). Les valeurs marquées d’une étoile sont celles
qui présentent une probabilité potentielle de relâchement adéquat de la ressource processeur par Dynamips. Si
vous n’observez aucune étoile, relancez le calcul et ce, autant de fois que nécessaire. Si c’est votre jour de
chance, une, voire plusieurs valeurs IdlePC « avec étoile » apparaissent dans la liste. Sélectionnez une de ces
valeurs et confirmez (point 8).

■ Vous devriez observer une baisse significative de l’activité processeur à la fois pour la machine virtuelle VMWKS02
et pour la machine hôte. Lancez la commande de menu Editer Images IOS et hyperviseurs. Dans la fenêtre
Images IOS et hyperviseurs, double cliquez sur l’image associée à la plateforme en cours d’émulation pour R8.
Observez que la valeur IDLE PC est dorénavant renseignée (comparez avec cette même fenêtre au début de
l’atelier). Ainsi, toute nouvelle instance de routeur issue de cette plateforme et déposée sur la topologie dispose
d’emblée d’une valeur IdePC, l’administrateur n’a pas à provoquer un nouveau calcul :
■ À ce stade, nous avons bien mérité de pouvoir lancer la console et ainsi taper nos premières commandes.
Effectuez un clic droit sur le routeur R8 et sélectionnez Console. Si tout va bien, c’est magique, nous voilà aux
commandes d’un routeur 2621. Répondez no à la proposition de setup, il sera toujours temps d’y revenir ensuite.
Pressez la touche [Entrée] et après quelques instants interminables, R8 consent à afficher l’invite de commandes.
L’interface ILC est en mode utilisateur. Passez en mode privilégié puis en mode de configuration afin de configurer
l’interface f0/0, c’estàdire l’interface connectée à VMnet8 donc à PCL8 :

■ Il est temps de sauvegarder notre projet. Cliquez sur le bouton Sauver la topologie de la barre d’outils. Saisissez
un nom qui vous convienne et confirmez. Cliquez sur le bouton Extract/Import all startupconfigs de la barre
d’outils (point 5). Dans la fenêtre Configs, sélectionnez Extracting to a directory et confirmez. Dans la fenêtre
Rechercher un dossier, choisissez par exemple GNS3_Work et confirmez. Observez le panneau Console situé au
bas de la fenêtre GNS3 : un message confirme que l’exportation s’est bien réalisée. Désormais, chaque nouvelle
sauvegarde de la topologie entraînera une extraction des fichiers de configuration startupconfigs vers le
répertoire GNS3_Work sans intervention de l’administrateur :
■ À la condition de régler la configuration IP de l’adaptateur virtuel NIC8 dans la machine virtuelle VMWKS02, il est
possible de pinguer le routeur R8 depuis VMWKS02 :

■ Il se trouve que sur le concentrateur VMnet8, nous avons également placé un adaptateur réseau virtuel hébergé
par la machine hôte. Cet adaptateur a été nommé NIC8. À la condition de régler la configuration IP de
l’adaptateur virtuel NIC8 dans la machine hôte, il est possible de pinguer le routeur R8 depuis la machine hôte :
■ N’activez l’adaptateur NIC8 de la machine hôte qu’au moment de vous en servir dans l’une des mises en situation
et désactivezle ensuite. En effet, quand cet adaptateur est activé, le système d’exploitation hôte dispose de deux
passerelles (celle de l’adaptateur réseau physique + celle de l’adaptateur virtuel) ce qui n’est une situation
acceptable que si les passerelles sont dans le même réseau. Dans le cas contraire, il est fort probable que la
machine hôte ne puisse plus par exemple sortir sur Internet.
■ Mais le plus intéressant est encore à venir. Ouvrez une seconde instance de VMware à l’aide de la commande de
menu File New Window. À l’aide de cette instance, ouvrez l’équipe de PC destinée aux tests. Pour le moment,
seul PCL8 est utile. Réglez la configuration IP de l’adaptateur réseau virtuel NIC8 qui équipe PCL8 : {@IP →
10.0.8.2/24 ; Passerelle → 10.0.8.1}. Tentez un ping vers R8 :

■ Vous êtes parvenu à ce stade. Sincèrement, félicitations et bravo de vos efforts. L’auteur a conscience que la mise
en place de ce contexte était lourde. Mais avouez que les perspectives ouvertes avec cette plateforme méritent
que l’on s’acharne !
e. Le mode setup
Aucun administrateur chevronné n’utiliserait le mode setup pour paramétrer un routeur. Ce paragraphe n’a donc
pour seul objet que de pouvoir répondre aux quelques questions que l’étudiant est susceptible de rencontrer dans
les épreuves de certification. Le mode setup inverse les rôles en posant des questions à l’administrateur dans le but
de bâtir une configuration minimale. L’IOS propose d’activer le mode setup quand il trouve un fichier de configuration
startupconfig vide pendant la séquence de démarrage. C’est toujours le cas d’un routeur sorti du carton, c’est
également le cas d’un routeur sur lequel l’administrateur aurait tapé la commande erase start :
R8#erase ?
/all Erase all files(in NVRAM)
/no-squeeze-reserve-space Do not reserve space for squeeze operation
flash: Filesystem to be erased
nvram: Filesystem to be erased
pram: Filesystem to be erased
startup-config Erase contents of configuration memory
R8#erase startup-config ?
<cr>
Au cas peu probable où l’administrateur souhaiterait relancer le mode setup, cela reste possible à l’aide de la
commande EXEC setup à entrer en mode privilégié.
À n’importe quel moment du mode setup, la combinaison de touches [Ctrl] C permet de mettre fin au processus.
Naturellement, les questions posées diffèrent selon le type de plateforme et la version d’IOS. Dans notre mise en
situation simulée à l’aide de GNS3 (Plateforme 2621, IOS 12.2(40a)), les questions ont été les suivantes :
Connected to Dynamips VM "R8" (ID 2, type c2600) - Console port
% Please answer ’yes’ or ’no’.

Would you like to enter the initial configuration dialog? [yes/no]: yes
At any point you may enter a question mark ’?’ for help.
Use ctrl-c to abort configuration dialog at any prompt.
Default settings are in square brackets ’[]’.
Basic management setup configures only enough connectivity

for management of the system, extended setup will ask you
to configure each interface on the system

Would you like to enter basic management setup? [yes/no]: no
First, would you like to see the current interface summary? [yes]:
Any interface listed with OK? value "NO" does not have a valid configuration
Interface IP-Address OK? Method Status

Protocol
FastEthernet0/0 unassigned NO unset up up
FastEthernet0/1 unassigned NO unset up up
Configuring global parameters:
Enter host name [Router]: R8
The enable secret is a password used to protect access to

privileged EXEC and configuration modes. This password, after
entered, becomes encrypted in the configuration.
Enter enable secret: ccna
The enable password is used when you do not specify an

enable secret password, with some older software versions, and
some boot images.
Enter enable password: ccent
The virtual terminal password is used to protect

access to the router over a network interface.
Enter virtual terminal password: ccie
Configure SNMP Network Management? [yes]: no
Configure IP? [yes]:
Configure IGRP routing? [yes]: no
Configure RIP routing? [no]:
Configure bridging? [no]:
Async lines accept incoming modems calls. If you will have

users dialing in via modems, configure these lines.
Configure Async lines? [yes]: no
Configuring interface parameters:
Do you want to configure FastEthernet0/0 interface? [yes]:

Use the 100 Base-TX (RJ-45) connector? [yes]:
Operate in full-duplex mode? [no]: yes
Configure IP on this interface? [yes]:
IP address for this interface: 10.0.8.1
Subnet mask for this interface [255.0.0.0]: 255.255.255.0
Class A network is 10.0.0.0, 24 subnet bits; mask is /24
Do you want to configure FastEthernet0/1 interface? [yes]: no
The following configuration command script was created:
hostname R8
enable secret 5 $1$cihY$rjw6EtAP7T48hLiV3kRDX0
enable password ccent
line vty 0 4
password ccie
no snmp-server
!
ip routing
no bridge 1
!
interface FastEthernet0/0
media-type 100BaseX
full-duplex
ip address 10.0.8.1 255.255.255.0
!

interface FastEthernet0/1
shutdown
no ip address
dialer-list 1 protocol ip permit
dialer-list 1 protocol ipx permit
!
End
[0] Go to the IOS command prompt without saving this config.

[1] Return back to the setup without saving this config.
[2] Save this configuration to nvram and exit.
Enter your selection [2]:

Building configuration...
Use the enabled mode ’configure’ command to modify this configuration.
Press RETURN to get started!
Observez les choix proposés à la fin du processus: le choix 0 ignore les réponses fournies et renvoie à l’invite de
commande de l’interface ILC, le choix 1 ignore les réponses et provoque un nouveau processus setup, enfin le choix
2 met en place la configuration bâtie à l’aide du mode setup en sauvegardant le fichier résultant en NVRAM.
Il est intéressant de constater que le choix 2 est le seul cas où l’IOS écrit à la fois dans le fichier runningconfig
présent en RAM et dans le fichier startupconfig présent en NVRAM.
Si le lecteur ne dispose pour unique ressource que ce seul ouvrage, alors il peut étudier l’exemple fourni. Bien sûr, il
gagnera à reproduire au moins une fois le processus sur un routeur réel ou émulé.
f. Accéder à l’interface puis passer en mode privilégié
Profitons du routeur dont nous disposons pour nous entraîner à en protéger les accès.
■ Reproduisez sur R8 les séquences de commandes suivantes :
R8>en
R8#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R8(config)#line vty 0 4
R8(config-line)#logging synchronous
R8(config-line)#exec-timeout 0 0
R8(config-line)#password ccna
R8(config-line)#login
R8(config-line)#exit
R8(config)#enable secret ccna
R8(config)#^Z
*Mar 1 09:04:20.924: %SYS-5-CONFIG_I: Configured from console by console
R8#copy run start
Destination filename [startup-config]?
[OK]
■ Sauvegardez en cliquant sur le bouton Sauver la topologie de la barre d’outils de GNS3.
g. Mise à profit de l’autocomplétion, de la détection d’erreurs de saisie, de l’aide
Vous avez sans doute observé différents messages sur la console, messages qui rapportent des évènements. Ces
messages sont produits par le processus SYSLOG. Par défaut, la manifestation de SYSLOG sur un routeur se limite à
l’émission des messages d’évènements vers le port console. Quel administrateur au cours de son travail depuis la
console n’a pas été agacé par l’arrivée impromptue de ces messages qui viennent perturber la saisie en cours ?
Problème facile à résoudre d’ailleurs car il existe une commande de configuration de ligne logging synchronous qui
peut être appliquée à la console ainsi qu’aux lignes vty et qui modifie le comportement de l’IOS quand il envoie un
message : si une commande est en cours de saisie, alors l’IOS réaffiche le contenu de la ligne saisie dans l’état où
elle se trouvait immédiatement avant l’envoi du message.
■ Placez l’interface en configuration de ligne console. Tapez les 4 caractères logg puis appuyez sur la touche [Tab]
et constatez que l’IOS complète la commande en affichant logging. Tapez les 2 caractères sy puis appuyez à

nouveau sur la touche [Tab] et constatez que l’IOS complète la commande en affichant logging synchronous. La
commande est complète et vous satisfait, il reste à valider par la touche [Entrée]. Vous venez de mettre à profit la
fonctionnalité d’autocomplétion de l’interface ILC :
R8#conf t
R8(config)#line con 0
R8(config-line)#logg
R8(config-line)#logging sy
R8(config-line)#
Au moindre petit temps mort dans notre activité (dix minutes par défaut), voilà la session console fermée par l’IOS.
Dans un environnement de production, cette mesure de sécurité se justifie pleinement. Mais dans notre
environnement didactique, que de temps perdu à ouvrir des sessions. Ce problème est facilement levé grâce à la
commande de configuration de ligne exectimeout. Cette commande définit le délai d’attente maximal de
l’interpréteur de commandes EXEC jusqu’à détection d’une entrée quelconque de l’utilisateur. Parvenu à ce délai, la
session est interrompue.
■ Placez l’interface en configuration de ligne console. Tapez les 4 caractères exec puis appuyez sur la touche ?,
l’aide contextuelle fournit trois commandes qui ont en commun de débuter par exec. Complétez la commande en
cours d’édition en tapant les caractères t puis la touche [Tab]. L’IOS complète la commande et affiche exec
timeout suivi d’un espace. Tapez à nouveau le point d’interrogation. L’aide affiche l’argument suivant attendu, il
s’agit d’un temps exprimé en minutes. Tapez 0 suivi d’un espace et à nouveau le point d’interrogation. Observez
que cette fois, deux choix sont possibles : appuyez sur la touche [Entrée] pour valider la commande telle qu’elle
est ou entrez un second argument permettant d’exprimer un temps en secondes. Validez par la touche [Entrée].
Vous venez de mettre à profit la fonctionnalité d’aide sur le mot puis la fonctionnalité d’aide sur la syntaxe :
R8 con0 is now available

Press RETURN to get started.
R8>en
Password:
R8#conf t
R8(config-line)#?
Line configuration commands:
... Extraits ...
exec-timeout Set the EXEC timeout
exit Exit from line configuration mode
flowcontrol Set the flow control
flush-at-activation Clear input stream at activation
full-help Provide help to unprivileged user
help Description of the interactive help system
history Enable and control the command history function
......
R8(config-line)#
R8(config-line)#exec?
exec exec-banner exec-character-bits exec-timeout
R8(config-line)#exec-t
R8(config-line)#exec-timeout ?
<0-35791> Timeout in minutes
R8(config-line)#exec-timeout 0 ?
<0-2147483> Timeout in seconds
<cr>
R8(config-line)#exec-timeout 0
■ Vous êtes toujours en configuration de ligne console. Simulez une erreur de frappe en tapant la commande exec
tileout 0 puis validez par la touche [Entrée]. Observez que l’IOS ne se contente pas de refuser la commande mais
place un caractère ^ à partir de la position incorrecte dans la ligne de commande :
R8(config-line)#exec-tileout 0
^
% Invalid input detected at ’^’ marker.

R8(config-line)#
■ Vous êtes toujours en configuration de ligne console. Simulez une entrée incomplète en tapant la commande
exectimeout sans arguments puis validez par la touche [Entrée]. Observez la réaction de l’IOS. C’est
typiquement un cas où l’historique de commandes est précieux : un appui sur la touche [Flèche en haut] et revoici
la commande incomplète, un appui supplémentaire sur le point d’interrogation et l’administrateur comprend
l’argument attendu par l’IOS :
R8(config-line)#exec-timeout
% Incomplete command.
R8(config-line)#
R8(config-line)#exec-timeout ?
<0-35791> Timeout in minutes
R8(config-line)#
h. Mise à profit de l’historique des commandes
■ Vous êtes toujours en configuration de ligne console.
■ Utilisez les touches de déplacement [Flèche en haut] et [Flèche en bas] pour vous déplacer dans l’historique des
commandes ; observez que seules les commandes valides dans le contexte sont rappelées.
■ Changez de contexte en revenant au mode privilégié. À nouveau, rappelez les commandes précédentes et
observez que cette fois l’historique affiche les commandes précédemment entrées dans ce mode privilégié.
Cet atelier est à présent terminé. Bien sûr, le lecteur peut le prolonger à loisir. L’important est de disposer d’un
contexte fonctionnel pour les ateliers à venir des chapitres suivants.

Mise en situation
Toutes les captures de ce chapitre ont été réalisées sur la topologie suivante :
Les routeurs sont des 2600, l’IOS est une version 12.4. Le serveur VMSRV01 est un serveur Windows 2000 utilisé
chaque fois qu’il est utile de disposer de services réseau. Dans le cas présent, c’est le service DNS qui est mis à profit.
L’administrateur y a créé une zone ccna.fr ainsi que deux enregistrements R11 et R12. Le lecteur gagnera à reproduire
cette topologie puis à tester l’ensemble des lignes de commandes proposées.

Configuration des paramètres globaux
1. Configurer l’invite de commande
Par défaut, l’invite de commande résulte de la concaténation de trois informations :
1. Le nom du routeur, « Router » quand le nom n’a pas encore été configuré.
2. Le contexte quand l’interface ILC quitte le mode d’exécution. Exemple (config) quand le mode de l’interface ILC est
le mode de configuration globale.
3. Le caractère de prompt « > » ou « # » qui rappelle le niveau de privilège, « > » rappelle le mode utilisateur, « # »
rappelle le mode privilégié.
Il est possible de compléter l’information fournie à l’aide de la commande prompt dont la syntaxe est la suivante :
● prompt string
● Mode de configuration globale.
● String est toute chaîne de caractères dans laquelle il est possible d’inclure un certain nombre de
variables. Une variable de prompt est précédée du caractère « % ». Le tableau suivant inventorie les
variables de prompt possibles :
Variable de Interprétation
prompt
%h Le « h » rappelle hostname. L’IOS remplace cette variable par le nom du routeur

ou « Router » quand le nom n’est pas configuré.
%n Numéro de ligne CON (n°0), TTY (lignes physiques), AUX ou VTY. Pour mémoire, il
est possible d’obtenir de l’information sur ces numéros à l’aide d’une commande
show users ou d’une commande show line.
%p Le caractère de prompt « > » ou « # ».
%s Caractère espace.
%t Tabulation.
%% Caractère %.
L’invite de commande par défaut correspond par conséquent à la commande prompt %h%p. Voici une proposition de
prompt modifié pour inclure le n° de ligne utilisé :
R11(config)#prompt TTY%n@%h%s%p
R11(config)#^Z
TTY66@R11 #sh line
Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int
* 0 CTY - - - - - 0 1 0/0 -
65 AUX 9600/9600 - - - - - 0 0 0/0 -
* 66 VTY - - - - - 1 0 0/0 -
67 VTY - - - - - 0 0 0/0 -
68 VTY - - - - - 0 0 0/0 -
69 VTY - - - - - 0 0 0/0 -
70 VTY - - - - - 0 0 0/0 -
Line(s) not in async mode -or- with no hardware support:1-64
TTY66@R11 #disable
TTY66@R11 >
Deux sessions sont ouvertes sur R11, l’une via le port console qui porte le numéro 0, l’autre via Telnet à laquelle l’IOS

a attribué le premier numéro VTY disponible, soit le numéro 66. La capture suivante illustre le changement de l’invite
de commande sur la session console :
*Mar 1 01:13:03.706: %SYS-5-CONFIG_I: Configured from console by vty0

(10.0.11.100)
R11#
TTY0@R11 #
2. Configurer un nom d’hôte
La commande à utiliser est :
● hostname name
● Attribution d’un nom d’hôte au routeur.
● La valeur par défaut est « Router ».
Le RFC1178 « Name your computer » peut servir de guide pour l’élaboration de noms valides : un nom d’hôte doit
débuter par une lettre, se terminer par une lettre ou un chiffre et ne devrait pas prendre la casse en compte. La
longueur ne devrait pas dépasser 63 caractères. On se souvient que le nom d’hôte est rappelé dans l’invite de
commande associé au contexte. Il se trouve que l’ensemble concaténé {nom d’hôte + contexte} ne peut dépasser 30
caractères. Audelà, l’interface ILC tronque le nom ou le contexte. Or, ces informations sont d’une importance majeure
pour l’administrateur qui serait sans doute très désorienté si l’invite de commandes ne lui rappelait pas de façon
exhaustive le vrai contexte courant :
Router>en
Router#conf t
Router(config)#hostname LeNomDeMonRouteurEstTropLong
LeNomDeMonRouteurEst(config)#exit
LeNomDeMonRouteurEstTropLong#
Dans l’exemple cidessus, l’interface a tronqué le nom pour permettre l’affichage du contexte. Le nom ne réapparaît au
complet qu’une fois sorti du mode de configuration. CISCO conseille par conséquent de limiter le nom d’hôte à 10
caractères :
LeNomDeMonRouteurEstTropLong#conf t
LeNomDeMonRouteurEst(config)#hostname R11
R11(config)#exit
R11#
Une ultime possibilité consiste à modifier la longueur admise de la chaîne hostname. Nous la citons pour mieux
l’oublier, d’autant que, sauf erreur, elle n’est pas documentée par le site « Command Lookup Tool » de Cisco :
R11(config)#prompt config hostname-length ?

<0-80> maximum hostname length
R11(config)#prompt config hostname-length 50

R11(config)#hostname LeNomDeMonRouteurEstTropLong
LeNomDeMonRouteurEstTropLong(config)#
LeNomDeMonRouteurEstTropLong(config)#hostname R11
R11(config)#^Z
R11#
Une entreprise bien organisée a probablement déjà élaboré une convention de nommage des équipements réseau.
Un administrateur nouvellement recruté doit s’enquérir de cette convention et doit en proposer une si elle n’existe
pas. Une bonne convention de nommage aide à mémoriser les noms de routeurs et aide à deviner un nom que
l’administrateur aurait oublié. Par exemple, on peut imaginer faire débuter tous les noms de routeurs par la séquence
« rtr » suivi d’une séquence rappelant la géolocalisation de l’équipement, les initiales de la ville peuvent convenir sur
un nombre de lettres choisi par avance, et terminer par une séquence de deux chiffres afin de prévoir le cas où une
même localisation accueille plusieurs routeurs. Ainsi, le premier routeur placé à Dunkerque serait « rtrdk01 ». Ce
nom est facile à deviner en ne connaissant que la convention de nommage.

Le caractère « underscore » (« _ ») doit être évité d’autant qu’il n’est pas admis par la résolution de noms DNS. Si
l’envie prend d’utiliser ce caractère, alors il est préférable de lui substituer le caractère « ».
3. Configurer une bannière
L’IOS supporte trois types de bannières et les affiche dans cet ordre :
1. La bannière motd (Message Of The Day) sans doute la moins utilisée. L’administrateur peut la mettre à profit pour
avertir toute personne qui se connecterait sur l’équipement d’une actualité qui concerne l’équipement ou le réseau.
Exemple : ce routeur sera redémarré le 01 avril 2010 à 0h00.
2. La bannière login est utilisée pour afficher un message d’avertissement en vue de prévenir l’utilisateur des pires
déconvenues au cas où il persisterait à vouloir se connecter alors qu’il ne fait pas partie des personnels autorisés.
Évacuons, une bonne fois pour toutes, les messages type Bienvenue d’une rare incongruité dans ces circonstances. La
bannière login est une pierre dans l’édification d’une politique de sécurité.
3. La bannière exec est la plus intéressante puisqu’elle permet l’affichage d’un message une fois la session ouverte,
c’estàdire une fois l’utilisateur authentifié. C’est donc un administrateur qui s’adresse à un autre administrateur.
Cette configuration...
R11#conf t
R11(config)#banner motd #
Enter TEXT message. End with the character ’#’.
Ceci est la banniere motd
#
R11(config)#banner login #
Ceci est la banniere login
#
R11(config)#banner exec #
Ceci est la banniere exec
#
R11(config)#^Z
R11#
... provoque l’affichage des messages...
R11 con0 is now available
Press RETURN to get started.
Ceci est la banniere motd

Ceci est la banniere login
User Access Verification
Password:
Ceci est la banniere exec
R11>
Puisqu’un message peut occuper plusieurs lignes, l’administrateur doit choisir un caractère qui délimitera le début et la
fin du message, tout caractère fait l’affaire à la condition de ne pas apparaître dans le corps du message, « # » a été
choisi dans les captures de ce chapitre.
Configurons une bannière de login un peu plus crédible :
R11#conf t
R11(config)#
R11(config)#banner login #
**********************************************************************
**** Avertissement ! Acces aux seules personnes autorisees ! ****
**** Vos activites au cours de cette session sont susceptibles ****
**** d’etre enregistrees. Toute activite illicite fera l’objet ****
**** d’un recours en justice ! ****

**********************************************************************
#
R11(config)#^Z
R11#
Depuis la version 12.0(3)T de l’IOS, il est possible d’insérer des variables système dans un message de bannière. Lors
de l’affichage, l’IOS substitue la valeur à la variable. Appelées « tokens » par CISCO, ces variables sont au nombre de
quatre au moment où ces lignes sont écrites :
« Token » Information correspondante
$(hostname) Nom d’hôte du routeur.
$(domain) Nom de domaine configuré sur le routeur.
$(line) Numéro de la ligne active.
$(linedesc) Description de la ligne active.
Mettons à profit ces variables pour créer une bannière exec sur R12 :
R12(config)#banner exec #
Bienvenue, vous venez de vous connecter au routeur $(hostname).$(domain)
depuis la ligne $(line) situe $(line-desc).
#
R12(config)#^Z
R12#
Si la liaison entre R11 et R12 est convenablement configurée, si au moins une ligne vty est configurée, si un nom de
domaine a été configuré sur R12 (objet des paragraphes suivants), une tentative de connexion Telnet depuis R11
donne le résultat suivant :
R11#telnet 10.0.8.12
Trying 10.0.8.12 ... Open
Password:
Bienvenue, vous venez de vous connecter au routeur R12.ccna.fr
depuis la ligne 66 situe 44811 SAINT HERBLAIN.
R12>exit
[Connection to 10.0.8.12 closed by foreign host]

R11#
4. Protection du passage au mode privilégié
Commandes déjà commentées dans le chapitre Les routeurs.

Sur R11 (à reproduire sur R12) :
R11(config)#enable secret ccna

R11(config)#^Z
R11#
Un cas réel nécessiterait de respecter des règles de longueur et de complexité du mot de passe. Mais une vraie
politique de sécurité consisterait à mettre en place une authentification fondée sur l’utilisation de couples {nom
d’utilisateur/mot de passe}. Cette authentification peut être locale, les couples {nom d’utilisateur/mot de passe} sont
alors mémorisés sur le routeur, ou centralisée, les identifiants sont dans ce cas conservés par un serveur RADIUS par
exemple.
5. Résolution de noms

Cette section est placée ici parce que les commandes de configuration dont il est question sont à entrer en mode de
configuration globale. Mais les démonstrations réalisées sur la topologie de mise en situation ne peuvent fonctionner
que si la configuration des interfaces a été réalisée. Merci donc au lecteur qui a pris la peine de reproduire la topologie
de bien vouloir se reporter à la section Configuration des interfaces, puis de revenir ensuite à cette section Résolution
de noms.
À ce stade d’avancement dans le cursus CCNA, il est inutile d’insister à nouveau sur l’intérêt d’identifier les machines
par des noms plutôt que par des adresses. Il est également possible d’utiliser des noms d’hôtes sur les routeurs, ce à
la condition de prévoir une résolution de noms, c’estàdire la possibilité pour une machine de traduire le nom d’hôte
en identifiant numérique (l’adresse). Deux possibilités s’offrent alors :
● Une résolution dynamique qui consiste à interroger un serveur DNS.
● Une résolution statique qui contraint l’administrateur à renseigner les correspondances dans la configuration
du routeur.
La résolution de noms est active par défaut, ce qui peut parfois entraîner quelques désagréments, comme l’illustre la
capture ciaprès. L’administrateur sur R11 se trompe et tape R13 au lieu de R12. Aucun serveur DNS n’est configuré
sur R11, qui tente de résoudre R13 en diffusant une requête DNS vers l’adresse de diffusion limitée 255.255.255.255.
Cette requête ne peut franchir R12, n’est donc pas transmise au serveur DNS de notre topologie et reste sans
réponse. R11 attend de longues secondes une réponse qui ne vient pas puis réitère deux fois la requête.
R11#R13
Translating "R13"...domain server (255.255.255.255)

(255.255.255.255)
% Unknown command or computer name, or unable to find computer address
Ainsi, à cause d’une erreur de frappe, l’administrateur est « privé de console » pendant un temps qui semble toujours
trop long. En conclusion, si l’administrateur n’a pas l’intention d’utiliser le service de résolution de noms, alors il est
préférable de le désactiver à l’aide de la commande no ip domainlookup :
R11#conf t
R11(config)#no ip domain-lookup
R11(config)#^Z
R11#
La même erreur de frappe est simulée après avoir désactivé le service de résolution de noms :
R11#R13
Translating "R13"
Translating "R13"
% Unknown command or computer name, or unable to find computer address
R11#
L’IOS ne génère plus de requête vers le serveur DNS et se contente de consulter son cache local, il n’y trouve pas R13
et rend la main presque immédiatement.
Les commandes permettant la configuration de la résolution de noms sont les suivantes :
● hostname name
● Déjà explicitée, mais en fait oui, en attribuant un nom d’hôte au routeur, cette commande participe à la
configuration de la résolution de noms.
● ip host {hostname} [tcpportnumber] {@IP1} [@IP2 @IP3 ...]}
● Crée une entrée statique de résolution de nom dans la table d’hôtes.
● [tcpportnumber] : port TCP à utiliser pour une connexion Telnet, 23 par défaut.

● La commande accepte plusieurs adresses IP associées à un seul et même nom d’hôte.
● [no] ip domainlookup
● Active/Désactive la résolution dynamique de noms (c’estàdire celle faisant appel à un serveur DNS).
● ip nameserveur {@DNS1 [@DNS2 @DNS3 ... @DNS6]}
● Spécifie le ou les serveurs DNS que le routeur doit interroger pour résoudre les noms.
● Jusqu’à 6 serveurs DNS différents.
● ip domainname {name}
● Quand l’administrateur cherche à résoudre un nom qui n’est pas pleinement qualifié (FQDN, Fully
Qualified Domain Name), l’IOS complète le nom relatif fourni avec le nom du domaine tel qu’il est défini à
l’aide de cette commande. Rappel :
● www.jules.dechezsmith.enface. avec le point final (le point final représente la racine de

l’arborescence) est un nom pleinement qualifié.
● www.jules est un nom relatif.
Mettons ces commandes à profit en deux temps. Dans un premier temps, en configurant une résolution statique sur
R11. Dans un second temps, en configurant une résolution DNS sur R11 et R12.
a. Résolution statique
R11(config)#no ip domain-lookup
R11(config)#ip host R12 10.0.8.12
R11(config)#^Z
R11#
*Mar 1 01:50:14.939: %SYS-5-CONFIG_I: Configured from console by console (59140
DUNKERQUE)
Désormais, rien de plus simple que de se connecter à R12 :
R11#R12
Trying R12 (10.0.8.12)... Open
Password:
depuis la ligne 66 situe 44811 SAINT HERBLAIN.
R12>exit
[Connection to R12 closed by foreign host]
R11#
Une commande show host permet de consulter la table de correspondances noms d’hôte/adresses IP :
R11#sh host
Default domain is not set

Name/address lookup uses static mappings
Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate

temp - temporary, perm - permanent
NA - Not Applicable None - Not defined
Host Port Flags Age Type Address(es)

R12 None (perm, OK) 0 IP 10.0.8.12
R11#
Les champs de cette table sont explicités dans le tableau ciaprès :
Information Description
Host Nom d’hôte de chaque correspondance présente dans la table.
Port Port utilisé lors d’une connexion Telnet si différent de 23.
Flags Drapeaux décrivant la méthode d’apprentissage de cette correspondance ainsi que son
degré de pertinence.
Perm → correspondance statique, ajoutée par l’administrateur.
Temp → correspondance acquise via un serveur DNS.
OK → correspondance valide.
EX → correspondance expirée.
Age Exprimé en heures, temps écoulé depuis l’instant où la correspondance a été apprise.
Type Type d’adresse.
Address Adresse(s) associée(s) à ce nom d’hôte.
b. Résolution dynamique
Un serveur DNS a été ajouté sur LAN12 de la topologie en cours. Son adresse IP est 10.0.12.100. Il héberge la zone
ccna.fr et l’administrateur y a ajouté deux enregistrements R11 et R12 :
Sur R11 (à reproduire sur R12) :
R11(config)#no ip host R12 10.0.8.12

R11(config)#ip domain-lookup
R11(config)#ip domain-name ccna.fr
R11(config)#ip name-server 10.0.12.100
R11(config)#^Z
R11#

DUNKERQUE)
R11#
Une commande show host montre que la table de correspondances est vide :
R11#sh host
Default domain is ccna.fr
Name/address lookup uses domain service
Name servers are 10.0.12.100

R11#
Sollicitons la résolution en tentant une connexion Telnet sur R12 :
R11#R12
Translating "R12"...domain server (10.0.12.100) [OK]
Trying R12.ccna.fr (10.0.12.1)... Open
Password:
depuis la ligne 66 situee 44811 SAINT HERBLAIN.
R12>exit
[Connection to R12 closed by foreign host]
Vérifions à nouveau le contenu de la table de correspondances. Cette fois R12 apparaît :
R11#sh host
Default domain is ccna.fr
Name/address lookup uses domain service
Name servers are 10.0.12.100


R12.ccna.fr None (temp, OK) 0 IP 10.0.12.1
R11#
6. Date et heure
Parmi les multiples tâches accomplies par l’IOS, l’une d’elles intéresse particulièrement l’administrateur parce qu’elle lui
permet de découvrir ou de mieux comprendre les évènements qui affectent le fonctionnement du routeur et donc du
réseau. Il s’agit de l’activité de journalisation des évènements. En la matière, CISCO comme une majorité de
constructeurs se conforme au protocole SYSLOG normalisé dans le RFC 5424. Par défaut, la manifestation de SYSLOG
sur un routeur se limite à l’émission des messages d’évènements vers le port console. Ces évènements sont
horodatés, mais pour que la date et l’heure associées à un évènement prennent du sens, encore fautil que l’horloge
entretenue par chaque routeur soit ellemême « mise à l’heure ». Deux moyens s’offrent à l’administrateur :
1. Configurer l’heure et la date directement sur le routeur. Hélas, ceci contraint l’administrateur à intervenir sur chacun
des routeurs dont il a la charge.
2. Transformer l’un des routeurs en serveur de temps et régler les autres routeurs afin de récupérer l’heure sur le
serveur de temps.
Notre topologie nous offre l’occasion de tester les deux méthodes. Dans un premier temps, R12 sera mis à l’heure.
Dans un second temps, R12 sera configuré pour être serveur de temps puis R11 sera configuré pour obtenir l’heure de

R12. Les commandes nécessaires à cette configuration sont les suivantes :
● show clock
● Affiche la date et l’heure du système.
● clock set {hh:mm:ss} {day} {month} {year}
● Mode privilégié.
● « hh » exprime l’heure de 0 à 23.
● « day » exprime le jour de 1 à 31.
● « month » est le nom du mois.
● « year » exprime l’année sur 4 chiffres.
● ntp master [#stratum]
● Fait de ce routeur un serveur de temps.
● #stratum : optionnelle, le serveur de temps configuré sur ce système se réclame comme étant de
strate #stratum. La valeur doit être comprise entre 1 et 15 et vaut 8 par défaut.
● ntp server {hostname | @IP }
● Fait de ce routeur un client du serveur de temps identifié par son nom (si une résolution de noms est
en service sur le routeur) ou par son adresse IP.
Le protocole NTP (Network Time Protocol) se fonde sur une architecture arborescente. Une heure de référence est
diffusée verticalement de proche en proche. Chaque nœ ud choisit parmi ses parents le nœ ud qui présente les
meilleures garanties de fiabilité et hérite d’un attribut appelé « stratum ». Les machines placées à la racine sont sur le
« stratum » 1 et se synchronisent directement sur des dispositifs matériels donnant l’heure. Pendant la descente,
chaque traversée d’un nœ ud incrémente de 1 la valeur « stratum ». Les nœ uds placés sur la couche 2 (strate) se
synchronisent sur les nœ uds de strate 1, les nœ uds placés sur la couche 3 se synchronisent sur les nœ uds de strate
2 et ainsi de suite. En final, la valeur « stratum » mesure la distance d’un nœ ud aux machines racines et peut être
considérée comme un indicateur de la qualité de synchronisation qu’une machine donnée peut offrir aux nœ uds placés
sur les niveaux inférieurs.
Un routeur peut être configuré en NTP maître. Dans ce cas, et s’il ne parvient pas à joindre un serveur NTP de strate
inférieure (c’estàdire d’un niveau plus élevé dans la hiérarchie), alors le système se considère synchronisé sur la
strate de numéro « #stratum » et les autres systèmes peuvent à leur tour se synchroniser sur ce système.
Mise à l’heure de R12 :
R12#sh clock
*03:09:49.089 UTC Fri Mar 1 2002
R12#clock set ?
hh:mm:ss Current Time
R12#clock set 10:38:00 ?

<1-31> Day of the month
MONTH Month of the year
R12#clock set 10:38:00 21 ?

MONTH Month of the year
R12#clock set 10:38:00 21 february ?

<1993-2035> Year
R12#clock set 10:38:00 21 february 2010

R12#
*Feb 21 10:38:00.004: %SYS-6-CLOCKUPDATE: System clock has been updated from
03:11:40 UTC Fri Mar 1 2002 to 10:38:00 UTC Sun Feb 21 2010, configured from
console by console.
R12#sh clock
10:38:13.558 UTC Sun Feb 21 2010
R12#
Faisons de R12 un serveur de temps :
R12(config)#ntp ?
access-group Control NTP access
authenticate Authenticate time sources
authentication-key Authentication key for trusted time sources
broadcastdelay Estimated round-trip delay
clock-period Length of hardware clock tick
logging Enable NTP message logging
master Act as NTP master clock
max-associations Set maximum number of associations
peer Configure NTP peer
server Configure NTP server
source Configure interface for source address
trusted-key Key numbers for trusted time sources
R12(config)#ntp master ?
<1-15> Stratum number
<cr>
R12(config)#ntp master
R12(config)#^Z
R12#
Faisons de R11 un client du serveur de temps R12 :
R11(config)#ntp ?
access-group Control NTP access
authenticate Authenticate time sources
authentication-key Authentication key for trusted time sources
broadcastdelay Estimated round-trip delay
clock-period Length of hardware clock tick
logging Enable NTP message logging
master Act as NTP master clock
max-associations Set maximum number of associations
peer Configure NTP peer
server Configure NTP server
source Configure interface for source address
trusted-key Key numbers for trusted time sources
R11(config)#ntp server ?
Hostname or A.B.C.D IP address of peer
vrf VPN Routing/Forwarding Information
R11(config)#ntp server R12

R11(config)#^Z
R11#
DUNKERQUE)
R11#sh clock
03:21:57.992 UTC Fri Mar 1 2002
R11#sh clock
03:36:10.406 UTC Fri Mar 1 2002
R11#sh clock
.11:04:26.166 UTC Sun Feb 21 2010
R11#
Notre propos n’étant pas l’étude du protocole NTP, nous n’irons pas plus loin, les lecteurs insatiables trouveront la

capture des échanges NTP entre client et serveur téléchargeable sur le site ENI sous le nom cap_22_02.pcap.
Puisque aucune valeur #stratum n’a été configurée, on peut observer la valeur 8 dans les réponses NTP du routeur
R12. Après quelques échanges NTP, R11 adopte l’heure récupérée sur R12.

Configuration des accès
1. Accès console et Telnet
Sur R11 (à reproduire sur R12), accès console :
R11(config-line)#location 59140 DUNKERQUE
R11(config-line)#password eni
R11(config-line)#^Z
R11#
Sur R12 (à reproduire sur R11), accès Telnet :
R12(config)#line vty 0 4
R12(config-line)#password eni
R12(config-line)#location ?
LINE One text line describing the terminal’s location
R12(config-line)#location 44811 SAINT HERBLAIN

R12(config-line)#exit
Ces commandes ont déjà été commentées dans le chapitre Les routeurs. Le mot de passe de l’accès console n’est
pas absolument indispensable si l’on considère qu’il s’agit d’un accès physique et qu’il suppose donc que
l’administrateur ait pénétré dans un local sécurisé.
2. Accès http
Par défaut, l’IOS active un serveur http à l’aide de la commande de configuration globale :
● [no] ip http server
● Active/désactive le serveur http interne du routeur.
● Actif par défaut.
Accéder à ce service nécessite de disposer d’un navigateur Web et d’y entrer l’adresse IP d’une interface du routeur.
Lors de la connexion, le serveur demande à l’utilisateur de s’authentifier. À moins qu’une authentification plus forte
n’ait été configurée, il suffit de laisser le champ nom d’utilisateur vide et de taper le mot de passe qui protège le
passage au mode privilégié.

Configuration des interfaces
En connectant le routeur à son environnement, les interfaces LAN et WAN permettent au routeur d’assurer la tâche pour
laquelle il a été conçu, c’estàdire l’acheminement des paquets. Il faut encore y ajouter l’interface de loopback, interface
virtuelle qui peut rendre de nombreux services : l’adresse IP affectée à l’interface peut fournir un identifiant au routeur,
l’interface peut servir de destination aux paquets indésirables, l’interface virtuelle peut simuler une interface réelle, liste
non exhaustive.
Une commande show interfaces affiche une information très complète sur chacune des interfaces embarquées par le
routeur. Pour une interface LAN :
R11#sh int
FastEthernet0/0 is up, line protocol is up
Hardware is AmdFE, address is c801.02cc.0000 (bia c801.02cc.0000)
Description: LAN11
Internet address is 10.0.11.1/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:49, output 00:00:02, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
4 packets input, 526 bytes
Received 4 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
11 packets output, 1583 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Pour une interface WAN :
Serial0/0 is up, line protocol is up

Hardware is PowerQUICC Serial
Description: Lien loue 64K vers Nantes
Internet address is 10.0.8.11/24
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input 00:00:01, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 48 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
12 packets input, 1329 bytes, 0 no buffer
Received 12 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
9 packets output, 1143 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out

0 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
On y trouve notamment :
● l’adresse IP ainsi que le masque de sousréseau ;
● l’adresse de couche 2 ;
● l’encapsulation utilisée ;
● des statistiques sur le trafic qui transite par l’interface ;
● et le plus important : l’état de l’interface à la fois en couche physique et en couche liaison.
En effet, les fonctionnalités de la couche 3 (le routage) s’appuient sur les couches 1 et 2 et ne peuvent être
opérationnelles que si les interfaces sont actives à la fois en couche 1 et en couche 2. À ce sujet, la commande show la
plus pertinente est certainement la commande show ip interfaces brief que l’on peut abréger en sh ip int br :
R11#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.0.11.1 YES NVRAM up up
Serial0/0 10.0.8.11 YES NVRAM up up
FastEthernet0/1 unassigned YES NVRAM administratively down down
Serial0/1 unassigned YES NVRAM administratively down down
R11#
● L’état actif en couche 1 suppose :
● Que l’administrateur ait activé l’interface à l’aide d’une commande no shutdown. Dans le cas contraire,
l’interface reste dans l’état « administratively down ».
● Qu’il y ait bien une connectivité physique entre cette interface et l’interface de l’équipement en visàvis.
Par exemple, une interface WAN est connectée à son boîtier CSU/DSU luimême actif, une interface LAN
est connectée à un port de commutateur actif, les câbles utilisés sont en bon état et sont bien les
câbles attendus, liste très peu exhaustive hélas. Dans le cas contraire, l’interface reste dans l’état
« down ».
Une interface en couche 1 est dans l’un des trois états « administratively down », « down » ou « up ».
● L’état actif en couche 2 suppose :
● Que la couche 1 soit active.
● ET qu’il y ait compatibilité de protocole sur les couches 2 respectives des interfaces en visàvis. Dans le
cas d’une interface LAN, pas de problème depuis la prééminence d’Ethernet. Dans le cas d’une interface
WAN, l’administrateur doit avoir configuré le même protocole de couche 2 aux deux extrémités du lien.
Par défaut, l’IOS réalise une encapsulation HDLC (HighLevel Data Link Control).
● ET que l’interface reçoive les trames « Keepalive »...
● Concrètement, une interface s’assure de l’état de la couche 2 à l’aide de trames « Keepalive ».

Toute interface active en couche 1 émet de façon périodique une telle trame (voir « Keepalive set
10 sec » dans la capture cidessus, la période est configurable). Toute interface qui n’a pas reçu
de trame « Keepalive » depuis un délai suffisant passe dans un état « down » en couche 2.
Une interface en couche 2 est dans l’un des deux états « down » ou « up ».
Dans le cas d’une interface LAN, chaque interface envoie des trames « Keepalive » vers sa propre adresse. Ces trames

sont repérées « LOOP » dans l’extrait de capture cidessous :
Dans le cas d’une interface WAN et d’une encapsulation HDLC, CISCO met à profit sa déclinaison de ce protocole, il
s’agit pour l’essentiel de distinguer le protocole encapsulé en incluant dans la trame HDLC un champ « Protocol Code ».
Parmi les autres extensions au protocole HDLC, CISCO a également inclus la définition d’un protocole appelé SLARP
(Serial Line ARP). SLARP permet à une interface de s’attribuer une adresse IP en fonction de l’adresse IP affectée à
l’interface placée à l’autre extrémité du lien. En cela, SLARP est similaire à RARP. SLARP inclut également une trame «
Keepalive » émise par défaut toutes les 10 secondes. Les deux extrémités du lien doivent utiliser le même intervalle pour
assurer un fonctionnement fiable. Les trames « Keepalive » sont numérotées en séquence à partir de 0. Les deux
extrémités numérotent de façon indépendante. Outre le numéro de séquence attribué à la trame « Keepalive » en cours
de préparation, le système place également dans la trame le dernier numéro reçu de l’autre système :
Immédiatement avant d’émettre une trame « Keepalive », un système compare le numéro de séquence émis et le
dernier numéro de séquence acquitté par l’autre extrémité :

Quand la différence entre numéro de séquence émis et dernier numéro acquitté atteint 3, l’IOS considère que la liaison
est à l’état DOWN et ne peut plus servir à l’acheminement de paquets. Ainsi, 30 secondes au plus s’écoulent entre
l’incident qui affecte la bonne réception des trames « Keepalive » et sa prise en compte par les protocoles de routage.
Voici le résultat de la même commande sh ip int br quand l’interface s0/0 de R11 est laissée réglée sur l’encapsulation
par défaut HDLC alors que l’interface s0/0 de R12 est configurée pour adopter une encapsulation différente (en
l’occurrence PPP, Pointtopoint Protocol) :
R11#sh ip int br
Serial0/0 10.0.8.11 YES NVRAM up down
FastEthernet0/1 unassigned YES NVRAM up up
R11#
1. Configuration des interfaces LAN
Les commandes à utiliser sont les suivantes :
● interface {ethernet | fastethernet | gigabitethernet} {numéro}
● La commande provoque le passage en configuration d’interface.
● [no] shutdown
● Mode de configuration d’interface.
● Active/désactive l’interface.
● La commande no shutdown apparaît explicitement dans le fichier de configuration. La commande

shutdown active l’interface mais n’apparaît pas dans le fichier de configuration.
● ip address {@IP} {masque} [secondary]
● Affecte une adresse IP à l’interface.

● Il est possible d’affecter plusieurs adresses IP à la même interface. On ne change rien à la façon
d’assigner la première adresse IP à l’aide de la commande ip address en configuration d’interface. La
seconde adresse (et les suivantes si nécessaire) sont affectées à l’aide de la même commande à
laquelle on ajoute le motclé secondary.
● description {string}
● Permet d’associer à l’interface tout commentaire susceptible d’aider l’administrateur selon l’adage «
Tout ce qui paraît clair aujourd’hui semblera très obscur dans six mois ».
● N’a de signification que localement. Outre une commande show run ou show start, la description est
également affichée par une commande show interfaces.
● String est limitée à 238 caractères.
Sur R11 :
R11#conf t
R11(config)#int f0/0
R11(config-if)#description LAN11
R11(config-if)#ip address 10.0.11.1 255.255.255.0
R11(config-if)#no shutdown
R11(config-if)#^Z
R11#
*Mar1 04:55:33.798: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar1 04:55:34.800: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0,
changed state to up
Sur R12 :
R12(config)#int f0/0
R12(config-if)#description LAN12
R12(config-if)#^Z
R12#
*Mar1 01:04:52.060: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar1 01:04:53.061: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0,
changed state to up
2. Configuration des interfaces WAN
Aux commandes utiles à la configuration des interfaces LAN, il convient d’ajouter les commandes clock rate et
bandwidth :
● interface {serial | async} {numéro}
● Le motclé async est utilisé lorsque l’on a affaire à une interface série fonctionnant en mode
asynchrone (marginal).
● [no] shutdown
● Déjà décrit.

● Déjà décrit.
● clock rate {débit}
● En situation de TP, il faut simuler le lien WAN sans avoir recours à des boîtiers, modems ou DSU/CSU.
Fort heureusement, CISCO met à disposition des cordons à extrémité ETCD (DCE). Simuler un lien WAN
nécessite de relier les deux interfaces WAN des deux routeurs via deux cordons, l’un à extrémité ETTD,
l’autre à extrémité ETCD puis de configurer l’interface côté ETCD (DCE) de façon à ce qu’elle fournisse
l’horloge, c’est l’objet de la commande clock rate.
● Le débit est exprimé en bps (bits par seconde).
● bandwidth {bande_passante}
● Hélas, seules les interfaces LAN des routeurs CISCO sont automatiquement configurées avec la bande
passante convenable. Les interfaces WAN ne peuvent pas l’être car le débit est en réalité cadencé par
l’horloge fournie par le boîtier ETCD ou CSU/DSU. L’IOS n’établit aucune corrélation entre le débit
physique, cadencé par l’équipement de terminaison de circuit de données et le paramètre bandwidth
de la configuration d’interface. Par défaut, l’IOS considère que l’interface « serial » est connectée à un
canal T1 de débit 1,544 Mbps (Eh oui, CISCO est américain !). Réparer cette lacune nécessite le
recours à la commande bandwidth. Attention, les deux commandes clock rate et bandwidth n’utilisent
pas la même unité, bande_passante est exprimé en Kbps (Kilobits par seconde).
● encapsulation {encapsulation_type}
● La valeur par défaut dépend du type d’interface. L’interface WAN synchrone classique utilise un
protocole propriétaire CISCO extrapolé de HDLC et déjà évoqué, une interface WAN asynchrone
utiliserait par défaut une encapsulation SLIP (Serial Line Internet Protocol), protocole rudimentaire dont
le seul objet est précisément d’encapsuler IP sur des liaisons série.
R11(config)#int s0/0
R11(config-if)#encapsulation ?
atm-dxi ATM-DXI encapsulation
frame-relay Frame Relay networks
hdlc Serial HDLC synchronous
lapb LAPB (X.25 Level 2)
ppp Point-to-Point protocol
smds Switched Megabit Data Service (SMDS)
x25 X.25
R11(config-if)#encapsulation hdlc ?
<cr>
● description {string}
● Déjà décrit.
Application à notre mise en situation, sur R11 :
R11(config-if)#description Lien loue 64K vers Nantes
R11(config-if)#bandwidth 64

R11(config-if)#^Z
R11#
Sur R12 :
R12(config-if)#clockrate 64000
R12(config-if)#bandwidth 64
R12(config-if)#description Lien loue 64K vers Dunkerque
R12(config-if)#^Z
R12#
Nous sommes dans un cas d’école, R12 est le côté DCE du lien WAN ce qui explique la présence de la commande clock
rate 64000, commande absente de la configuration de S0/0 sur R11.
3. Configuration des interfaces de loopback
Les seules commandes utiles sont :
● interface {loopback} {numéro}
● Déjà décrit.
Dans notre mise en situation :
R11(config)#interface loopback ?
<0-2147483647> Loopback interface number
R11(config)#interface loopback 0
R11(config-if)#^Z
R11#
Une commande sh ip int br permet d’observer que l’interface de loopback passe dans l’état « up » sans qu’il y ait eu
besoin d’entrer la commande no shutdown. À l’inverse, une commande shutdown provoquerait son passage à l’état «
administratively down » :
R11#sh ip int br
Serial0/0 10.0.8.11 YES NVRAM up up
FastEthernet0/1 unassigned YES NVRAM administratively down down
Loopback0 1.0.0.11 YES manual up up

Commandes de visualisation d’état
La multiplicité des commandes show impressionne et il est vrai que l’administrateur doit en connaître un nombre
suffisant pour prétendre être autonome dans l’environnement ILC. Bien sûr, chaque chapitre de cet ouvrage propose
un jeu de commandes en rapport avec l’activité du chapitre. On ne saurait trop conseiller au lecteur d’enrichir un « petit
carnet » (un pensebête mais rien n’empêche d’en faire un penseintelligent) qui répertorie les commandes
importantes, au moins pendant la phase de préparation à la certification. En voici un premier aperçu qui ne prétend
absolument pas être exhaustif :
Commande Fréquence Affiche ...

d’utilisation
show runningconfig ***** Le fichier de configuration courante.
show startupconfig **** Le fichier de sauvegarde de la configuration.
show version ** La configuration matérielle du système, la version d’IOS, le

nom et la source de l’image IOS qui a servi à amorcer le
routeur, la valeur du registre de configuration confreg...
show processes * Des informations sur les processus actifs.
show processes cpu ** La consommation de ressources CPU des processus actifs.
show processes memory ** La consommation de ressources mémoire des processus

actifs.
show memory ? * Les nombreuses options possibles de cette commande qui

globalement, fournit des statistiques sur la mémoire du
routeur.
show stacks L’utilisation des piles par les processus.
show buffers * Des statistiques sur les « buffers » (mémoires tampons) du

routeur.
show arp ** Le contenu du cache ARP. La commande clear arp efface

les entrées dynamiques contenues dans la table.
show hosts ** La table de résolution de noms. La commande clear host

efface les entrées dynamiques contenues dans la table.
show flash ** Des informations sur la mémoire Flash, quantités utilisée,

disponible, totale, fichiers présents.
show interface [type numéro] ** Des informations couche 2 et 3 de configuration ainsi que
des statistiques de trafic pour chaque interface configurée
sur le routeur. Les statistiques sont exploitables à la
condition de connaître également la commande clear
counters [type numéro] qui permet de les remettre à
zéro.
show controllers [type *** Des informations couche 1 pour chaque interface
numéro] configurée sur le routeur. Cette commande show affiche
notamment le type d’extrémité connecté à l’interface DTE
ou DCE. Elle intéresse donc l’étudiant en situation d’atelier
quand le marquage des câbles a disparu.
show ip interface [type ***** Des informations IP sur les interfaces.

numéro] [brief]
show ip route ***** La table de routage du routeur. Certainement la

commande la plus utilisée. Il est possible de compléter la
commande en ajoutant des arguments qui vont affiner la

demande. C’est même nécessaire quand la table de
routage comporte beaucoup d’entrées.
show protocols *** Le nom et l’état de tous les protocoles de couche 3

configurés sur le routeur.
show ip protocols *** Des informations sur la configuration des protocoles de

routage sur ce routeur ainsi que les informations de
réseau : sources d’information, distances administratives.
show sessions ** La liste des sessions Telnet en cours.
show users ** La liste des utilisateurs actuellement connectés. En

ajoutant l’argument all, on obtient également de
l’information sur les lignes inactives. L’étoile marque la
ligne qui a été utilisée pour entrer cette commande.
show clock * L’heure et la date. Essayer également show clock detail.
show history ** L’historique des commandes précédemment entrées.

Sauvegarde et restauration des configurations
1. Sauvegarde/Restauration via TFTP
RFC utiles :
● RFC1350 The TFTP Protocol Juillet 1992
Toutes les applications n’ont pas besoin de la totalité des fonctions offertes par FTP. La complexité de FTP est acquise
au prix d’une application au volume conséquent. La pile de protocoles TCP/IP dispose d’un second protocole de
transfert de fichiers appelé TFTP (Trivial File Transfer Protocol, Trivial = simple), très simple, sans contrôle d’accès, sans
possibilité de lister les fichiers distants (il faut connaître le nom du fichier à récupérer). Les capacités de TFTP se
bornent à lire ou écrire des fichiers depuis ou vers un serveur distant. Il est donc moins volumineux que FTP, ce qui
permet par exemple de l’embarquer en mémoire morte d’un système informatique quelconque, avec un programme
d’amorce qui s’en servira pour rapatrier un système d’exploitation depuis un serveur distant.
TFTP s’exécute audessus d’UDP, le serveur TFTP offre son service sur le port UDP 69.
Le premier datagramme UDP transporte la demande de transfert de fichier qui sert aussi de demande de connexion. Si
le serveur autorise la requête, le fichier est envoyé par fragments de taille fixe de 512 octets. L’émetteur envoie un de
ces fragments puis attend un accusé de réception pour ce fragment avant d’envoyer le suivant. Le récepteur acquitte
chaque fragment dès sa réception. Un paquet de données de moins de 512 octets signale la fin du transfert et la fin
du fichier.
L’émetteur d’un paquet « N » (données ou acquittement) arme un temporisateur. Si ce temporisateur expire avant que
le paquet suivant ne lui soit parvenu, alors l’émetteur retransmet ce paquet « N ». Ainsi, l’émetteur ne conserve en
mémoire qu’un seul paquet dans l’attente éventuelle d’une retransmission. Les fragments du fichier sont numérotés
séquentiellement à partir de 1. Chaque paquet de données contient un entête qui indique le numéro du fragment
transporté. Un message d’erreur peut remplacer un paquet de données ou un accusé de réception. Il provoque la
terminaison immédiate du transfert.
Une fois demandée la lecture ou l’écriture du fichier, le serveur utilise l’adresse IP et le port UDP du client pour
identifier les échanges de la session TFTP. Ainsi, les messages de données ou d’acquittements n’ont pas besoin de
préciser le nom du fichier.
TFTP devrait être réservé à un usage sur réseau local. Les équipements réseaux embarquent TFTP afin de permettre
la mise à jour de leurs systèmes d’exploitation.
Commençons par mettre en place un serveur TFTP sur la machine virtuelle VMSRV01. L’Internet fourmille de petits
utilitaires gratuits pouvant remplir cet office. Dans l’ouvrage Cisco Notions de base sur les réseaux dans la collection
Certifications aux Editions ENI, nous avions déjà mis à profit l’excellent Tftpd32 capable autant de réaliser un serveur
DHCP qu’un serveur TFTP ou un serveur SYSLOG. Évitons de nous disperser, il fera parfaitement l’affaire. Pour
mémoire, il est possible de le télécharger depuis le site : http://tftpd32.jounin.net/
La figure cidessous illustre quelques étapes de la préparation d’un serveur TFTP sur la machine VMSRV01. Un
répertoire CONFIGS a été créé dans le répertoire racine du serveur TFTP. Le serveur est à l’adresse 10.0.12.100, à
l’écoute sur le port 69 :

Dans l’interface ILC, la commande à utiliser est la commande copy dont la fonction est de copier tout fichier d’une
source vers une destination. Une demande d’aide permet de se rendre compte de la quantité de sources et
destinations connues de l’IOS :
R11#copy ?
/erase Erase destination file system.
/error Allow to copy error file.
/noverify Don’t verify image signature before reload.
/verify Verify image signature before reload.
archive: Copy from archive: file system
cns: Copy from cns: file system
flash: Copy from flash: file system
ftp: Copy from ftp: file system
http: Copy from http: file system
https: Copy from https: file system
ips-sdf Copy from current IPS signature configuration
null: Copy from null: file system
nvram: Copy from nvram: file system
pram: Copy from pram: file system
rcp: Copy from rcp: file system
running-config Copy from current system configuration
scp: Copy from scp: file system
startup-config Copy from startup configuration
system: Copy from system: file system
tftp: Copy from tftp: file system
xmodem: Copy from xmodem: file system
ymodem: Copy from ymodem: file system
La syntaxe de la commande copy est la suivante :
● Copy [/erase] [/verify | /noverify] sourceurl destinationurl
● /erase : efface le fichier de destination avant d’effectuer la copie.
● /verify : ne s’applique qu’aux fichiers d’images IOS. Vérifie la signature du fichier de destination et
supprime le fichier si la vérification échoue.

● /noverify : ne s’applique qu’aux fichiers d’images IOS, permet de désactiver pour cette copie la
vérification systématique des copies d’images IOS, vérification entreprise parce que l’administrateur a
entré la commande de configuration globale file verify auto.
● Sourceurl et destinationurl : comprend à la fois la localisation du fichier ainsi que son nom. Source et
destination peuvent être locales ou distantes.
Avant toute mise en œ uvre, testons la connectivité avec le serveur TFTP :
R11#ping 10.0.12.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.12.100, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 24/37/56 ms
R11#
En version une seule ligne, la commande suivante permet de copier le fichier de configuration courante vers le fichier
R11confg.txt situé dans le sousrépertoire CONFIGS luimême placé à la racine du serveur TFTP, c’estàdire dans le
répertoire C:\TFTP de la machine VMSRV01 :
R11#copy run tftp://10.0.12.100/configs/R11-confg.txt

Address or name of remote host [10.0.12.100]?
Destination filename [configs/R11-confg.txt]?
.!!
1799 bytes copied in 7.752 secs (232 bytes/sec)
R11#
Le fichier de configuration courante peut indifféremment être désigné par {run | running config |
system:running config}.
La même commande peut fonctionner de manière interactive :
R11#copy run tftp

Address or name of remote host []? 10.0.12.100
Destination filename [r11-confg]? configs/r11-confg.txt
!!
R11#
Chaque point d’exclamation correspond au transfert de dix paquets de 512 octets chacun et indique que le transfert
se déroule normalement. Un point en lieu et place d’un point d’exclamation signifie que le processus de copie a subi un
temporisateur échu (timed out).
Outre l’intérêt de disposer d’une sauvegarde de la configuration du routeur et de pouvoir centraliser les sauvegardes
de toutes les configurations des équipements réseau, la sauvegarde sur serveur TFTP permet l’édition hors interface
ILC. Pour nous en convaincre, modifions légèrement la configuration de R11 en éditant le fichier texte R11confg.txt :

La modification porte sur le nom du routeur R11 changé en R11a. Il reste à « réinjecter » le fichier dans le routeur mais
plutôt que d’en faire directement le fichier runningconfiguration, proposonsnous d’en faire le fichier startup
configuration. Ainsi, la modification ne sera prise en compte que lors du prochain démarrage.
La commande suivante permet de récupérer un fichier de configuration sur un serveur TFTP et d’en faire le fichier de
sauvegarde de la configuration du routeur, c’estàdire le fichier « Startupconfig » :
R11#copy tftp://10.0.12.100/configs/R11-confg.txt start

Accessing tftp://10.0.12.100/configs/R11-confg.txt...
Loading configs/R11-confg.txt from 10.0.12.100 (via Serial0/0): !
[OK - 1919 bytes]
[OK]
R11a#
*Mar 1 00:01:53.770: %SYS-5-CONFIG_NV_I: Nonvolatile storage configured from
tftp://10.0.12.100/configs/R11-confg.txt by console (59140 DUNKERQUE)
R11a#
Le fichier de sauvegarde de la configuration peut indifféremment être désigné par {start | startup config |
nvram:startup config}.
Vérifions que la modification est bien prise en compte en redémarrant R11. Attention, sous GNS3 à bien sauvegarder la
topologie avant d’arrêter R11 (ce qui provoque la sauvegarde sur disque de la NVRAM simulée).
Le redémarrage peut être provoqué à l’aide d’une commande reload en mode privilégié. La syntaxe de cette
commande est la suivante :
● reload [/verify | /noverify] [line | in [hhh:mm |mmm [text ]] | at hh:mm [text] | cancel]
● /verify : vérifie la signature du fichier IOS qui sera chargé suite au redémarrage.
● /noverify : désactive pour ce redémarrage la vérification systématique de l’image IOS, vérification

entreprise parce que l’administrateur a entré la commande de configuration globale file verify auto.
● line : fournit, dans une chaîne limitée à 255 caractères, un motif qui a entraîné la nécessité de

redémarrer.
● In : le routeur redémarrera dans hhh :mm ou dans mmm minutes. On peut ainsi différer le
redémarrage jusqu’à 24 jours !
● at : le routeur redémarrera à l’heure programmée ce jour (si l’heure programmée est postérieure à
l’heure courante), le jour prochain (si l’heure programmée est antérieure à l’heure courante). Il est
également possible de spécifier une date. 00:00 provoque le redémarrage à minuit.
● cancel : annule un redémarrage programmé.
Si cette commande est tout à fait digne d’intérêt, il faut bien avouer qu’elle est assez mal acceptée par la plateforme
émulée à l’aide de GNS3. On s’en tiendra donc au clic droit sur le routeur qu’il faut redémarrer suivi du choix Arrêter
puis du choix Démarrer.
**********************************************************************
**** Avertissement ! Acces aux seules personnes autorisees ! ****
**** Vos activites au cours de cette session sont susceptibles ****
**** d’etre enregistrees. Toute activite illicite fera l’objet ****
**** d’un recours en justice ! ****
**********************************************************************
Password:
Bienvenue, vous venez de vous connecter au routeur R11a.ccna.fr
depuis la ligne 0 situee 59140 DUNKERQUE.
R11a>
CQFD.
2. Sauvegarde/Restauration par copiercoller
Cette seconde façon de procéder est tout aussi intéressante, particulièrement quand l’édition de la configuration du
routeur est longue et fastidieuse. Il s’agit d’éditer la configuration en dehors de l’interface ILC, un éditeur de texte
quelconque fait l’affaire, puis de l’injecter dans l’interface ILC par copier/coller.
Pour les ateliers de cet ouvrage, l’auteur a proposé d’utiliser l’émulateur de terminal PuTTY bien connu des
professionnels. L’avantage de cet outil est qu’il permet autant l’émulation d’un terminal que l’établissement d’une
connexion Telnet ou SSH via le réseau. Dans ce chapitre, le choix a été fait d’utiliser PuTTY associé à l’éditeur de texte
Notepad présent dans toutes les versions de Windows. Que les utilisateurs d’HyperTerminal se rassurent, la
manipulation est également possible avec leur logiciel préféré.

Suivez les numéros des pastilles sur les illustrations :
1. Une session console via le port console ou via Telnet est ouverte sur le routeur R11a. Si elle a été ouverte à
l’instant, la mémoire que PUTTY dédie à l’activité de la console (toutes les lignes affichées sur l’écran y sont
enregistrées) est vide. Si ce n’était pas le cas, il est possible de vider cette mémoire en effectuant un clic droit sur la
barre de titre puis en sélectionnant Clear Scrollback. L’administrateur a placé l’interface dans le mode privilégié et
provoque une commande show run. Puis, l’administrateur frappe la barre d’espace à chaque fois qu’il obtient le
message More, ce afin d’obtenir l’affichage complet de la configuration. Puisque la totalité de la configuration a été
affichée à l’écran, elle se trouve également dans la mémoire de PUTTY.
2. Pour transférer le contenu de cette mémoire dans le pressepapiers, l’administrateur effectue un clic droit dans la
barre de titre...
3. ...et dans le menu contextuel qui s’affiche, sélectionne Copy All to Clipboard.
4. L’administrateur a ouvert une instance de Notepad et s’empresse d’y coller le précieux contenu.
5. Il faut encore débarrasser le contenu des affichages pour ne conserver que les commandes qui constituent
réellement la configuration. Par exemple, en début de capture, effacez les lignes suivantes :
R11a#sh run
Current configuration : 1226 bytes
De la même façon, en fin de capture, effacez la ligne suivante :
R11#
Dans cette situation, le lecteur est en possession du fichier de configuration de ce routeur, qu’il est prudent de
sauvegarder (R11.txt par exemple) et qu’il est possible de modifier à loisir avant de le réinjecter dans le routeur :

6. L’administrateur s’impose d’utiliser les fichiers texte de configuration en partant systématiquement du mode
privilégié. Il ajoute par conséquent la commande conf t nécessaire pour passer en mode de configuration.
7. Observez enfin la commande end, équivalente à la combinaison [Ctrl] Z, et qui permet de revenir au mode privilégié
après l’injection de la configuration modifiée. Non illustré : la commande no shutdown n’apparaissant pas de façon
explicite lorsqu’une interface a été activée, il peut être utile de l’ajouter sur les interfaces concernées (f0/0 et S0/0
dans le cas présent). Ainsi, le fichier obtenu injecté dans un routeur sorti du carton permettrait de reproduire un clone
de R11.
8. L’administrateur sélectionne l’ensemble du contenu du fichier R11.txt...
9. ...et le place dans le Pressepapiers.
10. De retour dans la session console ouverte sur le routeur R11a, le mode en cours est le mode privilégié. Un simple
clic droit provoque le collage du contenu du Pressepapiers.
11. R11a est redevenu R11.
S’il faut comparer les deux méthodes d’édition hors interface ILC, remarquons tout d’abord qu’avec le transfert TFTP, la
source ou la cible de la configuration sont indifféremment le fichier run ou le fichier start. La méthode copier/coller
présente un peu moins de souplesse. Certes quand on capture la configuration dans le Pressepapiers, puisqu’elle est
issue d’une commande show, ce peut être une commande show run ou une commande show start. Mais dans l’autre
sens, quand on injecte la configuration, ce ne peut être que dans le fichier de configuration courante. Il reste à ne pas
oublier de conclure avec une commande de copie copy run start.
3. Commenter les fichiers de configuration
Avouez qu’à cet instant, on est plutôt satisfait à l’idée du temps qu’il est possible de gagner en travaillant hors de
l’interface ILC. Le second avantage tient à la possibilité de gérer de façon rationnelle, centralisée et sécurisée les
fichiers de configuration des équipements. Encore une pierre dans l’édification d’une politique de sécurité.
Un avantage non documenté consiste à commenter les fichiers de configuration. Le lecteur aura remarqué la présence
des points d’exclamation dans ces fichiers et le fait qu’ils font office de caractères de séparation. Le fichier de
configuration reste un fichier texte mais les différentes rubriques qui le composent sont « aérées » par les points
d’exclamation. On peut les supprimer ou en ajouter, c’est sans influence sur l’interprétation que fait l’IOS des lignes de
commande.
Chose irréalisable depuis l’interface ILC, on peut donc également ajouter du texte après l’un de ces points
d’exclamation, il ne sera pas interprété par l’IOS :

Supposons que l’on ait transféré le fichier cidessus vers le fichier de configuration start. Pendant l’opération de boot
du routeur, le fichier run a été obtenu par clonage du fichier start, à ceci près que le commentaire, inconnu de l’IOS a
été ignoré. En final, il est possible de visualiser le commentaire à l’aide d’une commande show start. Mais ce
commentaire reste absent du résultat d’une commande show run. Et une seule commande copy run start a raison du
commentaire. Il faut donc surtout le considérer comme un commentaire hors interface ILC.
4. TP : Création, sauvegarde et restauration d’un fichier de configuration
a. Activité guidée
En premier lieu, le lecteur est invité à reproduire la topologie proposée en début de chapitre puis à y reproduire
l’ensemble des activités de ce chapitre.
b. Activité non guidée
■ À l’aide de l’une des deux méthodes proposées, TFTP ou copier/coller, extrayez la configuration du routeur R11
dans un fichier R11.txt.
■ Modifiez ce fichier afin qu’il devienne la configuration de R12 et sauvegardez dans R12.txt.
■ Injectez R12.txt dans le routeur R12 par TFTP ou copier/coller.
■ Vérifiez la connectivité de PCL11 avec PCL12.
À tout hasard, les deux fichiers R11.txt et R12.txt ont été placés dans l’archive Atelier2a.zip disponible en
téléchargement. Ces fichiers sont prévus pour être injectés dans les routeurs par la méthode copier/coller. Pour
qu’ils puissent également être chargés par TFTP en tant que fichiers de configuration, il convient au préalable d’ôter
la première ligne « conf t » dans chacun des deux fichiers.
Cet atelier est à présent terminé.

L’IOS
1. Introduction
Comme tout ordinateur, un routeur ou un commutateur ne peuvent fonctionner sans système d’exploitation. Dans le
cas des équipements CISCO, le constructeur le désigne par IOS (Internetworking Operating System) et il est embarqué
sur la plupart de ses matériels, routeurs, commutateurs, points d’accès sans fil, indépendamment de leur taille ou de
leur type.
L’IOS est stocké dans la partition mémoire Flash qui est au routeur ce que le disque dur est au PC (quoique l’arrivée
des disques SSD « SolidState Drive » pourrait rapidement davantage renforcer les similitudes entre les équipements).
Avant son chargement en mémoire vive, l’ensemble CISCO IOS est fourni sous la forme d’un seul fichier de plusieurs
Mégaoctets. Curieusement, on désigne par image ce fichier, l’image contient l’IOS entier pour un équipement donné.
L’IOS est chargé en mémoire vive pendant le démarrage.
Comme tout système d’exploitation, l’IOS doit gérer les ressources matérielles et logicielles du routeur, cela comprend
l’allocation de mémoire, la gestion multitâches des différents processus, la gestion du système de fichiers. L’acronyme
IOS est devenu générique mais recouvre pourtant des réalités très différentes, ce pour au moins trois raisons :
● De nombreuses platesformes l’utilisent.
● La conception de l’IOS est modulaire, une image intègre des fonctionnalités plus ou moins nombreuses, ceci a
une incidence directe sur la taille de la mémoire Flash qui doit accueillir l’image ainsi que sur la quantité de
mémoire vive que le routeur doit embarquer pour espérer la faire tourner.
● CISCO propose régulièrement de nouvelles versions, il peut s’agir de corrections de bogues ou de l’ajout de
nouvelles fonctionnalités.
De fait, il existe de nombreuses images IOS et il est peu probable qu’un routeur termine son existence avec l’IOS qui
l’équipait à la sortie du carton. Les motivations à substituer un IOS à un autre sont diverses, ce peut être le souhait
de disposer de la version la plus récente ou de disposer de la même version sur l’ensemble des routeurs d’un réseau.
L’un des savoirfaire de l’administrateur consiste à charger une nouvelle image sur le routeur. Nous envisagerons trois
méthodes, deux qui supposent une interface réseau accessible, la troisième qui se cantonne à l’utilisation du port
console.
2. Les images IOS
CISCO distingue deux types d’images :

1. L’image boot contient un sousensemble de l’IOS complet, suffisant cependant pour charger un IOS complet depuis
le réseau ou pour charger une image IOS sur le routeur. Le routeur met également à profit l’image boot quand il n’est
pas parvenu à trouver une image système valide. L’image boot est désignée, selon les systèmes, image « rxboot »,
image « bootstrap » ou image « boot loader ».
Sur certaines platesformes, l’image boot est contenue en ROM, dans d’autres, elle peut être contenue en mémoire
Flash et dans ce cas, une commande boot bootldr en mode de configuration globale permet de spécifier quelle image
boot le routeur doit utiliser.
2. L’image système contient l’IOS complet. Cette image est chargée pendant le boot. Le plus ordinairement, le routeur
est sous le contrôle d’un IOS issu d’une image système.
Sur la plupart des platesformes, l’image est conservée dans la partition Flash. Certaines platesformes disposent de
plusieurs partitions Flash (flash, boot flash, slot 0, slot 1...) et dans ce cas, l’image peut être stockée sur chacune
d’elles. Une commande show file systems fournit la liste des partitions supportées par le routeur, un type « opaque »
fait référence à une pseudopartition :
Router#show file systems

File Systems:
Size(b) Free(b) Type Flags Prefixes

- - opaque rw archive:
- - opaque rw system:
29688 29636 nvramrwnvram:
- - opaque rw null:
- - network rwtftp:
- - opaque roxmodem:

- - opaque roymodem:
* 16777212 16777212 flash rw flash:
- - opaque wo syslog:
- - network rwrcp:
- - network rw pram:
- - network rw ftp:
- - network rw http:
- - network rwscp:
- - network rw https:
- - opaque rocns:
Router#
3. Nommage des images IOS<12.3
La convention de nommage des fonctionnalités décrite ici était celle qui prévalait avant la version 12.3 de l’IOS. Le nom
attribué au fichier image système respecte le format suivant :
● « Platformfeaturesettype », exemple : c2600ik9smz.12240a.bin
● « Platform » : identifie la plateforme matérielle pour laquelle l’image a été conçue. C2600 dans
l’exemple cidessus identifie la plateforme Cisco 2600.
● « featureset » : la conception de l’IOS est modulaire, l’image IOS résulte de l’assemblage de différentes
briques logicielles selon les fonctionnalités qu’elle doit intégrer. Ainsi, dans l’exemple cidessus, « I »
identifie la brique « IP », « K9 » identifie IPSec ainsi que des fonctionnalités de cryptographie telle
3DES (Triple DES (Data Encryption Standard)), S identifie des fonctionnalités en rapport avec SRB
(Source Route Bridging, technologie de routage introduite par IBM).
● « type » : renseigne sur une ou plusieurs caractéristiques de l’image :
● « f » : l’image s’exécute directement en mémoire Flash.
● « m » : l’image s’exécute en RAM.
● « r » : l’image s’exécute depuis la ROM.
● « l » : l’image est relogeable. Reloger un exécutable consiste à modifier, sitôt après son
chargement et avant son exécution, les adresses qu’il référence pour qu’elles correspondent
aux adresses physiques des éléments, code exécutable ou données, au moment de
l’exécution. En informatique, reloger est donc synonyme de translater.
● « z » : l’image est compressée selon le format zip.
● « x » : l’image est compressée selon le format mzip.
● « w » : l’image est compressée selon le format stac.
Le tableau cidessous reproduit une partie des symboles les plus fréquemment rencontrés :
Symbole Interprétation
B AppleTalk
G Réseau numérique à intégration de services (RNIS (Réseau

Numérique à Intégration de Services) ou ISDN (Integrated Services
Digital Network))
I Caractéristiques IP, comprend SNMP (Simple Network Management

Protocol), IP, Bridging, WAN, RemoteNode, Terminal Services...

I2 IP pour la plateforme 3600
I3 IP réduit sans BGP/EGP/NHRP (Next Hop Resolution Protocol)
J Caractéristiques « Enterprise » (ajoute tous les protocoles de

routage)
K Cryptographie, comprend IPSec, SSH (Secure Shell)
K8 Cryptographie faible, DES 56 bits
K9 Cryptographie forte, Triple DES, AES (Advanced Encryption Standard)
N Novell IPX (Internetwork Packet Exchange)
O Firewall
O2 Firewall (3xx0)
O3 Firewall avec SSH (36x0, 26x0)
S Caractéristiques Plus, comprend NAT, VPN…
S6 Plus sans ATM (Asynchronous Transfer Mode)
S7 Plus sans la voix
Y IP sur les routeurs de la série 1700
X H323 GateKeeper/Proxy pour 2500 3620, 3640, MC3810
Quelques exemples d’assemblages possibles :
■ Tapez dans un moteur de recherche « Cisco IOS 12.3 Feature Sets for Cisco 2600XM ».
Vous pouvez bien sûr remplacer Cisco 2600XM par la plateforme qui vous concerne.
■ Si le lien existe encore au moment où vous lisez ces lignes, cliquez sur le lien vers le document...
Au moment où ces lignes sont écrites, CISCO propose les packages suivants pour cette plateforme :
Feature Set Image Filename
Packages classiques
ENTERPRISE/FW/IDS PLUS IPSEC 3DES c2600jk9o3smz
ENTERPRISE PLUS IPSEC 3DES c2600jk9smz
ENTERPRISE PLUS c2600jsmz

IP/FW/IDS PLUS IPSEC 3DES c2600ik9o3smz
IP/FW/IDS PLUS IPSEC 56 c2600ik8o3smz
IP PLUS IPSEC 3DES c2600ik9smz
IP PLUS c2600ismz
IP/IPX/APPLETALK/FW/IDS PLUS c2600bino3smz
IP/IPX/APPLETALK PLUS c2600binsmz
IP/IPX/APPLETALK c2600binmz
IP/FW/IDS c2600io3mz
IP c2600imz
Packages spéciaux
ENTERPRISE/SNASW PLUS IPSEC 3DES c2600a3jk9smz
ENTERPRISE/SNASW PLUS c2600a3jsmz
ENTERPRISE PLUS/H323 MCM c2600jsxmz
ENTERPRISE/SSG c2600g4jsmz
ENTERPRISE PLUS IPIP GATEWAY IPSEC 3DES c2600jk9s2mz
ENTERPRISE PLUS IPIP GATEWAY c2600js2mz
SS7 SIGNALING LINK TERMINATION c2600ipss7mz
IP/H323 C2600ixmz
TELCO FEATURE SET C2600telcomz
Détaillons quelquesuns de ces packages :
● C2600ik9o3smz
● i → IP
● k9 → Cryptographie forte (3DES, AES)
● o3 → IOS Parefeu, détection d’intrusion
● s → Fonctionnalités Plus
● C2600binmz
● b → AppleTalk (protocole de communication d’Apple)
● i → IP
● n → IPX (protocole de couche 3 de Novell)

● C2600ik9smz
● Idem C2600ik9o3smz sans les fonctionnalités de parefeu.
La commande show version permet à l’administrateur de vérifier entre autres la version d’IOS en cours d’utilisation
sur le routeur. Profitons du contexte pour détailler le résultat de cette commande, présenté de la façon suivante :
Cisco IOS Software, <platform> Software (<image-id>), Version <software-version>,

<software-type>
Technical Support: http://www.cisco.com/techsupport
Copyright (c) <date-range> by Cisco Systems, Inc.
Compiled <day><date><time> by <compiler-id>
ROM: System Bootstrap, Version <software-version>, <software-type>

BOOTLDR: <platform> Software (image-id), Version <software-version>, <software-
type>
<router-name> uptime is <w> weeks, <d> days, <h> hours, <m> minutes
System returned to ROM by reload at <time><day><date>
System image file is "<filesystem-location>/<software-image-name>"
Last reload reason: <reload-reason>
Cisco <platform-processor-type> processor (revision <processor-revision-id>) with

<free-DRAM-memory>K/<packet-memory>K bytes of memory.
Processor board ID <ID-number>
<CPU-type> CPU at <clock-speed>Mhz, Implementation <number>, Rev <Revision-number>,
<kilobytes-Processor-Cache-Memory>KB <cache-Level> Cache
Les informations fournies sont de trois ordres :

1. Des informations logicielles :
● version de l’IOS ;
● capacités de l’IOS (feature set) ;
● emplacement et nom du fichier de boot en ROM.
2. Des informations spécifiques à l’équipement :
● Nom attribué.
● Temps écoulé depuis la mise sous tension (System uptime, c’est aussi le trap SNMP uptime).
● Motif qui a provoqué le dernier redémarrage (System reloadreason). Exemples : la commande reload, la mise
sous tension (power on)...
● Valeur courante du registre de configuration.
● Si différente, la valeur qu’adoptera le registre de configuration au prochain redémarrage.
3. Des informations sur quelques aspects physiques de la plateforme :
● type de plateforme ;
● type de CPU ;
● version hardware du CPU ;
● quantité de mémoire principale installée ;

● quantité de mémoire attribuée aux entrées/sorties ;
● quantité de mémoire Flash installée ;
● identifiant de carte mère.
Exemple de ce que pourrait être le résultat d’une commande show version :
R11#show version
Cisco IOS Software, 2801 Software (C2801-IPBASE-M), Version 12.4(16a), RELEASE
SOFTWARE (fc2)
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Mon 10-Sep-07 10:27 by prod_rel_team
ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)
R11 uptime is 0 minutes

System returned to ROM by reload at 10:36:51 UTC Tue Mar 9 2010
System image file is "flash:c2801-ipbase-mz.124-16a.bin"
Cisco 2801 (revision 7.0) with 114688K/16384K bytes of memory.

Processor board ID FCZ113990F6
2 FastEthernet interfaces
2 Low-speed serial(sync/async) interfaces
DRAM configuration is 64 bits wide with parity disabled.
191K bytes of NVRAM.
62720K bytes of ATA CompactFlash (Read/Write)
Configuration register is 0x2102
R11#
Observez notamment les parties en gras de la capture. Les deux nombres donnés au sujet de la quantité de mémoire
vive méritent quelques explications. La première valeur représente selon les cas la seule partie de mémoire vive
disponible pour le processeur ou la totalité de la mémoire vive installée sur le système. La seconde valeur représente
la quantité de mémoire dédiée aux paquets. Cette mémoire est organisée de façon à optimiser le traitement des
paquets, concrètement en y créant des tampons de paquets.
Les platesformes les plus puissantes de la gamme CISCO (Cisco 4000, 4500, 4700 et 7500) bénéficient de mémoire
dédiée à cet usage, CISCO la désigne par « I/O memory » ou « Fastmemory ». Le premier nombre fourni indique dans
ce cas la quantité totale de mémoire vive à disposition du processeur.
Les platesformes Cisco 2500, 2600, 2800, 3600 et 7200 quant à elles partagent la mémoire vive installée, afin d’en
mettre une partie à disposition, pour constituer les tampons de paquets associés aux interfaces. La conséquence est
qu’il est nécessaire d’additionner les deux nombres fournis pour exprimer la quantité totale de mémoire vive
embarquée par le routeur. Dans la capture cidessus, effectuée sur une plateforme 2800, la somme des deux
nombres donne 131072 K / 1024 = 128 Mo.
4. Évolution du packaging des images IOS
Avec l’arrivée de la version 12.3 de l’IOS, CISCO décide de refonder l’offre logicielle en la simplifiant, le nombre de
packages possibles passant selon Cisco de quarantequatre à huit ! Quatre de ces packages répondent à quatre
besoins repérés typiques : données IP, convergence voixdonnées, Sécurité et VPN et protocoles d’entreprise. Trois
packages supplémentaires offrent de nouvelles combinaisons de fonctionnalités à même de satisfaire des besoins sur
des réseaux d’une certaine complexité. Enfin, il est possible d’acquérir une version premium, appelée « Advanced
Enterprise Services » et qui regroupe l’ensemble des fonctionnalités offertes de façon séparée par les autres packages.
Une des caractéristiques de la nouvelle offre est de fonctionner selon un système d’héritage : une fonctionnalité
introduite sur un niveau bas ou intermédiaire de l’offre n’est pas ôtée sur un niveau supérieur, ce qui facile la
migration vers des packages de niveau plus élevé, l’administrateur ayant la certitude de ne pas perdre des
fonctionnalités parmi celles dont il disposait déjà. La figure suivante, issue de CISCO, illustre la nouvelle hiérarchie de
l’offre logicielle CISCO :

● Package « IP Base »
Ensemble de services requis pour opérer dans un environnement de données, comprend la connectivité DSL,
les modules de commutation Ethernet, le routage 802.1q, le « trunking » sur les interfaces Ethernet. Toutes
ces fonctionnalités sont héritées et donc présentes également dans les sept autres packages. L’image « IP
Base » est l’image par défaut sur la plupart des routeurs CISCO.
● Package « IP Voice »
Ce package ajoute des fonctionnalités typées voix aux fonctionnalités de « IP Base ». Outre la voix sur IP, le
support de la voix sur Frame Relay est également prévu. Toutes les interfaces voix existantes et leur protocole
de signalisation sont supportés (exemples : H323, MGCP : Media Gateway Control Protocol). Enfin, « IP Voice »
intègre des services dédiés à la téléphonie tels « Call manager Express » ou SRST (Survival Remote Site
Telephony).
● Package « Advanced Security »
Ce package ajoute des fonctionnalités de sécurité aux fonctionnalités de « IP Base », telles les VPN, des
fonctionnalités de parefeu, de détection d’intrusion, le support de SSH version 1, le support de « Cisco Easy
VPN Client and Server ». Ce package intègre pour ce faire les capacités de cryptographie AES et 3DES.
● Package « SP Services »
Ce package ajoute aux fonctionnalités de « IP Voice » le support de la voix sur ATM, le support de MPLS
(Multiprotocol Label Switching) et SSH version 1.
● Package « Enterprise Base »
Ce package ajoute aux fonctionnalités de « IP Voice » le support de nombreux protocoles tiers, tels Appletalk,
IPX de Novell, des protocoles ou des technologies issus d’IBM tels SDLC, SNA (Systems Network Architecture)
ou Token Ring.
● Package « Enterprise Services »
Ce package regroupe le support d’IPX, d’Appletalk, de DECnet et les services IBM avec les services voix et/ou
les services ATM. Il combine donc les fonctionnalités des deux packages « SP services » et « Enterprise Base ».

Il convient aux clients qui souhaitent intégrer les services voix et les services IBM.
● Package « Advanced IP Services »
Ce package regroupe des fonctionnalités de voix et données avec des capacités de sécurité et VPN. Il ajoute
donc aux fonctionnalités de « SP services » le support de VPN, la détection d’intrusion, IPv6, le parefeu,
toutes fonctionnalités issues du package « Advanced Security ».
● Package « Advanced Enterprise Services »
Ce package offre le support multiprotocoles (par exemple Appletalk, Novell IPX et DECnet) avec les services
voix et sécurité. C’est évidemment la solution la plus riche.
Le tableau suivant montre cette offre IOS réduite à huit pour la même plateforme 2600XM déjà utilisée en exemple
dans le paragraphe précédent :
Feature Set Image Filename Flash RAM

nécessaire nécessaire
Packages multiplatesformes
IP BASE c2600ipbasemz 16 Mo 64 Mo
IP VOICE c2600ipvoicemz 32 Mo 96 Mo
ADVANCED SECURITY c2600advsecurityk9mz 16 Mo 64 Mo
ENTERPRISE BASE c2600entbasemz 16 Mo 64 Mo
SP SERVICES c2600spservicesk9mz 32 Mo 96 Mo
ENTERPRISE SERVICES c2600entservicesk9mz 32 Mo 96 Mo
ADVANCED IP SERVICES c2600advipservicesk9mz 32 Mo 96 Mo
ADVANCED ENTERPRISE SERVICES c2600adventerprisek9mz 32 Mo 96 Mo
Toujours pour cette même plateforme 2600XM, CISCO suggère des migrations pour certaines de ses images IOS
retirées de la vente :
« EndofSales Feature Set » Migration suggérée
ENTERPRISE/SNASW PLUS IPSEC 56 ENTERPRISE/SNASW PLUS IPSEC 3DES
c2600a3jk8smz c2600a3jk9smz
IP PLUS IPSEC 56 IP PLUS IPSEC 3DES
c2600ik8smz c2600ik9smz
ADVANCED SECURITY
c2600advsecurityk9mz
ADVANCED IP SERVICES
c2600advipservicesk9mz
ENTERPRISE/FW/IDS PLUS IPSEC 56 ENTERPRISE/FW/IDS PLUS IPSEC 3DES
c2600jk8o3smz c2600jk9o3smz
ADVANCED ENTERPRISE SERVICES
c2600adventerprisek9mz

ENTERPRISE PLUS IPSEC 56 ENTERPRISE PLUS IPSEC 3DES
c2600jk8smz c2600jk9smz
ADVANCED ENTERPRISE SERVICES
c2600adventerprisek9mz
5. Le cassetête des numéros de version
Encore un sujet dont il va falloir renoncer à faire le tour. Un estimé confrère l’a fait et le résultat est un ouvrage de 308
pages ! Nous nous en tiendrons à l’indispensable. Les différentes versions de l’IOS sont classifiées en « trains »,
chaque train contient un ensemble différent de fonctionnalités, chaque train suit sa voie. Parmi tous les trains
maintenus par CISCO, l’administrateur doit absolument connaître l’existence des deux trains « Main Line » et
« Technology » :
Le train « Main Line » (littéralement grande ligne) offre les versions les plus stables et n’évolue jamais en termes de
fonctionnalités contenues (la stabilité est à ce prix), ce pendant toute sa vie. Les mises à jour régulières n’ont donc
pas pour objet de proposer de nouvelles fonctionnalités ou le support de nouveaux matériels mais bien d’apporter des
corrections à des problèmes identifiés.
Exemples :
● La version 12.4(1) est le premier exemplaire de l’IOS proposé dans le train « Main Line » 12.4.
● La version 12.4(16) constitue une mise à jour générale qui intègre tous les correctifs apportés depuis la
version 12.4(1). Ce n’est pourtant pas la 16 e version, car les numéros de version à l’intérieur d’un train sont
certes croissants, mais ne se suivent pas nécessairement. Ainsi, dans le train « Main Line », la version qui
précédait 12.4(16) était 12.4(13f). Les numéros de version (14) et (15) ne peuvent appartenir au train « Main
Line » car ils ont été attribués au train « Technology ».
● La version 12.4(16a) est une version transitoire, destinée à raccourcir le temps de réaction de CISCO visàvis
d’un problème identifié. Une autre version transitoire 12.4(16b) a suivi la version 12.4(16a) avant d’arriver à la
mise à jour générale 12.4(17).
Le train « Technology » est identifié par la lettre T (P avant la version 12). Les versions de l’IOS proposées dans ce
train peuvent à la fois comporter des corrections à des problèmes identifiés mais également comporter de nouvelles
fonctionnalités logicielles ou le support de nouveaux matériels. Ces apports ne peuvent se faire qu’au détriment de la
stabilité du système. C’est pourquoi CISCO recommande d’éviter l’utilisation du train T en environnement de
production sauf absolue nécessité (par exemple, dans le cas où l’une des nouvelles fonctionnalités se révélerait
indispensable).
Exemples :
● La version 12.4(2)T est le premier exemplaire de l’IOS proposé dans le train « Technology » 12.4.
● La version 12.4(20)T constitue une mise à jour générale.
● La version 12.4(20)T2 est une version transitoire.
La figure suivante illustre le cheminement parallèle des trains de versions :

Observez sur la figure cidessus la succession des versions du train « Main Line » pour parvenir à la version 12.4(25c),
version la plus récente de ce train au moment où ces lignes sont écrites. De la même façon, observez que la version la
plus récente du train « Technology » est la version 12.4(24)T2. Dans les deux cas, observez que les versions se
succèdent mais restent systématiquement affublées d’un suffixe placé entre parenthèses (ED) ou (MD) dont l’objet est
de qualifier la version. Les suffixes possibles sont les suivants :
● (DF) : « Deferral Releases », ce marquage annonce le retrait prochain de l’image concernée (l’image ne fera plus
partie de l’offre CISCO). L’éditeur recommande vivement à ses clients de migrer vers une image de
remplacement.
● (ED) : « Early Deployment Releases », l’objet d’une version ED est de traduire sans délai les efforts des équipes
de développeurs sur le marché. Les versions ED connaissent des souscatégories :
● (CTED) : « Consolidated Technology Early Deployment releases », également appelées versions T.
● (STED) : « Specific Technology Early Deployment releases ».
● (SMED) : « Specific Market Early Deployment releases ».
● (XED) : « ShortLived Early Deployment releases », également appelées versions X.
● (MD) : « Maintenance Deployment releases », l’objet d’une version MD est de fournir des correctifs logiciels dans
un cadre de maintenance logicielle normale.
● (GD) : « General Deployment releases », l’étape GD est un jalon important dans le cycle de vie de la version
d’IOS. Une version majeure atteint le stade GD quand CISCO estime que la version convient pour un
déploiement dans tous les réseaux de ses clients. CISCO se fonde sur une équation compliquée où
interviennent entre autres le retour des commentaires clients et les résultats des tests opérés avec cette
version.

● (LD) : « Limited Deployment releases », état qui précède l’état GD dans le cycle de vie d’une version.
Quelques relations entre ces types de versions :
● Les corrections à des problèmes logiciels identifiés sont appliquées au train « Main Line ». Régulièrement, ces
corrections sont également appliquées aux versions (CTED) et par suite aux versions (STED) qui ont un lien de
parenté avec les versions CTED.
● Une relation parentenfant lie toute version STED ou SMED soit avec une version du train « Main Line », soit
avec une version CTED. La version STED ou SMED reste active tant que la version parente demeure active et
hérite des mêmes développements.
● Une version X trouve son origine dans une version CTED. Elle offre aux équipes de développeurs le moyen de
fournir très rapidement de nouvelles technologies au marché. Une mise à jour de version X est appelée à être
également appliquée rapidement à sa racine CTED. Quand les fonctionnalités spécifiques qui ont justifié la
création de cette version X se voient finalement intégrées à la version CTED racine, la version X devient
obsolète et passe à l’état EoE (End of Engineering).
● Les technologies éprouvées introduites dans les six premières révisions du train « Technology » sont
conservées afin de fournir la base de ce qui constituera le prochain train « Main Line » (le 12.5 au moment où
ces lignes sont écrites).
6. Cycle de vie
Il est bon de connaître les acronymes associés aux grandes étapes qui jalonnent la vie d’une version :
● FCS : « First Customer Shipment », la version est mise à disposition de la clientèle sur le site Cisco.com.
● EoS : « End of Sale », la version n’est plus vendue mais les versions de maintenance restent disponibles sur le
site de téléchargement. L’annonce du futur état EoS intervient six mois avant sa date effective.
● EoE : « End of Engineering », CISCO ne construit plus de nouvelles images IOS, les équipes de développement
ne produisent plus de correctifs logiciels et n’intègrent plus de nouvelles fonctionnalités. Cependant, un
support reste assuré par le TAC (Technical Assistance Center).
● EoL : « End of Life », CISCO cesse tout support de cette version et recommande la mise à jour vers une
version plus récente.

La séquence de démarrage
1. Organigramme de la séquence de démarrage
Nous l’avons dit, un routeur est avant tout un ordinateur et les similitudes vont jusqu’à leur façon de démarrer. Une
différence cependant tient au fait qu’un ordinateur ne dispose ordinairement que d’un seul système d’exploitation
installé. Un routeur au contraire peut charger un système d’exploitation parmi plusieurs issus de sources différentes,
locales au routeur ou distantes.
L’organigramme ciaprès tente de retracer les étapes de la séquence d’amorçage :
1. Comme tout ordinateur, le routeur effectue le test appelé POST (PowerOn Self Test) et destiné à vérifier le bon

fonctionnement des différents composants matériels du routeur.
2. Le routeur copie en RAM et exécute un programme destiné à contrôler la suite du démarrage (« bootstrap »). S’agitil
d’un programme spécifique (un « picocode ») ou déjà du minisystème d’exploitation ROMMON comme le laissent
penser certaines documentations CISCO ? (par exemple : "Cisco IOS Configuration Fundamentals Guide Release 12.4
Booting Process"), peu importe.
3. Le programme d’amorçage détermine quelle image IOS doit être utilisée, charge cette image en RAM puis lui
transfère le contrôle.
4. C’est désormais l’IOS qui contrôle le routeur et une séquence normale de démarrage se poursuit en chargeant le
fichier de configuration startupconfig qui devient alors runningconfig.
L’administrateur n’a aucun contrôle sur les deux premières étapes, tout au plus peutil interrompre la séquence de
démarrage pour qu’elle s’achève au terme de l’étape 2, ce en générant un « Break » sur le port console pendant les
soixante premières secondes du démarrage (combinaison [Ctrl][Pause]).
Cette séquence de démarrage nécessite d’autres commentaires qui ne pourront être faits qu’une fois expliqué le
registre de configuration...
2. Le registre de configuration
D’anciens routeurs étaient équipés dans le passé de micro commutateurs qui participaient à la configuration de
l’équipement. CISCO a pérennisé les pratiques acquises alors en remplaçant ces micro commutateurs par un registre
de 16 bits appelé registre de configuration. La valeur stockée dans ce registre est maintenue en l’absence
d’alimentation. De plus, la commande qui permet d’écrire dans ce registre n’a pas besoin d’être suivie d’une commande
de sauvegarde. La figure suivante peut rejoindre directement le petit carnet de notes qu’un administrateur devrait
constituer et conserver sur lui :
Pour le CCNA, l’administrateur doit maîtriser...
● L’usage du champ d’amorçage : ce champ occupe les 4 bits de poids faible du registre. La séquence de
démarrage teste ce champ, trois résultats sont possibles :

● Champ d’amorçage = 0 → pas de chargement d’image, invite de commande ROMMON. Résultat
identique à celui obtenu en générant un « Break » sur le port console pendant les soixante premières
secondes du démarrage.
● Champ d’amorçage = 1 → Chargement de l’image Boot ou RxBoot.
● Champ d’amorçage compris entre 2 et F → Comportement déterminé par l’administrateur. S’il a placé
une ou plusieurs commandes boot system dans le fichier de configuration, alors le routeur tente de
charger l’image indiquée par la première commande. Si le chargement réussit, la séquence de
démarrage se poursuit. Dans le cas contraire, le routeur tente de charger l’image indiquée par la
commande boot system suivante. Quand l’administrateur n’a placé aucune commande boot system
dans le fichier de configuration, le routeur charge le premier IOS présent dans la partition Flash.
● L’usage du bit 6 → ce bit placé à 1 modifie le comportement du routeur à la fin de la séquence d’amorçage, qui
ignore dans ce cas le contenu de la NVRAM et donc le fichier de sauvegarde de la configuration startupconfig.
Cette faculté sera mise à profit dans la procédure de recouvrement de mots de passe décrite dans ce chapitre.
Pour luimême, l’administrateur devrait maîtriser l’usage des trois bits 5, 11 et 12 qui permettent de régler le débit
numérique du port console, c’est utile quand par exemple on souhaite détourner le port console de son usage premier
pour transférer une image IOS en Flash, la procédure est également décrite dans ce chapitre.
3. La commande "boot system"
La commande boot system admet plusieurs déclinaisons selon la localisation de l’image à charger. Les syntaxes
suivantes nous seront utiles :
● boot systemflash [flashfs:] [partitionnumber:] [filename]
● Utile quand il faut charger une image depuis une partition Flash.
● flashfs: → optionnel, désigne la partition Flash qui contient l’image à charger. Les valeurs possibles
sont :
● flash: → il s’agit de la mémoire flash interne sur les platesformes 1600 et 3600, c’est aussi la
partition par défaut sur ces mêmes platesformes.
● bootflash: → mémoire Flash interne des platesformes 7000.
● slot0: → premier emplacement PCMCIA sur les platesformes 3600 et 7000, partition par défaut
des platesformes 7000.
● slot1: → second emplacement PCMCIA des platesformes 3600 et 7000.
● partitionnumber: → optionnel, numéro attribué à la partition qui contient l’image système à charger.
Cet argument ne concerne que les systèmes dont les partitions créées par construction acceptent
d’être partitionnées par l’administrateur.
● filename → optionnel avec la commande boot system flash, nom du fichier image à charger au
démarrage. Cet argument est sensible à la casse. Quand il n’est pas spécifié, le routeur charge le
premier fichier valide à l’emplacement désigné par flashfs: partitionnumber:, dans la partition flash par
défaut quand l’emplacement est omis. La notion de premier fichier valide renvoie au fait que chaque
fichier écrit dans une partition flash est affublé d’un numéro, chaque nouvelle écriture incrémente ce
numéro. Le premier fichier est celui portant le plus petit numéro.
● boot system {rcp | tftp | ftp} filename [ipaddress]
● dont les arguments non encore explicités sont :

● {rcp | tftp | ftp} → outre la faculté de charger depuis un serveur TFTP, le routeur peut
également charger depuis un serveur FTP ou une machine UNIX (remote copy).
● [ipaddress] → optionnel, adresse IP du serveur qui contient l’image système à charger. Quand
elle est omise, le routeur lui substitue l’adresse de diffusion 255.255.255.255.
● boot system {fileurl | filename}
● fileurl → l’URL de l’image système à charger.
● Exemple : boot system tftp://10.0.12.100/IOS/c2801ipbasek9mz.12425c.bin
● Dans ce chapitre, cette troisième forme a été préférée à la forme boot system tftp car elle permet de
spécifier un répertoire sur le serveur TFTP.
4. Séquence de démarrage, suite et fin
Rien n’interdit d’utiliser plusieurs commandes boot system dans le fichier de configuration. Le routeur tente la
première commande boot system puis la seconde et ainsi de suite jusqu’à ce qu’une tentative aboutisse. Les
éventuelles commandes boot system suivantes sont alors ignorées.
Quand le routeur n’est pas parvenu à charger une image à l’aide des commandes boot system et que toutes
concernaient des tentatives vers le réseau, alors le routeur tente de charger une image depuis la partition Flash.
Quand le routeur a cherché sans succès une image valide dans la partition Flash, il poursuit sa quête sur le réseau en
diffusant des requêtes à la recherche d’un serveur TFTP qui disposerait d’une image IOS. Autant dire qu’il s’agit d’un
scénario improbable et au résultat assez aléatoire.
Tous les systèmes ne disposent pas nécessairement d’une image boot (Rxboot) en ROM ou en Flash. La conclusion
d’une séquence de démarrage se simplifie dans ce cas puisque le nombre de systèmes d’exploitation possible passe
de trois (ROMMON, Rxboot, IOS) à deux (ROMMON, IOS). Si le routeur n’a pas chargé d’IOS pour l’un des motifs
suivants :
● L’administrateur a interrompu la séquence de démarrage à l’aide d’un Break.
● L’administrateur avait placé 0x0 dans le champ d’amorçage du registre de configuration.
● Le routeur n’est pas parvenu à trouver une image IOS valide.
... alors le routeur reste sous le contrôle de ROMMON, un terminal connecté au port console affiche l’invite de
commande ROMMON n >.
Toujours dans le cas d’un système ne disposant pas d’image boot, le test du champ d’amorçage réalisé
immédiatement après le chargement de ROMMON est légèrement modifié :
Champ Commandes boot Effet

d’amorçage system
0x0 Ignorée ROMMON
0x1 Ignorée Le premier IOS en Flash est chargé, sinon

TFTP, sinon ROMMON.
0x2 Aucune
0x2 Une ou plusieurs Tente chaque commande jusqu’à ce que

l’une réussisse.
5. TP : « J’ai perdu le mot de passe du routeur ! Comment m’en sortir ? »
Contexte : une fois n’est pas coutume, difficile de virtualiser cet atelier. Le lecteur est donc invité à reproduire les

manipulations proposées sur un routeur CISCO quelconque. Nous supposons que si le lecteur est étudiant inscrit dans
l’académie CISCO, il a accès aux routeurs des bundles prévus pour les organismes de formation adhérents. Il s’agira
donc de 2600 ou 2800 pour lesquels la procédure décrite ciaprès s’applique strictement. Si le lecteur devait avoir
affaire au plus ancien routeur 2500, alors il conviendrait d’adapter les commandes ROMMON à ce modèle. Pour
l’essentiel, la commande confreg 2142 devient o/r 0x2142 et la commande reload devient initialize. Une solution à
laquelle on ne pense pas assez peut être donnée par le marché de l’occasion. Ainsi, au moment où ces lignes sont
écrites, le site eBay propose 848 objets sur le critère de recherche CISCO dont des routeurs 2600 à quelques euros.
Le mot de passe perdu peut être un mot de passe console, aux ou vty ou pire le mot de passe enable. S’il s’agit d’un
mot de passe de ligne console par exemple, peutêtre estil possible de tenter une connexion via Telnet ? Le plus
grave est évidemment de ne plus pouvoir accéder au mode privilégié puisque dans ce cas, toute modification de la
configuration est également interdite :
R12>enable
Password:
Password:
Password:
% Bad secrets
R12>
Le mot de passe n’est pas nécessairement perdu, il peut aussi être inconnu. Imaginez par exemple que votre
entreprise ait profité d’une opportunité alléchante en rachetant quelques routeurs sur le marché de l’occasion.
La procédure décrite ici convient quel que soit le mot de passe perdu. Elle suppose l’accès au port console autrement
dit l’accès physique au routeur. Puisque, bien entendu, le routeur est placé dans un local sécurisé, obtenir cet accès
physique ne peut être le fait que d’une personne habilitée. L’idée est de modifier la valeur du bit 6 du registre de
configuration afin que le contenu de la partition NVRAM, et avec elle le contenu du fichier startupconfig, soient ignorés
pendant le démarrage du routeur. Une fois le démarrage achevé, l’administrateur a donc affaire à un routeur « sorti du
carton » et peut à loisir charger la configuration et changer le ou les mots de passe.
1. L’administrateur a connecté un PC équipé d’un logiciel d’émulation de terminal au port console du routeur. La
jonction est réglée à 9600S81 (9600 bps, pas de parité, caractères exprimés sur 8 bits, 1 bit de stop).
2. Si aucun accès n’est possible, c’estàdire si les mots de passe associés aux lignes aux, con et vty sont perdus,
allez directement à l’étape 4 et rangez 2142 dans le registre de configuration (valeur la plus probable).
3. Une commande show version (Extrait) permet de découvrir la valeur actuelle du registre de configuration. Le plus
ordinairement, cette valeur s’établit à 0x2102 :
R12>show version
Cisco IOS Software, 2801 Software (C2801-IPBASEK9-M), Version 12.4(25c), RELEASE
.........
R12>
Faire passer le bit 6 à 1 dans ce cas implique de ranger 0x2142 dans le registre. Mais si la valeur lue dans le résultat
de la commande show version avait été 0x3922 par exemple, alors il aurait fallu ranger 0x3962. L’important est de
placer le bit 6 à 1 sans intervenir sur les autres réglages rangés dans le registre.
4. À ce stade, il faut redémarrer le routeur. On ne peut pas profiter de la commande reload qui nécessite le mode
privilégié. L’administrateur met hors tension le routeur, compte mentalement jusqu’à dix (une vieille habitude
d’électronicien) et remet sous tension. À partir de cet instant, il a 60 secondes pour provoquer une commande
« Break » de façon à ce que la séquence de démarrage s’interrompe après le chargement de ROMMON et affiche l’invite
de commande ROMMON. Le « Break » est obtenu à l’aide de la combinaison [Ctrl][Pause] au clavier :
Readonly ROMMON initialized

program load complete, entry point: 0x8000f000, size: 0xcb80
monitor: command "boot" aborted due to user interrupt

rommon 1 >
5. L’administrateur modifie la valeur du registre de configuration puis redémarre le routeur. Cette fois, il peut le faire à
l’aide de la commande reset de ROMMON :
rommon 1 >confreg 2142
You must reset or power cycle for new config to take effect
rommon 2 > reset
6. Le routeur achève le chargement de l’IOS sans charger ensuite le fichier de configuration startupconfig, ce que
confirme la question posée pour entrer dans le mode setup puis l’invite de commande Router> :
rommon 2 > reset

System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)
Copyright (c) 2006 by cisco Systems, Inc.
PLD version 0x10
GIO ASIC version 0x127
c2801 platform with 131072 Kbytes of main memory
Main memory is configured to 64 bit mode with parity disabled
program load complete, entry point: 0x8000f000, size: 0x111a9e4
Self decompressing the image :
###########################################################################
############# [OK]
Smart Init is enabled
smartinit is sizing iomem
ID MEMORY_REQ TYPE
0X003AA110 public buffer pools
0X00211000 public particle pools
0X00020000 Crypto module pools
0X0013 0X00035000 Card in slot 1
0X000021B8 Onboard USB
If any of the above Memory Requirements are
"UNKNOWN", you may be using an unsupported
.........
SOFTWARE (fc2)
.........
--- System Configuration Dialog ---
Would you like to enter the initial configuration dialog? [yes/no]: no
Router>
7. Plus rien ne s’oppose à ce que l’administrateur passe en mode privilégié puis fasse de la configuration sauvegardée
la configuration courante :
Router>en
Router#copy start run
Destination filename [running-config]?
8. L’administrateur visualise les mots de passe perdus (extrait) :
R12#sh run
.........
logging monitor warnings
enable secret 5 $1$vJGZ$oeNtoUc2zujJY9vumLnyR0
.........
line con 0
exec-timeout 60 0
password eni
logging synchronous
login
line aux 0
linevty 0 4
exec-timeout 0 0
password eni
logging synchronous
login
!
R12#
9. Les mots de passe en clair peuvent être réutilisés. Les mots de passe cryptés doivent être remplacés :
R12#conf t

R12(config)#enable secret cisco
10. L’administrateur replace la valeur du registre de configuration telle qu’il l’avait trouvée en début de procédure puis
sauvegarde :
R12(config)#config-register 0x2102
R12(config)#^Z
R12#copy run start
[OK]
11. Une commande show version confirme la future prise en compte de la nouvelle valeur du registre de configuration
(extrait) :
R12#sh ver
SOFTWARE (fc2)
.........
Configuration register is 0x2142 (will be 0x2102 at next reload)
R12#
12. Un dernier redémarrage et la procédure s’achève :
R12#reload
Proceed with reload? [confirm]
13. Mais comment vaton procéder pour éviter que ce genre de mésaventure ne se reproduise ?
Si l’entreprise a pris le temps d’élaborer une politique de sécurité, il serait étonnant que celleci ignore les mots de
passe et leur sauvegarde. Il faut donc déplorer un manquement par rapport aux procédures mises en place. Si cette
politique de sécurité est manquante ou en gestation, alors il faut profiter des événements qui viennent de se produire
pour alimenter son cahier des charges.
Cette séance d’atelier est maintenant terminée.

Gestion des images IOS
1. Sauvegarde/restauration des images via TFTP
Contexte : sur le routeur R12, un modèle 2801, l’administrateur décide de mettre l’IOS à jour pour la version la plus
récente du même train « Main line ». Son entreprise a souscrit un contrat de type « Smartnet » auprès de CISCO.
L’image IOS actuelle est c2801ipbasemz.12416a.bin. Le routeur dispose de 128 Mo de mémoire vive et de 64 Mo de
mémoire Flash :
■ Quelle est la partition active (ou partition de travail) ?
R12#show file systems

File Systems:

- - opaque rw null:
- - network rw tftp:
* 196600 194215 nvram rw nvram:
63995904 3837952 disk rw flash:#
- - opaque rwxmodem:
- - opaque rwymodem:
- - network rwrcp:
- - network rw ftp:
- - opaque rocns:
R12#
■ La partition active (marquée d’une étoile) est la partition NVRAM. L’administrateur souhaite faire de la mémoire Flash
la partition active. Pour ce faire, il utilise la commande cd (Change Directory) suivie d’une nouvelle commande show
file systems afin de confirmer que le changement est bien intervenu :
R12#cd flash:
R12#show file systems
File Systems:

- - opaque rw null:
- - network rw tftp:
196600 194215 nvram rw nvram:
* 63995904 3837952 disk rw flash:#
- - opaque rwxmodem:
- - opaque rwymodem:

- - network rwrcp:
- - network rw ftp:
- - opaque rocns:
R11#
■ Une commande pwd, moins bavarde, permet d’apprendre directement quelle est la partition active (wd : working
directory) :
R12#pwd
flash:
R12#
■ Une commande dir permet d’afficher le contenu de la partition active :
R12#dir
Directory of flash:/
1 -rw- 16810060 Sep 28 2007 02:32:00 +00:00 c2801-ipbase-mz.124-16a.bin

2 -rw- 1821 Sep 28 2007 02:49:02 +00:00 sdmconfig-2801.cfg
3 -rw- 6036480 Sep 28 2007 02:49:40 +00:00 sdm.tar
4 -rw- 861696 Sep 28 2007 02:50:00 +00:00 es.tar
5 -rw- 1164288 Sep 28 2007 02:50:22 +00:00 common.tar
6 -rw- 1038 Sep 28 2007 02:50:42 +00:00 home.shtml
7 -rw- 113152 Sep 28 2007 02:51:02 +00:00 home.tar
8 -rw- 1697952 Sep 28 2007 02:51:32 +00:00 securedesktop-ios-3.1.1.45-k9.pkg
9 -rw- 416354 Sep 28 2007 02:52:02 +00:00 sslclient-win-1.1.3.173.pkg
63995904 bytes total (36872192 bytes free)

R12#
On découvre ainsi que l’image IOS occupe 16 810 060 octets sur le support et que la place disponible sur cette
partition atteint 36 872 192 octets.
■ L’administrateur décide de mettre l’IOS à jour pour la version la plus récente du même train « Main line » et pour ce
faire, se connecte sur le site CISCO, section Products & Services Routers, onglet All products BranchRouters,
lien Cisco 2800 Series Integrated Services Routers, lien Support Download software pour finalement parvenir
à cette fenêtre Download software :

■ Dans la fenêtre Download Software, l’administrateur sélectionne le lien vers le modèle de routeur convenable, ce
qui provoque le passage à l’étape Select Software Type :

■ À cette étape, l’administrateur sélectionne le lien IOS Software, ce qui provoque le passage à l’étape 3 du
processus intitulée Select Software :

L’information affichée ici est très riche, on découvre en effet de façon exhaustive, l’ensemble des trains existants ainsi
que les versions sursitaires (Deferred Releases). L’affichage débute par un résumé des versions les plus récentes de
quelquesuns des trains dont le train « Main line ».
■ L’administrateur, qui souhaite rester dans le train « Main line », clique sur le lien 12.4.25c(MD) ce qui provoque
l’affichage de tous les packages (Feature Set) de cette version :

Hélas, le souhait de clarifier et simplifier l’offre IOS en ramenant le nombre de packages à huit (versions associées à
un rectangle dans l’illustration cidessus) n’aura probablement pas résisté aux contraintes marketing. Mais en réalité,
les versions ne sont pas aussi nombreuses que le laisse penser le tableau. Observez par exemple les quatre
premières versions toutes associées à un seul et même fichier c2801adventerprisek9mz.12425c.bin. On peut
s’étonner également que la version la plus évoluée « Advanced Enterprise Services », sensée agglomérer les
fonctionnalités de toutes les versions inférieures, exige moins de mémoire RAM (128 Mo) que la plupart des versions
immédiatement inférieures (192 Mo !).
■ L’administrateur, qui n’a pas de raison de changer de « Feature set », décide de télécharger « IP BASE », soit le
fichier c2801ipbasek9mz.12425c.bin. Il a bien noté que cette version n’exige pas davantage de RAM que celle qui
équipe actuellement le routeur cible. De plus, le fichier de l’image n’occupe que 17 935 236 octets et pourra donc
être placé sur la partition Flash sans exiger au préalable de détruire le fichier IOS en cours d’usage. C’est rassurant,
car si la nouvelle image devait se révéler corrompue, le routeur chargerait l’ancienne image. On est ainsi assuré de
limiter autant que faire se peut l’interruption de service. Un clic sur le bouton Download Now adéquat provoque
l’affichage d’une ultime fenêtre résumant le « panier ».

■ Une nouvelle confirmation entraîne l’affichage d’une fenêtre de licence :
■ Une fois les règles de téléchargement acceptées,

l’administrateur obtiendratil enfin le fichier convoité ? Oui, c’est en bonne voie...
■ Le précieux fichier est placé dans un répertoire IOS à la racine d’un serveur TFTP :

La mise en œ uvre de ce serveur a déjà été décrite dans le chapitre Tâches de configuration des routeurs de cet
ouvrage.
■ Avant de songer à tester la nouvelle image, l’administrateur décide de sauvegarder l’image en cours d’usage :
R12#copy flash:c2
R12#copy flash:c2801-ipbase-mz.124-16a.bin tftp://10.0.12.100/IOS/
Address or name of remote host [10.0.12.100]?
Destination filename [IOS/c2801-ipbase-mz.124-16a.bin]?
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
16810060 bytes copiedin 46.260 secs (363382 bytes/sec)
R12#
Observez que l’autocomplétion de l’interface ILC fonctionne y compris pour le nom de fichier qui contient l’image IOS.
■ Avant de charger la nouvelle image dans la partition Flash, l’administrateur décide de provoquer un démarrage du

routeur en mettant la nouvelle image à profit depuis son emplacement actuel, c’estàdire depuis le serveur TFTP.
Pour ce faire, il ajoute une commande boot system au fichier de configuration. Observez la commande no boot
system entrée en premier et qui donne l’assurance que la commande boot system entrée ensuite sera la seule
commande boot system présente dans le fichier de configuration :
R12(config)#no boot system

R12(config)#boot system tftp://10.0.12.100/IOS/c2801-ipbasek9-mz.124-25c.bin
R12(config)#^Z
R12#copy run start
[OK]
R12#reload
■ La nouvelle image se charge puis s’exécute sans problème apparent, une commande show version confirme que
cette image est bien en service :
R12#sh ver
SOFTWARE (fc2)
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Fri 12-Feb-10 00:29 by prod_rel_team

ROM: Cisco IOS Software, 2801 Software (C2801-IPBASE-M), Version 12.4(16a), RELEASE
SOFTWARE (fc2)
R12 uptime is 1 minute

System returned to ROM by reload at 13:10:08 UTC Wed Mar 10 2010
System image file is "tftp://10.0.12.100/IOS/c2801-ipbasek9-mz.124-25c.bin"
This product ..., return this product immediately.
Cisco 2801 (revision 7.0) with 114688K/16384K bytes of memory.

Processor board ID FCZ113990F6
2 FastEthernet interfaces
2 Low-speed serial(sync/async) interfaces
DRAM configuration is 64 bits wide with parity disabled.
191K bytes of NVRAM.
62720K bytes of ATA CompactFlash (Read/Write)
Configuration registeris 0x2102
■ Le chargement de la nouvelle version depuis TFTP étant un succès, l’administrateur décide qu’il est temps de placer
la nouvelle image dans la partition Flash :
R12#copy tftp://10.0.12.100/IOS/c2801-ipbasek9-mz.124-25c.bin flash:

Destination filename [c2801-ipbasek9-mz.124-25c.bin]?
Accessing tftp://10.0.12.100/IOS/c2801-ipbasek9-mz.124-25c.bin...
Loading IOS/c2801-ipbasek9-mz.124-25c.bin from 10.0.12.100 (via FastEthernet0/0):
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 17935236 bytes]
R12#
■ Une vérification de l’image s’impose :
R12#verify ?
/md5 Compute an md5 signature for a file
flash: File to be verified
nvram: File to be verified
R12#verify flash:c2801-ipbasek<<< Auto complétion

R12#verify flash:c2801-ipbasek9-mz.124-25c.bin
Verifying file integrity of flash:c2801-ipbasek9-mz.124-
25c.bin.........................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
.....Done!
Embedded Hash MD5 : FFBDB4755D369150A308535CF52E810F
Computed Hash MD5 : FFBDB4755D369150A308535CF52E810F
CCO Hash MD5 : 5D268C75DB75EA817E388CCB5072EAA7
Embedded hash verification successful.

R12#
■ Dans un second temps, l’administrateur intervient à nouveau sur la configuration afin de supprimer la ligne boot
system depuis TFTP et ajouter une ligne boot system qui provoquera le chargement de la nouvelle image. Notez
bien qu’il aurait suffi de supprimer l’ancienne image de la partition Flash pour provoquer le chargement de la
nouvelle image au prochain redémarrage. Mais puisque la place ne manque pas en partition Flash, pourquoi se
priver de la possibilité de revenir à l’image précédente (ceinture et bretelles toujours !) ?
R12(config)#no boot system

R12(config)#boot system ?
WORD TFTP filename or URL
flash Boot from flash memory
ftp Boot from a server via ftp
mop Boot from a Decnet MOP server
rcp Boot from a server via rcp
rom Boot from rom
tftp Boot from a tftp server
R12(config)#boot system flash ?

WORD System image filename
<cr>
R12(config)#boot system flash c2801-ipbasek9-mz<<< Auto complétion

R12(config)#boot system flash c2801-ipbasek9-mz.124-25c.bin
R12(config)#^Z
R12#copy run start
[OK]
R12#reload
■ Une fois le redémarrage achevé, une commande show version confirme que l’image IOS chargée provient
effectivement de la partition Flash (extrait) :
R12#show version
SOFTWARE (fc2)
Compiled Fri 12-Feb-10 00:29 by prod_rel_team
R12 uptime is 0 minutes

System returned to ROM by reload at 14:03:41 UTC Wed Mar 10 2010
System image file is "flash:c2801-ipbasek9-mz.124-25c.bin"
.........
R12#
■ Dans un futur pas si éloigné, l’administrateur souhaitera renouveler la procédure pour une version plus récente de
l’IOS. Mais, à moins de changer de mémoire Flash (c’est si simple avec le format Compact Flash), la place manquera
pour faire cohabiter trois fichiers d’images. L’administrateur devra alors se résoudre à supprimer l’image la plus

ancienne :
R12#dir
1 -rw- 16810060 Sep 28 2007 02:32:00 +00:00 c2801-ipbase-mz.124-16a.bin

.........
10 -rw- 17935236 Mar 10 2010 13:25:04 +00:00 c2801-ipbasek9-mz.124-25c.bin

R12#delete ?
/force Force delete
/recursive Recursive delete
flash: File to be deleted
nvram: File to be deleted
R12#delete flash:c2801-ipbase-<<< Auto complétion

R12#delete flash:c2801-ipbase-mz.124-16a.bin
Delete filename [c2801-ipbase-mz.124-16a.bin]?
Delete flash:/c2801-ipbase-mz.124-16a.bin? [confirm]
R12#undelete ?
% Unrecognized command
R12#dir /all
1 -rw- 1821 Sep 28 2007 02:49:02 +00:00 sdmconfig-2801.cfg

.........
9 -rw- 17935236 Mar 10 2010 13:25:04 +00:00 c2801-ipbasek9-mz.124-25c.bin

R12#
Sur les systèmes dits de classe A ou B (platesformes 7000 et 12000), un fichier effacé à l’aide d’une commande delete
ne l’est pas réellement. Le fichier est simplement marqué et une commande undelete permet de le récupérer (on peut
ainsi effacer puis récupérer un fichier jusqu’à quinze fois). Une commande squeeze provoque la purge des fichiers
marqués effacés. Dans le cas présent, nous avons affaire à un système dit de classe C pour lequel l’effacement est
immédiatement effectif, ce que confirme l’affichage de la mémoire Flash disponible, passée de 19 Mo environ à 35 Mo
environ.
a. La commande copy
La commande copy dont nous nous sommes servis dans ce scénario mérite quelques précisions :
● copy [/erase] [/verify | /noverify] sourceurl destinationurl
● /erase : optionnel, efface la partition cible avant d’effectuer la copie. Cette option est pratique sur
les platesformes dont l’espace mémoire flash est limité et pour lesquelles la copie nécessite une
partition cible vierge.
● /verify : optionnel, ne s’applique qu’aux fichiers images IOS. Le système qui a créé le fichier en a
calculé une signature MD5 qu’il a placée dans le fichier. Le système cible effectue le même calcul et
compare le résultat à la signature embarquée. En cas d’échec, le fichier est effacé de la partition
cible.
● /noverify : optionnel, ne s’applique qu’aux fichiers d’images IOS, permet de désactiver pour cette
copie la vérification systématique des copies d’images IOS, vérification entreprise parce que
l’administrateur a entré la commande de configuration globale file verify auto.
● sourceurl et destinationurl : comprend à la fois la localisation du fichier ainsi que son nom. Source et
destination peuvent être locales ou distantes.
Le scénario précédent a mis à profit des URL avec un préfixe tftp. Nous aurions également pu utiliser un serveur FTP,
ce choix offre évidemment davantage de fiabilité et devrait être préféré quand le serveur qui dispose du fichier

convoité est distant (sur un autre site). Mais l’accès à un serveur FTP peut nécessiter une authentification par nom
d’utilisateur et mot de passe. La syntaxe de l’URL est modifiée pour permettre l’entrée de ces informations :
● ftp:[[[//username [:password]@]location]/directory]/filename
L’exemple suivant copie un fichier IOS depuis le serveur FTP dont l’adresse est 10.0.12.100. Le compte utilisé pour
accéder au serveur est netadmin dont le mot de passe est ftppass :
Router# copy ftp://netadmin:[email protected]/IOS/c2801-ipbasek9-mz.124-25c.bin

flash:
2. Sauvegarde/Restauration des images via Xmodem
Le logiciel d’émulation de terminal PUTTY nous a rendu beaucoup de services mais hélas, il n’intègre pas les
fonctionnalités de transfert de fichiers via un port série (version 0.6). L’auteur propose de revenir à HyperTerminal, le
temps de régler le problème du chargement d’images à l’aide des protocoles Xmodem ou Ymodem. À nouveau hélas, il
se trouve que Microsoft n’est pas l’auteur de ce logiciel et qu’il a décidé de cesser de l’intégrer dans Windows 7, un
problème de royalties sans doute. Heureusement, ce logiciel reste disponible en téléchargement sur le site de son
véritable éditeur : ftp://ftp.hilgraeve.com/htpe/htpe63.exe
Le contexte de cette section est donc légèrement modifié par rapport à celui proposé pour ce chapitre : le logiciel
d’émulation de terminal est HyperTerminal et les manipulations sont effectuées depuis le port console. C’est
évidemment un pire cas, il faut une raison impérieuse pour en arriver à accepter de transférer un fichier sur le routeur
à l’aide d’un port asynchrone dont le débit culmine à 115200 bps. Même sans IOS, le routeur sous le contrôle de
ROMMON sait importer un fichier via TFTP. Donc il faut imaginer un état de catastrophe qui prive l’administrateur de
toute ressource réseau et à qui il ne reste que les ports d’administration : le port console pour un accès local et le port
aux pour un accès distant si on a pris la peine de le connecter à un modem relié à une ligne téléphonique.
Observez la fenêtre de capture cidessous. Elle retrace les évènements suivants :
■ Une combinaison [Ctrl][Pause] pendant les soixante premières secondes du démarrage provoque l’interruption de la
séquence de démarrage et l’affichage de l’invite de commande ROMMON. L’aide a le mérite d’exister sans prétendre
offrir les services de l’interface ILC. On apprend quand même qu’il existe une commande confreg permettant de
modifier la valeur du registre de configuration. Inutile d’entrer le préfixe « 0x » car la valeur attendue par confreg
est hexadécimale.
■ Quand le registre de configuration stocke la valeur normale 0x2102, les trois bits qui fixent le débit sont à zéro, ceci
correspond à un débit par défaut de 9600 bps sur le port console. Pour obtenir le débit maximal, soit 115200 bps,
il faut que ces trois bits soient à 1, ceci est obtenu en plaçant 0x3922 dans le registre de configuration.
■ Le passage au nouveau débit ne devient effectif qu’après un redémarrage obtenu à l’aide de la commande reset de
ROMMON.
■ Observez les caractères incompréhensibles qui s’affichent pendant un bref instant. Il s’agit des caractères émis par
le routeur sur le port console à 115200 bps mais lus à 9600 bps par le logiciel d’émulation de terminal. Le temps
pour l’administrateur de régler le logiciel à 115200 bps également et tout rentre dans l’ordre.
■ Une nouvelle combinaison [Ctrl][Pause] et voilà R12 à nouveau en mode ROMMON :
R12#reload
*Mar 10 15:37:23.879: %SYS-5-RELOAD: Reload requested by console. Reload Reason:

Reload Command.
Copyright (c) 2006 by cisco Systems, Inc.
PLD version 0x10
GIO ASIC version 0x127

rommon 1 > ?
alias set and display aliases command
bootboot up an external process
break set/show/clear the breakpoint
confreg configuration register utility
cont continue executing a downloaded image
context display the context of a loaded image
cookie display contents of motherboard cookie PROM in hex
dev list the device table
dir list files in file system
dis disassemble instruction stream
dnld serial download a program module
frame print out a selected stack frame
gioshow show the gio version
help monitor builtin command help
history monitor command history
iomemset set IO memory percent
meminfo main memory information
repeatrepeat a monitor command
reset system reset
rommon-pref Select ROMMON
set display the monitor variables
showmon display currently selected ROM monitor
stack produce a stack trace
sync write monitor environment to NVRAM
sysret print out info from last system return
tftpdnldtftp image download
unalias unset an alias
unsetunset a monitor variable
xmodem x/ymodem image download
rommon2>confreg 3922
You must reset or power cycle for new config to take effect
rommon3> reset
0ôqz¯?,>½¼Yìµÿ½3íÿ-
}VN®ýÿ¬¬llr&>ÿ³p_åv6ßï±önslÿÿ¿ýýÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ##############
############################################# [OK]
.........
rommon 1 >
■ La commande ROMMON permettant de provoquer le transfert d’un fichier vers la partition Flash est la commande
xmodem. Le choix de la partition cible n’est pas un argument de la commande, autrement dit le transfert s’effectue
obligatoirement vers cette partition. L’argument c permet d’opter pour un CRC sur 16 bits, plus fiable que le CRC
par défaut exprimé sur 8 bits :
rommon 1 >xmodem -c c2801-ipbase-mz.124-16a.bin

Do not start the sending program yet...
File size Checksum File name
0 bytes (0x0) 0x0000 k9-mz.124-25c.bin (invalid)
0 bytes (0x0) 0x0000 01.cfg (invalid)
0 bytes (0x0) 0x0000 (invalid)
0 bytes (0x0) 0x0000 p-ios-3.1.1.45-k9.pkg (invalid)
0 bytes (0x0) 0x0000 n-1.1.3.173.pkg (invalid)
WARNING: All existing data in flash will be lost!

Invoke this application only for disaster recovery.
Do you wish to continue? y/n [n]: y
Ready to receive file c2801-ipbase-mz.124-16a.bin ...

■ Le routeur se place en attente. Il reste à provoquer le transfert du fichier depuis HyperTerminal :
Arrivé à ce stade, l’administrateur est assez désappointé. En effet, le transfert ne sera achevé au mieux que dans un
peu moins de trois heures et encore à la condition qu’aucun incident ne se produise pendant ce laps de temps.
Xmodem utilise des paquets de 128 octets ce qui explique cette lenteur. Fort heureusement, ROMMON permet
également un transfert selon le protocole Ymodem qui met à profit un transfert par paquets de 1 Ko.
■ L’administrateur interrompt le transfert Xmodem et reprend la procédure à son début. Observez la commande
xmodem qui reste la même mais admet l’argument y quand on souhaite établir le protocole Ymodem en lieu et
place du protocole Xmodem :


rommon 1 >xmodem -c -y c2801-ipbase-mz.124-16a.bin
Do not start the sending program yet...
File size Checksum File name
0 bytes (0x0) 0x0000 k9-mz.124-25c.bin (invalid)
0 bytes (0x0) 0x0000 01.cfg (invalid)
0 bytes (0x0) 0x0000 p-ios-3.1.1.45-k9.pkg (invalid)
0 bytes (0x0) 0x0000 n-1.1.3.173.pkg (invalid)
WARNING: All existing data in flash will be lost!

Invoke this application only for disaster recovery.
Do you wish to continue? y/n [n]:y
Ready to receive file c2801-ipbase-mz.124-16a.bin ...
■ Cette fois, dans HyperTerminal, l’administrateur choisit le protocole Ymodem :

■ L’administrateur constate avec soulagement que le même transfert ne demandera avec Ymodem que quarante
minutes environ. Une fois le transfert achevé, la console affiche :
Format: Drive communication & 1st Sector Write OK...

Writing Monlib sectors.
.......................................................................
................................
Monlib write complete
Format: All system sectors written. OK...

Format: Operation completed successfully.
Format of flash: complete

■ Le routeur redémarre et charge l’image IOS objet de ce transfert, ce que confirme une commande show version
(extrait) :
R12#sh ver
Cisco IOS Software, 2801 Software (C2801-IPBASE-M), Version 12.4(16a), RELEASE S
OFTWARE (fc2)
.........
System image file is "flash:c2801-ipbasek9-mz.124-25c.bin"
.........
Configuration registeris 0x3922
La ligne d’information « System image file is "flash:c2801ipbasek9mz.12425c.bin" » ne correspond pas à l’image IOS
effectivement chargée mais à l’image IOS que le routeur a tenté de charger sans succès. En effet, cette image n’est
plus présente en Flash (suite à la commande xmodem) mais il subsiste une commande boot system dans le fichier de
configuration dont l’objet est de charger l’image version 12.4(25c).
■ Une commande show flash: confirme qu’il fallait prendre au sérieux l’avertissement de ROMMON avant de lancer la
commande xmodem. En effet, ne subsiste sur la partition Flash que le seul fichier image transféré à l’aide de la
commande xmodem :
R12#show flash:
-#- --length-- -----date/time------ path
1 16810060 Feb 23 2010 20:15:44 +00:00 c2801-ipbase-mz.124-16a.bin
47198208 bytes available (16814080 bytes used)
R12#dir

1 -rw- 16810060 Feb 23 2010 20:15:44 +00:00 c2801-ipbase-mz.124-16a.bin
Observez l’équivalence de la commande show flash: et de la commande dir (quand la partition active est la Flash bien
sûr).
Contrairement à la commande copy de l’IOS, la commande xmodem de ROMMON provoque le transfert de

fichiers mais aussi l’effacement complet de la partition Flash !
Observez la valeur actuelle 0x3922 du registre de configuration dans la capture de la commande show version ci
dessus. Attention, cette valeur doit nous rappeler que le débit du port console est encore réglé à 115200 bps.
Imaginez la surprise d’un autre administrateur qui viendrait à se connecter sur le port console de ce routeur en
ignorant que le débit du port console n’est pas celui par défaut.
■ Il est prudent de replacer la valeur par défaut soit 0x2102 dans le registre de configuration :
R12(config)#config-register 0x2102
R12(config)#^Z
R12#show version
Cisco IOS Software, 2801 Software (C2801-IPBASE-M), Version 12.4(16a), RELEASE
SOFTWARE (fc2)
.........
Configuration register is 0x3922 (will be 0x2102 at next reload)
R12#reload
Attention à bien régler le débit côté logiciel d’émulation de terminal à la valeur 9600 bps, une fois le routeur
redémarré.
Pour l’anecdote :
Sur un routeur 2801 qui a servi à préparer ce chapitre, l’auteur a eu les plus grandes difficultés à rétablir la valeur
0x2102 du registre de configuration. Ce n’est qu’après avoir établi la vitesse du port console à 9600 bps à l’aide de la
commande speed en configuration de ligne que le routeur a effectivement consenti à changer la valeur du registre de
configuration. Aucun message d’erreur mais la commande configregister restait sans effet ou ne donnait pas le
résultat escompté. Problème à approfondir sans doute...
3. TP : « J’ai effacé le contenu de la Flash, mon routeur n’a plus d’IOS ! Comment m’en
sortir ? »
Contexte : la capture ciaprès décrit un genre de manipulations qu’aucun administrateur normalement constitué
n’oserait entreprendre sur un routeur en production. Mais pourquoi se priver sur un routeur d’école ? (certains
formateurs vont me maudire !) À la condition bien sûr de rendre le routeur dans l’état où on l’a trouvé. Ce qui suppose
de s’être assuré de disposer sur une machine quelconque du ou des fichiers images adéquats.
Notez d’abord qu’effacer les fichiers d’image présents en Flash n’est pas toujours si simple et qu’il faut se montrer
persévérant et c’est rassurant. Le comportement observé ici est celui d’une plateforme 2800 qui utilise le système de
fichiers de classe C, il pourrait être différent sur des routeurs utilisant d’autres systèmes de fichiers (CISCO met en
œ uvre trois systèmes de fichiers différents dits de classe A, B ou C, ce point fait l’objet d’un paragraphe dédié dans ce
chapitre) :
R12#erase flash:
^
% Invalid input detected at ’^’ marker.
R12#erase ?
/all Erase all files(in NVRAM)
/no-squeeze-reserve-space Do not reserve space for squeeze operation
nvram: Filesystem to be erased
startup-config Erase contents of configuration memory
R12#delete flash:?
flash:c2801-ipbase-mz.124-16a.bin flash:c2801-ipbasek9-mz.124-25c.bin
flash:common.tarflash:es.tar
flash:home.shtmlflash:home.tar

flash:sdm.tar flash:sdmconfig-2801.cfg
flash:securedesktop-ios-3.1.1.45-k9.pkg flash:sslclient-win-1.1.3.173.pkg
R12#delete flash:
Delete filename []?
Delete flash:/? [confirm]
%Error deleting flash:/ (Can’t delete a directory that has files in it)
R12#
R12#delete flash:c2801-ipbase-
R12#delete flash:c2801-ipbase-mz.124-16a.bin
Delete filename [c2801-ipbase-mz.124-16a.bin]?
Delete flash:/c2801-ipbase-mz.124-16a.bin? [confirm]
R12#delete flash:c2
R12#delete flash:c2801-ipbasek9-mz.124-25c.bin
Delete filename [c2801-ipbasek9-mz.124-25c.bin]?
Delete flash:/c2801-ipbasek9-mz.124-25c.bin? [confirm]
R12#reload
Ainsi, sur un système de classe C, la commande erase flash: n’existe pas (la commande erase est utilisée sur les
systèmes de classe B, la commande correspondante en classe C est la commande format). Quant à la commande
delete, elle refuse de supprimer la partition tant que des fichiers y sont présents. La seule possibilité consiste à
supprimer les fichiers images un à un, remarquez à nouveau que l’autocomplétion fonctionne ce qui permet de ne
taper que quelques caractères du nom de fichier. Un redémarrage aboutit alors, faute d’IOS à charger, au mode
ROMMON :
boot: cannot load "flash:"

.........

rommon 1 >
Dans la première partie de cette section dédiée à la gestion des images IOS, nous avions utilisé TFTP mais l’IOS était
fonctionnel. Dans un second temps, nous avons utilisé Xmodem et Ymodem sous le contrôle de ROMMON mais cette
solution demande une certaine patience. Dans le cas présent, seul ROMMON est disponible mais nous explorerons une
troisième possibilité qui consiste à mettre en œ uvre TFTP sous son contrôle.
■ La commande à utiliser est tftpdnld. Avec l’argument h, elle fournit l’aide indispensable :
boot: cannot load "flash:"

.........
rommon 1 >tftpdnld -h
usage: tftpdnld [-hr]

Use this command for disaster recovery only to recover an image via TFTP.
Monitor variables are used to set up parameters for the transfer.
(Syntax: "VARIABLE_NAME=value" and use "set" to show current variables.)
"ctrl-c" or "break" stops the transfer before flash erase begins.
The following variables are REQUIRED to be set for tftpdnld:

IP_ADDRESS: The IP address for this unit
IP_SUBNET_MASK: The subnet mask for this unit
DEFAULT_GATEWAY: The default gateway for this unit
TFTP_SERVER: The IP address of the server to fetch from
TFTP_FILE: The filename to fetch
The following variables are OPTIONAL:

TFTP_VERBOSE: Print setting. 0=quiet, 1=progress(default), 2=verbose
TFTP_RETRY_COUNT: Retry count for ARP and TFTP (default=18)
TFTP_TIMEOUT: Overall timeout of operation in seconds (default=7200)
TFTP_CHECKSUM: Perform checksum test on image, 0=no, 1=yes (default=1)
FE_PORT: 0= (default), 1
FE_SPEED_MODE: 0=10/hdx, 1=10/fdx, 2=100/hdx, 3=100/fdx,
4=Auto (default)

TFTP_DESTINATION: The flash destination device for the file
flash:(default), usbflash0:
Command line options:

-h: this help screen
-r: do not write flash, load to DRAM only and launch image
■ Il faut saisir les paramètres nécessaires au transfert un par un. Attention, ROMMON n’exerce aucun contrôle de
syntaxe et vous laisse créer ces variables à votre guise. Ainsi, entrer ip_address=10.0.12.1 est accepté. Mais le
processus tftpdnld ne reconnaîtra pas l’adresse IP et génèrera un message ILLEGAL ADDRESS. Les variables
doivent donc être créées en respectant la casse :
rommon 2 > IP_ADDRESS=10.0.12.1

rommon 3 > IP_SUBNET_MASK=255.255.255.0
rommon 4 > DEFAULT_GATEWAY=10.0.12.254
rommon 5 > TFTP_SERVER=10.0.12.100
rommon 6 > TFTP_FILE=IOS/c2801-ipbasek9-mz.124-25c.bin
■ Une commande set permet un dernier contrôle des variables créées :
rommon 8 >set
PS1=rommon !>
WARM_REBOOT=FALSE
BOOT=flash:c2801-ipbasek9-mz.124-25c.bin,1;
BSI=0
RANDOM_NUM=948452295
RET_2_RTS=10:21:13 UTC Fri Mar 12 2010
RET_2_RCALTS=1268389276
IP_ADDRESS=10.0.12.1
IP_SUBNET_MASK=255.255.255.0
DEFAULT_GATEWAY=10.0.12.254
TFTP_SERVER=10.0.12.100
TFTP_FILE=IOS/c2801-ipbasek9-mz.124-25c.bin
?=0
rommon 9 >
Observez l’adresse IP de la passerelle, entrée uniquement pour satisfaire le processus tftpdnld. En effet, dans le
contexte utilisé pour ce chapitre, le serveur TFTP est directement connecté à R12, ce sur le port f0/0. Le processus
tftpdnld peut utiliser le port f0/1 mais il aurait fallu dans ce cas créer une variable supplémentaire FE_PORT=1.
■ La phase préparatoire est terminée, il devient possible de lancer effectivement la commande tftpdnld :
rommon10>tftpdnld
IP_ADDRESS: 10.0.12.1
IP_SUBNET_MASK: 255.255.255.0
DEFAULT_GATEWAY: 10.0.12.254
TFTP_SERVER: 10.0.12.100
TFTP_FILE: IOS/c2801-ipbasek9-mz.124-25c.bin
TFTP_MACADDR: 00:1c:f6:d6:74:bc
TFTP_VERBOSE: Progress
TFTP_RETRY_COUNT: 18
TFTP_TIMEOUT: 7200
TFTP_CHECKSUM: Yes
FE_PORT: 0
FE_SPEED_MODE: Auto Detect
Invoke this command for disaster recovery only.

WARNING: all existing data in all partitions on flash: will be lost!
Do you wish to continue? y/n: [n]: y
Receiving IOS/c2801-ipbasek9-mz.124-25c.bin from 10.0.12.100

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
File reception completed.
Validating checksum.
Copying file IOS/c2801-ipbasek9-mz.124-25c.bin to flash:.
Format: Drive communication & 1st Sector Write OK...

Writing Monlib sectors.
...............................................................................
........................
Monlib write complete
Format: All system sectors written. OK...

Format: Operation completed successfully.
Format of flash: complete

rommon11>
■ Vous n’obtenez pas ce résultat ?
● Avezvous pensé à désactiver le parefeu de la machine qui héberge le serveur TFTP ?
● Ou au moins à créer une règle autorisant le trafic UDP vers le port 69 ?
● Revérifiez les variables à l’aide de la commande set de ROMMON.
● Vérifiez la disponibilité effective du serveur TFTP (une commande netstat ano pour vérifier le port UDP 69).
■ Il est temps de revenir à l’IOS :
rommon 9 > reset

.........
program load complete, entry point: 0x8000f000, size: 0x111a9e4

Self decompressing the image :
###############################################################################
######### [OK]
Smart Init is enabled

smartinit is sizing iomem
ID MEMORY_REQ TYPE
0X003AA110 public buffer pools
0X00211000 public particle pools
0X00020000 Crypto module pools
0X0013 0X00035000 Card in slot 1
0X000021B8 Onboard USB
If any of the above Memory Requirements are

"UNKNOWN", you may be using an unsupported
.........

SOFTWARE (fc2)

.........
Password:
R12>en
Password:
R12#sh flash:
1 17935236 Feb 22 1907 17:31:44 +00:00 c2801-ipbasek9-mz.124-25c.bin
R12#
Observez le contenu de la partition Flash. Comme dans le cas de la commande xmodem, le contenu de la partition a
été totalement effacé, le seul fichier qui s’y trouve est celui résultant du transfert réalisé par le processus tftpdnld.
La commande tftpdnld de ROMMON a le même comportement que la commande xmodem. Contrairement à la

commande copy de l’IOS, ces deux commandes provoquent le transfert de fichier mais aussi l’effacement
complet de la partition Flash !
Cette séance d’atelier est maintenant terminée.

Les systèmes de fichiers CISCO
Au fur et à mesure de la rédaction de ce chapitre, il est apparu de plus en plus évident qu’il devenait difficile de
totalement passer sous silence les systèmes de fichiers utilisés par CISCO sur ses différentes platesformes. Alors bien
sûr, une fois de plus, nous sommes audelà des attendus de la certification CCNA.
1. Les dispositifs PCMCIA
Quand il a fallu décider quel serait le dispositif qui tiendrait le rôle du disque dur, CISCO a fait le choix de la mémoire
Flash. Les platesformes plus anciennes intégraient cette mémoire directement sous forme de modules sur la carte
mère du système. L’espace adressable de la mémoire réalisée sous cette forme est « linéaire ». L’organisation d’un
disque dur est très différente puisque l’espace est divisé en secteurs, euxmêmes regroupés en clusters, et qu’un
contrôleur complexe est chargé de gérer les secteurs.
Les platesformes les plus récentes embarquent de la mémoire Flash réalisée à l’aide de cartes au format Compact
Flash. La norme Compact Flash est conforme à la norme « PCCard » (ou PCMCIA). La mémoire Flash d’une carte
Compact Flash peut être accédée de deux manières différentes :
1) De façon classique, c’estàdire en réalisant un espace adressable linéaire, CISCO parle alors de carte Flash ou de
carte de mémoire Flash.
2) À l’aide d’un contrôleur interfacé au système via une interface ATA (AT Attachment) comme un classique dispositif
de type disque dur sur un PC, ce qui la fait appeler dans ce cas disque Flash ou disque Flash ATA.
Le disque Flash offre une utilisation plus souple que la mémoire Flash linéaire parce que son contrôleur émule le
fonctionnement d’un disque dur et prend en charge la gestion des secteurs (qui n’en sont plus dans le cas d’une
mémoire Flash) de façon transparente. Un secteur observé défectueux est marqué et le contrôleur ne l’utilise plus. Le
contrôleur gère également l’effacement d’un fichier et il est capable d’écrire un fichier sur des blocs non contigus. Ceci
élimine la nécessité de la commande squeeze utilisée sur la mémoire Flash linéaire quand il faut récupérer l’espace
mémoire occupé par des fichiers marqués effacés.
Parmi les différences entre une mémoire Flash linéaire intégrée à la carte mère et un dispositif PCMCIA, le fait
d’ajouter de la mémoire Flash linéaire permet d’augmenter l’espace disponible et donc d’y écrire un fichier plus grand.
Sur les platesformes qui peuvent recevoir plusieurs cartes Flash, ajouter une carte n’offre pas cette faculté. Cet
inconvénient est mineur parce que les cartes ou disques Flash offrent des espaces mémoire augmentés, couramment
de 48 à 128 Mo. Ils permettent ainsi le stockage de tout fichier dont pourrait avoir besoin le système, on pense bien
sûr aux images IOS et aux fichiers de configuration mais la liste n’est pas exhaustive.
En général, mais ce n’est pas systématique, CISCO distingue les disques Flash ATA en nommant les partitions
réalisées disk0: ou disk1:. Les espaces réalisés à l’aide de cartes Flash sont quant à eux désignés slot0: ou slot1:.
Une commande show version permet de découvrir les types de mémoire Flash qui équipent le routeur et leur
nommage par le système :
7200# show version

IOS (tm) 7200 Software (C7200-JS-M), Version 12.0(22), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2002 by cisco Systems, Inc.
Compiled Mon 01-Apr-02 19:44 by srani
Image text-base: 0x60008900, data-base: 0x610E0000
ROM: System Bootstrap, Version 12.1(20000914:181332) [bwhatley-npe200 102],

DEVELOPMENT SOFTWARE
BOOTFLASH: 7200 Software (C7200-BOOT-M), Version 12.0(5), RELEASE SOFTWARE (fc1)
cisco 7206 (NPE150) processor with 43008K/6144K bytes of memory.

R4700 processor, Implementation 33, Revision 1.0 (512KB Level 2 Cache)
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.

SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
1 FastEthernet/IEEE 802.3 interface(s)
125K bytes of non-volatile configuration memory.
1024K bytes of packet SRAM memory.
46976K bytes of ATA PCMCIA card at slot 0 (Sector size 512 bytes).
!— Ci-dessus, voici un disque Flash !

20480K bytes of Flash PCMCIA card at slot 1 (Sector size 128K).
!—Ci-dessus, voici une carte linéaire Flash !
4096K bytes of Flash internal SIMM (Sector size 256K).
2. Système de fichiers de classe A
Les platesformes concernées :
● ATM Switch/Processor for LightStream 1010 et Catalyst 5000/5500 ;
● Multiservice Switch Route Processor for LightStream 1010 ;
● Catalyst 5000/5500 Route Switch Module (RSM) ;
● Catalyst 8500 Switch Route Processor (SRP) ;
● Cisco 6400 Universal Access Concentrator ;
● Cisco 7000 Route Switch Processor (RSP) ;
● Cisco 7500 Series Route Switch Processors (RSP 2, RSP 4, RSP 8) ;
● Cisco 12000 Series Internet Router.
Le système de fichiers de classe A supporte les commandes suivantes :
● delete : les fichiers effacés sont marqués mais sans libérer l’espace qu’ils occupaient en mémoire Flash. Une
commande undelete est possible.
● squeeze : supprime de façon définitive l’ensemble des fichiers marqués « supprimés » ou « en erreur » de la
partition désignée. Les fichiers ne pourront pas être récupérés. Cette commande peut nécessiter un temps
d’exécution important (plusieurs minutes).
● format : supprime tout fichier de la partition et prépare le dispositif afin qu’il puisse être utilisé par la plate
forme.
● verify : calcule la somme de contrôle d’un fichier et la compare avec une somme de contrôle précédemment
calculée et stockée sur le dispositif. Les disques Flash ne peuvent stocker des sommes de contrôle si bien
que cette commande n’est pas supportée.
Quelques exemples de commandes en classe A :
● Une suppression de fichier :
C7513#delete slot0:rsp-jsv-mz.112-26.bin
Delete filename [rsp-jsv-mz.112-26.bin]? Y
Delete slot0:rsp-jsv-mz.112-26.bin? [confirm]y
● Une récupération de fichier :
C7513#undelete 1 slot0:

La récupération est possible à la condition de connaître l’index associé au fichier. Cet index peut être obtenu à l’aide
d’une commande show {device:} comme indiqué cidessous :
C7513#show slot0:
-#- ED --type-- --crc--- -seek-- nlen -length- -----date/time------ name
1 .D image 9CAA2A55 83C50C 19 8504460 Jan 13 2000 20:03:02 rsp-pv-mz.120-

10.S5
● La commande squeeze utile quand il faut supprimer de façon définitive les fichiers marqués effacés sur les
cartes Flash (mémoire linéaire). Cette commande n’est pas utilisée sur les disques Flash ATA. Avec une
commande squeeze, tous les fichiers présents sur la partition Flash considérée et non marqués effacés ou en
erreur sont réécrits depuis le début de la partition. La commande a donc un double effet : elle efface et
défragmente :
C7513#squeeze slot0:
All deleted files will be removed. Continue? [confirm]y
Squeeze operation may take a while. Continue? [confirm]y
Squeezing...
Squeeze of slot0 complete
● La commande format Il arrive que l’administrateur doive mettre en service une nouvelle carte Flash PCMCIA
afin d’y placer des images IOS ou d’y sauvegarder des fichiers de configuration. La nouvelle carte ne devient
disponible pour le système qu’après avoir été formatée. La prudence recommande de formater la nouvelle
carte sur la plateforme même qui l’utilisera ensuite. On est ainsi assuré de pouvoir lancer un démarrage et
un chargement d’IOS depuis cette carte (elle est « bootable ») :
C7513#format slot0:
Format operation may take a while. Continue? [confirm]y
Format operation will destroy all data in "slot0:".Continue? [confirm]y
Formatting sector 160.....
Format of slot0: complete
3. Système de fichiers de classe B
● Cisco 1000 Series Routers ;
● Cisco 2801 Router.
Les routeurs de la série 1600 ne comportent qu’une seule carte Flash PCMCIA. Les modèles 1601 et 1604 exécutent
l’IOS directement en Flash. La conséquence est que si la carte Flash est ôtée, le routeur cesse de fonctionner. Les
modèles 1601R et 1605R exécutent l’IOS en RAM. Un retrait de la carte Flash empêche le prochain redémarrage.

Les routeurs de la série 3600 utilisent le système de fichiers de classe B mais une manipulation permet de faire en
sorte qu’ils acceptent autant les commandes de classe B que celles de classe C.
Les commandes utiles pour gérer un système de fichiers de classe B sont :
● delete : les fichiers effacés sont marqués mais sans libérer l’espace qu’ils occupaient en mémoire Flash.
● erase : supprime de façon définitive l’ensemble des fichiers présents sur la partition.
● partition : divise l’espace de mémoire Flash. La forme no de la commande fait revenir à un espace composé
d’une partition unique.
Quelques exemples de commandes en classe B :

La commande delete ne fait que marquer les fichiers. Avant de copier un fichier sur une partition en classe B, il est
bon de vérifier que l’on dispose encore de suffisamment de place disponible à l’aide d’une commande dir{device:}.
Quand ce n’est pas le cas, il faut se résoudre à effacer la mémoire Flash à l’aide d’une commande erase. Une fois la
commande erase exécutée, le seul moyen de disposer à nouveau d’un fichier effacé est de le charger à nouveau
dans la partition, via TFTP ou FTP par exemple :
3640#delete slot1:c3640-i-mz.113-11c.bin
Delete filename [c3640-i-mz.113-11c.bin]? Y
Delete slot1:c3640-i-mz.113-11c.bin? [confirm]y
Sur un système de fichiers de classe B, la commande erase permet de récupérer l’espace encore occupé par
les fichiers marqués effacés. Mais il faut se souvenir qu’elle provoque également la suppression de tout
fichier présent dans le système de fichiers.
Un exemple de commande erase entrée sur un routeur 3640 pour effacer le contenu de slot1:...
3640#erase slot1:
Erasing the slot1 filesystem will remove all files! Continue? [confirm]y
Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erased
Erase of slot1 complete
La commande partition, en mode de configuration globale, permet de diviser une mémoire Flash en partitions.
Exemple de partitionnement sur les platesformes 1600 et 3600 :
partition flash-filesystem: [number-of-partitions][partition-size]
La forme no de la commande supprime le partitionnement et restaure une partition unique :
no partition flash-filesystem:
L’utilisation de la commande partition nécessite d’effacer la mémoire Flash au préalable à l’aide d’une
commande erase.
La syntaxe générale de la commande permettant de partitionner sur les platesformes de classe B en dehors des
platesformes 1600 et 3600 est :
partition flash partitions [size1 size2]
La forme no de la commande supprime le partitionnement et restaure une partition unique :
no partition flash
Sur une plateforme 3600, l’exemple suivant divise l’espace de mémoire Flash Slot0: en trois partitions : deux
partitions de 8 Mo et une partition de 4 Mo.
3640(config)# partition slot0: 3 8 8 4

Une commande show slot0: fait découvrir ou permet de vérifier le partitionnement établi sur une mémoire Flash. Ainsi
dans l’exemple suivant, l’administrateur observe que trois partitions existent, deux de 8 Mo et une de 4 Mo. La
première partition est chargée avec une image IOS. Cette image a nécessairement été placée là après l’opération de
partitionnement :
3640#show slot0:
PCMCIA Slot0 flash directory, partition 1:
File Length Name/status
1 2779832 c3640-i-mz.113-11c.bin
[2779896 bytes used, 5608712 available, 8388608 total]
8192K bytes of processor board PCMCIA Slot0 flash (Read/Write)
No files in PCMCIA Slot0 flash
No files in PCMCIA Slot0 flash
Pour supprimer les partitions, il faut utiliser la forme no de la commande :
3640(config)#no partition flash 3 8 8 4
4. Système de fichiers de classe C
● AS5800 Dial Shelf Controller ;
● Catalyst 5000/5500 Supervisor III Module ;
● Catalyst 6000/6500 Supervisor Engine I ;
● Catalyst 6000/6500 Supervisor Engine II ;
● Cisco 7000 Route Processor ;
● Cisco uBR7100 Series Routers ;
● Cisco 7200 Series Network Processing Engine ;
● Cisco uBR7200 Series Routers ;
● Cisco 7200VXR Series Network Services Engine 1 ;

● Cisco 7600 Series Internet Routersv ;
● Cisco 10000 Series Routers (ESR) ;
● Cisco uBR10000 SeriesRouters ;
● Cisco 2800 SeriesRouters (à l’exception du routeur 2801) ;
● Cisco 3800 SeriesRouters.
Les commandes utiles pour gérer un système de fichiers de classe C sont :
● format : formate la mémoire Flash et par suite, supprime de façon définitive l’ensemble des fichiers présents.
● mkdir : crée un nouveau répertoire dans le système de fichiers de classe C.
● rmdir : supprime un répertoire existant dans le système de fichiers de classe C à la condition que ce
répertoire ait été vidé de ses fichiers (ou sousrépertoires) au préalable.
Quelques exemples de commandes en classe C :

Quand une commande show flash: all fournit des informations de géométrie et de format, alors on est assuré d’avoir
affaire à un système de fichiers de classe C, c’est le cas dans la capture ciaprès :
R12>show flash: all

1 17935236 Feb 22 1907 17:31:44 +00:00 c2801-ipbasek9-mz.124-25c.bin
******** ATA Flash Card Geometry/Format Info ********
ATA CARD GEOMETRY

Number of Heads: 8
Number of Cylinders 490
Sectors per Cylinder 32
Sector Size 512
Total Sectors 125440
ATA CARD FORMAT

Number of FAT Sectors 62
Sectors Per Cluster 8
Number of Clusters 15628
Number of Data Sectors 125297
Base Root Sector 235
Base FAT Sector 111
Base Data Sector 267
ATA MONLIB INFO

Image Monlib size = 61144
Disk monlib size = 56832
Name = piptom-atafslib-m
Monlib Start sector = 2
Monlib End sector = 104
Monlib updated by =
Monlib version = 1
R12>
Une commande dir permet d’afficher le contenu du répertoire courant :
R12#dir flash:

1 -rw- 17935236 Feb 22 1907 17:31:44 +00:00 c2801-ipbasek9-mz.124-25c.bin
2 -rw- 1363 Mar 17 2010 13:15:44 +00:00 R12_cfg.txt

R12#
La commande mkdir flash:/config ou mkdir /config crée le répertoire config à la racine de la partition Flash. Observez
la lettre « d » parmi les attributs, seule façon de distinguer un fichier d’un répertoire :
R12#mkdir flash:/config
Create directory filename [config]?
Created dir flash:/config

R12#dir

2 -rw- 1363 Mar 17 2010 13:15:44 +00:00 R12_cfg.txt
3 drw- 0 Mar 17 2010 13:18:24 +00:00 config

R12#
La commande cd permet de changer de répertoire courant :
R12#cd config
R12#dir
Directory of flash:/config/
No files in directory

R12#
Plaçons un fichier quelconque dans notre nouveau répertoire :
R12#copy running-config R12_cfg.txt

Destination filename [/config/R12_cfg.txt]?

R12#dir
4 -rw- 1363 Mar 17 2010 13:22:00 +00:00 R12_cfg.txt

R12#
Remontons à la racine à l’aide d’une commande cd .. puis tentons de supprimer le répertoire config :
R12#pwd
flash:/config/
R12#cd ..
R12#pwd
flash:/
R12#rmdir config
Remove directory filename [config]?
Delete flash:/config? [confirm]
%Error Removing dir flash:/config (Can’t delete a directory that has files in it)
R12#
C’est un échec parce que le répertoire config n’est pas vide. Vidons le répertoire à l’aide d’une commande delete.
Observez la quantité de mémoire disponible avant et après la suppression. Elle confirme que le fichier effacé l’est
effectivement, ce qui caractérise un système de fichiers de classe C :
R12#cd config
R12#delete R12_cfg.txt
Delete filename [/config/R12_cfg.txt]?
Delete flash:/config/R12_cfg.txt? [confirm]

R12#dir
No files in directory

R12#
Une nouvelle tentative pour supprimer le répertoire config est cette fois couronnée de succès :
R12#cd ..
R12#dir

2 -rw- 1363 Mar 17 2010 13:15:44 +00:00 R12_cfg.txt
3 drw- 0 Mar 17 2010 13:18:24 +00:00 config

R12#rmdir config
Remove directory filename [config]?
Delete flash:/config? [confirm]
Removed dir flash:/config
R12#dir

2 -rw- 1363 Mar 17 2010 13:15:44 +00:00 R12_cfg.txt

R12#

Solution travaux pratiques : application du découpage
Il faut se souvenir que vu de l’extérieur, l’adresse du réseau 194.2.16.0/24 est toujours valide, un datagramme destiné
à l’une des machines de l’un quelconque des sousréseaux est toujours transporté par l’Internet (ici le réseau
séparant R0 et R1) en mettant à profit l’adresse réseau, il suffit donc d’entrer sur R0 la route statique suivante :
194.2.16.0 255.255.255.0 via 192.168.1.1
Naturellement si vous avez entré une route statique pour chacun des 10 sousréseaux, cela fonctionne également
mais vous êtes très courageux !
Vous venez du chapitre Le routage, initiation Sousréseaux et surréseaux.

Solution exercice 9.1 : découpage VLSM
M. COUSIN, administrateur d’un parc de 500 adresses dans le site Nord de l’entreprise Primevère se voit déléguer le
bloc 10.0.14.0/23. Il peut vouloir l’utiliser en globalité ou réaliser un découpage VLSM.
Question 1
Si M. COUSIN utilise le préfixe dans sa globalité, quelles sont les adresses du premier hôte, du dernier hôte, de
diffusion ?
Question 2
Réalisez à votre tour un découpage en tableau « dichotomique » en arrêtant la division au préfixe /28.
Vous venez du chapitre Le routage, initiation Sousréseaux et surréseaux Masque de longueur variable VLSM.

Solution travaux pratiques : routes statiques agrégées
Voici les 14 routes à entrer :
Routeur Réseau distant via Tronçon suivant
R11 10.0.12.0/24 via 10.0.8.12
10.0.16.0/21 via 10.0.8.8
R12 10.0.11.0/24 via 10.0.11.0/24
10.0.16.0/21 via 10.0.8.8
R8 10.0.11.0/24 via 10.0.11.0/24
10.0.12.0/24 via 10.0.8.12
10.0.16.0/21 via 10.0.1.16
R16 10.0.21.0/24 via 10.0.16.21
10.0.22.0/24 via 10.0.16.22
10.0.16.0/21 via 10.0.1.8
R21 10.0.22.0/24 via 10.0.16.22
10.0.8.0/21 via 10.0.16.16
R22 10.0.21.0/24 via 10.0.16.21
10.0.21.0/24 via 10.0.16.16
Le masque correspondant au préfixe /21 est 255.255.248.0. Les interfaces du réseau 10.0.1.0/24 ne sont pas
joignables mais cela ne faisait pas partie du cahier des charges.
Vous venez du chapitre Le routage, initiation Sousréseaux et surréseaux.

Prise en main de l’outil de simulation Packet Tracer
1. Exemple : observation des trafics de diffusion à l’aide de Packet Tracer
CISCO met à disposition des étudiants engagés dans ses différents cursus de certification professionnelle un outil de
simulation absolument merveilleux nommé Packet Tracer. La version 4 était déjà très aboutie et au moment où ces
lignes sont écrites, la version 5.3.1 est disponible depuis peu.
Packet Tracer est un outil de simulation d’équipements CISCO. À partir d’une bibliothèque d’équipements
conséquente (commutateurs, routeurs…), l’utilisateur configure et assemble les équipements choisis afin de
constituer son interréseau. Il lui est ensuite possible de visualiser le fonctionnement de l’interréseau, soit en temps
réel, soit pas à pas. L’analyse de protocole est incluse dans l’outil de simulation et se révèle très pédagogue
puisqu’elle va jusqu’à justifier chaque couche d’un paquet.
Il est possible de maquetter un réseau existant en récupérant les fichiers de configuration des équipements réels
pour ensuite les « injecter » dans les équipements virtuels. Packet Tracer peut donc aider à comprendre le
fonctionnement d’un réseau existant voire servir d’outil de mise au point.
Packet Tracer décuple les possibilités d’apprentissage de l’étudiant :
● Avec du matériel réel, les possibilités du centre de formation sont toujours limitées et il est impossible de
mettre à disposition de chaque étudiant 5 ou 6 routeurs, autant de commutateurs, des PC, des analyseurs de
protocole, de la connectique… Le parc de matériel est ce qu’il est, obligeant l’instructeur à planifier l’utilisation
de ressources nécessairement mutualisées.
● L’outil de simulation permet de dématérialiser les équipements mais aussi le lieu de formation, il devient
possible de pratiquer à domicile.
● L’instructeur peut préparer des « mises en scène » (fichier *.pkt) que l’étudiant fera « rejouer » par l’outil au
moment opportun de l’apprentissage.
Naturellement, il ne s’agit pas d’oblitérer le nécessaire passage sur du matériel réel même si le souci des concepteurs
de Packet Tracer a été de s’approcher au plus près de la réalité (il faut mettre un équipement virtuel « hors tension »
avant de pouvoir y ajouter une carte !). Mais au final, voilà un outil d’aide pédagogique extraordinaire et on ne peut
que saluer l’effort accompli.
■ Si ce n’est déjà fait, ouvrez une session sur le site de l’académie afin de récupérer l’outil de simulation version 5 ou
ultérieure :
■ Si ce n’est déjà fait, installez l’outil de simulation sur votre PC.
■ Sur le site ENI, récupérez les fichiers de cet atelier de prise en main : TP1_7a.pkt et TP1_7b.pkt.
■ Démarrez l’outil et avec lui, ouvrez le fichier TP1_7a.pkt. Voici l’interréseau correspondant :

Cet interréseau a été conçu dans l’idée de pouvoir être réutilisé de nombreuses fois pendant le cursus. On peut
imaginer un site « Nord » et un site « Sud » reliés par une liaison urbaine à haut débit, liaison secourue par une
liaison WAN beaucoup plus lente.
■ Cliquez sur PC11.
■ Dans l’onglet Desktop de la fenêtre PC11, cliquez sur Command Prompt.
■ Ping du routeur 11 : tapez la commande ping 10.0.11.1.
■ Ping du routeur 12 : tapez la commande ping 10.0.8.12.
■ Ping du PC12 : tapez la commande ping 10.0.12.2.
Les trois commandes doivent aboutir. En effet, le protocole de routage RIP est activé sur chacun des routeurs. À
l’aide de ce protocole, les routeurs échangent de façon régulière des informations de routage et disposent donc
d’une table de routage à jour. On se propose de tester à nouveau une commande ping mais cette fois en mode
simulation.
■ En bas et à droite de la fenêtre Packet Tracer, cliquez sur l’onglet Simulation :

Pour ce TP, seuls les évènements ICMP (la commande ping) et RIP (le protocole de routage activé sur les routeurs)
nous intéressent. Il est possible d’ajuster le filtre de l’analyseur de protocole (l’analyseur intégré à l’outil de
simulation) afin de ne conserver que ces évènements…
■ En bas et à droite de la fenêtre Packet Tracer, cliquez sur le bouton Edit Filters puis cochez les cases ICMP et
RIP :
La fonction Add Complex PDU de l’outil de simulation offre une seconde manière de générer une commande ping…
■ Dans la barre d’outils à droite de la fenêtre Packet Tracer, cliquez sur le bouton Add Simple PDU. Le curseur de la
souris change et devient un symbole plus associé à une petite enveloppe.
■ Cliquez sur l’objet de l’interréseau qui doit être l’émetteur de la commande ping. Une enveloppe reste en attente
sur l’objet. Dans le cas présent, choisissez PC11.
■ Cliquez sur l’objet destinataire de la commande ping. Dans le cas présent, choisissez PC12. L’enveloppe en
attente sur l’émetteur adopte une couleur. Chaque message de la fenêtre Event List qui concerne ce futur
échange ping en préparation adoptera la même couleur :
Observez également l’œ il de la fenêtre Event List, il rappelle quel est l’évènement attaché à l’enveloppe.
■ Cliquez à plusieurs reprises sur le bouton Capture/Forward. Observez la progression de la requête d’écho jusque
PC12 puis de la réponse d’écho jusque PC11. Arrêtez quand la réponse d’écho atteint PC11. Puisque la
commande ping a abouti, l’enveloppe se pare alors d’une coche :

■ Dans la section Event List, cliquez successivement sur chaque case de couleur afin de provoquer l’analyse de
l’évènement correspondant.
■ Observez à chaque fois le décodage de la couche 3 et notamment l’adresse IP de destination : il s’agit à l’aller de
l’adresse de PC12 et au retour, de l’adresse de PC11.
Vous venez de provoquer, observer et analyser un trafic monodiffusion.
■ Afin de repartir d’une capture vierge, cliquez sur le bouton Reset Simulation.
Puisque le protocole RIP est activé sur l’ensemble des routeurs, chaque routeur prépare de façon régulière des
paquets contenant les routes qu’il connaît, un paquet par interface. Le routeur R11 dispose de deux interfaces
actives et donc, sa mise à jour RIP se traduit par la préparation de deux paquets.
■ Cliquez à plusieurs reprises sur le bouton Capture/Forward jusqu’à voir apparaître deux enveloppes sur le
routeur R11.
■ Cliquez une fois sur le bouton Capture/Forward et observez la réaction de PC11, sa couche 4 n’a pas de service à
l’écoute de RIP et le paquet est donc rejeté.
■ Cliquez à nouveau sur le bouton Capture/Forward et observez la réaction des routeurs R8 et R12. La couche
application RIP de chacun de ces routeurs accepte le paquet et profite des informations de route qui y sont
contenues :

■ Dans la section Event List, cliquez successivement sur chaque case de couleur afin d’afficher l’analyse de
■ Observez à chaque fois le décodage des couches 2 et 3. Observez en couche 3, l’adresse IP de destination qui est
l’adresse de diffusion limitée soit 255.255.255.255. Observez ensuite en couche 2 l’adresse MAC correspondante
de destination qui est l’adresse de diffusion FFFF.FFFF.FFFF.
Vous venez d’observer et analyser un trafic de diffusion. Il reste à observer un trafic de multidiffusion. Un moyen
simple consiste à modifier la version de RIP utilisée par les routeurs pour passer à la version 2. En effet, cette version
du protocole de routage envoie les mises à jour de routage dans des paquets en multidiffusion vers l’adresse dédiée
224.0.0.9.
■ Toujours dans l’outil de simulation Packet Tracer, ouvrez le fichier TP1_7b.pkt. L’interréseau n’a pas changé mais
la configuration de chaque routeur a été modifiée afin de passer à RIP version 2.
■ En bas et à droite de la fenêtre Packet Tracer, cliquez sur l’onglet Simulation.
■ En bas et à droite de la fenêtre Packet Tracer, cliquez sur le bouton Edit Filters puis cochez les cases ICMP et
RIP.
■ Cliquez à plusieurs reprises sur le bouton Capture/Forward jusqu’à voir apparaître deux enveloppes sur le
routeur R11.
■ Cliquez une fois sur le bouton Capture/Forward et observez la réaction de PC11.

■ Cliquez à nouveau sur le bouton Capture/Forward et observez la réaction des routeurs R8 et R12. La couche
application RIP de chacun de ces routeurs accepte le paquet et profite des informations de route qui y sont
contenues.
■ Dans la section Event List, cliquez successivement sur chaque case de couleur afin d’afficher l’analyse de
■ Observez à chaque fois le décodage des couches 2 et 3. Observez en couche 3, l’adresse IP de destination qui est
l’adresse de multidiffusion dédiée à RIP V2 soit 224.0.0.9. Observez ensuite en couche 2 l’adresse MAC
correspondante de destination qui est l’adresse de multidiffusion 0100.5E00.0009.
Au niveau de PC11, avec RIP, le paquet n’avait été rejeté qu’à la couche 4 car cette couche n’avait pas de service à
l’écoute de RIP. Avec RIP version 2, le paquet est rejeté au niveau de la couche 3 car l’adresse IP de destination de
ce paquet n’est ni l’adresse IP de PC11, ni l’adresse IP de diffusion. La multidiffusion a effectivement permis
d’économiser quelques ressources.

Liaisons série synchrone/asynchrone
La jonction RS 232 est en train de disparaître des interfaces du PC, le bus USB est passé par là. Les notions qui suivent
sont donc en cours d’obsolescence. Il subsiste pourtant une jonction sur tout équipement réseau qui permet d’effectuer
la première configuration ou qui permet de reprendre la main dans les cas de dysfonctionnements les plus graves.
Hélas, pour en profiter, il va dorénavant falloir s’équiper d’un convertisseur USB/RS 232.
1. Contexte
L’interface entre ETTD et ETCD, appelée jonction, doit permettre la gestion par l’ETTD du déroulement d’une
communication. La séquence comprend généralement quatre phases :
1. Établissement d’un circuit entre les deux correspondants
● S’il s’agit d’une ligne louée, cette phase se limite à la connexion.
● S’il s’agit d’un réseau commuté (RTC ou RNIS), cette phase comprend la numérotation suivie de la connexion.
2. Initialisation de la transmission
● Dans le cas d’une ligne analogique, elle permet aux modems de s’adapter à la ligne ; elle comprend alors
l’émission en ligne de la porteuse, sa détection à l’autre extrémité (CAG : contrôle automatique de gain,
apprentissage de l’égaliseur et de l’annuleur d’écho autoadaptatifs), la reconstitution de la porteuse locale...
3. Transmission
● Phase durant laquelle les informations utiles sont effectivement échangées.
4. Libération de la liaison
● Cette phase termine la communication une fois la transmission achevée et libère le circuit.
Cet enchaînement nécessite un dialogue entre l’ETTD (donne les ordres) et l’ETCD (exécute et rend compte), dialogue
opéré via la jonction. La standardisation de la jonction recouvre trois familles de caractéristiques :
1. Les caractéristiques fonctionnelles définissent la nature et la fonction des informations échangées.
2. Les caractéristiques électriques concernent les spécifications (tension, courant, impédance...) des circuits émetteurs
et récepteurs de signaux ainsi que les tolérances associées.
3. Les caractéristiques mécaniques définissent le connecteur utilisé ainsi que l’affectation des signaux aux broches de
la prise.
Les organismes de normalisation impliqués dans la standardisation de la jonction sont l’EIA (Electronic Industrie
Association), l’UITT et l’ISO. L’EIA fournit des recommandations « RS » (Recommended Standard) traitant des trois
aspects, électriques, fonctionnels et mécaniques, l’UITT offre des recommandations distinctes pour les aspects
électriques et fonctionnels, l’ISO quant à elle, ne traite que de l’aspect mécanique. Les recommandations de l’UITT
relatives aux jonctions se trouvent dans la série V (transmission de données sur lignes téléphoniques) ou dans la
série X (réseaux publics de données).
Le tableau cidessous distingue le partage des caractéristiques pour la jonction la plus ancienne et la plus utilisée,
c’estàdire la jonction RS 232 (pour l’EIA) ou V24/V28 (pour l’UIT) :
EIA UITT ISO

Électrique RS232D V28
Fonctionnel création : 1962 V24
Mécanique RS232C : 1969 DP2110

dernière révision : 1987
2. Transmission synchrone
L’ouvrage Cisco Notions de base sur les réseaux dans la collection Certifications aux Editions ENI introduisait la
notion de signal numérique : le signal numérique qui intéresse l’expert réseau est un signal synchrone, c’estàdire
dont les intervalles de temps alloués à chaque symbole sont égaux (au moins du côté de l’émetteur) et correspondent
aux périodes successives d’un signal périodique fourni par « l’horloge » ou la « base de temps » :
Ceci revient à dire que la suite numérique a été composée du côté émetteur en séquençant les symboles à l’aide de
l’horloge. Le signal numérique ainsi créé est composite : certes il contient l’information mais il contient également
l’horloge dans ses transitions. L’espace qui sépare deux transitions est toujours multiple de la période de cette
horloge. Du côté du récepteur, le flux numérique arrive sans être accompagné du signal Horloge. Et pourtant, ce flux
n’est compréhensible qu’à condition de disposer de cette base de temps afin de « lire » l’état du symbole au moment
le plus favorable c’estàdire au milieu d’une période.
La première tâche du récepteur n’est donc pas de lire le flux mais bien de reconstituer la base de temps qui a servi à
l’émetteur pour cadencer ce flux. On parle d’extraction d’horloge et il va de soi que le circuit d’extraction ne fonctionne
convenablement que si le flux de symboles comporte suffisamment de transitions. Du côté émetteur, le souci doit donc
être de composer un flux numérique présentant des transitions réparties de façon régulière.
Dans une transmission synchrone, le temps qui sépare deux transitions quelconques est toujours multiple du
temps élémentaire.
3. Transmission asynchrone
Dans une transmission asynchrone, l’émetteur transmet une succession de trains synchrones, chaque train représente
un caractère, l’espace qui sépare deux caractères est quelconque :

Dans ces conditions, comment le récepteur parvientil à reconstituer les caractères ?
Il faut bien sûr que le récepteur échantillonne les bits au moment le plus favorable, c’estàdire au milieu de chaque
temps bit. Mais plutôt que d’utiliser une horloge extraite du flux reçu, le récepteur utilise une horloge locale. L’idée est
de resynchroniser cette horloge au début de chaque train synchrone puis d’espérer que sur le dernier bit du train,
cette horloge ne soit pas suffisamment décalée pour provoquer une erreur. Pour ce faire, le premier bit d’un train
synchrone n’est pas un bit d’information, il s’agit du bit de START. Ce bit est systématiquement précédé d’un état
repos et c’est ce passage de l’état repos à l’état travail que recherche en permanence le récepteur. Dès que cette
transition se présente, le récepteur resynchronise son horloge puis échantillonne chaque bit du caractère reçu. Afin
d’être sûr que le bit de START est effectivement précédé par un état repos, l’émetteur ajoute au minimum un bit à
l’état repos à la fin de tout caractère (parfois un bit et demi voire deux bits). Ce ou ces bits sont appelés bits de STOP.
Il faut bien comprendre que ce ne sont pas les bits de START et STOP qui sont importants mais le fait que leur
succession entraîne une transition toujours dans le même sens repos → travail détectable par le récepteur et
comprise comme le début d’un caractère.
Hélas, cette transition, si elle permet bien au récepteur de détecter le début d’un caractère, ne lui permet pas de
préjuger quel est le débit, c’estàdire quelle est l’horloge choisie par l’émetteur. De la même façon, chaque caractère
est exprimé sur un certain nombre de bits, généralement 7 ou 8, dans un code qui le plus souvent est l’ASCII mais
dont le choix du côté émetteur doit également être connu par le récepteur. Enfin, les bits de caractère peuvent être
suivis ou pas par un bit de parité dans le but de constituer un premier niveau de détection d’erreur. Et quand on
choisit de le mettre en œ uvre, il faut encore choisir parmi parité paire (le bit de parité adopte la valeur qui convient de
façon à ce que le nombre de bits à 1 dans le caractère soit pair) ou impaire (le bit de parité adopte la valeur qui
convient de façon à ce que le nombre de bits à 1 dans le caractère soit impair). En final, si la transition repos → travail
d’une transmission asynchrone permet de se passer d’une coûteuse extraction d’horloge, elle impose de régler le
récepteur à l’identique avec les choix opérés côté émetteur.
Exemple de réglage :
9600S81, code ASCII
Il est fréquent de rencontrer cette façon abrégée de noter les réglages d’une liaison asynchrone.
● 9600 rappelle le débit choisi, soit 9600 bits/s. Les débits possibles appartiennent à l’ensemble {150, 300, 600,
1200, 2400, 4800, 9600, 14400, 19200, 38400, 57600, 115200}. Sans rapport avec le choix d’une
transmission asynchrone, le débit maximal prévu par le standard RS 232 est 19200 bps. Il est rare qu’une
jonction supporte des débits audelà de 115200 bps.
● La lettre « S » rappelle le choix opéré pour le bit de parité, dans le cas présent « Sans parité ». Les autres
choix sont « P » pour parité paire, « I » pour parité impaire, forcé à 0, forcé à 1. En anglais, les trois lettres « S
», « P » et « I » deviennent respectivement « N » pour « No parity », « E » pour « Even » qui signifie pair et «
O » pour « Odd » qui signifie impair. Un moyen mnémotechnique consiste à observer que « Even » comporte
quatre lettres tandis que « Odd » n’en comporte que trois. L’état « forcé à 0 » est noté « space » tandis que
l’état « forcé à 1 » est noté « mark ». L’auteur vous livre cet autre moyen mnémotechnique : « Un invité de
marque ».
● « 8 » signifie que chaque caractère est exprimé sur 8 bits. Les choix possibles sont « 7 » et « 8 ».

● « 1 » rappelle enfin de nombre de bits de STOP que l’émetteur doit ajouter à la fin de chaque caractère émis.
Les choix possibles sont « 1 », « 1,5 » ou « 2 » bits de STOP.
S’il faut comparer transmission synchrone et asynchrone, l’efficacité est l’apanage de la liaison synchrone. En effet,
chaque caractère d’une transmission asynchrone est encadré par deux bits qui ne sont pas des bits d’information et
c’est ainsi 20 % (8 bits de donnée, un START, un STOP, 8 bits utiles sur 10) voire 30 % (7 bits de donnée, un START, un
STOP) de la bande passante consommée pour assurer la synchronisation bit.
4. Aspects fonctionnels, la recommandation V24
La philosophie qui soustend la recommandation V24 consiste à matérialiser chaque commande ou signalisation par un
circuit physique distinct. Ces circuits se répartissent en deux groupes :
● Le groupe de la série 100 concerne l’utilisation générale et comporte 39 circuits.
● Le groupe de la série 200 réservé à l’appel automatique en comporte 13.
Les chiffres du numéro du correspondant étaient successivement présentés en BCD sur les circuits 206 à 209. Il
s’agissait donc d’une transmission en mode parallèle. La série est devenue désuète dès qu’un constructeur proposa
un moyen astucieux de numéroter en utilisant les circuits de la série 100 (HAYES et ses commandes « AT »).
Restent les circuits de la série 100. Tous véhiculent des informations binaires. En pratique, une partie seulement des
circuits d’interfaces figurant dans la recommandation V24 est utilisée à la fois. On peut classer les circuits de multiples
manières :
1. Selon la phase de communication où ils sont utilisés :
● Établissement de la liaison, initialisation, transmission, libération.
2. Selon les catégories suivantes :
● Données, horloges, commandes, masses.
Parmi les 39 circuits de la série 100, maîtriser la jonction nécessite de connaître l’usage des douze circuits décrits ci
après.
a. Les douze circuits essentiels
La figure cidessous représente le schéma synoptique d’un modem :

Imaginons que l’ETTD relié à l’ETCD cidessus désire établir une communication avec un correspondant et observons
les événements durant les quatre phases : établissement initialisation, transmission et libération.
Les deux circuits 108 et 107 sont utilisés lors de la phase d’établissement de la liaison :
1. Le terminal fait monter CPD (Connecter poste de données, ce qui signifie littéralement connectez le modem sur la
ligne).
2. L’ETCD répond par le circuit 107 (PDP, Poste de Données Prêt) qu’il a pris la ligne (l’indication contraire signifie que
la ligne est connectée au poste téléphonique).
La phase établissement est maintenant terminée (on passe sous silence la numérotation sur RTC). La phase
initialisation peut commencer.
3. Pour ce faire, le terminal fait monter le circuit 105 (DPE : Demande Pour Emettre)... Ceci oblige le modem à se
mettre en position émission puis à transmettre sa porteuse afin que le modem distant puisse entamer sa phase
d’initialisation (on suppose que lui aussi a terminé la phase établissement et que le circuit est établi). Le cas
échéant, outre la porteuse, le modem émet la séquence de signaux d’initialisation nécessaire à la synchronisation du
modem distant. L’effet le plus visible de l’envoi de la porteuse sur le modem distant, le symptôme pour l’utilisateur
côté distant, est la montée du circuit 109 (DP : Détection de Porteuse).
4. La commande 105 (DPE) provoque également le lancement d’une temporisation sur le modem local. Cette
temporisation, appelée « Délai DPE/PAE » doit être suffisante pour que le modem distant puisse achever sa phase
d’initialisation avant de recevoir les données utiles proprement dites.
5. Pour que cette condition soit réalisée, le terminal local ne peut émettre ses données qu’après la montée du circuit
106 (PAE : Prêt A Emettre), événement qui se produit lorsque la temporisation est achevée...
La phase d’initialisation est maintenant terminée et la phase de transmission peut démarrer.
Le terminal émet ses données par le circuit 103 (ED : Emission de Données). Il s’agit d’une transmission série. Une
transmission série peut s’opérer suivant deux modes différents :
● mode de transmission synchrone
● mode de transmission asynchrone
Réglons d’abord le cas le plus simple pour ce qui est de la jonction, c’estàdire le mode de transmission asynchrone.
Dans ce mode, chaque caractère est séquencé individuellement et un dispositif qui reçoit un caractère asynchrone
resynchronise son horloge à l’aide du bit de START. Dans ces conditions, le circuit 103 (ED) se suffit à luimême et les
circuits 113 (HET) et 114 (HEM) restent inutilisés.
Dans le mode de transmission synchrone, les données ne sont compréhensibles qu’à l’aide de l’horloge qui a servi à

les séquencer. Le technicien qui configure une liaison doit souvent opérer un choix : à qui confier la fourniture de
l’horloge ?
● au terminal : dans ce cas la jonction doit comporter le circuit 113 (HET : Horloge Emission Terminal). Le
terminal séquence les données émises à l’aide de son horloge interne et transmet ces données sur le circuit
103 ainsi que l’horloge qui permettra de les exploiter sur le circuit 113. Le modem reçoit les données sur le
circuit 103 et les comprend à l’aide de l’horloge qu’il reçoit sur le circuit 113. En final, dans cette situation, le
terminal a été configuré en « horloge interne » tandis que le modem a été configuré en « horloge externe ».
● au modem : dans ce cas, la jonction doit comporter le circuit 114 (HEM : Horloge Emission Modem). Le terminal
séquence les données émises à l’aide de l’horloge modem qu’il reçoit sur le circuit 114 et transmet ces
données sur le circuit 103. Le modem reçoit les données sur le circuit 103 et les comprend à l’aide de sa
propre horloge. En final, dans cette situation, le terminal a été configuré en horloge externe tandis que le
modem a été configuré en horloge interne.
Ainsi dans le mode synchrone, le circuit 103 n’est « compréhensible » qu’à l’aide du circuit 113 ou du circuit 114 selon
la configuration qui a été choisie. C’est pourquoi sur les figures représentant la jonction, les trois circuits 103, 113 et
114 sont voisins.
Il faut noter que le mode de transmission synchrone ne concerne pas le PC car les ports série dont il dispose
nativement sont des ports asynchrones (à moins évidemment d’avoir équipé le PC de cartes spéciales synchrones).
Du côté distant, les données reçues sont mises à disposition du terminal sur le circuit 104 (RD : Réception des
Données). À nouveau se pose la question : mode synchrone ou asynchrone ?
En mode asynchrone, le circuit 104 se suffit à luimême. En mode synchrone, l’une des tâches du modem consiste à
extraire du signal reçu en ligne, l’horloge qui a servi à séquencer les données du côté émission. Cette horloge
extraite est mise à disposition du terminal distant sur le circuit 115 (HRM : Horloge Réception Modem) de la jonction
distante. Ainsi dans le mode synchrone, le circuit 104 n’est « compréhensible » qu’à l’aide du circuit 115. C’est
pourquoi sur les figures représentant la jonction, les deux circuits 104 et 115 sont voisins.
Pour en terminer avec les circuits 103 et 104, notons qu’en dehors des périodes de transmission, ces circuits sont
maintenus à l’état 1 (l’état 1 est donc l’état de repos).
Imaginons que la phase de transmission soit achevée. Deux cas sont à envisager :
1. Il s’agit d’un état « je n’ai rien à dire pour le moment ». L’ETTD peut alors faire retomber le circuit 105 (DPE), ce
n’est pas systématique. Il n’y est en effet obligé que dans le cas où le support physique de la transmission (la ligne)
est partagé par plusieurs ETTD. Dans ce cas, faire retomber le circuit 105 équivaut à « laisser la parole aux autres »,
c’estàdire à permettre à un autre ETTD qui désire transmettre de le faire après avoir monté son propre circuit 105.
Dans le cas contraire où le support de transmission est à l’usage exclusif d’un ETTD, celuici peut laisser le circuit 105
monté. Ainsi, chaque fois qu’il souhaite transmettre, il peut le faire sans attendre l’écoulement de la temporisation
105/106 (le circuit 105 restant monté, le circuit 106 (PAE) le reste également).
2. Il s’agit d’un état définitif de fin de transmission. L’ETTD fait alors retomber les circuits 105 et 108, ce qui équivaut
à « raccrocher ». La ligne est alors libérée et les ETCD sont dans un état de repos.
b. Affectation des broches
Circuit N° broche N° broche (9 Abréviation UITT Abréviation EIA ETTD

UITT (25 pts) pts) ETCD
101 1 TP PG
102 7 5 TS SG
103 2 3 ED TD (Transmitted Data) →
104 3 2 RD RD (Received Data) ←
105 4 7 DPE RTS (Request To Send) →
106 5 8 PAE CTS (Clear To Send) ←
107 6 6 PDP DSR (Data Set Ready) ←
108/1 20 4 CPD DTR (DTE Ready) →

108/2 20 4 TDP DTR →
109 8 1 DP CD ←
110 21 QS SQD ←
111 23 SDT/SDM RS ↔
113 24 HET TSTE (Transmitter Signal →

Timing DTE Source)
114 15 HEM TST (Transmitter Signal ←

Timing DCE Source)
115 17 HRM RCT (Receiver Signal ←

Timing DCE Source)
116/1 14 Passage en secours (LS sur RC) provoqué par le →

terminal
116/2 14 Passage en secours (LS sur RC) à l’initiative du →

modem
117 16 Indicateur de passage en secours ←
125 22 9 IA RI ←
140 21 Commande de boucle 2 distante →
141 18 Commande de boucle 3 →
142 25 IT TI ←
Le connecteur normalement utilisé pour une interconnexion de type V28 correspond à la norme ISO 2110,
connecteur couramment désigné par « CANNON 25 points » ou « SUB D 25 points » (SUB : subminiature, D parce que
la forme du connecteur rappelle la lettre D) ou « DB25 », la lettre « B » rappelant la taille du connecteur.
La firme IBM n’a pas intégré la totalité de la spécification V24 sur ses PC. Les ports série de cette machine ne
permettaient la communication qu’en mode asynchrone. C’est pourquoi les circuits d’horloge (HEM, HET, HRM) étaient
inutiles et il fut possible d’intégrer l’ensemble des circuits restants sur un port à 9 broches, le connecteur adopté
étant alors le « CANNON 9 points » ou « DE9 ».
La seule certitude est la suivante :
Sur la machine PC qui en dispose encore, le port série est identifiable par son connecteur DE9 mâle.
5. Aspects électriques, la recommandation V28
Le fonctionnement électrique prévu par V28 est rudimentaire. L’interface est asymétrique (unbalanced) avec un
conducteur par circuit et un retour commun pour tous les signaux quelle que soit leur direction ETTD vers ETCD ou
ETCD vers ETTD. De plus, les lignes ne sont pas adaptées en impédance. Enfin, chaque circuit chemine au voisinage de
tous les autres circuits qui composent la jonction et la diaphonie est importante. De fait, les performances sont très
limitées à la fois en débit (20 Kbits/s) et distance (15 mètres) :

a. Performances demandées à l’émetteur V28
Courtcircuit de sortie. La sortie doit pouvoir supporter un courtcircuit à la

masse de l’alimentation, ou à tout conducteur du
câble d’interface. Le courant de sortie doit rester
inférieur à 500 mA.
Résistance de la sortie en l’absence d’alimentation. > 300 Ω
Tension de sortie maximale en circuit ouvert. ± 25 V
Tension de commande de la sortie pour une charge de > 5 V et < 15 V

3000 Ω à 7000 Ω.
Vitesse de transition de sortie (slewrate). 30 V/µs
Temps de montée et de descente de la sortie dans les La plus faible des deux valeurs suivantes :
limites de transition de 3V et 3V. ≤ 1 ms ou ≤ 3 % de la durée du temps bit.
Vitesse maximale des données. 20000 bits/s
b. Performances demandées au récepteur V28
Résistance d’entrée. Comprise entre 3000 et 7000 Ω
Charge capacitive à l’entrée, câble compris. < 2500 pF
Limites de la tension d’entrée. ± 25 V
Tension d’entrée en circuit ouvert. <2V
Vitesse maximale des données. 20000 bits/s
c. V28 : ce qu’il faut en retenir
L’administrateur peut ajouter le tableau suivant au précieux calepin dans lequel il consigne les savoirfaire
importants :

Si les commandes sont exprimées en logique positive (un +V correspond à une commande ON), les données elles,
sont exprimées en logique négative (un état « 1 » est exprimé à l’aide d’une tension V).
6. Un exemple de transmission asynchrone RS 232
Un oscilloscope numérique à mémoire a été placé sur l’un des deux circuits ED ou RD. La séquence capturée
correspond au caractère « A ». L’émetteur est réglé sur 110P71 (110 bits par seconde, caractère exprimé sur 7 bits,
parité paire, 1 bit de STOP). Pour mémoire, le code ASCII du caractère « A » est 0x41, soit la séquence binaire 100
0001.
7. Contrôle de flux via une liaison série RS 232

a. Contrôle de flux matériel
L’exemple de l’imprimante se prête particulièrement bien à l’explication qui suit mais tout périphérique peut être
concerné dès lors qu’il dispose d’un tampon de mémoire susceptible de se remplir plus vite qu’il ne se vide.
Imaginons donc une imprimante reliée à un PC via un port série asynchrone. Premier problème : aton affaire à un
ETTD ou un ETCD ? Si la documentation n’a pas permis de le découvrir, il reste la solution de connecter au port série
de l’imprimante une jonction éclatée puis de vérifier quel est le circuit générateur (au sens électrique) parmi les deux
circuits ED et RD. Si le voyant de test s’allume sur le circuit ED, alors il doit rester éteint sur le circuit RD et le
périphérique est ETTD. Si c’est le voyant de test associé au circuit RD qui s’illumine, celui associé au circuit ED doit
rester éteint et le périphérique se comporte comme un ETCD sur la jonction.
Dans l’exemple objet de l’illustration cidessus, les données à imprimer parviennent via le circuit RD qui est donc une
entrée pour le périphérique (un récepteur au sens électrique). L’imprimante est ETTD sur sa jonction.
Une imprimante est nécessairement un périphérique lent, ce qui signifie que le débit des données du PC vers le
périphérique d’impression peut être supérieur, voire très supérieur au débit des données vers la tête d’impression.
C’est pourquoi toute imprimante est dotée d’un tampon de mémoire qui reçoit en entrée les données à imprimer et
envoie en sortie les données vers la tête d’impression. Le tampon peut contenir, selon les capacités de l’imprimante,
plusieurs lignes, plusieurs pages voire plusieurs documents en attente d’impression. Quoi qu’il en soit, la capacité de
ce tampon est finie et pas question d’admettre qu’il se remplisse à 100 % puisque cela entraînerait des caractères
perdus et une impression erronée. La solution consiste à mettre en œ uvre un contrôle de flux c’estàdire le moyen
pour le puits (dans le cas présent le tampon) d’asservir la source (dans le cas présent le PC). Parvenu par exemple à
80 % du remplissage maximal, le tampon demande à l’émetteur de cesser son émission. Le tampon peut alors se
vider vers la tête d’impression. Parvenu à 20 % de remplissage, le tampon fait savoir à l’émetteur que l’émission
peut reprendre.
Deux choix s’offrent à l’administrateur chargé de mettre en place un tel contrôle de flux : le contrôle de flux matériel
et le contrôle de flux logiciel. Avec le contrôle de flux matériel, l’idée est de résumer l’état de l’imprimante prête ou
pas prête, c’est donc un état logique, binaire, sur l’un des circuits de la jonction. Ordinairement, dans le cas d’une
imprimante équipée d’une jonction type ETTD, on confie ce rôle au circuit DPE (RTS, broche 4 sur le DB25) ou au
circuit CDP (DTR, broche 20 sur le DB25). Quelques constructeurs vont jusqu’à proposer des imprimantes pour
lesquelles le choix de ce circuit fait l’objet d’une configuration. Si l’administrateur ignore quel est le bon circuit, il lui
reste à le découvrir à l’aide d’une jonction éclatée placée sur le port série de l’imprimante. Ensuite, chaque appui sur
le bouton « OnLine/OffLine » de l’imprimante provoque le changement d’état du voyant associé au circuit recherché.
Une fois le circuit connu, il reste à le relier à l’un des circuits de la jonction du PC, circuit auquel est « sensible » le
logiciel chargé d’envoyer les documents à imprimer sur le port série. La jonction du PC est ETTD, le circuit est
nécessairement une entrée, ce peut être le circuit PAE (CTS, broche 5 sur le DB25) ou le circuit PDP (DSR, broche 6
sur le DB25).
En final, la liaison que doit construire l’administrateur pourrait ressembler à la suivante :

Bien sûr, les appellations des circuits DPE/PAE (RTS/CTS) ou CPD/PDP (DTR/DSR) n’ont de signification que dans le
contexte d’une transmission via modems et il faut se souvenir qu’en fait le circuit établi de la broche 20 côté
imprimante à la broche 5 côté PC reflète l’état de l’imprimante prête ou pas à imprimer les données.
b. Contrôle de flux logiciel

Vous avez trouvé le contrôle de flux matériel particulièrement indigeste ! Alors le contrôle de flux logiciel devrait vous
convenir. Plutôt que de rechercher avec difficultés quel est le circuit qui représente le remplissage du tampon côté
récepteur puis quel est le circuit qui permettra d’asservir l’émetteur, il s’agit de construire une liaison bidirectionnelle
simultanée (full duplex) puis de provoquer l’envoi de caractères de commande qui traduiront l’état de l’imprimante.
On se souvient (voir table ASCII ciaprès) que les deux premières colonnes de la table du code ASCII sont des
caractères de contrôle. Ces caractères sont dits non visualisables car lorsqu’ils sont reçus par un équipement, celuici
ne les affiche pas mais les interprète comme des commandes.
Parmi ces 32 caractères, les caractères DC1 à DC4 (DC = Device Control) sont dédiés à la gestion de périphériques
connectés. Il a été décidé d’affecter deux de ces caractères au contrôle de flux logiciel, ce sont le caractère DC1
(0x11) devenu XON (« Transmit ON » = Reprendre le flux) et le caractère DC3 (0x13) devenu XOFF (« Transmit Off » =
Suspendre le flux). Parvenue par exemple à 80 % de remplissage de son tampon, l’imprimante génère un ou
plusieurs caractères XOFF. Le logiciel émetteur cesse l’envoi de données à imprimer ce qui permet au tampon de se
vider vers la tête d’impression. Parvenue à 20 % de remplissage, l’imprimante génère un ou plusieurs caractères
XON qui seront interprétés par le logiciel émetteur comme une autorisation d’émettre à nouveau.
La simplicité du cordon à réaliser entre les deux équipements se passe de commentaire :

c. Comparaison des contrôles de flux matériel et logiciel
Avantages Inconvénients
Contrôle de flux Le fournisseur de données est informé en La jonction à réaliser est plus complexe et
matériel permanence de l’état de l’imprimante. pas toujours symétrique (on ne peut pas
retourner le cordon réalisé pour faire la
jonction entre les deux équipements).
Contrôle de flux Le fournisseur de données n’est informé La jonction à réaliser est toujours simple
logiciel que des changements d’état de et symétrique (on peut retourner le cordon
l’imprimante. Cela suppose qu’il réalisé pour faire la jonction entre les deux
entretienne luimême une mémoire équipements).
reflétant cet état et qu’il soit « attentif »

lorsqu’il reçoit l’information de changement
d’état.
8. Le port série RS 232 et le PC
Présenté en 1981, le PC d’IBM est doté d’un port série asynchrone. IBM choisit le standard RS 232 et le débarrasse
des circuits d’horloge nécessaires à la réalisation d’une transmission synchrone. Jusqu’à la présentation de ses micro
ordinateurs PS/2, le seul moyen de communication bidirectionnel avec le monde extérieur intégré dans le PC et
reconnu officiellement par IBM est ce port de communication de données asynchrone. À l’origine, le port série est par
conséquent utilisé pour des périphériques qui doivent communiquer en mode bidirectionnel avec l’ordinateur. C’est le
cas pour des équipements aussi divers que :
● les modems ;
● les souris ;
● les scanners ;
● les tablettes à numériser ;
● les traceurs ;
● les imprimantes quand elles ne sont pas placées à proximité immédiate de l’ordinateur hôte, etc.
Parce que sur les douze circuits indispensables, il n’en reste que neuf une fois ôtés les trois circuits d’horloge, IBM a
pu, en 1983, présenter son PCAT doté d’un port série DE9 en lieu et place du DB25 de la norme RS 232, privilégiant
ainsi la compacité. Beaucoup d’équipements réseaux sont également dotés d’un port série destiné à permettre leur
configuration initiale : commutateurs, routeurs…
Le circuit électronique chargé de la conversion parallèle série est appelé UART (Universal Asynchronous
Receiver/Transmitter). IBM avait choisi d’équiper son PC/XT de la puce UART 8250. Ce circuit était loin de jouir d’une
haute considération. En effet, la puce était dépourvue de tampon d’émission/réception et s’avérait donc très lente. De
plus, il fallait déplorer plusieurs bogues mineurs dont un qui fut corrigé par le BIOS du PC/XT. Première machine 16
bits, le PC/AT était doté d’un circuit UART 16450 : ce circuit disposait d’un tampon d’émission/réception de 1 octet et
les bogues du 8250 étaient corrigés. À partir du PS/2, IBM choisit la puce UART 16550, beaucoup plus rapide car
équipée d’un tampon FIFO (« First In First Out » soit premier entré premier sorti) de 16 caractères. C’est ce circuit
qui a permis d’atteindre le débit 115200 bits/s sur le port série (sur des distances courtes bien sûr).
Les cartes mères des PC sont dorénavant équipées d’une puce de « super E/S » (Entrées/Sorties). Cette puce intègre
des circuits qui se présentaient auparavant sous forme de cartes d’extension distinctes. Par exemple, la puce de «
super E/S » référencée FDC37C777 de la firme SMC intègre un contrôleur de disquettes, deux contrôleurs de ports
série de type NS16550A, un contrôleur de port parallèle, un contrôleur de clavier et de souris.
Voici un exemple d’architecture de PC qui date déjà mais l’important est ailleurs :

La table ASCII
La table débute par 32 caractères de contrôle. Ces caractères sont dits non visualisables car lorsqu’ils sont reçus par un
équipement, celuici ne les affiche pas mais les interprète comme des commandes.
Sur les terminaux compatibles télétype (TTY), il est possible d’émettre un caractère des colonnes 0 et 1 par appui
simultané de la touche [Ctrl] et de la touche correspondant au caractère de même rang dans les colonnes 4 et 5. Ce
que rappelle la colonne key du tableau cidessous qui fait référence à la combinaison de touches adéquate.
La combinaison « 000 0000 » n’est pas associée à un caractère ni à une commande et n’a donc pas de signification
particulière. Ainsi, un système en réception connectée à une ligne au repos ne risque pas d’interpréter les « 0 » non
significatifs.
Les caractères TC1 à TC10 (TC = Transmission Control) ont été pendant un temps utilisés afin de définir des protocoles
de communication. Certains caractères, tels STX et ETX, servaient de délimiteurs aux blocs de données, d’autres, tels
ENQ ou ACK, servaient dans la procédure de dialogue. On peut citer le protocole BSC d’IBM (Binary Synchronous
Communications) annoncé en 1967. L’utilisation de caractères de commande pour créer un protocole génère deux types
de problèmes : 1> le protocole est lié au code, on ne peut faire évoluer l’un sans faire évoluer l’autre ; 2> si les
données comprises entre deux caractères d’encadrement comportent des séquences binaires susceptibles d’être
confondues avec des caractères de commande, il faudra faire précéder ces séquences par des caractères
d’échappement. C’est ce qu’on appelle le problème de la transparence au code.
Les caractères FE1 à FE5 (FE = Format Effector) sont dédiés à la mise en page de l’information, qu’il s’agisse d’une
imprimante ou d’un écran de terminal et comprennent le retour chariot, le changement de ligne, les tabulations
horizontale et verticale, le saut de page.
Les caractères DC1 à DC4 (DC = Device Control) sont dédiés à la gestion de périphériques connectés. Deux de ces
caractères sont célèbres puisqu’ils sont utilisés dans le contrôle de flux logiciel, ce sont les caractères XON (= Reprendre
le flux) et XOFF (= Suspendre le flux).
Les caractères IS1 à IS4 (IS = Information Separators) permettent de hiérarchiser l’information en fichiers, articles, sous
articles…
Enfin, il reste les caractères inclassables, tel le caractère BEL qui entraîne l’émission d’un signal audible par l’équipement
qui le reçoit.
Hex Dec Key Name Description
00 0 ^@ NUL Null
01 1 Â TC1/SOH Start of Header

02 2 ^B TC2/STX Start of Text
03 3 ^C TC3/ETX End of Text
04 4 ^D TC4/EOT End of Transmission
05 5 Ê TC5/ENQ Enquiry
06 6 ^F TC6/ACK Acknowledge
07 7 ^G BEL Bell
08 8 ^H FE0/BS Backspace
09 9 Î FE1/HT Horizontal Tab
0A 10 ^J FE2/LF ou NL Line Feed ou New Line*
0B 11 ^K FE3/VT Vertical Tab
0C 12 ^L FE4/FF Form Feed
0D 13 ^M FE5/CR Carriage Return
0E 14 ^N SO Shift Out
0F 15 Ô SI Shift In
10 16 ^P TC7/DLE Data Link Escape
11 17 ^Q DC1/XON Device Control 1
12 18 ^R DC2 Device Control 2
13 19 ^S DC3/XOFF Device Control 3
14 20 ^T DC4 Device Control 4
15 21 Û TC8/NAK Negative Acknowledge
16 22 ^V TC9/SYN SynchronousIdle
17 23 ^W TC10/ETB End Transmission Block
18 24 ^X CAN Cancel
19 25 ^Y EM End of Medium
1A 26 ^Z SUB Substitute
1B 27 ^[ ESC Escape
1C 28 ^\ IS4/FS File Separator
1D 29 ^] IS3/GS Group Separator
1E 30 ^^ IS2/RS Record Separator
1F 31 ^_ IS1/US Unit Separator

*Certains appareils ne comportent qu’une seule commande pour l’opération combinée de retour chariot et de saut de
ligne, la fonction FE2 prend alors la signification NL (New Line).

Numérotation des interfaces des routeurs de la série 2800
Dans le cas du routeur 2801, la numérotation s’établit ainsi :
Numéro de slot Type de slot Étendue de numérotation
Ports embarqués Fast Ethernet 0/0 et 0/1.
0 VIC/VWIC (voix seulement) De 0/0/0 à 0/0/3.
1 HWIC / WIC / VIC / VWIC (*) De 0/1/0 à 0/1/3 dans le cas d’un module HWIC
simple largeur.
De 0/1/0 à 0/1/7 dans le cas d’un module HWIC

double largeur.
2 WIC / VIC / VWIC (*) De 0/2/0 à 0/2/3.
3 HWIC / WIC / VIC / VWIC (*) De 0/3/0 à 0/3/3 dans le cas d’un module HWIC
simple largeur.
De 0/3/0 à 0/3/7 dans le cas d’un module HWIC

double largeur.
(*) Un module VWIC placé dans l’un des slots 1, 2 ou 3 peut fonctionner indifféremment dans les modes donnée et
voix. Ce même module placé dans le slot 0 ne peut fonctionner que dans le mode voix.
Dans le cas des routeurs 2811, 2821 et 2851, le nommage s’établit ainsi :
Emplacement du port Format de la numérotation Exemples
Embarqué, face avant. Interfacetype port usb 0

usb 1
Embarqué, face arrière. Interfacetype 0/port Interface fa 0/x
Interface gi 0/x
Sur une carte d’interface Interfacetype 0/slot/port interface serial 0/x/y

(HWIC, HWICD, WIC,
VWIC, VIC) installée interface async 0/x/y
directement dans un slot line 0/x/y
HWIC du châssis.
interface fa 0/x/y
voiceport 0/x/y
Sur une carte d’interface Interfacetype 1/slot/port controller t1 1/x/y

(WIC, VWIC, VIC)
installée dans un slot « 1 » identifie le module NM sur tous les voiceport 1/x/y
appartenant à un module routeurs de la série 2800.
interface serial 1/x/y
NM.
interface async 1/x/y
line 1/x/y
Embarqué directement Interfacetype 1/port interface gi 1/x

sur le module NM (NME,
NMEX, NMD, NMDXD). « 1 » identifie le module NM sur tous les interface serial 1/x
routeurs de la série 2800.
interface async 1/x
line 1/x
Port FXS ou FXO installé Interfacetype 2/0/port voiceport 2/0/x

sur un module EVM
(voix). « 2 » identifie le module EVM sur tous les
routeurs 2821 et 2851 (autres routeurs
non concernés).
FXS/DID, les ports 0 à 7 sont embarqués

directement sur le module EVM.
FXS/FX0, les ports 8 à 15 appartiennent

au module d’extension 0.
FXS/FX0, les ports 16 à 23 appartiennent
au module d’extension 1.
Le chiffre « 0 » au deuxième rang du
nommage est requis par la syntaxe
imposée pour un module EVM mais
n’identifie pas un slot sur le module.
Ports voix dans une Interfacetype 2/0/port interface bri 2/x

extension BRI (Basic
Rate Interface, l’une des « 2 » identifie le module EVM sur tous les
interfaces du réseau routeurs 2821 et 2851 (autres routeurs
RNIS) placée dans un non concernés).
module EVM. Les ports 8 à 11 appartiennent au module
d’extension 0.
Les ports 16 à 19 appartiennent au

module d’extension 1.
Le chiffre « 0 » au deuxième rang du

nommage est requis par la syntaxe
imposée pour un module EVM mais
n’identifie pas un slot sur le module.
Une partie des acronymes contenus dans ce tableau est certainement déjà connue à ce stade. À tout hasard :
WIC WAN Interface Card.
HWIC HighSpeed WIC.
VWIC Voice WIC.
VIC Voice Interface Card.
NM Network Module.
NME Network Module Enhanced.
BRI Basic Rate Interface.
RNIS Réseau Numérique à Intégration de Services.
FXS Foreign eXchange Subscriber. Port qui amène la ligne téléphonique de l’abonné. Cette
interface fournit notamment la tonalité, le courant du mode décroché, la tension du mode
raccroché, la tension de sonnerie. Un téléphone analogique classique, branché sur cette
interface, reçoit le service téléphonique.
FXO Foreign eXchange Office. Extrémité du câble permettant de relier un appareil, tel un
téléphone ou un télécopieur, au port FXS. On parle souvent de périphérique FXO. FXO et FXS
vont toujours de pair.

Utiliser la machine virtuelle LINUX
1. Configuration réseau en ligne de commande
L’invite de commandes est matérialisée par le caractère « $ ».
■ Un certain nombre de commandes nécessitent de disposer du niveau de privilège root (équivalent au niveau
privilégié dans l’IOS CISCO). Pour obtenir ce niveau, utilisez le préfixe sudo :
$ sudo <commande>
■ Si la commande su a été activée pour les droits root (sudopasswdroot), utilisez la commande su @ pour accéder au
compte root.
■ Pour découvrir les interfaces physiques installées :
$ ifconfig -a
■ Commande équivalente à la commande ipconfig de Windows :
$ ifconfig
■ Pour vérifier la configuration d’une interface réseau spécifique :
$ ifconfig eth0
■ Configuration des interfaces réseau :
$ sudo nano /etc/network/interfaces
Exemple de configuration statique :
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.8.3
netmask 255.255.255.0
gateway 192.168.8.1
Exemple de configuration dhcp :
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
■ Quittez par [Ctrl] X, acceptez le lieu et le nom de sauvegarde en tapant Y puis confirmez par la touche [Entrée].
■ Provoquez un redémarrage du réseau afin de prendre en compte une modification de la configuration :
$ sudo nano /etc/init.d/networking restart
■ Configuration DNS :

$ sudo nano /etc/revolv.conf
■ Pour ajouter un serveur DNS dans le fichier resolv.conf :
nameserver 10.0.8.1
■ Pour activer une interface :
$ sudo ifup<interface>
■ Pour désactiver une interface :
$ sudo ifdown<interface>
Exemple :
$ sudo ifdown eth0
Pour éditer un fichier texte :
$ nano <chemin du fichier>
■ Pour quitter nano, utilisez la combinaison de touches [Ctrl] X, puis entrez Y pour sauvegarder le fichier.
Exemple de configuration :
a) L’administrateur désactive l’interface :
$ sudo ifconfig eth0 inet down
b) L’administrateur configure et réactive l’interface :
$ sudo ifconfig eth0 inet up 192.168.0.1 netmask 255.255.255.0 broadcast

192.168.0.255
c) L’administrateur ajoute la passerelle en créant une route :
$ sudo route add default gw 192.168.0.1
2. Envoyer un courrier électronique en ligne de commande
Si le serveur DNS est bien renseigné dans le fichier resolv.conf (sinon remplacer smtp.ccna.fr par l’adresse IP du
serveur SMTP) :
$ telnet smtp.ccna.fr 25
220 Hello client, heureux de vous rencontrer
Helo ccna.fr
250 Hello.
mail from:[email protected]
250 OK
rcpt to:[email protected]
250 OK
data
354 OK, send.
subject: Test du serveur hmailserver
BlaBlaBlaBla
BlaBlaBlaBla
BlaBlaBla
.
250 Queued (84.391 seconds)

quit
221 goodbye
$
3. Recevoir un courrier électronique en ligne de commande
Si le serveur DNS est bien renseigné dans le fichier resolv.conf (sinon remplacer pop.ccna.fr par l’adresse IP du
serveur POP) :
$ telnet pop.ccna.fr 110

+OK Bienvenue sur le serveur POP CCNA
user [email protected]
+OK Send your password
pass cisco
+OK Mailbox locked and ready
stat
+OK 3 643
list
+OK 3 messages (643 octets)
1 177
2 188
3 278
.
retr 3
+OK 278 octets
return-Path: [email protected]
received: from ccna.fr(10.0.8.3)
By smtp.ccna.fr
With hMailServer ; Mon, 9 Feb 2009 18:02:22 +0100
message-ID: [email protected]
subject: Test du serveur hmailserver
BlaBlaBlaBla
BlaBlaBlaBla
BlaBlaBla
.
dele 1
+OK msg deleted
dele 2
+OK msg deleted
quit
+OK POP3 server saying goodbye…
4. Ouvrir une session SSH
Il s’agit de l’application Openssh client accessible via la commande :
$ ssh<username>@<ipaddress> -p <num_port>
Variante avec nom de machine :
$ ssh<username>@<nom_machine> -p <num_port>

Quelques notions sur la représentation binaire signée
1. Code complément à 1 ou complément restreint
Ce code n’a d’autre utilité que celle d’introduire le code complément à 2.
● Le complément à 1 de 0 est 1.
● Le complément à 1 de 1 est 0.
Pour exprimer le complément à 1 d’un mot binaire, il suffit donc de complémenter chaque bit du mot.
Exemple : le complément à 1 de 10010 est 01101.
La nécessité d’introduire les codes complément à 1 et complément à 2 provient de la solution choisie pour
représenter les nombres négatifs ou de la solution choisie pour réaliser une soustraction binaire. Si la plus petite
entité manipulable par une machine informatique est le bit, la seule opération arithmétique réalisable est l’addition.
Pour faire une soustraction, on additionne le nombre négatif correspondant au nombre que l’on voulait soustraire. La
question à se poser est donc « comment représenter les nombres négatifs en binaire ? »
Supposons un nombre binaire x = 0101
Notons son complément à 1
Réalisons l’addition de x et de son complément à 1 :
On constate que .
Ce faisant, on a introduit le signe moins ce qui est satisfaisant mais on a également introduit une constante (15(10) )
dont il faut se débarrasser, ce que permet le code complément à 2.
2. Code complément à 2 ou complément vrai
Le complément à 2 est égal au complément à 1 + 1.
Ajoutons 1 au complément à 1 de x et notons le résultat :
Puis, additionnons x et son complément à 2 :

On constate que .
La constante est toujours là mais si l’on admet que le domaine de définition des mots binaires est celui des mots à 4
bits (pour cet exemple), il faut ignorer le cinquième bit ce qui revient à ignorer la constante. Ce faisant, on obtient :
.
Exemple
Supposons que l’on désire réaliser l’opération binaire correspondant à l’opération décimale suivante :
Sur 4 bits, le mot binaire représentant 5 est 0101.
Son complément à 1 est 1010. Le nombre négatif représentant 5 est donc 1011 (1010 + 1).
Il reste à additionner le mot binaire représentant 7 et le mot binaire représentant 5 :
En ignorant le cinquième bit, le résultat est 0010 ce qui est bien le mot binaire représentant 2.
Lorsque le complément à 2 est utilisé, il faut impérativement connaître le format (nombre de bits) utilisé. En
effet, le complément à 2 d’un mot binaire ne sera pas le même selon que le format est 4, 8, 16 ou 32 bits.
Toujours sur 4 bits, essayons d’envisager ce que deviennent les 16 combinaisons possibles en complément à 2 :
Pour ce faire, construisons un tableau à quatre colonnes. Les deux premières colonnes contiendront les nombres
positifs en représentation décimale et binaire. Pour chaque mot binaire représentant un nombre positif, on place dans
les deux dernières colonnes, son complément à 2 ainsi que le nombre négatif correspondant :
Nombre positif Mot binaire positif Complément à 2 Nombre négatif
0 0000 0000 0
1 0001 1111 1
2 0010 1110 2
3 0011 1101 3
4 0100 1100 4

5 0101 1011 5
6 0110 1010 6
7 0111 1001 7
1000 8
On constate ainsi que sur 4 bits et en complément à 2, il est possible de représenter les nombres décimaux de 8 à
+7. On pourrait penser que les nombres négatifs sont privilégiés mais si l’on veut bien admettre que 0 est positif,
alors il y a autant de nombres positifs que de nombres négatifs.
Sans que cela prête à conséquence, le complément à 2 des mots binaires représentant les nombres négatifs donne à
nouveau les nombres positifs (le complément à 2 de 1110→2 est 0010→+2) sauf dans le cas du nombre négatif 8
car le complément à 2 de 1000 est 1000.
Enfin, il faut constater que le code complément à 2 est toujours un code pondéré. Pour trouver les poids
correspondant à chaque bit, il suffit d’observer les quatre cas où un seul bit est vrai : 0001, 0010, 0100 et 1000. On
remarque ainsi que si les poids binaires des trois bits de poids faible sont toujours 1, 2, 4, le poids binaire du
quatrième bit est 8.
Nécessairement, puisque 0111 → 7 et 1000 → 8, lorsque le quatrième bit est à 1, on peut conclure que le nombre
représenté est négatif. Ceci apparaît clairement dans le tableau ordonné suivant :
POIDS NOMBRE DÉCIMAL
8 4 2 1
0 0 0 0 0
0 0 0 1 1
0 0 1 0 2
0 0 1 1 3
0 1 0 0 4
0 1 0 1 5
0 1 1 0 6
0 1 1 1 7
1 0 0 0 8
1 0 0 1 7
1 0 1 0 6
1 0 1 1 5
1 1 0 0 4
1 1 0 1 3
1 1 1 0 2
1 1 1 1 1
Ceci fait parfois appeler le bit de poids fort bit de signe.

Sur quatre bits, en binaire naturel, on pouvait représenter les nombres décimaux de 0 à 15. En complément à 2, les
nombres décimaux s’étendent de 8 à +7. Essayons d’imaginer l’étendue de représentation lorsqu’on passe à 8, 16

ou 32 bits :
Format Binaire naturel Complément à 2
4 bits 0 à 15 8 à +7
8 bits 0 à 255 128 à +127
12 bits 0 à 4095 2048 à +2047
16 bits 0 à 65535 32768 à +32767
32 bits 0 à 4.294.967.295 2.147.483.648 à

+2.147.483.647
n bits 0 à 2n 1 2 n1 à + 2n1 1

Adresses de multidiffusion multicast
Le bloc 224.0.0.0/4, exadresses de classe D de 224 à 239, est dédié aux adresses de multi diffusion. À l’intérieur de
ce bloc, la subdivision en partie réseau et partie hôte de l’adresse est sans objet : les 4 premiers bits sont « 1110 » et
les 28 bits restants désignent le groupe. Sans fournir le niveau de détail du RFC3171, il est utile de connaître le bloc «
Local Network Control Block » :
224.0.0.0/24 → La traduction est dangereuse, le bloc est réservé par l’IANA sous le nom « Local Network Control
Block ». Ces adresses sont allouées aux protocoles chargés de la gestion du réseau, tels les protocoles de routage,
des protocoles de découverte de topologies, des protocoles de maintenance. Tout comme dans le cas des adresses «
localesliens », les paquets émis vers des adresses du bloc 224.0.0.0/24 le sont avec une durée de vie de 1 et restent
donc locaux. Exemples d’adresse dans ce bloc : 224.0.0.0 est réservée ; 224.0.0.1 désigne toutes les interfaces
présentes sur le réseau local (All systems on this subnet) ; 224.0.0.2 désigne toutes les interfaces de routeurs
présentes sur le réseau local (All routers on this subnet). Les autres affectations peuvent être consultées sur le site de
l’IANA : http://www.iana.org/assignments/multicastaddresses/multicastaddresses.xml
Comment reconnaître la trame qui encapsule un paquet envoyé vers une adresse IP multicast ? Il faut se souvenir que
la carte Ethernet en réception, ne se saisit que des trames qui lui sont destinées (dont l’adresse de destination
correspond à l’adresse MAC de la carte) et des trames qui sont émises en diffusion (dont l’adresse de destination
correspond à FFFFFFFFFFFF.
Donc pour envoyer un paquet vers une adresse multi diffusion, la première possibilité consistait à l’encapsuler dans
une trame dont l’adresse de destination est l’adresse de diffusion de couche 2. L’inconvénient est qu’une interface
n’appartenant pas au groupe ne le découvrira qu’en couche 3, imposant une surcharge inutile du processeur de la
machine.
L’idéal serait de pouvoir répercuter l’appartenance à un groupe de multi diffusion sur la couche 2. Il se trouve que
l’IANA disposait d’une plage d’adresses IEEE (un OUI) : 00005EXXXXXX. Il fut décidé d’en réserver la moitié (23 bits
sur 24) pour le multicast, les valeurs retenues sont 01005E000000 à 01005E7FFFFF. Le premier octet peut
sembler différent, il s’agit simplement du bit I/G qui est positionné à « 1 » pour rappeler que l’on a affaire à une
adresse de groupe. Le passage de l’adresse de groupe IP à l’adresse de groupe MAC s’effectue de la façon suivante :
Les 23 bits de poids faible de l’adresse de groupe IP sont placés dans les 23 bits de l’adresse de groupe MAC. On
objectera que sur les 32 bits de l’adresse IP d’un groupe, 28 désignent le groupe et que par conséquent plusieurs
groupes IP pourraient avoir la même adresse de groupe MAC. En effet, la conséquence est que même si la couche 2
fait remonter le paquet parce qu’elle a reconnu l’adresse de groupe, la couche 3 doit quand même vérifier qu’elle est
effectivement concernée par le paquet en question.

Installer Et Configurer Un Routeur

Transféré par

Droits d'auteur :

Formats disponibles

Installer Et Configurer Un Routeur

Transféré par

Informations du document

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

Installer Et Configurer Un Routeur

Transféré par

Droits d'auteur :

Formats disponibles

CISCO

Installer et configurer un routeur

Les chapitres du livre :

© ENI Editions - All rigths reserved - Moha Anisa - 1-

© ENI Editions - All rigths reserved - Moha Anisa - 1-

● RFC791 ­ Internet Protocol ­ Septembre 1981 ;

● RFC1122 ­ Requirements for Internet Hosts ­ Communication Layers ­ Octobre 1989.

● Appletalk, longtemps utilisé par les ordinateurs Macintosh de la firme Apple.

IP fournit un service de remise :

© ENI Editions - All rigths reserved - Moha Anisa - 1-

● dont l’unité de données, appelée datagramme, est associée à un format de paquet ;

b. Champ IHL (Internet Header Length)

c. Champ TOS (Type Of Service) (→ champ clé)

● la version du RFC791 décrivant le protocole IP ;

- 2- © ENI Editions - All rigths reserved - Moha Anisa

● RFC3168 ­ The Addition of Explicit Congestion Notification (ECN) to IP ­ Septembre 2001.

Le contenu de ce champ tel qu’il était défini dans le RFC791 :

L’illustration suivante montre le contenu actuel de l’octet TOS :

© ENI Editions - All rigths reserved - Moha Anisa - 3-

Le tableau suivant regroupe les valeurs DSCP recommandées du groupe PHB AF :

00 Non ECT (ECN Capable Transport), paquet non ECN

01 ECT(1) : paquet ECN pas encore marqué

- 4- © ENI Editions - All rigths reserved - Moha Anisa

normalement mis à profit par TCP

11 CE (Congestion Experienced), paquet ECN marqué

d. Champ Total Length

g. Champ Fragment Offset (→ champ clé)

● le premier datagramme porte le premier fragment de 600 octets, il en reste 800 ;

● le second datagramme porte le second fragment de 600 octets, il en reste 200 ;

● le troisième datagramme porte le dernier fragment de 200 octets.

Les valeurs correspondantes du champ Fragment Offset et du bit MF sont :

Numéro de fragment Données transportées Fragment Offset Bit MF

© ENI Editions - All rigths reserved - Moha Anisa - 5-

h. Champ TTL ( → champ clé)

i. Champ Protocol ( → champ clé)

j. Champ Header checksum

- 6- © ENI Editions - All rigths reserved - Moha Anisa

k. Champ Adresse Source (→ champ clé)

l. Champ Adresse Destination (→ champ clé)

© ENI Editions - All rigths reserved - Moha Anisa - 7-

n. Champ Padding (Bourrage)

- 8- © ENI Editions - All rigths reserved - Moha Anisa

● RFC791 ­ Internet Protocol ­ Septembre 1981 ;

● RFC823 ­ DARPA Internet Gateway ­ Septembre 1982.

Site utile : http://technet.microsoft.com/fr­fr/library/bb878104(en­us).aspx

PC11 souhaite communiquer avec PC22, de quelles informations doit­il disposer ?

En premier lieu, des informations le concernant :

● son masque réseau.

En second lieu, PC11 doit connaître l’adresse IP de PC22.

2. Le routage, une succession de sauts

© ENI Editions - All rigths reserved - Moha Anisa - 1-

2. R11 connaît la route vers 10.0.22.0/24 via 10.0.8.8.

3. R8 connaît la route vers 10.0.22.0/24 via 10.0.1.16.

4. R16 connaît la route vers 10.0.22.0/24 via 10.0.16.22.

On peut classer cette séquence de sauts en trois parties :

● Trouver le bon routeur de sortie (étape 1).

● Trouver le routeur destinataire (étapes 2, 3 et 4).

● Trouver la machine finale (étape 5).

3. Trouver le routeur de sortie

L’adresse de destination est­elle locale ?

● RFC791 Internet Protocol Septembre 1981 ;

● RFC1122 Requirements for Internet Hosts Communication Layers Octobre 1989.

● RFC3168 The Addition of Explicit Congestion Notification (ECN) to IP Septembre 2001.

● RFC791 Internet Protocol Septembre 1981 ;

● RFC823 DARPA Internet Gateway Septembre 1982.

Site utile : http://technet.microsoft.com/frfr/library/bb878104(enus).aspx

PC11 souhaite communiquer avec PC22, de quelles informations doitil disposer ?

L’adresse de destination estelle locale ?

Que se passetil quand le réseau de l’émetteur comporte plus d’un routeur ?