In­te­grat­ing OpenDay­light VTN Man­ager with OpenS­tack

OpenDay­light is the largest open source SDN con­troller. The OpenDay­light vir­tual ten­ant net­work (VTN) is an ap­pli­ca­tion that pro­vides a multi-ten­ant vir­tual net­work on an SDN con­troller. This ar­ti­cle is a tu­to­rial on how to in­te­grate the OpenDay­light VTN

OpenSource For You - - Contents - By: Vinoth Ku­mar Sel­varaj The au­thor is a DevOps en­gi­neer at Clouden­ablers Inc., a cloud tech­nol­ogy startup based in Chen­nai. He has also worked as a book re­viewer with Pack­Pub Pub­lish­ers, for books re­lated to OpenS­tack. He blogs at http://www.hellovinoth

Avir­tual ten­ant net­work (VTN) al­lows users to de­fine the net­work with a look and feel of the con­ven­tional L2/ L3 net­work. Once the net­work is de­signed on VTN, it au­to­mat­i­cally gets mapped into the un­der­ly­ing phys­i­cal net­work, and is then con­fig­ured on the in­di­vid­ual switch, lever­ag­ing the SDN con­trol pro­to­col. The def­i­ni­tion of the log­i­cal plane makes it pos­si­ble not only to hide the com­plex­ity of the un­der­ly­ing net­work but also to man­age net­work re­sources bet­ter. This re­duces the re­con­fig­u­ra­tion time of net­work ser­vices and min­imises net­work con­fig­u­ra­tion er­rors.

The tech­ni­cal in­tro­duc­tion given above might seem com­plex to SDN begin­ners. In this ar­ti­cle, I have tried to be as sim­ple as I can, while teach­ing read­ers about VTN and its in­te­gra­tion with OpenS­tack.

For the pur­pose of this ar­ti­cle, I’m as­sum­ing read­ers have a ba­sic un­der­stand­ing of SDN. So let me start with

VTN di­rectly.

The SDN VTN Man­ager helps you to ag­gre­gate mul­ti­ple ports from the many un­der­ly­ing SDN-man­aged switches (both phys­i­cal and vir­tual) to form the sin­gle iso­lated vir­tual ten­ant net­work (VTN). Each ten­ant net­work has the ca­pa­bil­ity to func­tion as an in­di­vid­ual switch.

For ex­am­ple, con­sider that you have two phys­i­cal switches (say, s1 and s2) and one vir­tual Open vSwitch (say, vs1) in your lab en­vi­ron­ment. Now, with the help of the VTN Man­ager, it is pos­si­ble to group (ag­gre­gate) the three ports (say p1, p2 and p3) from switch s1 — i.e., s1p1, s1p2, s1p3; two ports from switch s2 — i.e., s2p1 and s2p2; and two ports from the vir­tual switch vs1 — i.e., vs1p1 and vs2p2, to form a sin­gle switch en­vi­ron­ment (say, VTN-01).

This means, vir­tu­ally, the group (ten­ant) named

VTN-01 is one switch with seven ports (s1p1, s1p2, s1p3, s2p1, s2p2, vs1p1 and vs2p2) in it. This VTN-01 will act ex­actly like a sin­gle iso­lated switch with the help of flows con­fig­ured in the ports of all three switches by the OpenDay­light VTN Man­ager.

The above ex­am­ple ex­plains the con­cept called port map­ping in VTN, and will help begin­ners to un­der­stand the ba­sic con­cept bet­ter. It will also help them to com­pare all other VTN con­cepts like VLAN map­ping and MAC map­ping.

VTN OpenS­tack in­te­gra­tion

There are sev­eral ways to in­te­grate OpenDay­light with OpenS­tack. This ar­ti­cle will fo­cus on the method that uses VTN fea­tures avail­able on the OpenDay­light con­troller. Dur­ing in­te­gra­tion, the VTN Man­ager works as the net­work ser­vice provider for OpenS­tack.

The fea­tures of VTN Man­ager em­power OpenS­tack to work in a pure Open­Flow en­vi­ron­ment, in which all the switches in the data plane are an Open­Flow switches. You could also re­fer to my blog on ‘OpenDay­light In­te­gra­tion with OpenS­tack us­ing OVSDB’ from the link

