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.
That means it is done successfully.
If you click on the any network-1 or network-2 you will see following type of information
Now click on the net-2, you will see following screen.
Notice the Segment ID in the above networks. That is your VXLAN segment IDs is assigned automatically.
You can also verify it on Nexus 1000V VSM. The creation of the networks Silver-Net-1 and Silver-Net-2 trigger the allocation of a network segment. The segment configuration can be viewed by entering the command
# show nsm network segment.
These network segments are also configured with the IP pool information such as the subnet range and default gateway. This configuration can be verified by entering the command
# show nsm ip pool template.
Corresponding to a network segment, a bridge-domain is created which corresponds to a single virtual network. The segment ID for a bridge domain corresponds to the segment ID of the network that in the OpenStack dashboard. To view the bridge-domains enter the command show bridge-domain. The key points to note in this output are:
1. The segment mode is unicast-only. The Nexus 1000V supports an enhanced mode for VXLAN which does not require multicast in the underlay network
2. The segment ID matches the ID for the networks in the OpenStack dashboard
3. The virtual interfaces correspond to each bridge-domain
VXLAN requires each node in the network to have a Virtual Tunnel Endpoint (VTEP) configured. A VTEP is used as the source or destination of the encapsulated VXLAN packet. To view the bridge-domains associated with a VTEP enter the command
# show bridge-domain vteps
Configuring a Router to connect the networks
The click create router and following is what you will see
You see following
Now add interface to this router.
You will see following interface created
Now if you click on the 18088510 name of the interface, you will see following info.
Now repeat the steps above and created the second interface on the same logical router.
Shown in the following diagram
Cline on the second interface-ID
Verifying the Network Topology
Click on the network topology.
Launching Virtual Machine Instances
Leave access and security to default as shown below
But change the network tab options as follows
Leave volume default as shown below
Post creation is default too as shown below
Now click Launch on the above diagram.
And now do the same for the other network silver-net-2
Verify Network Connectivity between VM-1 and VM-2
This shows how Nexus 1000V for OpenStack will be consumed and used by tenant administrators.
The Nexus 1000V is based on two important pillars:
- Mobility of the network
- Non-disruptive operational model
For more information about the Cisco Nexus 1000V, visit http://www.cisco.com/go/nexus1000v
Most Frequently Used Terminologies and Acronyms
Nexus 1000V
Cisco Nexus 1000V is a distributed virtual switch. This is a multi-hypervisor switch supported on VMware ESXi, Microsoft Hyper-V and OpenStack KVM hypervisors.
OpenStack
OpenStack is opne source software for creating private and public clouds. OpenStack software controls large pool of compute, storage and networking resources throughout a datacenter, managed through a dashboard or via OpenStack API.
KVM Hypervisor
KVM (Kernel Virtual Machine) is a Linux kernel module that allows a user-space program to utilize the hardware virtualization features of various processors. One can run multiple virtual machines running unmodified Linux or Windows images.
Virtual Tunnel Endpoint
These interfaces represent the VTEPs on each host that function as the VXLAN tunnel endpoint for the overlay network. A VTEP is required on every node that will participate in the overlay. Both compute nodes and the network node have a VTEP configured.
Credits:
The author of this document is Shahzad Ali, Cisco Systems Cloud and Network Virtualization Group. This document is written using Cisco’s Demonstration lab equipment and resources.
