TPR4 : Technologie IP

Sommaire
TP1 : Translation d’adresse, de port et routage sous Linux
Objectifs spécifiques :
1- Savoir mettre en œuvre NAT et PAT sous Linux
2- Savoir-faire du routage sous linux avec comme application le partage d’Internet

TP2 : Environnement Cisco, ACL, NAT et PAT sous Cisco

Objectifs spécifiques
1- Comprendre l’architecture d’un routeur Cisco et les modes utilisateurs
2- Savoir les différents moyens de connexion à un routeur Cisco
• Câble console
• Telnet
• Ssh
3- Savoir mettre en place des listes d’accès sous cisco
4- Savoir mettre en œuvre le NAT et PAT sous Cisco

TP3 : Routage Dynamique avec le protocole RIP

Objectifs spécifiques :
1- Comprendre les concepts de base du protocole RIP
2- Savoir mettre en œuvre le routage dynamique avec le protocole RIP
3- Savoir mettre en place de réglés de sécurité pour protéger les informations de routage

TP4 : Routage externe avec le protocole BGP

Objectifs spécifiques :
1. Comprendre les concepts de base du protocole BGP
2. Savoir mettre en œuvre le routage dynamique avec le protocole BGP
3. Savoir mettre en place de règles de sécurité pour protéger les informations de routage
L’utilitaire iptables est intégré aux noyaux Linux à partir de la version 2.4
Fonctionnement d’iptables :

À l’arrivée d’un paquet (après décision de routage) :

1. : Si le paquet est destiné à l’hôte local Alors
Début
2. : il traverse la chaîne INPUT.
3. : S’il n’est pas rejeté Alors
4. : il est transmis au processus impliqué.
Fin
5. : Sinon
6. : Si le paquet est destiné à un hôte d’un autre réseau Alors
Début
7. : il traverse la chaîne FORWARD
8. : S’il n’est pas rejeté Alors
9. : il poursuit alors sa route
Fin
Tous les paquets émis par des processus locaux au routeur traversent la chaîne OUTPUT.
L’utilitaire iptables peut être aussi utilisé pour faire du NAT ou faire le marquage des paquets.
Iptables possède trois tables de chaines que sont :
• FILTER
• NAT
• MANGLE
Le tableau ci-dessous donne les chaines FILTER (INPUT, OUTPUT, FORWARD) et NAT
(PREROUTING, POSTROUTING, OUTPUT).
La table MANGLE quant à elle sert uniquement au marquage des paquets

Fonctionnalités NAT d’Iptables

Attention : pour permettre à une machine Linux d’autoriser le transfert des datagrammes IP
d’une de ses interfaces à une autre de ses interfaces, il faut éditer le fichier /etc/[Link] et
mettre le paramètre :

Ensuite on exécute la ligne de commande pour appliquer la modification :

Les deux commandes ci-après permettent de rendre accessible la machine [Link] aux réseaux
extérieurs.
Modifications de la destination du paquet avant le routage (paquet reçu de l’extérieur) :

iptables -t nat -A PREROUTING -d [Link] -i eth1 -j DNAT -to-destination [Link]

Modification de la source du paquet après le routage (paquet émis à partir du réseau privé) :
iptables -t nat -A POSTROUTING -s [Link] -o eth1 -j SNAT -to-source [Link]

Exercice : Comment faire pour que le routeur puisse envoyer un paquet à l’adresse [Link]?
Réponse :
Il faut modifier la destination du paquet émis localement avant le routage.
iptables -t nat -A OUTPUT -d [Link] -j DNAT -to-destination [Link]

Chaine POSTROUTING
Association entre toutes les adresses privées du sous-réseau [Link]/24 avec l’interface eth1.
iptables -t nat -A POSTROUTING -o eth1 -s [Link]/24 -j MASQUERADE
Association entre toutes les adresses privées du sous-réseau [Link]/24 avec l’interface eth2.
iptables -t nat -A POSTROUTING -o eth2 -s [Link]/24 -j MASQUERADE

Les deux commandes ci-dessus permettent respectivement aux machines des réseaux
[Link]/24 et [Link]/24 d’utiliser des interfaces différentes du Routeur pour accéder à
Internet.
Transfert de Ports
On peut transférer les connexions externes vers un port donné du routeur vers un port d’une
machine dans le réseau local.
Exemple :
Transférer les connexions sur le port 80 de l’adresse [Link] sur la machine ayant l’adresse
privée [Link] sur le port 8080 :
iptables -t nat -A PREROUTING -p tcp -i eth0 -d [Link] --dport 80 --sport 1024:65535 -j DNAT
-to [Link]:8080
Iptables et filtrage
iptables peut être utilisé pour filtrer les paquets IP, TCP, UDP ou ICMP.
On peut spécifier des règles pour le rejet ou l’acceptation de paquet en utilisant la table FILTER et
des des chaînes INPUT, OUTPUT et FORWARD.

Les règles traitées de manière séquentielle : Le paquet sort dès qu’il rencontre une règle qui peut lui
être appliquée
Exemples :
o Accepter tous les paquets utilisant TCP en provenance de n’importe où et destinés à
l’adresse du routeur [Link].
iptables -A INPUT -s 0/0 -i eth0 -d [Link] -p TCP -j ACCEPT
o Accepter de router les paquets entrant sur eth0 tels que :
Adresse Source Adresse Destination Port source Port Destination

0/0 [Link] 1024-65535 80

iptables -A FORWARD -s 0/0 -i eth0 -d [Link] -o eth1 -p TCP -sport 1024:65535 -dport 80 -j
ACCEPT
Accepter un paquet ICMP “echo-request” (ping) par seconde :
iptables -A INPUT -p icmp -icmp-type echo-request -m limit -limit 1/s -i eth0 -j ACCEPT
Accepter 5 segments TCP ayant le bit SYN positionné par seconde (permet d’éviter de se faire
inonder) :
iptables -A INPUT -p tcp -syn -m limit -limit 5/s -i eth0 -j ACCEPT
Accepter de router les paquets entrants sur eth0 tels que :
Adresse Source Adresse Destination Port source Port Destination

0/0 [Link] 1024-65535 80 ou 443

iptables -A FORWARD -s 0/0 -i eth0 -d [Link] -o eth1 -p TCP --sport 1024:65535 -m
multiport --dport 80,443 -j ACCEPT
Iptables et suivi des connexions
iptables peut être utilisé pour suivre l’état des connexions disponible
Quatre états sont définis pour une connexion :
o NEW . Nouvelle connexion établie
o ESTABLISHED . La connexion analysée est déjà établie
o RELATED . La connexion est en relation avec une connexion déjà établie (ftp-data par
exemple)
o INVALID . Le paquet reçu n’appartient à aucune des trois catégories précédentes.
Exemples :
• Autoriser tous les paquets émis par le routeur concernant des connexions déjà établies.
iptables -A OUTPUT -o eth0 -m state -state ESTABLISHED,RELATED -j ACCEPT

Outils de diagnostic
On peut journaliser les actions d’iptables
Par exemple :
1. Tracer toutes les actions iptables :
iptables -A OUTPUT -j LOG
iptables -A INPUT -j LOG
iptables -A FORWARD -j LOG
2. Rajouter une règle pour tracer les paquets rejetés
iptables -N LOG_DROP
iptables -A LOG_DROP -j LOG -log-prefix ’[IPTABLES DROP] : ’
iptables -A LOG_DROP -j DROP
Les utilitaires tels que nmap, nessus peuvent être utilisés pour diagnostiquer l’état d’un firewall
(trouver les ports ouverts, détecter les services utilisant les ports, …)
Fonctionnement détaillé du NAT statique et du NAT dynamique
Généralement en entreprise lé réseau local utilisé des adresses privées dans le but :
• de gérer la pénurie d’adresses publiques
• de masquer l’intérieur du réseau par rapport à l’extérieur (le réseau peut être vu comme une
seule et même machine)
• D’améliorer la sécurité pour le réseau interne
• d’assouplir la gestion des adresses du réseau interne
• de faciliter la modification de l’architecture du réseau interne
Le mécanisme de translation d’adresses (NAT - Network Address Translation) est alors utilisé pour
que les machines du réseau local puissent accèder à internet ou rendre accessibles hébergées dans
le réseau local.
Deux types de NAT existent :
• Statique : lorsqu’on fait une association entre n adresses publiques et n adresses privées.
• Dynamique : lorsqu’on fait une association entre 1 adresse publique et n adresses privées.
NAT statique
Association entre une adresse publique et une adresse privée.

Association entre une adresse publique et une adresse privée.

Intérêt :
• Uniformité de l’adressage dans la partie privée du réseau (modification de la
correspondance @publique/@privée facile)
• Sécurité accrue (tous les flux passent par la passerelle NAT)

Inconvénient :
• Le problème de pénurie d’adresses IP publiques est non-résolu
NAT statique
Principe :
Pour chaque paquet sortant (resp. entrant), la passerelle modifie l’adresse source (resp.
destination).
NAT dynamique : Masquerading
NAT dynamique consiste à faire une association entre m adresses publiques et n adresses privées
avec (m < n).

Intérêt :
• Plusieurs machines utilisent la même adresse IP publique pour sortir du réseau privé
• Sécurité accrue (tous les flux passent par la passerelle NAT)
Inconvénient :
• Les machines du réseau interne ne sont pas accessibles de l’extérieur (impossibilité d’initier
une connexion de l’extérieur)
Comment est ce que le routeur différencie les paquets qui lui sont destinés de ceux qu’il doit
relayer?

A chaque nouvelle connexion :

1. : Modifier l’adresse source et le port source :
(@source_privée,port_source)→(@publique,port_source’)
2. : Sauvegarder l’association dans la table NAT Pour chaque paquet entrant :
3. : Chercher une association correspondant au couple (@destination, port_destination)
4. : Si ∃ une association dans la table NAT Alors
5. : Modifier l’adresse de destination et le port de destination
6. : Relayer le paquet
7. : Sinon
8. : /* Erreur de routage */
Problèmes liés à NAT dynamique
Comment faire de la translation d’adresse sur des protocoles qui ne sont pas basés sur TCP ou UDP
(pas de numéro de port)?
• Nécessité d’implémenter une méthode spécifique au protocole (identifiant ICMP pour ICMP
par exemple).
• Dans le cas des protocoles dont les paquets contiennent des données relatives aux adresses
IP, il est nécessaire de mettre en place des “proxy” (FTP en mode actif par exemple).

Comment rendre joignables des machines du réseau local?

• Nécessité de faire de la redirection de port (port forwarding/mapping).
Principe.
• Toutes les connexions entrantes sur un port donné sont redirigée vers une machine du
réseau privé sur un port (qui peut être le même ou non).
 I. La traduction d'adresse – NAT
La traduction d'adresse est gérée avec les chaînes PREROUTING, POSTROUTING et OUTPUT. Dans
la chaîne PREROUTING (avant routage), on ne peut modifier que l'adresse de destination. L'adresse
source est conservée. On fait donc du DNAT. On dit qu'on fait du "NAT destination". Dans la chaîne
POSTROUTING, (après routage) on ne peut modifier que l'adresse source. L'adresse de destination
est conservée. On fait donc du SNAT. On dit qu'on fait du "NAT source".

II. Le DNAT ou NAT Destination

On substitue à l'adresse de destination des paquets provenant du réseau public, une adresse du
réseau local privé. Dans l'exemple, les paquets à destination de la machine 195.x sont redirigés vers
la machine 172.y. On ne tient pas compte du port.
• iptables -F INPUT ;
• iptables -P INPUT ACCEPT
• iptables -F OUTPUT ;
• iptables -P OUTPUT ACCEPT
• iptables -F FORWARD ;
• iptables -P FORWARD ACCEPT
• iptables -t nat -F PREROUTING
• iptables -t nat -A PREROUTING -d [Link]/32 \ -j DNAT --to-destination [Link]/32

III. Le SNAT ou NAT Source

