Nokia/Nuage, Software Defined

Nuage VCS (Virtual Cloud Services) Build Part Two – VSC [Virtual Services Controller] & VRS [Virtual Route Switch]

Ok – Now that the VSD is build in Part One; Nuage VCS (Virtual Cloud Services) Build Part One – VSD [Virtual Services Directory], and we’re able to get to the Dashboard…Let’s go ahead and build the VSCs followed by the VRS.

DISCLAIMER: The material presented in this blog is for educational and training purposes only.  Neither the author(s) nor Ahaliblogger©   assume any liability or responsibility to any person or entity with respect to loss or damages incurred from the information contained in this blog.

VSC Prerequisites

Before deploying the VSCs, additional tasks are needed.  This should be done as part of your planning exercise. They are:

  • Management IP for VSC
  • Control/Data IP for VSC
  • Standard vSwitch and VLAN assignment on hosts where the VSC is deployed
  • Configuration on your Infrastructure Fabric to support VSC reachability between hosts
  • DNS entries for each VSC

Here is the Abstract to put context around what is being done

VSC Build

Before we deploy the VSC OVA, we need to create a few vswitches and port-groups to support control & data traffic southbound to the VRS as well to federate VSCs (this will be done through BGP a bit later).

As shown in the diagram, on my server 10.1.8.80 – I created a vSwitch2 and have two port-groups assigned to it.  Which has physical NICs assigned that is then connected to my ToRs. See VSD build for the diagram.

For this portgroup [VSC01-VLAN5] – it’s assigned to VLAN 5. On the other server 10.1.8.82 it will be assigned VLAN 6.

NOTE: I designed it this way to show the flexibility of the VSCes.  It shows the ability of using different subnets across the Data Plane [routing] and not limited to one VLAN. What’s the fun in using only one VLAN? J

So the vSwitch2 Settings on Server 10.1.8.80 are:

  • The properties tab – I left it 1500 MTU for now.
  • The security tab – I have all options set to ‘Accept’.
  • Traffic Shaping and Teaming are left as default. Not shown.

The settings for VSC01-VLAN5:

Deploy VSC OVA

Right the server, select Deploy OVF Template

Select the OVA. Choose singledisk OVA option:

Click Next and Define the VM name and DataCenter it will belong to.

Click Next…Review the details

Click Next and select your storage. I chose Thin Provisioned and my local storage on disk.

Click Next, Select your settings for Datapath and Management Network:

Click Next and at this point you’ll need to fill out some metadata information per the customized template:

NOTE: Before assigning values to this template – review your design and configuration aspects.

Here are the settings that are initially assigned:

  • uncheck DHCP
  • MGMT IP: 10.1.10.165/22
  • Static Route: 0.0.0/1 <MGMT DG IP>;128.0.0.0/1 <MGMT DG IP>
  • DNS Server1: <DNS IP#1>
  • DNS Server2: <DNS IP #2>
  • DNS Search Domain: domain.local
  • VSC Name: your.domain.local
  • XMPP Server: your.domain.local
  • SNTP Server: not be used, change to NTP when in console
  • Datapath IP: IP to reach your underlay fabric
  • System IP: leave as is
  • Datapath DFGW: DG to reach your fabric ToR
  • BGP Peer 1: leave as is
  • BGP Peer 2: leave as is
  • Autonoums Number: 65000
  • BGP Group: internal

Once all entries are completed, Click Next to review items and make sure they’re correct and click Finish to deploy VSC OVA.

Verification

After OVA is deployed – Power on VSC. It should take about five minutes to power on and update itself.  Try and ping the VSC using MGMT IP [10.1.10.165 for me]:

Now log in using SSH [admin/admin] and display the BOF [Boot Option File] information:

Verify if it all looks good. If not – you will have to tear it down and being from scratch.

Let’s ping the IP of our VSD and DG on the Fabric. And then the FQDN of the VSD [why must this be reachable?]

Notice the ‘router management’ syntax when issuing a ping to the VSD IP

Now let’s look at some details on the VSD via the VSC

