NSX for vSphere: Management Interface of Distributed Logical Router Control VM

This article has been re-published as a KB: http://kb.vmware.com/kb/2122060

NSX for vSphere: VXLAN Control Plane modes explained

NSX for vSphere supports three VXLAN Control Plane modes:

1. Multicast (described in Section 4 of RFC 7348);
2. Hybrid; and
3. Unicast.

None of these is “simply better” than others; each has it’s positive and negative sides. In this post, I’m covering how each mode works along with some of those negatives and positives, to hopefully help you can make a better informed choice for your circumstances.

NSX for vSphere: Understanding Transport Zone scoping

As part of NSX preparation for logical switching and routing, it is necessary to define at least one Transport Zone (from here on – “TZ”).

It is obvious from the UI that TZ configuration includes default VXLAN Control Plane mode and a list of ESXi clusters; but what does it actually do?

Let’s find out.

NSX for vSphere: Controller “Connections” and “VTEPs”

In many NSX training classes I heard the same question come up: “what do the Connections and VTEPs numbers represent in show control-cluster logical-switches vni XXX command output?”

nsx-controller # show control-cluster logical-switches vni 5001
 VNI      Controller      BUM-Replication ARP-Proxy Connections VTEPs
 5001     192.168.110.202 Enabled         Enabled   6           4

As training lab exercises build on as well as time passes, the numbers above also keep on changing. What is going on there?

Let’s shed some light on that part of NSX-v.

NSX-v under the hood: VXLAN ARP suppression

When troubleshooting, it’s important to know how the system is supposed to work, so that one can tell whether the currently observed behaviour is normal or not.

This post covers VXLAN ARP suppression in NSX-v.

Distributed Firewall (DFW) in NSX for vSphere, and “Applied To:”

NSX for vSphere maintains a single set of Distributed Firewall rules per NSX Manager. By default, all active rules are applied to all vNICs of all Virtual Machines running on all clusters within the NSX Manager’s domain.

This isn’t always desirable; two cases that come to mind are: (a) large sets of rules, not all applicable to every single vNIC of every VM; and (b) overlapping IP addresses.

To clarify the second case: while in DFW you can use vCenter objects as rules’ Source and/or Destination, “under the covers” DFW always translates those objects into address sets, populated with IP addresses of those objects. So in the end the allow/deny decisions are made against IP addresses. This means that if a given IP address is used by more than one VM (think a multi-tenant environment, for example), there’s a clear risk of unintended firewall action.

The “Applied To:” field in DFW rules can be used to avoid this problem. That’s pretty much it. If you feeling adventurous, below the fold is a small walk-through demo of what I’m talking about above.