Le SNAT consiste à substituer une adresse source dans un paquet sortant à son adresse source
d'origine. On substitue ici, aux requêtes provenant du réseau [Link]/24, une des 10 adresses
publiques.
• iptables -F INPUT ;
• iptables -P INPUT ACCEPT
• iptables -F OUTPUT ;
• iptables -P OUTPUT ACCEPT
• iptables -F FORWARD ;
• iptables -P FORWARD ACCEPT
• iptables -t nat -F POSTROUTING
• iptables -t nat -A POSTROUTING -s [Link]/24 \ -j SNAT --to-source [Link]-
[Link]
IV. L'IP Masquerade
Dans ce cas, les adresses privées, utilisent toutes la même adresse publique. Il s'agit en fait de
translation de port
iptables -F INPUT ;
iptables -P INPUT ACCEPT
iptables -F OUTPUT
iptables -P OUTPUT ACCEPT
iptables -F FORWARD ;
iptables -P FORWARD ACCEPT
iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -s [Link]/8 -j SNAT --to-source [Link]
Une autre option consiste à utiliser l'option "MASQUERADE"
iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -s [Link]/8 -j MASQUERADE
Exemple sur un réseau privé
echo 1 > /proc/sys/net/ipv4/ip_forward
#iptables -t nat -A POSTROUTING -s [Link]/24 -j MASQUERADE

V. Fonctions de filtrage
Le filtrage des paquets au niveau IP, transport ou adresse est utilisé pour des raisons de sécurité. Par
exemple autoriser ou interdire l'accès à un service, à un réseau ou à une machine (voir fiche de cours).
Avec les noyaux 2.2, il est possible de faire du filtrage et du masquage d'adresse IP par translation de
port (PAT). Ipchains utilise, de base, trois chaînes (input, output, forward) qui contiennent des règles
de filtrage/masquage.
Les règles de filtrage sont analysées de manière séquentielle, dès qu'une règle correspond au paquet
analysé, elle est appliquée.
Chaque paquet est analysé au travers des chaînes. Si un filtre correspond, la règle associée est
appliquée au paquet ( ACCEPT, DENY, MASQ ...). Sinon le filtre suivant est testé. A la fin de chaque
chaîne un traitement "par défaut" est appliqué en dernier ressort ( ACCEPT/DENY)
VI. TD
Utiliser la documentation donnée à la fin du document.
Figure1.1 : Schéma maquette TD
1. Ecrire les règles de filtrage iptables qui répondent aux différents problèmes exprimés ci-dessous.
Notation :
A = 195.0.0, B = 172.16,
A.0 = toutes les machines du réseau A, B.0 = toutes les machines du Réseau B
A.1, B.1, indiquent respectivement [Link] et [Link]
2. Interdire tous les paquets de A.0 vers B.0
3. Interdire tous les paquets de A.0 vers B.1
4. Interdire tous les paquets NetBIOS sur A.254
5. Masquer toutes les adresses de A.0 pour tous les protocoles
6. Masquer toutes les adresses de A.0 pour tous les protocoles uniquement pour les services SMTP
et POP3
7. N'autoriser que les paquets de A.1 vers B.1, interdire tout le reste
8. Interdire les paquets de A.1 vers B.1, autoriser tout le reste
9. N'autoriser que les paquets telnet de A.1 vers B.1, interdire tout le reste
10. N'autoriser que les paquets TCP de A.0 vers B.0, interdire tout le reste.
Application sur le routage et le filtrage de paquets IP
Schéma de la maquette pour le TP
Schéma d'un réseau simple. Le routeur a trois interfaces réseau. Les segments de classe A et le
segment de classe B peuvent être réalisés à l'aide de simples machines et de câbles croisés.
Figure1.2 : Réseau simple

Schéma d'un réseau simple plus complexe. Quatre maquettes construites sur le schéma précédent
sont reliées à un segment fédérateur. Ce dernier peut être le réseau de l'établissement.
 Figure 1.3 : Réseau intégré

