Category Archives: NSX

VMware Network Virtualization

Screen Shot 2018-02-05 at 10.46.39 AM

On-Demand NSX Load Balancer spun up by vRA Configs

In this post, you will face the configs of the NSX 6.2.6 on-demand LB what was spun up by vRA 7.01.

1. For HTTP, you can select Cookie or Source IP for Persistence.
Screen Shot 2018-02-05 at 10.55.53 AM


2. For HTTPS, SSL Passthrough is enabled by default. No persistence is configured. You can select Source IP or SSL Session ID for Persistence.
Screen Shot 2018-02-05 at 10.54.41 AM

3. The algorithm is configured Round-Robin by default. Screen Shot 2018-02-05 at 10.40.32 AM


4. Enable acceleration is not enabled, ie. L7 load balancer will be used.
Screen Shot 2018-02-05 at 10.46.39 AM


Screen Shot 2018-02-05 at 9.29.30 AM

Whats new for NSX Load Balancer in vRA 7.3?

In this blog post, I would like to find and list out whats available for NSX LB in vRealize Automation 7.3. You can read more about the announcement on vRA 7.3 NSX features here.

1. There is a virtual server section where you can select what type of traffic you would like to load balancer.
Screen Shot 2018-02-05 at 9.23.23 AM

2. If you add a new virtual server and you can customise the protocol.Screen Shot 2018-02-05 at 9.27.30 AM


3. You can choose the algorithm and the persistence options.
Screen Shot 2018-02-05 at 9.29.30 AM

Screen Shot 2018-02-05 at 9.31.10 AM


4. Health Check Option
Screen Shot 2018-02-05 at 9.32.24 AM

5. And last the Advance options where you can set a connection limit, connection rate limit, change the acceleration engine or set a min or max connections for the members.
Screen Shot 2018-02-05 at 9.33.13 AM


6. You can also change the logging level.
Screen Shot 2018-02-05 at 9.39.43 AM


7. Other things include changing the size of the LB and enable HA for the LB.
Screen Shot 2018-02-05 at 9.44.29 AM



Screen Shot 2018-01-21 at 1.22.14 PM

NSX-v Testing Series – Part 1 – ESG HA, OSPF, Graceful Restart

In the past 3-4 years since I have been started playing around with NSX-v, first version 6.0.4, I have been testing features here and there, performing demos after I join VMware, without really documenting down. Its always test and forget. So now, I’m going to start documenting down my tests with blogging, recording videos and diagrams.

*Disclaimer: You will find incomplete blog posts because with my work commitments and being a dad of 2 young kids, its really tough to blog in a single block of time. I will update whenever I can and with my best ability.

First off the list, I’m going to start with ESG (Edge Services Gateway) High Availability. Why? The ESG is the gateway between virtual and physical, services rich(LB/NAT/Firewall/VPN), always required in every NSX deployment. In the region I served – South East Asia and Korea, many customers footprint size falls between 20 – 40 physical ESXi hosts and North-South bandwidth typically is under 10Gbps. Therefore, a single ESG is suffice to meet these performance requirements. However, since so many services can be turn on on the ESG, the availability is very important. We can always depends on vSphere HA but the reboot of VM would depends takes time. Therefore, application level HA is required and we have ESG-HA or Edge-HA.

[Placeholder for Network Diagram]
CSR – ESG(s) – DLR – Test VM (High level connectivity)

First Edge-HA Failover Test (OSPF default timers with Graceful Restart)

Screen Shot 2017-12-19 at 9.40.18 PM

NSX Test App

A few of you have watched my youtube videos such as VIC, SRM with NSX and requested for the NSX Test App that I used for my demos. Alright, I thought why not share to the community the simple PHP Web application that I wrote. I also written a Lucky Draw App for my demo use which I use at large audience events, to have a little engagement with the audience. I will also share with the community, maybe the next time round.

The NSX test App is basically a PHP file. You can download the PHP file from Once you downloaded, you can use it with for example Apache+PHP or a LAMP. Usually its place in the /var/www folder.

If you open up the PHP file, you will see the servername which is the IP address of the DB VM. I will export the DB into an OVA.       Screen Shot 2017-12-19 at 9.28.02 PM

You can either use the database server in the LAMP or use another VM to be the database. In my demos, I usually use a separate VM as the DB server so mimic a real world scenario, like a 2 or 3 Tier Application. So save you the trouble, I export the whole DB as ova so you can easily import it.

This is the DB OVA. You can download from here

It will look like it if you get it work.

Screen Shot 2017-12-19 at 9.30.30 PM


You watch the VIC with NSX video here which utilising the web application.


