Reading Time: 7 minutes

When we talk about VMware NSX (formerly VMware NSX-T Data Center), most of us think about abstracting management of the network away from the physical fabric thanks to NSX’s magic sauce and overlay networking capability via Geneve encapsulation. However, overlay networking isn’t always the primary use case, with a high volume of customers opting for micro-segmentation only.

Some customers, for example, are happy to allow the network’s management and physical gateways to remain within the physical fabric. Perhaps their organisation already has an alternative software-defined networking product, or they simply don’t make that many changes within their network. So, how can customers use micro-segmentation via the NSX Distributed Firewall (DFW)? Simply put, by utilising currently existing vSphere environments and VDSs in conjunction with the NSX DFW.

The deployment process to facilitate the micro-segmentation-only use case is often the quickest and most straightforward architecture to deploy. In this article, we look at the process in detail.

There are two options for deploying the Security Only use case:

  1. Firstly, we have the wizard-driven Security Only deployment option available via the Quick Start option (Quick Start > Prepare Clusters for Networking and Security). This is a great way to get customers up and running quickly and will enable immediate use of the DFW in conjunction with vSphere-owned distributed port groups. However, with its ease and speed comes a few caveats – unfriendly naming conventions for the required NSX constructs will be created (transport zones, uplink and transport node profiles), some of which cannot be edited or deleted, and more importantly, were a customer to decide to leverage networking via NSX (VLAN-backed or overlay) at a later date, they would need to uninstall NSX VIBs from the cluster and reinstall. As it’s best to start as you mean to go one, let’s discuss Option 2.
  2. The second option is a manual deployment, which in most cases, is preferable. This option gives us more flexibility and allows us to configure transport zones, uplink and transport node profiles, etc., with ‘nice’ names and not the long automated identifiers defined via the quick start approach. The manual approach also enables us to create VLAN-backed networks/segments within NSX itself. Where customers wish to leverage overlay networking in the future, they will be able to build on top of what has already been deployed without the need to strip out the automated Security Only deployment configuration.

Nutshell, where a customer never requires NSX-owned networking (either VLAN-backed or overlay), Option 1 will suffice. If the use case were to change and a requirement for NSX networking is identified in the future, Option 2 every day of the week.

Micro-Segmentation Only Deployment Process

1. Firstly, let’s take a look at our environment. This is a lab environment and, as such, I have a vSphere Cluster of two ESXi hosts. Both ESXi hosts have two (2) physical 10 Gbps network adapters and have been added to a vSphere Distributed Switch. This VDS will be utilised by VMware NSX and, as a requirement, must be version 7 or above.

2. Next up, let’s log in to VMware NSX and create a Transport Zone by browsing to System > Fabric > Transport Zones, and by clicking + ADD ZONE.

3. Configure the Transport Zone appropriately, ensuring Traffic Type is set to VLAN. When ready, click ADD.

4. The Transport Zone is successfully created, however, note the Status displays as Unknown. This is expected, as the TZ is not currently utilised within our environment.

5. Next, browse to System > Fabric > Profiles > Uplink Profiles, and click + ADD PROFILE.

6. Configure the Uplink Profile appropriately, ensuring the Teaming Policy is set to Load Balance Source with two uplinks (i.e. – traffic will load balance across both active uplinks on my ESXi hosts). Note, as we will not be utilising Overlay networking we will not be utilising a transport VLAN for GENEVE encapsulation. As such, the Transport VLAN can be left at the default 0, and MTU can be left blank (MTU will be controlled via the VDS). When ready, click ADD.

7. The Uplink Profile is successfully created.

8. Next, browse to System > Fabric > Profiles > Transport Node Profiles, and click + ADD PROFILE.

9. Configure the Transport Profile appropriately, ensuring the Switch Type is set to VDS, Mode is set to Standard, the appropriate Compute Manager and VDS is selected, and our newly created Transport Zone and Uplink Profile are attached. When ready, click ADD.

10. The Transport Node Profile is successfully created.

11. After these several simple steps, all that is left for us to do is to apply the Transport Node Profile to the vSphere Cluster. Browse to System > Fabric > Nodes > Host Transport Nodes, select the vSphere Cluster, and click CONFIGURE NSX.

12. Select the appropriate Transport Node Profile and, when ready, click APPLY.

13. Monitor the NSX Installation process via the NSX Configuration tab.

