Okinawa open laboratory First hand on seminar OpenDaylight edition July 29, 2014 Satoshi Hieda Takahiro Oshima

Agenda Part 1: OpenDaylight Part 2: VTN (Virtual Tenant Network) Introduction to OpenDaylight project Introduction to OpenDaylight Hydrogen OpenDaylight hands on Break Part 2: VTN (Virtual Tenant Network) Introduction to VTN VTN hands on Practice problems

Part 1: OpenDaylight

Introduction to OpenDaylight project

SDN Separate network control and data forwarding (Software Defined Networking) Separate network control and data forwarding Make network control programmable Current network SDN application API control control control forwarding Control/Data plane Interface forwarding forwarding control control forwarding forwarding

OpenDaylight project Part of Linux Foundation Collaborative Project Main activities SDN controller development Develop SDN controller for commercial use from the development resources committed by participating vendors. Make it Open source Offer SDN controller as OSS to a wide range of users and vendors Promote SDN market Accelerate the rise of SDN market and promote its commercial use with the above activities.

Multi-vendor Participation of both network vendors and IT vendors. 39 vendors at present. The participants are increasing. (from http://www.opendaylight.org/project/members, as of 7/19)

Multi-project Project proposal by many participants/vendors There are 25 projects at present. AAA Service Affinity Metadata Service BGP-LS/PCEP Controller dlux - openDayLight User eXperience Documentation Project Defense4All Dynamic Resource Reservation Group Policy Plugin Project Integration Group LISP Flow Mapping Open DOVE OpenFlow Plugin OpenFlow Protocol Library OpFlex Implementation Project OVSDB Open vSwitch Database Integration Project OSCP Project PacketCable PCMM Project Secure Network Bootstrapping Infrastructure (SNBI) project Service Function Chaining SNMP4SDN Table Type Patterns (TTPs)/Negotiable Datapath Models (NDMs) Toolkit Project Virtual Tenant Network (VTN) YANG Tools (from https://wiki.opendaylight.org/view/Main_Page, as of 7/19)

Open community Vendor neutral Governance Only vendor neutral projects can be proposed Check by TSC in creation review of project Governance Board: Collegiate system with focus on Platinum member. TSC: Committer elected by Core project representative (focus is on Platinum member for now because it is just after the inauguration) Contents of discussion have been published on Internet TSC: Technical Steering Committee. Organization controlling the overall design/development of OpenDaylight

Introduction to OpenDaylight Hydrogen

OpenDaylight Hydrogen SDN controller released in February, 2014 First OpenDaylight release License: Eclipse Public License Three release edition Base Edition Basic features only For SDN, OpenFlow investigation Virtualization Edition Base Edition + virtualization For data centers Service Provider Edition Base Edition + multiple protocol support For providers, carriers Eclipse Public License(EPL) The receiver of EPL-licensed programs can use, modify, copy and distribute the work and modified versions. However, certain obligations are attributed to the distribution of the modified version, like revealing the method to acquire the source code. (from http://ja.wikipedia.org/wiki/Eclipse_Public_License)

Code volume Rapid increase in short period of time after OpenDaylight inauguration(May, 2013) Many contribution of existing code as well (total: 1.5ML, code: 1.0ML) Hydrogen release OpenDaylight 発足 (from http://www.ohloh.net/p/opendaylight)

Adoption Announcement of products with OpenDaylight base Cisco: XNC (Extensible Network Controller) One PK, OpenFlow 1.0 support IBM: SDN VE (Software Defined Network for Virtual Environment) Adopt same technology as OpenDOVE PoC of OpenDaylight starts in Deutsche Telekom, Italtel etc. Ericsson launches laboratory for validation

Community Many vendor-led projects Depending on the project, committers are limited to one company Non vendor-led projects are also increasing University of Kentucky, ITRI, ... Community is diversifying Projects with multiple vendor participation Integration between projects

Community Contributors: 154 (as of February,2014) Commit count (Reference: OpenStack 1974, Floodlight 52) Commit count Line count (from http://events.linuxfoundation.org/sites/events/files/slides/OpenDaylight-Year1%20v4-ext.pdf )

Projects in the Hydrogen Release Project name Activities Proposed vendors OpenDaylight Controller SDN controller framework and basic features Cisco OpenFlow Plugin Plugin to control OpenFlow compliant network devices Ericsson, IBM, Cisco OpenFlow Protocol Library Library supporting OpenFlow 1.3 and above versions Pantheon YANG Tools Tools and library to set network devices using NETCONF and YANG VTN Virtualization technology for realizing multi tenants across multiple SDN controllers NEC OVSDB Integration Configuration/management feature of OVSDB mediated OVS(Open vSwitch) Kentucky Univ. Open DOVE Virtualization technology for realizing multi tenant with overlay technology IBM Affinity Metadata Service API for expressing relationship and service level of workload Plexxi Defense4All Feature controlling the detection/defense of DDoS attack Radware BGP-LS/PCEP Feature controlling BGP-LS and PCEP compliant network devices LISP Flow Mapping Feature controlling LISP compliant network devices ConteXtream SNMP4SDN SNMP support ITRI (From https://wiki.opendaylight.org/images/2/24/ODL_2013.11-IETF-final.pptx)

(From OpenDaylight_Briefing_Deck_06.30.14.ppt http://bit.ly/ZPgDut)

OpenDaylight Hydrogen Base Edition

(From http://www.opendaylight.org/software/base-edition )

OpenDaylight Controller Framework of SDN controller Constitutes of OSGi Framework + bundle Major features Base Network Service Function Bundle the basic controller features and offer it as REST API Topology Manager, Stats Manager, Switch Manager, ... SAL (Service Abstraction Layer) HA, Clustering Northbound API GUI

SAL Abstraction layer between Controller Platform and Protocol Plugin Control data sharing, request calls etc. Two types of SAL are defined AD-SAL (API-Driven SAL) MD-SAL (Model-Driven SAL) Supported SAL differs based on Plugin

AD-SAL SAL defines the service APIs offered to upper layers Higher applications use SB Plugin via service API Degree of support provided for service APIs differ based on SB Plugin, and it is necessary to be aware of the return code AD-SAL (From https://wiki.opendaylight.org/view/OpenDaylight_Controller:AD-SAL )

MD-SAL Java bindings(API/Plugin) are created via YANG Tools, based on the data model defined in YANG (From https://wiki.opendaylight.org/images/7/78/ONF_NBI_Leadership_Roundtable_Presentation_-_ODL.pptx )

MD-SAL Application and SB plugin operate model data, and execute request (RPC) and notification via the generated Java bindings (From https://wiki.opendaylight.org/images/e/e3/Os2014-md-sal-tutorial.pdf )

OpenFlow Plugin & Protocol Library Protocol plugin that controls OpenFlow switch Supports OF 1.0, 1.3.x OpenFlow Protocol Library Library for transmitting and receiving OpenFlow protocol data (From https://wiki.opendaylight.org/view/File:Openflow_Protocol_Library.pdf )

YANG Tools Tools and libraries to configure network devices by using NETCONF and YANG Generates Java binding from model described in YANG Service module of MD-SAL can be easily created from YANG model

OpenDaylight Hydrogen Virtualization Edition

(From http://www.opendaylight.org/software/virtualization-edition )

VTN Refer details in Part 2 VTN! Virtualization technology that realizes a multi tenant that spans across multiple SDN controllers Offers VTN API for higher applications to control the virtual network Refer details in Part 2 VTN!

OVSDB OVS(Open vSwitch) configuration and management features via OVSDB Offers features for OVS like creation of bridge, port etc., modification of settings, deletion, information retrieval and tunnel control Possible to integrate with OpenStack (From http://www.1-4-5.net/~dmm/talks/OpenDaylight_SDN_Workshop_AZ.pdf )

OpenDOVE Virtualization technology with overlay technology (VxLAN) Tenants can connect with each other on L2 and L3 (ACL control) Has a gateway feature with the existing physical network Integrates with OpenStack (From https://wiki.opendaylight.org/view/Open_DOVE:Proposal )

Affinity Metadata Service Metadata to realize network model This service does not look into how metadata is expressed as config and flow entry (From https://wiki.opendaylight.org/view/Project_Proposals:Affinity_Metadata_Service )

Defence4All Feature to control detection and defense for DDoS attacks When a DDoS attack is detected, it mitigates the attack by directing target flows to mitigation systems (From https://wiki.opendaylight.org/view/Project_Proposals:Defense4All )

OpenStack Service Offers one northbound for the controller Plugin individual implementations of each project under it Supported projects VTN,OVSDB,OpenDOVE Resources Resources used differs for different projects Resource VTN OVSDB OpenDOVE Network Yes Subnet - Port Router FloatingIP VTN Provider VTN Provider DOVE Provider DOVE Provider OVSDB Provider hop by hop overlay overlay (From http://www.1-4-5.net/~dmm/talks/OpenDaylight_SDN_Workshop_AZ.pdf )

OpenDaylight Hydrogen Service Provider Edition

(From http://www.opendaylight.org/software/service-provider-edition )

LISP, BGP, PCEP, SNMP LISP Mapping Service BGP-LS/PCEP SNMP4SDN Controls network devices that support LISP Offers mapping feature between EID/Locator of LISP BGP-LS/PCEP Controls network devices that support BGP-LS and PCEP Allows topology detection via BGP-LS and path programming via PCEP SNMP4SDN Controls network devices via SNMP

Conclusion

Future of OpenDaylight OpenDaylight Helium (incoming SDN controller) Under development, release planned for September 29 Projects that plan to participate (25 projects) AAA Service BGPCEP Controller dLux Defense4All Docs Group Based Policy Integration Group L2 Switch Lisp Flow Mapping Service ODL-SDNi App OpenFlow Plugin Openflow Protocol Library OpFlex protocol Agent OVSDB PacketCablePCMM Secure Network Bootstrapping Infrastructure Service Function Chaining Southbound plugin to the OpenContrail platform Reservation SNMP4SDN Table Type Patterns Toolkit VTN Project YANG Tools

Conclusion We now have an overview of OpenDaylight project and OpenDaylight Hydrogen For those who are interested in the projects, please refer this page! https://wiki.opendaylight.org/view/Main_Page

OpenFlow overview

Status of OpenFlow OpenDaylight Controller Architecture それは、OpenFlow は Control plane と Data plane のあいだ、southbound interface を実現する方法一つとして位置づけられる。 Southbound interface の中でも OpenFlow は代表的なプロトコルであり、 SDN = OpenFlow と混同するひともいる。 One of the protocols supported by OpenDaylight (Southbound Interface)

Basic overview of OpenFlow (version 1.0) Controller enters the rules for packet processing into the switch tables. Switch will process the packets based on this table information. = Separating control and forwarding features OpenFlow specification defines - message format between controller and switch - necessary switch capabilities Priority Header Fields Action Count 10000 DMAC＝AA:AA:… Port 1 250 5000 SIP=10.0.0.1 Port 2 300 4000 L4-port=23 Drop 892 1 ANY Controller 11 OpenFlow の基本概念を説明する。 従来のネットワークでは、各々のNW機器が制御機能と転送機能の両方を持っていた。つまり、各機器が自分の中の設定に従い、 パケットを次にどこに出力すればよいかを判断していた。したがって、ネットワーク設計者は、全体として整合性が取れるように各機器を適切に 設定しなければならなかった。 OpenFlow ではこの制御機能と転送機能を分離され、Controllerと呼ばれる機器が制御機能を、Switchと呼ばれる機器が転送機能を担う。 SwitchはControllerから指示されたルールに従いパケットを処理するのみで、制御はすべてControllerによって集中的に行われる。 これにより、設定の複雑さを軽減するとともに、従来のネットワークよりも柔軟な経路制御をダイナミックに行うことができる。

OpenFlow utilization (Overlay or Hop-by-hop) Overlay technology Hop-by-hop technology OF OF OF OF Legacy OF OF OF OF OF OF OpenFlow in edge only Maintains existing network devices Central management of core NW is not possible → Cannot visualize physical path → Traffic path control is difficult OpenFlow in its entirety Replaces existing network devices Central management of core NW is possible → Visualize physical path → Traffic path control is easy OpenFlowの仕様についてはあとでもう少し説明するが、その前にOpenFlowの利用形態には大きく分けて2つの流派があるので そのことを説明する。 それそれOverlay方式、Hop-by-hop方式と呼ばれる。 違いはいたって単純。 端末が接続するエッジのみをOF化するのはOverlay、全体をOF化するのがHop-by-hop。 一般的にOverlay方式では、Hypervisor上の仮想スイッチのみをOF化し物理NWは既存のものをそのまま使用する。 これにより。既存のネットワークを維持したままSDNを導入できることがOverlay方式の利点。 しかし、コアNWとしてLegacyを使用するため、ネットワークの集中制御はできない。 つまり、Legacy部分のネットワークは可視化することができず、また、トラフィックの経路制御も困難である。 一方、Hop-by-hop方式は、 機器の置換えは必要となるが、 通信経路上のすべてがOF化されるため、パケットがどこを通過しているのかといった物理経路の可視化や きめ細やかなトラフィック経路制御が可能となる。 このトラフィック経路制御については次のスライで具体例を上げる。

Traffic path control specifically, such things are possible ■ Sophistication of traffic path control with Open flow Effective use of network bandwidth by path control of each flow (multi-path) ② Improvement in network device maintainability by moving flows to one side ③ Place network appliances like Firewall, Load balancer etc. between the path and allow passage of specific flows (WayPoint feature) OpenFlow controller ① OpenFlow switch Flow 1 Flow 2 App 1 App 1 App 2 Hop-by-hop方式だと 具体的にはこんなことができます、という例。 App 2 Server ① 45

②Maintenance possible Traffic path control　specifically, such things are possible ■ Sophistication of traffic path control with Open flow Effective use of network bandwidth by path control of each flow (multi-path) ② Improvement in network device maintainability by moving flows to one side ③ Place network appliances like Firewall, Load balancer etc. between the path and allow passage of specific flows (WayPoint feature) OpenFlow controller OpenFlow switch Flow 1 Flow 2 App 1 App 1 ②Move flows to one side App 2 App 2 Server ②Maintenance possible 46

Traffic path control specifically, such things are possible ■ Sophistication of traffic path control with Open flow Effective use of network bandwidth by path control of each flow (multi-path) ② Improvement in network device maintainability by moving flows to one side ③ Place network appliances like Firewall, Load balancer etc. between the path and allow passage of specific flows (WayPoint feature) OpenFlow controller OpenFlow switch Flow 1 Flow 2 App 1 App 1 App 2 App 2 Server FW ③ LB Firewall Load balancer 47

Packet header fields used in Match conditions OF1.0 Uses total of twelve header fields as Match conditions from L1 to L4 [Conventional network devices] Controls forwarding to individual network devices according to destination address of L2/L3 layers L2 (MAC) switching L3 (IP) routing (Firewall etc.) Ingress Port Dst MAC Src MAC Ether Type VLAN id VLAN Priority Dst IP Src IP IP Proto IP ToS TCP/UDP Src Port TCP/UDP Dst Port Data Ｌ１ Ｌ２ Ｌ３ Ｌ４ [What happens in OpenFlow?] 　Distinguish communication traffic with any combination of address/ identifier in each of the L1(physical port etc.）, L2(MAC), L3(IP) and L4(port number) layers and define actions accordingly for more flexible control. 48 48 48

Action for each flow (Action) OF1.0 As Action, it is possible to update packet header (Modify-Field), output to specified port (OUTPUT) or add to specified queue (ENQUEUE). Drop action is performed if action is not specified Type of action Description Forward PORT specification Specify physical port number of switch IN_PORT Forward packets to input port of packets TABLE Perform flow table match operations (during Packet Out messages) NORMAL Forward packets using legacy switch features FLOOD Output to all ports except the port that received the packet and the port where NO_FLOOD is set in OpenFlow ALL Transmit packets from all ports except the input port of packets CONTROLLER Transmit packets to controller LOCAL Termination process in protocol stack inside switch Enqueue Add to specified queue Modify-field Update packet header

OpenDaylight hands on

Agenda In this session, we will operate and experience the following sample applications preset in Hydrogen. Simple Forwarding Static Flow Installation Manual setting from GUI (filtering) Manual setting from REST API (L2 communication) Load Balancer Service Load distribution with L4 load balancing

Environment preparation Check VM start 　User name： mininet 　 Password： mininet Modify keyboard layout to Japanese sudo dpkg-reconfigure keyboard-configuration Select “Japanese” on the second screen 　　（leave the rest as default） BackSpace enable stty erase ^H Record above in ~/.bash_profile as well

Start OpenDaylight controller Start controller with Base Edition. cd ~/controller-base/opendaylight/ ./run.sh ※ Startup takes some time（few seconds） Check start Open browser and access the following. 　　http://127.0.0.1:8080/ 　　User name：admin　　Password：admin

OpenDaylight GUI screen Confirm the start of OpenDaylight controller.

Start Mininet Next, prepare OpenFlow switch. Use the emulator Mininet this time. Open new terminal, run the following sudo mn --controller=remote,ip=127.0.0.1 Please reload the GUI page after start. Was a switch displayed? 　　＃Please drag it if hidden in screen corner.

Start Mininet Since one switch is not enough, we will use custom topology. Stop mininet. mininet> exit Store the downloaded USB.zip to home directory (/home/mininet) Start Mininet with custom topology. sudo mn --controller=remote,ip=127.0.0.1 --custom ~/handson/topo-tree-depth2.py --topo mytopo

Explanation： Topology detection With this, the ODL controller and OF switch are connected. The link between switches is detected automatically and displayed on GUI. ODL controller is able to detect link by… LLDP packet P2 P1 OpenDayLight Controller S1 S3 OF|P1@ | OF | OFS2 OF|P1@ | OF | OFS2 OF|P2@ | OF | OFS1 OF|P2@ | OF | OFS1 OF|P2@ | OF | OFS1 P2 P1 OF|P1@ | OF | OFS2 S1 S3 S2

Check in GUI Check for correct topology recognition in GUI.

Simple Forwarding

Simple Forwarding mininet> h11 ping h12 Now, let us ping the traffic in data plane. mininet> h11 ping h12 　→　Communication was possible. It is obvious that the OpenFlow switch is just a box until the controller sets flows. There will be no communication if controller does not set flows.

Simple Forwarding S1 S3 S2 What happens after Ping start is・・・ ③ Forward ARP Req OpenDayLight Controller ② Forward ARP Req S1 S3 S2 ① ARP Req h11 h12 h13 10.0.0.2 10.0.0.3 10.0.0.1

Explanation： Simple Forwarding ARP Reply OpenDayLight Controller ④ Forward ARP Reply ③ ARP Reply S1 S3 S2 h11 h12 h13 10.0.0.2 10.0.0.3 10.0.0.1

Explanation ： Simple Forwarding Flow Entry setting ④ Set Flow Entry in each switch Match condition： dstIP=10.0.0.1 OpenDayLight Controller S1 S3 S2 h11 h12 h13 10.0.0.2 10.0.0.3 10.0.0.1

Simple Forwarding The application Simple Forwarding runs by default and communication was possible because it configured the Flow entry. The mechanism is simple but we have just seen an example of how the controller establishes communication after detecting each host by central management of the switches.

Static Flow Installation - set from GUI

Static Flow Installation – set from GUI In the example above, Simple Forwarding automatically configured the flows. In OpenDaylight controller, you can also set each flow manually. Next, we will use this feature to manually set the rules(flow) on switch to block specific traffic.

Static Flow Installation – set from GUI Flow to set manually Set the rule to drop packets bound for 10.0.0.2 at a higher priority than the flow set by Simple Forwarding . S1 S3 S2 h11 h12 h13 10.0.0.2 10.0.0.3 10.0.0.1

Static Flow Installation – set from GUI Setting example Name： Drop_dst_h12(optional) Node： 00:00:～:00:01 InputPort： s1-eth1 Priority： 500 Dst-IP： 10.0.0.2 Action：　Drop

Static Flow Installation – set from GUI Operation check No communication between h11 – h12 due to drop flow 　 　mininet> h11 ping h12 Communication possible between H11 – h13 with Simple Forwarding 　　　mininet> h11 ping h13 Cleanup Stop the controller.

Static Flow Installation – set from GUI We were able to see how traffic filtering is possible by setting flows manually from GUI. Were you able to understand OpenFlow better and feel the flexibility after setting the flows manually?

Static Flow Installation - set from REST API

Static Flow Installation – set from REST API This time we will set flows manually with Rest API. The aim is to set flows without relying on Simple Forwarding and establish communication.(not easy though) REST API reference can be found below. https://wiki.opendaylight.org/view/OpenDaylight_Controller:REST_Reference_and_Authentication

Static Flow Installation – set from REST API In the topology below, all hosts are to communicate with each other. Use Mac address as Match condition of flow. S1 S2 h11 h12 Mac_h11 Mac_h12 S3 S4 h13 h14 Mac_h13 Mac_h14

Static Flow Installation – set from REST API Start OpenDaylight controller cd ~/controller-base/opendaylight/ ./run.sh Start Mininet sudo mn --controller=remote,ip=127.0.0.1 --custom ~/handson/topo-fullyMesh.py --topo mytopo Stop Simple Forwarding. 　　(in osgi console) Give command “ss simple” , get Bundle id Stop simple forwarding with “stop 112” 　 （in GUI） Modify the “Operation Mode” of each switch to [Proactive Forwarding Only]

Static Flow Installation – set from REST API Check for no ping mininet> h11 ping h12 →　Check for failure here

Static Flow Installation – Fully Mesh topology Set the flows like this. h12 S1 2 S2 h11 1 Mac_h12 Mac_h11 Match： Inport=1 dlDst=MAC_h12 dlSrc=MAC_h11 Action： Output=2 S3 S4 h14 h13 Mac_h13 Mac_h14

Static Flow Installation – Fully Mesh topology Similarly・・・

Static Flow Installation – Fully Mesh topology You need to set a total of 6 flows to forward packets from single host to each host Since there are 4 hosts, a total of 24 flows are required for intercommunication. h12 S1 2 S2 h11 1 Mac_h12 Mac_h11 S3 S4 h14 h13 Mac_h13 Mac_h14

Static Flow Installation – Fully Mesh topology Set as per the sequence below. Assign the Mac address of each host in variable （at the mininet prompt) Display Mac address of h11 with mininet> h11 ifconfig Copy it to clipboard （in Linux shell） Mac_h11=86:15:23:67:d8:6d 　　　　　　　　　　※paste address from clipboard. Similarly, perform the above operation for h12～h14 as well.

Static Flow Installation – Fully Mesh topology curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs1h11h12\",\"node\":{\"id\":\"00:00:00:00:00:00:00:01\",\"type\":\"OF\"},\"ingressPort\":\"1\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h12\",\"dlSrc\":\"$Mac_h11\",\"actions\":[\"OUTPUT=2\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:01/staticFlow/ofs1h11h12 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs1h11h13\",\"node\":{\"id\":\"00:00:00:00:00:00:00:01\",\"type\":\"OF\"},\"ingressPort\":\"1\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h13\",\"dlSrc\":\"$Mac_h11\",\"actions\":[\"OUTPUT=3\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:01/staticFlow/ofs1h11h13 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs1h11h14\",\"node\":{\"id\":\"00:00:00:00:00:00:00:01\",\"type\":\"OF\"},\"ingressPort\":\"1\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h14\",\"dlSrc\":\"$Mac_h11\",\"actions\":[\"OUTPUT=4\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:01/staticFlow/ofs1h11h14 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs1h12h11\",\"node\":{\"id\":\"00:00:00:00:00:00:00:01\",\"type\":\"OF\"},\"ingressPort\":\"2\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h11\",\"dlSrc\":\"$Mac_h12\",\"actions\":[\"OUTPUT=1\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:01/staticFlow/ofs1h12h11 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs1h13h11\",\"node\":{\"id\":\"00:00:00:00:00:00:00:01\",\"type\":\"OF\"},\"ingressPort\":\"3\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h11\",\"dlSrc\":\"$Mac_h13\",\"actions\":[\"OUTPUT=1\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:01/staticFlow/ofs1h13h11 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs1h14h11\",\"node\":{\"id\":\"00:00:00:00:00:00:00:01\",\"type\":\"OF\"},\"ingressPort\":\"4\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h11\",\"dlSrc\":\"$Mac_h14\",\"actions\":[\"OUTPUT=1\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:01/staticFlow/ofs1h14h11 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h12h11\",\"node\":{\"id\":\"00:00:00:00:00:00:00:02\",\"type\":\"OF\"},\"ingressPort\":\"1\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h11\",\"dlSrc\":\"$Mac_h12\",\"actions\":[\"OUTPUT=2\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:02/staticFlow/ofs2h12h11 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h12h13\",\"node\":{\"id\":\"00:00:00:00:00:00:00:02\",\"type\":\"OF\"},\"ingressPort\":\"1\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h13\",\"dlSrc\":\"$Mac_h12\",\"actions\":[\"OUTPUT=3\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:02/staticFlow/ofs2h12h13 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h12h14\",\"node\":{\"id\":\"00:00:00:00:00:00:00:02\",\"type\":\"OF\"},\"ingressPort\":\"1\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h14\",\"dlSrc\":\"$Mac_h12\",\"actions\":[\"OUTPUT=4\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:02/staticFlow/ofs2h12h14 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h11h12\",\"node\":{\"id\":\"00:00:00:00:00:00:00:02\",\"type\":\"OF\"},\"ingressPort\":\"2\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h12\",\"dlSrc\":\"$Mac_h11\",\"actions\":[\"OUTPUT=1\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:02/staticFlow/ofs2h11h12 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h13h12\",\"node\":{\"id\":\"00:00:00:00:00:00:00:02\",\"type\":\"OF\"},\"ingressPort\":\"3\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h12\",\"dlSrc\":\"$Mac_h13\",\"actions\":[\"OUTPUT=1\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:02/staticFlow/ofs2h13h12 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h14h12\",\"node\":{\"id\":\"00:00:00:00:00:00:00:02\",\"type\":\"OF\"},\"ingressPort\":\"4\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h12\",\"dlSrc\":\"$Mac_h14\",\"actions\":[\"OUTPUT=1\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:02/staticFlow/ofs2h14h12 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h13h11\",\"node\":{\"id\":\"00:00:00:00:00:00:00:03\",\"type\":\"OF\"},\"ingressPort\":\"1\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h11\",\"dlSrc\":\"$Mac_h13\",\"actions\":[\"OUTPUT=2\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:03/staticFlow/ofs2h13h11 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h13h12\",\"node\":{\"id\":\"00:00:00:00:00:00:00:03\",\"type\":\"OF\"},\"ingressPort\":\"1\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h12\",\"dlSrc\":\"$Mac_h13\",\"actions\":[\"OUTPUT=3\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:03/staticFlow/ofs2h13h12 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h13h14\",\"node\":{\"id\":\"00:00:00:00:00:00:00:03\",\"type\":\"OF\"},\"ingressPort\":\"1\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h14\",\"dlSrc\":\"$Mac_h13\",\"actions\":[\"OUTPUT=4\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:03/staticFlow/ofs2h13h14 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h11h13\",\"node\":{\"id\":\"00:00:00:00:00:00:00:03\",\"type\":\"OF\"},\"ingressPort\":\"2\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h13\",\"dlSrc\":\"$Mac_h11\",\"actions\":[\"OUTPUT=1\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:03/staticFlow/ofs2h11h13 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h12h13\",\"node\":{\"id\":\"00:00:00:00:00:00:00:03\",\"type\":\"OF\"},\"ingressPort\":\"3\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h13\",\"dlSrc\":\"$Mac_h12\",\"actions\":[\"OUTPUT=1\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:03/staticFlow/ofs2h12h13 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h14h13\",\"node\":{\"id\":\"00:00:00:00:00:00:00:03\",\"type\":\"OF\"},\"ingressPort\":\"4\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h13\",\"dlSrc\":\"$Mac_h14\",\"actions\":[\"OUTPUT=1\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:03/staticFlow/ofs2h14h13 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h14h11\",\"node\":{\"id\":\"00:00:00:00:00:00:00:04\",\"type\":\"OF\"},\"ingressPort\":\"1\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h11\",\"dlSrc\":\"$Mac_h14\",\"actions\":[\"OUTPUT=2\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:04/staticFlow/ofs2h14h11 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h14h12\",\"node\":{\"id\":\"00:00:00:00:00:00:00:04\",\"type\":\"OF\"},\"ingressPort\":\"1\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h12\",\"dlSrc\":\"$Mac_h14\",\"actions\":[\"OUTPUT=3\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:04/staticFlow/ofs2h14h12 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h14h13\",\"node\":{\"id\":\"00:00:00:00:00:00:00:04\",\"type\":\"OF\"},\"ingressPort\":\"1\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h13\",\"dlSrc\":\"$Mac_h14\",\"actions\":[\"OUTPUT=4\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:04/staticFlow/ofs2h14h13 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h11h14\",\"node\":{\"id\":\"00:00:00:00:00:00:00:04\",\"type\":\"OF\"},\"ingressPort\":\"2\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h14\",\"dlSrc\":\"$Mac_h11\",\"actions\":[\"OUTPUT=1\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:04/staticFlow/ofs2h11h14 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h12h14\",\"node\":{\"id\":\"00:00:00:00:00:00:00:04\",\"type\":\"OF\"},\"ingressPort\":\"3\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h14\",\"dlSrc\":\"$Mac_h12\",\"actions\":[\"OUTPUT=1\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:04/staticFlow/ofs2h12h14 curl --user "admin":"admin" -X PUT -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -d "{\"installInHw\":\"true\",\"name\":\"ofs2h13h14\",\"node\":{\"id\":\"00:00:00:00:00:00:00:04\",\"type\":\"OF\"},\"ingressPort\":\"4\",\"priority\":\"500\",\"etherType\":\"0x800\",\"dlDst\":\"$Mac_h14\",\"dlSrc\":\"$Mac_h13\",\"actions\":[\"OUTPUT=1\"]}" http://127.0.0.1:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:00:00:00:00:00:04/staticFlow/ofs2h13h14

Static Flow Installation – Fully Mesh topology Operation check 　　mininet> h11 ping h12 mininet> h11 ping h13 Cleanup 　　Stop controller. 　　Stop mininet

Static Flow Installation – Fully Mesh topology That is all for the static injection of Flow Entry. It is not an easy task. If the switch and host count increase, the required flow entries also increase and it is difficult to set one by one. We hope you have understood the fact that the controller should conceal the physical layer and must offer an abstract interface for the operator. → Next, we will see an example of this. 　　The actual VTN is in Hands on part two・・・

Load Balancer Service

Load Balancer Service Next, we will try a sample application - Load Balancer Service. Overview Load Balancer h2 メンバIP 1 仮想IP メンバIP 2 h3 h1 メンバIP 3 h4

Load Balancer Service Settings PoolRR h2 MemberIP 1 仮想IP Member IP 2

Load Balancer Service Setting sequence Creation of Pool curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://127.0.0.1:8080/one/nb/v2/lb/default/create/pool -d '{"name":"PoolRR","lbmethod":"roundrobin"}‘ Registration of virtual IP curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://127.0.0.1:8080/one/nb/v2/lb/default/create/vip -d '{"name":"VIP-RR","ip":"10.0.0.20","protocol":"TCP","port":"5550","poolname":"PoolRR"}' curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X PUT http://127.0.0.1:8080/one/nb/v2/lb/default/update/vip -d '{"name":"VIP-RR","poolname":"PoolRR"}'

Load Balancer Service Setting sequence(continued) Registration of member IP curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://127.0.0.1:8080/one/nb/v2/lb/default/create/poolmember -d '{"name":"PM2","ip":"10.0.0.2","poolname":"PoolRR"}' curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://127.0.0.1:8080/one/nb/v2/lb/default/create/poolmember -d '{"name":"PM3","ip":"10.0.0.3","poolname":"PoolRR"}' curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://127.0.0.1:8080/one/nb/v2/lb/default/create/poolmember -d '{"name":"PM4","ip":"10.0.0.4","poolname":"PoolRR"}'

Load Balancer Service Check operation Start mininet sudo mn --topo=tree,2,4 --controller=remote,ip=127.0.0.1,port=6633 Display virtual host(h1～h4) console （on mininet prompt,）　xterm h1 h2 h3 h4 Start server ・ Run the following on each console in h2～h4 iperf -s -p 5550 Accessing server from client ・ Run the following on h1 console 　arp -s 10.0.0.20 00:00:10:00:00:20 iperf -c 10.0.0.20 -p 5550 ・ Connect to 10.0.0.20:5550 again 　 iperf -c 10.0.0.20 -p 5550

Load Balancer Service S1 S3 S2 Specify in Pool srcL4=36001 → 10.0.0.2 ② Forward to controller OpenDayLight Controller S1 S3 S2 ① Traffic to 10.0.0.2 （Destination TCP port=5550 　Source TCP port=36001） h1 h2 h3 10.0.0.2 10.0.0.3 10.0.0.1

Summary That is all for hands-on part one(OpenDaylight edition). Were you able to understand the possibilities with Base edition of Hydrogen? You now have a deeper understanding of OpenFlow as well. You might think that Base Edition is not enough to perform advanced operations. In part 2, we will see more advanced features with VTN of existing project as an example.

End of part one！

Break

Part 2: VTN

Introduction to VTN

VTN Application for providing multi-tenant type virtual network on SDN controller “Virtual network” is A network where you can modify network configuration logically without modifying the configuration and settings of physical network device. “Multi-tenant” is ・Create multiple virtual planes isolated from each other on physical network and expose each virtual plane as tenants to the user. ・You can reduce CAPEX,OPEX compared to having physically independent network configuration in each tenant.

VTN model Realize virtual network by combining the components below Description Virtual node (vNode) vBridge Virtual L2 switch vRouter Virtual L3 router vTep TEP(Tunnel End Point) vTunnel Overlay tunnel vBypass Connectivity between control network Virtual Interface interface End point of virtual node Virtual link vLink Link between virtual interface

VTN features Virtual network provisioning Add, remove, modify VTN Add, remove, modify VTN model Flow control on virtual network flow filter(pass, abandon, redirect, remarking) QoS control on virtual network policing (pass, abandon, penalty) Virtual network monitoring Stats info of traffic Failure event

VTN workflow Basic workflow Virtual network provisioning Create VTN Y N VTN creation Set flow filter on virtual network Add vNode Y Add vNode N Y flow filter N Addition of interface and vLink Set QoS on virtual network Physical resource mapping Y policing N

VTN workflow flow filter QoS Create flow list (set match condition) Set flow filter to interface (set action) Create policing profile (set rate, action) Set policing profile to interface

Multi-controller orchestration You can create VTN spanning multiple data centers You can create VTN spanning different type of SDN controllers VTN vBridge vBridge vBridge vBypass vBridge vRouter Controller 1 Controller 2 Controller 3 Inter-DC network DC 1 DC 2 DC 3

Physical resource mapping Control packet flowing on virtual network by mapping the physical network resource Mapping Mapping key Description Physical Logical Port mapping Switch ID, Port ID (VLAN ID option) vBridge interface Support for Untagged frame as well VLAN mapping VLAN ID (Switch ID option) vBridge MAC mapping MAC address To be supported in Helium release

Flow filter Filtering features for packets flowing on virtual network You can specify match condition and action as filter You can set filter on any vNode interface

Flow filter match condition You can set the following fields as match condition MAC address (source/destination) Ether type VLAN priority IP address (source/destination) DSCP IP Protocol TCP/UDP port number (source/destination) ICMP type ICMP code

Redirection - WayPoint routing Flow Filter action You can set the following actions in Flow filter Action Description ACL Pass Pass the packets matching the conditions specified Drop Drop the packets matching the conditions specified Redirection - WayPoint routing Redirect packet to specific virtual interface You can modify MAC address (source/destination) (assuming L3 firewall) Remarking Remark VLAN priority, DSCP

APIs for VTN VTN offers WebAPI (REST) Resources accessible via API GET/PUT/POST/DELETE to virtual network resource Supports XML, JSON format Resources accessible via API VTN vBridge vRouter vTep vTunnel vBypass vLink interface Port mapping VLAN mapping Flow Filter Controller Physical Switch / Port / Link (Read only) Alarm (Read only)

VTN API use case OpenStack Neutron GUI System Center 3rd party Orchestration Application for appliance GUI Plug-in VTN Coordinator VTN Manager

VTN software configuration Consists of VTN Coordinator and VTN Manager VTN Coordinator: ・Offers VTN API ・Build VTN model using OpenDaylight API ・Control VTN spanning multiple SDN controllers VTN Coordinator VTN Manager VTN Manager: ・Offers virtual node feature ・Does packet forwarding control as per VTN model

VTN Manager

Software configuration（１） VTN Manager is implemented as OSGi bundle and loaded on OpenDaylight Controller.

Software configuration （２） VTN Manager is implemented as AD-SAL Application. MD-SAL is not supported. Only OpenFlow switches are managed At present, only OpenFlow 1.0 is supported.

Software configuration （３） Control OpenFlow switch via AD-SAL and internal information management component.

How to realize multi tenant： Virtual network environment VTN (Virtual Tenant Network) Virtual network environment Network inside a different VTN are managed as independent networks. vBridge (Virtual Bridge) Virtual L2 switch inside VTN Build virtual broadcast domain by mapping physical network to vBridge.

How to realize multi tenant ： Port mapping Map the VLAN on physical port of specific switch to vBridge. You cannot map physical ports to which other OpenFlow switches are connected.

How to realize multi tenant ： ＶＬＡＮ mapping Map any VLAN to vBridge. When physical switch is specified, only the VLAN on specified physical switch is mapped. When a physical switch is not specified, the VLAN on all managed switches are mapped. Physical port connected to OpenFlow switch is not in scope for VLAN mapping. Port mapping settings are given priority. VLAN on port mapped physical port is not in scope for VLAN mapping.

How to realize multi tenant ： mapping of input packets A unique vBridge to map packets is determined by VLAN and the physical port of switch where input packets are detected. You cannot map same VLAN on same physical port to multiple vBridge.

How to realize multi tenant ： determining the output destination The source host information of packet mapped to vBridge is recorded in a MAC address table inside vBridge. Source MAC address Physical port of switch that detects packet VLAN ID When performing unicast communication inside vBridge, search destination MAC address from MAC address table and determine the destination physical network. Since you determine destination VLAN with only the MAC address, it is not possible to map the same MAC address belonging to different VLAN to a single vBridge.

Broadcast communication The broadcast and multicast packets are forwarded to all physical networks that are mapped to vBridge with PACKET_OUT. No forwarding to physical networks with PACKET_IN. Flow entry is not set.

Unicast communication Set flow entry if the destination MAC address of unicast packet is recorded inside vBridge. If the address is not recorded, broadcast is done to all physical networks mapped to the vBridge. The flow entry passing a path with minimum hop count is set.

During failure：Link down(１) All flow entries passing links that are down get deleted. If the link state changes, the shortest path graph is updated.

During failure：Link down(２) PACKET_IN happens when there is communication after removal of flow entry and a flow entry passing a substitute path gets set.

During failure：Switch down(１) All flow entries passing through switch that is down are deleted. The shortest route graph is updated if switch information is deleted.

During failure ：Switch down(２) PACKET_IN happens when there is communication after removal of flow entry and a flow entry passing an alternate path gets set.

ＯｐｅｎＳｔａｃｋ(Ｎｅｕｔｒｏｎ) integration Automatically map OpenStack Neutron network with vBridge. Shared networks are not supported. Only VLAN mapping is supported in Hydrogen release. Specify VLAN to map in Neutron network attribute.

VTN hands on (1) “Multi-tenancy”

Hands-on contents Build two virtual networks on a single physical network. Check that the virtual networks are mutually isolated Communication is possible between the hosts contained in same virtual network Communication is not possible between the hosts contained in different virtual networks

Physical Network S7 S5 S6 S1 S2 S3 S4 Use “mininet”(emulator software of OpenFlow network) to build a physical network as shown below S7 S5 S6 S1 S2 S3 S4 h11 h12 h13 h14 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4

Virtual network to build Build a virtual network like the one shown below on the physical network vtn1 vtn2 vBridge vBridge vtn1: Connect h11 and h14 with L2 switch vtn2: Connect h12 and h13 with L2 switch

Advance preparations

Open terminal Keep three terminals open Use the three terminals for VTN, for controller and for mininet Follow the terminal specified when running command. If terminal is not specified, run on terminal for VTN

Set alias Set alias for a compact command display alias curl="curl -H 'content-type: application/json' -H 'username: admin' -H 'password: adminpass' -H 'ipaddr:127.0.0.1'"

Start controller, VTN Start OpenDaylight Hydrogen Controller: Setup DB Start VTN Coordinator Controller: cd ~/controller-virt/opendaylight/ ./run.sh -virt vtn sudo /usr/local/vtn/sbin/db_setup sudo /usr/local/vtn/bin/vtn_start sudo /usr/share/java/apache-tomcat-7.0.39/bin/catalina.sh start From Helium release onwards, you will be able to start Tomcat as well with vtn_start command

Check VTN startup Get version information to confirm VTN startup The result should be as below curl -X GET http://127.0.0.1:8081/vtn-webapi/api_version.json {"api_version":{"version":"V1.0"}} The port number used by VTN (Coordinator) of hands on version is 8081 but VTN of Hydrogen release uses 8080, and VTN from Hydrogen onwards uses 8083 In Helium release,“V1.2” will be displayed for version

Start-up physical network Start mininet. The scenario used is topo-tree-depth3.py mininet: sudo mn --custom ~/handson/topo-tree-depth3.py --topo mytopo --controller=remote,ip=127.0.0.1

Virtual Network Provisioning

Virtual network provisioning Run VTN API and build virtual network The concrete operation is as follows Registration of controller Register OpenDaylight Hydrogen(ODC) in VTN Provisioning of virtual network(2 tenants) Creation of VTN Creation of vBridge Creation of interface port-mapping

Registration of controller Register the controller started in “Start controller, VTN” curl -X POST -d '{"controller": {"controller_id": "odc1", "ipaddr": "127.0.0.1", "type": "odc", "version": "1.0", "auditstatus": "enable"}}' http://127.0.0.1:8081/vtn-webapi/controllers.json

Confirm controller registration Check the controller registered The result should be as follows curl -X GET http://127.0.0.1:8081/vtn-webapi/controllers/detail.json {"controllers":[{"controller_id":"odc1","ipaddr":"127.0.0.1","auditstatus":"enable","operstatus":"up","actual_version":"1.0.0.0","version":"1.0"}]}

Creation of VTN Create VTN This is the image of virtual network at this point of time. We have created a box for us to work on curl -X POST -d '{"vtn": {"vtn_name": "vtn1"}}' http://127.0.0.1:8081/vtn-webapi/vtns.json vtn1

Creation of vBridge Next, create vBridge inside VTN With this, we have placed a switch inside the box curl -X POST -d '{"vbridge": {"vbr_name": "vbr1", "controller_id": "odc1", "domain_id": "(DEFAULT)"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn1/vbridges.json vtn1 vBridge

Creation of interface Create two interface With this, we have created two interfaces in L2 switch curl -X POST -d '{"interface": {"if_name": "if1"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn1/vbridges/vbr1/interfaces.json curl -X POST -d '{"interface": {"if_name": "if2"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn1/vbridges/vbr1/interfaces.json vtn1 vBridge

Before port mapping To do port-mapping, it is necessary to know the port information of s1, s4 connected to h11, h14 vtn1 vBridge Which port of s1 to map to? Which port of s4 to map to?

Get logical-port Get logical-port. logical-port refers to the port information etc. recognized by the controller From the output result, get the logical-port of target switch, port based on the DPID, port name etc. In this example, get the following logical-port curl -v -X GET http://127.0.0.1:8081/vtn-webapi/controllers/odc1/domains/\(DEFAULT\)/logical_ports.json "PP-OF:00:00:00:00:00:00:00:01-s1-eth1" "PP-OF:00:00:00:00:00:00:00:04-s4-eth1"

port-mapping settings Now, port map the logical-port to the interface created before curl -v -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:01-s1-eth1"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn1/vbridges/vbr1/interfaces/if1/portmap.json curl -v -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:04-s4-eth1"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn1/vbridges/vbr1/interfaces/if2/portmap.json

port-mapping settings With this we have finished the settings for one tenant vtn1 vBridge PP-OF:00:00:00:00:00:00:00:01-s1-eth1 PP-OF:00:00:00:00:00:00:00:04-s4-eth1

Creation of second VTN Now, create another tenant the same way. curl -v -X POST -d '{"vtn": {"vtn_name": "vtn2"}}' http://127.0.0.1:8081/vtn-webapi/vtns.json curl -v -X POST -d '{"vbridge": {"vbr_name": "vbr1", "controller_id": "odc1", "domain_id": "(DEFAULT)"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn2/vbridges.json curl -v -X POST -d '{"interface": {"if_name": "if1"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn2/vbridges/vbr1/interfaces.json curl -v -X POST -d '{"interface": {"if_name": "if2"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn2/vbridges/vbr1/interfaces.json curl -v -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:02-s2-eth1"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn2/vbridges/vbr1/interfaces/if1/portmap.json curl -v -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:03-s3-eth1"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn2/vbridges/vbr1/interfaces/if2/portmap.json

Check communication Now, let us check for communication between hosts Execute ping on mininet console Ping will succeed between hosts contained in the same virtual network Ping will fail between hosts contained in different virtual networks mininet: mininet > h11 ping h14 mininet > h12 ping h13 mininet: mininet > h11 ping h12 mininet > h13 ping h14

Summary We built two virtual networks on a single physical network We confirmed that the virtual network is logically separated Communication is possible between hosts contained in same virtual network Communication is not possible between hosts contained in different virtual networks

Cleanup Now, stop VTN Stop the controller as well Stop mininet too sudo /usr/share/java/apache-tomcat-7.0.39/bin/catalina.sh stop sudo /usr/local/vtn/bin/vtn_stop mininet: mininet > exit From Helium release onwards, you can also terminate Tomcat with vtn_stop command

VTN hands on (2) Building virtual networks for VLAN

Hands on contents Build virtual network containing same VLAN communication Experience amazing ease in configuring virtual networks for VLAN

Physical Network This time, use mininet to build a physical network as shown below This topology was also used in OpenDaylight hands-on S1 S2 h11 h12 10.0.0.1 10.0.0.3 S3 S4 h13 h14 10.0.0.2 10.0.0.4

Virtual network to build Build a virtual network as shown below on the physical network vtn3 vBridge VLAN mapping (no VLAN tag)

Start controller,VTN Now, let us start the controller and VTN once again. The command is same as before. Controller: cd ~/controller-virt/opendaylight/ ./run.sh -virt vtn sudo /usr/local/vtn/sbin/db_setup sudo /usr/local/vtn/bin/vtn_start sudo /usr/share/java/apache-tomcat-7.0.39/bin/catalina.sh start

Physical network start-up Now, start mininet. The script to use is topo-fullyMesh.py mininet: sudo mn --custom ~/handson/topo-fullyMesh.py --topo mytopo --controller=remote,ip=127.0.0.1

Provisioning in VTN Run VTN API and perform provisioning Registration of controller Register OpenDaylight Hydrogen(ODC) in VTN VTN provisioning Creation of VTN Creation of vBridge VLAN mapping

Creation of controller ~ creation of vBridge The sequence is same as before till creation of vBridge With this, we were able to complete till here curl -v -X POST -d '{"controller": {"controller_id": "odc1", "ipaddr": "127.0.0.1", "type": "odc", "version": "1.0", "auditstatus": "enable"}}' http://127.0.0.1:8081/vtn-webapi/controllers.json curl -v -X POST -d '{"vtn": {"vtn_name": "vtn3"}}' http://127.0.0.1:8081/vtn-webapi/vtns.json curl -v -X POST -d '{"vbridge": {"vbr_name": "vbr1", "controller_id": "odc1", "domain_id": "(DEFAULT)"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn3/vbridges.json vtn3 vBridge

VLAN mapping In VLAN mapping, you can specify the VLANID(or Untagged packet) handled by all switches and map it to vBridge Consequently, interface creation is not required Now, let us try and do VLAN mapping We will map an Untagged packet here curl -v -X POST -d '{"vlanmap": {"no_vlan_id": "true"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn3/vbridges/vbr1/vlanmaps.json

VLAN mapping Such ease in packing virtual networks for VLAN! vtn3 vBridge VLAN mapping (Untagged packet)

Check for communication Now, check the communication between hosts Do ping on mininet console Ping is successful between every host Ping packet is an Untagged packet mininet: mininet > h11 ping h12 mininet > h11 ping h13 ... mininet > h13 ping h14

Summary We built a virtual network with same VLAN You must have realized how easy it is to configure virtual networks for VLAN

Cleanup Now, stop VTN Stop OpenDaylight Hydrogen as well Stop mininet. sudo /usr/share/java/apache-tomcat-7.0.39/bin/catalina.sh stop sudo /usr/local/vtn/bin/vtn_stop mininet: mininet > exit

Practice Problems

Physical Network S7 S5 S6 S1 S2 S3 S4 Assume a network inside a building Companies A,B and C are on the first and second floor. VLAN ID is different for each company. S7 Network on 1F Network on 2F S5 S6 CompanyA (VID:100) CompanyB (VID:200) Company A (VID:100) Company C (VID:300) S1 S2 S3 S4 h11 h12 h13 h14 h15 h16 h17 h18 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4 10.0.0.5 10.0.0.6 10.0.0.7 10.0.0.8

Virtual network to build Problem: Build VTN for company A, B and C vtn4 vtn5 vtn6 vBridge vBridge vBridge VLAN mapping VLAN ID:100 VLAN mapping VLAN ID:200 VLAN mapping VLAN ID:300

Start controller, VTN Now, start controller and VTN once again. The command is same as before. Controller: cd ~/controller-virt/opendaylight/ ./run.sh -virt vtn sudo /usr/local/vtn/sbin/db_setup sudo /usr/local/vtn/bin/vtn_start sudo /usr/share/java/apache-tomcat-7.0.39/bin/catalina.sh start

Physical network startup First, start mininet. The script to use is topo-tree-depth3-host8.py mininet: sudo mn --custom ~/handson/topo-tree-depth3-host8.py --topo mytopo --controller=remote,ip=127.0.0.1

VLAN ID allocation to host Startup xterm on host h11~h18 and set VLAN ID Run the following commands on each xterm Read host name whenever required VLAN ID is allocated to each host by executing set_vlan.sh mininet: mininet > xterm h11 h12 h13 h14 h15 h16 h17 h18 mininet(xterm): root@mininet-vm:~\> ~/handson/set_vlan.sh h11 root@mininet-vm:~\> exit

Think！

Check the answers Were you able to? curl -v -X POST -d '{"controller": {"controller_id": "odc1", "ipaddr": "127.0.0.1", "type": "odc", "version": "1.0", "auditstatus":"enable"}}' http://127.0.0.1:8081/vtn-webapi/controllers.json curl -v -X POST -d '{"vtn": {"vtn_name": "vtn4"}}' http://127.0.0.1:8081/vtn-webapi/vtns.json curl -v -X POST -d '{"vtn": {"vtn_name": "vtn5"}}' http://127.0.0.1:8081/vtn-webapi/vtns.json curl -v -X POST -d '{"vtn": {"vtn_name": "vtn6"}}' http://127.0.0.1:8081/vtn-webapi/vtns.json curl -v -X POST -d '{"vbridge": {"vbr_name": "vbr1", "controller_id": "odc1", "domain_id": "(DEFAULT)"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn4/vbridges.json curl -v -X POST -d '{"vbridge": {"vbr_name": "vbr1", "controller_id": "odc1", "domain_id": "(DEFAULT)"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn5/vbridges.json curl -v -X POST -d '{"vbridge": {"vbr_name": "vbr1", "controller_id": "odc1", "domain_id": "(DEFAULT)"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn6/vbridges.json curl -v -X POST -d '{"vlanmap": {"vlan_id": "100"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn4/vbridges/vbr1/vlanmaps.json curl -v -X POST -d '{"vlanmap": {"vlan_id": "200"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn5/vbridges/vbr1/vlanmaps.json curl -v -X POST -d '{"vlanmap": {"vlan_id": "300"}}' http://127.0.0.1:8081/vtn-webapi/vtns/vtn6/vbridges/vbr1/vlanmaps.json

Check connectivity You can check for successful build with mininet. Start-up xterm in h11 Ping should be successful from host h11 to h12, h15, h16 Also check that there is no ping from host h11 to h13, h14, h17, h18 mininet: mininet > xterm h11 mininet(xterm): root@mininet-vm:~\> ping 10.0.0.2 root@mininet-vm:~\> ping 10.0.0.5 root@mininet-vm:~\> ping 10.0.0.6

Summary Increased understanding about VTN through introduction to VTN and hands-on VTN is a vendor neutral virtual network technology adopted in Hydrogen release. It is an easy to use technology and anyone can participate in the development. Detailed information regarding VTN can be found on the following page. For those who are interested, please refer this page! https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Main

Thank you for your time!