Remote VPN Configuration (video de configuration)

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.

Configuration Des Différents Types De Zones OSPF

Après avoir vu la théorie des zones OSPF, voyons la pratique.

Nous allons voir comment configurer les différentes zones détaillées dans l’article précédent.

Nous ne reviendrons que très peu sur la théorie. Il est donc important de maitriser les bases.

 1)     La topologie

 Voici la topologie qui sera utilisée dans cet article. Il s’agit de la même que dans l’article précédent.

1)     Configuration Basique

 Avant de passer à la configuration des zones, mettons en place la configuration basique.

Premièrement, appliquez les IP indiquées sur les interfaces associées.

Une fois cela fait, il faut configurer le protocole OSPF.

Voici la procédure :

 R1(config)#router ospf 1

R1(config-router)#router-id 1.1.1.1
R1(config-router)#network 10.0.12.1 0.0.0.0 area 0
R1(config-router)#network 10.0.13.1 0.0.0.0 area 0

R2(config)#router ospf 1
R2(config-router)#router-id 2.2.2.2
R2(config-router)#network 10.0.12.2 0.0.0.0 area 0
R2(config-router)#network 10.0.23.2 0.0.0.0 area 0
R2(config-router)#network 10.40.1.2 0.0.0.0 area 40
R2(config-router)#network 10.50.1.2 0.0.0.0 area 50

R3(config)#router ospf 1
R3(config-router)#router-id 3.3.3.3
R3(config-router)#network 10.0.13.3 0.0.0.0 area 0
R3(config-router)#network 10.0.23.3 0.0.0.0 area 0
R3(config-router)#network 10.60.1.3 0.0.0.0 area 60

R4(config)#router ospf 1
R4(config-router)#router-id 4.4.4.4
R4(config-router)#network 10.40.1.4 0.0.0.0 area 40

R5(config)#router ospf 1
R5(config-router)#router-id 5.5.5.5
R5(config-router)#network 10.50.1.5 0.0.0.0 area 50

R6(config)#router ospf 1
R6(config-router)#router-id 6.6.6.6
R6(config-router)#network 10.60.1.6 0.0.0.0 area 60
R6(config-router)#network 10.70.1.6 0.0.0.0 area 70

R7(config)#router ospf 1
R7(config-router)#router-id 7.7.7.7
R7(config-router)#network 10.70.1.7 0.0.0.0 area 70

 Configurons R1 comme un ASBR :

 R1(config)#ip route 172.16.0.0 255.255.255.0 Null0

R1(config)#ip route 172.16.1.0 255.255.255.0 Null0
R1(config)#ip route 172.16.2.0 255.255.255.0 Null0
R1(config)#ip route 172.16.3.0 255.255.255.0 Null0

R1(config)#router ospf 1
R1(config-router)#redistribute static subnets metric-type 1 metric 200

Vérifions que les routes externes sont bien redistribuées et que les routes des zones voisines sont bien accessibles :

Bien, la configuration de base est faite.

Les relations OSPF sont en place et toutes les zones sont en mode standard.

Actuellement, les LSA de types 3, 4 et 5 peuvent transiter librement entre les zones.

Il va donc falloir mettre en place les zones vues dans l’article précédent.

Autre chose que nous allons devoir traiter : la zone 70.

Si vous avez été attentifs, vous aurez surement remarqué que la zone 70 n’est pas directement reliée à la zone 0.

Cela est contraire aux principes des zones.

Ce type de topologie ne doit pas être mis en place dans une bonne architecture.

 Mais si pour une bonne raison vous devez mettre en place ce type de topologie (une zone reliée à la zone 0 par une autre zone), il faudra utiliser un « Virtual Link ».

Sans cela, la zone 70 sera isolée du reste.

 Voyons cela, avant de passer aux différents types de zone.

 3)     Virtual Link

Comme dit précédemment, le Virtual Link permet de relier la zone 70 à la zone 0 et ce de manière virtuelle.

 Pour l’instant, le routeur R7 est totalement isolé (malgré sa relation avec R6).

La configuration du Virtual Link est très simple :

 R3(config)#router ospf 1

R3(config-router)#area 60 virtual-link 6.6.6.6

 R6(config)#router ospf 1

R6(config-router)#area 60 virtual-link 3.3.3.3

Voyons si R7 est moins seul :

En effet, c’est comme si il était connecté à la zone 0.

4)     Stubby Area 

Attaquons le vif du sujet en commencent pas la Stubby Area.

Pour rappel, son but est d’empêcher les LSA de type 4 et 5 de rentrer (et de circuler) dans la zone.

Nous allons mettre cela en place pour la zone 40.

R4 n’aura donc plus les routes externes (172.16.0.0 /22) mais une route par défaut pointant vers R2.

 La configuration est très simple :

 R2(config)#router ospf 1

R2(config-router)#area 40 stub

 R4(config)#router ospf 1

R4(config-router)#area 40 stub

 Vérifions si les routes externes ont bien été remplacées par une route par défaut :

En effet !

 Vous pouvez aussi constater que R4 ne possède plus de LSA de type 4 et 5 dans sa base de données :

