Redistribution De Routes : Théorie

Parlons aujourd’hui d’un sujet important dans les grands réseaux : la redistribution de routes.

Si votre réseau fonctionne avec plusieurs protocoles de routage, il est essentiel de maitriser la redistribution.

Le but étant que les routes se propagent à travers tout le réseau, même si celui-ci utilise plusieurs protocoles de routage.

A travers cette série d’articles, nous allons voir pourquoi il est important de redistribuer les routes, quels sont les risques qui peuvent mener à des erreurs, et comment mettre en place la redistribution.

Il est préférable de bien maitriser les protocoles EIGRP et OSPF.

 

1)    Pourquoi la redistribution de routes ?

 

Comme dit précédemment, la redistribution de routes est utile lorsque votre réseau utilise plusieurs protocoles de routage.

Les raisons pour qu’un réseau utilise plusieurs protocoles de routage sont diverses (rattachement de deux réseaux ensemble, plusieurs générations de routeurs, plusieurs marques de routeurs, besoins spécifiques, etc…)

Vous le savez certainement, par défaut, des protocoles différents ne s’échangent pas de route entre eux.

Prenons cet exemple :

Trois réseaux sont connectés entre eux. L’un fonctionne en OSPF, l’autre en EIGRP et le dernier en RIP.

Le but serait que les trois réseaux dans les cadres gris, puissent être accessibles depuis partout.

Prenons l’exemple de 172.16.10.0 /24

R7 va annoncer une route pour 172.16.10.0 /24, à R5 et R6.

Ceux-ci pourront donc joindre 172.16.10.0 /24, en allant vers R7.

Jusqu’ici, tout va bien.

Mais par contre, que va faire R5 quand il va recevoir la MAJ RIP (pour 172.16.10.0 /24) ?

Va-t-il envoyer cette MAJ vers R3 et R4 ?

Bien sûr que non. R3 et R4 fonctionne en EIGRP. Ils ne peuvent donc pas recevoir de MAJ RIP.

 

Au-delà de R5, il personne n’aura connaissance du réseau 172.16.10.0 /24.

 

Cela pose donc un problème.

 

Vous l’aurez deviné, le but la redistribution de routes est d’annoncer une route venant d’un certain protocole, vers un réseau fonctionnant avec un autre protocole.

 

Pour faire simple, nous allons ajouter une règle sur R5, disant qu’il faut annoncer les routes RIP, dans le réseau EIGRP. R5 va donc inclure 172.16.10.0 /24 dans ses MAJ EIGRP.

Nous pourrons bien sûr choisir quelles routes doivent être redistribuées, quelle métrique y appliquer, etc…

 

 

2)    Problèmes posés

 

Malheureusement, la redistribution de routes amène plusieurs problèmes.

 

Problème 1 : Perte de la métrique

Le premier problème lorsque l’on redistribue une route, c’est que la métrique de base est perdue.

Voyons cela en exemple :

R4 cherche la meilleure route pour 172.16.30.0 /24, c’est-à-dire R1.

Il est évident que la meilleure route est : R4 -> R5 -> R2 -> R1.

Pourtant, en mettant en place une redistribution de routes simple, R1 préfèrera choisir R1 -> R3 -> R1.

Pourquoi ?

Tout simplement, car quand une route est redistribuée, sa métrique de base est perdue.

R3 et R2 vont tous les deux annoncer une route pour 172.16.30.0 /24, dans laquelle il ne sera plus fait état de la métrique des liens 100 et 10 Mbps.

Aux yeux de R4, R3 est meilleur que R2 pour joindre 172.16.30.0 /24.

Il nous faudra donc choisir nous-même la métrique à appliquer aux routes (à configurer sur R2 et R3 en activant la redistribution).

Ainsi, R4 préférera passer par R2.

 

Problème 2 : Perte de la distance administrative

Autre problème, quand une route est redistribuée, sa distance administrative est perdue.

Pour rappel, la distance administrative (ou AD), est utile quand le routeur possède deux routes pour une même destination, et que ces deux routes viennent d’un protocole différent.

On préférera donc utiliser une route annoncée par OSPF, qu’une route annoncé par RIP.

 

Voyons quel problème peut poser la perte de l’AD :

R4 possède une route EIGRP externe. Ces routes-là ont une AD de 170.

R2 va donc apprendre 2 routes pour 172.16.20.0 /24 :

• Une qui a été annoncé par R4, et qui passe par R2 -> R5 -> R4
• Une qui a été redistribué dans le réseau OSPF, et qui passe par R2 -> R1 -> R3 -> R4

