Traceflow IP : tracer précisément le chemin d'un paquet dans NSX
Traceflow IP est l'outil intégré à NSX qui permet d'injecter un paquet synthétique directement dans le plan de données et de suivre son parcours réel à travers tout le réseau virtuel. On voit exactement quels composants le traitent, s'il passe ou s'il se fait dropper, et souvent par quelle règle. C'est devenu un réflexe pour pas mal d'équipes qui gèrent des environnements virtualisés un peu complexes.
Le truc, c'est qu'on n'est plus limité à un ping qui traverse sans rien dire sur ce qui se passe à l'intérieur. Là, on a une vraie vue interne.
Comment Traceflow IP observe vraiment le flux
Le principe est assez malin. Au lieu de partir de la VM invitée comme un ping classique, Traceflow crée le paquet au niveau du nœud de transport. Ce paquet est marqué spécifiquement. Chaque élément de la stack NSX — commutateur logique, routeur distribué, Distributed Firewall, Edge — le reconnaît et renvoie une observation au NSX Manager.
Le paquet n'arrive généralement jamais à la VM de destination. On observe juste le chemin qu'il aurait pris. Ça évite de perturber quoi que ce soit en production. Et ça marche sur IPv4 comme sur IPv6.
On peut simuler de la monodiffusion, de la multidiffusion ou même de la diffusion (avec quelques conditions pour cette dernière). Les protocoles supportés couvrent ICMP, TCP, UDP, mais aussi DHCP, DNS ou ARP/NDP selon ce qu'on veut tester.
Pourquoi c'est très différent de ping ou traceroute
Un ping, ça reste entre les systèmes d'exploitation des VMs. Il traverse le réseau, mais il ne vous raconte rien sur les règles de micro-segmentation, les NAT ou les décisions prises par le DFW. Traceroute, lui, s'arrête souvent aux routeurs physiques avec ses messages ICMP Time Exceeded.
Traceflow, c'est autre chose. Il reste dans l'overlay, il voit tout ce qui se passe dans NSX et il vous le montre de façon graphique avec une table d'observations en dessous. Quand un paquet se fait dropper, vous avez souvent l'ID de la règle responsable directement. C'est concret et ça fait gagner un temps fou.
Lancer un traceflow ip depuis NSX Manager
C'est assez direct. On se connecte au NSX Manager, on va dans Planifier et dépanner puis Traceflow. On choisit IPv4 ou IPv6, le type de trafic (monodiffusion dans 90 % des cas), la source (VM, port logique, liaison montante) et la destination (VM, port ou adresse IP/MAC).
Dans les options avancées, on peut ajuster la taille de la trame, le TTL, le protocole précis avec ses ports ou flags, et même mettre une charge utile custom. Un clic sur Trace et les observations reviennent en quelques secondes.
Pour la diffusion, il faut parfois indiquer une longueur de préfixe de sous-réseau, histoire que le paquet passe les contrôles pare-feu. C'est un détail, mais ça évite des échecs bêtes.
Les cas d'usage qui reviennent tout le temps
Le plus courant, c'est de vérifier pourquoi une VM ne parle plus à une autre. On lance le traceflow et on voit tout de suite si c'est une règle de pare-feu, un problème de routage ou un NAT qui foire.
Un usage qui devient de plus en plus fréquent : tester l'ingress depuis le réseau physique. On simule une IP externe qui arrive sur le Tier-0 et on regarde si elle traverse correctement jusqu'à la VM cible, en confirmant que le DFW et le routage sont alignés. Ça rassure avant d'ouvrir un nouveau flux.
On peut aussi isoler le domaine de faute. Si le traceflow affiche "Delivered" au niveau de l'uplink Edge, le problème est probablement après, dans le physique. Si ça bloque avant, on sait que c'est dans le virtuel. Ça évite les allers-retours inutiles entre équipes.
Et puis il y a les traductions NAT. Traceflow affiche clairement les hops où une SNAT ou DNAT s'applique, avec l'IP traduite et l'ID de règle. Pratique quand on a des VIP de load balancer ou des règles d'egress un peu tordues.
Lire les résultats sans se perdre
Les observations sont classées par hop. On voit le type (Injected, Received, Forwarded, Delivered ou Dropped) et le composant concerné. Quand c'est un drop, NSX indique souvent la raison et la règle. La vue graphique montre le chemin à travers les Tier-0, Tier-1, segments logiques et Edge. C'est assez lisible une fois qu'on a l'habitude.
Attention quand même avec le bridging : un paquet avec une MAC inconnue peut être envoyé vers le VLAN physique et marqué comme delivered sans qu'on ait la garantie qu'il arrive vraiment à destination.
Aller plus loin avec l'API
Si vous gérez beaucoup d'incidents ou que vous voulez automatiser un peu, Traceflow est accessible via l'API REST de NSX. On peut lancer des traces depuis un script, récupérer le JSON et l'envoyer dans un ticket ou un bot. Ça permet de donner aux équipes de support un outil simple pour diagnostiquer rapidement les problèmes de connectivité ou de règles qui bloquent.
Les limites qu'il faut avoir en tête
Traceflow s'arrête aux Edge. Il ne trace pas dans le réseau physique sous-jacent, parce que les équipements physiques ne comprennent pas les tags NSX. Pour les paquets broadcast, il faut bien configurer le préfixe de sous-réseau, sinon les contrôles RPF sur les Edge peuvent le rejeter (parfois il faut convertir l'IP source en IP réseau).
Dans certains environnements cloud managés, la multidiffusion et la diffusion ne sont pas supportées. Et bien sûr, tout repose sur une topologie NSX propre et des nœuds de transport bien vus par le Manager.
Au bout du compte, Traceflow IP reste un des outils les plus efficaces pour rendre les réseaux virtuels un peu plus lisibles. Une fois qu'on s'y est habitué, les méthodes à l'ancienne paraissent vraiment limitées. C'est rapide, c'est visuel, et ça donne des réponses actionnables direct. Dans un métier où chaque minute de diagnostic compte, ça change pas mal la donne.
