Monday, May 14, 2018

NSX-T Resources


Its been a while when I last blogged but here I am again with NSX-T.

Please go through the whole article here about getting anything for NSX-T

NSX-T - Reference Architecture

NSX-T - Reference Design

Containers and container Networking with NSX-T

NSX-T Hands-on-Labs
HOL-1826-01-NET – VMware NSX-T – Getting Started (
HOL-1826-02-NET – VMware NSX-T with Kubernetes (

NSX-T White Paper

NSX-T Routing

Software Download

PKS CLI                                    
Kubectl CLI                               
Pivotal Ops Manager for vSphere
Stemcell for vSphere                 

NSX-T Official Documentation

NSX-T Deployment Architecture with NAT 
NSX-T deployment with PKS using the Network Address Translation (NAT) topology. The following figure shows the NAT deployment architecture:

Early Access: VMware Validated Design for NSX-T in a Workload Domain


Please provide an update to the article and I will update it at my earliest.

There are some other information also I am waiting on currently so I will update them as well once confirmed.

Thank you for your time and please share and care.

Have a nice day !!

Monday, May 8, 2017

NSX Firewall Rules using Application Rule Manager (ARM)

Hi All,

Recently I was engaged in a project for NSX Brownfield deployment and the requirement was to migrate the citrix environment to VMware Horizon View desktops.

So the challenge we had was to find out what is in use by the Citrix VMs in the existing environment from the service/port perspective so it will be easier to find out the communication path between twoVMs (for test for now) but it can be scaled all the way to the cluster level if needs to.

So there are few ways this can be achieved and I will cover the same in the series of 3 parts.

1) Using ARM (Application Rule Manager) which will be covered in this post
2) Using vRNI (vRealize Network Insight) which will be the next post
3) Using LI (vRealize Log Insight) which will be the last post of this series

So lets get started.

We are running the latest NSX Manager version 6.3.1.

Now I assume that the readers are familiar with NSX Manager and other components of VMware vSphere as I will be using the terminologies quite frequently and also the acronyms of the same.

So once you go to Networking and Security and you need to click on Flow Monitoring to see the option of application Rule Manager

Im showing here the screen shot of the same.

Then you need to generate the flows by doing certain activities to invoke the traffic to use particular ports / services.

So now lets dig deeper in to ARM.

lets say I want to know the flows between two VMs so I will start with New Session and then give a name to the session.

Next option is to select the source and here you have only two options to choose from as a Object Type

1) Virtual Machine

2) vNIC

So I will go with VM and provide a name of the VM.

Thats the only thing you need to provide and once you click OK then it will start gathering the flows from the VM.

Now click Stop to finish collecting the flows and once you highlight any flows under the View Flows option then you will see two options under Actions.

So either you can hide records or you can create a Firewall Rule based on the flow captured.

After I selected Create Firewall Rule, then I will go to the tab "Firewall Rules" and check what rule is created.

So before you publish the rule you can modify the Rule with necessary details e,g Source, Destination, Service, Applied To, Action and Log.

You can create multiple sessions and just select the drop down to see/view specific Flow details about a particular session.

Name the session properly so you can see what you have captured. In the above screen shot as you can see I've given the name tst-h-ic-blk which I provided to find out the icmp block for horizon and the rule is test rule.

You can keep the name with the function of the VM/server you are going to create the firewall rule for, so it will be easier to understand take actions on the particular rule set.

Once you create the rule then you need to go the Firewall Rule tab and publish it and it will be immediately come in to the effect. Which you can verify under Firewall section on the left.

So as you can see, it will be added as a new Section to give the name to the rule properly so it will be meaningful.

If there are more than one service you can see in the flow then click on the small gear icon on the right besides the services and you can see all the services captured.

Now from the product use perspective this will be a trouble when you have to find out the traffic patterns on a large environment (having no other options of at the cluster level or host level options) so you have only one choice of finding out per VM basis and then go thro each flow collected and create the rule/s.

May be I can suggest a feature request to VMware about incorporating other options when dealing with multiple items and have a single option to create Firewall rule / rules based on the collected flows. This can be based on the at the Data Center/ Cluster Level which can be considered in aggregation of all the flows captured.

It will help the Admin of the environment to allow the default communication ports which got captured after running the flow capturing for enough duration which will allow to capture all possible traffic coming from X and going to Y or Z.

Hoping that in next version this improvement will get incorporated to ease the process of utilizing only ARM to recommend the rules and go with the same.

Hope this helps.

In Next post I will cover vRNI to find out how you can utilize the same to create Firewall Rule/s.

Please share and care.

Thanks for your time.

Monday, April 3, 2017

vMotion of NSX EDGE gotcha vMotion of NSX EDGE gotcha: Hi, Recently I was working on a brown field deployment of NSX and ran into an issue where we were not able to connect to the DHCP server ...

vMotion of NSX EDGE gotcha


Recently I was working on a brown field deployment of NSX and ran into an issue where we were not able to connect to the DHCP server from a Logical Switch (which means the VMs are not getting IP addresses from DHCP server) which was a key.

If we put the VM on a regular VDS dvportgroup it gets the DHCP IP correctly.

So we started looking in to the issue further and engage VMware GSS to look in to the issue.

During the troubleshooting we had to decide the location of Edge and try moving it to a different host to verify if its not hitting any uplink issue.

As we were using vCenter Web Client and as soon as we tried migrating (vMotion) it to another host and we were prompted with the NIC mapping page. Where we need to map each interface exists on the NSX Edge to a corresponding portgroup or dvportgroup. Now we have only limited number of portgroups/dvportgroups existed on the Cluster and we could not map all the internal interfaces (which gets created by default on the Edge appliance).

The source were listed as "None" so not sure where to map them.

So we ended up using the vSphere client to migrate the Edge appliance, and got migrated with no notification about mapping all the interfaces. Just select the destination ESXi host and hit "Finish", and we are done.

We were then moved into the next phase of troubleshooting but the above just put me in a dilemma that the behaviour of Web Client is a bug or is it by design.

Interested in getting the answer from VMware so that I can clarify that with the existing and future customers on why to use vSphere client and what is the alternate methods to use when the Fat/Thick client will completely got removed by VMware??

Please leave the comment and share this.

Thanks for your time.

Tuesday, January 3, 2017

vRA and SCCM Timeout Issue vRA and SCCM Timeout Issue: Hi, OK here I am again. Been away for few months working on various projects including vRA, vROPS, SRM, VIN, vRB etc.etc. And one of the...