cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Integrating and Consuming Nexus 1000V Virtual Switch For OpenStack / KVM

1581
Views
5
Helpful
1
Comments

Purpose

This document is intended as a reference for technical professionals for managing and operating OpenStack Cloud based Infrastructure as a Service (IaaS) using Cisco Nexus 1000V for OpenStack as their virtual switch. This document will guide how OpenStack admin can offer network, storage and compute services to tenant admins. And how tenant admins will consume those services and offer it to their customer within their organization.

 

Nexus 1000V For OpenStack Setup

 

Following are the versions being used in this document

  • Compute Node 1 (KVM Ubuntu 12.04 LTS)
  • Compute Node 2 (KVM Ubuntu 12.04 LTS)
  • Network Node (Ubuntu 12.04 LTS)
  • Openstack Controller (Grizzly. Ubuntu 12.04 LTS)
  • Build Server (Ubuntu 12.04 LTS)

 

Prerequisite

  • Base OpenStack installation and configuration is completed and admin is able to access the OpenStack Horizon Dashboard
  • Nexus 1000V VEM is installed
  • VSM is installed and configured with basic config

 

For detailed installation instructions, refer to Cisco Nexus 1000V For Ubuntu documentation.

 

OpenStack Cloud Admin Horizon Dashboard

 

Following is what admin sees when he/she logs into the OpenStack Horizon Dashboard browser based GUI interface.

 

 

Connecting to the Nexus 1000V VSM

 

SSH into Nexus 1000V VSM (Virtual Supervisor Module) and run show version command on the CLI

 

 

The Nexus-OS version is 5.2(1)SK1(2.1). "K" in the name indicates KVM Hypervsior version.

 

Verify the VEM modules on the VSM

 

Run show module command to display various components

 

 

 

 

Module 1 and Module 2 are reserved for the Virtual Supervisor Module. The Cisco Nexus 1000V supports VSM high availability. Hence, VSM virtual machine can run in an active/standby high availability mechanism. The output shows that there is only one VSM, that means it is a standalone deployment.

 

The rest of the modules (6 through 8) are Virtual Ethernet Modules (VEM). As per the network diagram above the VSM is managing the network node and the two compute nodes in the setup. As shown at the bottom of the screen, each VEM corresponds to a node, identified by the server IP address and name. This mapping of virtual line-card to a physical server eases the communication between the network and server team.

 

 

Verify service-policy configuration

 

Verify the default service-policy, that will be used for instances, created on this VSM. Nexus1000V allows for the segregation of network policy and service policy (ACL or Firewall Services for example). If services such as ACL or firewall were to be applied on an instance, the service-policy would be configured accordingly.

 

To view the default service-policy used in this lab enter following command

 

# show run port-profile Client-Policy

 

 

 

To check the restricted service policy configured, run the command

# show running-config port-profile restricted-client-policy

 

 

Creating a Network-Profile

 

Cloud admin can create network-profile by using OpenStack Horizon dashboard.

 

 

 

 

 

Also, notice that the lists of Policy Profiles are reflected in the bottom part of the page. This information is retrieved by OpenStack Controller from Nexus1000V VSM and displayed here. We will be consuming this Policy Profile when we create a new tenant network segment.

Now the admin should complete the creation of Network Profile by entering Name, Segment Type and other information as shown below

 

 

Following is what you see on the OpenStack Horizon dashboard after it is done.

 

 

The Sub-Type says “Unicast”, although we selected ‘Enhanced” when we were creating the network profile. Enhanced mode is in fact unicast. The normal mode of operation is multicast.

 

The Nexus 1000V supports an enhanced mode for VXLAN which does not require multicast in the underlay network.

You can also verify it on the Cisco Nexsu 1000V VSM (Virtual Supervisor Module) by ssh into the VSM virtual machine as shown below

# show nsm logical network

 

 

 

 

Create Networks in the Silver-Corp project

 

Now create networks in the silver-corp project.

Now we will login as silver-corp admin to create network for silver-corp company. This is imp to show that now you can give control to the tenant and he will be able to do the rest from here and can control his own department or orginzation.

Now we will login and silver-admin and following is how it shows on OpenStack dashboard.

 

 

Create overlay network segment in the Cloud

 

In this section, we will perform the following steps:

  • Create two VXLAN backed overlay networks.
  • Create a logical router and attach the two overlay networks to this router
  • Instantiate one Virtual Machine each on the two overlay networks
  • Test network connectivity between these VMs over the overlay network through the virtual router

 

 

 

 

 

 

 

 

 

 

After the above step, now submit “Create this network”.

Following is what you see after it is successful

 

 

 

 

Now create another network in the same siver-corp

 

 

 

Then following

 

 

 

 

After the above steps is done, you can click on the create subnet button now.

Now you see the following screen on OpenStack horizon dashboard.