There are multiple scenarios in which traceflow is useful.
Before you begin
Traceflow operations require communication among vCenter, NSX Manager, the NSX Controller cluster and the netcpa user world agents on the hosts.
For Traceflow to work as expected, make sure that the controller cluster is connected and in healthy state.
About this task
Traceflow is useful in the following scenarios:
Troubleshooting network failures to see the exact path that traffic takes
Performance monitoring to see link utilization
Network planning to see how a network will behave when it is in production
- In vCenter Web Client, navigate to Home > Networking & Security > Traceflow.
- Select the traffic type: Unicast, broadcast, or multicast.
- Select the source VM vNIC.
If the VM is managed in the same vCenter Server where you are running the traceflow, you can select the VM and vNIC from a list.
- For a unicast traceflow, enter the destination vNIC information.
The destination can be a vNIC of any device in the NSX overlay or underlay, such as a host, a VM, a logical router, or an edge services gateway. If the destination is a VM that is running VMware Tools and is managed in the same vCenter Server from which you are running the traceflow, you can select the VM and vNIC from a list.
Otherwise, you must enter the destination IP address (and the MAC address for a unicast Layer 2 traceflow). You can gather this information from the device itself in the device console or in an SSH session. For example, if it is a Linux VM, you can get its IP and MAC address by running the ifconfig command in the Linux terminal. For a logical router or edge services gateway, you can gather the information from the show interface CLI command.
- For a Layer 2 broadcast traceflow, enter the subnet prefix length.
The packet is switched based on MAC address only. The destination MAC address is FF:FF:FF:FF:FF:FF.
Both the source and destination IP addresses are required to make the IP packet valid for firewall inspection.
- For a Layer 2 multicast traceflow, enter the multicast group address.
The packet is switched based on MAC address only.
Both the source and destination IP addresses are required to make the IP packet valid. In the case of multicast, the MAC address is deduced from the IP address.
- Configure other required and optional settings.
- Click Trace.
The following example shows a Layer 2 traceflow involving two VMs that are running on a single ESXi host. The two VMs are connected to a single logical switch.
The following example shows a Layer 2 traceflow involving two VMs that are running on two different ESXi hosts. The two VMs are connected to a single logical switch.
The following example shows a Layer 3 traceflow. The two VMs are connected to two different logical switches that are separated by a logical router.
The following example shows a broadcast traceflow in a deployment that has three VMs connected to a single logical switch. Two of the VMs are on one host (esx-01a), and the third is on another host (esx-02a). The broadcast is sent from one of the VMs on host 192.168.210.53.
The following example shows what happens when multicast traffic is sent in a deployment that has multicast configured.
The following example shows what happens when a traceflow is dropped because of a distributed firewall rule that blocks ICMP traffic sent to the destination address. Notice that the traffic never leaves the original host, even though the destination VM is on another host.
The following example shows what happens when a traceflow destination is on the other side of an edge services gateway, such as an IP address on the Internet or any internal destination that must be routed through the edge services gateway. The traceflow is not allowed, by design, because traceflow is supported for destinations that are either on the same subnet or are reachable through distributed logical routers (DLRs).
The following example shows what happens when the traceflow destination is a VM that is on another subnet and is powered off.