CISCO Installer Et Configurer Un Routeur

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

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.

CISCO Installer et configurer un routeur

André VAUCAMPS

Résumé

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.

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

enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MhbjKZ/1O82ICwA=-enidentnumber

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.


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1Mkgx4rH1O82ICwA=-enidentnumber

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 :


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1Mh0Fq9f1O82ICwA=-enidentnumber

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 « ECNcapable » 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é



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 :

10 ECT(0) : paquet ECN pas encore marqué

normalement mis à profit par TCP

11 CE (Congestion Experienced), paquet ECN marqué

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



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 600 0 1

2 600 600/8 = 75 1

3 200 75 + 75 = 150 0



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 :


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MtmZKgf2O82ICwA=-enidentnumber

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

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 locale ?



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’adresse de destination estelle directement connectée ?



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.

L’expéditeur connaîtil une passerelle ?



Station et passerelle sont directement connectées !

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 ?

L’acheminement vu par la station, synthèse partielle



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 cidessus, 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é.

Tapez la commande :

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)# ».

Tapez la commande :

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.


Tapez la commande :

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



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.


Tapez la commande :

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.



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.


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1Mo9EDDz2O82ICwA=-enidentnumber

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 sousré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 :


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MlzopmL2O82ICwA=-enidentnumber

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 sousré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 sousréseau

255.255.255.240

Nombre de sousréseaux max

16 Nombre d’hôtes par sousréseau

14

Bitmap du sousréseau

(n = network, s = subnet, h = host)

110nnnnn.nnnnnnnn.nnnnnnnn.sssshhhh

Adresse sousréseau

Premier hôte Dernier hôte Adresse de 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



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 sousré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.

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



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 les datagrammes vers des adresses de ce site.

Un routeur extérieur au site Centre n’a besoin que de la route vers 10.0.0.0/21 pour faire progresser les datagrammes vers des adresses de ce site.

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).

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.

