Blogroll

What’s new in NSX 6.2 – Traceflow

This is a post in the series – What’s new in 6.2? It covers off the new features of a pseudo-major NSX release.

Introducing Traceflow

Traceflow adds functionality to the Toolbox that NSX provides to help Operationalise the NSX Network Virtualisation platform. Traceflow allows the injection of varying types of packets into application topologies. As the name suggests traces the flow through the path. It collects observation of actions, hosts, relevant components, and their names. This is used to help administrators visualise a topology path.

Tracing within a Layer 2 domain

As an administrator using Traceflow it is possible to craft a packet with a variety of settings. As seen below I have picked a source and destination VM on a Logical Switch. This can be selected on Logical Switches in Unicast or Hybrid mode.

Here you can see that there is an ability to select protocol and then modify additional fields. I have chosen a TCP packet and a SRC/DST port of 80 for this example. My firewall rules ‘protecting’ my workloads are permit any any.

This matches App-01 Web Tier that are in a Security Group (matching on a Security Tag) to individual VM’s listed App01, App01, App02, App02. This rule allows all traffic. When the Traceflow is executed the following output is seen:

At first this looks rather busy. It is possible to identify the following information from the above figure:

SRC: Web01 NIC1 172.16.172.10

DST: App01 NIC1 172.167.172.12

Packet flow and order of operations

Objects between two points

These Virtual Machines are on a VXLAN Logical Segment. This allows administrators to provide Layer 2 connectivity between workloads independent of the underlying infrastructure.

The component name for Sequence 2 states Firewall (Rule 1005) is the Culprit. All the objects in the Component Name column are hyperlinked. This will reveal more information to the user about the object.

Drop details which are hyperlinked show Rule ID 1005 is the culprit as suspected. The reason is due to a FW_RULE.

If this is not a desired behaviour or a rule that should not be enforced on this workload the administrator can quickly, easily, and efficiently identify the rule and remediate accordingly.

Layer 3 Traces just got visible

Taking this mentality with security policies on the same Layer 2 domain it is possible to perform Traceflow across routed segments. In this example the administrator decides to

The difference between this Traceflow and the last one is that the Destination is an IP address. It is an ICMP trace. This is an address that is attached to the DLR. In this case this IP address is the Gateway IP for that subnet. It is local to all hosts in the transport zone the Logical Switch and DLR are assigned to. When the flow is executed the output below is seen:

Time to look at the steps occurring here to gain an insight into how the traffic is being processed:

Like before it is possible to understand the related objects from the Component Name hyperlink. Observation details below outline the Segment ID and Component Name. Very handy to know what VXLAN Numerical Identifier (VNI) is assigned to a Logical Switch.

Conclusion

Traceflow is a great addition to the tools within VMware NSX for vSphere. It is born out of a maturing platform and provides actionable information at an administrators fingertips. I personally like how I can correlate Firewall policies to where a packet stops. I also like the notion I can inject varying traffic types into my topologies very easily.