mardi 22 avril 2014

TP- Redistribution avancée des routes

Introduction
Nous avons vu le but de la redistribution, les problèmes posés par celle-ci, puis nous avons fait un aperçu des méthodes qui existent pour redistribuer les routes sans trop entrer dans les détails. A la fin de ce TP, vous devriez maitriser au moins la redistribution basique.
Nous allons implémenter :
-          la redistribution basique
-          la redistribution avec la "Distribution List"
1)     Topologie
La topologie que nous allons utiliser est presque la même que dans la partie cours .

Nous retrouvons 3 réseaux : un OSPF, un EIGRP, et un RIP.
Les IP des interfaces sont celles du réseau associé + ID du routeur.
Exemple pour R3 S0/1 : 10.0.34.3 /24

2)     Configuration de base

 Voici la liste des choses à mettre en place avant de commencer :
-          IP des interfaces
-          Interfaces Loopback
Configurons ensuite le routage.

OSPF

R1(config)#router ospf 1
R1(config-router)#router-id 1.1.1.1
 
R1(config-router)#network 172.16.30.0 0.0.0.255 area 0
R1(config-router)#network 172.16.31.0 0.0.0.255 area 0
R1(config-router)#network 172.16.32.0 0.0.0.255 area 0
R1(config-router)#network 172.16.33.0 0.0.0.255 area 0
R1(config-router)#network 10.0.13.0 0.0.0.255 area 0
R1(config-router)#network 10.0.12.0 0.0.0.255 area 0
 
R2(config)#router ospf 1
R2(config-router)#router-id 2.2.2.2
R2(config-router)#network 10.0.12.0 0.0.0.255 area 0
 
R3(config)#router ospf 1
R3(config-router)#router-id 3.3.3.3
R3(config-router)#network 10.0.13.0 0.0.0.255 area 0

EIGRP

 
R2(config)#router eigrp 1
R2(config-router)#no auto-summary
R2(config-router)#network 10.0.25.0 0.0.0.255
 
R3(config)#router eigrp 1
R3(config-router)#no auto-summary
R3(config-router)#network 10.0.34.0 0.0.0.255
 
R4(config)#router eigrp 1
R4(config-router)#no auto-summary
R4(config-router)#network 10.0.34.0 0.0.0.255
R4(config-router)#network 10.0.45.0 0.0.0.255
 
R4(config-router)#network 172.16.20.0 0.0.0.255
R4(config-router)#network 172.16.21.0 0.0.0.255
R4(config-router)#network 172.16.22.0 0.0.0.255
R4(config-router)#network 172.16.23.0 0.0.0.255
 
R5(config)#router eigrp 1
R5(config-router)#no auto-summary
R5(config-router)#network 10.0.25.0 0.0.0.255
R5(config-router)#network 10.0.45.0 0.0.0.255

RIP


R5(config)#router rip
R5(config-router)#version 2
R5(config-router)#network 10.0.56.0

R6(config)#router rip
R6(config-router)#version 2
R6(config-router)#network 10.0.56.0
R6(config-router)#network 172.16.0.0
La configuration de base est prête.
Avant de passer à la redistribution, vérifier que les routes se sont bien propagées.
R3#sh ip route
R5#sh ip route
3)     Redistribution basique
Nous allons commencer par redistribuer les routes OSPF dans EIGRP
La configuration doit s’effectuer sur R2 et R3.


Pour redistribuer les routes OSPF dans EIGRP, il faut aller dans le mode EIGRP (attention à ne pas se tromper).
Il est très important de spécifier la métrique quand on redistribue des routes dans EIGRP (de même pour RIP). Sans une métrique choisie, les routes sont annoncées avec une métrique infinie.
Il faut ensuite faire de même pour R3 :

Si la redistribution s'est passée correctement, on devra retrouver dans la table de routage de R4 des routes vers les réseaux distants de la zone verte (domaine de routage OSPF). 
Allons voir sur R4 si la redistribution a fonctionné :

Les routes ayant le préfix « EX » sont des routes externes, c’est-à-dire les routes que nous avons importées dans EIGRP.
Faisons de même en important les routes EIGRP dans OSPF.

La commande est presque la même que précédemment.
Le mot clé « Subnet » permet de ne pas résumer les routes quand elles sont redistribuées.
Si vous ne spécifiez pas de métrique çàd que vous vous limitez à la commande "redistribute eigrp 1 subnets", une métrique de 20 est utilisée par le processus OSPF.
Le « metric-type » permet de définir si la métrique doit grandir après redistribution.
Un « Metric-type » de 1 signifie que la métrique augmente après la redistribution (à chaque fois qu’un routeur annonce cette route)
Un « Metric-type » de 2 signifie que la métrique reste la même après redistribution (tous les routeurs recevant cette route verrons une métrique de 50)
Faites de même sur R3 :

Voyons le résultat sur R1 :

R1 connait les routes venant d’EIGRP !
Sous packet tracer, la commande redistribute est limitée, vous ne pouvez saisir que "subnets" en tant qu'argument, la métrique 20 sera donc utilisée par défaut, voici un imprime-écran du résultat dans ce cas de figure:



Finissons par la redistribution entre RIP et EIGRP


 Vérifions si R6 connait toutes les routes

Faites quelques tests pour vous assurer du bon fonctionnement de la redistribution (ping vers des réseaux distants). 
4)     Modification de la distance administrative
Comme nous l’avons vu dans le cours, la perte de la distance administrative (DA), peut amener à choisir une route moins bonne.

Pour constater cela, allez voir la table de routage de R3 :

constater cela, allez voir la table de routage de R3 :


Pour joindre 172.16.10.0/24, R3 va utiliser R1 comme NextHop. Alors que passer par R5 serait plus intéressant (on traversera 2 domaines de routage au lieu de 3).

Si R3 a choisi R1, c’est à cause de la distance administrative.
Il a le choix entre :
NextHop R1, DA 110
NextHop R5, DA 170

La redistribution de route a donc faussé le choix de route.
La solution est simple : changer les paramètres de DA sur R3.
R3(config)#router eigrp 1
R3(config-router)#distance eigrp 90 105
 Et le résultat :

5)     Distribution List (à tester sous GNS3!)
 Nous venons de voir la redistribution basique. Voyons maintenant une première technique permettant de contrôler la redistribution.
La Distribution List se base sur une ACL pour savoir si oui ou non il faut redistribuer une route.
Prenons un exemple : nous ne voulons pas qu’une route vers le réseau 172.16.33.0/24 soit redistribuée. Nous allons donc faire une ACL n’autorisant que les routes voulues (ou bien une ACL interdisant la route non voulue).
R2(config)#access-list 1 permit 172.16.30.0 0.0.0.255
R2(config)#access-list 1 permit 172.16.31.0 0.0.0.255
R2(config)#access-list 1 permit 172.16.32.0 0.0.0.255
R2(config)#access-list 1 permit 10.0.12.0 0.0.0.255
R2(config)#access-list 1 permit 10.0.13.0 0.0.0.255
Le Deny All qui est automatiquement placé à la fin, se chargera de refuser le reste.
R2(config)#router eigrp 1
R2(config-router)#distribute-list 1 out
N’oublions pas de faire la même chose sur R3 :
R3(config)#access-list 1 permit 172.16.30.0 0.0.0.255
R3(config)#access-list 1 permit 172.16.31.0 0.0.0.255
R3(config)#access-list 1 permit 172.16.32.0 0.0.0.255
R3(config)#access-list 1 permit 10.0.12.0 0.0.0.255
R3(config)#access-list 1 permit 10.0.13.0 0.0.0.255

R3(config)#router eigrp 1
R3(config-router)#distribute-list 1 out
Puis vérifions le résultat sur R5 :

Plus aucune trace de la route vers 172.16.33.0/32
Les réseaux sont en /32 à cause des interfaces Loopback. En fait, un routeur OSPF considère ses interfaces loopback des routes hôte çàd qu'elles devront être définies avec le préfixe /32.
La commande ip ospf network point-to-point sur les interfaces Loopback résout ce problème

 

Redistribution de route



Parlons aujourd’hui d’un sujet important dans les grands réseaux : la redistribution de route.
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.
Dans ce chapitre, 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.
1)    Pourquoi la redistribution de route ?
Comme dit précédemment, la redistribution de route 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.).
Sachez que par défaut, des protocoles différents ne s’échangent pas de route entre eux.
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, personne n’aura connaissance du réseau 172.16.10.0 /24.
Cela pose donc un problème.
Le but la redistribution de route 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 route 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.
Exemple :


R4 cherche la meilleure route pour 172.16.30.0 /24.
Il est évident que la meilleure route est : R4 -> R5 -> R2 -> R1.
Pourtant, en mettant en place une redistribution de route simple, R4 préfèrera choisir :
R4->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.
Pour R4, R3 est meilleur que R2 pour joindre 172.16.30.0 /24.
Donc, il faudra que nous choisissions 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

Un autre problème est soulevé, quand une route est redistribuée, sa distance administrative est perdue.
Pour rappel, la distance administrative (DA) 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 ou source différente.
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 la DA :

R4 possède une route EIGRP externe. Ces routes-là ont une DA 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 ? quand la route pour 172.16.20.0 /24 a été redistribuée dans OSPF, la DA de cette route est passée de 170 à 110.
R2 a donc le choix entre une bonne route avec une DA de 170, ou une mauvaise route avec une DA de 110.
Et bien sûr, il va choisir la route avec la DA de 110.
 Il faudra donc faire attention. La perte de la DA peut parfois poser problème.
Dans le cas présent, nous pourrions changer la DA sur R2. Nous pourrions choisir une DA 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 route 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 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 dû 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 route. Voyons maintenant les 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 List 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. 

Sachez qu'il existe deux autres solutions : Prefix List et Route Map (redistribution avancée qui sort du cadre de ce cours).