NSX-T: Deterministic Traffic on VLAN-backed Segments?

NSX-T: Deterministic Traffic on VLAN-backed Segments?

Can data on VLAN-Backed Segments be deterministic?

The ask?

A few weeks ago, a fellow VMware enthusiast reached out to me with a question that I did not have an immediate answer to. Does NSX-T support deterministic traffic on VLAN-backed segments?

Configuring named-teaming and attaching the policy is quite straight forward, but the end-result of completing this may not be the expected outcome. More to the point, I’ve really only used this on segments that are attached to Tier-0 uplinks, and their respective N-VDS on an Edge node. It is normally configured to ensure the VLAN or point to point link for a respective BGP peer is sent to the upstream peer that requires it, and not any other. Consider the diagram below.

In the image above, we can see the Tier-0 (SR) instantiated on an Egde node has two uplinks. The logical link between the Tier-0 SR and the VDS is plumbed together with VLAN-backed segments, and the VDS

The Testing Environment

This section will highlight the testing environment and ensure readers are across what is configured, and how.

Named Teaming Policy

To start, let’s create a named teaming policy. Navigate to System -> Fabric -> Profiles, edit the host uplink profile you have attached to your host transport nodes.

I have added a line under the default teaming, the policy (vlan63), is configured with Failover Order, and only one active uplink. I do not want the traffic to fail over to the secondary uplink in this case.

Next, we need to attach this policy to the VLAN transport zone that the hosts are a part of. If you are not sure which transport zone this is navigate to System -> Fabric -> Nodes, configure one of the hosts and you will see it listed (if it has one attached).

Once identified, navigate to System -> Fabric -> Transport Zones, edit the VLAN transport zone, in this case ‘nsx-vlan-transportzone’. In the Uplink Teaming Policy Names section, enter the name of the teaming policy you created earlier, in this case it is ‘vlan63′. Click save once complete.

Create a VLAN-Backed segment and assign the policy

Navigate to Networking -> Segments -> Click on Add Segment. Give the segment a name, no connected gateway, select the VLAN transport zone, tag the VLAN, and assign the named teaming policy. Click save once complete.

This creates the segment or portgroup in vCenter.

The next section discusses the issue and how to test it.

Testing Teaming Policy for VDS attached VLAN-backed Segments

Ordinarily, a VDS portgroup that has teaming and failover configured displays this in the UI. Refer to the example below.

The portgroup created in vCenter called ‘teaming-test’ has an active-standby uplink configuration.

Selecting this portgroup in topology view shows very clearly, there is one active uplink.

Now, let’s compare that to the VLAN-backed segment vlan63. You would ideally expect the same result, as the teaming policy was created.

Notice how the UI shows both uplinks as being active, this could easily cause confusion.. does this mean the named teaming policy isn’t working? The answer is no, it is working… but let’s test it!

Before we can test it, you will need to provision workload and attach it to the segment in vCenter.

The VM below has been attached to the segment.

We can see it has connectivity.

Now, we need to simulate an uplink failure to uplink1 on the host this VM resides on. But first, lets make sure the uplink being used for the VM is uplink1 (vmnic4). SSH onto the host with the VM, type esxtop, then press n. The image below shows the blueseg VM’s vNIC sitting on vmnic4.

Let’s fail that vmnic, if both interfaces were truly active or even active-standby, we should see no or minimal connectivity loss and the eth0 interface float over to vmnic5 (uplink2).

Back onto the terminal session type ‘esxcli network nic down -n vmnic4′.

Let’s check the pings from the VM again. Notice the black space, I get it’s hard to make out, but the pings have stopped. This indicates to me that the interface of the VM has not failed over to vmnic5.

To further check this, rerun the esxtop command and have a look at the state of the VM’s interface. Notice, it is stuck in fallback, it has not failed over and is waiting for the nic to come back up.

Conclusion

Hopefully this article has demonstrated that NSX-T does support deterministic traffic on VLAN-backed segments. One thing to keep in mind is that the vCenter UI does not reflect the policy applied to the segment in NSX-T. Any NSX-T segments created and presented to vCenter are shown as active across all uplinks.

I cover deep NSX-T logical routing configuration and packet walks in my latest book: NSX-T Logical Routing.

Related