OpenDaylight - SDN-NFV Tutorial

Basics and Hands Ondec/2016

Prof. Christian Rothenberg (FEEC/UNICAMP)PhD candidate Javier Quinto (UNICAMP & INICTEL-UNI)

Agenda

● Introduction to Open DayLight (ODL)

● Exercise 1: Learning-Switch

● Exercise 2: Flow Programming Through REST

● Exercise 3: TAP Application

Open DayLight Introduction

High-level Architecture (versión 0.3)

1. Get familiar with the Model-View-Control approach for app development in a modular fashion

- YANG Model for data, RPC and notifications- RESTconf View generated automatically- Implementation in Java or Scala to handle data changes, notifications and

RPC call backs

2. Get familiar with platform essentials (maven, config subsystem, dependencies) and useful tools

3. Learn about existing projects and reuse modules- No need to change code of other projects. Just link them as binary libraries

What does it mean to program in ODL

Outdated Tutorial: This is focused solely on:- OpenFlow based app development- API driven SAL that is similar in spirit to what ONOS usesOSGi based activation

Current Tutorial:- Approaches app development from the perspective of YANG modeling since it is core to OpenDaylight- Model driven SAL (MD-SAL) for all state handlingUses config subsystem for bundle activation

What’s new in this tutorial?

Java, Maven, OSGi, Interface

● Java chosen as an enterprise-grade, cross-platform compatible language.

● Maven build system for Java, uses pom.xml (Project Object Model for

thisbundle) to script the dependencies between bundles and also to

describewhat bundles to load on start.

Developing OSGi Components for OpenDaylight

● OSGi- Allows dynamically loading bundles.- Allows registering dependencies and services exported.- For exchanging information across bundles.

● Java Interfaces are used for event listening, specifications and forming patterns.● Karaf: Karaf is a small OSGi based runtime which provides a lightweight container

for loading different modules.

The tutorial application that we will work with is located in/home/tutorial/SDNHub_OpenDaylight_tutorial directory.

Open a Terminal tab (Ctrl-Shift-T) and go into the SDNHub_Opendaylight_Tutorial folder where we have included sample applications that this tutorial will focus on:

1) a Hub / L2 learning switch

2) a network traffic monitoring tap.

Setup

For a better handling of this tutorial, we have created six environment variable in “.bashrc” file.

a) Go to controller path: export control=~/SDNHub_Opendaylight_Tutorial/distribution/opendaylight-karaf/target/assembly/bin/b) Go to learning-switch code: export learn=~/SDNHub_Opendaylight_Tutorial/learning-switch/implementation/src/main/java/org/sdnhub/odl/tutorial/learningswitch/impl/c) Go to deploy folder:export deploy=~/SDNHub_Opendaylight_Tutorial/distribution/opendaylight-karaf/target/assembly/deployd) Go to target folder:export target=~/SDNHub_Opendaylight_Tutorial/learning-switch/implementation/targete) go to learning-switch folder: export program1=~/SDNHub_Opendaylight_Tutorial/learning-switchf) go to TAP folder: export program2=~/SDNHub_Opendaylight_Tutorial/tapapp

Setup

To build Open DayLigth Tutorial in our VM, we have required JDK 1.8 and Apache Maven 3.3.9. The following commands allow building maven and install components in the controller:

$ cd ~/SDNHub_Opendaylight_Tutorial/ # Go to our working space

$ mvn clean install # Cleaning anything of maven and install again, (this

step is done, not repeat it again!)

$ cd $control # Go to the path from Open DayLigth controller

$ ./karaf debug # Start the controller

karaf> feature:install sdnhub-XYZ # Install any program available in the

controller

How to Build ( Not doing this step for now)

● pom.xml: The POM in the main directory specifies all the sub-POMs to build

● commons/parent: contains the parent pom.xml with all properties defined for the subprojects.

● commons/utils: contains custom utilities built for OpenFlow programming

● learning-switch: contains the tutorial L2 hub / switch● tapapp: contains the traffic monitoring tap application● features: defines the two features

"sdnhub-tutorial-learning-switch", "sdnhub-tutorial-tapapp" that can be loaded in Karaf

● distribution/karaf-branding: contains karaf branner for SDN Hub● distribution/opendaylight-karaf: contains packaging relevant pom

to generate a running directory

Directory Organization

Maven and project building

