window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-16803030-1');

End to end virtual network security with the Cisco Nexus VSG

So I’ve been spending a lot of time in our lab with the Cisco Nexus Virtual Security Gateway. I have come to the conclusion that it rocks! Finally, the virtual infrastructure is no longer treated as a second class citizen when it comes to securing network traffic between virtual machines. We are at a point now with the Cisco VSG that we can have robust Cisco infrastructure, including security, from the upstream physical network to the virtual network.

The Cisco Nexus VSG builds upon the Nexus 1000v distributed virtual switch and communicates with the Virtual Ethernet Modules in the Nexus 1000v to provide a very robust security policy engine that can perform granular filtering and matching on a number of parameters. For example:

  • Network (ip address, port number, etc.)
  • VM (VM Name, Installed OS Name, Cluster, Host, Zone)

Yep, that’s right, I said VM. Since the Cisco VSG integrates with the vSphere API’s and vCenter, you can filter on items like a virtual machine name or partial name, installed OS, cluster, etc. This is very powerful. I no longer have to rely on network and IP rules alone to filter traffic between virtual machines. This is a more intelligent approach to filtering that really highlights the synergies that Cisco and VMware have established. Best of all, once it is set up everything is managed from a single Cisco Virtual Network Management Center (VNMC) instance. This web-based management tool let’s you manage multiple Virtual Security Gateway instances. Let’s look at a simple example of how easy it is to perform traffic filtering in the virtual infrastructure with the Cisco VSG.

Topology and Components:

  • vSphere 4.1 Enterprise Plus Host Servers
  • Cisco VNMC VM
  • Cisco Nexus 1000v Infrastructure
  • Cisco VSG Infrastructure
  • tenanta-srv1 VM
  • tenanta-srv2 VM
  • tenantb-srv1 VM
  • tenantb-srv2 VM

The goal of this configuration is to allow the following communication flows:

  • tenanta-srv1 and tenanta-srv2 should communicate
  • tenantb-srv1 and tenantb-srv2 should communicate
  • The Tenant A servers(tenanta-srv1 and tenanta-srv2) should not be able to communicate with the Tenant B servers (tenantb-srv1 and tenantb-srv2)
  • Anyone else should be able to communicate with both the Tenant A and Tenant B servers
  • There is a further caveat that the Tenant A and Tenant B servers are both on the same subnet (don’t worry these servers belong to the same company Winking smile )

Below are the network settings:

  • tenanta-srv1 VM – 10.91.41.200
  • tenanta-srv2 VM – 10.91.41.201
  • tenantb-srv1 VM – 10.91.41.202
  • tenantb-srv2 VM – 10.91.41.203
  • a client with another ip address

Here are the general steps for setting up this scenario once the Cisco VSG infrastructure is in place:

  • Create a tenant
  • Assign the VSG to the tenant
  • Create a zone each for the Tenant A and Tenant B servers (these zones match VM’s with names that contain “tenanta” and “tenantb” respectively)
  • Create a firewall policy for the VSG
  • Create a policy set that includes the policy
  • Bind the policy set to the VSG
  • Bind the tenant to a port-profile so that any VM that is on that port-profile is filtered with the policy rules

Below are the screenshots of the results after the VSG was configured.

These are the only rules that are required for the communication flows.

image

 

Here is what the port-profile looks like on the Nexus 1000v. Notice the org and vn-service entries. This means that this port profile is VSG aware.

image

 

The ICMP traffic from the Tenant A Servers.

image

image

ScreenClip

ScreenClip(1)

ScreenClip(2)

ScreenClip(3)

 

The ICMP traffic from the Tenant B Servers (same result as the Tenant A servers. Only one is shown here.)

ScreenClip(4)

ScreenClip(5)

ScreenClip(6)

 

Finally the results from the external client

ScreenClip(7)

ScreenClip(8)

ScreenClip(9)

ScreenClip(10)

 

As you can see, we achieved our goal with just three filtering rules. Also, we were able to leverage VM name filtering instead of IP filtering which allowed us to filter on the same subnet without resorting to naming each IP address or different port numbers. Very cool! The Cisco VSG is capable of many complex configurations combining both networking categories (ip, port number, etc.) and VM categories. This was just a quick example of what can be done. As always, if you have any questions or would like to see a live demo feel free to contact me.

Cisco Nexus 1000v and vSphere HA Slot Sizes

When implementing the Cisco Nexus 1000v, High Availability (HA) Slot Sizes can be affected on your vSphere Cluster. HA slot sizes are used to calculate failover capacity for HA when the “Host Failures” HA setting is used. By default the slot size for CPU is the highest reservation of CPU among all VM’s in the cluster (or 256 MHz if no per VM reservations exist). The slot size for Memory is the highest reservation of Memory among all VM’s in the cluster (or 0 MB + Memory Overhead if no per VM reservations exist). If you want to really dive further into HA and slot size calculations, I would highly recommend reading Duncan Epping’s HA Deepdive at Yellow-Bricks.com.

image

Each Cisco Nexus 1000v Virtual Supervisor Module (VSM) has a reservation of 1500 MHz on the CPU and 2048 MB on the Memory so that these resources can be guaranteed for the VSM’s. So, the slot size will be affected accordingly (1500 MHz for CPU and 2048 MB for Memory).

image

If you do not want your slot size affected and you do not want to enable the advanced slot size parameters das.slotCpuInMHz or das.slotMemInMB there is another solution that will allow you to still guarantee resources for the Nexus 1000v VSM’s and maintain smaller slot sizes.

Create a separate resource pool for each VSM with a CPU reservation of 1500 MHz and Memory reservation of 2048 MB.

image

 

image

Since slot sizes are only affected by per VM reservations, the resource pools will give you the desired results without increasing your HA slot sizes. I wouldn’t recommend doing this with too many VM’s as this turn into a management nightmare very quickly. However, for the two VSM’s in a Cisco Nexus 1000v infrastructure it is manageable.

Now your Nexus 1000v VSM’s are happy and you are not wasting resources in your HA cluster by calculating larger slot sizes than are required.

 

References

http://www.yellow-bricks.com/vmware-high-availability-deepdiv/

http://frankdenneman.nl/2010/02/resource-pools-and-avoiding-ha-slot-sizing/