Cross vCenter Networking and Security with Service Composer - NOT SUPPORTED

With the recent release of NSX 6.2 we now allow for cross vCenter Networking and Security.  This allows the security posture of your virtual machine to follow it when migrating from one vCenter to another.  As per the NSX 6.2 Cross vCener Installation Guide on page 18 service composer isn't actually supported but we can create local policies on each vCenter that populate a security group based on the name of the virtual machine.  When the VM vMotions from one vCenter to another the VM is removed from one security group and populate in the other.

In my environment I have two vCenter servers called NY-VCSA-01 and PA-VCSA-02 with the following compute, management and workloads:

The default Distributed Firewall Policy for both vCenters is to reject:

I'm now going to create a new security group within Service Composer and populate it based on the virtual machine name containing the work "web".  First go into Service Composer and create a new security group:

Give it a name and click Next:

Set the correct matching criteria which in my case is to populate the group if the VM Name contains the word "web" then click Finish:

Ensure the same Security Group is created on both the Primary and Secondary NSX Managers.  Once completed if you have any VM's with the name "web" in the text then they should be members of the security group:

We are now going to create the policy that we will apply to the security group.  The policy will be configured accordingly:

ANY -> Security Group -> HTTP/HTTPS -> Allow
ANY -> Security Group -> SSH -> Allow
ANY -> Security Group -> ICMP Echo / ICMP Echo Reply -> Allow

Go back into Service Composer and create a new policy and give it a name:

Create the firewall rules as required and then click Finish:

Apply the policy to the security group:

Ensure you have identical security groups and policies on both the primary and secondary NSX Managers.  

I currently have WEB01 running in NY-VCSA-01 and WEB02 running in PA-VCSA-01 and I can check what distributed firewall rules are currently being applied:

Now when I vMotion WEB01 from NY-VCSA-01 to PA-VCSA-02 the VM will be removed from the Web Servers security group in NY-VCSA-01 and then populated into the Web Servers security group in PA-VCSA-01.  I've tested this via pinging WEB01 during the migration.  As you can see the VM pings fine and then the connectivity drops.  This happens when the VM is removed from the security group on NY-VCSA-01 and not yet a member of the security group in PA-VCSA-01 so the default deny rule is being applied.  Once the VM is populated in the security group in PA-VCSA-01 the rules apply and connectivity is restored:

As we can see the VM is now in PA-VCSA-01 and the same firewall rules are being applied:

North East VMUG - Thursday 26th November

Registrations for the next North East VMUG are open and you can register via the link below:

Register Now

The event is taking place at Campus North:

Campus North
Auditorium
Sunco House
5 Carliol Square
Newcastle, Tyne and Wear
NE1 6UF
Click here for directions

Agenda is as follows:

12:00 - Registration and Networking
12:30 - Introduction – North East VMware User Group Committee.
12:45 - Zerto Gold Sponsor Presentation: People Depend on Your Data; Your Data Depends on Zerto. Ensure IT availability: protect, migrate & recover workloads on any infrastructure or cloud.
13:30 - Lunch and Break out Session – Breakout session time to interact with our sponsors and enter vendor giveaways for a very good chance of winning some great gadgets.
14:00 - VMware Presentation – Lee Dilworth, @leedilworth, Principle Systems Engineer VMware Site Recovery Manager across Metro stretched clusters.
14:45 - Community Presentation – Nick Evans, Senior Infrastructure Engineer. Nick runs a demo of his Zerto environment and discusses use of the product in a real world disaster recovery scenario. This is a no sales honest account of actual use of the Zerto solution by a real North East company. Attend this session to learn from Nick’s experience.
15:15 - Breakout session – Breakout session time to interact with our sponsors and enter vendor giveaways
15:30 - Nimble Gold Sponsor Presentation – Consolidate hybrid and all flash workloads in one platform for businesses of any size. At this presentation you will learn how Nimble makes this happen.
16:15 - VMware Presentation – Michael Armstrong, @m80arm, North East VMware System Engineer. In this session we will introduce you to Network Virtualization and VMware's NSX which provides Layer 2 to 7 network services.
17:00 - Breakout session – Breakout session time to interact with our sponsors and enter vendor giveaway.
17:15 - Community Presentation – Andy Ferguson, NHS design engineer. The benefits and realisation of automation from real world implementations. Andy will discuss how your business can reap the unlimited benefits of automation across multiple technologies using Powershell.
18:15 - Questions and Answers
18:45 - Closing statement and giveaways – All these prizes have to go
19:00 - vBeers and networking at location