Logiquement, R2 devrait préférer passer par R5, plutôt que par le réseau OSPF.

Malheureusement, ce n’est pas ce qu’il va faire.

Pourquoi ? Simplement que quand la route pour 172.16.20.0 /24 a été redistribuée dans OSPF, l’AD de cette route est passée de 170 à 110.

R2 a donc le choix entre une bonne route avec une AD de 170, ou une mauvaise route avec une AD de 110.

Et bien sûr, il va choisir la route avec l’AD de 110.

 

Il faudra donc faire attention. La perte de l’AD peut parfois poser problème.

Dans le cas présent, nous pourrions changer l’AD sur R2. Nous pourrions choisir une AD de 105 pour les routes EIGRP externes.

Ainsi, il préférera passer par R5, que par le réseau OSPF.

 

Problème 3 : Boucle de redistribution

Ce dernier problème est relativement simple.

Il est possible que la redistribution de routes cause une boucle de routage.

 

Prenons la topologie suivante :

 

R4 va annoncer une route pour 172.16.20.0 /24

Cette route sera ensuite redistribuée par R3 dans le réseau OSPF.

R2 va prendre connaissance de la route redistribuée, puis va lui-même la redistribuer dans le réseau EIGRP (vers R5).

R5 va ensuite faire suivre cette route.

Au final, R4 possèdera deux routes pour 172.16.20.0 /24.

Une qui a pour Next Hop, R8 (ce qui est logique), et l’autre qui a pour Next Hop R5.

Déjà, ce n’est pas bien. Cela ne sert à rien d’envoyer un message vers R2, alors que le seul moyen de joindre 172.16.20.0 /24 est d’aller vers R8.

 

Maintenant, imaginons que la route redistribuée depuis OSPF dans EIGRP, ait une meilleure métrique et une distance administrative meilleure ou équivalente que la route ayant pour Next Hop R8.

C’est-à-dire que R4 préférera envoyer les paquets vers R2 plutôt que vers R8.

Il en résultera une boucle de routage. Les paquets à destination de 172.16.20.0 /24 feront constamment le chemin R4 -> R5 -> R2 -> R1 -> R3 -> R4, etc… (Jusqu’à ce que le TTL arrive à 0).

 

Au final, il n’est plus possible de joindre le réseau 172.16.20.0 /24.

Et d’où vient le problème ?

Simplement que R2 n’aurait pas du re-redistribuer la route pour 172.16.20.0 /24 dans le réseau EIGRP.

Il faudrait donc mettre une règle sur R2, disant que seules les routes pour 172.16.30.0 /24 doivent être redistribuées.

Ainsi, la route pour 172.16.20.0 /24 sera toujours redistribuée dans le réseau OSPF par R3, mais R2 ne la renverra pas dans le réseau EIGRP.

 

3)    Les solutions

 

Nous avons vu les problèmes et les contraintes de la redistribution de routes. Voyons maintenant les solutions.

Nous allons faire un rapide aperçu. Par la suite, nous ferons un TPpour mettre en place ces solutions.

Nous avons déjà vu qu’il est possible de choisir la métrique et de modifier la distance administrative. Nous ne reviderons donc pas sur ces deux solutions pour le moment.

 

Distribution List

Le principe est très simple : utiliser une ACL pour choisir les routes à redistribuer.

 

Par exemple, nous pouvons mettre une Distribution Liste sur R2 et R3, de manière à ce qu’ils n’autorisent que les routes pour 172.16.30.0 /24 à être redistribuées.

De cette manière, plus de risque de boucle de routage comme vu précédemment.

 

Prefix List

La Prefix List ressemble à la Distribution Liste.

Sauf que celle-ci n’utilise pas d’ACL.

De plus, il est possible d’effectuer un filtrage en fonction du masque de sous réseau.

Par exemple, il est possible d’autoriser toutes les routes pour 10.1.0.0 /8, qui ont un masque supérieure ou égal à /24.

 

Donc :

• 10.1.0.0 /24 -> OK
• 10.1.35.0 /29 -> OK
• 10.1.67.0 /22 -> Non

 

Route Map

La Route Map est la solution la plus complexe, mais aussi la plus complète.

Il est possible de faire beaucoup de chose avec. Parmi les possibilités nous pouvons :

• Redistribuer ou non, selon la destination de la route
• Choisir la métrique à annoncer
• Taguer les routes pour éviter les boucles
• Etc…