NSX Load Balancer for HTTPS Name-based Virtual Hosting

Few of you all know I used NSX Load Balancer for Name-based Virtual Hosting in my home lab as I only got a single Public IP Address and I got a few websites that I would like to host. For example, this blog you are reading now is actually being hosted behind a NSX LB. Try resolving and, they will both resolve to same IP address ie. but when you access these URLs, they are actually different web servers. I used to do that with an apache proxy server but managing the config was rather painful. Since NSX Load Balancer was able to achieve that and it comes with a nice UI, why not? Of course, the other motivation of using NSX LB is for the benefit of my work, getting to know the inside-out of the NSX LB is always good.

Name-based Virtual Hosting for HTTP has been working well for me. I always wanted to find out whether that will work for HTTPS. Asking around my friends on this requirement ie. multiple https websites on the same port 443 and same IP Address seems possible. I was referred to Server Name Indication.

So lets see whether something like this will work for HTTPS. First I have to find some web servers internally that able to do https. I have been using this Turnkey debian LAMP for my NSX testing, so I will use them in this test.

Before testing HTTPS, let see the HTTP in action first. These are the individual web servers, accessing them directly with IP address.

Screen Shot 2017-07-25 at 5.35.27 PM

Lets now map and to the same IP address, which is that has been configured on the NSX ESG as secondary IP Address.

Screen Shot 2017-07-25 at 5.38.38 PM


Screen Shot 2017-07-25 at 5.28.16 PM


OK. lets now access the web servers using their FQDN. Great! It works! NSX LB is now looking at the URL given and point it to the right pool.

Screen Shot 2017-07-25 at 5.40.41 PM


Well, if you are interested in the script that made this work. Here you go.

acl host_app11 hdr(Host) -i
acl host_app12 hdr(Host) -i
use_backend dev2acepod if host_app11
use_backend dev3acepod if host_app12

You will need use the Application Rule. After you create the Application Rule, you have to attach it to the Virtual Server.

Screen Shot 2017-07-25 at 5.43.39 PM

Screen Shot 2017-07-25 at 5.46.14 PM

Alright. Lets now get to the goal which is test out the HTTPS. Same test again, now with HTTPS.

Screen Shot 2017-07-25 at 5.33.10 PM

I’m going to write an application rule that is something similar but now I will use a different Pool. I will name the pool dev2acepod-https and dev3acepod-https.

Screen Shot 2017-07-25 at 6.03.35 PM Screen Shot 2017-07-25 at 6.03.43 PM

Screen Shot 2017-07-25 at 5.55.52 PM

Screen Shot 2017-07-25 at 5.52.55 PM


This is the Application Rule I used for HTTPS.


acl host_app21 hdr(Host) -i
acl host_app22 hdr(Host) -i
use_backend dev2acepod-https if host_app21
use_backend dev3acepod-https if host_app22

Next will be creating a Virtual Server and attach this Application Rule to it.

Screen Shot 2017-07-25 at 5.54.24 PM

Screen Shot 2017-07-25 at 5.55.12 PM


The final configuration looks like this.Screen Shot 2017-07-25 at 5.59.10 PM


OK. Let test it out. So, as you can see, it does not work. Different URL, but its still goes to the same pool. It uses the dev2acepod-https pool because I place it as the default pool.

Screen Shot 2017-07-25 at 6.04.29 PM


Lets now take away the default pool and see how it goes.

Screen Shot 2017-07-25 at 6.06.13 PM


Cannot even load.

Screen Shot 2017-07-25 at 6.07.00 PM


Conclusion is we have to use different secondary IP addresses for different https url. Then the next question is why would you use LB to do this, why not consider NAT?

The other thought is maybe the application rule does not work out this way. Will have to spend some time researching on the right application rule.


[25 July 2017 Update]

Alright, its the application rule after some researching here. So by changing to the following, it works!!!

mode tcp
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }

use_backend dev2acepod-https if { req_ssl_sni -i }
use_backend dev3acepod-https if { req_ssl_sni -i }

Screen Shot 2017-07-25 at 6.37.24 PM

Screen Shot 2017-07-25 at 6.34.28 PM









Screen Shot 2017-05-30 at 12.52.15 AM

VMs Security Tags during Disaster Recovery

If you use VM Security Tags for Security Group membership, these Security Tags are not applied on those VMs on the recovery site.

On the protected site.

Screen Shot 2017-05-30 at 12.52.15 AM

After using SRM for a planned migration or during a disaster recovery.

Screen Shot 2017-05-30 at 12.51.18 AM


I have created the same Security Tags on both the NSX Managers.

