[inetdoc.LINUX]

R1(RIP)# show ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds with +/-50%, next due in 35
Timeout after 180 seconds, garbage collect after 120 seconds
Outgoing update filter list for all interface is not set
Incoming update filter list for all interface is not set
Default redistribution metric is 1
Redistributing: connected
Default version control: send version 2, receive version 2
 Interface       Send         Recv        Key-chain
 eth1            2            2

Routing for Networks:
100.0.0.0/8
Routing Information Sources: 
 Gateway   BadPackets BadRoutes Distance Last Update
 100.0.0.2 0          0         120      00:00:34
Distance: (default is 120) 

La dernière ligne du listing précédent évoque une «distance» dont la valeur par défaut est 120. Il s'agit de la distance administrative. Elle n'a aucun rapport avec la distance (métrique) en nombre de sauts calculée par RIP.

Zebra et Quagga peuvent constituer une table de routage à partir de routes apprises de différentes manières (réseau directement connecté, route statique, RIP, OSPF, BGP). Si Zebra ou Quagga se trouvent avec plusieurs routes menant vers un même réseau mais rapportée par des moyens différents, il doit en choisir une. Il a été décidé d'attribuer à chaque moyen d'apprendre une route un score. La route découverte par un moyen dont le score est le plus faible sera élue. Les distances administratives standards sont les suivantes :

Ainsi, une route configurée de façon statique (donc par un administrateur) est jugée plus crédible qu'une même route rapportée par RIP (notez au passage que RIP est considéré comme le moins crédible...). On retrouve cette notion de distance administrative dans la table de routage de Zebra. Sur R1, connectez-vous avec telnet au terminal de configuration de Zebra (dans le shell, faites un telnet localhost 2601, puis saisissez le mot de passe) :

R1(Zebra)> show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       B - BGP, > - selected route, * - FIB route

C>* 100.0.0.0/8 is directly connected, eth1
R>* 101.0.0.0/8 [120/2] via 100.0.0.2, eth1, 00:08:11
C>* 102.0.0.0/8 is directly connected, eth2
C>* 127.0.0.0/8 is directly connected, lo
C>* 192.168.1.0/24 is directly connected, eth0
R>* 192.168.2.0/24 [120/2] via 100.0.0.2, eth1, 00:08:11
R1(Zebra)>

Les deux routes dynamiques notées R comportent deux nombres entre crochets ([120/2]). Le premier correspond à la distance administrative et le deuxième à la distance en nombre de sauts.

Je vous invite maintenant à activer RIP sur vos trois routeurs en redistribuant les adresses des réseaux immédiatement connectés sur tous les réseaux. Vous connaissez les manipulations à effectuer. A la fin du processus, chaque routeur doit connaître les adresses des six réseaux ainsi que le moyen de les atteindre. Pour information, je vous donne le contenu du fichier de configuration de R3 (fichier /etc/quagga/ripd.conf) :

hostname R3(RIP)
password foo
!
interface lo
!
interface eth0
!
interface eth1
!
interface eth2
!
router rip
redistribute connected
network 101.0.0.0/8
network 102.0.0.0/8
!
line vty
!
end

Vous pouvez également, si vous le souhaitez, modifier la valeur par défaut des temporisateurs utilisés par RIP afin de visionner plus rapidement le résultat des manipulations que nous allons réaliser par la suite. Ceci se fait de la façon suivante, par exemple dans R1 :

R1(RIP)# conf t
R1(RIP)(config)# router rip
R1(RIP)(config-router)# timers basic 10 30 20

Notez bien qu'en exploitation, je vous conseille vivement de conserver ces compteurs à leur valeur par défaut. Avec les durées que nous avons indiqué ici, une partie importante de votre bande passante va être consommée par les diffusions de RIP.

Supposons que la liaison entre R1 et R2 va tomber en panne. Visionnons la table RIP de R1 avant ce triste événement :

R1(RIP)> show ip rip
Codes: R - RIP, C - connected, O - OSPF, B - BGP
  Network            Next Hop         Metric From            Time
C 100.0.0.0/8                         1
R 101.0.0.0/8        100.0.0.2        2      100.0.0.2       02:52
C 102.0.0.0/8                         1
C 192.168.1.0/24                      1
R 192.168.2.0/24     100.0.0.2        2      100.0.0.2       02:52
R 192.168.3.0/24     102.0.0.2        2      102.0.0.2       02:36

Le réseau 100.0.0.0/8 tombe en panne. R1 ne reçoit donc plus d'informations de routage à partir de R2. Si vous observez la table RIP sur R1, vous verrez que toutes les routes issues de R2 finissent par disparaître. Mais pendant ce temps, R3 continue à envoyer des mises à jour via le réseau 102.0.0.0/8. R3 connaît un moyen d'atteindre les réseaux que l'on pouvait joindre auparavant par R2. Aussi, au bout d'un certain délai de convergence, R1 construit la table suivante :

R1(RIP)> show ip rip
Codes: R - RIP, C - connected, O - OSPF, B - BGP
  Network            Next Hop         Metric From            Time
R 100.0.0.0/8        102.0.0.2        3      102.0.0.2       02:34
R 101.0.0.0/8        102.0.0.2        2      102.0.0.2       02:34
C 102.0.0.0/8                         1
C 192.168.1.0/24                      1
R 192.168.2.0/24     102.0.0.2        3      102.0.0.2       02:34
R 192.168.3.0/24     102.0.0.2        2      102.0.0.2       02:34

Tous les réseaux sont à nouveau accessibles à partir de R1 ! Cela démontre que RIP a su digérer une panne de liaison. Rétablissons le lien entre R1 et R2. Progressivement, on retourne vers la première table car les métriques via R2 sont plus faibles.

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 :

R1(RIP)# conf t
R1(RIP)(config)# key chain test
R1(RIP)(config-keychain)# key 1
R1(RIP)(config-keychain-key)# key-string motdepasse
R1(RIP)(config-keychain-key)# exit
R1(RIP)(config-keychain)# exit
R1(RIP)(config)# int eth1
R1(RIP)(config-if)# ip rip authentication mode md5
R1(RIP)(config-if)# ip rip authentication key-chain test
R1(RIP)(config-if)#

Nous créons le porte-clé (keychain) nommé test avec le mot de passe motdepasse. Ce mot de passe est associé à l'interface eth1, il sera transmis au format MD5 (sinon, il est transmis en clair !). Pour que cela fonctionne, vous devrez faire des manipulations identiques sur R2.

Examinons avec une capture de paquets le contenu des informations de routage reçues de R2 :

R1 # tcpdump -i eth1 -nt -s0 src host 100.0.0.2
tcpdump: listening on eth1
100.0.0.2.router > 224.0.0.9.router: RIPv2-resp [items 6]:
[auth 3: 0068 0114 3cfb 0c6f 0000 0000 0000 0000]
{101.0.0.0/255.0.0.0}(1)
{102.0.0.0/255.0.0.0}(2)
{192.168.2.0/255.255.255.0}(1)
{192.168.3.0/255.255.255.0}(2)
[auth 1: 4d71 f8e0 077c cc58 8247 6656 17c3 95f2]
(DF) [ttl 1]

Notez au passage que seul le mot de passe est crypté, les informations de routage continuent à circuler en clair.