Exercice 9.1 : découpage VLSM



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


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1Mv1VdX/2O82ICwA=-enidentnumber

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).


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1Mv1VdX/2O82ICwA=-enidentnumber

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 :


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MnVpE732O82ICwA=-enidentnumber

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 (7200I/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 :

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.

Modèle Ports 100BaseT Fast Ethernet (FE) RJ45

Ports 1000BaseT

Gigabit Ethernet (GE) RJ45

Ports USB (Universal Serial Bus)

Port Console (RJ45)

Port Auxiliaire (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



Le tableau suivant recense les quantités de mémoire embarquée ainsi que les extensions possibles selon les platesformes :

d. Alimentations

Pour chacun des routeurs de la série 2800, deux ou trois choix d’alimentation sont possibles :

Plateforme DRAM Boot/NVRAM Flash Memory

CISCO 2801 Mémoire type SDRAM (Synchronous DRAM).

128 Mo sur la carte mère.

Extension possible jusque 384 Mo à l’aide d’un slot d’extension DIMM (Dual Inline Memory Module).

4 Mo de mémoire Flash sur la carte mère.

Carte CompactFlash.

64 Mo par défaut.

128 Mo possible.

CISCO 2811 Mémoire type DDR ECC (Double Data Rate errorcorrecting code) SDRAM.

2 slots DIMM, aucune mémoire sur la carte mère.

Barrettes de 256 ou 512 Mo.

Mémoire par défaut 256 Mo.

Mémoire max 768 Mo.

2 Mo de mémoire Flash sur la carte mère.

Carte CompactFlash.

64 Mo par défaut.

128 ou 256 Mo possible.

CISCO 2821 et 2851

Idem 2811 sauf mémoire max 1024 Mo.

Alimentation Entrée Routeurs concernés

Secteur sans possibilité d’alimenter des téléphones IP

100 240 VAC 2A 2801, 2811

Secteur sans possibilité d’alimenter des téléphones IP

100 240 VAC 3A 2821, 2851

Secteur avec alimentation 48VDC 120 W pour les téléphones IP

100 240 VAC 5A 2801 (l’alim. 48V peut fournir 120 W)

2811 (l’alim. 48V peut fournir 160 W)

2821, 2851 (l’alim. 48V peut fournir 240 W)

DC sans possibilité d’alimenter des téléphones IP

24 60 VDC 8 A 2811

DC sans possibilité d’alimenter des téléphones IP

24 60 VDC 12 A 2821, 2851



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 :

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

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.

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.



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.

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 fixe

Des transferts de paquets sont en cours.

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 fixe

Activité sur les ports FE ou GE. Face arrière

F (=FDX) Vert Indique un fonctionnement en Fullduplex.

Éteint Indique un fonctionnement en Halfduplex.

S (=Speed) 1 flash suivi d’une pause

Débit des interfaces FE et GE à 10 Mbps.

2 flashs suivis d’une pause

Débit des interfaces FE et GE à 100 Mbps.

3 flashs suivis d’une pause

Débit des interfaces GE à 1000 Mbps (ne concerne que les platesformes 2821 et 2851).

L (=Link) Vert Le lien FE ou GE est établi.

PVDM x

x = 0, 1 (ou 2 si 2821 ou 2851)

Vert Un module PVDM est présent dans le slot x et initialisé.

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

x = 0, 1

Vert Le module AIM dans le slot x est initialisé.

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.



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

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.

La spécificité de ce standard est d’utiliser les quatre paires du câble réseau :

Cas des interfaces Ethernet et Fast Ethernet

Croisement du lien en 1000BaseT



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, NMEX23ES, 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’EIA232, 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. EIA449, 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 EIAX21, 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 CABSS232FC. 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 :

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 :

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.

interface ethernet numéro

Quand il s’agit de l’Ethernet historique à 10 Mbps.

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é.

interface ethernet 0

int e0

interface fastethernet 0/1

int fa0/1

interface gigabitethernet 0/0

int gi0/0



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 :


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MgwCNQj3O82ICwA=-enidentnumber

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 sousmodes. 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 cidessus, 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

959=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 :

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

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é.



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



Les raccourcis suivants effacent un caractère ou une partie de mot ou une partie de ligne :

[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).

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



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

de la combinaison [Ctrl] Y.



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 :

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é :

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 réseau

1 5 1 1

Système d’exploitation W2000 SRV XP Prof SP3 W2000 Prof SP4 W2000 Prof SP4

Ou Ubuntu

Logiciels notables Services réseau

GNS3 Serveur SYSLOG (Kiwi)

Serveur RADIUS (RADL)

PuTTY

Wireshark



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



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 :

VMnet6

VMnet7

VMnet8 NIC8 NIC8 NIC8

VMnet9



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]? Building configuration... [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 Enter configuration commands, one per line. End with CNTL/Z. R8(config)#line con 0 R8(config-line)#logg R8(config-line)#logging sy R8(config-line)#logging synchronous 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 exectimeout 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 Enter configuration commands, one per line. End with CNTL/Z. R8(config)#line con 0 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 exectileout 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)#exec-timeout 0 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.


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MgY+te33O82ICwA=-enidentnumber

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 :

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

Variable de prompt

Interprétation

%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 %.


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MkCldPj3O82ICwA=-enidentnumber

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 Enter configuration commands, one per line. End with CNTL/Z. 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 # Enter TEXT message. End with the character ’#’. Ceci est la banniere login # R11(config)#banner exec # Enter TEXT message. End with the character ’#’. 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 Enter configuration commands, one per line. End with CNTL/Z. R11(config)# R11(config)#banner login # Enter TEXT message. End with the character ’#’. ********************************************************************** **** 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 :

Mettons à profit ces variables pour créer une bannière exec sur R12 :

R12(config)#banner exec # Enter TEXT message. End with the character ’#’. 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 User Access Verification 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

« 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.



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) Translating "R13"...domain server (255.255.255.255) (255.255.255.255) Translating "R13"...domain server (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 Enter configuration commands, one per line. End with CNTL/Z. 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 User Access Verification Password: Bienvenue, vous venez de vous connecter au routeur R12.ccna.fr 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 :

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#

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.



*Mar 1 02:33:46.352: %SYS-5-CONFIG_I: Configured from console by console (59140 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 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) 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 User Access Verification Password: Bienvenue, vous venez de vous connecter au routeur R12.ccna.fr 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 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.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# *Mar 1 03:21:48.521: %SYS-5-CONFIG_I: Configured from console by console (59140 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 con 0 R11(config-line)#location 59140 DUNKERQUE R11(config-line)#logging synchronous R11(config-line)#exec-timeout 0 R11(config-line)#password eni R11(config-line)#login R11(config-line)#^Z R11#

Sur R12 (à reproduire sur R11), accès Telnet :

R12(config)#line vty 0 4 R12(config-line)#exec-timeout 0 R12(config-line)#logging synchronous R12(config-line)#password eni R12(config-line)#login 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é.


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MuWfKQT4O82ICwA=-enidentnumber

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


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MhTiaxL4O82ICwA=-enidentnumber

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 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 down

FastEthernet0/1 unassigned YES NVRAM up up Serial0/1 unassigned YES NVRAM administratively down down 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 Enter configuration commands, one per line. End with CNTL/Z. 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)#ip address 10.0.12.1 255.255.255.0 R12(config-if)#no shutdown 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)#int s0/0 R11(config-if)#ip address 10.0.8.11 255.255.255.0 R11(config-if)#no shutdown R11(config-if)#description Lien loue 64K vers Nantes R11(config-if)#bandwidth 64



R11(config-if)#^Z R11#

Sur R12 :

R12(config)#int s0/0 R12(config-if)#ip address 10.0.8.12 255.255.255.0 R12(config-if)#no shutdown 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)#ip address 1.0.0.11 255.255.255.255 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 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 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 d’utilisation

Affiche ...

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 numéro]