http://www.clouden­ablers.com/blog/open­day­light­in­te­gra­tion-with-opens­tack/.

The re­quire­ments are:

OpenDay­light Con­troller

OpenS­tack Con­trol Node

OpenS­tack Com­pute Node

OpenDay­light sup­port for OpenS­tack net­work types

Till the Boron re­lease, OpenDay­light (ODL) only sup­ported‘Lo­cal’net­work type in OpenS­tack and there was no sup­port for VLAN. You may won­der why the de­vel­op­ers never speak about VxLAN and GRE tun­nelling net­work types sup­port. You can answer that ques­tion if you re­call the ex­am­ple I men­tioned at the be­gin­ning of this ar­ti­cle.

To re­cap, I said that with the help of the VTN Man­ager, the user can group mul­ti­ple ports from mul­ti­ple switches in the in­fra­struc­ture to form a sin­gle iso­lated net­work.

Let’s com­pare this with our OpenS­tack en­vi­ron­ment, which has two Open vSwitches in­stalled in the con­troller and com­pute node.

1. When­ever a new net­work is cre­ated in OpenS­tack, VTN Man­ager cre­ates a new VTN in ODL.

2. When­ever a new sub-net­work is cre­ated, VTN Man­ager han­dles it and cre­ates a vBridge un­der the VTN. vBridge is noth­ing but the vir­tual switch.

3. When a new VM is cre­ated in OpenS­tack, the ad­di­tion of a new port in the Open vSwitch of the com­pute node is cap­tured by VTN Man­ager, and it cre­ates a vBridge in­ter­face in the newly cre­ated vBridge and maps that Open vSwitch port with the par­tic­u­lar vBridge port.

4. In this case, the port (say, vs1p1) of the DHCP agent in the Open vSwitch of the con­troller node and the port (vs2p1) of the VM in the com­pute node are iso­lated from the ac­tual Open vSwitch, us­ing the flow en­tries from the OpenDay­light VTN Man­ager, to form a new vir­tual switch en­vi­ron­ment called the vir­tual ten­ant net­work.

5. When the packet sent from the DHCP agent reaches the OpenS­tack con­troller’s Open vSwitch port vs1p1, then flow en­tries will tell the port vs1p1 to for­ward the packet to the com­pute node's Open vSwitch port vs2p1 us­ing the un­der­ly­ing phys­i­cal net­work. This packet will be sent as a reg­u­lar TCP packet with a source and des­ti­na­tion MAC ad­dress, which means that the traf­fic cre­ated in one net­work can be sent as a reg­u­lar packet across the con­troller and com­pute node with­out any tun­nelling pro­to­col.

6. This ex­plains why sup­port for VxLAN and GRE net­work types is not re­quired.

LAB set-up lay­out

The VTN fea­tures sup­port mul­ti­ple OpenS­tack nodes. Hence, you can de­ploy mul­ti­ple OpenS­tack com­pute nodes.

In the man­age­ment plane, OpenDay­light con­troller, OpenS­tack nodes and Open­Flow switches (op­tional) should com­mu­ni­cate with each other.

In the data plane, Open vSwitches run­ning in OpenS­tack nodes should com­mu­ni­cate with each other through phys­i­cal or log­i­cal Open­Flow switches (op­tional). Core Open­Flow switches are not manda­tory. There­fore, you can di­rectly con­nect to the Open vSwitches.

You may need to dis­able the fire­wall (UFW) in all the nodes to re­duce the com­plex­ity.

In­stalling OpenS­tack with the Open vSwitch con­fig­u­ra­tion

In­stalling OpenS­tack is beyond the scope of this ar­ti­cle; how­ever, get­ting started with a min­i­mal multi-node OpenS­tack de­ploy­ment is rec­om­mended.

To help speed up the process, you could use my fully au­to­mated bash script for in­stalling the OpenS­tack-Mi­taka set-up at https://github.com/Clouden­abler­sPvtLtd/opens­tack-setup.

