Deux problèmes différents, un même outil — envoyer le trafic vers un next hop spécifique selon sa provenance ou son application, plutôt que ce que la table de routage choisirait autrement — correspondance au niveau interface par source et par application, une redirection à l'échelle du réseau, des commandes de vérification, et où s'arrête le routage basé sur les stratégies et où commence la route-policy.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
La table de routage répond à « comment atteindre cette destination ». Le routage basé sur les stratégies répond à une autre question : selon qui demande et ce qui est demandé, quelle direction ce trafic précis doit-il réellement prendre.
Une table de routage normale prend une décision par destination, et chaque hôte envoyant vers cette destination obtient la même réponse. Cela convient jusqu'au moment où ça ne convient plus — quand une source interne a besoin d'un chemin précis quelle que soit la destination indiquée par la table de routage, ou qu'une application a besoin de son propre chemin pour des raisons de latence ou de coût pendant que tout le reste emprunte la route par défaut. Le routage basé sur les stratégies (PBR) existe précisément pour combler cet écart : il fait d'abord correspondre le trafic — par adresse source, protocole, port, tout ce qu'un classificateur de trafic peut exprimer — et ne décide du next hop qu'ensuite, en amont et indépendamment de la décision propre de la table de routage.
Voici deux configurations concrètes : faire correspondre le trafic sur une seule interface entrante par adresse source et par application (HTTP), chacune redirigée vers un next hop différent ; et une stratégie à l'échelle du réseau qui redirige le trafic d'une paire source-destination vers un routeur précis, quel que soit le choix que ferait autrement la table de routage normale — construite ici par OSPF. Si votre scénario ressemble davantage à envoyer le trafic de chaque liaison Internet sur sa propre liaison avec basculement automatique, c'est un problème connexe mais différent — voir notre note sur la configuration de basculement double WAN et de partage de charge pour cela.
Un routeur, plusieurs interfaces, et deux règles de correspondance indépendantes décidant quels paquets sont redirigés avant même que la table de routage ne les voie.
Les légendes du schéma restent en anglais pour la clarté technique.
Classificateurs de trafic et cibles de redirection
| Correspondance | Next hop de redirection | Précédence |
|---|---|---|
| ACL 3005 — source 10.2.1.1/32 | 10.5.1.2 | 5 — évalué en premier |
| ACL 3006 — destination-port www (HTTP) | 10.3.1.2 | 10 |
| Unmatched traffic | 10.4.1.2 | Table de routage normale — préférence de route statique 40 |
Cinq étapes : définir la correspondance, l'associer à une redirection, lier le tout dans une seule stratégie avec précédence, l'appliquer à la bonne interface et direction, et s'assurer que le trafic non correspondant a toujours une destination.
#
sysname Router
#
acl number 3005
rule 0 permit ip source 10.2.1.1 0
#
acl number 3006
rule 0 permit tcp destination-port eq www
#
traffic classifier 10.2.1.1 operator or
if-match acl 3005
traffic classifier www operator or
if-match acl 3006
#
traffic behavior 10.2.1.1
redirect ip-nexthop 10.5.1.2
traffic behavior www
redirect ip-nexthop 10.3.1.2
#
traffic policy pbr
classifier 10.2.1.1 behavior 10.2.1.1 precedence 5
classifier www behavior www precedence 10
#
interface GigabitEthernet2/0/0
ip address 10.1.2.1 255.255.255.0
traffic-policy pbr inbound
#
interface GigabitEthernet2/0/1
ip address 10.3.1.1 255.255.255.0
#
interface GigabitEthernet2/0/2
ip address 10.4.1.1 255.255.255.0
#
interface GigabitEthernet2/0/3
ip address 10.5.1.1 255.255.255.0
#
ip route-static 192.168.1.0 24 10.3.1.2
ip route-static 192.168.1.0 24 10.4.1.2 preference 40
ip route-static 192.168.1.0 24 10.5.1.2
#
returnTrois routes statiques atteignent délibérément le même préfixe 192.168.1.0/24 — 10.4.1.2 porte la préférence la plus basse (40) et l'emporte donc dans la sélection propre de la table de routage pour le trafic non correspondant, tandis que 10.3.1.2 et 10.5.1.2 restent joignables uniquement pour que les next hops redirigés par le PBR soient valides.
Un réseau différent et plus grand illustre cela à plus grande échelle : RouterA, RouterB et RouterC partagent des routes via OSPF, et la table de routage seule enverrait le trafic de 10.0.2.0/24 vers 10.0.0.0/24 via RouterC. Une stratégie de trafic sur RouterA redirige ce seul flux vers RouterB à la place.
#
acl number 3001
rule 5 permit ip source 10.0.2.0 0.0.0.255 destination 10.0.0.0 0.0.0.255
#
traffic classifier rdt operator or
if-match acl 3001
#
traffic behavior rdt
redirect ip-nexthop 10.181.10.2
#
traffic policy rdt
classifier rdt behavior rdt
#
interface GigabitEthernet1/0/0
ip address 10.181.20.1 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.181.10.1 255.255.255.0
#
interface GigabitEthernet3/0/0
ip address 10.0.2.1 255.255.255.0
traffic-policy rdt inbound
#
ospf 1
area 0.0.0.0
network 10.0.2.0 0.0.0.255
network 10.181.20.0 0.0.0.255
network 10.181.10.0 0.0.0.255
#
return#
interface GigabitEthernet1/0/0
ip address 10.181.10.2 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.184.10.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 10.181.10.0 0.0.0.255
network 10.184.10.0 0.0.0.255
#
return#
interface GigabitEthernet1/0/0
ip address 10.181.20.2 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.184.10.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 10.184.10.0 0.0.0.255
network 10.181.20.0 0.0.0.255
network 10.0.0.0 0.0.0.255
#
returnMalgré la similitude du nom, route-policy est un mécanisme totalement différent opérant sur un plan différent. Route-policy (configurée avec route-policy ... permit/deny node ...) filtre et modifie les routes elles-mêmes lorsqu'elles sont apprises ou annoncées entre protocoles de routage — par exemple en appliquant un attribut local-preference ou community aux routes BGP, ou en contrôlant quelles routes sont redistribuées d'un protocole à un autre. Le routage basé sur les stratégies, en revanche, ne touche jamais à la table de routage ni aux routes qu'elle contient — il intercepte des paquets déjà arrivés sur une interface et les transmet vers un next hop précis selon un classificateur de trafic, quoi que dise la table de routage. Une route-policy change quelles routes existent et comment elles sont étiquetées ; une stratégie de trafic avec PBR change où vont réellement des paquets déjà décidés. Un détail à emprunter à la configuration de route-policy : une route-policy a besoin d'un nœud permit explicite et vide à la fin, sinon les routes qui n'ont correspondu à aucun nœud précédent sont silencieusement filtrées — un mode de défaillance différent du comportement propre du PBR face au trafic non correspondant, mais un réflexe similaire à vérifier.
Vérifiez le classificateur, le comportement et la stratégie indépendamment, puis confirmez avec une trace que le trafic sort effectivement par le next hop redirigé.
<Host> tracert -a 10.0.2.1 10.0.0.1
1 10.181.20.1 3 ms 2 ms 1 ms
2 10.181.10.2 4 ms 3 ms 3 ms
3 10.184.10.1 5 ms 4 ms 4 ms
4 10.0.0.1 6 ms 5 ms 5 msLe deuxième saut (10.181.10.2) est l'adresse de RouterB — confirmant que la stratégie de trafic a redirigé ce flux là plutôt que par le chemin préféré par OSPF via RouterC. Vos propres adresses de saut et temps différeront ; ce qui compte, c'est le routeur par lequel passe la trace.
Celles qui transforment une redirection fonctionnelle en trafic qui part silencieusement dans la mauvaise direction, ou nulle part du tout.
SYMPTÔMEUn trafic qui ne correspond clairement à aucun classificateur de la stratégie finit quand même par être abandonné ou mal acheminé, au lieu de simplement suivre la table de routage normale.
CAUSEAppliquer traffic-policy en entrée sur une interface ne crée pas de refus par défaut comme le fait une certaine logique d'ACL — mais si la route normale de l'interface vers cette destination est elle-même absente ou erronée, il n'y a rien de sensé vers quoi le trafic non correspondant peut se rabattre. Le PBR ne décide que pour ce qu'il fait explicitement correspondre ; tout le reste a besoin d'une entrée de table de routage fonctionnelle au départ.
SOLUTIONConfirmez l'accessibilité normale (une route dans display ip routing-table) vers la destination avant de superposer le PBR — le PBR remplace le next hop du trafic correspondant, il ne crée pas d'accessibilité à partir de rien.
SYMPTÔMEUne route statique vers l'adresse du next hop de redirection existe, mais display ip routing-table montre une route complètement différente l'emportant pour ce même préfixe.
CAUSEredirect ip-nexthop transmet directement les paquets correspondants vers cette adresse — cela n'exige pas que la route de cette adresse soit le meilleur chemin propre de la table de routage. Dans la configuration ici, trois routes statiques vers le même préfixe coexistent délibérément : l'une l'emporte dans la sélection propre de la table de routage (valeur de préférence la plus basse) pour le trafic non correspondant, tandis que les deux autres existent uniquement pour que les next hops redirigés par le PBR soient joignables.
SOLUTIONNe supposez pas que le next hop de redirection doit « gagner » une quelconque comparaison de routes — vérifiez son accessibilité directement (pingez-le, ou vérifiez la route statique spécifique), pas en regardant quelle route la table préfère actuellement.
SYMPTÔMEUn paquet qui devrait clairement toucher la règle la plus spécifique — par exemple, celle correspondant à une adresse source précise — se retrouve à la place redirigé par la règle plus large basée sur l'application, ou inversement.
CAUSEUne stratégie de trafic évalue ses paires classificateur-comportement dans l'ordre de précédence — le numéro de précédence le plus bas en premier — et s'arrête à la première correspondance, de la même manière qu'une ACL s'arrête à sa première règle correspondante. Si la règle plus générale a un numéro de précédence plus bas que la plus spécifique, la règle générale l'emporte même quand les deux pourraient correspondre.
SOLUTIONDonnez à la correspondance la plus spécifique le numéro de précédence le plus bas, exactement comme dans la configuration de travail — la correspondance par adresse source est à la précédence 5, avant la correspondance applicative à la précédence 10.
SYMPTÔMEUn trafic qui correspond clairement à l'ACL utilisée dans un classificateur n'est toujours pas redirigé.
CAUSELa stratégie est liée avec une direction — en entrée sur une interface précise. Elle n'évalue le trafic que lorsqu'il arrive sur cette interface exacte dans cette direction ; un trafic provenant d'ailleurs sur le routeur, ou arrivant sur une autre interface, ne passe jamais du tout par cette stratégie.
SOLUTIONConfirmez par quelle interface physique le trafic en question entre réellement, et assurez-vous que c'est bien cette interface — et cette direction — à laquelle la traffic-policy est appliquée, pas n'importe quelle interface du chemin.
SYMPTÔMEQuelqu'un essaie d'orienter le trafic d'une source précise vers un next hop précis en modifiant une route-policy appliquée à un protocole de routage, et cela ne fait rien pour ce trafic.
CAUSERoute-policy façonne quelles routes existent et leurs attributs dans le plan de contrôle — elle n'a aucune notion de « paquets de cette source précise », seulement de routes et de leurs attributs tels qu'échangés par les protocoles. Orienter le trafic d'une source vers un next hop précis, quelle que soit la meilleure route normale de la destination, est une décision du plan de données, par paquet — c'est à cela que sert le PBR.
SOLUTIONUtilisez le PBR lorsque le facteur décisif concerne le paquet lui-même (source, protocole, port) ; utilisez route-policy lorsque le facteur décisif concerne la route (quel protocole l'a apprise, ses attributs, si elle doit être redistribuée).
Cette note s'appuie sur deux configurations concrètes : du PBR au niveau interface faisant correspondre par adresse source et par port de destination HTTP avec deux cibles de redirection indépendantes, et une redirection PBR à l'échelle du réseau superposée à un réseau routé par OSPF. Elle ne couvre pas le PBR basé sur la longueur des paquets ou le marquage DSCP/précédence, la répartition de charge du trafic entre plusieurs next hops de redirection, ni l'application du routage basé sur les stratégies en sortie plutôt qu'en entrée. Elle ne traite pas non plus route-policy en profondeur — route-policy façonne des routes, pas des paquets, et mérite son propre traitement ; ce qui figure ici n'est que la distinction nécessaire pour choisir le bon outil.
Tirées des mêmes cas de configuration sur lesquels s'appuie cette note.
Non — il ne s'applique en amont que pour le trafic correspondant. Tout ce qu'un classificateur de trafic ne fait pas correspondre explicitement retombe sur la table de routage normale, exactement comme si le PBR n'était pas configuré du tout.
Oui — tout ce qu'une ACL (ou un classificateur de trafic plus complexe) peut exprimer est permis : source, destination, protocole, plages de ports, et plus. Les deux exemples ici — adresse source et port de destination HTTP — sont simplement ceux qu'illustre la configuration concrète sous-jacente.
Route-policy agit sur les routes elles-mêmes — filtrant ou étiquetant ce qu'un protocole de routage apprend ou annonce. Le PBR agit sur des paquets déjà arrivés — les redirigeant vers un next hop précis selon un classificateur de trafic, sans changer aucune route ni attribut de route. Voir la comparaison dans la section de configuration ci-dessus pour la distinction complète.
C'est lié mais distinct. Cela se construit généralement avec des routes statiques à préférence égale ou inégale (pour le partage de charge ou le primaire/secours) plutôt qu'une redirection par stratégie de trafic — voir notre note sur la configuration de basculement double WAN et de partage de charge pour cette conception précise.
Oui — redirect ip-nexthop a quand même besoin que cette adresse de next hop soit réellement joignable ; le PBR décide qu'un paquet correspondant y va, mais il ne fabrique pas d'accessibilité. Comme le montre le piège 2 ci-dessus, cette route n'a pas besoin d'être le chemin préféré de la table de routage pour ce préfixe, elle doit juste exister.
Le mot-clé de configuration prend en charge les deux directions, mais l'entrée sur l'interface où le trafic provient réellement de la source que vous mettez en correspondance est de loin le placement le plus courant et le plus prévisible — il capte le trafic au point le plus précoce, avant qu'une autre décision de transfert n'ait la chance de s'appliquer.
Dites-nous quel trafic — par source, application ou liaison — doit aller où, et nous vous aiderons à rédiger correctement le classificateur et l'ordre de précédence.