*** Des informations couche 1 pour chaque interface 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 numéro] [brief]

***** Des informations IP sur les interfaces.

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


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1Mipx2yD4O82ICwA=-enidentnumber

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.


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1Mipx2yD4O82ICwA=-enidentnumber

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 :


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1Mk/g/Cj4O82ICwA=-enidentnumber

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

Mode privilégié.

/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 | runningconfig | system:runningconfig.

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 !! 1799 bytes copied in 4.399 secs (409 bytes/sec) 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 startupconfiguration. 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

Destination filename [startup-config]? 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] 1918 bytes copied in 11.431 secs (168 bytes/sec) 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 | startupconfig | nvram:startupconfig.

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]

Mode privilégié.

/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 ! **** ********************************************************************** User Access Verification 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 Building configuration... 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:


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MiLjhDn4O82ICwA=-enidentnumber

- - 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...



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 :

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

Feature Set Image Filename

Packages classiques

ENTERPRISE/FW/IDS PLUS IPSEC 3DES c2600jk9o3smz

ENTERPRISE PLUS IPSEC 3DES c2600jk9smz

ENTERPRISE PLUS c2600jsmz



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)

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



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) Technical Support: http://www.cisco.com/techsupport 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 :

Toujours pour cette même plateforme 2600XM, CISCO suggère des migrations pour certaines de ses images IOS retirées de la vente :

Feature Set Image Filename Flash nécessaire

RAM 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

« EndofSales Feature Set » Migration suggérée

ENTERPRISE/SNASW PLUS IPSEC 56

c2600a3jk8smz

ENTERPRISE/SNASW PLUS IPSEC 3DES

c2600a3jk9smz

IP PLUS IPSEC 56

c2600ik8smz

IP PLUS IPSEC 3DES

c2600ik9smz

ADVANCED SECURITY

c2600advsecurityk9mz

ADVANCED IP SERVICES

c2600advipservicesk9mz

