Ping du routeur ou hôte VLAN : quelle politique PBR s’applique ?

VLAN 10 doit utiliser le VPN et VLAN 20 le WAN, donc le premier test est un ping du routeur avec l’adresse d’interface de VLAN 10 comme source. Il réussit, les compteurs du route-map augmentent et tout le monde conclut que la conception fonctionne. Ce n’est pas le cas. Ce ping a été généré localement, et le trafic généré localement atteint un point d’attache de politique différent d’un paquet arrivant sur l’interface VLAN.

Trois conditions décident de la politique que vous testez réellement : où le paquet est créé, où il entre et à quoi il correspond.

L’endroit où le paquet entre décide de la politique qui s’exécute

Un route-map d’interface attaché avec ip policy route-map s’applique aux paquets arrivant sur cette interface, comme le guide PBR IOS XE décrit. Un hôte de VLAN 10 envoie sa requête, la trame arrive sur la sous-interface VLAN et le routeur évalue la politique ici. Le paquet propre du routeur n’arrive jamais sur cette interface, car il est né dans le routeur.

Choisir l’adresse VLAN comme source change l’en-tête. Cela ne change pas l’origine.

Pourquoi le ping avec adresse source n’est toujours pas l’hôte

L’adresse source compte pour une correspondance ACL, et c’est exactement ce qui rend le test si convaincant. Le paquet correspond à une clause de source, les compteurs augmentent et la sortie semble correcte. Ce que le test ne peut pas montrer, c’est l’interface d’entrée, le contexte d’arrivée ou si un paquet d’hôte prendrait la même branche.

Un test qui reproduit la correspondance mais pas le contexte prouve la moitié de la conception, et c’est avec une demi-preuve que les conceptions partent avec la mauvaise politique attachée.

Quand une politique locale est la bonne réponse

Cisco documente ip local policy route-map pour le trafic que le routeur génère lui-même. C’est un périmètre distinct, et c’est le bon outil lorsque l’exigence concerne réellement le trafic propre du routeur. Ce n’est pas une étape manquante dont chaque conception de pilotage VLAN a besoin. Une correspondance large y affecte aussi les connexions de gestion et de support, ce qui est un changement bien plus important qu’il n’y paraît.

Le TCP généré localement a une condition préalable supplémentaire : il lui faut une entrée de destination applicable dans la table de routage, même lorsque la politique choisit un autre chemin. Un résultat ICMP ne prouve pas le même comportement pour TCP.

Ce qu’il faut tester sur l’hôte à la place

Exécutez le test depuis un hôte autorisé dans VLAN 10, avec sa vraie adresse source, sa destination, son protocole et son port. Consignez l’interface d’entrée et la correspondance du route-map à côté du résultat, afin que la preuve nomme la politique qui s’est exécutée. Répétez ensuite pour un hôte de VLAN 20 et confirmez qu’il prend l’autre chemin.

Les deux chemins ont besoin de next hops fonctionnels, d’une joignabilité de retour et, le cas échéant, d’une couverture VPN. PBR choisit une décision de transfert ; il ne crée pas le service distant et n’accorde pas l’autorisation à l’application.

Ce que le résultat peut et ne peut pas prouver

Un flux d’hôte réussi prouve que la politique correspondait et que le chemin choisi fonctionnait à ce moment-là. Il ne prouve pas que le trafic propre du routeur est piloté, et il ne prouve pas que l’application était autorisée, car ce sont des questions différentes avec des preuves différentes.

Gardez le ping dans le dossier comme preuve d’un paquet local. Ensuite, allez chercher la preuve du flux de l’hôte, plutôt que d’élargir le périmètre de la politique jusqu’à ce que les deux tests se ressemblent.