#NET5488: Troubleshooting Methodology for VMware NSX (for vSphere, v6.2):
I designed the pack to be read, so hopefully you find it useful without the recording. For those who have attended VMworld, both US and Europe sessions were recorded. You should be able to watch them on vmworld.com.
Not sure which one (US or EU) went better, to be frank. 🙂
This article has been re-published as a KB: http://kb.vmware.com/kb/2122060
NSX for vSphere supports three VXLAN Control Plane modes:
- Multicast (described in Section 4 of RFC 7348);
- Hybrid; and
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.
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.
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 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.
A few days ago while chatting with a customer who is getting ready to plan their virtual infrastructure with NSX, I realised they did not know that documentation for the NSX vSphere has been publicly available for a while.
Also, turns out they haven’t seen the brilliant collection of NSX resources hosted on VMware’s NSX web site, including Network Virtualisation Design Guide, which, well, pretty much covers all of the important considerations for an NSX deployment.
So, while they are a just quick google search away, here’s the links:
NSX Resources (see the design guides in the “Technical Resources” section):
NSX vSphere Documentation:
NSX Support Center:
https://www.vmware.com/support/nsx.html – Includes all documentation guides and Release Notes
NSX VMTN Documents:
https://communities.vmware.com/community/vmtn/nsx/content?filterID=contentstatus%5Bpublished%5D~objecttype~objecttype%5Bdocument%5D – Guides, whitepapers, etc
P.S. While this post isn’t really intended as a collection of useful NSX links, I think I’ll likely be updaing it if I come across any items of a comparable caliber.