Policy Based Routing – Rediriger le traffic en fonction de l’adresse IP source

Cet article présente une configuration simple qui permet de rediriger le traffic venant d’un subnet précis vers un next-hop précis. Ce genre de configuration peut se révéler utile lorsqu’un routeur dispose de deux réseaux de « sortie » afin d’affiner ou de contourner le comportement d’un protocole de routage…

Topologie utilisée pour l’exemple

Dans cette topologie, on a deux sites (POD1 et POD2) chacun ayant son propre réseau LAN et interconnectés par une double liaison. D’une part par une liaison sérielle directe avec une bande passante configurée de 128kbits/s et d’autre part une liaison Frame-Relay 64kbits/s.

L’ensemble des routeurs sont configurés pour utiliser EIGRP sur l’AS 100. Les routeurs ont échangé leurs topologies et disposent de toutes les routes.

Etat des lieux avant la redirection du traffic

EIGRP, par défaut calcule la métrique de ses route en fonction de la bande passante et du délai configurés sur les interfaces.

Par défaut sur une interface sérielle le délai est de 20000µs.

Ce qui fera la différence entre la route entre les POD1 et POD2 passant par la liaison sérielle et celle passant par le Frame-Relay, ce sera donc la bande passante. En toute logique la liaison sérielle sera préférée (métrique plus faible).

P1R1>sh ip eigrp 100 topology
IP-EIGRP Topology Table for AS(100)/ID(192.168.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 192.168.1.32/28, 1 successors, FD is 409600
    via 192.168.1.2 (409600/128256), FastEthernet0/0
P 192.168.2.32/28, 1 successors, FD is 20665600
    via 172.16.0.2 (20665600/409600), Serial0/1
    via 172.16.12.2 (40665600/409600), Serial0/0
P 192.168.1.0/28, 1 successors, FD is 281600
    via Connected, FastEthernet0/0
P 192.168.2.0/28, 1 successors, FD is 20537600
    via 172.16.0.2 (20537600/281600), Serial0/1
    via 172.16.12.2 (40537600/281600), Serial0/0
P 192.168.1.16/28, 1 successors, FD is 409600
    via 192.168.1.2 (409600/128256), FastEthernet0/0
P 192.168.2.16/28, 1 successors, FD is 20665600
    via 172.16.0.2 (20665600/409600), Serial0/1
    via 172.16.12.2 (40665600/409600), Serial0/0
P 172.16.12.0/30, 1 successors, FD is 40512000
    via Connected, Serial0/0
P 172.16.0.0/30, 1 successors, FD is 20512000
    via Connected, Serial0/1
P1R1>

La table de topologie EIGRP sur P1R1 confirme cette logique. La « Feasible Distance » (autement dit la métrique) des routes passant par le Frame-Relay (en brun) est nettement supérieure à celles passant par la laison sérielle (en vert).

Donc, sauf configuration particulière, le traffic entre le POD1 et le POD2 passera toujours à travers la liaison sérielle.

Configuration de la redirection du réseau de l’interface Loopback1 de P1R2

La première chose à faire est de créer, sur P1R1, une access-list qui correspond au subnet en question.

P1R1(config)# access-list 1 permit 192.168.1.32 0.0.0.15

Ensuite, on crée une « route-map », dans laquelle on va définir que le traffic correspondant à l’ACL 1 soit redirigé vers le Frame-Relay (on va forcer le next-hop, dans ce cas, ce sera 172.16.12.2).

P1R1(config)# route-map RMAP-P1R1-L1 permit 10
P1R1(config-route-map)# match ip address 1
P1R1(config-route-map)# set ip next-hop 172.16.12.2

Notes:

  • RMAP-P1R1-L1 est simplement le nom donnée à la route-map
  • match ip address 1 fait référence à l’access-list 1 précédemment configurée.

Il reste maintenant à appliquer cette règle. Pour cela, on doit l’appliquer sur l’interface par laquelle arrive le traffic provenant du subnet en question. Dans le cas présent, l’interface Fa0/0 de P1R1.

P1R1(config-if)# ip policy route-map RMAP-P1R1-L1

Reste maintenant à vérifier le fonctionnement. Pour ça rien de tel que « traceroute » en mode privilégié à partir de P1R2, histoire de spécifier l’interface « source ».

P1R2# traceroute
Protocol [ip]:
Target IP address: 192.168.2.33
Source address: 192.168.1.33
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 192.168.2.33
1 192.168.1.1 60 msec 56 msec 64 msec
2 172.16.12.2 68 msec 72 msec 48 msec
3 192.168.2.2 92 msec 108 msec 162msec
P1R2#

Afin de s’assurer du bon fonctionnement, on peut également vérifier que le reste du traffic passe bien toujours par la liaison sérielle.

P1R2#traceroute
Protocol [ip]:
Target IP address: 192.168.2.33
Source address: 192.168.1.2
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 192.168.2.33
1 192.168.1.1 48 msec 64 msec 16 msec
2 172.16.0.2 40 msec 60 msec 40 msec
3 192.168.2.2 76 msec 68 msec *
P1R2#

Remarques

  • L’utilisation des route-maps est ici assez simpliste. il est possible d’être plus précis dans la redirection du traffic. Pour cela il faut utiliser des access-list étendues qui permettent de jouer sur les adresses IP de destinations et également sur les numéros de ports. On peut ainsi par exemple rediger tous le traffic SMTP (port de destination TCP 25) vers un next-hop précis et laisser le reste du traffic transiter normalement.
  • Dans le cadre d’une route-map, l’access-list joue un rôle un peu particulier. Le traffic correspondant à une clause « permit » de l’access-list sera traité dans la route-map. Le reste sera ignoré et transitera « normalement ».
  • Dans une route-map on peut également définir une succession de règles, ordonnées par un numéro de séquence. Le principe étant que la première règle qui s’applique au paquet (par ordre de séquence) est utilisée, les autres seront ignorées. Il convient donc dans ce cas d’ordonner les règles de la plus spécifique à la plus générale.
  • IMPORTANT: Une route-map ne modifie en rien la table de routage. Par contre, elle défini si le routeur doit où non traiter les paquets de manière spécifique.

0 Comments on “Policy Based Routing – Rediriger le traffic en fonction de l’adresse IP source