Primary NSX Manager:Screen Shot 2017-05-30 at 12.57.09 AM

Secondary NSX Manager:Screen Shot 2017-05-30 at 12.57.45 AM

Please let me know if you have any solution.

Screen Shot 2017-05-29 at 11.34.16 PM

NSX Components DRS Anti-Affinity Rules

NSX Edge Services Gateways(ESG) – DRS Anti-Affinity automatically configured by NSXScreen Shot 2017-05-29 at 11.34.16 PM

NSX Control VMs – DRS Anti-Affinity automatically configured by NSXScreen Shot 2017-05-29 at 11.34.53 PM

NSX Controllers – Need to manually configured for DRS Anti-Affinity rulesScreen Shot 2017-05-30 at 4.12.56 PM

Screen Shot 2017-05-23 at 3.28.28 PM

How should I connect NSX Edges to Firewalls?

In most of the NSX design documents, you will find that they usually consider connecting the NSX ESG(Edge Services Gateway) to physical routers which are usually the border leaf if you are using a Spine-Leaf architecture or Core switches if you are using a 3-Tier architecture. Below are some examples.
Reference: NSX Design Guide
Screen Shot 2017-05-23 at 5.28.02 PM      Screen Shot 2017-05-23 at 5.28.17 PM


Screen Shot 2017-05-23 at 5.38.56 PM

In certain scenarios, the above might not be always the case. Especially, an existing 2/3-Tier Firewalls exist and you cannot change the architecture. There are also instances whereby you have a combine compute-edge or management-edge cluster where the Top of Racks(ToR) are the only switches you have to be able to connect to the NSX Edges. Therefore, the ESXi management VLAN SVI and the External VLANs SVI for NSX Uplinks are all terminating at the same ToR which means they are routable.

Screen Shot 2017-05-23 at 4.57.46 PM

Normally, there is Perimeter Firewall, could be Internet facing or Internal Firewall which could help to prevent these inter-routing of these SVIs but terminating the External VLANs SVI on the Perimeter Firewall. Viola! But don’t be too happy yet, because back to my first point, there are not much documentation out there explaining to you how to do that. That explains the rationale for this post!

Screen Shot 2017-05-23 at 5.13.49 PM

Personally, from my customer engagement experiences, majority of the time, I have to design connecting the NSX ESG to Firewalls.

Lets list down all the considerations and options.

I would assume Firewalls are deployed in a pair for High Availability and for maintenance purposes. Typically most of the vendors would support Active/Standby and Active/Active. I would say most of the deployments I seen were Active/Standby as the traffic flow is more deterministic and easier to troubleshoot.

NSX Edges could be deployed in Edge-HA mode or ECMP. Basically the major difference is stateful services. Edge-HA would support stateful services like NAT, Firewall and Load Balancer while ECMP mode will do routing only.

Firewalls in Active/Active mode would definitely have better performance than Active/Standby as both physical firewall appliance would be able to process traffic.

NSX Edges ECMP mode can support up to 8 Edges. So if require Performance, ECMP NSX Edges would be the choice.

From my knowledge, there are some firewall vendors would be able to do clustering of up to 8 firewalls and in Active/Active. Active/Active firewall would be more scalable but the difficulty in operating this kind of deployment, I doubt there would be any of these kind of deployments. I still think Active/Standby firewall model is still more manageable.

NSX Edge-HA is just a checkbox you select during deployment. NSX ECMP have to be configured one by one. In terms of manageability, NSX Edge-HA would be easier.

NSX Edge-HA will also allow you to configure any stateful services without any redeployment of NSX Edges.

Active/Active firewall during a failure will have a lesser impact to the traffic as compare to Active/Standby firewall as all the traffic have to redirected from one appliance to another appliance.

NSX Edge-HA failover from the Active Edge to Standby Edge will take about 15 seconds. My colleague Kian Wah would say 22 seconds because he tested it. NSX ECMP during failover would take about 3-4 seconds depending on the routing protocol timers you configured.

Nothing much to be consider here for Security aspects.

Possible Options
1) Active/Standby Firewalls with NSX Edge-HA
2) Active/Standby Firewalls with NSX Edge-ECMP
3) Active/Active Firewalls with NSX Edge-HA
4) Active/Active Firewalls with NSX Edge-ECMP

Decision on what to Test
I would like to test all the above scenarios if I have the time. Lets just pick one option to test and hopefully that would be able to meet 80% of the scenarios. I usually don’t have requirements for Active/Active Firewalls so I will rule out Option 3 and 4.