Let’s start with building the tutorial project in the VM using the following step:

~/SDNHub_Opendaylight_Tutorial$ mvn install -nsu

If at the end of the installation appears the message “BUILD SUCCESS”, means that the build was sucessfully, otherwise the build will stop at the module where it failed.

Maven compiles code based on the pom.xml file in that directory. “install” is essential for compilation. It also accepts an optional argument “clean” if you wish to clean the temporary build files.

Maven Configuration

Now that we compiled our sample project, let’s run the controller itself; preferably in a different terminal. (<CTRL>+<SHIFT>+T)

cd $controltutorial$ ./karaf debug

Karaf Parameters:

- List available features in ODLfeature:list # List all features available in ODLfeature:list | grep sdnhub # Filter a specific feature in ODL

- List avalable bundles in ODL

bundle:list -s | grep sdnhub # Filter a specific bundle in ODL

- Install our feature “sdnhub-tutorial-learning-switch”

feature:install sdnhub-tutorial-learning-switch

Karaf Configuration

Karaf Configuration

Mininet-based Topology

Hands-on

Learning-Switch

For the purposes of this tutorial, you should attempt to convert the hub learning switch to a MAC learning switch that programs flows. Here, we give you the steps to configure this first exercise:

1. Start the ODL controller in debug mode # Terminal 1cd $control./karaf debug

2. Verify if the feature “sdnhub-tutorial-learning-switch” is installed> feature:list -i |grep sdnhub-tutorial-learning-switch

If it is not installed, install it

> feature:install sdnhub-tutorial-learning-switch

Wait 30 seconds until the Learning-Switch program is installed and active

> bundle:list -s |grep learning-switch189 | Active | 80 | 1.0.0.SNAPSHOT org.sdnhub.odl.tutorial.learning-switch.impl

Setup Configuration

3. Start mininet topology # Change to a second terminal (Terminal 2)sudo mn --topo single,3 --mac --switch ovsk,protocols=OpenFlow13

--controller remote* We wait until the controller is connected to the mininet topology:

is_connected: true

4. Try to do ping between “host1” and “host2”mininet> h1 ping h2From 10.0.0.1 icmp_seq=1 Destination Host Unreachable

Q1: Why is the Ping failing?

5. Add the next rule and verify the pingmininet> s1 ovs-ofctl add-flow tcp:127.0.0.1:6654 -OOpenFlow13 priority=1,action=output:controller

mininet> h1 ping -c 10 h2

Setup Configuration

6. Open the learning-switch program ($learn/TutorialL2Forwarding.java) and pay attention in the lines #79 and #143

In the line #79 you may note that the default function of the code is in “hub mode”. This means that our program (learning-switch) will act as hub, thus ping between hosts would have a high RTT value, as you can see above. In the line #143 you may note the code block related to the behavior of the program.

7. In the same file TutorialL2Forwarding.java, change the default function of the program from “hub” to “switch”.

private String function = "hub"; # Line 79toprivate String function = "switch";

Setup Configuration

8. Update maven from the path of the program and copy the “JAR” generated by maven to the folder “deploy” of our controller

cd $program1 # Path of the learning-switch programmvn install -nsucp $target/learning-switch-impl-1.0.0-SNAPSHOT.jar $deploy/

9. Restart “mininet” and the “controller” and do ping between h1 and h2 again:> logout # Logout to the controller./karaf debug # Start the controller again

mininet > exit # Exit to the mininet$ mn -c # Clean mininet$ sudo mn --topo single,3 --mac --switch ovsk,protocols=OpenFlow13 --controller remotemininet > h1 ping -c 10 h2

Q2 Do you note changes in the RTT value obtained in the steps 5 and 9?

Setup Configuration

Flow Programming Through REST

It is possible to use RESTconf to send static flows to the controller. The REST input is based on the YANG model. For instance, post following 2 static flows using XML tags

Exercise #2: Flow Programming Through REST