Les LSA de types 4 et 5 s’arrêtent à R2. La même commande sur ce dernier vous permettra de voir les LSA de types 4 et 5.

 Il est à noter que tous les routeurs de la zone 40 doivent être en mode Stub.

 5)     Totally Stubby Area

Comme dit dans le précédent article, le but de cette zone est d’empêcher le transit des LSA de types 3, 4 et 5.

Le routeur ne connaitra que les routes internes à sa zone. Les autres seront remplacées par une route par défaut.

Voyons cela pour la zone 50 :

R2(config)#router ospf 1
R2(config-router)#area 50 stub no-summary

R5(config)#router ospf 1
R5(config-router)#area 50 stub

Vérifions la table de routage :

Parfait, il ne reste plus que les / la route interne.

Un petit coup d’œil à la base de données pour être sûr :

6)     Not So Stubby Area 

 Pour ce type de zone, réutilisons la zone 40.

Mais avant toutes choses, retirons la configuration actuelle :

Vous pouvez aussi essayer de conserver la configuration Stub puis de configurer la redistribution. Un message d’erreur vous dira qu’il n’est pas possible de configurer la redistribution dans une zone Stub (voir article précédent).

R4(config)#router ospf 1
R4(config-router)#no area 40 stub

R2(config)#router ospf 1
R2(config-router)#no area 40 stub

Puis, ajoutons des routes statiques sur R4 :

R4(config)#ip route 172.18.0.0 255.255.255.0 Null 0
R4(config)#ip route 172.18.1.0 255.255.255.0 Null 0
R4(config)#ip route 172.18.2.0 255.255.255.0 Null 0
R4(config)#ip route 172.18.3.0 255.255.255.0 Null 0

Mettons en place la redistribution :

R4(config)#router ospf 1
R4(config-router)#redistribute static subnets metric 200 metric-type 1

 Si vous consultez les tables de routage des autres routeurs, vous verrez que les routes ont été redistribuées.

 Passons maintenant cette zone en Not So Stubby :

R2(config)#router ospf 1
R2(config-router)#area 40 nssa

R4(config)#router ospf 1
R4(config-router)#area 40 nssa

Normalement, à ce stade, R4 devrait être capable de redistribuer les routes 172.18.0.0 /22 vers le reste de la topologie.

Vérifions sur R3 :

R3 a bien connaissance des routes !

Mais est ce que R4 fonctionne toujours comme un routeur Stub (c’est-à-dire qu’il ne reçoit pas les routes redistribuée) ?

En effet, il ne possède pas les routes redistribuées (cad 172.16.0.0 /22).

On garde les avantages du mode Stub, tout en permettant la redistribution de route depuis l’intérieure de la zone.

Parfait non ?

Presque. Vous n’avez rien remarqué dans la table de routage de R4 ?

Oui, il manque bien la route par défaut !

R4 sera donc incapable de joindre les réseaux 172.16.0.0 /22.

En mode NSS, R2 n’annonce pas de route par défaut.

Pas de soucis, il y a une solution :

R2(config)#router ospf 1
R2(config-router)#area 40 nssa default-information-originate

 Retour sur R4 :

Et voilà !

R4 et en mode Stubb (ou plutôt NSS) et permet la redistribution de route.

 Si vous êtes curieux, je vous invite à aller consulter les bases de données OSPF des différents routeurs, et voir quels types de LSA elles contiennent.

 7)     Totally Stubby Not So Stubby Area 

Le principe est le même que pour le mode NSS.

Ici nous gardons les avantages du mode Totally Stubby (pas de LSA de types 3, 4 et 5), mais nous avons la possibilité de redistribuer des routes.

Il n’y a qu’une seule commande à changer.

(Bien entendu, il faut d’abord annuler la configuration précédente)

R2(config-router)#area 40 nssa no-summary

Voici à quoi ressemble alors la table de routage de R4 :

8)     Conclusion

 Et bien voilà, nous avons vu comment mettre en place une configuration OSPF avec des zones.

Nous avons d’abord vu l’utilité d’un Virtual Link.

Pour rappel, voici sa configuration :

R3(config)#router ospf 1
R3(config-router)#area 60 virtual-link 6.6.6.6

R6(config)#router ospf 1
R6(config-router)#area 60 virtual-link 3.3.3.3

Ensuite, nous avons vu comment configurer une Stubby Area :

R2(config)#router ospf 1
R2(config-router)#area 40 stub

R4(config)#router ospf 1
R4(config-router)#area 40 stub

Puis nous avons vu la Totally Stubby Area

R2(config)#router ospf 1
R2(config-router)#area 50 stub no-summary

R5(config)#router ospf 1
R5(config-router)#area 50 stub

Par après, nous avons vu la Not So Stubby Area :

R2(config)#router ospf 1
R2(config-router)#area 40 nssa
R2(config-router)#area 40 nssa default-information-originate

R4(config)#router ospf 1
R4(config-router)#area 40 nssa

Et enfin, la Totally Stubby Not So Stubby Area :

R2(config-router)#area 40 nssa no-summary