NSX per-VM licensing compliance

I had a customer with a production cluster of around 100 VMs. They needed to segment off a few VMs due to PCI compliance, and were looking at a large expense to create a physically separate PCI DMZ. I suggested instead the purchase of our per-VM NSX solution. This is a great cost-effective way to license NSX when you’re in a situation like this that doesn’t require socket licenses for your whole cluster.

The problem with per-VM licensing is with compliance. VMware doesn’t have a KB explaining a way to make sure you aren’t using more than the number of licenses that you bought. If you add a 25-pack of NSX licenses to a cluster with 100 VMs in it, the vCenter licensing portal will show that you’re using 100 licenses but only purchased 25. VMware KB 2078615 does say “There is no hard enforcement on the number of Virtual Machines licensed and the product will be under compliance.” However, this post is related to the way per-socket licensing displays when you add it to vCenter, not related to per-VM pricing.

I’ve had a few conversations with the NSX Business Unit (NSBU) and the intent of per-VM licensing is to allow customers to use the NSX distributed firewall without physically segmenting clusters. You can run NSX-protected VMs in a cluster alongside non-NSX-protected VMs. However, you have to take some steps to ensure that you’re remaining in licensing compliance. This post shows you how to do it.

One way to do this is to avoid using ‘any’ in your firewall rules. If all of your firewall rules are VM to VM or security group to security group, all you have to do is keep the total VM count below your purchased VM count. It is difficult to craft a firewall policy without using ‘any’, though this is the simplest method if your requirements lend themselves to this method.

An alternative way is to use security tags. It’s a bit more involved but lets you have precise control over where your NSX security policy is applied.

First, I create two custom tags, Custom_NSX.FirewallDisabled and Custom_NSX.FirewallEnabled

nsx-custom-tags

I then assigned tags to my VMs as shown below. The disadvantage to this method is you have to keep making sure that you security tag VMs. But it does make rule writing easier. I’m only creating two groups – NSX enabled and disabled. However, there’s nothing stopping you from creating multiple tags – maybe you have a DMZ1 and DMZ2, maybe PCI and HIPAA are separate tags.

In this case, I assign all of my PCI VMs the FirewallEnabled tag and the rest of my VMs the FirewallDisabled tag.

assign-security-tag

Now, instead of going to the Firewall section, I go to Service Composer. Don’t be confused by the fact that the security groups already exist – I took the screenshot of the Security Groups tab after I created the groups.

service-composer

First, I create an NSX_Disabled group with a dynamic membership of CUSTOM_NSX.FirewallDisabled.

custom-disabled

Next, I create an NSX_Enabled security group with a dynamic membership of CUSTOM_NSX.FirewallEnabled

custom-enabled

I then specifically exclude NSX_Disabled from the NSX_Enabled group. This guarantees that no firewall rules can touch my excluded VMs.

nsx-exclude

I create a new security policy in Service Composer

new-security-policy

In the Firewall Rules section, NSX has something called “Policy’s Security Groups”.  If we assign the policy to the NSX_enabled security group, we can safely use an ‘any’ rule as long as the other side is ‘Policy’s Security Groups’. So source could be ‘any’ if dest is Policy’s Security Groups, or dest could be ‘any’ if source is Policy’s Security Groups. The security group we made enforces that NSX won’t apply rules on VMs that aren’t in the NSX_enabled group.

policys-security-groups

I then apply my new policy to the NSX_Enabled security group.

policy_apply security-group-select

Doing a security policy this way is a bit more involved than simply using the Firewall section of NSX, but it’s worth considering. It’s a perfect way to ensure 100% compliance in a per-VM model. It’s also helping you unlock the power of NSX – all you have to do is security tag VMs and they automatically get their security policy.

 

Cisco support – a colossal failure

I’m so fed up with Cisco that I’m ready to switch platforms. Maybe I’ll start building networks by following the Microsoft certification route “Your core network router is a Windows 2008 Server running Microsoft Routing and Remote Access…”

The Cisco debacle began as I attempted to expand a pair of Cisco MDS 9124 fibre switches from 8 to 16 ports. We ordered quantity 2 of SKU M9124PL8-4G-AP=. This gives you an expansion license for the additional 8 ports as well as 8 SFP transceivers. The order arrived on a Monday. I unpacked everything and installed the SFPs. Now I moved on to the licensing.

I plugged the PAK from the first box into the Cisco website and it came back as a bad key. The second one was also bad. I then contacted Cisco licensing to assist as neither PAK worked. Cisco soon issued me license keys, but they failed to install. The switches reported “Installing license failed, not compatible with the platform MDS9124.” I reported this back to Cisco Licensing and got “Please be informed that those are the licenses found to be associated for those PAK Numbers you provided as shown on the claim certificate you provided. Please contact your Account Team or local Cisco Sales Engineer for assistance determining what license are compatible with your switches. My apologies for we at Licensing Team only issue, resend and re-host licenses based on entitlements being provided to us and your understanding on this is appreciated.

I then engaged Cisco TAC, the TAC engineer said that the PAK was for the 9124 model designed for a HP blade chassis. I looked at the PAK that was included in the box and sure enough it was an MDS 9124 kit for HP. But the order we placed was correct, the SKU on our wholesaler’s paperwork was correct, and Cisco even had a record of the correct purchase. Apparently somebody in the Cisco factory stuck the wrong piece of paper in the box.

The TAC engineer was certain that licensing could fix this issue, so he kicked the ticket back to them with his notes. Licensing again refused to assist, saying they could not issue a new license. At this point it had been 3 days of back and forth with Cisco. I went back to our Cisco partner sales rep, but he was unable to get anybody with authority to fix the problem. Finally we ended up back at the wholesaler. They spent two business days using their Cisco contacts to attempt resolution without success.

9 days after my initial contact with Cisco, the wholesaler ended up issuing two new certificates and eating the cost. Cisco gave the runaround to 1) My client, 2) My company, a Gold Partner and Academic Partner of the Year and 3) Ingram Micro, Cisco’s Global Distribution Partner of the Year. Cisco wasted all of our time and money, and ended up getting paid twice for the product.

One week later, I received an e-mail from a Cisco Licensing manager. Part of it said On cases like this, your point of sales should check if the Sales Order that they got from Cisco has the exact SKU that you ordered included in the SO#. If yes, it would be with manufacturing team providing the incorrect license claim certificate, which we could fix by escalating internally.This is exactly what I wanted when I contacted Cisco initially. All the paperwork was correct, but the licensing paperwork was not. This seemed to be an insurmountable challenge for the licensing team. My email chain with the manager ended with Rest assured, this is an isolated incident which has been reported internally on our end and I do hope that this does not happen to you again in the future.