1. Start and configure the ODL controller (Terminal #1)

cd $control./karaf clean # Clean features and bundles

Install the features that are needed to use for Restconf

> feature:install odl-restconf odl-mdsal-apidocs odl-dlux-core

2. Start the mininet topology (Terminal #2)

sudo mn -c # Clean mininet configurationsudo mn --topo single,3 --mac --switch ovsk,protocols=OpenFlow13

--controller remote

3. Two files “forward.xml” and “reverse.xml” are stored in the ~/XML folder. By using Postman application, create two OpenFlow rules to send static flows to the controller. See the next steps:

Flow Programming

4. Open Postman application and enter Request URL in PUT mode and configure header parameters needed, such as is shown in Figure below:

Postman Configuration

5. XML Configuration for forward ping (See the file ~/XML/forward.xml). Note that the XML information is added in the “Body” tag

Postman Configuration

6. XML Configuration for reverse ping (See the file ~/XML/reverse.xml)

Postman Configuration

7. Dump flows from mininet (same terminal #2)

mininet> sh ovs-ofctl dump-flows s1 -O OpenFlow13OFPST_FLOW reply (OF1.3) (xid=0x2): cookie=0x0, duration=5264.052s, table=0, n_packets=20, n_bytes=1624, in_port=1 actions=output:2 cookie=0x0, duration=4983.190s, table=0, n_packets=17, n_bytes=1498, in_port=2 actions=output:1

8. Testing connectivity between hosts h1 and h2

mininet> h1 ping -c 3 h2PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.432 ms64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.118 ms

Postman Configuration

Q3: By using Postman and DELETE mode, how can you delete the flows previously created? (see the file ~XML/delete.xml)

TAP Application

The traffic monitoring tap application is a simple proactive flow programmer that deals with source, sinks and traffic types. We will follow the steps described earlier to build this application. The model of the tap configuration data was described earlier in the slide above. Based on that model, we perform following to make the tap work:

1. Extract header details from the tap object during the onDataChanged() event handling

2. For each source-port, perform following steps to create a flow- Create match object using appropriate builders- Create action list with a list of actions specifying output to sink-port- Create flow object with match and action list. Write this flow object to the Flow

table of the node

Note that the traffic type is a special enum field defined in the YANG model to allow user to specific important traffic types worth monitoring, like ARP, ICMP, DNS, DHCP, TCP, UDP. For converting the enum to actual values for the dl_type, nw_proto and tp_port, one can use the following switch statement:

Network Traffic Monitoring Tap

Karaf Parameters:

- Install the features that are needed to use for Restconf

feature:install odl-restconf-all

- List the installed programs in Karaf

feature:list -i |grep odl-restconf-all

feature:list -i |grep tapapp

- List avalable bundles in ODL

bundle:list -s | grep sdnhub # Filter a specific bundle in ODL

Karaf Configuration

1. Start the controller again

$ ./karaf debug

2. Start mininet$ sudo mn --topo single,3 --mac --switch ovsk,protocols=OpenFlow13

--controller remote

Once you add the model, you can build the project and run Karaf to immediately verify if your model is sufficient for your application. For instance, when we run karaf, even without any implementation or event handlers defined, you will be able to store data in the data store as follows:

Network Traffic Monitoring Tap

3. Add flows using RESTFul. Open a terminal in the VM and copy the box below

$ curl -u admin:admin -H "Content-Type:application/json" -X PUT -d '{"tap-spec":{"tap":[ {"id":"1", "node":"openflow:1", "traffic-match":"HTTP", "src-node-connector":["openflow:1:1"], "sink-node-connector":["openflow:1:2"] } ]}}' http://localhost:8181/restconf/config/tap:tap-spec

Network Traffic Monitoring Tap

You can open a browser and inspect the data store at http://localhost:8181/restconf/config/tap:tap-spec

4. Open Postman and import the XML file stored in the path ~/XML/tap.xml

Network Traffic Monitoring Tap

In each Tag added you should configure the Authorization Type as “Basic Auth” and then click in “Update Request”

Q4: By using Postman, could you add two new rules to match traffics ARP and ICMP?Q5: What happens if the controller goes down? Are the flows removed?

5. Using Postman, install the two addition rules (Tap1 addition and Tap2 addition) on OVS, clicking in the bottom “Send”.

6. Inspect the data stored:http://127.0.0.1:8181/restconf/config/tap:tap-spec

7. Now, send the two deletion rules clicking in the bottom “Send”. Repeat step 6.

8. Now, send the two Create dummy rules. Go to mininet and type:mininet> sh ovs-ofctl dump-flows s1 -O OpenFlow13mininet> h1 ping h2

9. Finally, delete those flows with the Delete dummy rules

Network Traffic Monitoring Tap

Thanks!