Vous allez réaliser ce TP sur la maquette que vous avez monté pour le routage. Vous utiliserez trois
machines C, R et S. R fait référence à votre routeur. C fait référence au client installé sur le réseau de
classe B, S fait référence au serveur installé sur le réseau de classe A.
C’est sur un réseau "privé" (C sera client pour les tests)
S est sur un réseau "public"
R servira de routeur et pare-feu (firewall) entre votre réseau privé et le réseau public.
Vous allez réaliser ce TP en trois parties :
Première partie : vérification du routage sur le routeur logiciel R,
Deuxième partie : mise en œuvre de règles de filtrage simples et de la tranduction d'adresse sur R
Troisième partie : mise en place de règles de filtrage par adresse, par port et par protocole
Vous utiliserez la documentation de ipchains ou iptables ainsi que les exemples commentés qui vous
sont fournis.
Première partie : installation et configuration du routage
1. Installez les interfaces réseau sur le routeur et démarrer la machine.
2. Créez les fichiers de configuration des interfaces eth0, eth1 et eth2.
3. Installez le module de la carte dans le fichier " /etc/[Link] " si nécessaire
4. Lancez le service réseau sur R " /etc/rc.d/init.d/network restart ", relevez les routes.
5. Vérifiez à l'aide de la commande " ifconfig " que les interfaces sont bien actives. Corrigez tant
que ce n'est pas le cas. Configurez et installez C sur votre réseau privé,
6. Testez l'accès de C vers les deux interfaces de R. Pourquoi l'accès vers le réseau public ne
fonctionne pas ?
7. Activez le routage (ip forward) entre les interfaces réseau. (NETWORKING=yes dans
/etc/sysconfig/network pour Mandrake ou ip_forward=yes dans /etc/network/options pour
Debian.
Vous pouvez également utiliser la commande :
echo 1 > /proc/sys/net/ipv4/ip_forward
 8. Relancez le service réseau, relevez les routes de R à l'aide de la commande " route ".
9. Vérifiez avec une commande " ping " que les deux interfaces de R sont bien visibles à partir
de C.
10. Vérifiez l'installation du programme iptraf sur R

Deuxième partie : Règles de filtrage simples

1. Interdisez toutes les requêtes de C vers S (extérieur) (tester)
2. Autorisez toutes les requêtes du client C vers S (tester)
3. Interdisez tout passage sur la chaîne FORWARD en laissant l'option " ACCEPT " sur les
chaînes INPUT et OUTPUT (tester)
4. Activez le masquage d'adresse pour toutes les machines du réseau auquel appartient C vers
tous les autres réseaux (tester)
5. Activez le masquage d'adresse pour toutes les machines du réseau auquel appartient C vers
un seul des autres réseaux. Exemple si vous êtes sur le domaine [Link], activer le masquage
vers [Link]. Les paquets ne devront pas passer vers [Link] ou [Link]. (tester)
6. Restaurez l'état réalisé au point 4 (après masquage). Activez " iptraf " sur l'interface publique.
Vérifiez que seule, l'adresse ip de l'interface du réseau privé apparaît et que toutes les autres
sont " masquées ". Notez la traduction de port et identifiez les sessions.

Troisième partie : Règles de filtrage par adresse, port et protocoles

1. Relevez dans le fichier " /etc/protocol " et " /etc/services " les ports et noms des protocoles
utilisés par les services ftp et http. Refusez tout trafic de C vers l'extérieur à destination de
ces ports. Vérifier que telnet est accepté. (tester puis restaurer)
2. N'autorisez à C l'accès qu'à une seule machine (par exemple le client C de [Link] si vous
êtes sur [Link]), refusez tout le reste. (tester puis restaurer)
3. Refusez tout accès à la machine (192.168.x.1) de votre réseau (192.168.x.0) vers le réseau
(192.168.y.0). (tester.) (tester aussi en modifiant l'adresse ip de votre client que celui-ci passe.)
4. Relevez les ports et protocoles utilisés par les services de résolution de noms Construisez les
règles afin qu'elles répondent au problème suivant. On désire que : toutes les machines du
réseau privé puissent avoir accès à tous les autres services de n'importe quel réseau, la
machine C de votre réseau privé ne peut pas envoyer de requête UDP/DOMAIN vers la
machine S.
(Tester pour les requêtes sur le serveur de noms puis pour des requêtes sur le serveur ftp en
utilisant l'adresse IP)
5. Pour les deux traitements qui suivent, vous utiliserez deux écritures, dont l'opérateur " ! "
(not) qui permet d'obtenir des compléments.
6. Autorisez toutes les requêtes qui sortent vers l'extérieur, sauf celles qui vont sur un port ftp
7. N'autorisez aucune requête hormis celles qui sont à destination du port 80
I. Comprendre l’architecture d’un routeur Cisco et les modes
utilisateurs
1. Prérequis : Rappel sur les architectures des routeurs
Un routeur est un élément intermédiaire dans un réseau informatique assurant le routage des
paquets. Un routeur est chargé de recevoir sur une interface des données sous forme de paquets et
de les renvoyer sur une autre en utilisant le meilleur chemin possible. Selon l’adresse destination et
l’information contenue dans sa table de routage.
Tous Les routeurs Cisco ont une architecture interne qui peut être représenté par :

Ils contiennent tous :

• Une mémoire NVRam pour Ram non Volatile et sur laquelle l’administrateur va stocker
la configuration qu’il aura mise dans le routeur. Elle contient également la configuration
de l’IOS,

• Une carte mère qui est en général intégrée au châssis,

• Un CPU qui est un microprocesseur Motorola avec un BIOS spécial nommé » I.O.S.
«pours Internetwork Operating System,

• Une mémoire RAM principale contenant le logiciel IOS, c‟est dans laquelle tout sera
exécuté un peu à la manière d’un simple ordinateur,

• Une mémoire FLASH, également une mémoire non volatile sur laquelle on stocke la
version courante de l’IOS du routeur,

• Une mémoire ROM non volatile et qui, quant à elle, contient les instructions de
démarrage (bootstrap) et est utilisée pour des opérations de maintenance difficiles de
routages, ARP, etc.), mais aussi tous les buffers utilisés par les cartes d’entrée.
 a. Méthodes d’accès à Cisco IOS :
Il y a plusieurs moyens d’accéder à l’environnement ILC. Les méthodes les plus répandues
utilisent :
• Le port de console,
• Le protocole Telnet ou SSH,
• Le port AUX
Port de console
Il est possible d’accéder à l’environnement ILC par une session console, également appelée ligne CTY.
La console connecte directement un ordinateur ou un terminal au port de console du routeur ou du
commutateur via une liaison série lente. Le port de console est un port de gestion permettant un
accès hors réseau à un routeur. Le port de console est accessible même si aucun service réseau n’a
été configuré sur le périphérique. Le port de console est souvent utilisé pour accéder à un
périphérique avant que les services réseau ne soient lancés ou lorsqu’ils sont défaillants.
La console s’utilise en particulier dans les circonstances suivantes :
• Configuration initiale du périphérique réseau,
• Procédures de reprise après sinistre et dépannage lorsque l’accès distant est impossible,
• Procédures de récupération des mots de passe.
Lorsqu’un routeur est mis en service pour la première fois, ses paramètres réseau n’ont pas été
configurés. Le routeur ne peut donc pas communiquer via un réseau. Pour préparer le démarrage
initial et la configuration du routeur, un ordinateur exécutant un logiciel d’émulation de terminal est
connecté au port de console du périphérique. Ainsi, il est possible d’entrer au clavier de l’ordinateur
connecté les commandes de configuration du routeur. S’il est impossible d’accéder à distance à un
routeur pendant qu’il fonctionne, une connexion à son port de console peut permettre à un
ordinateur de déterminer l’état du périphérique. Par défaut, la console transmet les messages de
démarrage, de débogage et d’erreur du périphérique.
Pour de nombreux périphériques IOS, l’accès console ne requiert par défaut aucune forme de
sécurité. Il convient toutefois de configurer un mot de passe pour la console afin d’empêcher l’accès
non autorisé au périphérique. En cas de perte du mot de passe, un jeu de procédures spéciales permet
d’accéder aux périphériques sans mot de passe. Il est recommandé de placer le périphérique dans
une pièce ou une armoire fermée à clé pour interdire l’accès physique.
Telnet et SSH
Une autre méthode d’accès distant à une session ILC consiste à établir une connexion Telnet avec le
routeur. À la différence des connexions console, les sessions Telnet requièrent des services réseau
actifs sur le périphérique. Le périphérique réseau doit avoir au moins une interface active configurée
avec une adresse de couche 3, par exemple une adresse IPv4. Les périphériques Cisco IOS disposent
d’un processus serveur Telnet qui est lancé dès le démarrage du périphérique. IOS contient
également un client Telnet. Un hôte doté d’un client Telnet peut accéder aux sessions vty en cours
d’exécution sur le périphérique Cisco. Pour des raisons de sécurité, IOS exige l’emploi d’un mot de
passe dans la session Telnet en guise de méthode d’authentification minimale.
Le protocole Secure Shell (SSH) permet un accès distant plus sécurisé aux périphériques. À l’instar
de Telnet, ce protocole fournit la structure d’une ouverture de session à distance, mais il utilise des
services réseau plus sécurisés.
SSH fournit une authentification par mot de passe plus résistante que celle de Telnet et emploie un
chiffrement lors du transport des données de la session. La session SSH chiffre toutes les
communications entre le client et le périphérique IOS. Ceci préserve la confidentialité de l’ID
d’utilisateur, du mot de passe et des détails de la session de gestion. Il est conseillé de toujours utiliser
SSH à la place de Telnet dans la mesure du possible. La plupart des versions récentes de Cisco IOS
contiennent un serveur SSH. Dans certains périphériques, ce service est activé par défaut. D’autres
périphériques requièrent une activation du serveur SSH.
Les périphériques IOS incluent également un client SSH permettant d’établir des sessions SSH avec
d’autres périphériques. De même, vous pouvez utiliser un ordinateur distant doté d’un client SSH
pour démarrer une session ILC sécurisée. Le logiciel de client SSH n’est pas fourni par défaut sur
tous les systèmes d’exploitation. Il peut donc s’avérer nécessaire d’acquérir, d’installer et de
configurer un logiciel de client SSH pour votre ordinateur.
Port AUX
Une autre façon d’ouvrir une session ILC à distance consiste à établir une connexion téléphonique
commutée à travers un modem connecté au port AUX du routeur. À l’instar de la connexion console,
cette méthode ne requiert ni la configuration, ni la disponibilité de services réseau sur le
périphérique.
Le port AUX peut également s’utiliser localement, comme le port de console, avec une connexion
directe à un ordinateur exécutant un programme d’émulation de terminal. Le port de console est
requis pour la configuration du routeur, mais les routeurs ne possèdent pas tous un port AUX. En
outre, il est préférable d’utiliser le port de console plutôt que le port AUX pour le dépannage, car il
affiche par défaut les messages de démarrage, de débogage et d’erreur du routeur.
En général, le port AUX ne s’utilise localement à la place du port de console qu’en cas de problèmes
liés au port de console, par exemple lorsque vous ignorez certains paramètres de la console.
 b. Les différents modes d’utilisateur
Mode Utilisateur : Permet de consulter toutes les informations liées au routeur sans pouvoir les
modifier. Le Shell est le suivant :
Router >
Utilisateur privilégié : Permet de visualiser l’état du routeur et d’importer/exporter des images
d’IOS. Le Shell est le suivant :
Router #
Mode de configuration globale : Permet d’utiliser les commandes de configuration générale
du routeur. Le Shell est le suivant :
Router(config)#
Mode de configuration d’interfaces : Permet d’utiliser des commandes de configuration des
interfaces (Adresses IP, masque, etc.). Le Shell est le suivant :
Router(config-if)#
Mode de configuration de ligne : Permet de configurer une ligne (exemple : accès au routeur
par Telnet).
Le Shell est le suivant :
Router(config-line)#
2. Accès à distance
Reproduire l’architecture suivante en vous référant sur le TP en intégrant une machine Ubuntu
On compte mettre un mot de passe pour passer en mode de configuration du routeur quelque soit
les moyens utilisés.
a. Telnet et port console : activation sur un routeur
Démarche à suivre :
Pour le mode console :
R1(config)#line console 0
R1(config-line)# password passer
R1(config-line) #login
R1(config-line) #exit
Pour mode Telnet
R1(config)#line vty 0 4
R1(config-line) # password passer
R1(config-line) #login
R1(config-line) #exit
Pour le mode général
R1(config)# enable secret passera
NB : Ce mot de passe sera demandé lorsqu’on passe au mode utilisateur au mode enable
NB : Notre routeur à l’adresse [Link]
Test de connexion par telnet à partir de la machine Ubuntu

b. ssh : activation de connexion sur routeur

Démarche à suivre :
• On donne un nom de domaine au routeur par la commande :
R1(config)# ip domain-name [Link]
• on gérére la clé de chiffrement par la commande :
R1(config)# crypto key generate rsa genral-keys modulus 1024
• On active le ssh par la commande :
R1(config)# ip ssh version 2
• On configure l’authentification et on ajoute un compte utilisateurs
R1(config)# aaa new-model
R1(config)# aaa authentication login default local
R1(config)# username admin secret passer
NB : On peut filtrer les connexions ssh avec une liste de contrôle d’accès avec les commandes
suivantes :
R1(config)#access-list 10 permit [Link] [Link]
R1(config)#line vty 0 4
R1(config-line) #access-class 10 in
On ajoute sur le client SSH de Linux pour l’échange des paramètres de diffie-hellman dans le
fichier /etc/ssh/ssh_config

Test de connexion depuis la machine Ubuntu

3. Routage directe, Routage indirecte et Routage statique avec interface fastEthernet

 • Ajouter sur le slot0 des routeurs R1 et R2 l’interface C7200-IO-2FE
• Comment les routeurs R1 et R2 vont nommer les interfaces qu’on vient d’ajouter ?
• Adressage des réseaux

Réseau1 : [Link]/24
Réseau 2 : [Link]/24
reseauinter1: [Link]/30
reseauinter2 : [Link]/30
reseauinter3 : [Link]/30
• configurer les routeurs
R1 : fa0/0 :[Link]/30 ;
fa0/1 : [Link]/30
R2 : fa0/0 : [Link]/30
fa0/1 : [Link]/30
R4 : fa0/0 : [Link]/30
fa0/1 : [Link]/24
R3 : fa0/0 : [Link]/30
fa0/1 : [Link]/24
• Routage statique
Proposer sur chaque routeur les routes à ajouter de manière statique pour que les machines du 1 er
réseau puissent voir les machines du 2éme réseau et inversement.
• Configurer le routeur R3 du réseau [Link]/24 comme un serveur DHCP
o Configuration du routeur R3 pour qu’il donne les éléments TCP/IP aux différents
clients du réseau [Link]/24

o Configurer chacune des machines du réseau [Link]/24 comme client DHCP

comme le montre la capture ci-dessous :

• Configurer le Routeur R4 comme serveur DHCP pour le réseau [Link]/24 comme le

montre la figure suivante :
 o Configurer chacune des machines du réseau [Link]/24 comme client DHCP
comme le montre la capture ci-dessous :

o Tester la connectivité depuis PC1 vers PC3

• Configurer le Routeur R3 comme serveur DNS
o La capture suivante montre la configuration du serveur DNS sur le R3 :

Il faut aussi préciser l’adresse du serveurs DNS au serveur DHCP pour qu’il puisse la donner aux
clients demandeurs sur le routeur R3 avec les commandes:
R3(config)# ip dhcp pool ec2lt
R3(config)# dns-server [Link]
o Sur chacune des machines redemander les éléments TCP/IP et afficher ces derniers
comme le montre la figure ci-après
 •
o Configurer le Routeur R4 de sorte qu’il utilise le Routeur R3 comme serveur DNS
avec la commande suivante :
R4(config)# ip name-server [Link]

o Modifier la configurer du serveur DHCP du routeur R4 pour spécifier l’adresse IP du

serveur DNS qui sera donnée aux clients demandeurs dans le réseau [Link]/24
avec les commandes suivantes :
R4(config)# ip dhcp pool rtn
R4(config)# dns-server [Link]
o A partir de PC3 on demande les éléments TCP/IP

• Tester le bon fonctionnement du serveur DNS depuis PC3 du réseau [Link]/24

NB: Il est à noter qu’il est préférable d’avoir dans chaque réseau un serveur DHCP
pour allouer dynamiquement les éléments TCP/IP aux clients demandeurs, en ce qui
concerne un serveur DNS on peut configurer un dans un réseau ou utiliser un
serveur DNS externe.
4. Sauvegarde et restauration des routeurs et switchs

• Reproduire l’architecture ci-après en prenant Ubuntu sous docker

NB : Le NAT permet d’avoir un réseau privé d’avoir internet via la machine physique qui est utilisée
comme Modem ADSL

• Cliquer droit sur la machine Ubuntu puis configure pour la mettre en client DHCP
 • On se connecte sur la machine ubuntu et on met à jour sa source-list

#apt-get update
• on installe sur la machine ubuntu le serveur tftpd et le client tftp-hpa
# apt-get install tftpd-hpa tftp-hpa

• Configurer le serveur tftpd en précisant l’adresse du serveur tftpd dans le fichier

/etc/default/tftpd-hpa comme suit et le tester

On donne le dossier /var/lib/tftpboot ainsi son contenu à tftp

# chown -R tftp /var/lib/tftpboot

On crée un fichier pour tester le serveur

#touch essai
On se connecte sur le serveur
#tftp @IP_serveurtftp
>put essai
On devait avoir le fichier essai dans le répertoire /var/lib/tftpboot du serveur ; donc le serveur tftp
fonctionne.

• Paramétrer le routeur R1 et sauvegarder sa configuration sur le serveur TFTPD

• On simule une panne en arrêtant le routeur R1 et en ajoutant un nouveau routeur R2 comme

le montre la figure
 • Connecter un nouveau routeur R2 au Switch et utiliser la configuration de R1 stockée sur R2

NB : Avant de restaurer il faut que le routeur soit dans le réseau, on peut faire en sorte qu’il ait les
élément TCP/IP par DHCP avec les commandes :
R2(config)# int fa0/0
R2(config)# ip address dhcp

Vérification de la restauration
On tape la commande show running-config pour vérifier la restauration

On constate que les configurations ont été bien restauré sur le nouveau routeur depuis le serveur
tftpd
II. Les Listes d’Accès : ACL
1. Généralités
Ces Tp qui suivront vont vous permettre de manipuler les ACL des routeurs sous GNS3. Les ACL (en
anglais « Acces Control Lists ») ou en Français « Listes de Contrôle d’Accès », vous permettent
d’établir des règles de filtrage sur les routeurs, pour régler le trafic des datagrammes en transit.
Les ACL permettent de mettre en place un filtrage dit « statique » des datagrammes, c'est-à-dire
d’instaurer un certain nombre de règles à appliquer sur les champs concernés des en-têtes des divers
protocoles.
2. Fonctionnement des A
Quel que soit le type d’ACL dont il s’agit ; leur utilisation se fait toujours selon les mêmes principes
généraux :
Première étape : En mode « config », on crée une ACL, c'est-à-dire une liste de règles.

Chaque règle est du type (condition, action). Les règles sont interprétées séquentiellement.
Si la condition analysée ne correspond pas, on passe à la règle suivante. Si la condition correspond,
l’action correspondante est effectuée, et le parcours de l’ACL est interrompu. Par défaut, toutes les
ACL considèrent la règle (VRAI, REJET) si aucune des règles précédentes n’a été prise en compte,
c'est-à-dire que tout datagramme non explicitement accepté par une règle préalable sera
rejeté.
Deuxième étape : En mode « config-int », on applique une ACL en entrée (in) (respectivement en
sortie(out)), c'est-à-dire que l’on décide d’activer la liste de règles correspondante à tous les
datagrammes « entrant » dans le routeur (respectivement « sortant » du routeur) par l’interface
considérée. En conséquence, sur un routeur, il peut y avoir au maximum 2 ACLs (IP) par interface.
Lorsque l’on construit une ACL, les règles sont ajoutées à la fin de la liste dans l’ordre dans lequel on
les saisit. On ne peut pas insérer de règle dans une ACL, ni même en supprimer … le seul moyen reste
d’effacer complètement l’ACL et de recommencer ! En situation réelle, pour saisir une ACL assez
longue, il peut être judicieux de créer un fichier texte et de le faire prendre en compte par la suite
comme un fichier de capture de configuration de routeur …
Les ACL standards
Les ACL standards n’offrent pas énormément de possibilités, elles permettent simplement de créer
des règles dont les conditions ne prennent en compte que les adresses IP sources des
datagrammes IP analysés. C’est assez contraignant, mais cela permet déjà un certain nombre de
manipulations intéressantes.
La commande pour créer une ACL standard (ou ajouter une règle à une ACL existante) est la suivante :
# access-list <#ACL> {permit/deny} <@IP source> <masque>
Le numéro de liste (#ACL) doit être compris entre 1 et 99 pour une ACL standard (tapez un ? après
la commande « access-list » pour visualiser toutes les fourchettes possibles en fonctions des types
d’ACL).
« Permit ou deny » indique l’action à prendre (deux seules actions sont possibles : autorisé ou refusé)
L’IP source + masque indique la condition.
Les ACL étendues
La syntaxe un peu plus complète des ACL étendues, permet, selon le même principe que
précédemment, de créer des règles de filtrage plus précises, en utilisant des conditions applicables
sur d’autres champs des en-têtes des divers protocoles.
La commande pour créer une ACL (ou ajouter une règle à une ACL existante) est la suivante :
# access-list <#ACL> {permit/deny} <protocole> <@IPsource> <masque> [port]
<@IPdest> <masque> [port] [established]
Le numéro de liste (#ACL) doit être compris entre 100 et 199 pour une ACL étendue.
« Permit ou deny » indique l’action à prendre (deux seules actions sont possibles : autorisé ou
refusé)
« Protocole » indique le protocole concerné par le filtre (tapez un ? pour avoir la liste des protocoles
disponibles) Les protocoles indiqués peuvent être de différents niveaux jusqu’au niveau transport
(ex : TCP ou UDP, mais également IP ou ICMP). La distinction sur les protocoles applicatifs (http,
FTP …) se fera sur le champ « port ».
IP et masques suivent les mêmes règles que pour les ACL standards,
« Port » permet d’indiquer un numéro de port (ou son nom symbolique s’il est connu http, FTP,
Telnet, …). Notez qu’un port doit être indiqué précéder d’un opérateur (ex : « eq http » ou « eq 80 »
ou « lt 1024 ») avec « eq » (pour « equal »), « lt » (pour « lower than ») ou « gt » (pour greater
than), …
« established » indique qu’il s’agit d’une communication TCP déjà établie (et donc pas d’une
demande de connexion avec le bit « syn » positionné).Remarques essentielles sur la syntaxe des
ACL
Le masque est complètement inversé par rapport à la notion de masque que vous connaissez
jusqu’ici !!! (On parle de masque générique) ex : [Link] avec le masque [Link] désigne toute
adresse source du type 193.55.221.X … merci Cisco !
• Abréviations dans une règle :
[Link] [Link] qui signifie « tout équipement » peut être remplacé par le mot clé
« any ».
• W.X.Y.Z [Link] qui signifie « l’équipement W.X.Y.Z » peut être remplacé par « host
W.X.Y.Z »
• Par défaut, la règle « deny any » est prise en compte par toutes les ACL. En d’autre termes, le
simple fait de créer une ACL vide et de l’appliquer à une interface interdit le passage a tout
datagramme. Pour changer de politique par défaut d’une ACL, il suffit de mettre la règle « permit
any » (ou « permit ip any any » pour les ACL étendues) en fin de liste. Cette règle sera prise en
compte si aucune des précédentes ne l’est.
• En mode « enabled » la commande « show access-list <#ACL> » vous permet de visualiser (et
donc de capturer le cas échéant …) le contenu de l’ACL dont vous donnez le numéro.

Exercice compléter le masque générique

Compléter le tableau ci-dessous :

3. Activation d’une ACL
Pour activer une ACL sur une interface, il faut :
Se positionner dans le mode de configuration de l’interface, grâce à la commande « interface <nom
de l’interface> »
Saisir la commande : « ip access-group <#ACL> < in | out> ».
N’oubliez pas de vous considérer « à l’intérieur du routeur », pour choisir entre le mot clé « in » et le
mot clé « out » …
4. Désactivation d’une ACL
Pour désactiver une ACL, les manipulations sont les mêmes que pour l’activer, en utilisant le mot clé
« no » devant la commande …
5. Utilisation des ACL standards et étendues dans la « vraie vie »
Dans la pratique, étant donné que les ACL standards ne peuvent prendre en compte que les adresse
IP sources, il est logique qu’elles soient souvent utilisées pour filtrer les datagrammes proches de là
sur un passage « obligé » pour joindre le destinataire final.
En revanche, les ACL étendues prenant aussi en comptent les adresses destination, peuvent être
utilisées au contraire sur les routeurs les plus proches des équipements sources concernés, ceci afin
d’éviter du trafic superflu sur le réseau.

6. MANIPULATIONS
Mise en place préliminaire
• Câblez correctement les éléments de votre réseau en respectant l’architecture proposée
Activer le protocole de routage RIP version 2.
• Configurez les PC en conséquence (@IP, masque, passerelle, et DNS : [Link] sur
chaque machine), sous Windows pour le PC relié au port console (PC de gauche), sous
Linux pour l’autre (PC de droite).
• Vérifier les accès à toutes les machines du réseau.
ACL Standards
Pour tout le TP il est demandé de conserver la politique « all open » par défaut, c'est-à-dire de
conserver la politique du « tout autoriser » et de n’interdire que le strict nécessaire. C’est loin
d’être la plus sûre, mais c’est celle qui permettra aux autres binômes de travailler,
• Depuis un terminal sur chacune des machines interne (PC sous Windows et sous Linux)
effectuez un PING sur « sv1ec2lt», Que constatez vous ?
• Cette machine est en mesure de répondre au moins aux services , http (port 80), ftp (port
21, entre autres), dns (port 53) et icmp bien sûr. Tester
• Créez une ACL standard permettant d’interdire tout accès du réseau «ec2lt» à vos PC
mais pas internet. Activez cette ACL sur les datagrammes « sortant » sur l’interface du
LAN. Vérifiez que le filtre fonctionne et que vous avez toujours accès à Internet.
Remarque : attention aux échanges DNS.
• Quelle règle auriez vous écrit maintenant pour interdire l’accès au réseau ec2lt à tous les
PCs de votre LAN SAUF le PC Linux (il n’y a pas de différence pour vous étant donné que
vous n’avez que 2 pc sur votre LAN, mais il en aurait eu une si vous en aviez eu 3 !). Créez
une autre ACL pour tester cette règle.
ACL Etendues
• Créez une ACL étendue pour interdire au PC Windows de faire des « pings » sur le réseau
de mrim.
• Faites en sorte d’interdire tout trafic UDP à destination de sv1mrim depuis votre PC Linux.
Trouvez une manipulation pour valider ce filtre. Trouvez une manipulation pour vérifier
que le trafic est toujours autorisé sur une autre machine que sv1mrim (PC16 par exemple).
• Interdisez le trafic web à tout votre réseau local.
• Allégez les restrictions en permettant uniquement à votre PC Windows d’accéder
uniquement au site web de sv1mrim.
• Mettez en place un filtre autorisant votre PC Linux à faire un telnet sur sv1mrim, mais pas
à sv1mrim de faire un telnet sur votre PC Linux.
• Consignes utiliser gns3 et planifier, configurer et verifier des ACL standart, étendues et
nommées.
Objectifs
• Configurer une liste d’accès VTY pour assurer la sécurité de l’accès à distance
• Créer des listes de contrôle d’accès standard, étendues et nommées pour améliorer la
sécurité du réseau
Contexte / Préparation
L’atelier d’entretien du réseau nécessite un accès à un routeur installé récemment à Londres. V
• ous devez configurer une liste de contrôle d’accès pour lui autoriser un accès Telnet au
routeur et refuser l’accès à tous les autres. Une liste d’accès supplémentaire doit être créée
sur les routeurs London et DC afin de remplir les conditions requises ci-après.
 • Autoriser l’accès de tous les clients London au serveur London et bloquer tous les autres
utilisateurs.
• Autoriser l’accès de tous les clients au serveur DC et bloquer tous les autres utilisateurs.
Mot de passe actif : admin.
Étape 1 : création de liste d’accès pour limiter l’accès au VTY
a- Sélection du routeur London.
b- b- Configurez les lignes vty 0 à 4 pour la connexion. Le mot de passe doit être cisco123.
• Créez une liste d’accès standard permettant un accès Telnet à tous les clients du sous-
réseau demaintenance.
o Numéro de la liste d’accès : 10.
o Sous-réseau de maintenance : [Link] [Link].
• Appliquez la liste d’accès aux lignes vty 0 à 4.
• Entrez dans le mode de configuration.
• Entrez line vty 0 4
• Entrez access-class 10 in e- Enregistrez les configurations.

Étape 2 : création de liste d’accès étendue sur le routeur DC

Planification et création de listes d’accès numérotées sur le routeur DC suivant les conditions
requises ci-après.

• Créer une liste d’accès sortante numérotée 150 et l’appliquer à l’interface Fast Ethernet
0/1.1 b-
• Créer une liste d’accès sortant numérotée 160 et l’appliquer à l’interface Fast Ethernet
0/1.2
Étape 3 : création d’une liste d’accès nommée sur le routeur London
Planification et création d’une liste d’accès nommée sur le routeur London suivant les conditions
requises ci-après.
 • Nommez la liste d’accès ICMP.

• Appliquez la liste d’accès à l’interface série comme une liste d’accès entrant.
• Enregistrez les configurations.
Étape 4 : vérification des listes d’accès configurées
Vérification des restrictions applicables aux vty placés sur le routeur London.
• Sélectionnez le PC Maint et le Telnet du routeur London.
• Sélectionnez le PC2 et le Telnet du routeur London. Le Telnet du PC Maint devrait aboutir
contrairement à celui du PC2.
Vérifiez la liste d’accès étendue du routeur DC.
• Sélectionnez le PC2 et recherchez le serveur DC ([Link]).
• Envoyez une requête ping au serveur DC ([Link]).
• Sélectionnez le PC1 et recherchez le serveur London ([Link]).
• Envoyez une requête ping au serveur London ([Link]).
La navigation aboutit contrairement à la commande ping.

Vérifiez la liste d’accès nommée du routeur London.

• Sélectionnez le PC2 et envoyez une requête ping au PC1.
• Naviguez du PC2 au Server0 ([Link]).
La commande ping aboutit contrairement à la navigation qui dépasse son délai d’attente.
• Cliquez sur le bouton Check Results Remarques générales :
• Que signifie le terme « out » en fin de ligne d’un énoncé d’une commande ip access-group ?
• Quelle est la différence entre les commandes d’ajout d’une liste de contrôle d’accès sur une
interface spécifique et le VTY
• Quelle est la différence entre les commandes d’ajout d’une liste de contrôle d’accès sur une
interface spécifique et le VTY ?
III. NAT et PAT
1. Introduction
L'espace d'adressage IPv4 est trop restreint pour accommoder tous les périphériques à connecter à
Internet.
Les adresses privées des réseaux sont conçues pour être utilisées dans une organisation ou un site
uniquement.
Elles ne sont pas routées sur internet, contrairement aux adresses publiques.
Elles peuvent pallier la pénurie d'adresses IPv4, mais comme elles ne sont pas routées par les
périphériques Internet, elles doivent d'abord être traduites.
C'est le rôle de la fonction NAT.
2. FONCTINNEMENT DE LA NAT
Il existe trois techniques :
• NAT STATIQUE
La fonction NAT statique utilise un mappage « un à un » entre les adresses privées et publiques.
Ces mappages sont configurés par l'administrateur réseau et ne changent pas.
La fonction NAT statique est particulièrement utile lorsque les serveurs hébergés dans le réseau
interne doivent être accessibles depuis le réseau externe.
• NAT DYNAMIQUE
La NAT dynamique utilise un pool d'adresses publiques et les attribue selon la méthode du premier
arrivé, premier servi.
Lorsqu'un périphérique interne demande l'accès à un réseau externe, la NAT dynamique attribue
une adresse IPv4 publique disponible du pool.
Il doit y avoir suffisamment d'adresses publiques disponibles pour le nombre total de sessions
utilisateur simultanées.
• LA TRANDUCTION D’ADRESSE DE PORT ( PAT )
La fonction PAT mappe les adresses IPv4 privées à des adresses IP publiques uniques ou à quelques
adresses.
Elle utilise la paire port source/adresse IP source pour garder une trace du trafic de chaque client
interne.
3. CONFIGURATION DE LA TRADUCTION D’ADRESSES RÉSEAU (NAT)
NAT STATIQUE
Reproduire l’architecture et passer à la configuration des contrôles de listes d’accès

Étapes de configuration
Configurations des interfaces du routeur :
# interface FastEthernet0/0
# ip address [Link] [Link]
# no sh ip nat inside interface FastEthernet0/1
# ip address [Link] [Link]
# no sh ip nat outside
Création du mappage entre adresse privée et publique
# ip nat inside source static [Link] [Link]
# ip nat inside source static [Link] [Link]
Vérification de la traduction satatic
# show ip nat translation
Une capture wireshark

NAT DYNAMIQUE
Cette partie consiste à reprendre la même architecture et de paramétrer le NAT dynamique

Étapes de configuration :

Étape 1 : définition du pool d’adresse publique

# ip nat pool pl1 [Link] [Link] netmask [Link]

Étape 2 : définition d’une liste d’accès standard autorisant les adresses qui doivent être traduites.
# access-list 1 permit [Link] [Link]

Étape 3 : lier le pool d’adresse à la liste d’accès

Procédures de configuration
Nous aller prendre le cas d’une seule adresse publique
#interface FastEthernet0/0
#ip address [Link] [Link]
#ip nat inside
#interface FastEthernet0/1
#ip address [Link] [Link] ip nat outside
#ip nat inside source list 1
#interface FastEthernet0/1 overload
#access-list 1 permit [Link] [Link]

CONCLUSION
Ce TP nous a permis non seulement de mettre en pratique nos connaissances acquises sur la NAT à
travers le logiciel de simulation GNS3.
Mais aussi d’observer les mécanismes de traduction d’adresses privées en adresses publique grâce
au logiciel wireshark.
 I. Initiation au routage RIP
Introduction
Nous savons que les routeurs sont de véritables postes d'aiguillage qui acheminent de proche en
proche les paquets IP dans l'inter-réseau. On peut configurer manuellement des routes statiques sur
chaque routeur. Mais dans un réseau important, cette tâche devient rapidement cauchemardesque !
Heureusement, des protocoles de routage ont été développés afin que les routeurs s'échangent les
informations dont ils disposent. On parle dans ce cas de routage dynamique. L'objet de cette partie
est de présenter le fonctionnement et la mise en oeuvre d'un protocole de routage des plus
élémentaires : RIP (Routing Information Protocol).
Avant d'aborder la partie pratique avec GNS3, nous évoquerons les avantages du routage dynamique
en comparaison du routage statique. Nous détaillerons ensuite le fonctionnement du protocole RIP.
Pourquoi le routage dynamique ?
Le routage statique consiste à indiquer l'adresse IP des réseaux que l'on cherche à atteindre. On
associe à chaque adresse, le nom de l'interface du routeur ou l'adresse IP du routeur voisin se situant
sur la route vers ces réseaux de destination. Si le réseau global est complexe, la configuration peut
être fastidieuse et source d'erreurs. De plus, lorsque un nouveau réseau est ajouté, il faut reconfigurer
l'ensemble. Enfin, pour prévenir tout dysfonctionnement (panne d'un routeur, ligne coupée, etc.), il
faut effectuer une surveillance permanente et reconfigurer chaque routeur le cas échéant. Si la route
est rétablie, il faut recommencer la manipulation.
L'idée générale du routage dynamique est la suivante : plutôt que de centraliser la configuration du
routage dans les mains d'un individu dont le temps de réaction est fatalement long et les risques
d'erreurs importants, nous allons délocaliser cette tâche au niveau des routeurs. En effet, chaque
appareil n'est-il pas le mieux placé pour connaître les adresses des réseaux auxquels il est
directement relié puisque chacune de ses interfaces possède une adresse IP ? De plus, étant
directement au contact des supports de communication, il peut établir un diagnostic sur l'état des
liaisons. Fort de ces informations, il n'a plus qu'à les partager avec ses voisins. De proche en proche,
les nouvelles se répandront à chaque routeur du réseau. L'intervention humaine se situera en amont
dans la définition de directives et de règles à appliquer par les routeurs pour la diffusion des routes.