The major design quality that separate out Option 1 and 2 I would say is Performance. If you require more than 10Gbps, Option 2 would be the way to go. Again, I seldom see customer requirements that have 10Gbps North-South requirements. Lets explore more on Option 1.

Additional note on Option 2: I’m not sure whether does this option even make sense. Have to revisit this option again or probably have to test it out. For now, Focus will be on Option 1.

Routing Protocols
Most of the Firewall vendors support Static routing, OSPFv2 and BGP. NSX Edge likewise support the same. NSX Edge-ECMP logically would require OSPF or BGP for ECMP.

Possible Options with Routing Protocol
1) Active/Standby Firewalls with NSX Edge-HA using static routing protocol
Screen Shot 2017-05-23 at 4.03.58 PM

2) Active/Standby Firewalls with NSX Edge-HA using OSPF routing protocol
Screen Shot 2017-05-23 at 4.03.46 PM

3) Active/Standby Firewalls with NSX Edge-HA using BGP routing protocol
Screen Shot 2017-05-23 at 4.03.34 PM

Decision on what to Test and Goal
I would test all 3 scenarios because I am not sure what would be the behaviour like. The goal of these testings would provide the basis for future design decisions and provide some recommendations for my customers.

I foresee this will probably going take awhile to test and document all the various options, I decided to break up into 3 parts.

1) Active/Standby Firewalls with NSX Edge-HA using static routing protocol (Part 1) [Not Done]
2) Active/Standby Firewalls with NSX Edge-HA using OSPF routing protocol (Part 2)
3) Active/Standby Firewalls with NSX Edge-HA using BGP routing protocol (Part 3) [Not Done]

Firewall vendors
I would probably have access to Cisco ASA and Checkpoint VE appliances. Most of the firewalls high availability works almost the same way so I guess these two brands would be suffice to represent the rest.

Test cases
1) Ping test to make sure everything working
2) Failover test – Fail the Firewall Active and measure how long does the failover takes
3) Failover test – Fail the NSX ESG Edge-HA Active and measure how long does the failover takes

To be continued…


TWO new VMware NSX Offerings – Now Part of VMUG Advantage!

NSX is included in EVALExperience!

Enjoy exclusive access to 365-day evaluation licenses for the following VMware solutions:

  • VMware NSX Enterprise Edition – NEW!
  • VMware vCenter Server Standard for vSphere 6.5
  • VMware vSphere with Operations Management Enterprise Plus v6.5
  • VMware vSAN
  • VMware vCloud Suite Standard
  • VMware vRealize Orchestrator
  • VMware vRealize Operations 6 Enterprise
  • VMware vRealize Log Insight
  • VMware vRealize Operations for Horizon
  • VMware Horizon Advanced Edition
  • VMware Workstation Pro 12.5 & VMware Fusion Pro 8.5


Looking to get your NSX Certification?

Look no further, VMUG Advantage has teamed up with VMware NSX to offer an exclusive training package to help you earn your VCP-NV.  Purchasing similar products individually would cost over $4,000. Follow along with the NSX Learning Path.

NSX Training & Certification Package: Exclusive Price $1,995 (offer valid until June 30th, 2017).

  • VMware NSX: Install, Configure, Manage [V6.2] – On Demand Content
  • VMware NSX: Install, Configure, Manage [V6.2] – On Demand Lab
  • VMware vSphere 6 Foundations Exam Voucher
  • VMware Certification Exam Prep: VCP6 – Network Virtualization Exam v6.2
  • VMware Certification Exam Prep: vSphere 6 Foundations Exam

Learn more about VMUG Advantage today!

Screen Shot 2017-04-11 at 11.16.15 PM

Virtual Network Assessment (VNA)

Recently I have been actively involved in carrying out the rolling out of VNA. Training for the internal VMware folks as well as the VMware partners. So what is exactly VNA and whats in for you?

VMware Virtual Network Assessment(VNA) is a assessment that analyzes network traffic patterns within your data center. In 24 to 72 hours the assessment delivers:
Insights into the security risk (amount of East-West traffic) present in your network
A preview of actionable NSX micro-segment recommendations for your network
Opportunities to optimize network performance with NSX

How do I get my assessment?

You can contact me or your VMware partner to request your Virtual Network Assessment today. When your assessment is complete, an NSX expert will review your report and outline how NSX can help secure your network.

Are there any technical requirements to getting an Assessment?
vSphere 5.5 or above
ESXi 5.5 update 2 (build 2068190)
ESXi 6.0 update 1b (3380124)
ESXi 6.5
vSphere Distributed Switch

Here is a video on VNA.

Screen Shot 2017-04-11 at 11.16.15 PM