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’in té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.

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

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

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 utilise ront 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)#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

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 !

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.

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 ?

Le principe est le même pour EIGRP.

Il suffit d’indiquer un Offset cohérant par rapport à la métrique.