II. Le protocole RIP

Comme toujours, pour qu'une communication puisse s'établir, chaque interlocuteur doit parler la
même langue. Il a donc été nécessaire de concevoir un protocole. RIP a été défini, pour sa version 1
dans la RFC 1058 et pour sa version 2 dans la RFC 2453. Par la suite, je ne traiterai que RIPv2.
Toutefois, avant de passer à la partie pratique, nous évoquerons rapidement les différences entre ces
deux versions.
Quelles informations de routage s'échanger ?
Le principe général est très simple. Un routeur RIP transmet à ses voisins les adresses réseau qu'il
connaît (soit les adresses de ses interfaces, soit les adresses découvertes via les autres routeurs) ainsi
que la distance pour les atteindre. Ces couples adresse/distance sont appelés vecteurs de distance.
La notion de distance
Nous touchons ici au concept de métrique, fondamental dans le domaine du routage. En effet, il
arrive fréquemment (c'est même une situation recherchée pour des raisons de tolérance aux pannes)
que le réseau ait une topologie maillée. Dans ce cas, plusieurs routes mènent à la même destination.
Le routeur doit alors choisir la route qu'il considère la meilleure vers une destination donnée.
La seule métrique utilisée par RIP est la distance correspondant au nombre de routeurs à traverser
(hop ou nombre de sauts) avant d'atteindre un réseau. Pour chaque route, RIP calcule la distance.
Ensuite, si des routes redondantes apparaissent, RIP retient celle qui traverse le moins de routeur
(donc avec la distance la plus faible).
Du fait de la méthode utilisée pour diffuser les routes, la longueur d'une route (et par voie de
conséquence le diamètre du réseau) est limitée. La norme limite la distance maximale d'une route à
quinze. Cela signifie que deux réseaux ne peuvent être éloignés de plus de quinze routeurs. Nous
verrons ci-après qu'une distance égale à seize (distance "infinie" pour RIP) joue un rôle particulier
en indiquant qu'une route est devenue inaccessible.
Un exemple
Prenons l'exemple simple du réseau suivant :

