[inetdoc.LINUX]

Afin d'observer la diffusion des routes qu'opère RIP, je vous propose de saisir la commande suivante dans le shell d'un routeur immédiatement voisin de R1, R2 par exemple :

R2 # tcpdump -i eth1 -nt -s 0 src host 100.0.0.1
tcpdump: listening on eth1

Ensuite, connectons-nous au routeur RIP sur R1 avec un telnet sur le port 2602. Dans le shell de R1 :

R1 # telnet localhost 2602

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

Hello, this is zebra (version 0.91a).
Copyright 1996-2001 Kunihiro Ishiguro.


User Access Verification

Password:

R1(RIP) >

Cette opération étant réalisée, comme pour zebra il faut activer le mode privilégié, passer dans le terminal de configuration et enfin, entrer dans la configuration du routeur RIP :

R1(RIP)> enable
R1(RIP)# conf t
R1(RIP)(config)# router rip
R1(RIP)(config-router)# version 2

La première tâche consiste à déterminer les types de routes en notre «possession» que nous souhaitons voir diffuser à nos voisins. Cette configuration se fait par la commande redistribute. Voici les différents paramètres de cette commande :

R1(RIP)(config-router)# redistribute ?

    bgp Border Gateway Protocol (BGP)
    connected Connected
    kernel Kernel routes
    ospf Open Shortest Path First (OSPF)
    static Static routes

On constate que l'on peut diffuser des routes propres à la machine comme les routes statiques et les adresses des réseaux directement connectés. Mais nous pouvons également utiliser RIP pour diffuser des routes dynamiques apprises via RIP ou d'autres protocoles de routage comme OSPF ou BGP. Dans tous les cas, les routes diffusées aux voisins seront vues par eux comme des routes étiquetées «découvertes grâce à RIP».

Nous choisissons de diffuser les adresses des réseaux directement connectés :

R1(RIP)(config-router)# redistribute connected

Pour l'instant, rien ne se produit. Il faut indiquer à RIP sur quels réseaux nous souhaitons voir la diffusion des routes s'opérer. Nous retrouvons ici une commande commune avec le routage statique. Avant de la valider, pensez à observer le résultat du tcpdump sur l'écran de R2 :

R1(RIP)(config-router)# network 100.0.0.0/8

À ce stade, R1 diffuse sur le réseau 100.0.0.0/8 la table RIP toutes les 30 secondes. Le résultat sur R2 doit ressembler à ceci :

R2 # tcpdump -i eth1 -nt -s 0 src host 100.0.0.1
tcpdump: listening on eth1

100.0.0.1.router > 224.0.0.9.router: RIPv2-req 24 (DF) [ttl 1]

100.0.0.1 > 224.0.0.9: igmp v2 report 224.0.0.9 (DF) [ttl 1]

100.0.0.1.router > 224.0.0.9.router: RIPv2-resp [items 2]:
{102.0.0.0/255.0.0.0}(1)
{192.168.1.0/255.255.255.0}(1) (DF) [ttl 1]

Les messages adressés par R1 se font via une adresse multicast convenue pour les routeurs RIP : 224.0.0.9. Les dernières lignes montrent clairement que RIP diffuse deux vecteurs de distance : un concernant le réseau 102.0.0.0/8 et un autre concernant le réseau 192.168.1.0/24. Observons sur R1 la table avec laquelle RIP travaille :

R1(RIP)(config-router)# end
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
C 102.0.0.0/8                         1
C 192.168.1.0/24                      1

R1(RIP)# 

RIP a été activé sur le réseau 100.0.0.0/8, donc aucune information le concernant n'est diffusée sur ce même réseau pour des raisons évidentes d'optimisation mais aussi, pour la gestion du problème de la convergence lente (Voir poison reverse.