Big thanks to our sponsors as without them these events wouldn't happen:

We're Slacking at the North East VMware User Group

Duncan (Twitter) and Alan (Twitter) who are both VMUG Leaders for the North East VMware User Group have setup a Slack account / channel / forum or whatever the correct term is for the North East VMware User Group.  Slack allows people to chat and collaborate in real time and we though it would be a good idea to get the North East VMUG community involved and use it for general chat, announcements and ideas for the future events.  So, if you want to get involved create an account and join us via the URL below:

https://nevmug.slack.com

All the VMUG leaders participate so the more members we get the better community we will have. So, what are you waiting for, sign up and join us.  Just remember to turn off notifications if you install the mobile app, it can get quite busy.

North East VMUG MIni Meet

The North East VMUG Leaders are having a catch up on Friday 25th September and would like to extend the invite out to the community as per below:

What’s happening?
We've been busy behind the scenes planning the next VMUG and decided to have a mini VMUG meeting in September. As this is a community group, we'd like to extend the planning to all our members so you have a part in shaping the next event.

When's it happening?
25th September 2015
4:30PM - 5:30PM (leaders meet)
5:30 PM - 6:30PM (All community members)

All VMUG members welcome.

Why are we meeting?

• Test out an awesome new location
• Discuss content our community would like to see at the next meeting
• Requests for community presentation
• Provide forum to support for community speakers
• Launch an exciting new channel for community collaboration
• Requests for VMUG leader volunteers
• Social catch up for group members
• Make people aware of Campus North and the excellent facilities available
• See who will be at VMworld to share contact details

You can register for the event and find all location details here or feel free to turn up.  I'm sure knowing the leaders that there may be a few selected drinks on offer if that's enough to tempt you.

See you there

NSX 6.2 Communication Channel Health

A great feature released as part of NSX 6.2 is the Communication Channel Health which can be used to troubleshoot communications between NSX Managers and Controllers to the individual hosts or clusters.  The following diagram taken from a VMware presentation shows the communication channels involved:

The VSFWD is the Firewall Agent and NETCPA is the Network Control Plane agent that both run on all hosts / clusters that have been prepared for NSX.  To check the Communication Channel Health log into the vSphere Web Client and navigate to the Networking & Security plug in -> Installation and then the Host Preparation.  Click on a cluster or individual host and selection Actions and then Communications Channel Health:

The following shows the health of the PA-MGMT cluster:

The following shows the health of an individual host:

When your hosts looses the ability to communicate with an NSX Controller then you will see the Control Plane Agent to Controller being down (To simulate this I just powered off the only controller in my lab):

If there are issues with the NETCPA agent then you will see the following (To simulate this I just stopped the NETCAP service on a single host):

Because the host uses the NETCPA agent to communicate with the controllers you will see an unknown error as well.  Finally if there are issues with the firewall agent you will see the following (To simulate this I just stopped the vShield-Stateful-Firewall service on a single host):

You will also notice that NSX Manager to Control Plane Agent is down and Control Plane Agent to Controller is unknown and this is because the connection status from each host to controller is locally monitored and the health status is then reported by each host to the NSX Manager over the messaging bus which is dependent on the VSFWD service.

Creating a Universal Logical Switch in NSX 6.2 and vMotioning a VM from one vCenter to another