Figure2.1 : Topologie du réseau

Afin de bien comprendre le routage dynamique, supposons la situation initiale suivante : sur chaque
routeur, toutes les interfaces réseau sont actives, aucune route statique n'est définie et le routage RIP
est inactif.
Sur R1, lorsque l'on active le processus de routage RIP, une première table est constituée à partir des
adresses IP des interfaces du routeur. Pour ces réseaux directement connectés au routeur, la distance
est égale à un puisqu'il faut au moins traverser ce routeur pour les atteindre. On obtient :
 Moyen de
Adresse/Préfixe Distance
l'atteindre

[Link]/8 f1/1 1

[Link]/24 f1/0 1
Tableau 1 : table initiale constituée par R1

R1 transmet à ses voisins immédiats (ici, il n'y a que R2) un seul vecteur de distance {[Link]/24,
1} qui signifie : "je suis le routeur d'adresse IP [Link] et je connaîs un moyen d'atteindre le réseau
[Link]/24 en un saut". Aucune information sur le réseau commun aux deux routeurs
([Link]/8) n'est transmise car R1 considère que R2 connaît déjà ce réseau.
Ensuite, lorsque l'on active RIP sur R2, il constitue la table ci-après à partir de ses propres
informations et de celles reçues de R1 :
Moyen de
Adresse/Préfixe Distance
l'atteindre

[Link]/8 f1/1 1

[Link]/8 f1/1 1

[Link]/24 [Link] 2

[Link]/24 f1/0 1
Tableau 2 : table constituée par R2
Sur R2, RIP a calculé que la distance pour atteindre [Link]/24 est égale à deux puisqu'il faut
traverser R2 puis R1. R2 a déduit le "moyen de l'atteindre" à partir de l'adresse IP de l'émetteur
contenue dans le paquet RIP.
Lorsque RIP sera démarré sur R3, la route vers [Link]/24 avec une distance de deux sera
ajoutée dans la table ci-dessus.
Dans ce petit exemple, aucune restriction n'a été définie sur la diffusion des routes. Donc, à l'issue
d'un certain délai appelé temps de convergence, variable selon la taille du réseau, chaque routeur
connaît un moyen d'atteindre chaque réseau.

III. Algorithme général de RIP

Examinons un peu plus en détail le fonctionnement de RIP. Lors de l'initialisation du routeur, celui-
ci détermine l'adresse réseau de ses interfaces puis envoie sur chacune une demande d'informations
(table RIP complète) aux routeurs voisins. Lors de la réception d'une demande, un routeur envoie sa
table complète ou partielle suivant la nature de cette demande. Lors de la réception d'une réponse,
il met à jour sa table si besoin. Deux cas peuvent se présenter :
pour une nouvelle route, il incrémente la distance, vérifie que celle-ci est strictement inférieure à 15
et diffuse immédiatement le vecteur de distance correspondant ;
Pour une route existante mais avec une distance plus faible, la table est mise à jour. La nouvelle
distance et, éventuellement, l'adresse du routeur si elle diffère sont intégrées à la table.
Bien sûr, si l'appareil reçoit une route dont la distance est supérieure à celle déjà connue, RIP l'ignore.
Ensuite, à intervalles réguliers (les cycles durent 30 secondes environ), la table RIP est diffusée qu'il
y ait ou non des modifications.
Des routes doivent être retirées de la table gérée par RIP dans deux situations.
En premier lieu, un réseau immédiatement connecté devient inaccessible (panne de l'interface, de la
ligne, modification de la topologie par l'administrateur, etc.). Les routeurs RIP reliés à ce réseau
affectent dans leur table une distance "infinie" (16 comme indiqué plus haut) à cette route. Elle est
conservée pendant la durée d'un temporisateur de "maintien" (ou garbage collect) de 120 secondes
puis est supprimée. Immédiatement puis pendant toute la durée de ce délai, le vecteur est diffusé.
Un routeur qui reçoit un vecteur avec une distance de 16 comprend : "il faut que tu retires cette route
de ta table car elle est devenue invalide !". De proche en proche, cette information se propage.
En second lieu, un routeur du réseau tombe en panne. Cela veut peut-être dire que les réseaux situés
derrière cet appareil sont devenus inaccessibles. Mais comment savoir si un routeur est en panne ?
RIP considère qu'un routeur qui n'a pas donné de nouvelles depuis trois minutes est hors-service.
Pour gérer cette situation, il attribue à toutes les routes dynamiques un temporisateur initialisé à 180
secondes (par défaut). A chaque réception d'un vecteur de distance déjà présent dans la table, le
compteur est réinitialisé. Mais si jamais ce compteur atteint zéro, la route est considérée comme
invalide. On se retrouve alors dans la situation précédente (distance infinie, temporisateur de
maintien, diffusion de l'information puis suppression de la route). Maintenant, si un autre routeur
connaît une route menant vers un des réseaux que l'on vient de retirer, c'est parfait ! Notre routeur
intègrera cette nouvelle route dans sa table : RIP permet la tolérance aux pannes.
Comment justifier l'existence de ces mécanismes qui peuvent paraître un peu complexes ? Cela est
dû à une faiblesse des algorithmes à vecteurs de distance que l'on appelle "problème de la
convergence lente". Dans certains cas, après la panne d'un accès réseau, deux routeurs voisins
risquent de se transmettre mutuellement puis, ensuite, de propager des informations contradictoires
au sujet de ce réseau et créer ainsi une boucle de routage infinie. Zebra met en oeuvre les mécanismes
nommés "split horizon" (une information de routage reçue d'une interface n'est jamais retransmise
sur celle-ci), "poison reverse" (temporisateur de maintien) et "triggered update" (une panne est
immédiatement diffusée sans attendre le prochain cycle de diffusion des tables) afin d'empêcher ce
phénomène et de réduire le délai de convergence.
Diffusion des tables) afin d'empêcher ce phénomène et de réduire le délai de convergence.
Améliorations de RIPv2 par rapport à RIPv1
Même si les principes évoqués ci-dessus sont valables quelle que soit la version de RIP, les différences
restent intéressantes à relever. Les améliorations de RIPv2 sont :
Diffusion des masques de sous-réseaux associés aux adresses réseaux (RIPv1 n'utilisait que les
masques réseau par défaut) ;
 Utilisation d'adresses multicast pour diffuser les vecteurs de distance au lieu d'adresses de broadcast,
ce qui réduit l'encombrement sur le réseau ;
Support de l'authentification en transportant un mot de passe crypté avec MD5 ;
Interopérabilité entre protocoles de routage en diffusant des routes apprises à partir d'autres
protocoles.
L'ensemble de ces raisons rendent RIPv1 obsolète bien qu'il soit supporté par la plupart des routeurs
logiciels ou matériels.
Place à la pratique
Afin de mieux apprécier les facilités offertes par le routage dynamique, je vous propose de travailler
sur une topologie légèrement modifiée afin d'introduire un lien redondant. Voici le plan :
Figure 2.2 : Topologie de travail

INSERER un doc impliquant comment faire du routage RIP sur CISCO

IV. La distance administrative
Les distances administratives standards sont les suivantes :

Moyen de découvrir une route Distance administrative

Connected 0

Static 1

BGP 20

OSPF 110

RIP 120
Tableau 3 : distances administratives par défaut
V. Un problème de sécurité
Le routage dynamique est pratique car avec très peu de commandes de configuration on arrive à une
solution qui fonctionne correctement et qui est même capable de prendre en compte
automatiquement des modifications de la topologie. Seulement voilà : imaginez qu'un petit malin
insère sur le réseau un routeur RIP et qu'il lui fasse diffuser des routes totalement farfelues. Cela
peut créer un certain nombre de désagréments comme des dénis de service par exemple. Pour limiter
ce risque, RIPv2 permet d'associer un mot de passe crypté à chaque diffusion de vecteurs de distance.
Seuls les routeurs ayant connaissance de ce mot de passe traiteront les informations de routage.
Mettons en place ce mécanisme entre R1 et R2 :
Conclusion
RIP constitue un excellent moyen pédagogique pour aborder la problématique du routage
dynamique. Mais il est peu utilisé en exploitation car il souffre de certaines limitations et défauts qui
le cantonnent à des réseaux de taille moyenne. Nous avons vu que le diamètre maximum d'un réseau
géré avec RIP est limité à 15 routeurs soit 16 segments de réseau. RIP est un gros consommateur de
bande passante du fait de la méthode utilisée pour diffuser les informations de routage (toutes les
30 secondes, l'intégralité de la table RIP est diffusée même si elle n'a subi aucune modification). C'est
fâcheux, en particulier sur des liaisons lentes ou facturées au volume de données transférées. La
métrique utilisée ne garantit pas que le routage soit optimal. En effet, la distance masque les
caractéristiques réelles de la voie de transmission (débit ou coût en particulier). Enfin, le temps de
convergence, délai avant que tous les routeurs ne possèdent des tables cohérentes peut être long dans
certaines situations. Pour toutes ces raisons, on a cherché à développer un protocole de routage
beaucoup plus efficace : OSPF, objet du prochain paragraphe.
VI. Rappels sur les éléments vus
Le routeur est un élément essentiel dans l'aiguillage des paquets de données dans un inter-réseau.
Pour chaque paquet reçu, il extrait le préfixe réseau de l'adresse IP de destination du paquet et le
recherche dans une table qu'il possède en mémoire. Cette table de routage contient essentiellement
une liste d'adresses réseau et, pour chacune, le moyen de l'atteindre, à savoir l'adresse d'un routeur
immédiatement voisin et situé sur la route vers la destination. Si le routeur trouve dans cette table le
préfixe réseau, il transmet le paquet sur le réseau du routeur voisin concerné. Ce processus sera
renouvelé par le routeur voisin et ainsi de suite, de proche en proche le paquet sera orienté vers sa
destination.
Seulement voilà, il faut saisir les tables de routage ! Travail fastidieux pour les petits doigts agiles de
l'administrateur lorsque les réseaux sont de grande taille. De plus, compte tenu de l'évolution du
nombre de réseaux à interconnecter dans le cas d'internet, il est de toute façon devenu impossible de
se cantonner au routage statique (voir séquence sur le routage statique). C'est pourquoi, le routage
dynamique a été imaginé afin d'alléger la charge d'administration mais aussi pour réaliser des
réseaux tolérants aux pannes d'un routeur ou d'une liaison. RIP est un bon exemple de protocole de
routage dynamique*. Les routeurs supportant RIP s'échangent des informations sur les routes qu'ils
 possèdent (les fameux "vecteurs de distance"). Si une panne se produit, les routeurs immédiatement
voisins notent que certaines routes sont devenues inaccessibles et propagent l'information aux autres.
Mais hélas, RIP souffre de certaines limitations qui ont poussé l'IETF (Internet Engineering Task
Force) à plancher sur un protocole plus robuste, plus efficace, plus paramétrable et supportant des
réseaux de grande taille. Cette merveille s'appelle OSPF (Open Shortest Path First),.
VII. Les grands principes
OSPFest un protocole de routage dynamique défini par l'IETF à la fin des années 80. Il a fait l'objet
d'un historique relativement complexe de RFC. Ce protocole a deux caractéristiques essentielles : -
il est ouvert (le Open de OSPF), son fonctionnement peut être connu de tous ; - il utilise l'algorithme
SPF (Shortest Path First), plus connu sous le nom d'algorithme de Dijkstra, afin d'élire la meilleure
route vers une destination donnée.
Examinons une topologie qui nous servira de support pour les explications :
Exemple de topologie