Note: This script will in­stall OpenS­tack and con­fig­ure the Linux bridge for net­work­ing. But for the VTN in­te­gra­tion to work in OpenS­tack, we need net­work con­fig­u­ra­tion with Open vSwitch. So, you must unin­stall the Linux bridge set­tings and re­con­fig­ure with Open vSwitch.

Af­ter the suc­cess­ful OpenS­tack in­stal­la­tion, run the san­ity test by per­form­ing the fol­low­ing op­er­a­tions.

Cre­ate two in­stances on a pri­vate sub­net. Then add the float­ing IP ad­dress from your pub­lic net­work, ver­ify that you can con­nect to them and that they can ping each other.

In­stalling OpenDay­light

The OpenDay­light con­troller runs in a JVM. The OpenDay­light-Boron re­lease re­quires OpenJDK8, which you can in­stall us­ing the com­mand given be­low:

$apt-get in­stall open­jdk-8-jdk

Down­load the lat­est OpenDay­light-Boron pack­age from the of­fi­cial repo, as fol­lows:

$wget https://nexus.openday­light.org/con­tent/repos­i­to­ries/ openday­light.re­lease/org/openday­light/in­te­gra­tion/ dis­tri­bu­tion-karaf/0.5.1-Boron-SR1/dis­tri­bu­tion-karaf-0.5.1Boron-SR1.tar.gz

Un­tar the file as the root user, and start OpenDay­light us­ing the com­mands given be­low:

$ tar -xvf dis­tri­bu­tion-karaf-0.5.1-Boron.tar.gz $ cd dis­tri­bu­tion-karaf-0.5.1-Boron.tar.gz $ ./bin/karaf

Now, you should be in OpenDay­light’s console. In­stall all the re­quired fea­tures, as fol­lows:

openday­[email protected]> fea­ture:in­stall odl-vtn-man­agerneu­tron openday­[email protected]> fea­ture:in­stall odl-vtn-man­ager-rest openday­[email protected]> fea­ture:in­stall odl-md­sal-api­docs openday­[email protected]> fea­ture:in­stall odl-dlux-all

Fea­ture in­stal­la­tion may take some time. Once the in­stal­la­tion is com­plete, you can check whether every­thing is work­ing fine by us­ing the fol­low­ing curl call:

$ curl -u ad­min:ad­min http://<ODL_IP>:8080/con­troller/nb/v2/ neu­tron/net­works

The re­sponse should be an empty net­work list if OpenDay­light is work­ing prop­erly.

Now, you should be able to log into the DLUX in­ter­face on http://<ODL_IP>:8181/in­dex.html.

The de­fault user­name and pass­word are ad­min/ ad­min. Ad­di­tion­ally, you could find use­ful log de­tails at the fol­low­ing lo­ca­tion:

$ tail -f /<di­rec­to­ry_of_odl>/data/log/karaf.log

$ tail -f /<di­rec­to­ry_of_odl>/logs/we­b_ac­cess_log_2015-12.txt

Now, you have a work­ing OpenDay­light-Boron set-up. Let’s get into the in­te­gra­tion part.

Con­fig­ur­ing OpenS­tack for VTN in­te­gra­tion

Step 1

Erase all VMs, net­works, routers and ports in the con­troller node, since you al­ready have a work­ing OpenS­tack set-up.

You might test for VM pro­vi­sion­ing as a san­ity test, but be­fore in­te­grat­ing OpenS­tack with OpenDay­light, you must clean up all the un­wanted data from the OpenS­tack data­base. When us­ing OpenDay­light as the Neu­tron back-end, ODL ex­pects to be the only source for Open vSwitch con­fig­u­ra­tion. Be­cause of this, it is nec­es­sary to re­move ex­ist­ing OpenS­tack and Open vSwitch set­tings to give OpenDay­light a clean slate.

The fol­low­ing steps will guide you through the clean­ing process.

Delete in­stances, as fol­lows:

$ nova list

$ nova delete <in­stance names>

Re­move links from sub­nets to routers, as fol­lows:

$ neu­tron sub­net-list

$ neu­tron router-list

$ neu­tron router-port-list <router name>

$ neu­tron router-in­ter­face-delete <router name> <sub­net ID or name>