14. Finally, check that NSX Configuration is successful and that the Transport Node Manager Connectivity, Controller Connectivity and PNIC/Bond Status all report Up. Note, Tunnel Status will remain in an Unknown state as these ESXi hosts do not require GENEVE tunnels due to no overlay networking being utilised.

This completes the deployment process for VLAN-backed micro-segmentation only. Next, we will validate we are able to secure a test VM.

Micro-Segmentation Validation

I’ve written and presented on the subject of micro-segmentation several times in the past, so I won’t go into too much detail in this article. However, to validate our deployment, I will quickly secure a VM so that, in reality, I could hand over the solution to a customer.

1. Firstly, let’s create an NSX VLAN-backed Segment so that we can migrate our test VM. Browse to Networking > Connectivity > Segments, and click ADD SEGMENT.

2. Configure the new Segment with an appropriate name, select our recently created VLAN Transport Zone, and allocate the appropriate VLAN ID. When ready, click SAVE.

Remember, the gateway will continue to reside on the physical network, so no gateway or subnet details need to be configured here. As an example, the below Segment ties to VLAN ID 100, which has a subnet of 10.0.100.0/24 and a gateway of 10.0.100.1.

3. The VLAN-backed Segment is successfully created.

4. If we jump back to vSphere, we can now see the NSX Segment has been created and is visible, albeit read-only as an NSX-owned Port Group.

5. Finally, I have moved a test VM over to the new NSX Segment and amended its IP configuration to align with the subnet. Specifically, IP address 10.0.100.20/24 with the gateway mentioned above (10.0.100.1).

6. ICMP tests to/from this VM are successful. Any duplicate packets can be ignored as this is a nested lab environment.

ICMP test TO the test VM is SUCCESSFUL
ICMP traffic FROM the test VM is SUCCESSFUL

7. Now that we have a test workload VM running on an NSX Segment, let’s secure it. Browse to Security > East West Security > Distributed Firewall and expand the Default Layer3 Section. Note that this rule, by default, is set to Any/Any/Any/Allow.

8. To drop all traffic to/from this VM (and everything else sat on an NSX Segment), simply change the Action to Drop and click PUBLISH. Of course, in a real environment, you would opt to configure VM/application-based DFW rules.

9. Running the same basic connectivity tests as we did in Step 6 now shows that all traffic to this VM is dropped.

ICMP test TO the test VM is UNSUCCESSFUL
ICMP test FROM the test VM is UNSUCCESSFUL

This concludes the micro-segmentation test to validate the micro-segmentation-only deployment process.

In Summary

In this article, we looked at the process of preparing a vSphere Cluster for micro-segmentation only via VMware NSX. Where overlay networking is not required, NSX can still be utilised to perform micro-segmentation.

Further Reading

3 Comments

    1. Hi Totie,

      A huge thanks for your comment.

      I touched on two deployment options early in the article, specifically around the caveats of the automated quick-start security-only deployment and why it might be preferable for a customer to deploy this configuration manually. Thanks to your query, I’ve added a little more detail to the options to clarify why the manual approach should be chosen.

      In a nutshell, were a customer to prepare vSphere hosts/clusters via the automated security-only quick-start wizard, the vSphere hosts/clusters would not be able to leverage VLAN-backed or overlay networking via NSX in the future. Instead, NSX would need to be uninstalled from the hosts/clusters.

      The manual option gives much more flexibility where customers MAY decide to leverage additional features of NSX in the future. Where a customer would absolutely never wish to move from the security-only model, you’re absolutely right; the quick-start deployment is perfect. However, as a customer’s NSX knowledge and skillsets mature, I see many wanting to utilise additional functionalities.

      The manual approach allows us to meet the security-only use case, as well as to provide a solid platform for future/additional use cases. More importantly, we prevent any future headaches.

  1. Hey Gareth, thanks and appreciate the efforts for writing NSX blogs. I love to read them and this really helps to understand concept more clearly.
    i wanted to request if you can more such blogs which covers multiple design on NSX, for example – Multiple NSX instances with different set of requirements ( vdi/dmz ) where customer looks for isolations.
    – Another could be isolation of (vdi/dmz example cluster) on Transport Zones level with single NSX instances with available options.
    – multi VDS etc.

    Again thanks for all your efforts.Keep up doing great work

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.