La notion de coût
Supposons que du routeur R1 on cherche à atteindre le réseau [Link]. Dans une telle situation,
RIP aurait élu la route passant par R5 puisque c'est la plus courte en termes de saut. Cependant,
imaginez que les liens représentés sous forme d'éclairs soient "rapides" (type Ethernet à 100 Mbps
par exemple) et que les liens "droits" soient "lents" (type Ethernet à 10 Mbps par exemple). Le choix
de RIP n'est plus du tout pertinent !
OSPF fonctionne différemment. Il attribue un coût à chaque liaison (dénommée lien dans le jargon
OSPF) afin de privilégier l'élection de certaines routes. Plus le coût est faible, plus le lien est
intéressant. Par défaut, les coûts suivants sont utilisés en fonction de la bande passante du lien :
 Type de réseau Coût par défaut

Ethernet > = 100 Mbps 1

FDDI 1

Ethernet 10 Mbps 10

E1 (2,048 Mbps) 48

T1 (1,544 Mbps) 65

64 Kbps 1562

56 Kbps 1785

19.2 Kbps 5208

La formule de calcul est simplissime : coût = référence / bande passante du lien. Par défaut, la
référence est 100 000 000 correspondant à un réseau à 100 Mbps.
OSPF privilégie les routes qui ont un coût faible, donc celles qui sont supposées rapides en terme de
débit théorique.

La base de données topologique

Avec OSPF, tous les routeurs d'un même réseau (on parle de "zone" dans le vocabulaire OSPF, ceci
vous sera expliqué avant la mise en pratique) travaillent sur une base de données topologique
identique qui décrit le réseau. Cette base a été constituée pendant une première phase de découverte
qui vous sera expliquée un peu plus loin. Examinons la base de données suivante qui décrit la
topologie de la figure 1 :

Arc Coût

R1, R2 1

R1, R5 10

R2, R3 1

R3, R4 10

R3, R5 1

R4, R5 10

R4,[Link] 10

L'élection des meilleures routes

L'algorithme du SPF de Dijsktra va traiter cette base de données afin de déterminer les routes les
moins coûteuses. Une fois le traitement réalisé, chaque routeur se voit comme la racine d'un arbre
contenant les meilleures routes.
L'algorithme du SPF de Dijsktra va traiter cette base de données afin de déterminer les routes les
moins coûteuses. Une fois le traitement réalisé, chaque routeur se voit comme la racine d'un arbre
contenant les meilleures routes. Par exemple :
Figure 68.2. Le réseau vu de R1 Figure 68.3. Le réseau vu de R5

Dans l'exemple, entre R1 et [Link], la meilleure route passe par R2, R3 et R4 pour un coût total
de 1 + 1 + 10 + 10 soit 22.
La détermination d'une table de routage
La base de données topologique décrit le réseau mais ne sert pas directement au routage. La table de
routage est déterminée par l'application de l'algorithme du SPF sur la base topologique. Sur R1, voici
un extrait de la table de routage calculée par SPF au sujet du réseau [Link] :

Réseau de Moyen de
Coût
destination l'atteindre

[Link] R2 22

Sur R5, on aura l'extrait suivant :

Sur R5, on aura l'extrait suivant :

Réseau de Moyen de
Coût
destination l'atteindre

[Link] R4 20

Le fonctionnement d'OSPF un peu plus en détail

Pour administrer un réseau OSPF correctement, il est indispensable de comprendre le
fonctionnement interne du protocole.
À l'intérieur d'une même zone, les routeurs fonctionnant sous OSPF doivent préalablement remplir
les tâches suivantes avant de pouvoir effectuer leur travail de routage :
 • établir la liste des routeurs voisins ;
• élire le routeur désigné (et le routeur désigné de secours) ;
• découvrir les routes ;
• élire les routes à utiliser ;
• maintenir la base de donnée topologique.

