open dayligth usando sdn-nfv
TRANSCRIPT
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!