TP3 Ris
TP3 Ris
TP3 Ris
Schéma de topologie
Table d’adressage
Périphérique Interface Adresse IP Masque de sous-réseau Passerelle par défaut
Étape 1 : réaliser sous Packet Tracer un réseau similaire à celui du schéma de topologie
Étape 2 : suppression de la configuration sur chaque routeur
Supprimez la configuration sur chaque routeur à l’aide de la commande erase startup-config,
puis rechargez les routeurs à l’aide de la commande reload. Répondez « Non » si une fenêtre vous
demande d’enregistrer les modifications.
Étape 2 : configuration des mots de passe de ligne de console et de terminal virtuel pour
chaque routeur
Router(config)# line console 0
Router(config-line)# password ...
Router(config-line)# login
Pour synchroniser les messages et les données de débogage non sollicités avec les
informations du logiciel IOS sollicitées et les invites d’une ligne de port console donnée, d’une
ligne de port auxiliaire ou d’une ligne de terminal virtuel, il est possible d’utiliser la commande
de configuration de ligne logging synchronous. En d’autres termes, la commande
logging synchronous évite que les messages IOS émis vers la console ou vers les lignes
Telnet interrompent vos saisies sur le clavier.
Par exemple, vous avez sans doute rencontré la situation suivante :
Remarque : ne configurez pas encore les interfaces R1.
R1(config)#interface fastethernet 0/0
R1(config-if)#ip address 172.16.3.1 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#descri
*Mar 1 01:16:08.212: %LINK-3-UPDOWN: Interface FastEthernet0/0,
changed state to up
*Mar 1 01:16:09.214: %LINEPROTO-5-UPDOWN: Line protocol on
Interface FastEthernet0/0, changed state to upption
R1(config-if)#
Le logiciel IOS envoie des messages non sollicités à la console lorsque vous activez une
interface via la commande no shutdown. Cependant, la saisie de la commande suivante
(dans ce cas précis description) est interrompue par ce message. La commande logging
synchronous résout ce problème en copiant la commande entrée à l’invite suivante du
routeur.
R1(config)#interface fastethernet 0/0
R1(config-if)#ip address 172.16.3.1 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#description
*Mar 1 01:28:04.242: %LINK-3-UPDOWN: Interface FastEthernet0/0,
changed state to up
*Mar 1 01:28:05.243: %LINEPROTO-5-UPDOWN: Line protocol on
Interface FastEthernet0/0, changed state to up
R1(config-if)#description <-- Entrée clavier copiée après le message
R1 a été choisi à titre d’exemple. Ajoutez la commande logging synchronous aux lignes
de terminal virtuel et de console de tous les routeurs.
R1(config)#line console 0
R1(config-line)#logging synchronous
R1(config-line)#line vty 0 4
R1(config-line)#logging synchronous
Description de la syntaxe :
minutes : valeur numérique indiquant le nombre de minutes.
secondes : intervalle de temps supplémentaire exprimé en secondes (facultatif).
Dans un environnement expérimental, vous pouvez spécifier « no timeout » (pas de délai
d’attente) en saisissant la commande exec-timeout 0 0. Cette commande est très utile,
car le délai d’attente par défaut est de 10 minutes. En production par contre, pour des raisons
de sécurité, les lignes ne sont pas configurées avec une commande « no timeout ».
R1 a été choisi à titre d’exemple.
Ajoutez la commande exec-timeout 0 0 aux lignes de terminal virtuel et de console
de tous les routeurs.
R1(config)#line console 0
R1(config-line)#exec-timeout 0 0
R1(config-line)#line vty 0 4
R1(config-line)#exec-timeout 0 0
Étape 1 : sur R1, en mode d’exécution privilégié, entrée de la commande debug ip routing
R1#debug ip routing
IP routing debugging is on
La commande debug ip routing indique les routes qui sont ajoutées, modifiées et
supprimées de la table de routage. Ainsi, à chaque configuration et activation d’interface, IOS
ajoute une route à la table de routage. Il est possible de le vérifier en consultant les
informations issues de la commande debug ip routing.
Dès que vous appuyez sur la touche Entrée, les informations de débogage IOS signalent la
présence d’une nouvelle route, mais son état est False. En d’autres termes, vous n’avez
pas encore ajouté de route à la table de routage. Pourquoi et quelles sont les mesures à
prendre pour que la route soit effectivement entrée dans la table de routage ?
Le nouveau réseau que vous avez configuré sur l’interface du réseau local (LAN) est maintenant
ajouté à la table de routage (partie surlignée du résultat affiché).
172.16.0.0/24 is subnetted, 1
subnets
C 172.16.3.0 is directly connected, FastEthernet0/0
Dès que vous appuyez sur la touche Entrée, les informations de débogage IOS signalent la
présence d’une nouvelle route, mais son état est False. Étant donné que R1 représente la
partie ETCD de notre environnement expérimental, nous devons indiquer la vitesse de
synchronisation des bits entre R1 et R2.
Certaines versions du logiciel IOS affichent ces informations toutes les 30 secondes. Pourquoi
l’état de la route est-il encore False ? Quelles sont les mesures à prendre maintenant pour
vérifier que l’interface est entièrement configurée ?
Étape 7 : entrée de la commande permettant de vérifier que l’interface est entièrement configurée
R1(config-if)#
Lorsque vous avez entré la commande correcte, les données de débogage s’affichent
comme dans l’exemple suivant :
is_up: 0 state: 0 sub state: 1 line: 0 has_route: False
%LINK-3-UPDOWN: Interface Serial0/0/0, changed state to down
Étape 9 : entrée de la commande permettant de vérifier que l’interface est entièrement configurée
R2(config-if)#
Lorsque vous avez entré la commande correcte, les données de débogage s’affichent
comme dans l’exemple suivant :
is_up: 0 state: 4 sub state: 1 line: 0
%LINK-3-UPDOWN: Interface Serial0/0/0, changed state
to up is_up: 1 state: 4 sub state: 1 line: 0
RT: add 172.16.2.0/24 via 0.0.0.0, connected metric [0/0]
RT: interface Serial0/0/0 added to routing
table is_up: 1 state: 4 sub state: 1 line:
0
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0, changed
state to up
is_up: 1 state: 4 sub state: 1 line: 0
Le nouveau réseau que vous avez configuré sur l’interface du réseau étendu est maintenant
ajouté à la table de routage (partie surlignée de la sortie).
172.16.0.0/24 is subnetted, 2
subnets
C 172.16.2.0 is directly connected, Serial0/0/0
C 172.16.3.0 is directly connected, FastEthernet0/0
R2#
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile,
B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF
inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA
external type 2 E1 - OSPF external type 1, E2 - OSPF
external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter
area
* - candidate default, U - per-user static route, o
- ODR P - periodic downloaded static route
172.16.0.0/24 is subnetted, 1
subnets
C 172.16.2.0 is directly connected, Serial0/0/0
Si la réponse à une de ces questions est « Non », vérifiez les configurations pour trouver
les erreurs. Procédez comme suit :
1. Vérifiez le câblage.
Les routeurs sont-ils physiquement connectés ?
Les voyants de liaison clignotent-ils sur tous les ports concernés ?
2. Vérifiez les configurations du routeur.
Correspondent-elles au schéma de topologie ?
Avez-vous configuré la commande clock rate du côté ETCD de la liaison ?
3. L’interface est-elle activée ?
4. Vérifiez les interfaces du routeur à l’aide de la commande show ip interface
brief. Les interfaces apparaissent-elles up et up ?
Si la réponse à ces trois questions est « Oui », l’envoi de la requête ping de R2 vers R1 et de
R2 vers R3 doit aboutir.
Les interfaces correspondantes de chaque routeur sont-elles activées (c’est-à-dire que leur état est up et
up) ?
Combien y a-t-il d’interfaces activées sur R1 et R3 ?
Pourquoi y a-t-il trois interfaces actives sur R2 ?
172.16.0.0/24 is subnetted, 2
subnets
C 172.16.2.0 is directly connected, Serial0/0/0
C 172.16.3.0 is directly connected, FastEthernet0/0
Quels sont les réseaux présents dans le schéma de topologie, mais pas dans la table de
routage pour R1 ?
R2#
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile,
B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF
inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA
external type 2 E1 - OSPF external type 1, E2 - OSPF
external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate
default U - per-user static route, o - ODR
172.16.0.0/24 is subnetted, 2
subnets
C 172.16.1.0 is directly connected, FastEthernet0/0
C 172.16.2.0 is directly connected,
Serial0/0/0 C 192.168.1.0/24 is directly
connected, Serial0/0/1
Quels sont les réseaux présents dans le schéma de topologie, mais pas dans la table de
routage pour R2 ?
R3#
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile,
B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF
inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA
external type 2 E1 - OSPF external type 1, E2 - OSPF
external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate
default U - per-user static route, o - ODR
Pourquoi tous ces réseaux ne se trouvent-ils pas dans les tables de routage des autres routeurs ?
Que faut-il ajouter au réseau pour que les périphériques qui ne sont pas directement
connectés puissent s’envoyer mutuellement des paquets ping ?
Tâche 8 : configuration d’une route statique en utilisant une adresse du tronçon suivant
Sur le routeur R3, configurez une route statique vers le réseau 172.16.1.0 en utilisant
l’interface série 0/0/1 de R2 comme adresse du tronçon suivant.
R3(config)#ip route 172.16.1.0 255.255.255.0 192.168.1.2
R3(config)#
Étape 2 : affichage de la table de routage pour vérifier la nouvelle entrée de la route statique
Remarquez que la route est codée avec un S, ce qui indique qu’il s’agit d’une route statique.
R3#
172.16.0.0/24 is subnetted, 1
subnets
S 172.16.1.0 [1/0] via 192.168.1.2
C 192.168.1.0/24 is directly connected, Serial0/0/1
C 192.168.2.0/24 is directly connected,
FastEthernet0/0
R3#
Lorsque cette route est introduite dans la table de routage, tous les paquets qui correspondent aux
24 premiers bits les plus à gauche de 172.16.1.0/24 sont transférés vers le routeur du tronçon
suivant sur 192.168.1.2.
Quelle interface R3 va-t-il utiliser pour transférer les paquets vers le réseau 172.16.1.0/24 ?
Supposons que les paquets suivants sont arrivés sur R3 avec l’adresse de destination
indiquée. Le paquet est-il abandonné par R3, ou est-il transféré ? Si R3 transfère le
paquet, quelle interface sera utilisée ?
Bien que R3 transfère les paquets vers les destinations pour lesquelles une route a été
définie, cela ne signifie pas que le paquet va parvenir sans problème à sa destination finale.
Étape 3 : utilisation de la commande ping pour tester la connectivité entre l’hôte PC3
et l’hôte PC2
À partir de l’hôte PC3, est-il possible d’envoyer une requête ping à l’hôte PC2 ?
Ces requêtes ping doivent échouer. Les requêtes ping parviennent au PC2 si vous avez
configuré et testé tous les périphériques, « Collecte des informations ». PC2 envoie une
réponse ping à PC3. Toutefois, cette réponse est abandonnée sur R2 car ce dernier ne
dispose pas d’une route de retour vers le réseau 192.168.2.0 dans la table de routage.
Étape 5 : affichage de la table de routage pour vérifier la nouvelle entrée de la route statique
Remarquez que la route est codée avec un S, ce qui indique qu’il s’agit d’une route statique.
R2#
172.16.0.0/24 is subnetted, 2
subnets
C 172.16.1.0 is directly connected, FastEthernet0/0
C 172.16.2.0 is directly connected,
Serial0/0/0 C 192.168.1.0/24 is directly
connected, Serial0/0/1 S 192.168.2.0/24 [1/0]
via 192.168.1.1
R2#
Étape 6 : utilisation de la commande ping pour tester la connectivité entre l’hôte PC3
et l’hôte PC2
À partir de l’hôte PC3, est-il possible d’envoyer une requête ping à l’hôte PC2 ?
Cette commande ping doit réussir.
Étape 2 : affichage de la table de routage pour vérifier la nouvelle entrée de la route statique
R3#
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile,
B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF
inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA
external type 2 E1 - OSPF external type 1, E2 - OSPF
external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate
default U - per-user static route, o - ODR
172.16.0.0/24 is subnetted, 2
subnets
S 172.16.1.0 [1/0] via 192.168.1.2
S 172.16.2.0 is directly connected,
Serial0/0/1 C 192.168.1.0/24 is directly
connected, Serial0/0/1
C 192.168.2.0/24 is directly connected,
FastEthernet0/0 R3#
<résultat omis>
!
hostname R3
!
interface FastEthernet0/0
ip address 192.168.2.1 255.255.255.0
!
interface
Serial0/0/0 no ip
address shutdown
!
interface Serial0/0/1
ip address 192.168.1.1 255.255.255.0
!
ip route 172.16.1.0 255.255.255.0 192.168.1.2
ip route 172.16.2.0 255.255.255.0 Serial0/0/1
!
end
Étape 4 : affichage de la table de routage pour vérifier la nouvelle entrée de la route statique
R2#
172.16.0.0/24 is subnetted, 3
subnets
C 172.16.1.0 is directly connected, FastEthernet0/0
C 172.16.2.0 is directly connected,
Serial0/0/0 S 172.16.3.0 is directly
connected, Serial0/0/0 C 192.168.1.0/24 is
directly connected, Serial0/0/1 S
192.168.2.0/24 [1/0] via 192.168.1.1
R2#
À ce stade, R2 dispose d’une table de routage complète, qui contient toutes les routes
valides vers les cinq réseaux mentionnés dans le schéma de topologie.
Cela signifie-t-il que R2 peut recevoir des réponses ping de toutes les destinations
mentionnées dans le schéma de topologie ?
Justifiez votre réponse.
Étape 5 : utilisation de la commande ping pour tester la connectivité entre l’hôte PC2 et PC1
Cette requête ping échoue car R1 ne dispose pas d’une route de retour vers le réseau
172.16.1.0 dans la table de routage.
Étape 2 : affichage de la table de routage pour vérifier la nouvelle entrée de la route statique
R1#
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile,
B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF
inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA
external type 2 E1 - OSPF external type 1, E2 - OSPF
external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate
default U - per-user static route, o - ODR
Remarquez que le routeur R1 possède maintenant une route par défaut, appelée passerelle
de dernier recours (notée dans le script gateway of last resort) et qu’il va transmettre tout le
trafic inconnu via l’interface série 0/0/0 qui est connectée à R2.
Étape 3 : utilisation de la commande ping pour tester la connectivité entre l’hôte PC2 et PC1
Est-il possible d’envoyer une requête ping au PC1 depuis le PC2 hôte ?
Cette commande ping doit maintenant aboutir, car le routeur R1 peut renvoyer le paquet en
utilisant la route par défaut.
Est-il possible d’envoyer une requête ping au PC1 hôte depuis le PC3 hôte ?
La table de routage sur R3 contient-elle une route à destination du réseau 172.16.3.0 ?
172.16.1.0 10101100.00010000.00000001.00000000
172.16.2.0 10101100.00010000.00000010.00000000
172.16.3.0 10101100.00010000.00000011.00000000
Pour créer un masque avec les 22 bits les plus à gauche, on utilise un masque dont 22 bits
sont activés, de gauche à droite :
Bit Mask 11111111.11111111.11111100.00000000
La configuration d’une route résumée sur R3 n’a pas supprimé les routes statiques configurées
auparavant, car elles sont plus spécifiques. Elles utilisent toutes deux le masque /24, alors que
la route résumée utilise le masque /22. Nous pouvons désormais supprimer les routes /24, plus
spécifiques, pour minimiser la taille de la table de routage.
R3 possède maintenant une seule route à destination de tous les hôtes des réseaux
172.16.0.0/24, 172.16.1.0/24, 172.16.2.0/24 et 172.16.3.0/24. Le trafic destiné à ces
réseaux est expédié à R2 sur 192.168.1.2.
Étape 5 : utilisation de la commande ping pour tester la connectivité entre l’hôte PC3 et PC1
Est-il possible d’envoyer une requête ping au PC1 hôte depuis le PC3 hôte ?
Cette commande ping doit maintenant réussir, car le routeur R3 possède une route vers le réseau
172.16.3.0 et R1 peut renvoyer le paquet en utilisant la route par défaut.