Après avoir vu plusieurs protocoles de routage, voyons comment influencer le routage sur un réseau.
Certains réseaux possèdent des liens redondants. Il peut être utile de choisir comment les routeurs vont exploiter ces liens : répartition de charge, réaction en cas de panne, meilleures performances, etc…
Nous allons voir 3 choses :
- Le Policy Based Routing
- Les Offset List
- Les SLA – Service Level Agreement
Chacune de ces techniques nous permettra de faire du Path Control. Comme elles ont des utilités différentes, il sera important de toutes les maitriser.
1) Théorie sur le Path Control
Avant de nous plonger dans la configuration de ces techniques, voyons rapidement l’intérêt du Path Control.
Comme nous l’avons dit, un réseau moderne possède souvent plusieurs chemins pour une même destination :
- Plusieurs chemins en interne
- Plusieurs chemins vers internet (plusieurs FAI)
Le but est donc de contrôler l’utilisation de ces déférents liens.
Par exemple, utiliser un FAI pour certains types de trafic (VOIP ?), et utiliser l’autre pour le reste.
Ou encore, garder un FAI en secours au cas où le premier tombe en panne (et basculer le trafic sur le FAI de secours si nécessaire).
Aussi, nous pouvons influencer les protocoles de routage. Par exemple, RIP ne prend pas en charge la bande passante.
Ce qui fait que si il a le choix entre deux liens, le premier en 2 saut à 1Gbs, et le deuxième en 1 saut à 100Mbs, il va préférer le deuxième (ce qui n’est pas le bon choix).
Encore une fois, le Path Control nous permet de corriger cela.
2) La topologie
Voici la topologie que nous allons utiliser.
Oui, il y a beaucoup de routeur.
Si vous ne disposez pas de suffisamment de ressources pour faire fonctionner tous les routeurs en même temps, vous pouvez vous contenter de démarrer seulement les routeurs utiles au moment de la configuration.
Nous avons donc deux réseaux, plus Internet.
Le tout est représenté de manière basique (pas de NAT).
Le réseau 1 fonctionne en EIGRP.
Le réseau 2 en RIP.
La configuration de base à appliquer est la suivant :
- IP sur les interfaces
- EIGRP pour le réseau 1
- RIP pour le réseau 2
Ensuite, utiliser des routes statiques sur R1 et R2 pour l’accès à internet :
R1(config)#ip route 0.0.0.0 0.0.0.0 172.16.1.3 R2(config)#ip route 0.0.0.0 0.0.0.0 172.16.2.3
Sur internet, nous allons utiliser des routes statiques :
R4(config)#ip route 172.16.0.0 255.255.0.0 serial 0/0 R4(config)#ip route 172.17.0.0 255.255.0.0 serial 0/1
R5(config)#ip route 172.16.0.0 255.255.0.0 serial 0/0 R5(config)#ip route 172.17.0.0 255.255.0.0 serial 0/1
R6(config)#ip route 172.16.0.0 255.255.0.0 serial 0/0 (Pour plus de simplicité, R6 utilisera toujours R4 comme Next Hop) R6(config)#ip route 172.17.0.0 255.255.0.0 serial 0/2
Dans le réseau RIP, annoncez une route par défaut pour Internet :
R7(config)#ip route 0.0.0.0 0.0.0.0 Serial0/0 R7(config)#router rip R7(config-router)#redistribute static
A ce stade, le réseau possède une configuration basique.
Nous allons maintenant influencer le routage des données du réseau 1 vers internet.
Plus tard, nous nous occuperons du réseau 2.
3) Policy Based Routing
Le Policy Based Routing est le fait d’influencer le routage des données.
Par exemple, en fonction de la source du trafic, de son type, de sa destination, nous pourrons forcer le routeur à envoyer le trafic vers le FAI 1 ou le FAI 2.
C’est ce que nous allons faire dans un premier temps.
Par la suite, nous allons mettre en place un système de tolérance de panne.
Commençons donc par influencer le routage.
Nous allons définir un scénario à suivre !
Partons du principe que le FAI 1 (R4) est le plus rapide et le plus fiable. Le FAI 2 est moins rapide et moins fiable.
Le but sera donc d’envoyer le trafic important vers le FAI 1, et le reste vers le FAI 2.
Faisons simple :
- Le réseau 172.16.10.0 est celui des employés. Ce trafic n’est pas important, nous l’enverrons sur le FAI 2.
- Le réseau 172.16.20.0 est celui des serveurs. Ces serveurs sont très sollicités sur internet. Ils utiliseront le FAI 1.
Voici donc un scénario basique, mais suffisant pour une petite démonstration.
La question est donc « Comment faire pour répondre au scénario ? ».
La réponse est simple, avec une Route-Map !
Voici sa structure :
Route Map ChoixFAI Match ip address « Adresses voulues » Set ip next-hop « FAI voulu »
Voici comment faire en pratique :
R3(config)#ip access-list extended CLIENTS R3(config-ext-nacl)#permit ip 172.16.10.0 0.0.0.255 any R3(config-ext-nacl)#permit ip 172.16.1.0 0.0.0.255 any
R3(config)#route-map ChoixFAI permit 10 R3(config-route-map)#match ip address CLIENTS R3(config-route-map)#set ip next-hop 35.0.0.5
Et voici comment rediriger tout le trafic des clients (employés) vers le FAI No 1
Faisons de même pour les serveurs :
R3(config)#ip access-list extended SERVERS R3(config-ext-nacl)#permit ip 172.16.20.0 0.0.0.255 any R3(config-ext-nacl)#permit ip 172.16.2.0 0.0.0.255 any
R3(config)#route-map ChoixFAI permit 20 R3(config-route-map)#match ip address SERVERS R3(config-route-map)#set ip next-hop 34.0.0.4
Ensuite, envoyons le trafic non capturé, vers le FAI 2.
R3(config)#route-map ChoixFAI permit 30 R3(config-route-map)#set ip next-hop 35.0.0.5
Enfin, ajoutons une dernière règle. Vous aurez peut être remarqué que jusqu’ici, même le trafic allant du Lan vers le Lan (par exemple R1 vers R2) sera renvoyé vers un FAI.
Il faut donc ajouter une entrée dans la Route-Map, de manière à ce que le Next-Hop du trafic ne soit pas altéré.
Commençons par une ACL :
R3(config)#ip access-list extended LanToLan R3(config-ext-nacl)#permit ip 172.16.0.0 0.0.255.255 172.16.0.0 0.0.255.255
(Il est tout à fait possible de mieux construire cette ACL, de manière à capturer toutes les IP privées)
Puis ajoutons l’entrée dans la Route-Map :
R3(config)#route-map ChoixFAI permit 2 R3(config-route-map)#match ip address LanToLan
Voilà, il ne reste plus qu’à appliquer la Route-Map.
R3(config)#interface serial 0/0 R3(config-if)#ip policy route-map ChoixFAI
R3(config)#interface serial 0/1 R3(config-if)#ip policy route-map ChoixFAI
Si vous faites des tests, vous verrez que les paquets vont bien vers les FAI voulus.
Les clients (R1) utilisent le FAI 2 comme convenu
Les serveurs (R2) utilisent bien le FAI 1
Libre à vous maintenant de créer un scénario plus complexe.
Par exemple, le trafic HTTPS (ou tout autre type de trafic) venant des clients doit utiliser le FAI 1
Voici la marche à suivre :
R3(config)#ip access-list extended CLIENTS_HTTPS R3(config-ext-nacl)#permit tcp 172.16.10.0 0.0.0.255 any eq 443
R3(config)#route-map ChoixFAI permit 5 R3(config-route-map)#match ip address CLIENTS_HTTPS R3(config-route-map)#set ip next-hop 34.0.0.4
Pour tester cette configuration, faites un Telnet sur l’IP voulu, en spécifiant le port 443
Le message “Connection refused by remote host “ indique que le message est bien arrivé.
Si vous voulez vous assurer que le message passe bien par le FAI 1, il suffit de couper l’interface R3 s0/2.
La tentative de Telnet donnera alors :
N’oubliez pas de réactiver l’interface.
Avant de passer à la suite, prenez le temps d’élaborer un peu plus le scénario, afin d’explorer les possibilités.
Attention, il faudra alors adapter la suite du TP à vos modifications, on bien les supprimer.
4) SLA – Service Level Agreement et techniques de test proactives
Vous avez apprécié la manipulation précédente, vous allez adorer celle-ci !
Avec ce que nous avons mis en place, il y a un problème.
Que se passe-t-il si le FAI 1 tombe en panne ? Et bien les serveurs n’ont plus accès à internet.
Pareil avec le FAI 2 et les clients.
L’idéal serait d’utiliser le deuxième FAI si le premier tombe.
Voyons comment faire !
Il faut utiliser ce que l’on appelle une technique de test proactive.
Le principe est simple, tester la disponibilité du FAI (avec des Ping), et basculer sur le deuxième FAI si le premier ne répond plus.
Nous allons mettre en place cela pour les serveurs. Si le FAI 1 ne répond plus, ils utiliseront le FAI 2.
Quant aux clients, nous ne ferons pas la manipulation pour qu’ils basculent sur le FAI 1 en cas de panne (mais libre à vous de la faire par la suite).
La première chose à faire est de mettre en place une opération SLA :
R3(config)#ip sla monitor 1 R3(config-sla-monitor)#type echo protocol ipicmpEcho 34.0.0.4 R3(config-sla-monitor-echo)#timeout 1000 R3(config-sla-monitor-echo)#frequency 3 (tous les combien de temps une requête est envoyée, par défaut : 60)
R3(config)#ip sla monitor schedule 1 start-time now life forever (le test démarre tout de suite, et ne s’arrête jamais)
Ensuite, un objet de tracking va analyser le statut de l’opération SLA.
R3(config)#track 1 rtr 1 reachability
Il faut maintenant utiliser cet objet de tracking
Retournons dans la Route Map qui définit le FAI à utiliser pour les serveurs.
Voici son état actuel :
route-map ChoixFAI permit 20 match ip address SERVERS set ip next-hop 34.0.0.4
Et voici comment la modifier :
R3(config)#route-map ChoixFAI permit 20 3(config-route-map)#no set ip next-hop 34.0.0.4 R3(config-route-map)#set ip next-hop verify-availability 34.0.0.4 10 track 1 R3(config-route-map)#set ip next-hop 35.0.0.5
Lors de la configuration du Next Hop, nous pouvons spécifier l’objet de tracking (ici track 1)
Le numéro 10 après l’IP du Next Hop, correspond au poids de la route. Plus le poids est élevé, plus la route est favorisée.
Ici, le routeur utilise le Next-Hop 34.0.0.4 si l’objet de tracking répond. Sinon il utilise le deuxième Next-Hop.
Vous pouvez maintenant faire les tests !
La bascule se fait automatiquement !
A vous de voir si vous souhaitez faire de même pour les clients.
5) Les Offset-Lits
Finissons par une notion simple, les Offset-List.
Le but est de rajouter un Offset à la métrique d’une route.
Offset signifie décalage.
Le but est donc de modifier la métrique d’une route.
Prenons un exemple.
Dans le réseau 2, R7 a deux chemins pour joindre 172.17.10.0 /24.
Soit R7 -> R9
Soit R7 -> R8 -> R9.
Dans le cas présent, mieux vaut prendre le chemin le plus court.
Mais imaginons que le lien R7 -> R9 soit un lien 100Mbs, alors que R7 -> R8 et R8 -> R9 sont des liens 1Gbs.
Quel chemin RIP va-t-il choisir ? Le lien de 100Mbs, car c’est celui avec le moins de saut.
Il faudrait donc augmenter la métrique de la route suivante :
Si nous changeons le nombre de saut pas « 3 », R7 préférera passer par R8.
La manipulation est relativement simple :
R7(config)#access-list 1 permit 172.17.10.0 0.0.0.255 R7(config)#router rip R7(config-router)#offset-list 1 in 2 serial 0/2
Voici les détails de la commande :
offset-list : mot clé pour mettre en place une Offset List en mode « router »
1 : identifiant de l’ACL indiquant qu’elles routent il faut filtrer
In : permet de choisir si l’Offset est appliqué sur les routes reçus ou annoncées
2 : Offset à appliquer
Serial 0/2 : interface sur laquelle on applique l’Offset List
Qu’en est-il de la table de routage ?
Parfait, R7 a choisi R8 comme Next Hop pour 172.17.10.0 /24
Le principe est le même pour EIGRP.
Il suffit d’indiquer un Offset cohérant par rapport à la métrique.
Bonjour,
un très bon résumé des PBR 🙂
Merci beaucoup