Ce document, vous explique comment installer un reseau local poste a posteDescription complète
Descripción completa
Descripción completa
Conceptos Basicos para la configuracion de un switch CISCO
configuración de firewall
Descripción: prueba cisco
Descripción completa
CISCO Installer et configurer un routeur
André VAUCAMPS
Résumé Ce livre sur les routeurs Cisco s’adresse à tous les techniciens et ingénieurs concernés par le déploiement, la configuration et la maintenance de routeurs dans les réseaux informatiques. Après avoir resitué le contexte des protocoles et services de la couche réseau, l’auteur pose les fondements du routage. Les problèmes d’adressage sont également approfondis, l’ouvrage montre comment satisfaire les besoins d’une topologie en utilisant les masques de longueur variable VLSM (Variable Length Subnet Mask). L’ouvrage s’intéresse ensuite au composant matériel routeur proprement dit et décrit son objet, sa nature ainsi que son fonctionnement. Le lecteur est invité à prendre en main l’interface en ligne de commande CISCO (CLI – Command Line Interface), interface commune à l’ensemble des produits CISCO. L’auteur propose au lecteur de maîtriser les fondements d’une méthode de configuration cohérente. Le système d’exploitation CISCO IOS qui équipe les routeurs n’est pas oublié : la séquence d’amorçage, le nommage des versions et la mise à jour de l’IOS sont décrits. L’ouvrage se veut pratique, il s'agit de prendre en mains le routeur dans les différentes phases de sa vie en production et ce, dès sa sortie du carton. Une place importante est accordée à la réalisation d’ateliers dans des environnements simulés ou émulés que le lecteur pourra reproduire sur son PC (fichiers disponibles en téléchargement sur www.editions-eni.fr. Les chapitres du livre : Avant-propos - Le routage, initiation - Les routeurs - Tâches de configuration des routeurs - Gestion de la plate-forme logicielle CISCO IOS Exercices corrigés - Annexes
L'auteur Ancien Responsable de Formation en Centre AFPA, André VAUCAMPS enseigne aujourd'hui dans les sections de Techniciens Supérieurs en Réseaux Informatiques et Télécommunications d'Entreprise. Il est l'auteur des livres de préparation à la certification CCNA 640-802 aux Editions ENI.
Ce livre numérique a été conçu et est diffusé dans le respect des droits d’auteur. Toutes les marques citées ont été déposées par leur éditeur respectif. La loi du 11 Mars 1957 n’autorisant aux termes des alinéas 2 et 3 de l’article 41, d’une part, que les “copies ou reproductions strictement réservées à l’usage privé du copiste et non destinées à une utilisation collective”, et, d’autre part, que les analyses et les courtes citations dans un but d’exemple et d’illustration, “toute représentation ou reproduction intégrale, ou partielle, faite sans le consentement de l’auteur ou de ses ayants droit ou ayant cause, est illicite” (alinéa 1er de l’article 40). Cette représentation ou reproduction, par quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles 425 et suivants du Code Pénal. Copyright Editions ENI Ce livre numérique intègre plusieurs mesures de protection dont un marquage lié à votre identifiant visible sur les principales images.
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.
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 :
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 : ●
RFC2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers Décembre 1998 ; RFC3168 The Addition of Explicit Congestion Notification (ECN) to IP Septembre 2001.
Ce champ existe également dans l’entête IPv6 mais devient le champ Classe de trafic. Le contenu de ce champ tel qu’il était défini dans le RFC791 :
L’illustration suivante montre le contenu actuel de l’octet TOS :
Que se passetil lorsqu’un routeur ne parvient pas à écouler les paquets qu’il reçoit ? En temps normal, il peut se produire des salves de paquets dont le rythme dépasse la capacité de traitement du routeur, ces paquets sont placés en file d’attente et le routeur vient les chercher en séquence et à son rythme. Bien sûr, le système a une limite et un flot d’entrée trop important peut provoquer la saturation de ces files d’attente, ce phénomène est appelé congestion. Inévitablement, le routeur est amené à supprimer des paquets, il peut le faire de façon aléatoire (c’est la notion du « Best effort »), mais à l’aide du champ DS (Differentiated Services), il devient possible de le faire de façon plus intelligente. L’idée est de créer des classes de trafic caractérisées par une probabilité de rejet, les classes les plus élevées correspondant aux probabilités de rejet les plus faibles. Le RFC2474 définit la notion de PHB (Per Hop Behaviour), difficile à traduire mais il s’agit de définir un comportement du routeur dans l’acheminement des paquets, selon la valeur de priorité DSCP (Differentiated Services Code Point) contenue dans le champ DS. La valeur DSCP 000000 n’assure rien de plus que le comportement par défaut de type « Best Effort ». Pour les paquets nécessitant un traitement plus « Best » (« tous les hommes seront égaux mais ça ne sera pas facile. Y’en a même qui seront …. Et pour eux, ça sera très dur », dixit le célèbre amuseur), les RFC 2597 et 2598 fournissent des valeurs de DSCP pour deux types de comportements :
Le PHB « Expedited Forwarding » (traitement accéléré) défini dans le RFC 2598 puis 3246 offre une bande passante garantie avec taux de perte, délai et gigue faibles, soit un service similaire à une réservation de ressources (en bref, un circuit !). Ce PHB est destiné aux applications temps réel type téléphonie sur IP. Le DSCP prend la valeur 46. Le groupe PHB « Assured Forwarding » (acheminement assuré) défini dans le RFC 2597, offre quatre classes de service et trois niveaux de priorité (« precedence ») qui permettent de composer douze PHB différents. Un fournisseur d’accès peut ainsi offrir différents niveaux de service définis par la bande passante allouée ainsi que le volume des files d’attente. Les paquets conformes au groupe PHB AF sont affectés à une ou plusieurs classes par le client ou le fournisseur d’accès selon le contrat de prestation souscrit. À l’intérieur d’une classe, le paquet est à nouveau marqué par une priorité parmi trois, priorité qui est mise à profit en cas de congestion dans la classe en question en arbitrant les suppressions de paquets.
Le tableau suivant regroupe les valeurs DSCP recommandées du groupe PHB AF :
La figure suivante illustre un exemple d’utilisation des PHBs AF pour le déploiement d’une offre « Triple Play » sur ADSL :
Observez que les valeurs DSCP choisies n’interfèrent ni avec l’ancienne valeur de priorité 000 du champ TOS (« Best effort »), ni avec les anciennes valeurs de priorité 11x correspondant à la gestion de réseau. Ceci permet aux anciens routeurs « TOScapable » encore présents sur le réseau de continuer à fonctionner. Le champ ECN (Explicit Congestion Notification) n’est apparu dans l’octet TOS que lors de sa dernière révision proposée par le RFC3168. L’idée est de prévenir un émetteur que son émission en cours contribue à la formation d’une congestion, ce avant que le rejet de paquets ne se produise. De plus, l’émetteur est prévenu à l’aide de drapeaux positionnés dans les acquittements qu’il doit normalement recevoir, il n’y a pas de création de flux supplémentaires pour alerter cet émetteur. Le pire serait en effet de créer un dispositif qui contribue à transformer le risque de congestion en congestion effective. Un routeur mesure le risque de congestion au remplissage de ses files d’attente. Lorsqu’un routeur utilisant ECN veut prévenir une congestion (le remplissage moyen a dépassé un seuil), il marque les paquets qui sont « ECN capable » c’estàdire les paquets qui portent un label certifiant que l’émetteur comprendra le marquage. Le RFC3168 fournit la table suivante : ECN
ECT(0) : paquet ECN pas encore marqué normalement mis à profit par TCP
11
CE (Congestion Experienced), paquet ECN marqué
Difficile d’aller plus avant dans la description de ce mécanisme car il faudrait disposer de solides connaissances sur le protocole de transport TCP et aborder quelques notions quant aux stratégies possibles de gestion des files d’attente.
d. Champ Total Length Taille du paquet IP, entête + données, exprimée en octets. Le champ étant exprimé sur 16 bits, la longueur maximale s’établit à 65535 octets mais il est probable qu’aucun hôte ni aucun réseau ne seraient en mesure de traiter de tels datagrammes. Le RFC 791 précise, et le RFC 1122 le rappelle, que tout hôte doit pouvoir accepter des datagrammes dont la longueur atteint 576 octets, que ces datagrammes arrivent en entier ou par fragments. Par ailleurs, un hôte ne devrait émettre un datagramme de longueur supérieure à 576 octets que s’il a la certitude que l’hôte distant peut l’accepter. On touche ici un point délicat qui pourrait faire l’objet d’un chapitre entier, d’autres précisions sont fournies dans l’étude du protocole de transport TCP.
e. Champ Identification Lorsque, pendant l’acheminement, un processus IP est contraint de fragmenter un paquet pour prendre en compte le MTU du prochain saut, le processus IP destinataire final devra accomplir la tâche supplémentaire qui consiste à réassocier les différents fragments afin de reconstituer le paquet initial. Il est aidé en cela par le champ Identification (un « tag ») dont la valeur est générée aléatoirement dans le paquet initial, puis copiée dans chacun des fragments.
f. Champ Drapeaux Le bit de poids fort n’est pas utilisé et reste à 0. Les deux autres bits interviennent dans le processus de fragmentation : ●
●
Bit DF (Don’t Fragment) : positionné à 1, indique que le datagramme ne doit pas être fragmenté. Un routeur qui n’aurait pas d’autre choix détruira le paquet tout en générant un message ICMP de compte rendu de destination inaccessible ; Bit MF (More Fragment) : positionné à 1, indique que le datagramme n’est qu’une partie du datagramme initial. Positionné à 0 avec une valeur de champ Fragment offset différente de 0, indique que le datagramme est la dernière partie du datagramme initial.
g. Champ Fragment Offset (→ champ clé) Sur 13 bits, permet le réassemblage d’un paquet fragmenté en fournissant la position dans le datagramme initial. Hors entête, la position exprimée en octets est égale à 8 fois la valeur contenue dans le champ Fragment Offset (Déplacement). Exemple : soit à acheminer 1400 octets de données sur une liaison de MTU 620. Le datagramme initial a été émis sur un LAN de MTU 1500. En admettant que l’entête IP ne comporte pas d’options, chaque datagramme émis sur la liaison MTU 620 peut porter 620 20 = 600 octets de données. ●
le premier datagramme porte le premier fragment de 600 octets, il en reste 800 ;
●
le second datagramme porte le second fragment de 600 octets, il en reste 200 ;
●
le troisième datagramme porte le dernier fragment de 200 octets.
Les valeurs correspondantes du champ Fragment Offset et du bit MF sont : Numéro de fragment
On identifie un datagramme non fragmenté lorsque bit MF et valeur de déplacement sont tous deux à 0.
h. Champ TTL ( → champ clé) Sur 8 bits, durée de vie du datagramme dans le réseau exprimée en secondes. Chaque routeur qui fait transiter le paquet décrémente la durée de vie d’au moins un quel que soit le temps inférieur à un passé dans le routeur. En pratique, ce champ est donc plutôt à considérer comme un nombre de sauts maximum qui limite la portée du paquet mais surtout qui permet d’éliminer un datagramme qui « errerait » dans le réseau sans jamais atteindre son destinataire (boucle de routage).
i. Champ Protocol ( → champ clé) Sur 8 bits, le champ Protocol contient le NSAP de couche 3, c’estàdire l’information qui permet au processus IP destinataire de remettre la charge utile au protocole de couche 4 convenable. Ce mécanisme est appelé démultiplexage de protocole :
Les numéros alloués sont bien connus et donc gérés par l’autorité IANA, on en trouve la liste sur le site : http://www.iana.org/assignments/protocolnumbers/protocolnumbers.xhtml Il est indispensable de connaître quelques valeurs telles ICMP → 1, TCP → 6 ou UDP → 17.
j. Champ Header checksum La somme de contrôle de l’entête, exprimée sur 16 bits, permet de s’assurer de l’intégrité de l’entête du datagramme IP. Un routeur qui reçoit un datagramme calcule cette somme puis la compare à la somme reçue. Si les valeurs diffèrent, le paquet est détruit et le routeur génère un message ICMP. Si les valeurs sont identiques, le routeur décrémente la valeur TTL ce qui l’oblige à recalculer une somme de contrôle qui vient remplacer la somme reçue avant l’émission du paquet vers le routeur suivant. Le procédé de calcul est le suivant :
1) Mettre checksum à 0. 2) Calculer somme des mots de 16 bits qui composent l’entête. 3) Ajouter retenue1 à somme1. 4) Ajouter retenue2 à somme2. 5) Complémenter à 1 somme3 → on obtient la valeur recherchée.
k. Champ Adresse Source (→ champ clé) L’adresse Source identifie l’expéditeur du datagramme et n’est pas modifiée par les routeurs, elle reste donc inchangée pendant l’acheminement du paquet.
l. Champ Adresse Destination (→ champ clé) L’adresse Destination identifie le destinataire final du datagramme et n’est pas modifiée par les routeurs, elle reste donc inchangée pendant l’acheminement du paquet (sauf à nouveau s’il y a translation d’adresses).
m. Champ Options La présence d’options est signalée par une valeur du champ IHL supérieure à cinq. Les options sont normalement destinées à effectuer des tests pendant des phases de mise au point. L’organisation des options rappelle celle de la zone vendeur de BOOTP : chaque option présente comporte un code option sur un octet suivi d’un champ longueur et des données propres à l’option :
À titre d’exemple, l’option Enregistrement de route comporte une liste vide d’adresses IP lors de son émission par la source. Puis chaque routeur qui fait progresser le datagramme ajoute son adresse IP à la liste, le champ Pointeur lui permet de déterminer le prochain emplacement libre dans le champ Données de l’option.
n. Champ Padding (Bourrage) Le champ IHL exprime la longueur de l’entête en unités de 32 bits, le champ Bourrage permet d’atteindre une longueur multiple de 32 bits quand elle ne l’est pas naturellement. En l’absence d’options par exemple, le champ Bourrage n’est pas nécessaire, la longueur de l’entête s’établissant alors à 5 x 4 octets.
Site utile : http://technet.microsoft.com/frfr/library/bb878104(enus).aspx
1. Prérequis indispensables
PC11 souhaite communiquer avec PC22, de quelles informations doitil disposer ? En premier lieu, des informations le concernant : ●
son adresse IP ;
●
son masque réseau.
L’adresse IP répond à la question « Qui suisje ? ». Un ET logique entre l’adresse IP et le masque réseau fournit l’adresse réseau et répond à la question « à quel groupe j’appartiens ? ». Ces deux informations font partie de la configuration IP de la machine. En second lieu, PC11 doit connaître l’adresse IP de PC22.
2. Le routage, une succession de sauts Un acheminement consiste en une succession de sauts, chaque routeur qui fait transiter le paquet doit connaître une route vers le réseau de destination :
1. Le processus IP de PC11 détermine que l’adresse de destination est extérieure. Il remet le datagramme à R11 via 10.0.11.1. 2. R11 connaît la route vers 10.0.22.0/24 via 10.0.8.8. 3. R8 connaît la route vers 10.0.22.0/24 via 10.0.1.16. 4. R16 connaît la route vers 10.0.22.0/24 via 10.0.16.22. 5. R22 connaît le réseau 10.0.22.0/24 puisqu’il lui est directement connecté et peut donc remettre le datagramme directement à PC22. On peut classer cette séquence de sauts en trois parties : ●
Trouver le bon routeur de sortie (étape 1).
●
Trouver le routeur destinataire (étapes 2, 3 et 4).
●
Trouver la machine finale (étape 5).
3. Trouver le routeur de sortie L’adresse de destination estelle locale ? Par locale, on entend ici « appartientelle à la machine ? ». PC11 demande à son processus IP d’expédier un datagramme. Le processus IP examine l’adresse de destination et le premier test consiste à vérifier que cette adresse est bien extérieure à la machine. Dans le cas contraire, le datagramme passe directement du buffer émission au buffer réception et n’est pas remis à la couche Liaison :
L’adresse de destination estelle directement connectée ? Après avoir vérifié que l’adresse de destination n’est pas locale, le second test réalisé par le processus IP est le test d’adjacence. Il s’agit de déterminer si le destinataire et l’expéditeur partagent le même réseau, autrement dit de déterminer si le destinataire est directement connecté. Si la réponse est oui, les deux hôtes peuvent communiquer sans nécessiter de périphérique intermédiaire de couche réseau (sans routeur), il reste pour l’expéditeur à vérifier qu’il dispose de la correspondance @physique @logique dans son cache ARP, à déclencher une requête ARP pour le cas où cette correspondance manquerait puis à remettre le datagramme à la couche Liaison. Le test d’adjacence consiste en deux ET logique successifs : ●
●
le premier ET logique est réalisé entre l’adresse IP de l’expéditeur et son masque, le résultat est l’adresse réseau de l’expéditeur ; le second ET logique est réalisé entre l’adresse IP du destinataire et le masque, le résultat est comparé à l’adresse réseau de l’expéditeur.
En cas d’égalité, les deux machines sont adjacentes c’estàdire directement connectées. La figure suivante résume cette séquence d’évènements. PC11 d’adresse 10.0.11.2/24 tente un ping sur l’adresse de PC15 10.0.11.5 :
L’expéditeur connaîtil une passerelle ? Dernier scénario pour l’expéditeur, le test d’adjacence a montré que le destinataire n’était pas directement connecté. La solution consiste alors à confier le datagramme à un périphérique intermédiaire, le routeur, qui fait office de passerelle vers le réseau qui héberge le destinataire. L’adresse de la passerelle par défaut est un élément clé de la configuration IP de la machine. La figure suivante illustre ce scénario. PC11 d’adresse 10.0.11.2/24 tente un ping sur l’adresse extérieure 10.0.22.2. La configuration IP de PC11 comporte la passerelle par défaut 10.0.11.1 :
L’acheminement de datagramme via la passerelle nécessite que station et passerelle partagent le même réseau. - 4-
Station et passerelle sont directement connectées ! L’acheminement vu par la station, synthèse partielle Au final, et puisque le cas d’une adresse de destination locale à la machine est avant tout un cas d’administrateur, émettre un datagramme revient pour la station à se poser une seule question : l’adresse du destinataire estelle directement connectée ou pas ?
Dans le premier cas, le datagramme est envoyé directement au destinataire. Dans le second cas, il est confié à la passerelle, charge à elle de le faire progresser vers sa destination. Ce faisant, on a reporté la complexité du routage et la nécessaire connaissance du réseau sur le routeur, un équipement spécialisé pour cette tâche. La configuration IP de la machine conditionne le fonctionnement décrit. Les manipulations autour de ces thèmes ont déjà été réalisées, en forme de rappel donc, la figure suivante montre comment imposer ou vérifier la configuration IP d’une machine :
Que se passetil quand le réseau de l’émetteur comporte plus d’un routeur ? Pour chaque station, l’administrateur attribue la fonction passerelle par défaut au routeur le plus approprié parmi les routeurs présents sur le lien local. Quand ce routeur reçoit un datagramme et constate à l’examen de l’adresse de destination qu’un autre routeur est plus approprié, il le fait savoir à la station en utilisant un message ICMP de redirection.
4. Trouver le routeur destinataire, Notion de route Le routeur passerelle se voit confier les datagrammes dont l’adresse de destination est extérieure au réseau. Charge à lui de les faire progresser vers leur destination et pour ce faire, le routeur consulte sa table de routage à la recherche d’une route vers le réseau en question. Comment se présente une route dans cette table de routage ?
A minima, il s’agit d’une correspondance entre un réseau qu’il est possible d’atteindre et l’adresse IP du prochain routeur à qui il faut confier les datagrammes pour s’approcher de ce réseau ou l’atteindre. Ainsi dans l’exemple ci dessus, le routeur R11 pour atteindre le réseau 10.0.12.0/24 doit confier les paquets à l’adresse 10.0.8.12. La route est donc la correspondance 10.0.12.0/24 via 10.0.8.12. L’apprentissage de cette route et par suite, le remplissage de la table de routage peut être le fait de l’administrateur, on parle alors de routage statique. Il existe également des protocoles de routage qui, par des échanges réguliers entre routeurs, permettent à chacun des routeurs de découvrir des informations de route ou de topologie de réseau, le remplissage de la table de routage est alors automatisé, ce que l’on désigne par routage dynamique. Sans entrer de route statique et sans avoir mis en œ uvre un quelconque protocole de routage, on pourrait penser que la table de routage est vide. Mais si l’administrateur a fourni la configuration IP des interfaces du routeur, celuici déduit de cette configuration les réseaux auxquels il est directement connecté, qui sont autant de routes immédiatement présentes dans la table de routage :
Toutes les routes n’ont pas le même degré d’acuité. Vous êtes à Bruxelles et vous allez à Marseille. Au premier croisement, deux routes se présentent : le panneau indicateur de la première indique « Toutes directions », le panneau de la seconde indique « Marseille ». Vous êtes intrigué mais vous choisissez la seconde. Ainsi, le réseau 10.0.22.0/24 englobe la machine 10.0.22.2 mais le réseau 10.0.16.0/21 englobe le réseau 10.0.22.0/24 et donc la machine 10.0.22.2. Dans sa table de routage, pour l’adresse de destination 10.0.22.2, le routeur préfèrera la route la plus spécifique 10.0.22.0/24 à la route la plus générale 10.0.16.0/21 :
Pour trouver la route la plus spécifique, le processus de routage utilise l’algorithme de recherche de correspondance de préfixe la plus longue (« Longest Match based Forwarding Algorithm »). Si toutes les recherches précédentes ont échoué, le processus de routage utilise la route par défaut si elle existe. Enfin, pour le cas ultime où le processus de routage n’a pas trouvé de route et ne dispose pas d’une route par défaut, le datagramme est supprimé (« dropped », c’est l’action Poubelle) et le routeur génère un message ICMP « Destination Host Unreachable » destiné à alerter l’émetteur du datagramme supprimé. Dans ses activités de maintenance ou de mise au point, le contrôle des routes qui composent la table de routage du routeur fait partie des outils essentiels de l’administrateur. Sur les routeurs CISCO, la commande permettant d’afficher l’état en cours de cette table est : Router> show ip route Il n’y a pas de différence conceptuelle entre le processus de routage d’un routeur et celui d’une machine d’extrémité. Les deux utilisent une table de routage. L’approche qui consiste à indiquer dans la configuration IP de la station l’adresse d’un routeur privilégié appelé Passerelle par défaut revient à créer une route par défaut dans la table de routage de la machine. Pour observer la table de routage de votre PC, en invite de commandes, tapez au choix l’une des commandes suivantes : c:\> netstat -r c:\> route print Pour PC11, cette route par défaut est 0.0.0.0/0 (le reste du monde) via 10.0.11.1 (la passerelle par défaut).
5. Trouver la machine finale Le routeur R22 consulte sa table de routage et découvre que l’adresse de destination appartient à un réseau directement connecté :
6. Travaux pratiques : l’acheminement Ces notions sont immédiatement vérifiables à l’aide d’une simulation Packet Tracer. Sur le site ENI, téléchargez la mise en situation TP1_9a.pkt. Une aide à l’utilisation de cet outil est fournie au chapitre Annexes Prise en main de l’outil de Simulation Packet Tracer.
■
Exécutez Packet Tracer et avec lui, ouvrez la simulation.
■
a. Étape 1 : Visualisation de la table de routage Seules les interfaces sont configurées sur les routeurs de cette simulation. Par conséquent, les seules routes connues au démarrage de ce TP sont les réseaux directement connectés. ■
Restez dans le mode Temps réel.
■
Cliquez une fois sur le routeur R11 puis activez l’onglet CLI (Command Line Interface).
■
Appuyez sur la touche [Entrée] jusqu’à voir apparaître le prompt R11>.
■
Tapez la commande : R11> sh ip route La commande « sh » est l’abrégé de « show ». Vous devriez obtenir : C 10.0.8.0 is directly connected, FastEthernet0/0 C 10.0.11.0 is directly connected, FastEthernet0/1
■
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. ■
Cliquez une fois sur le routeur R12 puis activez l’onglet CLI (Command Line Interface).
■
Appuyez sur la touche [Entrée] jusqu’à voir apparaître le prompt 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.
■
Tapez les commandes : 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 : C 10.0.8.0 is directly connected, FastEthernet0/0 S 10.0.11.0 [1/0] via 10.0.8.11 C 10.0.12.0 is directly connected, FastEthernet0/1 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. ■
Cliquez une fois sur PC11 puis activez l’onglet Desktop et cliquez sur Command Prompt.
■
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.
■
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 les commandes : 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.
■
Tapez les commandes : R11(config)# exit R11# sh ip route
Vous devriez obtenir : C 10.0.8.0 is directly connected, FastEthernet0/0 C 10.0.11.0 is directly connected, FastEthernet0/1 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. ■
Cliquez une fois sur PC11 puis activez l’onglet Desktop et cliquez sur Command Prompt.
■
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.
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.
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.
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 : ●
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.
■
Exécutez Packet Tracer et avec lui, ouvrez la simulation. 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. Cette séance de travaux pratiques est terminée.
Sousréseaux et surréseaux 1. Adressage par sousréseaux RFC utile : ●
RFC950 Internet standard Subnetting Procedure Août 1985.
Internet s’est trouvé un temps menacé par la pénurie d’adresses. Le réseau né dans les années 1980 était alors confidentiel, l’espace d’adressage paraissait plus que suffisant et on a sans doute à l’époque distribué les blocs d’adresses avec un peu de légèreté. Le système de classes contribuait au gaspillage, les besoins des entreprises étant souvent supérieurs à ceux pouvant être satisfaits par la classe C sans toutefois justifier l’attribution d’adresses de classe B. L’adressage par classes est devenu tout à fait inadapté mais il fallait pourtant tenter de préserver les attributions déjà réalisées. Une partie de solution a été adoptée en 1985 en proposant la possibilité de structurer l’espace d’adressage d’un réseau de classe A, B ou C :
L’idée consiste à « emprunter » un nombre de bits à définir dans l’adresse hôte afin d’en faire une adresse de sous réseau : ●
un bit emprunté permet de définir deux sousréseaux et donc de diviser l’espace de départ en deux parties égales ;
●
deux bits empruntés permettent de définir 4 sousréseaux (cas de l’illustration) ;
●
trois bits empruntés permettent de définir 8 sousréseaux et ainsi de suite.
Vu de l’extérieur, l’adresse du réseau est toujours valide, un datagramme destiné à l’une des machines de l’un quelconque des sousréseaux est toujours transporté par l’Internet en mettant à profit l’adresse réseau, il n’y a donc pas d’impact sur l’Internet mondial. En interne par contre, il devient possible pour l’entreprise de mieux structurer son espace d’adressage et cela peut contribuer à éviter des demandes de blocs d’adresses supplémentaires dont l’objet ne serait pas de pourvoir un besoin d’adresses mais bien de permettre cette structuration. C’est à l’administrateur qu’il revient de fixer la frontière entre l’adresse sousréseau et l’adresse hôte selon les besoins de l’entreprise, chaque bit emprunté supplémentaire multiplie par deux le nombre de sousréseaux et divise par deux le nombre potentiel de machines à l’intérieur d’un sousréseau. Les critères sont au choix, soit le nombre de machines qu’il lui faut atteindre dans chaque sousréseau, soit le nombre de sousréseaux qu’il lui faut constituer. Découpage en sousréseaux d’une adresse réseau de classe B :
Découpage en sousréseaux d’une adresse réseau de classe C :
Exemple : Subnetting Vous êtes administrateur chez un important opérateur et avez « hérité » de l’adresse de classe C 194.2.16.0/24. On vous demande de diviser cet espace en 10 sousréseaux différents. La solution consiste à emprunter 4 bits de l’adresse hôte, ce qui en première approximation, devrait permettre de créer 16 sousréseaux. En réalité, dans un tel découpage, on évitait d’utiliser le premier ainsi que le dernier sous réseau. En effet, dans le cas du premier sousréseau, il y a ambiguïté sur son adresse qui, à moins d’y associer le masque, est identique à l’adresse réseau. Quant au dernier sousréseau créé, c’est son adresse de diffusion qui se confond avec celle du réseau d’origine. Une fois le nombre de bits empruntés fixé, il devient possible de déduire le masque de sousréseau : ●
Le masque de classe est /24, 4 bits sont empruntés, le masque de sousréseau est /28 ;
●
Soit 1111 1111.1111 1111. 1111 1111.1111 0000 ;
●
Et en réaffectant les poids 128 64 32 16 8 4 2 1, le masque est 255.255.255.240.
Chaque station d’un sousréseau doit être configurée avec ce masque et non avec le masque de classe afin que le test d’adjacence soit à même de faire ce pourquoi il est conçu : déterminer si l’adresse de destination est directement connectée (appartient au même sousréseau) ou pas. Dans le premier cas, le datagramme est envoyé directement au destinataire (précédée d’une requête ARP si son adresse physique n’est pas connue). Dans le second cas, le datagramme est remis à la passerelle par défaut. Ensuite, chaque combinaison de bits empruntés fournit un sousréseau. À l’intérieur de l’une de ces combinaisons : ●
tous les bits de l’adresse hôte à zéro fournissent l’adresse de sousréseau ;
●
tous les bits de l’adresse hôte à un fournissent l’adresse de diffusion de ce sousréseau.
Par sousréseau, c’est à nouveau deux adresses qui sont perdues. Faisons un bilan dans le cas de cet exemple : ●
●
avant le découpage : un bloc de classe C permet 254 adresses ; après le découpage avec emprunt de 4 bits, chaque sousréseau peut comporter 14 machines (2^4 2), il reste donc 16 x 14 = 224 adresses.
La figure suivante tente de résumer la façon de faire. Que le lecteur se rassure, chaque découpage n’entraînera pas
autant de gaspillage de papier. Mais nous sommes sur un point de compréhension capital et il est impératif que le lecteur administrateur en devenir soit à l’aise avec ces notions. Il existe bien des « calculettes IP » mais bien sûr, impossible d’en disposer pendant l’épreuve du CCNA. Vos seuls outils seront alors une planchette type tableau blanc et un feutre effaçable. Pas de papier, on comprend aisément pourquoi. Attention, les trois premiers octets sont représentés dans la notion décimale tandis que le quatrième est représenté en binaire. Voici les deux premiers ainsi que les deux derniers sousréseaux résultant du découpage :
Il est conseillé de reporter les résultats du découpage dans un tableau à raison d’une ligne par sousréseau de la façon suivante : Adresse réseau : 194.2.16.0/24 Bits empruntés : 4
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.
■
Exécutez Packet Tracer et avec lui, ouvrez la simulation.
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. Cette séance de travaux pratiques est terminée.
3. Masque de longueur variable VLSM Dans le découpage d’un réseau avec classe, nous avons observé qu’il était possible de fragmenter le réseau initial de la façon la plus grossière à la façon la plus fine, afin d’épouser au mieux les besoins de structuration d’une organisation. Dans le même temps, nous avons observé que, vu de l’extérieur, la route qui menait vers cet ensemble de sous réseaux n’était pas modifiée par l’opération de découpage. La route devient une « superroute » vers un ensemble de réseaux ! Nous avons pu mesurer l’intérêt de cette route agrégée sur le volume des tables de routage.
Pourquoi ne pas étendre le procédé audelà de la simple idée de départ qui consistait à offrir un moyen de structurer. Dans le découpage en sousréseaux, la longueur du préfixe n’est plus imposée par la classe d’adresse mais choisie, à condition d’être plus long que le préfixe initial de la classe. Pour profiter de cette possibilité d’agréger plusieurs routes en une seule, l’idée consiste à autoriser toute longueur de préfixe et donc à abandonner le système de classes pour adopter VLSM (Variable Length Subnet Mask). Étudions un cas concret afin de mesurer la portée d’une telle décision. L’administrateur de l’entreprise Primevère a négocié un préfixe suffisant pour attribuer des adresses à un parc de 6000 machines. Le développement régulier de son entreprise le rend prudent et il a obtenu le préfixe 10.0.0.0/19. Cela signifie qu’il dispose de 13 bits pour l’espace d’adressage de son entreprise. 13 bits représente 2^13 2 = 8190 adresses potentielles avant structuration. Première observation : imaginons ce qu’il serait advenu dans l’ancien système d’attribution avec classes. Son besoin ne pouvait être satisfait qu’en lui attribuant au choix 33 adresses de classe C (8190/254 = 32,xxx) ou une adresse de classe B, mais dans ce cas, l’Internet mondial se voyait privé de 65534 adresses dont seulement 8190 utiles. L’entreprise Primevère avant structuration de l’espace d’adressage :
L’entreprise couvre trois sites d’égale importance, l’administrateur décide de créer un quatrième site de réserve et donc de diviser l’espace initial en quatre parties égales. Pour ce faire, il faut emprunter deux bits au champ de 13 bits initial, la longueur de préfixe pour chacun des quatre réseaux résultants est /21 :
Le site Nord a immédiatement besoin de trois réseaux d’environ 250 machines. Chacun de ces réseaux nécessite un préfixe /24 (l’ancien préfixe de la classe C) et puisque le préfixe attribué au site Nord est /21, il est possible d’y créer 8 réseaux /24. D’autres façons de diviser sont envisageables, par exemple toujours en partant du préfixe du site Nord /21, il serait possible de créer un réseau /22 et quatre réseaux /24. En imaginant que le site Sud ait des besoins symétriques au site Nord, la structuration résultante est :
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).
Exercice 9.1 : découpage VLSM Allons encore plus avant dans notre scénario. M. COUSIN, administrateur d’un parc de 500 adresses dans le site Nord se voit déléguer le bloc 10.0.14.0/23. Il peut vouloir l’utiliser en globalité ou à nouveau réaliser un découpage VLSM. Question 1 Si M. COUSIN utilise le préfixe dans sa globalité, quelles sont les adresses du premier hôte, du dernier hôte, de diffusion ? Question 2 Réalisez à votre tour un découpage en tableau « dichotomique » en arrêtant la division au préfixe /28. La solution de cet exercice est donnée au chapitre Corrigé des exercices Solution exercice 9.1 : découpage VLSM.
4. Travaux pratiques : routes statiques agrégées Ces notions sont vérifiables à l’aide d’une simulation Packet Tracer. ■
Sur le site ENI, téléchargez la mise en situation TP_9d.pkt.
■
Exécutez Packet Tracer et avec lui, ouvrez la simulation.
Soyons ludiques, l’auteur vous lance un défi. Vous disposez d’un capital de 14 routes statiques à répartir sur l’ensemble des routeurs de cette configuration qui nous est maintenant familière. Chaque route peut être agrégée ou pas. Seul le lien à haut débit sera utilisé entre les deux routeurs R8 et R16. Une fois les routes statiques entrées (au plus 14), chacun des quatre PC doit pouvoir communiquer avec les trois autres, ce dont on s’assurera avec des commandes ping.
La solution à ce problème est proposée dans le chapitre Corrigé des exercices Solution Travaux pratiques : routes statiques agrégées.
5. Synthèse découpage/agrégation L’idée d’un préfixe de longueur variable est déjà présente dans le RFC950 en 1985 : « la taille du masque bien que constante dans un réseau donné, varie d’un réseau à l’autre…. Une caractéristique intéressante de l’autoencodage est qu’il permet la division de l’espace d’adressage d’un réseau en sousréseaux de différentes tailles… ». L’IETF a adopté VLSM et le routage sans classe CIDR en 1993 (RFC 1517, 1518, 1519). En guise de synthèse, faisons l’inventaire des avantages : ●
●
VLSM permet une attribution plus fine des blocs d’adresses, une attribution qui « colle » au besoin ; Il devient possible d’agréger les routes et par suite, de réduire le volume des tables de routage (ou de le contenir). En diminuant le temps de recherche dans les tables, on améliore également les performances du routage.
et des contraintes… ●
●
●
●
L’assignation des préfixes doit être topologique. Les informations de route échangées entre routeurs et qui jusquelà ne contenaient que des adresses de destination connues ont dû être adaptées pour transporter également le masque associé à chaque adresse. Ceci justifie la version 2 du protocole de routage RIP également en 1993. Difficile de changer de fournisseur sans changer d’adresses (il faut changer de branche dans l’arborescence de préfixes). Il a fallu modifier l’algorithme utilisé par le processus de routage implanté dans les routeurs pour adopter l’algorithme de la correspondance la plus longue (relire si nécessaire la section La problématique du routage Trouver le routeur destinataire, Notion de route dans ce chapitre).
La compétence qui consiste à diviser un réseau de classe en sousréseaux n’a plus cours. Elle constitue cependant un bon point de départ pour acquérir la compétence qui consiste à diviser et structurer un préfixe en mettant à profit des masques de longueur variable VLSM.
Le routeur dans son environnement Le vocable routeur peut recouvrir des réalités bien différentes selon que l’on a affaire à un routeur d’agence ou de succursale, un routeur d’entreprise ou de campus ou enfin à un routeur de fournisseur de services. Pour répondre à ces différents besoins, CISCO a segmenté son offre en trois familles d’équipements : « Branch » traduisible par agence, succursale, site distant. Les routeurs proposés par le constructeur pour répondre aux problèmes spécifiques de l’agence sont dits à services intégrés, ou routeurs ISR (Integrated Services Routers).
●
« WAN » : les routeurs de cette gamme affichent évidemment de grandes ambitions en matière de performances, d’intégration de la sécurité, de communications temps réel. Le routeur WAN propose bien davantage que le simple transport de données fiable et peut devenir une plateforme de convergence de la communication d’entreprise.
●
« Service Provider » (Fournisseur de services) : les routeurs de cette gamme, outre des performances exceptionnelles, doivent également offrir un degré de disponibilité très élevé, une très grande longévité ainsi que la possibilité de faire évoluer en taille les dispositifs sans remise en question de l’existant.
●
1. Le routeur d’agence ou de succursale Un routeur qui se contenterait d’assurer sa fonction première c’estàdire l’acheminement des datagrammes IP, aurait peu de chances de pouvoir satisfaire les attentes des clients. Le contexte des communications est en mouvance rapide, accélérée encore par des accès toujours plus fluides vers l’Internet ainsi que par les possibilités toujours accrues offertes par l’électronique. Ainsi par exemple, un téléphone portable aurait peu de chances de se vendre avec l’unique fonction téléphone. Il est également devenu lecteur MP3, appareil photo, caméscope, navigateur Web, support de stockage, dispositif d’authentification et sans doute demain, seratil à même de satisfaire d’autres besoins que nous n’avons pas encore imaginés. De même, un ordinateur n’est plus la machine de calcul des temps héroïques mais une machine « World Gate » ouverte sur le monde, multimédia, capable autant de lire ou d’enregistrer un DVD que de servir de téléphone VoIP, de TV et presque accessoirement de participer à quelque travail en cours. De 2006 à 2009, CISCO a écoulé plus de 5 millions de routeurs ISR et doit ce succès à son analyse de ce qu’est devenue l’activité économique. Une entreprise, ce n’est plus un siège où se concentre l’exécutif et qui pilote de façon autocratique des sites de production. L’entreprise moderne résulte du maillage de nombreux sites (CorporateBranch que l’on peut traduire par succursale) et de telles infrastructures sont efficaces à la condition que la prise de décision puisse être également décentralisée sans perdre la cohérence avec le reste du groupe, ce qui suppose une architecture réseau disponible et fiable. Après différentes enquêtes menées auprès de ses clients, CISCO recense les besoins suivants : ●
Routage.
●
Commutation (switching).
●
Connexion sécurisée via VPNs.
●
Fonctions de sécurité toujours plus importantes : ●
Parefeu.
●
Détection/Prévention d’intrusions.
●
Atténuation de la gravité des attaques par déni de service distribuées (c’estàdire des attaques par déni de service dans lesquelles le serveur cible est attaqué de façon simultanée par plusieurs ordinateurs).
par l’entreprise (état de la protection antivirus, mises à jour de sécurité, présence d’un certificat…) et regroupés dans la notion de contrôle d’accès au réseau (NAC : Network Admission Control). ●
●
●
●
Filtrage d’URL...
Applications dites collaboratives : téléphonie sur IP, intégration voixvidéo, vidéoconférence. Optimisation de la bande passante consommée sur le WAN (techniques de compression de la charge utile des paquets, de multiplexage des sessions TCP, d’élimination de la redondance des entêtes). Prise en compte de la mobilité avec les applications sans fil.
Un routeur ISR intègre outre le routage, tout ou partie des fonctions citées. La gamme de routeurs ISR comprend les séries 800, 1800, 2800, 3200 et 3800. Ce qui est bon pour un routeur d’agence ne l’est pas nécessairement dans le cadre d’un apprentissage des fondements des réseaux. C’est pourquoi pour le CCNA, CISCO maintient l’usage de routeurs et commutateurs séparés.
2. Les routeurs WAN CISCO range dans cette catégorie les routeurs des séries 7200, 7300, ASR1000, 6500 et 7600.
3. Les routeurs « Service Provider » CISCO classe dans cette catégorie les séries ASR1000, ASR9000, 7600, 10000 et XR12000 ainsi que la plateforme CRS1 (Carrier Routing System).
Le routeur : un ordinateur spécialisé 1. Architecture Découvrons les principaux blocs fonctionnels qui constituent un routeur et distribuons les rôles :
Si sur un routeur d’entrée de gamme la plupart des composants sont soudés sur la carte mère, au fur et à mesure que l’on monte en gamme, la conception est de plus en plus modulaire. Les interfaces réseau connectent le routeur à différents réseaux. Un trafic entrant par une interface est commuté par le routeur vers l’interface sortante. CISCO propose évidemment une vaste gamme de types d’interfaces et il est peu probable qu’un cahier des charges ne puisse être tenu. Le routeur dispose toujours d’un ou deux ports, Ethernet ou FastEthernet, intégrés mais les autres interfaces, WAN notamment, sont ajoutées par l’intermédiaire de cartes qui viennent prendre place dans des emplacements appelés slots. L’unité centrale est basée sur une architecture RISC (Reduced InstructionSet Computer ou microprocesseur à jeu d’instructions réduit). Classiquement on oppose ce type d’architecture à l’architecture CISC (Complex InstructionSet Computer) dont les représentants les plus fameux sont les processeurs x86 qui ont équipé nos PC au moins jusqu’à la génération 486. Un processeur CISC dispose d’un jeu d’instructions que l’on a peutêtre enrichi à l’excès. En effet, chacune des instructions complexes de ce jeu d’instructions demande plusieurs cycles de lecture de la mémoire ROM qui contient le microcode (mémoire intégrée sur la puce du processeur). C’est la firme IBM qui en 1975, inventa le processeur RISC dont le jeu d’instructions était réduit de façon à permettre l’exécution d’une instruction par cycle d’horloge. Outre cet avantage, le décodage des instructions étant plus simple, il peut être câblé plutôt que microcodé et ainsi occuper moins d’espace sur la puce. Il semble que la polémique qui oppose les tenants de chacune de ces architectures soit en passe de s’éteindre, faute de combattants. En effet, à partir du Pentium, INTEL a adopté une architecture hybride dans laquelle est enfoui un processeur RISC, le fonctionnement CISC étant conservé mais émulé. CISCO étant peu disert sur le sujet, difficile de savoir quels sont les processeurs adoptés par la firme pour équiper ses routeurs. Par exemple, sauf erreur, il n’existe aucune commande « show » qui permettrait d’afficher le type de processeur. Pour les plus curieux, il faut donc se résoudre à ouvrir les boîtiers puis relever les références des circuits et entamer une recherche patiente sur le net. Ainsi on découvre que le routeur ISR (Integrated Services Router) 2801 embarque un processeur RM5261A250H, processeur RISC 64 bits conforme à l’architecture MIPS (c’estàdire architecture RISC développée par la compagnie MIPS). Pour l’anecdote, outre les routeurs CISCO, des processeurs conformes à cette architecture équipent également des consoles de jeux type PlayStation. Les lecteurs insatiables pourront trouver d’autres détails sur le site : http://www.pmcsierra.com/products/details/rm5261a/#Features En fait, le microprocesseur effectue sans doute les tâches génériques car, toujours sur la carte mère du routeur 2801, on remarque la présence d’un contrôleur de communications de type GT96103A et pour lequel quelques détails sont fournis sur le site :
http://www.marvell.com/products/communication/horizon/index.jsp Selon la firme MARVELL qui l’a conçu, ce contrôleur rassemble les fonctionnalités suivantes : ●
Routage entre LAN et WAN
●
Passerelle Voix sur IP
●
Sécurité
●
Qualité de service
Que le lecteur se rassure, le passage de l’examen CCNA ne requiert aucune connaissance en la matière. Ceci se justifie parfaitement, car quel que soit le processeur embarqué, le système d’exploitation reste CISCO IOS et c’est lui que l’administrateur doit maîtriser. D’anciens routeurs étaient équipés dans le passé de microcommutateurs qui participaient à la configuration de l’équipement. CISCO a pérennisé les pratiques acquises alors en remplaçant ces micro commutateurs par un registre de 16 bits appelé « configregister ». La valeur stockée dans ce registre est maintenue en l’absence d’alimentation. De plus, la commande qui permet d’écrire dans ce registre n’a pas besoin d’être suivie d’une commande de sauvegarde. Ce registre intervient notamment dans la séquence de démarrage, son utilité est détaillée dans la section Gestion de la plateforme logicielle CISCO IOS La séquence de démarrage.
2. Les ports d’administration Le lecteur peu au fait du standard RS232 ou du mode de fonctionnement asynchrone gagnera à lire la section Liaisons série synchrone/asynchrone du chapitre Annexes de cet ouvrage. En dehors des interfaces réseau, le routeur est pourvu de deux interfaces de type série asynchrone, nommées port console et port auxiliaire et dédiées à l’administration du système. Le port console autorise un accès local et l’administrateur l’utilisera plutôt pour réaliser la configuration initiale du routeur. En effet, une fois configuré et en exploitation, le routeur est accessible par le réseau et l’administrateur peut en assurer la gestion à l’aide d’une session TELNET ou SSH (Secure Shell, version sécurisée destinée à remplacer TELNET). La seconde interface série, nommée port auxiliaire permet un accès de l’administrateur à distance. Un scénario possible est de reprendre la main sur l’équipement distant quand l’administrateur n’y parvient plus par le réseau. Pour profiter de cette possibilité, il faut avoir été prévoyant, c’estàdire avoir installé un modem au voisinage du routeur et avoir amené une ligne du réseau téléphonique commuté sur ce modem, ce qui revient à attribuer un numéro de téléphone au routeur. Une exception cependant : les routeurs de la gamme 800 ne disposent que d’un seul port série asynchrone destiné à l’administration. Appelé « console aux port », ce port est, selon le choix de l’administrateur, tantôt un port console, tantôt un port auxiliaire. En fait, il n’y a pas de différence de nature entre le port console et le port aux, les deux ports sont des ports série - 2-
asynchrones. La différence vient du câblage qu’en fait CISCO sur la face avant de ses routeurs. S’il avait fallu se conformer strictement à la norme RS232, le port console aurait dû se présenter sous la forme d’un port DB25 femelle et l’extrémité être de type ETCD (en anglais DCE) afin de faire face au terminal nécessairement ETTD (DTE). Le port auxiliaire lui, aurait dû adopter un port DB25 mâle et adopter le type ETTD pour faire face au modem nécessairement ETCD. C’est ce que CISCO a fait sur certains de ses routeurs, par exemple quelques routeurs de la série 7200 (7200 I/OFE, 7200I/O, 7200I/OFEMII). Mais CISCO, sur la plupart de ses routeurs, a préféré privilégier la recherche de compacité et les deux ports ont été câblés sur des sockets RJ45. Sur toute la gamme, il est facile de distinguer les deux sockets grâce à un code de couleurs : le socket attribué au port console est repérable à sa couleur bleu ciel, le socket attribué au port auxiliaire est repérable à sa couleur noire. En dehors de la couleur, les ports console et auxiliaire se distinguent également par les choix qu’a fait le constructeur quant aux circuits de la norme RS232 présents sur les 8 fils des sockets et quant à l’état de ces circuits, opérationnel ou forcé. En effet, les contraintes imposées par la liaison avec un terminal ne sont pas les mêmes que celles imposées par une liaison via modems. À moins d’avoir affaire à un administrateur fou, aucun risque pour que les caractères frappés au clavier du terminal et donc reçus par le port console ne saturent la capacité de réception du routeur sur ce port. De la même façon, il est peu probable que les caractères générés par le routeur ne dépassent les capacités d’affichage à l’écran du terminal (qui dépassent largement les capacités de lecture de l’administrateur et plus encore ses capacités à interpréter les messages). Le contrôle de flux est donc inutile sur ce port et CISCO n’en prévoit aucun, ni logiciel (à l’aide des caractères XON/XOFF), ni matériel (fondé sur l’état de l’un des circuits de la jonction). En revanche, le port auxiliaire dispose des circuits nécessaires à la réalisation d’un contrôle de flux matériel. CISCO fournit également les cordons et adaptateurs nécessaires à la mise en œ uvre de ces ports. En parcourant les guides d’installation des différents modèles de la gamme (tous téléchargeables sur le site CISCO), on peut dégager trois types de packagings : ●
●
Packaging 1 > Concerne les séries 800, 1800 et le routeur 2801. Le routeur est fourni avec : ●
Un câble console (RJ45toDE9, couleur bleu ciel) également appelé « management cable ».
●
Un adaptateur DE9toDB25.
Packaging 2 > Concerne les séries 2800 à l’exception du routeur 2801, 3800, 7200, etc. Le routeur est fourni avec : ●
●
●
Un câble console (RJ45toDE9, couleur bleu ciel) également appelé « management cable » ou « console adapter câble ». Un câble modem (RJ45toDB25, couleur noir) également appelé « modem adapter cable ».
Packaging 3 > Concerne les séries 2600, 3600, 3700 et 3800. Le routeur est fourni avec un kit comprenant : ●
●
●
●
Un câble inversé (RJ45toRJ45) appelé « rollovercable » dans la documentation CISCO. Un adaptateur RJ45toDE9 femelle permettant la connexion du port console au port série d’un PC émulant le terminal. Cet adaptateur porte la mention « TERMINAL ». Un adaptateur RJ45toDB25 femelle permettant la connexion du port console au port série d’un terminal. Cet adaptateur porte également la mention « TERMINAL ». Un adaptateur RJ45toDB25 mâle permettant la connexion du port auxiliaire au port série d’un modem. Cet adaptateur porte la mention « MODEM ».
La photo cidessous rassemble les éléments du kit fourni avec les séries 2600, 3600, 3700 et 3800 à l’exception de l’adaptateur modem :
Réglons le cas du câble inversé « rollover » qui fait décidément couler beaucoup d’encre. Ce câble résulte simplement du fait que CISCO utilise du câble en nappe pour réaliser ses cordons destinés aux ports d’administration. Dans ce câble en nappe, les 8 fils cheminent de façon parallèle et ne sont pas organisés en paires. Les cordons réalisés avec une telle nappe ne pourraient supporter les débits des réseaux locaux. Fort heureusement, les débits à supporter sont ceux d’une liaison série asynchrone RS232 et ne devraient donc jamais dépasser 19200 bits/s (il est possible de régler la jonction à 115200 bits/s mais c’est hors standard). Il faut observer que le sertissage d’un connecteur RJ45 à chaque extrémité d’une nappe à 8 fils produit naturellement un câble inversé. Il ne faut pas y voir une volonté quelconque du constructeur mais simplement une conséquence du choix de la nappe en lieu et place d’un classique câble à paires torsadées. Si le lecteur dispose d’un câble inversé à proximité, c’est le moment de le vérifier en plaçant les deux connecteurs RJ45 en visàvis :
Les fils reliés à Pin 1 d’un connecteur et Pin 8 de l’autre connecteur ont même couleur, puis pin 2 et pin 7 et ainsi de suite. Même s’il ne s’agit que d’un avatar de cordon RJ45toRJ45, l’étudiant ajoutera le câble inversé (rollover) à la panoplie de types qu’il doit connaître, qui comprenait déjà le câble droit (straightthrough) et le câble croisé (crossover) car on imagine bien que ce sujet peut faire l’objet de nombreuses questions dans un QCM du CCNA. Le rétablissement des connexions attendues de façon à relier convenablement deux ETTD (Port console Terminal) ou un ETTD et un ETCD (Port auxiliaire Modem) incombe à l’adaptateur RJ45toDBxx. Ainsi, l’illustration suivante inventorie les circuits utilisés dans le cas d’une liaison port console terminal :
Observez que les circuits DTR (Data Terminal Ready) et RTS (Request To Send) du port console restent en permanence montés. On est ainsi assuré que le terminal, qui reçoit ces états sur ses circuits DSR (Data Set Ready) et CTS (Clear To Send) est « satisfait » et consentira à afficher les caractères reçus du routeur ainsi qu’à envoyer au routeur les caractères frappés au clavier. En final, il ne devrait subsister aucune ambigüité quand il faut relier le PC émulant un terminal au port console, c’est le câble console RJ45toDE9 qu’il faut utiliser (ou son équivalent reconstitué à l’aide du câble inversé bleu ciel associé à l’adaptateur RJ45toDE9), ce câble est de couleur bleu ciel, le socket du port console est également de couleur bleu ciel (le fil bleu sur le bouton bleu...). L’extrémité DE9 du câble console est femelle, le connecteur DE9 du port série du PC est mâle. Le placement d’une jonction éclatée à l’extrémité d’un câble console confirme que cette extrémité est bien de type ETCD. En effet, le voyant associé au circuit RD est allumé et confirme que ce circuit est générateur (au sens électrique), ce qui est bien le fait d’une jonction ETCD.
Il reste à ajuster les paramètres de la transmission série. Par défaut, le port console est réglé à 9600S81 ce qui signifie 9600 bits par seconde, sans parité, caractères exprimés sur 8 bits, 1 bit de stop. Ce réglage, noté 9600N81 dans la documentation CISCO (No parity) est modifiable mais il n’y a pas d’intérêt à le faire. Il faut ajuster à égalité les paramètres de la jonction du terminal ou du PC émulant le terminal. Inutile d’activer un contrôle de flux. Dans de rares cas, le constructeur préconise 9600N82, qui signifie deux bits de stop, ceci incombant sans doute à un circuit UART un peu plus ancien et ayant besoin d’un temps de « récupération » plus important entre deux caractères. Quant au port auxiliaire, il n’y a pas d’autre contrainte que celle qui consiste à le régler à égalité avec la jonction du modem (vitesse maximale 115200 bits par seconde).
3. Le partitionnement de la mémoire Le déroulement normal du démarrage d’un routeur doit aboutir au chargement d’un système d’exploitation appelé CISCO IOS (Internetworking Operating System). Muni de ce système, le routeur est alors capable d’accomplir les tâches pour lesquelles il a été conçu dont le routage des datagrammes IP. En dehors de ce système d’exploitation complet, le routeur est également capable de charger d’autres systèmes d’exploitation partiels ou dont la finalité n’est pas d’assurer le routage. Ainsi, le système d’exploitation nommé RxBOOT offre un sousensemble des fonctionnalités de l’IOS, suffisant pour monter les interfaces réseau et permettre la mise à jour des images IOS contenues en mémoire Flash. Il ne concerne que les routeurs (série 2500) qui exécutent l’IOS directement en mémoire Flash car comment mettre à jour un fichier en cours d’utilisation ? RxBOOT intervient également en cas de sinistre sur la mémoire Flash : si pendant son initialisation, le routeur n’est pas parvenu à trouver une image IOS valide et si il dispose d’une image RxBOOT, alors il tente de charger RxBOOT. Enfin, le système ROMMON (ROM Monitor) intéresse particulièrement l’expert réseau puisqu’il permet un premier niveau de débogage, la récupération de mots de passe perdus ou la copie d’un fichier IOS valide en mémoire Flash quand celleci a été corrompue ou effacée par maladresse. ROMMON équipe tous les routeurs CISCO. Le chargement de ROMMON intervient : ●
●
●
Quand l’administrateur interrompt la séquence d’amorçage normale. Quand l’administrateur a modifié le contenu du registre de configuration afin d’influer sur cette séquence d’amorçage. En ultime recours quand le routeur a échoué dans ses tentatives de chargement d’un IOS complet puis échoué également dans le chargement de RxBOOT s’il en dispose.
C’est la mémoire ROM (Read Only Memory) qui contient, outre le programme d’amorçage, ce ou ces systèmes d’exploitation alternatifs. La mémoire RAM (Random Access Memory que l’on traduit par Mémoire à accès direct) est une mémoire volatile
accessible à la fois en lecture et en écriture. Comme pour tout ordinateur, la mémoire RAM d’un routeur contient à la fois le code des applications et les données objet du traitement réalisé par le code. Dans le cas du routeur, le code est constitué par le système d’exploitation CISCO IOS chargé pendant le démarrage depuis la mémoire Flash ou par un système d’exploitation alternatif, RxBOOT ou ROMMON, chargé depuis la mémoire ROM. Les données comprennent la configuration courante du routeur, les structures de données liées aux protocoles de routage telles les tables de routage, les tables ARP (Address Resolution Protocol, voir ouvrage Cisco Notions de base sur les réseaux dans la collection Certifications aux Editions ENI), les tampons de paquets associés aux interfaces. Avant son chargement en mémoire vive, le fichier IOS occupe plusieurs Mégaoctets et est stocké dans une zone de mémoire semipermanente nommée Flash. Il s’agit d’une zone de mémoire réalisée à l’aide de dispositifs EEPROM (Electrically Erasable Programmable ReadOnly Memory). Une mémoire PROM peut être lue indéfiniment mais ne peut être écrite qu’une seule fois. Une mémoire EPROM peut être effacée mais nécessite pour ce faire d’être soumise à un rayonnement ultraviolet. La mémoire EEPROM est effaçable à l’aide d’un banal courant électrique. Il devient alors possible de reproduire le fonctionnement d’un disque dur (maintien des données hors alimentation, lecture à volonté, écriture quasi à volonté) sans l’inconvénient majeur du disque dur, c’estàdire sans pièce mobile. Ainsi stocké en mémoire Flash, l’IOS peut être mis à niveau (une nouvelle version remplace une version plus ancienne) ou modifié (une version aux capacités élargies remplace la version existante). Cela a été dit, certains routeurs permettent l’exécution directe de l’IOS depuis la mémoire Flash, l’espace de mémoire Flash appartient alors à l’espace adressable par le processeur. Mais le plus ordinairement, l’IOS est chargé en mémoire vive pendant le boot de l’équipement. La mémoire NVRAM est une mémoire RAM non volatile, c’estàdire une mémoire dont le contenu est conservé hors alimentation. CISCO place en NVRAM le fichier de configuration initiale du routeur nommé startupconfig. L’initialisation normale d’un routeur s’achève avec le chargement de ce fichier en mémoire vive. Une fois chargé, la copie est nommée runningconfig. La mémoire Flash offre un emplacement de stockage pour l’IOS. L’administrateur dispose de mécanismes permettant les mises à jour (téléchargement de nouvelles versions via TFTP). Parmi les quatre partitions de la mémoire, ROM, RAM, FLASH et NVRAM, trois sont permanentes, c’estàdire conservées hors alimentation. Seul le contenu de la RAM est perdu lors d’un arrêt ou d’un redémarrage du routeur. CISCO n’utilise aucun dispositif de mémoire type disque ou disquette sur ses routeurs. La réussite au CCNA suppose de bien connaître l’affectation des quatre partitions de mémoire.
4. Découverte physique Chaque modèle de routeur CISCO fait l’objet d’un guide d’installation très complet et qu’il est vivement conseillé de s’approprier avant de sortir le nouveau routeur de son carton. Si les méandres du site CISCO rebutent le lecteur, il suffit de laisser faire un quelconque moteur de recherche. Ainsi, la requête « Cisco 2800 Series Routers Hardware Installation » dans Google fournit en première réponse un lien vers la documentation demandée (186 pages !) qu’il est possible au choix de consulter en ligne ou de télécharger au format pdf. Nous appuierons notre propos sur le routeur 2801 mais une bonne part des éléments qui suivent est transposable au reste de la gamme :
Ce routeur appartient à la nouvelle génération de routeurs dits à services intégrés, ou routeurs ISR (Integrated Services Routers).
a. Localisation du numéro de série Cet identifiant de 11 caractères est situé à l’arrière du châssis dans le cas du 2801, sur la face des interfaces dans le cas des autres routeurs de cette série :
Il existe un site CISCO qui répertorie pour l’ensemble des produits CISCO, localisation et format du numéro de série : http://tools.cisco.com/Support/CPI/index.do. L’accès à cet outil demandera au lecteur de s’enregistrer s’il ne dispose pas encore de compte sur Cisco.com.
b. Les interfaces intégrées Le tableau suivant inventorie l’ensemble des interfaces disponibles sans qu’il ait fallu ajouter de modules supplémentaires : Modèle
c. La mémoire Les platesformes 2800 disposent des mémoires physiques suivantes : ●
●
●
- 8-
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.
Signalons également la possibilité d’équiper le châssis d’une alimentation redondante RPS675 (Redundant Power System).
e. Les voyants LED Tous les voyants du routeur 2801 sont placés en face avant : LED
Couleur
Description
SYS PWR
Vert
Le routeur a terminé sa séquence d’initialisation et l’IOS est fonctionnel. Ce voyant clignote pendant le boot ou si le système d’exploitation chargé est ROMMON.
SYS ACT
Vert
Clignote chaque fois que des paquets sont émis ou reçus ou en cours de traitement par le système.
CF
Vert
Allumé quand la mémoire Flash est occupée. Dans ce cas, il ne faut pas ôter la carte Compact Flash de son logement.
AUX/PWR
Vert/Ambre
Allumé, indique la présence du dispositif d’alimentation. Vert, indique le fonctionnement convenable de cette alimentation. Ambre, indique un défaut de l’alimentation.
FE x Link
Vert
Allumé indique que le router est connecté à un LAN Ethernet via le port Ethernet x.
Fe x 100
Vert
Allumé indique un lien fonctionnant au débit de 100 Mbps. Éteint indique un lien fonctionnant au débit de 10 Mbps.
Fe x FDX
Vert
Allumé indique un mode de fonctionnement Fullduplex. Éteint indique un mode de fonctionnement Halfduplex.
AIM 0
Vert
Allumé indique la présence d’un module AIM (Advanced Integration Module) dans le slot AIM 0.
AIM 1
Vert
Allumé indique la présence d’un module AIM dans le slot AIM 1.
PVDM 0
Vert
Allumé indique la présence d’un dispositif PVDM (Packet Voice Data Module) dans le slot PVDM 0.
PVDM 1
Vert
Allumé indique la présence d’un dispositif PVDM (Packet Voice Data Module) dans le slot PVDM 1.
Pour les autres châssis de la série, les voyants sont répartis sur la face avant et sur la face arrière : LED SYS PWR
AUX/PWR
Couleur
Description
Vert fixe
Le système est fonctionnel.
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.
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.
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.
F (=FDX)
Vert
Indique un fonctionnement en Fullduplex.
Éteint
Indique un fonctionnement en Halfduplex.
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
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.
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.
S (=Speed)
x = 0, 1 (ou 2 si 2821 ou 2851)
AIM x
Face arrière
x = 0, 1
f. Horloge Temps réel Comme tout ordinateur, un routeur est équipé d’un circuit assurant la fourniture de la date et de l’heure au système. L’important est que ce circuit nécessite toujours une batterie pour assurer son office. Ceci constitue un point de fragilité et nécessite de la vigilance. Dans le cas des châssis 2811, 2821 et 2851, CISCO a prévu une batterie montée « à vie », c’estàdire dont l’espérance de vie est identique à celle du routeur. Seul le châssis 2801 est pourvu d’une batterie lithiumion remplaçable.
g. Exploration du châssis Observez la face avant du routeur 2801 cidessous :
Repérez les éléments suivants : ●
4 emplacements prévus pour recevoir les cartes d’interface, notés slot 0 à slot 3. Slot 0 est situé à droite : ●
●
●
●
●
- 12 -
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.
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 :
deux slots d’extension prévus pour recevoir des modules PVDM.
5. Connecter le routeur à son environnement Certains ouvrages distinguent deux familles d’interfaces : les interfaces Ethernet et les interfaces série. Même si cette façon de classer trouve une explication dans le mode de nommage des interfaces adopté par CISCO, c’est assez gênant. En effet, le mode de transmission parallèle des informations n’existe plus guère qu’entre le processeur et ses voisins immédiats dont la mémoire. En dehors de ce petit monde, toutes les transmissions se font sous forme série c’estàdire sous forme d’une succession de bits, cela concerne également Ethernet. Par ailleurs, même si Ethernet règne sans partage sur le monde des réseaux locaux et a étendu son hégémonie aux réseaux métropolitains, il n’est pas d’hégémonie qui ne finisse par s’écrouler. Restons prudents donc en distinguant deux familles d’interfaces, les interfaces LAN et les interfaces WAN.
a. Connecter l’interface LAN d’un routeur Cas des interfaces Ethernet et Fast Ethernet Ce sujet a déjà été traité dans l’ouvrage Cisco Notions de base sur les réseaux dans la collection Certifications aux Editions ENI. En forme de rappel donc, chaque dispositif relié à un segment Ethernet est constitué d’une partie émission et d’une partie réception. La liaison réalisée doit nécessairement relier la partie émission d’un dispositif à la partie réception de l’autre dispositif. On parle de croisement et les possibilités pour réaliser ce croisement sont nombreuses. Un port Ethernet de routeur qui ne dispose pas de la fonction « Auto MDI/MDIX » (détaillée plus avant) est de type MDI (pas de croisement réalisé par l’équipement). Relier un tel port à un équipement de type MDIX (qui croise) permet d’utiliser un cordon dit « droit » (Straighttrough), cas normal illustré par la figure cidessous :
Le cas suivant est plus un cas d’école puisqu’il est question de relier directement un PC à un port Ethernet de routeur, de type MDI. Il peut également s’agir de réaliser une liaison Ethernet entre deux ports MDI de routeurs. Le cordon doit alors être croisé (Crossovercable), ce qu’illustre la figure suivante :
Il n’est pas conseillé de réaliser un tel cordon « à la main ». En effet, quand les ennuis surviennent, le doute quant au cordon croisé que vous avez péniblement réussi à confectionner revient de façon obsédante. Croisement du lien en 1000BaseT La spécificité de ce standard est d’utiliser les quatre paires du câble réseau :
Le croisement à réaliser est double. Quand il n’est pas réalisé par l’un des deux équipements, le cordon croisé est plus difficile à confectionner. Dans le but d’éliminer le besoin de câbles croisés entre deux équipements similaires, l’IEEE propose une configuration MDI/MDIX automatique (section 40.4.4 de la norme 802.32008_section3 disponible en téléchargement sur le site de l’IEEE). Le mécanisme mis en œ uvre intervient en amont de tout autre mécanisme, dont par exemple celui de l’autonégociation, afin de faciliter la commutation de [DA+, DA] sur [DB+, DB ] ainsi que de [DC+, DC] sur [DD+, DD]. Une extrémité « Auto MDI/MDIX » ou « Auto crossover » détermine de façon aléatoire une première configuration MDI ou MDIX, adopte cette configuration puis attend un temps suffisant pour assurer une détection normale des impulsions NLP ou FLP émises par l’autre extrémité. Le temporisateur correspondant est appelé « Sample_timer » et s’établit à 62 ms. Si le nœ ud reçoit les impulsions émises par le nœ ud distant, il reste dans la configuration adoptée. Si la partie réception n’a pas détecté les impulsions, l’algorithme prend une nouvelle décision MDI ou MDIX fondée sur le bit suivant du registre résultat du tirage aléatoire (qui en comprend 11) puis réarme le temporisateur d’écoute des impulsions. On comprend que l’automatisme fonctionne autant qu’il y ait une parmi deux ou les deux extrémités capables d’autoconfiguration MDI/MDIX. L’implémentation de cette possibilité est facultative pour le 1000BaseT mais semble largement adoptée. En fait, c’est à ce point pratique que certains constructeurs dotent dorénavant les ports Fast Ethernet de cette faculté. Il est probable qu’à terme, le besoin de cordons croisés disparaisse et avec lui la compétence qui consiste à déterminer le cordon convenable. Dans le cas du constructeur CISCO, l’adoption de cet automatisme est sans doute appelé à s’étendre mais ne concerne, au moment où ces lignes sont écrites, qu’une partie des équipements. Ainsi, en explorant à nouveau le document « Relevant interfaces and modules » de la série 2800, on découvre que les ports suivants en sont dotés : ●
Les ports embarqués Fast Ethernet des routeurs 2801 et 2811.
●
Les ports embarqués Gigabit des routeurs 2821 et 2851.
●
Les ports Ethernet routés des modules HWIC1FE et HWIC2FE.
●
Les ports Ethernet des modules de commutation HWIC4ESW et HWICD9ESW.
Mais on trouve également des ports non encore dotés tels les ports des modules de commutation NME16S, NMEX 23ES, NMEXD24ES (liste non exhaustive).
b. Connecter l’interface WAN d’un routeur L’entreprise « monosite » a vécu. L’entreprise moderne résulte du maillage de plusieurs sites dont le siège. Raccorder ces sites entre eux est hors de portée du réseau local. Voilà l’entreprise contrainte d’en passer par des services de réseau étendu, services fournis par un opérateur de télécommunications. L’opérateur de communications électroniques est une entreprise qui fournit ou est autorisée à fournir l’accès à un réseau de communications public. Détailler la diversité des services proposés par les opérateurs sort du cadre de ce chapitre mais quoiqu’il en soit, l’accès au service se fait systématiquement par l’intermédiaire d’un dispositif nommé selon les cas « boîtier », « modem » ou « DSU/CSU » (Data Service Unit/Channel Service Unit). Il n’y a pas hélas de terme générique qui permette de désigner sans ambigüité ce boitier d’interface avec le WAN. C’est que le service de réseau étendu peut recouvrir des réalités très différentes. De façon globale, le « boîtier » convertit les normes de couche 1 et 2 de l’interface WAN du routeur en normes de couches 1 et 2 du circuit WAN de l’opérateur. Appuyons notre raisonnement sur la figure ci
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 :
http://www.cisco.com/en/US/docs/routers/access/hardware/notes/marcabl.pdf Puisque le port WAN est générique, réaliser la jonction avec le boîtier suppose de choisir le cordon convenable. Hormis pour la norme EIA530, CISCO prévoit systématiquement deux types de cordons, l’un fournit une extrémité ETTD (DTE), l’autre fournit une extrémité ETCD (DCE). Pour EIA530, CISCO ne prévoit que le seul cordon de type ETTD (DTE). Le point commun de ces neuf cordons est d’avoir une extrémité WIC (« WIC end ») destinée à être connectée au port WAN côté routeur, désigné DB60. L’autre extrémité (« network end ») de chacun de ces cordons utilise le connecteur physique le plus communément rencontré pour la norme considérée. Ainsi, dans le cas d’EIA 232, l’extrémité réseau du cordon utilise un port DB25M (M pour mâle) quand le cordon est de type ETTD, DB25F (F pour femelle) quand le cordon est de type ETCD. Pour chacune des cinq normes, CISCO fournit le plan de câblage du cordon. Observez par exemple le circuit « Emission de données » de la jonction, désigné le plus souvent par TxD (« Transmit Data »). En EIA232 (page 22 du document) il correspond à la broche J141 du port DB60. En EIA449, X21 et EIA530, il est véhiculé par une paire depuis les broches J111 et J112 du connecteur DB60. En V35 enfin, il est véhiculé par une paire depuis les broches J118 et J117 du connecteur DB60. En fait, il y a autant de solutions différentes que de normes électriques. EIA 449, X21 et EIA530 utilisent les normes électriques EIA422 et EIA423 (respectivement V11 et V10 à l’UIT) mais EIA232 tout comme V35, couvrent à la fois les aspects fonctionnels et électriques de la liaison. Estil possible de concevoir un port WAN plus compact ? Oui à la condition de réduire le nombre de broches. Et pour ce faire, chaque broche, ou chaque paire de broches dans le cas d’un signal véhiculé par une paire, doit pouvoir commuter d’une norme électrique à une autre en fonction de la norme de liaison série choisie. Le connecteur en devient « intelligent » et c’est pourquoi CISCO a baptisé son nouveau connecteur « Smart Serial ». Ce connecteur comporte 26 broches, conserve la forme en D, et équipe par exemple la carte WIC2A/S (deux ports WAN Asynchrones ou Synchrones) objet de l’illustration ciaprès :
La carte de type WIC2A/S est d’encombrement identique à la carte WIC1T précédente mais la compacité du connecteur Smart Serial a permis d’y loger deux ports. En puisant à nouveau dans la documentation « CISCO Modular Access Router Cable Specifications », observez le même circuit Emission de données pour chacune des cinq normes de liaison série. Pour toutes les normes hormis EIA232, le transport s’effectue en mode symétrique (balanced, nécessite une paire par circuit), le signal est véhiculé par une paire depuis les broches J101 et J114. EIA232 utilise un mode asymétrique (unbalanced, signal entre un fil et la masse), le signal est véhiculé par un circuit correspondant à la broche J101 du connecteur SS (Smart Serial). Observez également que les broches J101 et J114 se trouvent être en visàvis sur les deux rangées de broches du connecteur, ceci afin d’éviter au mieux les couplages entre paires et donc la diaphonie. La figure cidessous fournit les références des câbles CISCO dans le cas le plus normal, c’està dire lorsque l’on souhaite une extrémité réseau de type ETTD (DTE) :
Il existe une variante de la norme EIA530 nommée EIA530A. La principale différence concerne les circuits de gestion du modem. En EIA530, tous les circuits de la jonction sont en mode symétrique (balanced). En EIA530A, les circuits DTR (Data Terminal Ready), DSR (Data Set Ready) et DCD (Data Carrier Detect) sont asymétriques (unbalanced). Ceci porte à six le nombre de câbles prévus par CISCO pour fournir une extrémité ETTD. Il faut encore y ajouter quatre câbles prévus lorsque l’on souhaite une extrémité réseau de type ETCD (DCE). Pour EIA232, V35, EIA449 et EIA X21, remplacez les lettres « MT » de la référence par les lettres « FC » pour obtenir le cordon à extrémité ETCD (DCE) correspondant. Le connecteur de l’extrémité réseau est un connecteur femelle. Il n’existe pas de cordon EIA530 à extrémité ETCD. Il reste à traiter un cas peu utile dans le monde professionnel mais très utile en situation de TP ou de test pratique lors d’épreuves visant une certification, ce qu’il faut appeler un cas d’école, celui de la simulation d’un lien WAN sans faire appel aux services d’un opérateur. Parvenir à simuler un lien WAN nécessite de résoudre un problème d’horloge que l’on pouvait ignorer (mais mieux vaut le connaître) dans le monde réel. Resituons d’abord le contexte d’une transmission numérique synchrone réelle sur un lien WAN :
Appuyons notre propos sur le flux de données émis par l’ETTD11 et destiné à l’ETTD21. Chaque octet à émettre est présenté sur les entrées parallèles du registre à décalage. Rythmé par une horloge, ce registre présente les bits de l’octet un à un sur sa sortie. L’ETCD12 reçoit ces bits mais a besoin de l’horloge qui les cadence pour les exploiter. Qui fournit cette horloge ? Deux solutions s’offrent généralement : 1) On confie la fourniture de l’horloge à ETTD11. L’équipement est donc placé sur son réglage « Horloge interne ». L’horloge H11 dont il est équipé lui sert à cadencer le registre de sérialisation. De plus, cette horloge est mise à disposition de ETCD12 via le circuit HET (Horloge Emission Terminal). ETCD12 est placé sur son réglage « Horloge externe » et met à profit cette horloge pour exploiter les bits reçus. Le flux de données codé, et éventuellement modulé, est placé sur la ligne (le réseau étendu). Il porte l’horloge H11 en son sein. ETCD22 ne peut démoduler et décoder que s’il dispose de l’horloge. Sa première tâche consiste à extraire l’horloge du flux reçu, horloge qu’il met à disposition de la circuiterie de démodulation/décodage mais également à disposition de ETTD21 via le circuit HRM (Horloge Réception Modem), ce afin que ETTD21 puisse comprendre et exploiter les bits reçus sur le circuit RD. 2) On préfère confier la fourniture de l’horloge à ETCD12, dont le réglage d’horloge est placé cette fois sur « Horloge interne ». Cette horloge H12 est également mise à disposition de ETTD11 via le circuit HEM (Horloge Emission Modem). Pour le reste, rien ne change. Il est vraiment important de comprendre que ce choix d’horloge ne concerne que la partie émission. En effet, en réception, il n’y a aucun choix possible. Le flux de données arrive porteur de l’horloge. Le second point important consiste à observer que si l’ETTD est réglé en « Horloge interne », l’ETCD est obligatoirement réglé en horloge externe et des deux circuits HET et HEM, seul le circuit HET est utile. Si l’on préfère régler l’ETCD en horloge interne, alors l’ETTD est réglé sur « Horloge externe » et seul le circuit HEM est utile. Il se trouve que CISCO sur les interfaces WAN de ses routeurs, ne donne pas le choix et préfère laisser la responsabilité de la fourniture de l’horloge aux ETCD. L’interface WAN d’un routeur est par conséquent toujours en horloge externe, l’horloge est récupérée sur le circuit HEM. La partie émission d’un ETTD doit nécessairement être reliée à la partie réception de l’autre ETTD, c’est la notion de croisement déjà explicitée lorsqu’il a fallu connecter l’interface LAN du routeur. Observez que dans cette configuration de transmission numérique sur un lien WAN, c’est précisément la partie réseau étendu (la partie ligne) qui assure le croisement : l’émetteur côté WAN de ETCD12 est relié au récepteur de ETCD22 et vice versa. En situation de TP, à moins d’être très richement doté, il faut simuler le lien WAN sans avoir recours à des boîtiers, modems ou DSU/CSU. Fort heureusement, CISCO met à disposition des cordons à extrémité ETCD (DCE). Simuler un lien WAN nécessite de relier les deux interfaces WAN des deux routeurs via deux cordons, l’un à extrémité ETTD, l’autre à extrémité ETCD. Ce qu’illustre la figure cidessous en conservant la norme de liaison série EIA232 :
À nouveau, seuls les circuits de données et d’horloge sont représentés. Le flux de ETTD11 vers ET_D21 transite par [ETTD11J101 → ED → DB25broche 2 → RD → J105ET_D21] grâce au croisement introduit par le cordon CABSS 232FC. Ce flux est cadencé par une horloge qui transite via le circuit [ETTD11J102 → HET → DB25broche 24 → HRM → J104ET_D21]. Le flux de ET_D21 vers ETTD11 transite par des circuits symétriques. Il subsiste cependant un problème : ETTD11 est toujours en horloge externe et attend le cadencement sur son circuit HEM. CISCO résout ce problème de façon assez particulière en plaçant ET_D21 sur une configuration « Horloge interne » puis en connectant cette horloge au circuit HEM qui devient par conséquent une sortie (un générateur électrique). Ce circuit n’est pas croisé par le cordon CABSS232FC et parvient directement à l’entrée HEM de ETTD11.
Ainsi, l’interface WAN du routeur de droite n’est ni ETTD (le circuit HEM qui « sort » caractérise un ETCD) ni ETCD (le circuit HET qui sort caractérise un ETTD), c’est pourquoi l’auteur l’a désigné « ET_D21 ». Sur ET_D21, le passage en horloge interne ainsi que la fourniture de l’horloge sur le circuit HEM est provoqué par l’instruction « clockrate » en configuration d’interface WAN, ceci sera réexpliqué dans les paragraphes qui suivent. L’important est que ET_D21 associé à son cordon de type ETCD et convenablement configuré simule une interface WAN de type ETCD en horloge interne. On désigne souvent l’association de deux cordons ETTD et ETCD par câbles « backtoback » (littéralement dos à dos). Hors cadre CCNA et pour être complet, citons la norme de liaison série HSSI (High Speed Serial Interface) développée conjointement par les firmes CISCO et T3+ networking et depuis intégrée dans les standards de l’EIA. Cette technologie répond à un besoin de bande passante qui couvre les débits atteints par les liens WAN T3 (44,736 Mbps) et E3 (34,368 Mbps).
HSSI est une spécification ouverte et opère sur la couche physique du modèle OSI. HSSI définit à la fois les caractéristiques physiques (EIA613) et électriques (EIA612) de l’interface. Pour atteindre de tels débits, le mode de transmission est bien sûr différentiel mais HSSI s’octroie le renfort d’une technologie particulière, dite ECL (Emitter Coupled Logic), pour laquelle l’état saturé des transistors est remplacé par un état intermédiaire non saturé. La vitesse y gagne au détriment de la consommation. Le connecteur utilisé est le même que celui utilisé par la norme SCSI2. Le câble enfin doit utiliser des paires torsadées d’impédance caractéristique 110 Ω. Saluons le souci des concepteurs d’éviter le besoin en adaptateurs mâlefemelle en imposant que les cordons HSSI soient systématiquement pourvus de connecteurs mâles.
c. Connecter un PC en émulateur de terminal au port console Pour les ateliers de cet ouvrage, on se propose d’utiliser l’émulateur de terminal PuTTY bien connu des professionnels. L’avantage de cet outil est qu’il permet autant l’émulation d’un terminal que l’établissement d’une connexion Telnet ou SSH via le réseau. Au moment où ces lignes sont écrites, le logiciel en est à la version 0.6. Le fichier d’installation « putty0.60installer.exe » pèse 1719 Ko. Le logiciel, une fois installé, occupe 3,23 Mo sur le disque dur. Lien vers le site de téléchargement de PuTTY : http://www.chiark.greenend.org.uk/~sgtatham/putty/ Une fois installé et exécuté, il reste à configurer PuTTY pour un accès via un port série, le plus probablement COM1 :
Bien sûr, encore fautil avoir la chance de disposer d’un PC équipé d’un port série EIA232. Quand c’est le cas, il reste à connecter le port console du routeur au port série du PC à l’aide du câble console :
Quand PuTTY est prêt, quand le port console du routeur est relié au port série du PC, il reste à lancer le terminal émulé en cliquant sur le bouton Open puis, si ce n’est déjà fait, à mettre le routeur sous tension. En supposant que le routeur était effectivement hors tension, son démarrage s’accompagne de l’émission de différents messages vers le port console. On peut ainsi suivre l’ensemble de la séquence de démarrage sur l’écran du terminal :
La séquence de démarrage fait l’objet d’une description complète au chapitre Gestion de la plateforme logicielle CISCO IOS, la capture cidessus correspond au démarrage d’un routeur dont le fichier de configuration startupconfig n’est pas vide. Autrement dit, un administrateur a déjà configuré, peutêtre partiellement, ce routeur. La séquence s’achève alors par le message « Press RETURN to get started! ». Si l’administrateur frappe la touche [Entrée] du terminal à ce moment, et sauf configuration particulière, l’interface ILC passe dans le mode utilisateur.
Que faire quand le PC que l’on a l’intention d’utiliser pour émuler un terminal n’est pas équipé d’un port série ? La solution la plus évidente est d’acquérir un convertisseur USB EIA232. Une fois le précieux convertisseur connecté sur son port USB et le pilote convenable installé, encore fautil identifier le port série associé au convertisseur. Attention, débrancher le convertisseur d’un port USB pour le rebrancher sur un autre port USB de la même machine et voilà que le numéro de port COM associé change. Le plus simple quand on utilise régulièrement ce succédané de port série est encore de le connecter de façon systématique sur le même port USB. Sur un poste de travail Windows XP ou 7 : ■
■
Effectuez un clic droit sur Poste de travail dans le cas de Windows XP (sur Ordinateur dans le cas de Windows 7) puis dans le menu contextuel qui s’affiche, choisissez Gérer. Ceci provoque l’ouverture d’une console MMC (Microsoft Management Console) équipée du composant logiciel enfichable Gestion de l’ordinateur. Dans le volet gauche, déployez le nœ ud Gestionnaire de périphériques. Dans
le volet central, déployez Ports (COM et LPT). Le port COM affecté par Windows au convertisseur apparaît ici, COM3 dans le cas présent :
■
De retour dans la fenêtre de configuration de PuTTY, sélectionnez le nœ ud Serial dans le volet Category puis remplacez COM1 par COM3 dans le champ Serial line to connect to.
Ces convertisseurs ne gèrent généralement que les circuits Emission de données et Réception de données, les circuits qui permettraient de gérer un modem par exemple sont absents. Mais ce n’est gênant en rien dans le cas présent.
6. L’IOS Comme tout ordinateur, un routeur ou un commutateur ne peuvent fonctionner sans système d’exploitation. Dans le cas des équipements CISCO, le constructeur le désigne par IOS (Internetworking Operating System) et il est embarqué sur la plupart des matériels du constructeur indépendamment de leur taille ou de leur type. L’IOS CISCO est un système d’exploitation très puissant et très complexe associé à un langage de configuration tout aussi complexe. Beaucoup de commandes, beaucoup d’options et à chaque nouvelle commande entrée, le risque de compromettre le bon fonctionnement du réseau, cela peut aller jusqu’à isoler votre entreprise du reste du monde. Ce n’est évidemment pas l’objet de cet ouvrage, mais même à concevoir un ouvrage de mille cinq cent pages, il est peu probable qu’il parvienne à couvrir l’ensemble des fonctionnalités de l’IOS. Il faut donc accepter de ne pas pouvoir être exhaustif et s’en tenir à de la méthode. Pour le configurer, l’exploiter ou en assurer sa maintenance, l’administrateur accède à l’IOS via une interface en ligne de commande (ILC ou CLI : Command Line Interface). Les commandes accessibles varient évidemment selon la version d’IOS ainsi que selon la fonction de l’équipement considéré, routeur, commutateur ou encore point d’accès sans fil. L’IOS est stocké dans la partition mémoire Flash. Pendant le démarrage du routeur, l’IOS est chargé en mémoire vive. Ce point fait l’objet d’un développement complet dans le chapitre Gestion de la plateforme logicielle CISCO IOS.
7. Les interfaces et leur nommage Premier point agréable : CISCO IOS emploie de façon systématique le terme interface, ce qui rend les commandes de configuration à connaître transposables d’une plateforme à une autre. Le nommage d’une interface respecte la forme générale suivante :
numéro » 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 :
interface
ethernet
interface
fastethernet
interface
gigabitethernet
Quand il s’agit de l’Ethernet historique à 10 Mbps.
numéro
Interface capable des débits 10 et 100 Mbps, débit auto négocié.
numéro
numéro
Interface capable des débits 10, 100 et 1000 Mbps, débit auto négocié.
Le nommage d’une interface WAN fait abstraction de la technologie employée en couche physique et de l’encapsulation mise en œ uvre par la couche liaison : interface
serial
numéro
Hélas, cette belle recherche de systématicité se brise un peu quand on passe au numéro. En effet, la façon de numéroter les interfaces d’un routeur dépend de la série et du modèle dans la série. Il faut donc se référer au guide d’installation cité un peu plus haut. Le numéro peut être composé de un, deux ou trois chiffres séparés par des caractères « / » : ●
●
●
Pour les petits routeurs, l’interface peut être désignée par un numéro composé d’un seul chiffre. Quand le numéro d’interface est composé de deux chiffres, le chiffre de poids fort désigne par exemple le numéro de connecteur (« slot ») qui reçoit la carte d’interface sur la carte mère, le chiffre de poids faible désigne le numéro de port sur cette carte d’interface. Enfin, les configurations les plus importantes nécessitent une profondeur d’arborescence à 3 niveaux. Le chiffre de poids fort peut désigner un module, le chiffre intermédiaire peut désigner une carte fille, un adaptateur de ports, un sousmodule, un slot. Le lecteur notera avec soulagement que l’on peut parfaitement ignorer les détails physiques qui justifient cette arborescence à deux ou trois niveaux.
Selon que l’interface est embarquée sur la carte mère du routeur ou sur un module inséré dans le routeur, elle peut être désignée par un numéro à deux ou à trois chiffres. Quel que soit le chiffre considéré, la numérotation débute à zéro. Le tableau suivant fournit quelques exemples de nommage, corrects sur au moins un modèle de routeur CISCO, ainsi que, en référence avant puisque l’interface en ligne de commande fait l’objet du paragraphe suivant, la notation abrégée de ces mêmes noms d’interface :
interface
ethernet
0
interface
fastethernet
interface
gigabitethernet
0/1
0/0
int
e0
int
fa0/1
int
gi0/0
Reprenons en exemple le cas de la série 2800. CISCO nous explique que le format du numéro est châssis/slot/port. Pour le routeur 2801, châssis prend toujours la valeur 0 car tous les slots sont construits dans le châssis. Quant aux routeurs 2811, 2821 et 2851, certains slots appartiennent au châssis et dans ce cas, le chiffre châssis prend la valeur 0. D’autres appartiennent au module NM(E) ou au module EVM et dans ce cas, le chiffre châssis prend respectivement la valeur 1 ou la valeur 2. Pour ancrer ces notions dans le concret, le lecteur pourra se reporter au chapitre Annexes section Numérotation des interfaces des routeurs de la série 2800 qui fournit une liste exhaustive des numéros d’interface de ce routeur.
La configuration du routeur 1. Sources de configuration, fichiers de configuration Pour résumer de façon lapidaire, l’IOS CISCO peut faire, mais sans fichier de configuration ne saurait quoi faire. L’administrateur lui dicte ses tâches à l’aide de commandes regroupées dans des fichiers de configuration toujours au nombre de deux : ●
●
Le fichier runningconfig (fichier run de façon abrégée) est le fichier de configuration courante que le routeur utilise pendant son fonctionnement. Le fichier startupconfig (fichier start de façon abrégée), placé en NVRAM, sauvegarde la configuration du routeur en l’absence d’alimentation.
Le fichier runningconfig est obtenu par copie (clonage) du fichier startupconfig, copie réalisée pendant le démarrage du routeur. Lorsque l’administrateur modifie la configuration du routeur par ajout ou suppression de lignes de commande, c’est le fichier de configuration courante qui est modifié. Les modifications apportées prennent effet immédiatement, on parle de configuration incrémentale. Entre deux démarrages de routeur, les modifications apportées au fichier de configuration courante sont perdues car celuici n’existe qu’en mémoire vive. Si l’administrateur souhaite sauvegarder les modifications apportées et donc le nouvel état du fichier de configuration, il doit copier le fichier de configuration courante vers le fichier de sauvegarde à l’aide d’une commande : Router# copy running-config startup-config Ou de façon abrégée : Router# copy run start L’administrateur peut visualiser indifféremment le contenu de chacun de ces fichiers à l’aide de commandes show. Ainsi, pour visualiser le fichier de configuration courante : Router#show running-config Qu’il est possible d’abréger en : Router#sh run Pour visualiser le fichier de configuration de sauvegarde :
Router#show startup-config Qu’il est possible d’abréger en : Router#sh start
2. L’interface en ligne de commande ILC L’interface en ligne de commande (ILC en français, CLI en anglais) est la cabine de pilotage du routeur. À l’aide d’ILC, l’administrateur peut ajouter ou supprimer des lignes de commande aux fichiers de configuration. Il peut aussi vérifier le fonctionnement attendu du routeur ou du réseau. À partir de l’ILC d’un routeur, il peut ouvrir d’autres sessions ILC sur d’autres routeurs via Telnet ou SSH.
Cela a été dit dans la section Le routeur : un ordinateur spécialisé Les ports d’administration, l’administrateur accède à l’interface ILC soit de façon locale via le port console, soit par le réseau via une session Telnet ou SSH. Au premier abord, une telle interface peut sembler désuète. La plupart des configurations actuelles sacrifient à la mode des « cliquodromes » : des fenêtres, des onglets, des cases à cocher, des boutons radio... Ces environnements, évidemment attrayants dans un premier temps, ne présentent pas que des avantages. Demandez à un administrateur système rompu à l’usage de l’interface Windows XP ce qu’il a pensé de la nouvelle interface de Windows Vista. Une bonne part des savoirfaire perdus de façon instantanée alors qu’ils n’avaient été acquis qu’au prix d’une longue pratique. L’administrateur avisé, plutôt que de privilégier le côté attrayant d’une interface, doit s’interroger sur la pérennité des savoirfaire qu’il doit acquérir. Et de ce point de vue, l’ILC sort gagnante. Car les mécanismes mis en œ uvre sont peu ou prou les mêmes pour toutes les gammes de routeurs mais aussi pour toutes les gammes de commutateurs CISCO. Mieux, l’usage de cette interface s’est tellement répandu qu’il arrive à des constructeurs tiers de proposer leurs matériels dotés d’interfaces « CISCO like ».
L’interface ILC de l’exemple cidessus a été ouverte via le port console.
3. Les modes du routeur
C’est une façon de protéger l’équipement, mais aussi de rassurer la personne qui est en face de la console ILC, toutes les commandes de configuration ne sont pas immédiatement accessibles. L’IOS prévoit trois contextes, appelés modes par CISCO, et qui laissent plus ou moins de latitudes à l’administrateur : Mode utilisateur (User mode) : l’administrateur accède au routeur sans risque de corrompre son fonctionnement ou celui du réseau. En effet, ce mode n’autorise aucun changement dans la configuration et permet essentiellement l’affichage d’informations élémentaires. Au démarrage de la connexion et sauf configuration particulière, l’ensemble des moyens d’accès à l’interface ILC, Console, Aux et Telnet/SSH placent l’interface ILC dans ce mode. L’invite de commande rappelle que l’interface ILC est dans le mode utilisateur de la façon suivante :
Mode privilégié (Privileged mode) : également appelé mode enable du nom de la commande qui permet d’y entrer, ce mode offre l’accès à des commandes qui peuvent remettre en question le fonctionnement du routeur ou du réseau. Quelques exemples de commandes critiques : la commande reload qui provoque un redémarrage du routeur ; la commande debug utile au dépannage ou à la compréhension de phénomènes complexes mais qui mal utilisée, peut consommer de la ressource processeur au point d’empêcher l’équipement d’assurer ses tâches normales. Si l’administrateur peut s’interroger sur l’utilité d’un mot de passe qui protégerait l’accès au mode utilisateur, le doute n’est plus permis dans le cas du mode privilégié. L’invite de commande reflète le passage au mode privilégié de la façon suivante :
Les deux modes utilisateur et privilégié sont parfois appelés mode EXEC utilisateur et mode EXEC privilégié (mal traduits par mode d’exécution), ce qui rappelle simplement que l’IOS exécute les commandes saisies dans l’interface ILC puis y affiche des messages qui rendent compte des résultats. Mode de configuration globale (Global config mode) : aucun des deux modes utilisateur et privilégié ne permet de modifier la configuration de l’équipement. Il faut en passer par le mode de configuration globale ou l’un de ses sous modes. Comme son nom l’indique, ce mode accepte des commandes de configuration et ces commandes affectent le fonctionnement du routeur dans son entier. La configuration finale d’un routeur nécessitera la saisie de nombreuses commandes de configuration, chaque commande saisie prend immédiatement effet dès la validation par la touche [Entrée]. On désigne par configuration incrémentale cette façon de progresser vers la configuration définitive. L’ensemble des commandes saisies dans le mode de configuration globale ou dans l’un de ses sousmodes modifie le fichier de configuration courante runningconfig. Chaque commande et donc également chaque commande de configuration prend effet dès la validation par la touche [Entrée], voilà de quoi inciter l’administrateur à la prudence ! À nouveau, l’invite de commande reflète le passage au mode de configuration globale :
Observez au passage la possibilité offerte à l’administrateur d’utiliser des commandes abrégées. Dans l’exemple ci dessus, l’administrateur provoque deux fois le passage en mode de configuration globale. La première fois, il le fait en utilisant la commande complète. La seconde fois, il obtient le même effet en utilisant la commande abrégée. Une commande abrégée comporte suffisamment de caractères pour permettre à l’IOS de reconnaître la commande sans ambigüité. Par exemple, la séquence de caractères « con » ne peut pas abréger la commande configure car 44 commandes d’IOS (version de l’IOS 12.4T) débutent par cette séquence (configure, connect, controller…). De la même façon, il existe 14 commandes qui débutent par la séquence « conf » avec 7 motsclés différents : conferencejoin, 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é.
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 - 6-
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. - 8-
Observez les deux lignes enable password et enable secret présentes dans ce fichier de configuration. Ainsi, quand elles sont présentes ensemble, le seul mot de passe enable actif est celui saisi à l’aide de la commande enable secret et qu’il est désormais impossible de déchiffrer. L’algorithme utilisé par l’IOS pour crypter le mot de passe est MD5 (Message Digest 5), ce que rappelle le chiffre 5 placé immédiatement avant la séquence chiffrée dans le fichier de configuration. MD5 est utilisé en cryptographie pour obtenir une signature numérique à partir d’un fichier. Lorsqu’il est utilisé pour protéger les fichiers, on sait aujourd’hui que MD5 présente des failles. Mais dans le cas présent, il s’agit de ne pas pouvoir retrouver le mot de passe à partir de la séquence cryptée. Alors MD5 présentetil une fiabilité suffisante ? L’auteur a téléchargé sur le site http://www.oxid.it/cain.html Caïn & Abel, l’un des nombreux logiciels destinés à casser les mots de passe puis y a entré la séquence chiffrée contenue dans le fichier de configuration du routeur Nantes :
Il n’aura fallu que quelques secondes au logiciel pour trouver le mot de passe « ccna » correspondant à la séquence chiffrée en MD5. Mais que le lecteur ne cède pas à la panique et ne se précipite pas sur le téléphone pour exiger des explications du constructeur. L’algorithme utilisé par le logiciel Caïn & Abel est confondant de simplicité. Il explore toutes les combinaisons de caractères et pour chacune d’elles, calcule la séquence MD5 correspondante jusqu’à trouver la séquence objet de la recherche. Cet algorithme est entamé avec une longueur supposée de 1 caractère (a, b, c...) puis se poursuit avec deux caractères (aa, ab, ac... ba, bb, bc...) et ainsi de suite. Ce type d’attaque est appelé « attaque par force brute » et n’a de chances d’aboutir que si le mot de passe est simple et court. Imaginons un mot de passe sur 4 caractères entrés en minuscule parmi les caractères de l’alphabet. L’attaque par force brute doit au pire explorer 264 =456976 combinaisons. À raison de 4000 par seconde, performance observée sur la machine de l’auteur au moment où ces lignes sont écrites, moins de deux minutes suffisent pour parvenir à la solution. Mais mettons en place une politique de sécurité et imposons une longueur minimale de 9 caractères choisis parmi les caractères affichables de la table ASCII. Cette table comporte 128 caractères mais les caractères 0 à 31 ainsi que le caractère 127 sont dits non visualisables. Il reste 95 caractères possibles. L’attaque par force brute ignore la longueur du mot de passe et il lui faut explorer la longueur 1 puis la longueur 2 et ainsi de suite. Calculons le temps à passer si la machine est capable de 4000 essais par seconde. Rien que pour la longueur 9, il existe 95 9 = 630249409724609375 combinaisons qui réclameront années ! Hélas par souci de commodité (qui n’a pas craint un jour d’oublier un mot de passe ?), de nombreuses personnes utilisent des mots du langage courant pour créer leur mot de passe. L’attaque par dictionnaire met ce constat à profit et teste une série de mots de passe potentiels contenue dans une liste. De telles listes existent évidemment sur Internet, enrichies avec les mots de passe observés sur la planète. Pour contrer ces attaques, l’administrateur doit cette fois imposer des règles de complexité : le mot de passe doit contenir lettres et chiffres, mixer minuscules et majuscules, utiliser des caractères spéciaux, éviter les mots du dictionnaire, « saler » les mots utilisés s’il y en a (c’estàdire concaténer le mot utilisé avec un mot qui lui fait perdre son sens premier sans toutefois perdre l’intérêt de pouvoir être retenu facilement), remplacer certains caractères par leur correspondance dans l’alphabet « Leet » (exemples : la lettre M peut être remplacée par la séquence (V), la lettre U par la séquence (_)...). En final et à moins que demain, la puissance des processeurs ne permette des calculs beaucoup plus rapides, le mot de passe construit en s’imposant de telles règles a encore de beaux jours devant lui.
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 - 10 -
configuration de l’équipement. Impossible en effet de mémoriser la syntaxe de milliers de commandes, impossible également de rester connecté en permanence sur le site CISCO pour vérifier la syntaxe de telle ou telle commande. La touche magique qui permet de demander de l’aide est simplement le point d’interrogation ?, on peut le frapper à tout moment, le résultat diffère selon le contexte courant de l’interface ILC. Quelques contextes possibles : Commande
Usage
Prompt# help
Affiche comment obtenir de l’aide.
Prompt# ?
Affiche l’ensemble des commandes admises dans le contexte courant.
Prompt# commande ?
Liste de toutes les options admises pour cette commande (ce peut être des arguments ou des motsclés).
Prompt# abc?
Liste de toutes les commandes débutant par la chaîne de caractères abc.
Prompt# abc[Tab]
Autocomplétion : complète la commande partielle abc s’il est possible de le faire. Exemple : l’interface ILC substitue show à la séquence sh [Tab].
Prompt# commande motclé ? Liste de toutes les prochaines options admises pour cette commande associée à ce motclé. En résumé, on peut classer l’aide contextuelle en deux catégories : ●
●
D’une part, l’aide type vocabulaire, utile quand un doute subsiste sur le motclé en cours de frappe, est invoquée à l’aide du point d’interrogation non précédé d’un espace. D’autre part, l’aide type syntaxe, utile quand il faut connaître la liste des motsclés ou des arguments admis dans le contexte, invoquée par le point d’interrogation précédé cette fois d’un espace.
Quand la mention 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.
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 :
Déplace le curseur d’un caractère vers la gauche (B = Backward).
[Ctrl] F
Déplace le curseur d’un caractère vers la droite (F = Forward).
[Echap] B
Amène le curseur sur la première lettre du mot courant.
[Echap] F
Amène le curseur immédiatement après le dernier caractère du mot courant.
[Ctrl] A
Amène le curseur en début de ligne (At first).
[Ctrl] E
Amène le curseur immédiatement après le dernier caractère de la ligne (End).
Les raccourcis suivants effacent un caractère ou une partie de mot ou une partie de ligne :
Combinaison de touches
Action résultante
[Ctrl] D
Supprime le caractère situé sous le curseur (Delete).
[Ctrl] H
Supprime le caractère qui précède le curseur, même effet que la touche [Retour arrière].
[Ctrl] W
Supprime tous les caractères du mot courant qui précèdent le curseur.
[Echap] D
Supprime tous les caractères du mot courant qui suivent le curseur ainsi que le caractère situé sous le curseur.
[Ctrl] K
Supprime la totalité des caractères situés entre le curseur et la fin de ligne, caractère situé sous le curseur inclus.
[Ctrl] U
Supprime la totalité des caractères situés entre le curseur et le début de ligne. Les caractères sont placés dans un tampon qu’il est possible de rappeler à l’aide
7. Atelier : Prise en main de l’interface ILC a. Définition d’un contexte d’atelier Dès le premier ouvrage de cette série, le souci de l’auteur a été de permettre à l’étudiant de progresser chez lui avec ses moyens propres. Les ateliers proposés dans l’ouvrage Cisco Notions de base sur les réseaux dans la collection Certifications aux Editions ENI faisaient un abondant usage de VMware Workstation. Pour mémoire, VMware installé sur une machine hôte, permet d’y créer autant de machines virtuelles que nécessaire et que peut en supporter l’hôte. Chaque machine virtuelle est un espace clos dans lequel il est possible d’installer la plupart des systèmes d’exploitation que connaît le PC (l’éditeur en revendique deux cent). Si la machine hôte dispose de plusieurs processeurs (cas des machines « dual core » et « quad core », alors il est possible de configurer la machine virtuelle pour qu’elle profite d’un, de deux ou de quatre processeurs, cela n’a évidemment d’intérêt que si le système d’exploitation installé sur la machine virtuelle est conçu pour tirer parti de plusieurs processeurs (Windows 2000 Professionnel ou Windows XP par exemple peuvent mettre à profit deux processeurs, mais il faut se tourner vers des versions Serveur pour en supporter davantage). La quantité de mémoire disponible sur la machine hôte est déterminante mais si le système d’exploitation, comme c’est encore le plus souvent le cas au moment où ces lignes sont écrites, est une version 32 bits, alors le PC hôte embarque au maximum 232 =4 Go de RAM, limite qui ne sera franchie qu’avec l’adoption des systèmes d’exploitation 64 bits. L’essentiel est encore à venir : chaque machine virtuelle peut être dotée d’un ou plusieurs adaptateurs réseaux virtuels. L’administrateur décide ensuite de connecter chacun de ces adaptateurs à l’un des concentrateurs virtuels, VMware Workstation en fournit dix notés VMnet0 à VMnet9. Chacun de ces concentrateurs peut être à son tour relié à un adaptateur réseau virtuel installé cette fois dans la machine hôte (noté « VMware virtual ethernet adapter for VMnetx ». Parmi les nombreuses autres possibilités, notons celle qui consiste à établir un lien de type pont (« bridge ») entre l’adaptateur réseau physique de la machine hôte et l’un des concentrateurs virtuels VMnetx. En final, toute configuration de réseau local mêlant machines virtuelles et la machine physique est donc facile à réaliser. Quant aux routeurs, le premier ouvrage proposait des mises en situation réalisées à l’aide de cet excellent outil proposé par CISCO et nommé Packet Tracer. Mais il ne s’agissait que de simulations et l’étudiant lecteur engagé dans le cursus CISCO pouvait regretter de devoir patienter jusqu’à une mise en situation réelle proposée par l’organisme de formation pour prendre la main sur des routeurs physiques. Ce second ouvrage propose de passer de la simulation à l’émulation à l’aide de l’outil GNS3 (Graphical Network Simulator) qu’il est possible de télécharger sur le site : http://www.gns3.net/
GNS3 se définit comme un simulateur de réseau graphique, mais en réalité, il s’agit plutôt d’une interface qui facilite la mise en œ uvre de Dynamips, logiciel qui permet d’émuler un routeur physique. Dynamips est au routeur ce que VMware est au PC. VMware permet de créer une machine virtuelle dans laquelle l’administrateur installe un système d’exploitation comme il le ferait sur un PC réel. De la même façon, Dynamips permet de créer un routeur virtuel sur lequel l’administrateur charge l’image IOS convenable comme il le ferait sur un routeur réel. Et c’est là tout l’intérêt pédagogique. Apprendre sur un PC virtuel émulé dans VMware crée les mêmes savoirfaire qu’apprendre sur un PC physique. De façon analogue, un routeur émulé à l’aide de Dynamips se comporte strictement comme le routeur physique porteur de la même image IOS, les apprentissages sont donc les mêmes mais il devient possible de les délocaliser. C’est un peu comme si on permettait à l’étudiant d’emmener le bundle (ensemble de matériels CISCO que doit acquérir tout organisme de formation qui adhère à l’académie CISCO) sous le bras ! Merci donc à son créateur M. Christophe FILLOT de l’Université de Technologie de Compiègne. Dynamips est associé à Dynagen, une interface écrite dans le langage de programmation Python et qui facilite l’interconnexion de plusieurs machines émulées d’une même topologie. GNS3, également écrit en langage Python, fournit une interface utilisateur graphique facilitant l’exploitation de Dynamips/Dynagen. Dynamips est capable d’émuler actuellement les platesformes 1700, 2600, 3600, 3700 et 7200. L’ensemble des ateliers de cet ouvrage a été réalisé sur un portable équipé d’un processeur Intel T9600 Dual Core cadencé à 2,8 GHz et qui embarquait 4 Go de RAM. Le système d’exploitation hôte a été Windows 7 en version d’évaluation 7100. VMware Workstation était en version 6.5 (une version 7 est disponible). GNS3 pour Windows était en version 0.6.1. Le routeur émulé résulte de l’association de Dynamips et d’une image IOS valide. Si cela ne pose aucune difficulté pour un client CISCO, il en va en principe autrement pour l’étudiant administrateur en devenir. Sans intention de
vouloir encourager l’utilisation de licences illégitimes, l’auteur rappelle qu’aucune des machines virtuelles, PC ou routeur, de cet ouvrage ne sera jamais une machine de production. Tout au plus une construction didactique éphémère, support d’apprentissage.
b. Préparation des machines virtuelles VMware Les machines virtuelles préparées par l’auteur afin de servir de cadre aux ateliers de cet ouvrage sont inventoriées dans le tableau cidessous : VMSRV01
VMWKS02
VMWKS03
PC8, 11, 12, 21, 22 si Windows PCL8, 11, 12, 21, 22 si Linux
Nombre processeurs Mémoire vive
1
2
1
1
384 Mo
1024 Mo
128 Mo
64 Mo si W2000 48 Mo si Linux
Disque
8 Go
6 Go
6 Go
6 Go
1
5
1
1
W2000 SRV
XP Prof SP3
W2000 Prof SP4
W2000 Prof SP4
Nombre Adaptateurs réseau Système d’exploitation
Ou Ubuntu Logiciels notables
Services réseau
GNS3
Serveur SYSLOG (Kiwi) Serveur RADIUS (RADL)
PuTTY Wireshark
Chacun des ateliers proposés ensuite ne nécessitera pas d’activer ensemble toutes ces machines fort heureusement. À chaque instant, le souci doit être d’économiser la quantité de mémoire affectée aux différentes machines. C’est ainsi que les machines PC8, PC11, PC12, PC21, PC22 qui ne servent qu’à tester la connectivité doivent être des machines « Weight Watchers ». N’hésitez pas à désactiver des services inutiles (dans ce contexte) tels que : ●
Client de suivi de lien distribué.
●
Mises à jour automatiques.
●
Planificateur de tâches.
●
Agent de stratégie Ipsec.
À ce sujet, l’auteur utilise depuis peu les services de TuneUp 2010 sur la machine hôte. Il a ainsi été très facile de désactiver tout ce qui ne sert que l’apparence au profit d’une machine devenue très fluide, il faut savoir ce que l’on veut. PC11, PC12, PC21 et PC22 peuvent être obtenus très simplement par clonage de la machine PC8. De plus, parmi les options proposées lors du clonage, l’une d’elles permet, en conservant un lien avec la machine d’origine, d’obtenir une nouvelle machine avec très peu d’espace disque consommé :
Les férus de Linux gagneront sans doute à reproduire ces mises en situation sous leur système d’exploitation préféré. Pour sa part, l’auteur avoue une certaine réticence, toujours gêné par le militantisme, quelquefois assez peu professionnel, des porteurs de la bonne nouvelle du manchot. Mais la recherche d’efficacité et de compacité prime. C’est pourquoi nous avons placé en téléchargement sur le site ENI une machine virtuelle prête à l’emploi (merci à Gaëtan d’avoir préparé cette machine) dans l’archive wm_ubuntu.zip. Une documentation est incluse au format pdf. Sous VMware, ouvrez cette machine Ubuntu puis clonezla afin de produire les machines PCL8, PCL11, PCL12, PCL21 et PCL22. Pour chacune des machines, voici la séquence de commandes nécessaires afin d’adapter la machine au contexte : Login : ubuntu Mot de passe : sunrise $ ifconfig a L’invite de commandes (le « prompt ») est matérialisé par le symbole $. Le système renvoie la liste des interfaces réseau qu’il connaît, notez le numéro d’ordre affecté à l’interface Ethernet, par exemple eth4. $ sudo
nano
/etc/network/interfaces
Nano est un éditeur de texte. Sudo informe le système d’exploitation qu’il doit exécuter la commande avec le niveau de privilège root (administrateur). Le mot de passe root est également sunrise. Le fichier ouvert contient la configuration courante des interfaces. Sous le label # The primary network interface, remplacez les deux occurrences ethx par eth4 puis adaptez la configuration IP. Sortez par [Ctrl] X, Y pour yes et validez par la touche [Entrée]. Redémarrez la partie réseau afin de rendre effective la nouvelle configuration à l’aide de la commande : $ sudo
/etc/init.d/networking
restart
Le système répond : * Reconfiguring network interfaces -
[OK]
Voilà votre machine prête à l’emploi. Attention à la commande ping qui, à la différence des systèmes Windows, génère des requêtes de façon continue (une commande ping t provoquerait le même effet sous Windows) et dont on sort à l’aide de la combinaison de touches [Ctrl] C. Attention également au fait que les outils de VMware (« VM Tools ») ne sont pas installés sur cette machine. Par conséquent, une fois que la fenêtre correspondante à cette machine a le focus, la seule façon d’en sortir est la combinaison de touches [Ctrl][Alt]. La barre d’état de VMware rappelle cette particularité. À l’inverse des machines PC8 à PC22 (ou PCL8 à PCL22), la machine virtuelle nommée VMWKS02 accueille GNS3/Dynamips et a l’ambition de parvenir à faire fonctionner des topologies comprenant jusqu’à 6 routeurs. Ceci justifie une configuration plus musclée : 1 Go de RAM et deux processeurs. La machine VMWKS03 ne sera activée que pendant les ateliers organisés autour de SYSLOG (journalisation d’évènements) et RADIUS (authentification des utilisateurs). Enfin, la machine VMSRV01 héberge un Windows 2000 Server, ce qui peut s’avérer utile s’il fallait mettre en place un quelconque service réseau (DHCP, DNS...).
Nous ne détaillerons pas toutes les étapes nécessaires à la préparation d’un tel ensemble de machines, l’aide fournie par VMware est très complète. Il peut être agréable d’ouvrir plusieurs instances de VMware, c’est le cas quand on a la chance de disposer de plusieurs écrans sur la même machine hôte. Ceci s’opère à l’aide de la commande de menu VMware File New Window. Ainsi, dans l’exemple cidessous, une instance est ouverte sur une topologie de routeurs créée dans GNS3 hébergé par la machine virtuelle VMWKS02, l’autre instance de VMware est ouverte sur une équipe (« team ») composée des machines PC8, PC11, PC12, PC21 et PC22 :
Rassembler plusieurs machines virtuelles dans une équipe procure un certain nombre d’avantages : ●
●
●
L’administrateur peut provoquer le démarrage de l’équipe par une seule action. L’ordre de démarrage des PC dans l’équipe est prédéterminé. De plus, l’administrateur peut ajuster le temps qui s’écoule entre le démarrage d’un PC et le démarrage du PC suivant (10 secondes par défaut). Les machines virtuelles d’une équipe peuvent être connectées à un segment LAN dont l’administrateur peut à la fois régler la bande passante et le taux d’erreur ! Le focus est porté sur une machine de l’équipe mais les autres machines apparaissant sous forme de vignettes qui représentent l’activité réelle de l’écran.
c. Préparation des réseaux virtuels VMware Il s’agit d’assurer la connectivité convenable des machines virtuelles entre elles, des machines virtuelles avec la machine hôte voire des machines virtuelles avec le ou les adaptateurs réseau physique qui équipent la machine hôte. Le tableau cidessous tente d’inventorier les connexions établies, il semblera probablement nébuleux au lecteur, mais il prendra du sens à mesure de l’avancée dans l’atelier : Hôte
VMnet9 Chacune des cinq machines PC(L)x est reliée à la machine qui héberge GNS3. Les noms donnés aux adaptateurs réseau (NIC : Network Interface Card) le sont au sein du système d’exploitation qui équipe la machine correspondante. Dans la machine VMWKS02, il est conseillé d’ajouter un seul adaptateur réseau à la fois. Détaillons la procédure d’ajout d’un adaptateur réseau dans la machine VMWKS02 : ■
La machine virtuelle VMWKS02 est active. Commençons par un état des lieux. Effectuez un clic droit sur l’onglet de la machine virtuelle puis sélectionnez Settings :
■
■
Dans la fenêtre Virtual Machine Settings, sélectionnez l’élément Network Adapter. Faisons le choix de connecter cette carte virtuelle au réseau physique de la machine hôte en sélectionnant le bouton radio Bridged. Sur le bureau de la machine virtuelle, effectuez un clic droit sur l’icône Favoris réseau et sélectionnez Propriétés :
■
■
- 20 -
Renommez l’adaptateur réseau BRIDGE (effectuez un clic droit sur l’adaptateur puis sélectionnez Renommer) afin d’éviter de confondre cet adaptateur existant avec les adaptateurs à venir. Revenez aux réglages de la machine virtuelle et cliquez sur Add. Ajoutez un adaptateur réseau virtuel et connectezle au concentrateur VMnet1 :
Revenez au bureau de la machine virtuelle, effectuez un clic droit sur l’icône Favoris réseau et sélectionnez Propriétés. Renommez l’adaptateur ajouté en NIC11 :
■
Renouvelez l’ensemble de la séquence jusqu’à ce que la machine VMWKS02 dispose de ses cinq adaptateurs NIC11, NIC12, NIC21, NIC22 et NIC8, chaque adaptateur étant connecté au concentrateur VMnet convenable, selon le tableau d’affectation des VMnet fourni en début de paragraphe :
■
Depuis le menu Démarrer de la station hôte, lancez l’application Virtual Network Editor de VMware. Attention, si la station hôte est sous Windows Vista ou Windows 7, ce lancement doit s’opérer en mode administrateur ce qui est obtenu en effectuant un clic droit sur le raccourci de l’application :
De la fenêtre Virtual Network Editor, sélectionnez l’onglet NAT et désactivez toute translation d’adresses NAT :
Il est possible d’établir une connexion réseau entre la machine hôte et un ou plusieurs des concentrateurs virtuels VMnet. Par exemple, imaginons que l’on souhaite établir un lien avec VMnet8 : ■
- 22 -
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 :
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.
■
- 24 -
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 :
■
- 26 -
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 :
■
- 28 -
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 :
■
- 30 -
À 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 :
■
■
- 32 -
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 /no-squeeze-reserve-space flash: nvram: pram: startup-config
Erase all files(in NVRAM) Do not reserve space for squeeze operation Filesystem to be erased Filesystem to be erased Filesystem to be erased Erase contents of configuration memory
R8#erase startup-config ? 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 Protocol FastEthernet0/0 FastEthernet0/1
IP-Address
OK? Method Status
unassigned unassigned
NO NO
unset 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. R8(config)#line con 0 R8(config-line)#logg R8(config-line)#logging sy R8(config-line)#logging synchronous R8(config-line)#
End with CNTL/Z.
Au moindre petit temps mort dans notre activité (dix minutes par défaut), voilà la session console fermée par l’IOS. Dans un environnement de production, cette mesure de sécurité se justifie pleinement. Mais dans notre environnement didactique, que de temps perdu à ouvrir des sessions. Ce problème est facilement levé grâce à la commande de configuration de ligne exectimeout. Cette commande définit le délai d’attente maximal de l’interpréteur de commandes EXEC jusqu’à détection d’une entrée quelconque de l’utilisateur. Parvenu à ce délai, la session est interrompue. ■
Placez l’interface en configuration de ligne console. Tapez les 4 caractères exec puis appuyez sur la touche ?, l’aide contextuelle fournit trois commandes qui ont en commun de débuter par exec. Complétez la commande en cours d’édition en tapant les caractères t puis la touche [Tab]. L’IOS complète la commande et affiche exec timeout suivi d’un espace. Tapez à nouveau le point d’interrogation. L’aide affiche l’argument suivant attendu, il s’agit d’un temps exprimé en minutes. Tapez 0 suivi d’un espace et à nouveau le point d’interrogation. Observez que cette fois, deux choix sont possibles : appuyez sur la touche [Entrée] pour valider la commande telle qu’elle est ou entrez un second argument permettant d’exprimer un temps en secondes. Validez par la touche [Entrée]. Vous venez de mettre à profit la fonctionnalité d’aide sur le mot puis la fonctionnalité d’aide sur la syntaxe :
R8 con0 is now available Press RETURN to get started. R8>en Password: R8#conf t 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 R8(config-line)#exec-timeout 0
■
Vous êtes toujours en configuration de ligne console. Simulez une erreur de frappe en tapant la commande exec tileout 0 puis validez par la touche [Entrée]. Observez que l’IOS ne se contente pas de refuser la commande mais place un caractère ^ à partir de la position incorrecte dans la ligne de commande :
R8(config-line)#exec-tileout 0 ^ % Invalid input detected at ’^’ marker.
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 :
Vous êtes toujours en configuration de ligne console. Utilisez les touches de déplacement [Flèche en haut] et [Flèche en bas] pour vous déplacer dans l’historique des commandes ; observez que seules les commandes valides dans le contexte sont rappelées. Changez de contexte en revenant au mode privilégié. À nouveau, rappelez les commandes précédentes et observez que cette fois l’historique affiche les commandes précédemment entrées dans ce mode privilégié.
Cet atelier est à présent terminé. Bien sûr, le lecteur peut le prolonger à loisir. L’important est de disposer d’un contexte fonctionnel pour les ateliers à venir des chapitres suivants.
Mise en situation Toutes les captures de ce chapitre ont été réalisées sur la topologie suivante :
Les routeurs sont des 2600, l’IOS est une version 12.4. Le serveur VMSRV01 est un serveur Windows 2000 utilisé chaque fois qu’il est utile de disposer de services réseau. Dans le cas présent, c’est le service DNS qui est mis à profit. L’administrateur y a créé une zone ccna.fr ainsi que deux enregistrements R11 et R12. Le lecteur gagnera à reproduire cette topologie puis à tester l’ensemble des lignes de commandes proposées.
Configuration des paramètres globaux 1. Configurer l’invite de commande Par défaut, l’invite de commande résulte de la concaténation de trois informations : 1. Le nom du routeur, « Router » quand le nom n’a pas encore été configuré. 2. Le contexte quand l’interface ILC quitte le mode d’exécution. Exemple (config) quand le mode de l’interface ILC est le mode de configuration globale. 3. Le caractère de prompt « > » ou « # » qui rappelle le niveau de privilège, « > » rappelle le mode utilisateur, « # » rappelle le mode privilégié. Il est possible de compléter l’information fournie à l’aide de la commande prompt dont la syntaxe est la suivante : ●
prompt string ●
●
Mode de configuration globale. String est toute chaîne de caractères dans laquelle il est possible d’inclure un certain nombre de variables. Une variable de prompt est précédée du caractère « % ». Le tableau suivant inventorie les variables de prompt possibles :
Variable de 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 %.
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 * 0 CTY 0 65 AUX 9600/9600 0 * 66 VTY 1 67 VTY 0 68 VTY 0 69 VTY 0 70 VTY 0
Line(s) not in async mode -or- with no hardware support:1-64 TTY66@R11 #disable TTY66@R11 > Deux sessions sont ouvertes sur R11, l’une via le port console qui porte le numéro 0, l’autre via Telnet à laquelle l’IOS
a attribué le premier numéro VTY disponible, soit le numéro 66. La capture suivante illustre le changement de l’invite de commande sur la session console : *Mar 1 01:13:03.706: %SYS-5-CONFIG_I: Configured from console by vty0 (10.0.11.100) R11# TTY0@R11 #
2. Configurer un nom d’hôte La commande à utiliser est : ●
hostname name ●
Mode de configuration globale.
●
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 : « Token »
Information correspondante
$(hostname) Nom d’hôte du routeur. $(domain)
Nom de domaine configuré sur le routeur.
$(line)
Numéro de la ligne active.
$(linedesc) Description de la ligne active. Mettons à profit ces variables pour créer une bannière exec sur R12 : R12(config)#banner exec # 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.
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. R11(config)#no ip domain-lookup R11(config)#^Z R11#
End with CNTL/Z.
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 ...]} ●
Mode de configuration globale.
●
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 ●
Mode de configuration globale.
●
Active/Désactive la résolution dynamique de noms (c’estàdire celle faisant appel à un serveur DNS).
ip nameserveur {@DNS1 [@DNS2 @DNS3 ... @DNS6]} ●
Mode de configuration globale.
●
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} ●
●
Mode de configuration globale. 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 R12 R11#
Port None
Flags Age Type (perm, OK) 0 IP
Address(es) 10.0.8.12
Les champs de cette table sont explicités dans le tableau ciaprès : Information
Description
Host
Nom d’hôte de chaque correspondance présente dans la table.
Port
Port utilisé lors d’une connexion Telnet si différent de 23.
Flags
Drapeaux décrivant la méthode d’apprentissage de cette correspondance ainsi que son degré de pertinence. Perm → correspondance statique, ajoutée par l’administrateur. Temp → correspondance acquise via un serveur DNS. OK → correspondance valide. EX → correspondance expirée.
Age
Exprimé en heures, temps écoulé depuis l’instant où la correspondance a été apprise.
Type
Type d’adresse.
Address
Adresse(s) associée(s) à ce nom d’hôte.
b. Résolution dynamique Un serveur DNS a été ajouté sur LAN12 de la topologie en cours. Son adresse IP est 10.0.12.100. Il héberge la zone ccna.fr et l’administrateur y a ajouté deux enregistrements R11 et R12 :
Sur R11 (à reproduire sur R12) : R11(config)#no R11(config)#ip R11(config)#ip R11(config)#ip R11(config)#^Z R11#
ip host R12 10.0.8.12 domain-lookup domain-name ccna.fr name-server 10.0.12.100
*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 R12.ccna.fr R11#
Port None
Flags Age Type (temp, OK) 0 IP
Address(es) 10.0.12.1
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 ●
●
●
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] ●
Mode de configuration globale.
●
Fait de ce routeur un serveur de temps.
●
●
Affiche la date et l’heure du système.
#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 } ●
●
Mode de configuration globale. 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 ?
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 authenticate authentication-key broadcastdelay clock-period logging master max-associations peer server source trusted-key
Control NTP access Authenticate time sources Authentication key for trusted time sources Estimated round-trip delay Length of hardware clock tick Enable NTP message logging Act as NTP master clock Set maximum number of associations Configure NTP peer Configure NTP server Configure interface for source address Key numbers for trusted time sources
R12(config)#ntp master ? <1-15> Stratum number R12(config)#ntp master R12(config)#^Z R12# Faisons de R11 un client du serveur de temps R12 : R11(config)#ntp ? access-group authenticate authentication-key broadcastdelay clock-period logging master max-associations peer server source trusted-key
Control NTP access Authenticate time sources Authentication key for trusted time sources Estimated round-trip delay Length of hardware clock tick Enable NTP message logging Act as NTP master clock Set maximum number of associations Configure NTP peer Configure NTP server Configure interface for source address 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 ●
Mode de configuration globale.
●
Active/désactive le serveur http interne du routeur.
●
Actif par défaut.
Accéder à ce service nécessite de disposer d’un navigateur Web et d’y entrer l’adresse IP d’une interface du routeur. Lors de la connexion, le serveur demande à l’utilisateur de s’authentifier. À moins qu’une authentification plus forte n’ait été configurée, il suffit de laisser le champ nom d’utilisateur vide et de taper le mot de passe qui protège le passage au mode privilégié.
Configuration des interfaces En connectant le routeur à son environnement, les interfaces LAN et WAN permettent au routeur d’assurer la tâche pour laquelle il a été conçu, c’estàdire l’acheminement des paquets. Il faut encore y ajouter l’interface de loopback, interface virtuelle qui peut rendre de nombreux services : l’adresse IP affectée à l’interface peut fournir un identifiant au routeur, l’interface peut servir de destination aux paquets indésirables, l’interface virtuelle peut simuler une interface réelle, liste non exhaustive. Une commande show interfaces affiche une information très complète sur chacune des interfaces embarquées par le routeur. Pour une interface LAN : R11#sh int FastEthernet0/0 is up, line protocol is up Hardware is AmdFE, address is c801.02cc.0000 (bia c801.02cc.0000) Description: LAN11 Internet address is 10.0.11.1/24 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:49, output 00:00:02, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 4 packets input, 526 bytes Received 4 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog 0 input packets with dribble condition detected 11 packets output, 1583 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out Pour une interface WAN : Serial0/0 is up, line protocol is up Hardware is PowerQUICC Serial Description: Lien loue 64K vers Nantes Internet address is 10.0.8.11/24 MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set Keepalive set (10 sec) Last input 00:00:01, output 00:00:03, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/1/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 48 kilobits/sec 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 12 packets input, 1329 bytes, 0 no buffer Received 12 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 9 packets output, 1143 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out
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 FastEthernet0/0 Serial0/0 FastEthernet0/1 Serial0/1 R11#
Status Protocol up up up up administratively down down administratively down down
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 FastEthernet0/0 Serial0/0 FastEthernet0/1 Serial0/1 R11#
La commande provoque le passage en configuration d’interface.
[no] shutdown ●
Mode de configuration d’interface.
●
Active/désactive l’interface.
●
●
- 4-
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.
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} ●
●
●
●
Mode de configuration d’interface. 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} ●
Mode de configuration globale.
●
La commande provoque le passage en configuration d’interface.
●
●
Le motclé async est utilisé lorsque l’on a affaire à une interface série fonctionnant en mode asynchrone (marginal).
Mode de configuration d’interface. 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} ●
●
●
Déjà décrit.
Mode de configuration d’interface. 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} ●
●
Mode de configuration d’interface. 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.
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} ●
Mode de configuration globale.
●
La commande provoque le passage en configuration d’interface.
ip address {@IP} {masque} [secondary] ●
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 FastEthernet0/0 Serial0/0 FastEthernet0/1 Serial0/1 Loopback0
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
show runningconfig
*****
show startupconfig
****
show version
show processes
**
*
Affiche ...
Le fichier de configuration courante. Le fichier de sauvegarde de la configuration. 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... 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 ?
*
show stacks show buffers
Les nombreuses options possibles de cette commande qui globalement, fournit des statistiques sur la mémoire du routeur. L’utilisation des piles par les processus.
*
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
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
*
show history
- 2-
**
L’heure et la date. Essayer également show clock detail. L’historique des commandes précédemment entrées.
Sauvegarde et restauration des configurations 1. Sauvegarde/Restauration via TFTP RFC utiles : ●
RFC1350 The TFTP Protocol Juillet 1992
Toutes les applications n’ont pas besoin de la totalité des fonctions offertes par FTP. La complexité de FTP est acquise au prix d’une application au volume conséquent. La pile de protocoles TCP/IP dispose d’un second protocole de transfert de fichiers appelé TFTP (Trivial File Transfer Protocol, Trivial = simple), très simple, sans contrôle d’accès, sans possibilité de lister les fichiers distants (il faut connaître le nom du fichier à récupérer). Les capacités de TFTP se bornent à lire ou écrire des fichiers depuis ou vers un serveur distant. Il est donc moins volumineux que FTP, ce qui permet par exemple de l’embarquer en mémoire morte d’un système informatique quelconque, avec un programme d’amorce qui s’en servira pour rapatrier un système d’exploitation depuis un serveur distant. TFTP s’exécute audessus d’UDP, le serveur TFTP offre son service sur le port UDP 69. Le premier datagramme UDP transporte la demande de transfert de fichier qui sert aussi de demande de connexion. Si le serveur autorise la requête, le fichier est envoyé par fragments de taille fixe de 512 octets. L’émetteur envoie un de ces fragments puis attend un accusé de réception pour ce fragment avant d’envoyer le suivant. Le récepteur acquitte chaque fragment dès sa réception. Un paquet de données de moins de 512 octets signale la fin du transfert et la fin du fichier. L’émetteur d’un paquet « N » (données ou acquittement) arme un temporisateur. Si ce temporisateur expire avant que le paquet suivant ne lui soit parvenu, alors l’émetteur retransmet ce paquet « N ». Ainsi, l’émetteur ne conserve en mémoire qu’un seul paquet dans l’attente éventuelle d’une retransmission. Les fragments du fichier sont numérotés séquentiellement à partir de 1. Chaque paquet de données contient un entête qui indique le numéro du fragment transporté. Un message d’erreur peut remplacer un paquet de données ou un accusé de réception. Il provoque la terminaison immédiate du transfert. Une fois demandée la lecture ou l’écriture du fichier, le serveur utilise l’adresse IP et le port UDP du client pour identifier les échanges de la session TFTP. Ainsi, les messages de données ou d’acquittements n’ont pas besoin de préciser le nom du fichier. TFTP devrait être réservé à un usage sur réseau local. Les équipements réseaux embarquent TFTP afin de permettre la mise à jour de leurs systèmes d’exploitation. Commençons par mettre en place un serveur TFTP sur la machine virtuelle VMSRV01. L’Internet fourmille de petits utilitaires gratuits pouvant remplir cet office. Dans l’ouvrage Cisco Notions de base sur les réseaux dans la collection Certifications aux Editions ENI, nous avions déjà mis à profit l’excellent Tftpd32 capable autant de réaliser un serveur DHCP qu’un serveur TFTP ou un serveur SYSLOG. Évitons de nous disperser, il fera parfaitement l’affaire. Pour mémoire, il est possible de le télécharger depuis le site : http://tftpd32.jounin.net/ La figure cidessous illustre quelques étapes de la préparation d’un serveur TFTP sur la machine VMSRV01. Un répertoire CONFIGS a été créé dans le répertoire racine du serveur TFTP. Le serveur est à l’adresse 10.0.12.100, à l’écoute sur le port 69 :
Dans l’interface ILC, la commande à utiliser est la commande copy dont la fonction est de copier tout fichier d’une source vers une destination. Une demande d’aide permet de se rendre compte de la quantité de sources et destinations connues de l’IOS : R11#copy ? /erase /error /noverify /verify archive: cns: flash: ftp: http: https: ips-sdf null: nvram: pram: rcp: running-config scp: startup-config system: tftp: xmodem: ymodem:
Erase destination file system. Allow to copy error file. Don’t verify image signature before reload. Verify image signature before reload. Copy from archive: file system Copy from cns: file system Copy from flash: file system Copy from ftp: file system Copy from http: file system Copy from https: file system Copy from current IPS signature configuration Copy from null: file system Copy from nvram: file system Copy from pram: file system Copy from rcp: file system Copy from current system configuration Copy from scp: file system Copy from startup configuration Copy from system: file system Copy from tftp: file system Copy from xmodem: file system Copy from ymodem: file system
La syntaxe de la commande copy est la suivante : ●
/noverify : ne s’applique qu’aux fichiers d’images IOS, permet de désactiver pour cette copie la vérification systématique des copies d’images IOS, vérification entreprise parce que l’administrateur a entré la commande de configuration globale file verify auto. Sourceurl et destinationurl : comprend à la fois la localisation du fichier ainsi que son nom. Source et destination peuvent être locales ou distantes.
Avant toute mise en œ uvre, testons la connectivité avec le serveur TFTP : R11#ping 10.0.12.100 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.12.100, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 24/37/56 ms R11# En version une seule ligne, la commande suivante permet de copier le fichier de configuration courante vers le fichier R11confg.txt situé dans le sousrépertoire CONFIGS luimême placé à la racine du serveur TFTP, c’estàdire dans le répertoire C:\TFTP de la machine VMSRV01 : R11#copy run tftp://10.0.12.100/configs/R11-confg.txt Address or name of remote host [10.0.12.100]? Destination filename [configs/R11-confg.txt]? .!! 1799 bytes copied in 7.752 secs (232 bytes/sec) R11# Le fichier de configuration courante peut indifféremment être désigné par {run | running config | system:running config}. La même commande peut fonctionner de manière interactive : R11#copy run tftp Address or name of remote host []? 10.0.12.100 Destination filename [r11-confg]? configs/r11-confg.txt !! 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 startup configuration. Ainsi, la modification ne sera prise en compte que lors du prochain démarrage. La commande suivante permet de récupérer un fichier de configuration sur un serveur TFTP et d’en faire le fichier de sauvegarde de la configuration du routeur, c’estàdire le fichier « Startupconfig » : R11#copy tftp://10.0.12.100/configs/R11-confg.txt start 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 | startup config | nvram:startup config}. Vérifions que la modification est bien prise en compte en redémarrant R11. Attention, sous GNS3 à bien sauvegarder la topologie avant d’arrêter R11 (ce qui provoque la sauvegarde sur disque de la NVRAM simulée). Le redémarrage peut être provoqué à l’aide d’une commande reload en mode privilégié. La syntaxe de cette commande est la suivante : ●
reload [/verify | /noverify] [line | in [hhh:mm |mmm [text ]] | at hh:mm [text] | cancel] ●
Mode privilégié.
●
/verify : vérifie la signature du fichier IOS qui sera chargé suite au redémarrage.
●
●
- 4-
/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
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)
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
- 2-
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))
H323 GateKeeper/Proxy pour 2500 3620, 3640, MC3810
Quelques exemples d’assemblages possibles : ■
Tapez dans un moteur de recherche « Cisco IOS 12.3 Feature Sets for Cisco 2600XM ». Vous pouvez bien sûr remplacer Cisco 2600XM par la plateforme qui vous concerne.
■
Si le lien existe encore au moment où vous lisez ces lignes, cliquez sur le lien vers le document...
Au moment où ces lignes sont écrites, CISCO propose les packages suivants pour cette plateforme : Feature Set
Image Filename
Packages classiques ENTERPRISE/FW/IDS PLUS IPSEC 3DES
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, Software (), Version , Technical Support: http://www.cisco.com/techsupport Copyright (c) by Cisco Systems, Inc. Compiled
