#cloud services platform

Today we are going to discuss one possible method for deploying the Cisco Nexus 1000V Virtual Supervisor Module (VSM) software appliance.  If you aren’t familiar with the Nexus 1000V or its components, you should take a look at the official product data sheet or my previous post on its conceptual operation (or both!)

Since the VSM is a software appliance, we need an underlying platform on which to run it.  You have two options available:  a virtualization environment such as VMware or Hyper-V; or, the Cisco Nexus 1110 appliance.  Both approaches will have its merits and one will fit better in your environment than the other.  The less comfortable your network engineers are with VMware, the more likely you will prefer the Nexus 1110 appliance.  If you simply can’t get the access needed within VMware, you’ll prefer the Nexus 1110 appliance.  And so on.  But, I’m not here to pitch products.  My goal is to get you up to speed.

Components and Functions

First and foremost, let’s get some terminology of the appliances out of the way.

Nexus 1110 Appliance [http://bit.ly/1CGuOfi]

This is the physical sheet metal you get to touch.  Like many of Cisco’s physical appliances (think ISE’s PAN, MNT, and PSN appliances), it is really a Cisco UCS C-series server.  Unfortunately, if you’ve been around this product long enough, you have to suffer through a marketing name change for this appliance. 

The NX-OS 4.x code train referred to this appliance as the “Virtual Services Appliance” (VSA).  

NX-OS 5.x refers to the appliance as the “Cloud Services Platform” (CSP). Don’t be fooled, though.  

It has components generally not found on a network device:

Cisco Integrated Management Controller (CIMC) [http://bit.ly/1MSEo02] - an out of band interface to remotely manage the server: namely, monitoring (temperature, power, fan speeds, hard drive failures) and console access (both KVM for the server AND serial console to the CSP appliance.

Keyboard, Video, and Mouse (KVM) - yes, just like your desktop except the appliance fits nicely into a rack.  This method of access is initially used to configure the CIMC and then rarely used afterwards in my experience.

There are two models of the Nexus 1110 appliance:  the 1110-S model with 6x1GE copper interfaces and the 1110-X model with 2x10GE SFP+ interfaces. This post focuses on the 1110-S model.

Nexus 1110 Cloud Services Platform software

The firmware that enables the appliance to support multiple virtual switch functions in a high availability (HA) model [using two CSP appliances, of course]. It is really just a Linux operating system (yes, more aspects of “servers” invading the network space) whose CLI has been modified to (sort of) resemble NX-OS. You don’t need to learn Linux to use it, don’t panic!

Nexus 1000V Virtual Supervisor Module (VSM) Open Virtualization Archive

An “OVA” is merely a packaging format for software (or “virtualized”) appliances. So, it’s simply a file but, in this case, you need the one specific for the Nexus 1010 and 1110 appliances.  Because, as if it wasn’t confusing enough yet, you have different VSM software appliance formats (the VMware specific ones are not relevant to these posts):

OVA for Nexus 1010/1110

OVA for VMware

ISO installer for VM created in VMware

This OVA is a file that you copy to the CSP appliance in order to deploy the VSM into a “virtual service blade”

Virtual Service Blade (VSB)

A virtual service blade is merely Cisco’s way of abstracting virtualization concepts and operations from the network engineer so that all he/she must do is “install a supervisor blade” into the CSP to deploy a new “switch” or service blade (NAM, etc).  The number of VSBs that you are allowed to “install” into the CSP depends on the model.  

Networks in the Nexus 1110 CSP Environment

The CSP appliances come in pairs so that you can have an active-standby HA environment.  Similar to the Nexus 1000V VSM, the CSP has management and control VLANs.  Originally (in the 4.2 VSA “days”), these management and control VLANs were shared by the appliance and all the VSBs.  That is no longer (necessarily) the case.  You can separate the management and control VLANs if you wish.  So, despite adding a lot of terminology, I will preface each VLAN with the environment to which it belongs:

CSP Management VLAN: This VLAN is used to permit you to connect to the management interface of the CSP appliances in order to manage the CSP.

CSP Management Interface: The interface in the CSP software that is created, assigned the Management IP address for the appliance, and used to receive connections via SSH.

CSP Control VLAN: Used by the CSP physical appliances to establish the HA relationship and pass heartbeats.

CSP Control Interface: Currently, the CSP only supports a Layer 2 based control plane (see references for more info).  As such, this interface is created in the CSP software and communicates at layer 2 only to discover the other CSP appliance in the HA pair.

There is a “data” VLAN that is referenced in all the documentation for the CSP. There is very little information in the deployment guides for the CSP about the data VLAN other than it is used by service blade appliances such as the NAM. It is generally outside the scope of a basic CSP deployment to configure the data VLAN.  I have not yet had the pleasure of using it.  I’ll post about it later once I do.

Wrap Up

This post is all about concepts and setting the foundation for the cloud services platform.  Next up, let’s start down the road of getting them powered up and configured.  A sneak peek to the process:

Rack and stack the appliances

Connecting the keyboard, video, and mouse to the appliance

Connecting the server management (CIMC) adapter network adapter

Power the device and configure the CIMC

Update CIMC and server firmwares

Update Nexus 1110 CSP firmware

Cable up CSP network ports and configure upstream ports

Configure Nexus 1110 CSP firmware