Micro-Segmentation in Action

In this blog article I’m going to show you Micro-Sgementation in action with NSX in my lab.  The concept of Micro-Sgementaiton is the ability to block or limit traffic between all workloads within your datacenter, which includes blocking or limiting traffic between all VM’s on the same layer 2 network.  There is a great whitepaper here explaining more.  In my lab I have the following logical switches:

I have the following virtual machines assigned to the following logical switches:

WEB01 (192.168.0.11) -> Tenant-01-Web-Tier
WEB02 (192.168.0.12) -> Tenant-01-Web-Tier
APP01 (192.168.1.11) -> Tenant-01-App-Tier
DB01 (192.168.2.11) -> Tenant-01-DB-Tier

WEB01 can successfully ping WEB02 and vice versa:

The following rule will block all traffic from WEB01 to WEB02 but not from WEB02 to WEB01:

This was just a quick post showing the power of NSX and Micro-Segmentation.  I’m now going to start looking into the service composes functionality and policies can be applied to a specific group of VM’s.  Expect more soon 

vCOPS report to help size for vCloud Air

I was asked recently by one of my partners if there was a specific report that can be run within vCenter Operations Manager to help gather the size of an environment to then quote for some vCloud Air resources.  The best report to run to gather this information is the Virtual Machine List Report:

This will produce the following report for all VM's that vCOPS is currently monitoring:

You can also use the legacy C# client to gather this information and export to a .csv file if you prefer:

One thing to point out with the C# client is that it will show total space provisioned which will include snapshots and overhead.

Installing the NSX Management pack for vCenter Operations Manager

In this article I'm going to show you how to install the VMware vCenter Operations Management pack for NSX-vSphere 1.0.  First thing that you need to do is register for an account on the VMware Solution Exchange and download the .pak file:

Once you have it downloaded you need to upload and install it into vCenter Operations Manager.  Simply browse to the admin interface (https://UI-IP-ADDRESS/admin/) and log in, select the Update tab and browse to the downloaded .pak file and click Update.  Wait for the process to complete and you should see that it's been installed successfully:

Once the update has completed browse the customer dashboard (https://UI-IP-ADDRESS/vcops-custom) and verify that the NSX dashboards are available:

You will see the dashboard but no data will be collected until we configure the adapter instance to point to the NSX Manager as well as the vCenter associated with it.  To do this simply click Environment, Configuration and then Adapter Instances:

Add a new adapter instance of kind NSX Adapter and complete all the required information as per below:

Configure the required credentials to access NSX Manager and vCenter as per below:

Test the connection to ensure that the IP addresses and credentials are all correct:

Once completed, vCenter Operations Manager should start populating the new NSX Dashboards:

Missing logical switch in NSX GUI

I've been playing around with NSX recently in my nested lab and somehow I've managed to create a logical switch that's configured somewhere but missing form the GUI as per the screenshots below.  As you can see, my transport zone has one logical switch assigned to it:

When you go to view the logical switches it says that the list is empty:

When querying the controller VM through the CLI I can see that VNI 5002 is assigned to something:

And also when creating an NSX Edge I can see the logical switch appear there as well:

Anyone have any ideas on how to remove the logical switch via CLI as I can't seem to find any commands to do this?  I've tried rebooting both NSX Manager and the controller VM but no joy.  Once I find this out I'll update this post.

** UPDATE **

Since I can't find any way to delete this logical switch via the GUI or even CLI I thought I'd try the API.  When running the following GET command against the NSX Controller I still can't find that phantom logical switch:

GET https://10.1.2.41/api/2.0/vdn/scopes/vdnscope-3/virtualwires

As recommended by Geordy Korte (Blog | Twitter) in this VMware Communities post I tried forcing a sync via NSX Manager with no success:

I also tried rebooting the entire lab which included hosts, vCenter, NSX Manager and controllers.

** RESOLUTION **

First of all a big thanks go out to Dmitri Kalintsev (Blog | Twitter) for spending around an hour with me going through various troubleshooting techniques to get to the bottom of it.  Ultimately the issue was caused due to only having one NSX controller.  Basically I issued a delete command on the logical switch, the NSX controller deleted it from it's database and the hosts and then tried to delete it from the NSX controller which wasn't quite ready as I had just rebooted it.  If I had the recommended three controller VM's as per best practice this would not have happened.  So, how did Dmitir help me resolve this, well it's quite clever when you think about it.

First he asked me to change the controller plane of the Transport Zone from Unicast to Multicast but I first had to add Multicast IP addresses into the segment ID as per below:

I then changed the control plane to Unicast ensuring that I ticked the option to Migrate existing Logical Switches to the new control plane:

I then deleted and re-provisioned a new NSX controller and then when that was fully up and running, changed the Transport Zone back to Unicast remembering to tick the option to migrate existing logical switches and removed the multicast IP addresses from the segment ID:

Once this was performed the logical switch re-appeared:

Once again, big thanks to Dmitri and everyone else who helped out.  Hopefully this will help people who want to learn NSX and only use one NSX controller VM in their lab.

Configuring and testing VXLAN within a nested environment

In this post I'm going to show you how I managed to get VXLAN working (Which is required for NSX) within my test environment that I'm currently using to learn more about NSX.  My homelab currently consists of:

3 x HP ML310e G8
1 x RouterBOARD RB751
1 x Linksys SRW2016 16 Gigabit Switch
1 x Synology DS412+

Within the Production cluster I run all my home production services but I also run a Nested ESXi lab that I previously used for vCNS and now NSX as per the screenshot below:

My Test cluster contains three hosts and the vCenter Server Appliance.  I installed NSX manager outside of this cluster as I didn't want it to take up the nested lab resources.  My Test cluster looks like this:

I've deployed a single NSX controller in this cluster as I'm not too bothered about redundancy and would rather save the resources for VM's.  So, now onto the blog post.  In order for VXLAN to work you need a dedicated VLAN and the MTU needs to be set to 1600 end to end.  First step was to enable jumbo frames on my Linksys SRW2016 switch.  This simply involved ticking a box and rebooting the switch.  This was a pain as I had to power down all VM's and hosts but I also took the opportunity to upgrade my Synology DS412+ to the latest firmware.  To enable jumbo frames on the Linksys switch you simply browse to the admin interface, select Admin and then tick the option next to Jumbo Frames and then reboot the switch:

Next step was to create a new VLAN dedicated for VXLAN traffic and ensure the MTU was set to 1600.  I use a RouterBOARD RB751 as my router / Layer3 switch which I highly recommend.  This was simply a case of creating a new VLAN, I used 15, setting the MTU to 1600 and assigning it to the bridge-local interface:

It was then a case of creating the same VLAN within the Linksys switch and passing this VLAN down the trunks to the three ESXi hosts.  Once the VLAN was presented to the three ESXi hosts I then needed to set the MTU on both the Production and Test cluster Distributed Virtual Switchs as by default they are set to 1500.  To do this simply go to Networking, right click on the DVS and select Edit Settings.  From there, select Advanced and then change the MTU to 1600

It's then a case of configuring VXLAN for the cluster using VLAN 15, ensuring the MTU is set to 1600 and configuring an IP pool for the VMK nics:

In order to test network connectivity from one host to another you can use the following command after SSH'ing into the host:

ping ++netstack=vxlan -d -s 1600 -I vmk5 <IP ADDRESS>

In my case when pining another host with the MTU set to 1600 it failed:

After reading this article by Kamau Wanguhu (Blog | Twitter) I found the the actual VXLAN packet size is 1572.  I then pinged another host with the new MTU size and it worked fine:

So, hopefully that's VXLAN all configured in my NSX Test cluster.  Big thanks to Dan Watson (Twitter) and Geordy Korte (Blog | Twitter) for their help.  I'm sure I'll be harassing you more and more  in the coming months.

Getting started with NSX

This week I've been on an internal training course with VMware on NSX.  In case you haven't heard of NSX, this is a network virtualisation solution offered by VMware (My Employer).  I've already deployed NSX in a nested lab but this blog post is just going to quickly show you my current setup and how to grant specific user accounts admin rights within NSX and also how to stop accidentally locking yourself out of access to vCenter with the distributed firewall.  Expect more blog posts on NSX as I become more familiar with it and use it in the lab.  Firstly, This is how my physical lab looks like which hosts all my home production VM's:

As you can see I run a nested environment consisting of three virtual ESXi hosts and the vCenter Server Appliance.  The NSX Manager is running outside of the test cluster as I didn't want to consume resourced within the nested environment.  The nested environment simply has a three hosts, an NSX controller and a few simple web servers:

Once you've deployed NSX manager and deployed your first controller your probably going to want to grant your admin account permissions within NSX so you don't have to keep logging is as the local admin of the vCenter Server Appliance (This is just the way I like to work).  To grant your admin account access, simply log into the web client and select Networking & Security from the menu option:

From the NSX menu screen click on NSX Managers:

Click on the NSX manager link that you want to make changes to:

Click on the Manage tab and then the Users tab and simply click the green plus:

Enter the user or group name of the active directory object that you wish to add and click Next:

Select the role for the user or group and click Next:

Set the scope limit and click Finish:

You should now be able to access NSX Manager as the user or the user of the group that you just added.  Another operation that you should probably perform is to exclude vCenter from having any policies being applied to it as you can quite easily lock yourself out.  In my case it shouldn't be an issue as the vCenter Appliance does not reside in the same cluster as the one I'm going to be applying policies to but if yours does then simply browse to the NSX Manager, select Manage and then Exclusion List:

Click on the green plus and then form the drop down menu, select your vCenter server object.  As mentioned, in my case the vCenter does reside in the same cluster so I should be OK.  Once added simply click OK:

So, that's as far as I am at the moment.  I need to make some physical changes to my switch to allow jumbo frames (or MTU of 1600) for the VXLAN traffic and unfortunately I can't do that remotely without taking down the entire lab and my access so I'll be doing that over the weekend.

Great North Run 2014 Sponsorship

It’s that time again when everyone is asking for sponsorship for the Great North Run in September so I National Autistic Society.  I already have my place secured so I don’t need to raise a specific amount to guarantee entry.  I’m doing this more for personal reasons as a great friend’s son was recently diagnosed with Autism and it also runs in my family.  I’m also doing this for a little bit of financial motivation (More on that later).  I’ve always wanted to complete the Great North Run in under 1h 30m but have failed twice so far, once by around 7 minutes and last year by around 2.  In my defence last year I was training for a marathon and just used the Great North Run as another training session.  If you know me I’m definately not built for running but do have the knack and more importantly, enjoy it.  In order to complete this half marathon distance in under 1h 30m involves an average pace of 6m 51s and currently my last 5 mile run averaged around 7m 40s so I’ve got some serious training to do.

So, what is the financial motivation for this?  Well,  For every £100 donated I’ll stump up £50 (Up to a maximum of £250) if I fail to beat 1h 30m.  I’ll be going off the official time by the Great North Run organisers and will post my time up when finished.  So, to sum it all up:

If I get £300 worth of donations and I fail, then I’ll top that up with £150
If I get £700 worth of donations and I fail, then I’ll top that up with £250
If I get £130 worth of donations and I fail, then I’ll top that up with £100

You get the idea.  So dig deep everyone and pray that I fail.  Once again, for the people who know me, I hate loosing and I’m tight so bring it on!!

So, if you'd link to sponsor me then just follow the URL below and leave a "Hope you fail" message:

http://www.justgiving.com/Michael-Armstrong5

Thanks for taking the time to read this and hopefully donating.

Michael