État initial
Le processus de routage OSPF est inactif sur tous les routeurs de la figure 1.
Etablir la liste des routeurs voisins : Hello, my name is R1 and I'm an OSPF router.
Les routeurs OSPF sont bien élevés. Dès qu'ils sont activés, ils n'ont qu'une hâte : se présenter et
faire connaissance avec leurs voisins. En effet, lorsque le processus de routage est lancé sur R1
(commande router ospf), des paquets de données (appelés paquets HELLO) sont envoyés sur chaque
interface où le routage dynamique a été activé (commande network). L'adresse multicast [Link]
est utilisée, tout routeur OSPF se considère comme destinataire. Ces paquets ont pour but de
s'annoncer auprès de ses voisins. Deux routeurs sont dits voisins s'ils ont au moins un lien en
commun. Par exemple, sur la figure 1, R1 et R2 sont voisins mais pas R1 et [Link] le processus
de routage OSPF est lancé sur R2, celui-ci récupère les paquets HELLO émis par R1 toutes les 10
secondes (valeur par défaut du temporisateur appelé hello interval). R2 intègre l'adresse IP de R1
dans une base de données appelée "base d'adjacences" (adjacencies database). Cette base contient
les adresses des routeurs voisins. Vous pourrez visionner son contenu grâce à la commande show ip
ospf neighbor. R2 répond à R1 par un paquet IP unicast. R1 intègre l'adresse IP de R2 dans sa propre
base d'adjacences. Ensuite, généralisez ce processus à l'ensemble des routeurs de la zone.
Cette phase de découverte des voisins est fondamentale puisque OSPF est un protocole à état de liens.
Il lui faut connaître ses voisins pour déterminer s'ils sont toujours joignables et donc déterminer
l'état du lien qui les relie.
Elire le routeur désigné : c'est moi le chef !
Dans une zone OSPF, l'un des routeurs doit être élu "routeur désigné" (DR pour Designated Router)
et un autre "routeur désigné de secours" (BDR pour Backup Designated Router). Le DR est un
routeur particulier qui sert de référent au sujet de la base de données topologique représentant le
réseau.
Pourquoi élire un routeur désigné ? Cela répond à trois objectifs :
Réduire le trafic lié à l'échange d'informations sur l'état des liens (car il n'y a pas d'échange entre
tous les routeurs mais entre chaque routeur et le DR) ;
Améliorer l'intégrité de la base de données topologique (car il y a une base de données unique) ;
Accélérer la convergence (souvenez-vous, c'était le talon d'Achille de RIP).
Comment élire le DR ? Autrement dit, qui va se taper la corvée d'expliquer à ses petits camarades la
topologie du réseau ? On ne demande pas qui sait parler anglais ou couper les cheveux comme au
temps de la conscription Mais comme il faut bien un critère, le routeur élu est celui qui a la plus
grande priorité. La priorité est un nombre sur 8 bits fixé par défaut à 1 sur tous les routeurs. Pour
départager les routeurs ayant la même priorité, c'est celui avec la plus grande adresse IP qui est élu.
Le BDR sera le routeur avec la deuxième plus grande priorité. Afin de s'assurer que votre routeur
préféré sera élu DR, il suffit de lui affecter une priorité supérieure à 1 avec la commande ospf priority.
Vous devrez faire ceci avant d'activer le processus de routage sur les routeurs car, une fois élu, le DR
n'est jamais remis en cause même si un routeur avec une priorité plus grande apparaît dans la zone.
Découvrir les routes
Il faut maintenant constituer la base de données topologique. Les routeurs communiquent
automatiquement les routes pour les réseaux qui participent au routage dynamique (ceux déclarés
avec la commande network). Zebra étant multiprotocole, il peut également diffuser des routes
provenant d'autres sources que OSPF, grâce à la commande redistribute.
Chaque routeur (non DR ou BDR) établit une relation maître/esclave avec le DR. Le DR initie
l'échange en transmettant au routeur un résumé de sa base de données topologique via des paquets
de données appelés LSA (Link State Advertisement). Ces paquets comprennent essentiellement
l'adresse du routeur, le coût du lien et un numéro de séquence. Ce numéro est un moyen pour
déterminer l'ancienneté des informations reçues. Si les LSA reçus sont plus récents que ceux dans sa
base topologique, le routeur demande une information plus complète par un paquet LSR (Link State
Request). Le DR répond par des paquets LSU (Link State Update) contenant l'intégralité de
l'information demandée. Ensuite, le routeur (non DR ou BDR) transmet les routes meilleures ou
inconnues du DR.
L'administrateur peut consulter la base de données topologique grâce à la commande show ip ospf
database.
Elire les routes à utiliser
Lorsque le routeur est en possession de la base de données topologique, il est en mesure de créer la
table de routage. L'algorithme du SPF est appliqué sur la base topologique. Il en ressort une table de
routage contenant les routes les moins coûteuses.
Il faut noter que sur une base de données topologique importante, le calcul consomme pas mal de
ressources CPU car l'algorithme est relativement complexe.
Maintenir la base topologique
Lorsqu'un routeur détecte un changement de l'état d'un lien (cette détection se fait grâce aux paquets
HELLO adressés périodiquement par le routeur à ses voisins), celui-ci émet un paquet LSU sur
l'adresse multicast [Link] : le DR et le BDR de la zone se considèrent comme destinataires. Le DR
(et le BDR) intègre cette information à sa base topologique et diffuse l'information sur l'adresse
[Link] (tous les routeurs OSPF sans distinction). C'est le protocole d'inondation. Toute
modification de la topologie déclenche une nouvelle exécution de l'algorithme du SPF et une nouvelle
table de routage est constituée.
Voilà pour les principes fondamentaux d'OSPF mais des notions importantes restent à évoquer si
vous souhaitez déployer OSPF sur de grands réseaux (en particulier sur le fonctionnement d'OSPF
sur un réseau point à point et sur l'agrégation de routes). Si vous voulez approfondir, reportez-vous
au livre de C. Huitema cité en bibliographie qui, bien qu'un peu ancien est très complet sur la
question. Bien sûr, vous pouvez toujours vous plonger dans les différentes RFC qui constituent OSPF
(la RFC 2328 en particulier) et dont la lecture est toujours aussi agréable et passionnante ! (je
plaisante, bien sûr).
Avant d'attaquer la pratique, un dernier concept : les zones OSPF.
Le concept de zone (area)
Contrairement à RIP, OSPF a été pensé pour supporter de très grands réseaux. Mais, qui dit grand
réseau, dit nombreuses routes. Donc, afin d'éviter que la bande passante ne soit engloutie dans la
diffusion des routes, OSPF introduit le concept de zone (area). Le réseau est divisé en plusieurs zones
de routage qui contiennent des routeurs et des hôtes. Chaque zone, identifiée par un numéro,
possède sa propre topologie et ne connaît pas la topologie des autres zones. Chaque routeur d'une
zone donnée ne connaît que les routeurs de sa propre zone ainsi que la façon d'atteindre une zone
particulière, la zone numéro 0. Toutes les zones doivent être connectées physiquement à la zone 0
(appelée backbone ou réseau fédérateur). Elle est constituée de plusieurs routeurs interconnectés.
Le backbone est chargé de diffuser les informations de routage qu'il reçoit d'une zone aux autres
zones. Tout routage basé sur OSPF doit posséder une zone 0. doit posséder une zone 0.
Figure 2.4 : Un réseau découpé en trois zones

Le réseau est découpé en trois zones dont le backbone. Les routeurs de la zone 1, par exemple, ne
connaissent pas les routeurs de la zone 2 et encore moins la topologie de la zone 2. L'intérêt de définir
des zones est de limiter le trafic de routage, de réduire la fréquence des calculs du plus court chemin
par l'algorithme SPF ainsi que d'avoir une table de routage plus petite (ce qui accélère la
convergence). Les routeurs R1 et R4 sont particuliers puisqu'ils sont "à cheval" entre plusieurs zones
(on les appelle ABR pour Area Border Router ou routeur de bordure de zone). Ces routeurs
maintiennent une base de données topologique pour chaque zone à laquelle il sont connectés. Les
ABR sont des points de sortie pour les zones ce qui signifie que les informations de routage destinées
aux autres zones doivent passer par l'ABR local à la zone. L'ABR se charge alors de retransmettre les
informations de routage au backbone. Les ABRs du backbone ensuite redistribueront ces
informations aux autres zones auxquelles ils sont connectés.
Place à la pratique
Nous allons travailler avec le réseau suivant :

Figure 2.5 : Topologie de travail

Le réseau a été découpé en trois zones. Vous remarquez que la zone 0 permet de fédérer l'ensemble
du réseau. Il s'agit du backbone dont nous avons déjà discuté. Le découpage de ce réseau en trois
zones est un cas d'école dont le but est d'examiner la configuration d'OSPF dans un contexte multi-
zone. Généralement, on considère qu'une zone peut accueillir plusieurs dizaines de routeurs.
Pour ne pas surcharger ces lignes inutilement, nous nous en tiendrons ici à la configuration de R1,
R2 et R3. Vous verrez que la configuration n'est pas très complexe.
Activation du processus de routage
Dans le mode "config", nous allons activer le processus OSPF :
R1(OSPF)(config)# routerospf
R1(OSPF)(config-router)#

2. Activation des annonces de routes

Le processus de routage OSPF est activé mais rien ne se passe. Comme pour RIP, il faut indiquer sur
quel(s) réseau(x) on souhaite que le routage dynamique soit opérationnel. Ceci se fait par la
commande network. Mais, nouveauté par rapport à RIP qui n'intègre pas le concept de zone, il faut
indiquer à quelle zone sera rattaché le réseau. Sur la figure 5, on voit que R1 est relié à deux réseaux.
Le réseau [Link]/8 est attaché à la zone 0 et le réseau [Link]/8 à la zone 1. La configuration se
fait donc de cette manière :
R1(OSPF)(config-router)# network [Link]/8 area 0
R1(OSPF)(config-router)# network [Link]/8 area 1
Que se passe-t-il sur le réseau ? R1 envoie des paquets HELLO sur les interfaces pour lesquelles la
commande network a été saisie. Mais personne n'est là pour les écouter. Activez le routage sur R2 en
adaptant les commandes aux spécificités du routeur. Je vous aide un peu. Sur R2, vous réaliserez les
configurations suivantes :
R2(OSPF)(config-router)# network [Link]/8 area 1
R2(OSPF)(config-router)# network [Link]/8 area 1
Enfin, sur R3, vous réaliserez les configurations suivantes :
R3(OSPF)(config-router)# network [Link]/8 area 1
R3(OSPF)(config-router)# network [Link]/24 area 1
Mais sur R3, il y a une particularité. Le réseau [Link]/24 contient des ordinateurs mais aucun
routeur. La commande network va diffuser sur ce réseau des annonces de routes ce qui consomme
inutilement de la bande passante. Par conséquent, nous allons désactiver cette diffusion :
R3(OSPF)(config-router)# passive-interface eth1
Ainsi, aucune route n'est diffusée sur cette interface. De même, aucune annonce de route ne sera
prise en compte. Le réseau sera considéré comme étant d'extrémité (stub).
Affichage de la configuration
Affichons la configuration complète de R1 :
Etat des routeurs
Nos petits routeurs ont, en principe, bien travaillé. Dans chaque zone, ils ont élu leur chef (le DR),
ils ont échangé leurs connaissances et calculé une magnifique table de routage, ultra-optimale. En
résumé, les deux stations d'extrémité de la figure doivent pouvoir s'atteindre avec une commande
ping. Si jamais ce n'est pas le cas, c'est que probablement vous vous êtes trompé dans une
configuration. Dans ce cas, reprenez la configuration de chaque appareil. Utilisez les outils ping,
tcpdump et traceroutE pour contrôler votre configuration et suivre les paquets. Et n'oubliez pas que
dans un ping, il y a un aller mais aussi un retour !
Afin d'illustrer ce dont nous avons discuté dans la toute première partie de cet article, examinons
l'état du routeur R1. Nous pouvons faire un diagnostic très complet de l'appareil en utilisant les
nombreuses sous-commandes de show ip ospf. Vous constaterez que les informations fournies par
ospfd sur son état sont beaucoup plus conséquentes que celles que l'on pouvait extirper de ripd.
Dans un premier temps, je vous propose d'examiner l'état de santé général du routeur R3 :
Le premier bloc décrit le fonctionnement général du routeur : l'ID du routeur (égale à sa plus grande
adresse IP), conformité aux RFC, valeurs des temporisateurs. Une seule zone est attachée à ce
routeur. C'est la zone 1 (exprimée en notation décimale pointée). Notre routeur a deux interfaces
dans la zone, il n'a qu'un seul voisin. L'algorithme du SPF a été exécuté 13 fois. La base de données
topologique contient neuf états de liens (LSA). Si notre routeur était attaché à plusieurs zones, le
deuxième bloc serait répété autant de fois que de zones. Vous pourrez le constater sur R1.
Maintenant, listons nos informations sur les routeurs voisins :
Maintenant, listons nos informations sur les routeurs voisins :
R3(OSPF)# show ip ospf neighbor
 Neighbor
Prix State Dead Time Address Interface RXmtL RqstL DBsmL
ID

[Link] 1 Full/Backup 00:00:34 [Link] eth0 0 0 0

Déchiffrons ces informations. La différence entre la colonne ID et la colonne Address, c'est que l'ID
identifie l'appareil dans le réseau alors que l'adresse correspond à l'interface à laquelle nous sommes
relié avec ce routeur. La colonne State nous apprend deux choses : il est synchronisé avec le routeur
désigné grâce à la mention "Full", c' est le "routeur désigné de secours" de la zone grâce à l'indicateur
Backup. Ce routeur sera déclaré comme inactif si nous ne recevons pas de message HELLO d'ici 34
secondes (Dead Time).
Voyons le contenu de la base de données topologique de R3 :
Ces trois tableaux présentent de façon synthétique l'ensemble des LSA stockés dans la base
topologique. Le premier tableau contient des LSA diffusés par chaque routeur. Ils décrivent l'état des
interfaces de chaque routeur. Le deuxième tableau contient des LSA diffusés par le routeur désigné.
Ils décrivent la liste des routeurs présents dans chaque réseaux. Le dernier tableau contient un
résumé des routes diffusées par le routeur de bordure de zone (ABR). Ce sont des routes qu'il a reçu
via le backbone par les routeurs des autres zones. L'âge et le numéro de séquence sont utilisés pour
mettre à jour la base lorsque des LSA sont reçus. Le check sum est utilisé pour contrôler l'intégrité
des LSA.
Pour obtenir des informations détaillées sur chaque LSA, vous pouvez compléter la commande show
ip ospf database par router, network ou summary. Par exemple : show ip ospf database router
[Link] (qui correspond à la troisième ligne du premier tableau) vous apprendra que ce router
est relié à deux réseaux : un de transit ([Link]/8) et un d'extrémité (stub) [Link]/24.
Quelques éléments sur la sécurité
Filtrer la diffusion des routes
Le premier inconvénient d'un protocole de routage dynamique comme OSPF est sa volubilité. Il a
tendance à dévoiler tout un tas d'informations sur les réseaux qu'un administrateur consciencieux
n'a pas forcément envie de révéler. Pour limiter la diffusion des routes au strict minimum, ospfd
intègre, à l'instar de ripd, un mécanisme d'access-lists. Reportez-vous à l'article publié sur Zebra
dans Linux Magazine 43. La configuration est strictement identique. J'en profite pour faire un peu
de publicité : si vous êtes intéressés par les problèmes de sécurité, je vous conseille l'excellent
magazine M.I.S.C. La série d'articles sur la "protection de l'infrastructure réseau IP" constitue sur
certains points un approfondissement intéressant.
Protéger les annonces de routes
Le deuxième inconvénient d'un protocole de routage dynamique comme OSF est sa naïveté. Il croit
tout ce qu'on lui dit ! Un petit malin pourrait s'amuser à diffuser des routes farfelues à vos routeurs,
ce qui pourrait provoquer des dénis de service. Pour pallier à cela, on peut activer l'authentification
des annonces sur une zone. Voici les manipulations à réaliser sur chaque routeur :
Routeur(OSPF)(config-router)# area 1 authentication message-digest
Ensuite, pour chaque interface participant à la diffusion des routes :
Routeur(OSPF)(config)# int ethx
Routeur(OSPF)(config-if)# ospf message-digest-key 1 md5 motdepasse
Vous adapterez motdepasse à vos besoins. Ce mot de passe doit bien sûr être connu de tous les
routeurs.

Conclusion
OSPF est un protocole de routage dynamique moderne, robuste et conçu pour les grands réseaux.
On constate qu'il est nettement plus complexe que RIP. Pas forcément dans sa configuration mais
dans son fonctionnement interne. Un inconvénient de ce protocole est qu'il peut être gourmand en
puissance de calcul et en mémoire lorsque le réseau comporte beaucoup de routes ou qu'il y a de
fréquentes modifications de topologie.
OSPF est un protocole IGP (Interior Gateway Protocol), c'est-à-dire qu'il agit au sein d'un système
autonome. Un AS (Autonomous System) est un ensemble de réseaux gérés par un administrateur
commun. Chaque système autonome possède un numéro identifiant sur 16 bits délivré par l'IANA
(Internet Assigned Numbers Authority) ou ses délégations. Classiquement, les multinationales, les
opérateurs de télécom ou les fournisseurs d'accès à Internet détiennent un système autonome. Pour
assurer le routage entre les systèmes autonomes, un protocole de type EGP (Exterior Gateway
Protocol) doit être mis en oeuvre. Dans le cas d'Internet, c'est généralement BGP (Border Gateway
Protocol) qui assume cette mission. BGP, protocole supporté par Zebra, constitue un vaste terrain
d'investigation.
 I. Initiation au routage BGP : Introduction
Internet relie des réseaux appartenant à des acteurs (entreprises, administrations, opérateurs de
télécommunication, fournisseurs d'accès...) très différents. Il est peu probable qu'un consensus se
dégage naturellement autour d'un même algorithme de routage dynamique et d'une même métrique.
Ajoutons que des accords sont passés entre ces acteurs afin d'acheminer le trafic dans l'Internet et
que celui-ci franchit des frontières, ce qui impose de respecter les réglementations locales. Le
protocole BGP (Border Gateway Protocol) a été conçu pour répondre à ces problèmes. Comme
toujours, nous allons aborder brièvement son fonctionnement avant de passer à une mise en pratique
II. Les grands principes
BGP achemine les informations de routage entre les réseaux reliés à Internet.
Le concept de système autonome
Au sein d'une même organisation, les décisions concernant la topologie ou la politique de routage
sont, en général, prises par une autorité unique. Par conséquent, le routage à l'intérieur de
l'organisation est basé sur la confiance et un protocole de type IGP comme OSPF est mis en oeuvre.
Un réseau fonctionnant sous une autorité unique est appelé un système autonome (AS). En pratique,
un AS regroupe un ou plusieurs réseaux et un ou plusieurs routeurs ainsi que le montre l'exemple de
la figure 1 :
Figure 4.1: Un système autonome constitué de réseau

Les AS sont identifiés par un numéro sur 16 bits unique attribué par les mêmes organismes qui
affectent les adresses IP. Il existe une plage de numéros d'AS privés de 64 512 à 65 535 pour ceux qui
ne possèdent pas de numéro d'AS public.
A l'intérieur de votre AS, vous pouvez bien faire ce que vous voulez. Vous préférez tel protocole de
routage ? Vous estimez que telle métrique est plus pertinente ? Tant mieux, cela ne regarde que vous.
La seule contrainte, c'est que vous devrez désigner un ou plusieurs routeurs, à la frontière de votre
AS, pour propager les informations d'accessibilité de vos réseaux et collecter les informations
d'accessibilité des autres ASBR.
Par exemple, si l'on reprend la topologie présentée dans la séquence sur OSPF, que l'on en fait un AS,
on obtiendrait :

Figure 4.2: Un AS découpé en zones OSPF

Ce système autonome utilise OSPF en tant qu'IGP. Il est découpé en trois zones. R4 est le routeur de
bordure de zone. Celui-ci doit fonctionner sous BGP.
Les politiques de routage
Internet est un maillage de réseaux. Cela signifie que plusieurs chemins existent entre deux réseaux
d'extrémité (figure 3). Mais ceux-ci ne sont pas tous équivalents.
Figure4.3 : Réseaux d'AS

En effet, imaginez vos datagrammes circulant dans cette jungle cruelle et barbare qu'est Internet.
Vous préfèrerez peut-être qu'ils transitent par tel AS, car l'administrateur est un pote ou que vous
avez négocié un tarif avantageux. Vous refuserez peut-être qu'ils transitent par tel AS car vos flux
sont incompatibles avec la législation en vigueur dans le pays ou pour toute autre considération
politique, économique ou de sécurité que l'on peut imaginer. Dans ce cas, vous aurez besoin de
définir une politique de routage sur Internet. BGP vous rendra ce service.
Dans le réseau, l'administrateur de l'AS 600 définit une politique de routage. Il veut joindre l'AS 200
en passant par les AS 300 et 100.
Les informations de routage échangées par BGP
Une des particularités de BGP-IV (RFC 1771) est qu'il s'appuie sur la couche TCP (port 179), ce qui
permet de s'affranchir de la nécessité de supporter les fonctions de fragmentation, de retransmission,
d'acquittement et de séquencement.
Deux routeurs BGP s'échangent des messages pour ouvrir et maintenir la connexion. Le premier flot
de données est la table entière de routage. Ensuite, des mises à jours incrémentielles sont envoyées
lorsque la table de routage change : BGP ne nécessite pas de mises à jour périodiques des tables de
routage. Par contre, un routeur BGP doit retenir la totalité des tables de routage courantes de tous
ses pairs durant le temps de la connexion. Des messages « keepalive » sont envoyés périodiquement
pour maintenir la connexion.
BGP est un protocole de type " Path Vector ". Les routeurs s'échangent des informations du type :
Adresse IP
Adresse IP du
du réseau Liste des AS traversés
prochain routeur
de pour atteindre le réseau
(Next hop)
destination

On constate qu'avec BGP, la granularité du routage est l'AS. Par défaut, lorsque plusieurs routes
existent entre deux AS, BGP choisit la route qui traverse le moins d'AS.
Quand utiliser BGP ?
Ce protocole est généralement utilisé par les fournisseurs d'accès à Internet, les administrateurs des
points d'échange (IXP) et les administrateurs de systèmes autonomes qui souhaitent mettre en
œuvre leur propre politique de routage.
III. Place à la pratique
Voyons sur quelle topologie nous allons travailler :
figure .4. Topologie
Nous avons trois systèmes autonomes numérotés 10, 20 et 30. Dans un souci de simplification,
chaque système autonome a une topologie relativement simple. De ce fait, aucun IGP n'est utilisé.
On constate que chaque routeur est un ASBR. L'AS 20 a une particularité car pour les AS 10 et 30,
c'est un AS de transit. Nous reviendrons sur ce point dans la mise en oeuvre.
Tâches de configuration
Sur chaque routeur, il faudra réaliser les tâches suivantes :
0. Activer le protocole
activer le processus de routage BGP en indiquant dans quel AS de situe le routeur (commande router
bgp <numero_AS>) ;
spécifier les routes à annoncer via BGP (commande network <préfixe_IP_du_réseau>/<masque>) ;
établir une relation avec les routeurs voisins (commande neighbor <IP_du_voisin> remote-as
<AS_du_voisin>).
Situation de départ
IV. Cohabitation entre BGP et les IGP
Activation du processus de routage
Dans le mode « config », nous allons activer le processus BGP en n'oubliant pas d'indiquer le numéro
d'AS. Par exemple, sur R1 :
R1(BGP)(config)# router bgp 10
R1(BGP)(config-router) #
Spécification des routes à annoncer
Pour R1, le seul réseau que l'on souhaite annoncer via BGP aux autres routeurs est [Link]/24 car
il contient des ordinateurs :
R1(BGP)(config-router) # network [Link]/24
Cette commande est à renouveler autant de fois qu'il y a de réseaux à annoncer. Dans notre exemple,
nous avons choisi volontairement de ne pas annoncer le réseau [Link]/8 car celui-ci ne contient
que des routeurs. Vous noterez au passage que cette commande n'a pas la même vocation que dans
RIP ou OSPF.
Etablissement d'une connexion avec les voisins
Il faut distinguer deux cas : mon voisin est-il dans un autre AS ou dans le même AS que moi ?
1. Cas où le voisin est dans un autre AS :
Je rappelle que "un voisin" est un routeur avec lequel on est immédiatement connecté. Il faut
indiquer son adresse IP ainsi que son numéro d'AS. Dans le jargon BGP, une connexion entre deux
routeurs BGP s'appelle peering. Sur R1, on saisit la commande :
R1(BGP)(config-router)# neighbor [Link] remote-as 20
Cette commande est à renouveler autant de fois qu'il y a de routeurs BGP immédiatement connectés
(et avec qui on souhaite échanger des informations de routage bien sûr).
2. Cas où le voisin est dans le même AS :
L'AS 20 est particulier car il véhicule des données qui ne lui sont pas destinées, en particulier les
informations de routage en provenance et à destination des AS 10 et 30. En effet, pour que l'AS 30
connaisse l'existence du réseau [Link]/24, R2 doit récupérer cette information auprès de R1 puis
la transmettre à R3 qui lui-même la transmettra à R4. R2 et R3 étant dans le même AS, un "sous-
protocole" de BGP appelé iBGP est mis en oeuvre automatiquement par le routeur. Mais, celui-ci a
la particularité de ne pas modifier les next hop lorsqu'il relaie des informations de routage. Ainsi,
sans intervention, R4 apprendrait que le next hop pour joindre [Link]/24 est [Link]. Or, celui-
ci n'est pas joignable depuis l'AS 30 (puisque nous ne faisons pas de network [Link]/8). Pour
pallier à cette lacune, il existe la directive next-hop-self. Ainsi sur R2 et sur R3 nous réaliserons les
configurations suivantes :
R2(BGP)(config-router)# neighbor [Link] remote-as 20
R2(BGP)(config-router)# neighbor [Link] next-hop-self
R3(BGP)(config-router)# neighbor [Link] remote-as 20
R3(BGP)(config-router)# neighbor [Link] next-hop-self
Affichage de la configuration
Affichons la configuration complète de R1 :
R1(BGP)(config-router)# end
R1(BGP)# show running-config
Current configuration:

Affichons la configuration complète de R2 :

R2(BGP)# show running-config
Current configuration:
!
hostname R2(BGP)
password foo
!
router bgp 20
network [Link]/24
neighbor [Link] remote-as 10
neighbor [Link] remote-as 20
neighbor [Link] next-hop-self
!
line vty
!
end
R1(OSPF)# copy running-config startup-config
Par symétrie, vous devez être en mesure de configurer les autres routeurs du réseau.
Affichage de l'état des routeurs
Le débogage
La table de routage
Observons, par exemple, la table BGP calculée par R2 :
R2(BGP)# show ip bgp

La première colonne indique si la route est valide (*), si BGP considère que c'est la meilleure (>) et
si elle provient d'un routeur interne (i pour internal) à l'AS. Les paramètres Metric, LocPrf (Local
Preference) et Weight sont utilisés par BGP pour lire la meilleure route vers une destination. BGP
applique l'algorithme (simplifié) suivant :
BGP choisit la route avec le plus grand poids (weight). Par défaut, une route directement connectée
se voit attribuer le poids 32768 ;
Si une route n'est toujours pas choisie, BGP choisit celle avec la plus grande "préférence locale". Par
défaut, une route issue d'un routeur interne à l'AS se voit attribuer une préférence locale de 100 ;
Si une route n'est toujours pas choisie, BGP choisit une route de type "internal" ;
Si une route n'est toujours pas choisie, BGP retiens la route avec le chemin (As-Path) le plus court ;
Si une route n'est toujours pas choisie, BGP choisit la route avec la métrique la plus faible.
La colonne Path indique la liste des systèmes autonomes à traverser avant d'atteindre le réseau. Le i
indique ici que les routes sont de type IGP. En fait, BGP regroupe sous ce terme les routes statiques
et découvertes par un protocole dynamique tel RIP ou OSPF.
Vous pouvez obtenir des informations détaillées sur une route particulière en tapant :
R2(BGP)# show ip bgp [Link]
Informations sur les voisins
Donne de nombreuses sur la
show ip bgp neighbors
connexion avec les voisins

Synthétise les informations ci-

show ip bgp summary
dessus dans un tableau

show ip bgp <IP_voisin> Routes découvertes à partir de ce

routes voisin

show ip bgp <IP_voisin>

Routes annoncées à ce voisin
advertised-routes