Now that we have our Universal Transport Zone that spans clusters across multiple vCenter servers it's time to create a Universal Logical Switch, attach two virtual machines to it and then vMotion one from the Palo Alto vCenter to the New York vCenter.  One thing to remember when creating any universal objects is that they need to be created on the NSX Manager that has the primary role.  If you try to do it whilst connected to an NSX Manager with the secondary role you will not see any Universal Transport Zones.  Log into the vSphere Web Client and navigate to Logical Switches within the Network & Security tab and create a new Logical Switch whilst ensuring you are connected to the NSX Manager with the primary role:

Once the switch has been created you will notice that it's VNI number falls inline with the range we specified within the Universal Segment ID Pool:

If you switch across to the NSX Manager with the secondary role you will also see the same Universal Logical Switch created with the same VNI number:

If we check the VDS portgroups you should see the newly created portgroup in both vCenters:

I have the following two VM's which I am going to attach to the Universal-Web-Tier-01 Logical Switch and power on ensuring that are both in the same vCenter:

WEB01 - 192.168.1.11

WEB02 - 192.168.1.12

As you can see we have layer 2 connectivity between the two virtual machines:

Now time to vMotion WEB02 from the Palo Alto vCenter (PA-VCSA-01) to the New York vCenter (NY-VCSA-01).  Right click on the VM and select Migrate:

Select the option to Change Compute Resources only and click Next (The same storage is available to both vCenters / hosts in my lab):

Click on the clusters tab and select the cluster you want to migrate the VM to and click Next.  In my example I am moving WEB02 from the PA-Compute cluster in PA-VCSA-01 to the NY-Compute cluster in NY-VCSA-01:

Select the folder to place the VM into and click Next:

Select the network you want to attach the VM to in the other vCenter.  In my example I'm connecting it to the same Universal Logical Network.  It would be nice for this to have been automatically selected for me:

Set the appropriate priority and click Next:

Verify your setting, click Next and watch the magic happen:

WEB02 has now been vMotioned from the Palo Alto vCenter across to the New York vCenters with no drop in connectivity:

The possibilities for this are endless especially around Disaster Recovery with Site Recovery Manager.

Creating a Universal Transport Zone in NSX 6.2

One of the new features in NSX 6.2 is the ability to span logical networks across multiple vCenters. In order to do this we now have the ability to create a Universal Transport Zone than can contain clusters from different vCenters. In my lab I'm going to create three new Transport Zones:

PA-TransportZone - A dedicated transport zone for the Palo Alto DataCenter that will contain the PA-Compute and PA-MGMT clusters.

NY-TransportZone - A dedicated transport zone from the New York DataCenter that will contain the NY-Compute and NY-MGMT clusters.

Universal-TransportZone - A dedicated transport zone that will contain all four clusters that span over two vCenters.

In order to achieve this we first need to create local and universal segment ID pools.  Segment ID pools are used to allocate VNI's (VXLAN Network Identifiers) to logical networks. I'm going to use the following VNI pools:

Palo Alto Segment ID Pool - 5000-5999
New York Segment ID Pool - 6000-6999
Universal Segment ID Pool - 10000-10999

This will allow me to create 1000 logical networks in Palo Alto and New York but then also another 1000 than can span both vCenters.

To start log into the vSphere Web Client and navigate to Installation -> Logical Network Preparation and then click on the Segment ID tab.  Ensure that you are connected to the NSX Manager that has the Primary Role:

Edit the setting and add the segment ID pools for the primary NSX Manager:

Click OK and then change to the secondary NSX Manager.  You should already notice that the Universal Segment ID's have already been populated.  Add the segment ID's for the secondary ensuring that they don't overlap with the Universal segment ID's:

Click on the Transport Zone tab and create a new Transport Zone.  The first Transport Zone we are going to create is the PA-TransportZone and add the two Palo Alto DataCenter clusters:

Now create a new Transport Zone but ensure you tick the option to Mark this object for Universal Synchronization and add the two Palo Alto DataCenter Clusters again:

We now have two Transport Zones:

Switch to the secondary NSX Manager and you will notice that we already have the Universal Transport Zone available.  Add the two New York DataCenter clusters to it:

Finally create the second local transport zone and add the two New York DataCenter clusters to it:

We should end up with a Local and Universal Transport Zone in both the Palo Alto and New York sites: