NSX 6.2 for vSphere Released

Just a quick post to let you know that NSX 6.2 for vSphere has GA'd and available to download on vmware.com site.  The release notes can be found here. So, what's new in 6.2

NSX vSphere 6.2 includes the following new and changed features:

Cross vCenter Networking and Security

• NSX 6.2 with vSphere 6.0 supports Cross vCenter NSX where logical switches (LS), distributed logical routers (DLR) and distributed firewalls (DFW) can be deployed across multiple vCenters, thereby enabling logical networking and security for applications with workloads (VMs) that span multiple vCenters or multiple physical locations.
• Consistent firewall policy across multiple vCenters: Firewall Rule Sections in NSX can now be marked as "Universal" whereby the rules defined in these sections get replicated across multiple NSX managers. This simplifies the workflows involving defining consistent firewall policy spanning multiple NSX installations
• Cross vCenter vMotion with DFW: Virtual Machines that have policies defined in the "Universal" sections can be moved across hosts that belong to different vCenters with consistent security policy enforcement.
• Universal Security Groups: Security Groups in NSX 6.2 that are based on IP Address, IP Set, MAC Address and MAC Set can now be used in Universal rules whereby the groups and group memberships are synced up across multiple NSX managers. This improves the consistency in object group definitions across multiple NSX managers, and enables consistent policy enforcement
• Universal Logical Switch (ULS) - This new functionality introduced in NSX 6.2 as a part of Cross vCenter NSX allows creation of logical switches that can span multiple vCenters, allowing the network administrator to create a contiguous L2 domain for an application or tenant.
• Universal Distributed Logical Router (UDLR) - This new functionality introduced in NSX 6.2 as a part of Cross vCenter NSX allows creation of distributed logical routers that can span multiple vCenters. The universal distributed logical routers enable routing across the universal logical switches described earlier. In addition, NSX UDLR is capable of localized north-south routing based on the physical location of the workloads.

Operations and Troubleshooting Enhancements

• New traceflow troubleshooting tool: Traceflow is a troubleshooting tool that helps identify if the problem is in the virtual or physical network. It provides the ability to trace a packet from source to destination and helps observe how that packet passes through the various network functions in the virtual network.
• Flow monitoring and IPFIX separation: In NSX 6.1.x, NSX supported IPFIX reporting, but IPFIX reporting could be enabled only if flow reporting to NSX Manager was also enabled. Flow monitoring with IPFIX functionality are included in NSX Manager in layer deployment. Starting in NSX 6.2.0, these features are decoupled. In NSX 6.2.0 and later, you can enable IPFIX independent of flow monitoring on NSX Manager.
• New CLI monitoring and troubleshooting commands in 6.2: See the knowledge base article for more information.
• Central CLI: Central CLI reduces troubleshooting time for distributed network functions. Commands are run from the NSX Edge command line and retrieve information from controllers, hosts, and the NSX Manager. This allows you to quickly access and compare information from multiple sources. The central CLI provides information about logical switches, logical routers, distributed firewall and edges.
• CLI ping command adds configurable packet size and do-not-fragment flag: Starting in NSX 6.2.0, the NSX CLI 'ping' command offers options to specify the data packet size (not including the ICMP header) and to set the do-not-fragment flag. See the NSX CLI Reference for details.
• Show health of the communication channels: NSX 6.2.0 adds the ability to create communication channel health. The channel health status between NSX Manager and the firewall agent, between NSX Manager and the control plane agent, between host and the NSX Controller can be seen from the NSX Manager UI. In addition, this feature detects when configuration messages from the NSX Manager have been lost before being applied to a host, and it instructs the host to reload its NSX configuration when such message failures occur.
• Standalone Edge L2 VPN client CLI: Prior to NSX 6.2, a standalone NSX Edge L2 VPN client could be configured only through OVF parameters. Commands specific to standalone NSX Edge have been added to allow configuration using the command line interface. The OVF is now used for initial configuration only.

Logical Networking and Routing

