Path Control

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 aurait 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

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.

5)     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.

Le numéro 10 après l’IP du Next Hop, correspond à son ID.

Dans l’ordre, le routeur test la disponibilité du Next Hop ayant le plus haut ID.

Sinon, il prend le Next Hop par défaut (celui qui n’a pas d’ID).

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.

6)     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.