ENTERPRISE/FW/IDS PLUS IPSEC 56

c2600jk8o3smz

ENTERPRISE/FW/IDS PLUS IPSEC 3DES

c2600jk9o3smz

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 16e 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 :

ENTERPRISE PLUS IPSEC 56

c2600jk8smz

ENTERPRISE PLUS IPSEC 3DES

c2600jk9smz

ADVANCED ENTERPRISE SERVICES

c2600adventerprisek9mz



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


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MstpWk74O82ICwA=-enidentnumber

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é :

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

Champ d’amorçage

Commandes boot system

Effet

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.



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 ......... Configuration register is 0x2102 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) Technical Support: http://www.cisco.com/techsupport 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 Readonly ROMMON initialized program load complete, entry point: 0x8000f000, size: 0xcb80 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 ......... Cisco IOS Software, 2801 Software (C2801-IPBASEK9-M), Version 12.4(25c), RELEASE SOFTWARE (fc2) ......... --- System Configuration Dialog --- Would you like to enter the initial configuration dialog? [yes/no]: no

Press RETURN to get started! 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]? 1303 bytes copied in 0.332 secs (3925 bytes/sec)

8. L’administrateur visualise les mots de passe perdus (extrait) :

R12#sh run Building configuration... ......... 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



Enter configuration commands, one per line. End with CNTL/Z. 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 Destination filename [startup-config]? Building configuration... [OK]

11. Une commande show version confirme la future prise en compte de la nouvelle valeur du registre de configuration (extrait) :

R12#sh ver Cisco IOS Software, 2801 Software (C2801-IPBASEK9-M), Version 12.4(25c), RELEASE 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: Size(b) Free(b) Type Flags Prefixes - - opaque rw archive: - - opaque rw system: - - 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: - - network rw http: - - 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: Size(b) Free(b) Type Flags Prefixes - - opaque rw archive: - - opaque rw system: - - opaque rw null: - - network rw tftp: 196600 194215 nvram rw nvram: * 63995904 3837952 disk rw flash:#

- - opaque rwxmodem: - - opaque rwymodem:


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1Ms06m2P4O82ICwA=-enidentnumber

- - network rwrcp: - - network rw ftp: - - network rw http: - - 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 Destination filename [startup-config]? Building configuration... [OK] R12#reload Proceed with reload? [confirm]

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 Cisco IOS Software, 2801 Software (C2801-IPBASEK9-M), Version 12.4(25c), RELEASE

SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2010 by Cisco Systems, Inc. Compiled Fri 12-Feb-10 00:29 by prod_rel_team ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1) 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] 17935236 bytes copied in 59.096 secs (303493 bytes/sec) 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 Destination filename [startup-config]? Building configuration... [OK] R12#reload Proceed with reload? [confirm]

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 Cisco IOS Software, 2801 Software (C2801-IPBASEK9-M), Version 12.4(25c), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Compiled Fri 12-Feb-10 00:29 by prod_rel_team ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1) 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 Directory of flash:/ 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

63995904 bytes total (18935808 bytes free) 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 Directory of flash:/ 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

63995904 bytes total (35749888 bytes free) 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

Mode privilégié.

/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 Proceed with reload? [confirm] *Mar 10 15:37:23.879: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command. System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport 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 Readonly ROMMON initialized



