La Redistribution de route

Il n’est pas rare de voir , au sein d’ un réseau IP , plusieurs instances de protocole de routage. Les raisons sont diverses et variées, en effet , cela peut être dû à un rachat d’entreprise , une fusion-acquisition , la réintégration d’une filiale au sein de la société mère , chacune des entités utilisait avant le regroupement un protocole de routage différent sous la responsabilité d’équipes informatiques distinctes .La raison peut être aussi basée sur un motif purement politique : chaque équipes réseaux ayant des préférences vis-à-vis de tel ou tel protocole ( OSPF étant un protocole ouvert ,standardisé et donc multiconstructeurs , EIGRP est propriétaire et contraint donc à l’utilisation d’équipements Cisco…. ) .

Peu importe la raison , plusieurs protocoles de routages peuvent être déployé au sein d’un réseau , cependant les routes apprises par chaque instance ne sont pas partagées nativement entre ces protocoles.

Figure 1 (cliquez pour agrandir)  :

Ici , seul paris est configuré avec les 2 protocoles OSPF et EIGRP cependant les deux domaines sont complètement étanches , c’est à dire que les réseaux connectés à Bordeaux et Marseille ne sont pas connu de Nantes et Lyon . Le routeur de Paris n’annoncera pas les routes OSPF de Bordeaux et Marseille vers Nantes et lyon qui eux utilisent EIGRP.

Afin de rendre cela possible , il nous faut mettre en place un mécanisme de redistribution de routes , Paris deviendra alors un point de Redistribution entre OSPF et EIGRP , de façon à ce que :

Bordeaux et Marseille aient connaissance des réseaux : 192.168.3.0 /24 et 192.168.4.0 /24
Nantes et Lyon aient connaissance des réseaux : 192.168.1.0 /24 et 192.168.2.0 /24

La redistribution peut se faire de façon unidirectionnelle :

C’est à dire qu’ on redistribue OSPF dans EIGRP , dans ce cas Nantes et Lyon connaissent les routes des réseaux de bordeaux et Marseille , en revanche ces derniers n’ont aucunes annonce de routes vers Nantes et Lyon , inutile de dire que cela posera des problèmes de communications.

Dans notre cas la redistribution sera bidirectionnelle :

OSPF redistribué dans EIGRP et inversement.
On va distinguer un protocole « Hôte » qui accueille les routes du protocole « redistribué ». La configuration du mécanisme de redistribution se fait dans le mode de configuration du processus de routage Hôte. En d’autres termes , si on veut redistribuer les routes OSPF dans EIGRP, on se place en mode de configuration de l’instance de routage OSPF pour y inclure EIGRP .

Syntaxe de la redistribution

redistribute protocol [process-id] [level-1 | level-1-2 | level-2] [as-number] [metric metric-value] [metric-type type-value] [match{internal| external 1 | external 2}] [tag tag-value] [route-map map-tag] [subnets]

Les différentes options dépendent des protocoles Hôtes et Redistribués sur lesquels on travaille , d’éventuels filtrages routes ou alors de certaines manipulations sur les routes qu’on peut effectué, on y reviendra en détail plus tard .

Voila comment configurer la redistribution bidirectionnelle sur le réseau de la figure 1 :

R1

conf t
interface fa0/0
ip address 192.168.1.1 255.255.255.0
no shut
exit

interface fa0/1
ip address 192.168.5.2 255.255.255.252
no shut
exit

router ospf 1
network 192.168.1.1 0.0.0.0 area 0
network 192.168.5.2 0.0.0.0 area 0
ospf log-adjacency-changes

R2

conf t
interface fa0/0
ip address 192.168.2.1 255.255.255.0
no shut
exit

interface fa0/1
ip address 192.168.5.6 255.255.255.252
no shut
exit

router ospf 1
network 192.168.2.1 0.0.0.0 area 0
network 192.168.5.6 0.0.0.0 area 0
ospf log-adjacency-changes

R3

conf t
interface fa1/0
ip address 192.168.1.1 255.255.255.252
no shut
exit

interface fa1/1
ip address 192.168.5.5 255.255.255.252
no shut
exit

interface fa0/0
ip address 192.168.2.9 255.255.255.252
no shut
exit

interface fa0/1
ip address 192.168.5.13 255.255.255.252
no shut
exit

router ospf 1
network 192.168.1.1 0.0.0.0 area 0
network 192.168.5.2 0.0.0.0 area 0
ospf log-adjacency-changes
redistribute eigrp 10 metric 100 subnets

router eigrp 10
network 192.168.5.0
redistribute ospf 1 metric 100000 10 255 100 1500

R4

conf t
interface fa0/0
ip address 192.168.3.1 255.255.255.0
no shut
exit

interface fa0/1
ip address 192.168.5.10 255.255.255.252
no shut
exit

router EIGRP 10
network 192.168.5.0
network 192.168.3.0
no auto-summary

R5

conf t
interface fa0/0
ip address 192.168.4.1 255.255.255.0
no shut
exit

interface fa0/1
ip address 192.168.5.14 255.255.255.252
no shut
exit

router EIGRP 10
network 192.168.5.0
network 192.168.4.0
no auto-summary

Arrêtons nous sur la configuration de la redistribution sur R3 :

router ospf 1
network 192.168.1.1 0.0.0.0 area 0
network 192.168.5.2 0.0.0.0 area 0
ospf log-adjacency-changes
redistribute eigrp 10 metric 100 subnets

router eigrp 10
network 192.168.5.0
redistribute ospf 1 metric 100000 10 255 100 1500

Comme énoncé précédemment , on vois ici que la redistribution se fait au sein du mode de configuration de l’instance de routage Hôte qui va acceuillir les routes redistribuées.

Vous avez pu remarquer que dans les 2 cas , on a fixé une métrique pour ces routes redistribuées , la raison est simple , EIGRP et OSPF se base sur des critères complètement différente pour juger de la qualité d’une route par rapport à une autre pour une destination donnée ;

Petit Rappel :

OSPF utilise le coût comme métrique calculé de la sorte : Cout = 10*7 / BP

Eigrp utilise une métrique composite constituée de 5 paramètres :

• La Bande passante du lien en kilobits/s
• Le Délai : délai de traitement du paquet en fonction du type d’interface , en Dixième de micro-secondes
• Reliability : capacité de transport des paquets de façon sûre , (valeur entre 0 et 255 , 255 = 100% reliable , 0 = no reliability)
• Load : charge/ bande passante effective du lien ( valeur entre 0 et 255 , où 255 signifie une charge à 100% )
• MTU : maximum transmission Unit , taille maximum du paquet IP.

En réalité seulement , 2 paramètres sont utilisés :  la Bande Passante et le Délai.

RIP v1 / RIP v2 : on utilise les hop count , c’est-à-dire le nombre de saut ( de routeurs ) pour atteindre la route.

Comme vous pouvez le voir , ces métriques étant complètement différentes , les routes redistribuées doivent donc avoir une métrique intelligible par le protocol Hôte qui les acceuillent .

Ici , nous avons donc :

 redistribute eigrp 10 metric 100 subnets

On va redistribuer les routes venant de l’instance EIGRP dont l’AS est 10 , et leur assigner une métrique de 100 ( ici la métrique est purement arbitraire , pour notre exemple ) .

Le mot clé subnets ici permet de redistribué tous les sous réseaux , autrement seules les routes des réseaux majeurs c’est-à-dire les réseaux CLASSFUL auraient été injectées.

Inversement pour l’instance OSPF n°1 redistribuée dans EIGRP :

 redistribute ospf 1 metric 100000 10 255 100 1500

La metrique tient naturellement compte des 5 valeurs qu’on a présentée plus haut , respectivement : Bande passante – Delay – Reliability – Load – MTU ( ici , les valeurs sont choisies arbitrairement pour notre exemple ) .

A ce stade notre redistribution est faite , et nos sites de Bordeaux , Marseille , Lyon et Nantes peuvent communiquer sans problème.

Revenons un moment sur les métriques à fixer lors des redistributions :

Vous devez assigner une métrique aux routes redistribuées sous peine de dysfonctionnement.

En cas d’oubli , les routes se voient attribuées une métrique et un type de métrique par defaut en fonction du protocole dans lequel elles sont injectées :

Voici Trois méthodes qui permettent de définir une métrique pour les routes redistribués :

Note : elles sont classées de façon séquentielle et induisent donc un ordre de priorité , ainsi dans l’ordre décroissant (c’est-à-dire la plus prioritaire en premier )

• En utilisant l’option route-map de la commande redistribute qui pointe vers… une route-map qui va matcher les routes à injectées et définir la métrique à utiliser au moyen de l’instruction SET METRIC .

Portée de la commande : Cette option offre la plus grande granularité parmis les 3 méthodes de redistribution , car on va pouvoir affecter différentes métriques à différentes routes venant de la même source ( du même Peer ) en utilisant la logique conditionnelle des routes-map ( MATCH / SET )

• Au niveau de la commande redistribute , comme dans notre configuration de R3

Pour rappel , voici la syntaxe du redistribute

redistribute protocol [process-id] [level-1 | level-1-2 | level-2] [as-number] [metric metric-value] [metric-type type-value] [match {internal | external 1 | external 2}] [tag tag-value] [route-map map-tag] [subnets]

(Les options [level-1 | level-1-2 | level-2] [metric-type type-value] [match {internal | external 1 | external 2}] sont directements liées aux concepts de fonctionnement des protocoles de routages ; Il serait trop long de tout expliquer ici , aussi nous verrons ces notions dans les articles dédiés respectivement à chaque IGP. )

Portée de la commande : elle s’applique à toutes les routes redistribuées par la commande redistribute , ainsi si plusieurs protocoles sont redistribués et donc que plusieurs commande « redistribute » sont utilisées , l’utilisation de l’option métric dans la commande redistribute ne s’applique uniquement pour les routes conçernées par celle-ci et non pour les autres routes concernées par les autres redistribute.

• En utilisant l’option Default-metric

Portée de la commande : Cette commande force une métrique par défaut à toutes les routes redistribuées ( s’applique donc à tous les redistribute ).