So it looks like the VSD is available and functional. Did you notice the ‘*’ at the beginning of the line? This indicates that the VSC has registered with the VSD. If you don’t see this, then you might want to re-evaluate your DNS server, its entries, and if it’s operational.

Log into the VSD [ csproot/csproot/csp] and click on the ‘stat tick’ icon [monitoring console]on the top right

When you click on VSP, you’ll see the VSC.  And since the VSC has successfully registered with the VSD – it’s showing green.

On the right you can see more information about the VSC under the ‘DNA’ icon

Ok – the VSC is complete and you can deploy another following the steps above.

VSC Federations

After you’ve deployed you’re second VSC to your Nuage VCS solution – you must federate them. To accomplish this, BGP is used to form the federation of multiple VSC and synchronize the VSP network information. BGP is also used to exchange routing information with the data center provider edge router.

I’ll get to that after the installation of the VRSes.  If you’d like to view now click here.

To get more comprehensive – refer to the Nuage VSP install guide.

Next we’ll go ahead and deploy the VRS.

VRS Prerequisites

Just like the VSC, the VRS has some additional tasks.  This, again, should be done as part of your planning exercise. They are:

  • Management IP for VRS (used for data analytics by the VSD)
  • Control/Data IP for VRS
  • Standard vSwitch and VLAN assignment on hosts where the VSC is deployed
  • Configuration on your Infrastructure Fabric to support VSC reachability between hosts
  • DNS entries for each VRS – this is not really needed but I add them in for consistency

During the VSD/VCIN install – we configured a DVS and port-groups.  This DVS will bind VMs to the VRS to instantiate them in our VCS SDN plane.

VRS install

Deploy the OVF template on the server of choice and select the .vmdk & ovf files

Define the name, server to deploy on

Review and then select your storage [thin provisioned]

Now – the Networking aspect.  We have five connection points.  If you recall our DVS we created prior – here is where we need it.  The first three are required for the initial setup.  The others are more advanced features of the VRS. For the purpose of initial setup your network attachment should be similar to this.

NOTE: I chose VM Network for the last two, but won’t have them ‘connected’.

Next we’ll customize the template. There are 107 elements, a lot of which are default and should be left as is for now. Eighteen elements [18] should be filled out. Make sure the ‘personality’ is VRS.

Click finish to deploy.  After which power on the VRS.

Remember to deploy a VRS for each ESXi host in your cluster for which you want VMs in that cluster to be attached to your SDN overlay.

At this point – it’s best to install your license because your VRSes may not be visible without it.

VRS Verification

After deployment of the VRS, log into your VRS. Run the following command:
ovs-vsctl-show

You should have a screen similar to this.  You should see the IP [Dataplane] of your primary & secondary VSCs. What’s important is ‘is_connected: true’. This indicates the VRS is able to reach the VSC through its dataplane IP.

Next hop on your primary VSC. Run the following to verify the VRS has registered with it:
show vswitch-controller vswitches

Again you should see the Dataplane IP of the VRS, it’s personality, and if any VM/Containers are attached to it. So good so far?

Next – log into your VSD dashboard, navigate to the monitoring console and verify your VRS is showing green.

Note: Don’t mind the ‘red VSC’ – it’s residual from an incorrect deployment version…

Some stats of your VRS

As you can see the VRS is fully deployed and licensed!

You can now repeat the same process for each additional VRS you want to deploy on any ESXi host for which you want VMS to be part of your Nuage SDN overlay.

In later blog postings we’ll:

  • Deploy the Nuage Metadata Plugin for vCenter
  • Create a VSC enterprise, with zones and subnets…
  • Instantiate VMs using the Nuage Metadata Plugin
  • Deployment Openstack for CMS and VM instantiation into our Nuage SDN Overlay
  • Deploy SD-WAN capabilities
  • VCIN for automated VRS deployments
  • And other stuff

I hope you enjoyed this blog!

Please leave comments below

Happy Configuring.

About Alim H. Ali

1 thought on “Nuage VCS (Virtual Cloud Services) Build Part Two – VSC [Virtual Services Controller] & VRS [Virtual Route Switch]

Leave a Reply

Your email address will not be published. Required fields are marked *