Delete sub­nets, nets and routers, as fol­lows:

$ neu­tron sub­net-delete <sub­net name> $ neu­tron net-list

$ neu­tron net-delete <net name> $ neu­tron router-delete <router name>

Check that all ports have been cleared – at this point, this should be an empty list:

$ neu­tron port-list Stop the Neu­tron ser­vice, as fol­lows: $ ser­vice neu­tron-server stop

While Neu­tron is man­ag­ing the OVS in­stances on the com­pute and con­trol nodes, OpenDay­light and Neu­tron may be in con­flict. To

pre­vent is­sues, let’s turn off the Neu­tron server on the net­work con­troller and Neu­tron’s Open vSwitch agents on all hosts.

Step 2: Con­fig­ur­ing Open vSwitches in the con­troller and com­pute nodes

The Neu­tron plugin in ev­ery node must be re­moved be­cause only OpenDay­light will be con­trol­ling the Open vSwitches. So, on each host, we will erase the pre-ex­ist­ing Open vSwitch con­fig and set OpenDay­light to man­age the Open vSwitch:

$ apt-get purge neu­tron-plugin-open­vswitch-agent $ ser­vice open­vswitch-switch stop

$ rm -rf /var/log/open­vswitch/*

$ rm -rf /etc/open­vswitch/conf.db

$ ser­vice open­vswitch-switch start

$ ovs-vsctl show

# The above com­mand must re­turn the empty set ex­cept Open­Vswitch ID and it’s Ver­sion.

Step 3:Con­nect­ing Open vSwitch to OpenDay­light Use the com­mand given be­low to make OpenDay­light ad­min­is­ter Open vSwitch:

$ ovs-vsctl set-man­ager tcp:<OPENDAY­LIGHT MAN­AGE­MENT IP>:6640

You can copy the Open vSwitch ID from the com­mand ovs-vsctl show. Execute the above com­mand in all the nodes (con­troller and com­pute nodes) to set ODL as the man­ager for Open vSwitch:

$ ovs-vsctl show

The above com­mand will show that you are con­nected to the OpenDay­light server, which will au­to­mat­i­cally cre­ate a br-int bridge.

[[email protected] ~]# ovs-vsctl show 9e3b34cb-fefc-4br4-828s-084b3e55rtfd Man­ager “tcp:192.168.2.101:6640” Is_­con­nected: true

Bridge br-int

Con­troller “tcp:192.168.2.101:6633” fail_­mode: se­cure

Port br-int

In­ter­face br-int ovs_ver­sion: “2.1.3”

If you get any er­ror mes­sages dur­ing bridge cre­ation, you may need to log out from the OpenDay­light Karaf console and check the 90-vtn-neu­tron.xml file from the fol­low­ing path dis­tri­bu­tion-karaf-0.5.0-Boron/etc/openday­light/karaf/.

The con­tents of 90-vtn-neu­tron.xml should be as fol­lows:

brid­ge­name=br-int port­name=eth1 pro­to­cols=OpenFlow13 failmode=se­cure

By de­fault, if 90-vtn-neu­tron.xml is not cre­ated, VTN uses ens33 as the port name.

Af­ter run­ning the ODL con­troller, please en­sure it lis­tens to the fol­low­ing ports: 6633, 6653, 6640 and 8080.

Note:

6633/6653 are the Open­Flow ports. 6640 is the OVS Man­ager port. 8080 is the port for the REST API.

Step 4: Con­fig­ure ml2_­conf.ini for the ODL driver

Edit vi /etc/neu­tron/plug­ins/ml2/ml2_­conf.ini in all the re­quired nodes and mod­ify the fol­low­ing con­fig­u­ra­tion. Leave the other con­fig­u­ra­tions as they are.

[ml2] type­_­drivers = lo­cal ten­an­t_net­work_­types = lo­cal mech­a­nis­m_­drivers = openday­light

[ml2_odl] pass­word = ad­min user­name = ad­min url = http://<OPENDAY­LIGHT SERVER’s IP>:8080/con­troller/nb/ v2/neu­tron

Step 5: Con­fig­ure the Neu­tron data­base Re­set the Neu­tron data­base, as fol­lows:

$ mysql -uroot –p

$ drop data­base neu­tron;

$ cre­ate data­base neu­tron;

$ grant all priv­i­leges on neu­tron.* to ‘neu­tron’@’lo­cal­host’ iden­ti­fied by ‘<YOUR NEU­TRON PASS­WORD>’;

$ grant all priv­i­leges on neu­tron.* to ‘neu­tron’@’%’ iden­ti­fied by ‘<YOUR NEU­TRON PASS­WORD>’;

$ exit

$ su ­s /bin/sh ­c "neu­tron­db­man­age ­­con­fig­file /etc/ neu­tron/neu­tron.conf ­­con­fig­file /etc/neu­tron/plug­ins/ml2/ ml2_­conf.ini up­grade head" neu­tron

Restart the Neu­tron-server, as fol­lows: $ ser­vice neu­tron-server start

Step 6: In­stall the Python-net­work­ing-odl Python mod­ule IM­POR­TANT: You should get the sta­tus alert if the Neu­tron ser­vice fails to start by this time. Don’t worry. This is a tem­po­rary is­sue since you have en­abled OpenDay­light as the mech­a­nis­m_­driver but not yet in­stalled the Python mod­ule for it.

In­stall the Python-net­work­ing-odl Python mod­ule, as fol­lows:

$ apt-get in­stall python-net­work­ing-odl

Now, restart the Neu­tron server and check its sta­tus. It should be run­ning with­out er­rors.

Step 7: Ver­ify the in­te­gra­tion

We have al­most com­pleted the in­te­gra­tion of OpenS­tack with VTN. Now, cre­ate ini­tial net­works in OpenS­tack and check whether a new net­work is cre­ated and posted to ODL, for which VTN Man­ager cre­ates a VTN.

Use the curl com­mands given be­low to ver­ify the cre­ation of the net­work and VTN:

$ curl --user "ad­min":"ad­min" -H "Con­tent-type: ap­pli­ca­tion/ json" -X GET http://<ODL_IP>:8181/rest­conf/op­er­a­tional/ vtn:vtns/

$ curl -u ad­min:ad­min http://<ODL_IP>:8080/con­troller/nb/v2/ neu­tron/ net­works

When­ever a new sub-net­work is cre­ated in the OpenS­tack Hori­zon, VTN Man­ager will han­dle it and cre­ate a vBridge un­der the VTN. When you cre­ate a new VM in OpenS­tack, the in­ter­face (br-int) men­tioned as the in­te­gra­tion bridge in the con­fig­u­ra­tion file will be added with more in­ter­faces, and the net­work is pro­vi­sioned for it by the VTN Neu­tron bun­dle. The ad­di­tion of the new port is cap­tured by VTN Man­ager, and it cre­ates a vBridge in­ter­face with port map­ping.

When the VM starts to com­mu­ni­cate with the other VMs that have been cre­ated, VTN Man­ager will in­stall flows in the OVS and other Open­Flow switches to fa­cil­i­tate com­mu­ni­ca­tion be­tween the VMs.

Note: To ac­cess OpenDay­light Rest­Conf API doc­u­men­ta­tion, use the link http://<ODL_IP>:8181/ api­doc/ex­plorer/in­dex.html, which points to your ODL_IP.

If every­thing works cor­rectly, you will able to com­mu­ni­cate with other VMs cre­ated in the dif­fer­ent com­pute nodes.

The VTN project doesn't sup­port the vRouter up to the Boron re­lease, which means that the float­ing IP op­er­a­tion in OpenS­tack is not sup­ported when in­te­grat­ing VTN Man­ager with OpenS­tack. It might sup­port the vRouter in the Car­bon or Ni­tro­gen re­leases.

Ref­er­ences

[1] http://www.hellovinoth.com/ [2] http://www.clouden­ablers.com/blog/ [3] https://www.openday­light.org/ [4] http://docs.opens­tack.org/

Fig­ure 2: Re­quest flow

Fig­ure 3: LAB lay­out

Fig­ure 1: Vir­tual Ten­ant Net­work

Fig­ure 4: VTN OpenS­tack ar­chi­tec­ture

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.