monitor: command "boot" aborted due to user interrupt 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] ......... Readonly ROMMON initialized 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... program load complete, entry point: 0x8000f000, size: 0xcb80 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 (invalid) 0 bytes (0x0) 0x0000 (invalid) 0 bytes (0x0) 0x0000 (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 :

Readonly ROMMON initialized program load complete, entry point: 0x8000f000, size: 0xcb80 monitor: command "boot" aborted due to user interrupt rommon 1 >xmodem -c -y c2801-ipbase-mz.124-16a.bin

Do not start the sending program yet... program load complete, entry point: 0x8000f000, size: 0xcb80 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 (invalid) 0 bytes (0x0) 0x0000 (invalid) 0 bytes (0x0) 0x0000 (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 ...

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 :

program load complete, entry point: 0x8000f000, size: 0xcb80 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 program load complete, entry point: 0x8000f000, size: 0xcb80

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



Directory of flash:/ 1 -rw- 16810060 Feb 23 2010 20:15:44 +00:00 c2801-ipbase-mz.124-16a.bin

64012288 bytes total (47198208 bytes free)

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 cidessus. 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 Proceed with reload? [confirm]

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 Proceed with reload? [confirm]

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:"

System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1) ......... c2801 platform with 131072 Kbytes of main memory Main memory is configured to 64 bit mode with parity disabled Readonly ROMMON initialized 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:" ......... Readonly ROMMON initialized 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:. program load complete, entry point: 0x8000f000, size: 0xcb80 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 program load complete, entry point: 0x8000f000, size: 0xcb80 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 System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1) ......... Readonly ROMMON initialized program load complete, entry point: 0x8000f000, size: 0xcb80 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 ......... Press RETURN to get started! Cisco IOS Software, 2801 Software (C2801-IPBASEK9-M), Version 12.4(25c), RELEASE SOFTWARE (fc2)



......... User Access Verification Password: R12>en Password: R12#sh flash: -#- --length-- -----date/time------ path 1 17935236 Feb 22 1907 17:31:44 +00:00 c2801-ipbasek9-mz.124-25c.bin 46075904 bytes available (17936384 bytes used) 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 !


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MuVV1nH4O82ICwA=-enidentnumber

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).

Configuration register is 0x2102

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 plateforme.

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 7879412 bytes available (8504588 bytes used)

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 dirdevice:. 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) PCMCIA Slot0 flash directory, partition 2:

No files in PCMCIA Slot0 flash [0 bytes used, 8388608 available, 8388608 total] 8192K bytes of processor board PCMCIA Slot0 flash (Read/Write) PCMCIA Slot0 flash directory, partition 3:

No files in PCMCIA Slot0 flash [0 bytes used, 3932160 available, 3932160 total] 4096K bytes of processor board PCMCIA Slot0 flash (Read/Write)

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

-#- --length-- -----date/time------ path 1 17935236 Feb 22 1907 17:31:44 +00:00 c2801-ipbasek9-mz.124-25c.bin 46075904 bytes available (17936384 bytes used) ******** 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:

Directory of 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 64012288 bytes total (46071808 bytes free) 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 Directory of 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 3 drw- 0 Mar 17 2010 13:18:24 +00:00 config 64012288 bytes total (46067712 bytes free) R12#

La commande cd permet de changer de répertoire courant :

R12#cd config

R12#dir

Directory of flash:/config/ No files in directory 64012288 bytes total (46067712 bytes free) R12#

Plaçons un fichier quelconque dans notre nouveau répertoire :

R12#copy running-config R12_cfg.txt

Destination filename [/config/R12_cfg.txt]? 1363 bytes copied in 0.696 secs (1958 bytes/sec) R12#dir Directory of flash:/config/ 4 -rw- 1363 Mar 17 2010 13:22:00 +00:00 R12_cfg.txt 64012288 bytes total (46063616 bytes free) 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 Directory of flash:/config/ No files in directory 64012288 bytes total (46067712 bytes free) R12#

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

R12#cd .. R12#dir Directory of 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 3 drw- 0 Mar 17 2010 13:18:24 +00:00 config 64012288 bytes total (46067712 bytes free) R12#rmdir config

Remove directory filename [config]? Delete flash:/config? [confirm] Removed dir flash:/config R12#dir Directory of 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 64012288 bytes total (46071808 bytes free) 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.


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MpywPIX4O82ICwA=-enidentnumber

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.


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MppSv5P4O82ICwA=-enidentnumber

Solution travaux pratiques : routes statiques agrégées