• L2 Bridging Interoperability with Distributed Logical Router: With VMware NSX for vSphere 6.2, L2 bridging can now participate in distributed logical routing. The VXLAN network to which the bridge instance is connected, will be used to connect the routing instance and the bridge instance together.
• Support of /31 prefixes on ESG and DLR interfaces per RFC 3021
• Support of relayed DHCP request on the ESG DHCP server
• Ability to keep VLAN tags over VXLAN
• Exact Match for Redistribution Filters: The redistribution filter has same matching algorithm as ACL, so exact prefix match by default (except if le or ge options are used).
• Support of administrative distance for static route
• Ability to enable/disable uRPF check per interface on Edge
• Display AS path in CLI command show ip bgp
• HA interface exclusion from redistribution into routing protocols on the DLR control VM
• Distributed logical router (DLR) force-sync avoids data loss for east-west routing traffic across the DLR.
• View active edge in HA pair: In the NSX 6.2 web client, you can find out if an NSX Edge appliance is the active or backup in an HA pair.
• REST API supports reverse path filter(rp_filter) on Edge: Using the system control REST API, rp_filter sysctl can be configured, and is not exposed on REST API for vnic interfaces and sub-interfaces. See the NSX API Guide for more information.
• Behaviour of the IP prefix GE and IP prefix LE BGP route filters: In NSX Release 6.2, the following enhancements are made to BGP route filters:
• For the null route network address (defined as ANY or in CIDR format 0.0.0.0/0), less-than-or-equal-to (LE) and greater-than-or-equal-to (GE) keywords are no longer allowed. In previous releases, these keywords were allowed.
• LE and GE values in the range 0-7 are now treated as valid. In previous releases, this range was not valid.
• For a given route prefix, you can no longer specify a GE value that is greater than the specified LE value.

Networking and Edge Services

• The management interface of the DLR has been renamed to HA interface. This has been done to highlight the fact that the HA keepalives are going through this interface and issues on this interface can result in split-brain situation.
• LB Health Monitoring Improvements: Delivers granular health monitoring, that reports information on failure, keeps track of last health check and status change, and reports failure reasons.
• Support VIP and Pool port range: Enables LB support for applications that require a range of ports.
• Increased number of VIP: VIP support increased up to 1024.

Security Service Enhancements

• New IP address discovery mechanisms for VMs: Authoritative enforcement of security policy based on VM names or other vCenter-based attributes requires that NSX know the IP address of the VM. In NSX 6.1 and earlier, IP address discovery for each VM relied on the presence of VMware Tools (vmtools) on that VM or the manual authorization of the IP address for that VM. NSX 6.2 introduces the option to discover the VM's IP address using DHCP snooping or ARP snooping. These new discovery mechanisms enable NSX to enforce IP address-based security rules on VMs that do not have VMware Tools installed.

Solution Interoperatibility

• Support for vSphere 6.0 Platform Services Controller topologies: NSX now supports external Platform Services Controllers (PSC), in addition to the already supported embedded PSC configurations.
• Support for vRealize Orchestrator Plug-in for NSX 1.0.2: With NSX 6.2 release, NSX-vRO plug-in v1.0.2 is introduced in vRealize Automation (vRA).

Migrating Workloads into NSX

In this post I'm going to show you how to migrate virtual workloads from a VLAN backed portgroup into NSX and onto a VXLAN backed portgroup (Logical Network).  I've setup two VM's connected to a VLAN backed portgroup called Compute-VLAN14-Test and my router (RouterOS) has an L3 interface in this VLAN (10.1.14.1).  The VM's have an IP address on the 10.1.14.0/24 network and their default gateway is 10.1.14.1:

The plan is to create a new Logical Network (VXLAN backed portgroup) called Test-Network within NSX and then bridge this logical network and the VLAN and seamlessly migrate workloads across. The default gateway will remain on the physical router for external connectivity:

Once all workloads have been migrated the L3 interface the on physical router will be disabled and the logical network will be connected to the Logical Distributed Router (LDR) and an IP address of 10.1.14.1 will be assigned to that interface. Since I have OSPF configured between the LDR and the EDGE and BGP between the EDGE and the physical router (RouterOS) the 10.1.14.0/24 network will be advertised to the physical router and L3 connectivity will be restored:

This will allow us to migrate workloads into NSX and onto a logical network without having to re-ip any VM's and minimize outages to the application.  With that, lets get started.  We can see that the two VM are connected to the Compute-VLAN14-Test portgroup

We are now going to create the logical network by logging into the vSphere Web Client, navigating to the Networking and Security Plugin and then selecting logical switches.  I've created a new logical network called Test-Network and assigned it to my transport zone:

Now, I'm going to create the bridge between the Compute-VLAN14-Test portgroup and the logical network Test-Network. Bridging is configured on an LDR so I'm going to navigate to NSX Edges, modify my LDR and go to the Bridging tab and add a new Bridge.  In order to add a new bridge you need to supply a name and then the logical network and portgroup that you want to bridge together and then publish the changes:

You might have noticed that I'm bridging MGMT-VLAN14-Test instead of Compute-VLAN14-Test.  This is because I have a separate vSphere Distributed Switch for Management and Compute and my LDR resides in the management cluster.  I'm now going to move TEST01 onto the new logical network and show that we still have L2 and L3 connectivity:

We now have the following topology:

We are now going to change the network for TEST02 and attach it to the Test-Network, disable the L3 interface on the physical router and attach the Test-Network to the LDR and give it an IP address of 10.1.14.1.  After this the network will converge and the 10.1.14.0/24 network will be advertised to the EDGE and then back to the physical router.  First thing to do is disable the L3 interface on the physical router.  As you can see the interface has been disabled, the route has been removed from the routing table and I've lost connectivity to TEST01 and TEST02 (My client IP is in the 10.1.9.0/24 range):

We now go back into the LDR and add an interface into the Test-Network and assign it an IP address of 10.1.14.1:

As soon as this is completed L3 connectivity has been restored and the route has been advertised back up to the physical router:

Final task is to remove the bridge on the LDR and decommission the Compute-VLAN14-Test portgroup and VLAN from the physical infrastructure.  The default gateway for the VM's is the LDR and we have migrated our workloads with minimal downtime and no IP address changes. We are now left with the following topology:

How awesome is NSX

NSX Fundamentals Online - Thursday 6th August 16:00 - 19:00 UK Time

VMware is hosting an NSX Fundamentals Online training course on Thursday 6th August from 16:00 to 19:00 UK time.  You can register for the event here and they are normally available to view on demand after the event so if you can't make it you wont miss out.  The agenda is as follows:

VMware NSX Fundamentals Online is a three-hour virtual event designed for IT professionals where you will discover how to bring the operational model of a virtual machine to your data center network, so you can transform the economics of network and security operations.

Configuring OSPF / BGP Authentication within NSX and RouterOS

A little tip Andy Kennedy (Twitter) gave in one of his internal presentations was to use authentication when configuring a routing protocol during a Proof of Concept to avoid redistributing routes into a production environment in the event of a misconfiguration.  This is just a quick post to show you how to configure authentication when using OSPF and BGP within NSX and RouterOS.  My lab environment currently looks like this:

I have OSPF configured between my DLR (PA-DLR-01) and my Edge (PA-EDGE-01) and BGP between my Edge (PA-EDGE-01) and my physical router (Mikrotik) which runs RouterOS.  To configure OSPF authentication on the DLR simply fire up the vSphere web client and navigate to Networking & Security -> NSX Edges -> DLR you want to configure -> Routing -> OSPF and then modify the area definition.  Change the authentication type to Password and then enter a password, click OK and then publish the changes:

At this point routes should stop distributing into the Edge as we need to configure the same password on the Edge (PA-EDGE-01).  Once configured on Edge routes should start populating again.  We can also run a show ip ospf interface on the edge and see that authentication is enabled:

To configure authentication for BGP on the edge navigate to Networking & Security -> NSX Edges -> Edge you want to configure -> Routing -> BGP and edit the neighbour you want to configure for authentication.  In the password field enter the required password, click OK and then publish the changes:

Route distribution will stop from the Edge into the physical router and vice-versa until we configure authentication within the physical router.  To do this is RouterOS simply log in and navigate to Routing -> BGP -> Peers and modify the Edge peer.  Within the TCP MD5 Key field enter the same password you used on the Edge and click OK:

Once you do this routes should start redistributing again.  Now if the Edge uplink interface is accidentally connected to the wrong VLAN backed portgroup with a physical router with the same neighbour IP address we will not accidentally redistribute routes into the production environment.

Configuring BGP between RouterOS and an NSX Edge

I use a RouterBOARD RB715G in my homelab as my router and layer 3 switch which has been absolutely rock solid since I purchased it.  I'm probably not even using 10% of it's functionality but it's definitely worth the money.  When testing NSX and creating logical networks I always end up creating static routes into the NSX environment so I can test connectivity from my physical workstation so I decided to configure BGP from the Edge to the MikroTik.  The diagram below shows my current network layout.  I have OSPF configured from the distributed logical router (PA-DLR-01) to the Edge (PA-Edge-01)

Below are the results from the show ip route command on both the Edge and the DLR:

PA-Edge-01:

PA-DLR-01:

Below is the route information from my Mikrotik router:

As you can see OSPF is populating the routes from PA-DLR-01 into PA-Edge-01.  Now it's time to configure BGP between PA-Edge-01 and Mikrotik.  I'm not going to show you how to configure BGP on the Edge as there are numerous blog articles out there that document this process.  To configure BGP on the Mikrotik router log in and navigate to Routing and then BGP and edit the default entry in the Instances tab:

Ensure you have entered a router ID and Redistribute Connected and Redistribute Static options are ticked (Or whatever you want to redistribute via BGP).  Navigate to the Peers tab and add a new entry:

Give the new entry a name and then enter the IP address of the Edge, in my case it's 10.201.1.41. Enter the Remote AS number and then set the Default Originate option to Always and click OK.  If everything is configured correctly all directly connected routes to the PA-WebTier, PA-AppTier and PA-DBTier should appear in the Mikrotik's route list and any new networks directly connected to the PA-DLR-01 should appear as well:

PA-Edge-01

PA-DLR-01

Mikrotik:

Thanks to Geordy Korte (Blog | Twitter) for the assistance in configuring the Mikrotik router.

Decommission old vCenter Server 6.0 Appliance from Platform Services Controller

I deployed a temporary vCenter Server 6.0 Appliance to my existing lab to test the cross vCenter vMotion functionality across three vCenter appliances.  Once I validated this I no longer had the need for the VCSA and didn't want it taking up valuable resources in my lab.  My OCD also kicked in and I wanted to get rid of the associated error message that displayed within the web client:

As a good techie I searched for the solution but not couldnt find anything.  I posted the issue to twitter and legend William Lam (Blog | Twitter) was kind enough to post a link to a VMware KB article that explained the command:

If you've done what I've done and forgotten which VCSA was the PSC when you SSH in it should tell you at the logon screen:

After following the KB article I was able to successfully remove the decommissioned VCSA from the PSC and I no longer receive the warning within the Web Client.  I did have a slight hiccup in that the name of the VCSA in the error above was in capitals but inside the component manager database it was all lower case so the command had to be in lower case

North East VMUG - Thursday 21st May

The next North East VMUG will be held on Thursday 21st May at the Centre for Life in Newcastle:

International Centre for Life 

Marlborough Suite - Conference and Banqueting 

Times Square

Newcastle

NE1 4EP

You can register for the event here

The agenda is currently as follows:

9:30      Event Registration
10:00    Welcome & Agenda – VMUG Leadership
10:15    VMware Update – Michael Armstrong (Blog | Twitter)
11:00    vCloud Air DR (DRaaS) – Dave Hill (Blog | Twitter)
12:00    Lunch
12:30    Tegile – Gold Sponsor Presentation
13:30    Break
13:45    Data Centre Migration Project – Alan Burns
14:45    Break
15:00    Reflections on Convergence  – David Thomas
15:45    Break
16:00    EVO:RAIL – Mike Laverick (Blog | Twitter)
16:45    Closing statement and raffle
17:00    Onwards to vBeers

Big thanks to our Gold sponsor Tegile and Silver sponsor 10Zig