Voici les 14 routes à entrer :

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.

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


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MpP/nZv4O82ICwA=-enidentnumber

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 :


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MvmFAqn4O82ICwA=-enidentnumber

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 l’évènement correspondant.

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 l’évènement correspondant.

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


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MiRqcrz4O82ICwA=-enidentnumber

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 :

Électrique RS232D V28

Fonctionnel création : 1962 V24

Mécanique RS232C : 1969

dernière révision : 1987

DP2110



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 ciaprè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 UITT

N° broche (25 pts)

N° broche (9 pts)

Abréviation UITT Abréviation EIA ETTD 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) →



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) :

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 ←



a. Performances demandées à l’émetteur V28

b. Performances demandées au récepteur V28

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 :

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 3000 Ω à 7000 Ω.

> 5 V et < 15 V

Vitesse de transition de sortie (slewrate). 30 V/µs

Temps de montée et de descente de la sortie dans les limites de transition de 3V et 3V.

La plus faible des deux valeurs suivantes : ≤ 1 ms ou ≤ 3 % de la durée du temps bit.

Vitesse maximale des données. 20000 bits/s

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. < 2 V

Vitesse maximale des données. 20000 bits/s



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 matériel

Le fournisseur de données est informé en permanence de l’état de l’imprimante.

La jonction à réaliser est plus complexe et 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 logiciel

Le fournisseur de données n’est informé que des changements d’état de l’imprimante. Cela suppose qu’il entretienne luimême une mémoire reflétant cet état et qu’il soit « attentif »

La jonction à réaliser est toujours simple et symétrique (on peut retourner le cordon réalisé pour faire la jonction entre les deux équipements).



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 microordinateurs 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 :

lorsqu’il reçoit l’information de changement d’état.





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, sousarticles…

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


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MunGt9z4O82ICwA=-enidentnumber

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 :

(*) 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 :

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.

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 (HWIC, HWICD, WIC, VWIC, VIC) installée directement dans un slot HWIC du châssis.

Interfacetype 0/slot/port

interface serial 0/x/y

interface async 0/x/y

line 0/x/y

interface fa 0/x/y

voiceport 0/x/y

Sur une carte d’interface (WIC, VWIC, VIC) installée dans un slot appartenant à un module NM.

Interfacetype 1/slot/port

« 1 » identifie le module NM sur tous les routeurs de la série 2800.

controller t1 1/x/y

voiceport 1/x/y

interface serial 1/x/y

interface async 1/x/y

line 1/x/y

Embarqué directement sur le module NM (NME, NMEX, NMD, NMDXD).

Interfacetype 1/port

« 1 » identifie le module NM sur tous les routeurs de la série 2800.

interface gi 1/x

interface serial 1/x

interface async 1/x

line 1/x

Port FXS ou FXO installé Interfacetype 2/0/port

voiceport 2/0/x


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MnTrUeb4O82ICwA=-enidentnumber

Une partie des acronymes contenus dans ce tableau est certainement déjà connue à ce stade. À tout hasard :

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 extension BRI (Basic Rate Interface, l’une des interfaces du réseau RNIS) placée dans un module EVM.

Interfacetype 2/0/port

« 2 » identifie le module EVM sur tous les routeurs 2821 et 2851 (autres routeurs non concernés).

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.

interface bri 2/x

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.


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MnTrUeb4O82ICwA=-enidentnumber

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 :


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MuOtBe74O82ICwA=-enidentnumber

$ 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 :


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MiEtXPj4O82ICwA=-enidentnumber

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



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 :

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

5 0101 1011 5

6 0110 1010 6

7 0111 1001 7

1000 8

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



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

2n1 à + 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.


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA6NDIzMzg5IC0gTW9oYSBBbmlzYSAtIGJhZDVmMjk5LWQzNDAtNGRmNi1iMDUyLTcyNDU5ZmM1NTI1MkNKzAD5O82ICwA=-enidentnumber

Documents

CISCO Installer Et Configurer Un Routeur