BK User Guide 20160221

Op enDaylight
User Guide
Beryllium (February 21, 2016)
OpenDaylight User Guide February 21, 2016 Beryllium
OpenDaylight User Guide

OpenDaylight Community
Beryllium (2016-02-21)
Copyright © 2015 Linux Foundation All rights reserved.
This guide describes how to use and deploy OpenDaylight.

This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which
accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v10.html
ii
Table of Contents
I. Getting Started with OpenDaylight .............................................................................. 1
1. OpenDaylight Controller Overview ...................................................................... 2
2. Using the OpenDaylight User Interface (DLUX) .................................................... 3
Getting Started with DLUX ............................................................................. 3
Logging In ...................................................................................................... 3
Working with DLUX ........................................................................................ 3
Viewing Network Statistics .............................................................................. 4
Viewing Network Topology ............................................................................. 4
Interacting with the YANG-based MD-SAL datastore ....................................... 5
3. Running XSQL Console Commands and Queries ................................................. 12
XSQL Overview .............................................................................................. 12
Installing XSQL .............................................................................................. 12
XSQL Console Commands .............................................................................. 12
XSQL Queries ................................................................................................ 13
4. Setting Up Clustering ........................................................................................ 15
Clustering Overview ...................................................................................... 15
Single Node Clustering .................................................................................. 15
Multiple Node Clustering ............................................................................... 16
II. Applications and Plugins ............................................................................................ 21
5. ALTO User Guide ............................................................................................... 22
Overview ....................................................................................................... 22
ALTO Architecture ......................................................................................... 22
Configuring ALTO ......................................................................................... 22
Administering or Managing ALTO ................................................................. 23
6. Authentication and Authorization Services ........................................................ 26
Authentication Service ................................................................................... 26
Administering OpenDaylight Authentication Services ..................................... 32
OpenDaylight Authorization Service .............................................................. 33
7. Armoury ............................................................................................................ 34
Overview ....................................................................................................... 34
Armoury Architecture .................................................................................... 34
Armoury Catalog ........................................................................................... 34
Armoury Workload Manager ......................................................................... 35
Armoury Driver Registry ................................................................................ 35
Tutorials ........................................................................................................ 35
8. BGP User Guide ................................................................................................. 37
Overview ....................................................................................................... 37
Configuring BGP ............................................................................................ 37
Configuration through RESTCONF ................................................................. 41
Tutorials ........................................................................................................ 45
9. CAPWAP User Guide ......................................................................................... 49
Overview ....................................................................................................... 49
CAPWAP Architecture ................................................................................... 49
Scope of CAPWAP Project ............................................................................. 49
Installing CAPWAP ........................................................................................ 49
Configuring CAPWAP .................................................................................... 49
Administering or Managing CAPWAP ............................................................ 50
Tutorials ........................................................................................................ 50
iii
10. DIDM User Guide ............................................................................................ 51

Overview ....................................................................................................... 51
DIDM Architecture ........................................................................................ 51
11. Group Based Policy User Guide ........................................................................ 52
Overview ....................................................................................................... 52
GBP Base Architecture and Value Proposition ................................................ 54
Using the GBP UX interface ........................................................................... 70
Using the GBP API ......................................................................................... 83
Using OpenStack with GBP ............................................................................ 84
Using the GBP OpenFlow Overlay (OfOverlay) renderer ................................. 90
Using the GBP eBPF IO Visor Agent renderer ............................................... 101
Using the GBP FaaS renderer ....................................................................... 101
Using Service Function Chaining (SFC) with GBP Neutron Mapper and
OfOverlay .................................................................................................... 102
Demo/Development environment ................................................................ 107
12. L2Switch User Guide ...................................................................................... 108
Overview ..................................................................................................... 108
L2Switch Architecture .................................................................................. 108
Configuring L2Switch ................................................................................... 109
Configuring Loop Remover .......................................................................... 109
Configuring Arp Handler ............................................................................. 110
Configuring Address Tracker ........................................................................ 111
Configuring L2Switch Main .......................................................................... 111
Running the L2Switch project ...................................................................... 113
Create a network using mininet .................................................................. 113
Generating network traffic using mininet .................................................... 113
Checking Address Observations ................................................................... 113
Checking Hosts ............................................................................................ 114
Checking STP status of each link .................................................................. 115
Miscellaneous mininet commands ................................................................ 116
13. L3VPN Service: User Guide ............................................................................. 117
Overview ..................................................................................................... 117
Modules & Interfaces .................................................................................. 117
Provisioning Sequence & Sample Configurations .......................................... 121
14. Link Aggregation Control Protocol User Guide ............................................... 125
Overview ..................................................................................................... 125
Link Aggregation Control Protocol Architecture ........................................... 125
Configuring Link Aggregation Control Protocol ............................................ 125
Administering or Managing Link Aggregation Control Protocol .................... 126
Tutorials ...................................................................................................... 126
15. LISP Flow Mapping User Guide ...................................................................... 129
Overview ..................................................................................................... 129
LISP Flow Mapping Architecture .................................................................. 130
Configuring LISP Flow Mapping ................................................................... 131
Textual Conventions for LISP Address Formats ............................................. 132
Karaf commands ......................................................................................... 133
LISP Flow Mapping Karaf Features .............................................................. 134
Tutorials ...................................................................................................... 134
LISP Flow Mapping Support ......................................................................... 140
16. Messaging4Transport User Guide ................................................................... 141
Overview ..................................................................................................... 141
iv
Architecture ................................................................................................ 141

Administering or Managing Messaging4Transport ....................................... 142
17. NEtwork MOdeling (NEMO) .......................................................................... 144
Overview ..................................................................................................... 144
NEMO Engine Architecture .......................................................................... 144
Configuring NEMO Engine ........................................................................... 144
Administering or Managing NEMO Engine ................................................... 144
Tutorials ...................................................................................................... 144
18. NetIDE User Guide ......................................................................................... 146
Overview ..................................................................................................... 146
NetIDE API .................................................................................................. 146
19. Network Intent Composition (NIC) User Guide ............................................... 149
Overview ..................................................................................................... 149
Network Intent Composition (NIC) Architecture ........................................... 149
Configuring Network Intent Composition (NIC) ........................................... 150
Administering or Managing Network Intent Composition (NIC) .................... 150
Interactions ................................................................................................. 150
NIC Usage Examples .................................................................................... 151
20. ODL-SDNi User Guide ..................................................................................... 154
Introduction ................................................................................................ 154
Components ................................................................................................ 154
Troubleshooting .......................................................................................... 154
21. OpenFlow Plugin Project User Guide .............................................................. 155
Overview and Architecture .......................................................................... 155
Tutorial / How-To ........................................................................................ 157
Web / Graphical Interface ........................................................................... 189
Command Line Interface ............................................................................. 189
Programmatic Interface ............................................................................... 193
Example flows ............................................................................................. 193
Opendaylight OpenFlow Plugin: Troubleshooting ......................................... 221
22. OpFlex agent-ovs User Guide ......................................................................... 222
Introduction ................................................................................................ 222
Agent Configuration .................................................................................... 222
Endpoint Registration .................................................................................. 224
Inspector ..................................................................................................... 226
23. PCEP User Guide ............................................................................................ 229
Overview ..................................................................................................... 229
Configuring PCEP ......................................................................................... 229
24. PacketCable User Guide ................................................................................. 230
Overview ..................................................................................................... 230
PacketCable Components ............................................................................ 230
Installing PacketCable .................................................................................. 230
Explore and exercise the PacketCable REST API ............................................ 230
Postman ...................................................................................................... 231
25. Service Function Chaining .............................................................................. 232
OpenDaylight Service Function Chaining (SFC) Overiew ................................ 232
SFC User Interface ....................................................................................... 233
SFC Southbound REST Plugin ....................................................................... 233
SFC-OVS integration .................................................................................... 235
SFC Classifier User Guide .............................................................................. 237
SFC OpenFlow Layer 2 Renderer User Guide ................................................ 239
v
Service Function Scheduling Algorithms ....................................................... 249

Service Function Load Balancing User Guide ................................................ 261
26. SNMP Plugin User Guide ................................................................................ 264
Installing Feature ......................................................................................... 264
Northbound APIs ......................................................................................... 264
27. SXP User Guide .............................................................................................. 267
Overview ..................................................................................................... 267
SXP Architecture .......................................................................................... 267
Configuring SXP .......................................................................................... 268
Administering or Managing SXP .................................................................. 268
28. TCPMD5 User Guide ...................................................................................... 272
Overview ..................................................................................................... 272
Configuring TCPMD5 manually .................................................................... 272
Configuring TCPMD5 through RESTCONF ..................................................... 275
29. TSDR H2 datastore User Guide ...................................................................... 280
Overview ..................................................................................................... 280
TSDR Architecture ....................................................................................... 280
Configuring TSDR with default datastore H2 ................................................ 280
Administering or Managing TSDR with default datastore H2 ........................ 280
30. TSDR HBase Data Store User Guide ................................................................ 282
Overview ..................................................................................................... 282
TSDR with HBase Data Store Architecture .................................................... 282
Configuring TSDR with HBase Data Store ..................................................... 283
Administering or Managing TSDR HBase Data Store ..................................... 283
Tutorials ...................................................................................................... 284
31. TTP CLI Tools User Guide ............................................................................... 286
Overview ..................................................................................................... 286
TTP CLI Tools Architecture ........................................................................... 286
32. Unified Secure Channel .................................................................................. 287
Overview ..................................................................................................... 287
USC Channel Architecture ............................................................................ 287
Installing USC Channel ................................................................................. 288
Configuring USC Channel ............................................................................. 288
Administering or Managing USC Channel ..................................................... 288
Tutorials ...................................................................................................... 288
33. Virtual Tenant Network (VTN) ....................................................................... 290
VTN Overview ............................................................................................. 290
VTN OpenStack Configuration ..................................................................... 299
VTN Usage Examples ................................................................................... 321
34. NETCONF User Guide ..................................................................................... 346
Overview ..................................................................................................... 346
Southbound (netconf-connector) ................................................................. 346
Northbound (NETCONF servers) .................................................................. 353
NETCONF testtool ....................................................................................... 355
35. YANG-PUSH ................................................................................................... 357
Overview ..................................................................................................... 357
YANG-PUSH Architecture ............................................................................. 358
YANG-PUSH Catalog .................................................................................... 358
YANG-PUSH Workload Manager .................................................................. 358
Configuring YANG-PUSH Workload Manager ............................................... 358
Administering YANG-PUSH Workload Manager ............................................ 359
vi
Tutorials ...................................................................................................... 359
vii
List of Figures
2.1. DLUX Modules ......................................................................................................... 4
2.2. Topology Module ..................................................................................................... 5
2.3. Yang UI .................................................................................................................... 6
2.4. Yang API Specification .............................................................................................. 7
2.5. Yang UI API Specification ......................................................................................... 8
2.6. DLUX Yang Topology ............................................................................................... 9
2.7. DLUX List Elements ................................................................................................ 10
2.8. DLUX List Warnings ................................................................................................ 10
2.9. DLUX List Button1 .................................................................................................. 11
11.1. Intent System Process and Policy Surfaces ............................................................. 53
11.2. GBP Access Model Terminology - Endpoints, EndpointGroups, Contract ................. 55
11.3. GBP Access Model Terminology - Subject, Classifier, Action .................................... 56
11.4. GBP Forwarding Model Terminology - L3 Context, L2 Bridge Context, L2 Flood
Context/Domain, Subnet ............................................................................................... 57
11.5. GBP Access (or Core) Model ................................................................................. 58
11.6. GBP Forwarding Model ......................................................................................... 59
11.7. GBP Endpoints, EndpointGroups and Contracts ..................................................... 60
11.8. GBP Endpoints and the Forwarding Model ............................................................ 61
11.9. GBP High Level Beryllium Architecture .................................................................. 62
11.10. GBP High Level Beryllium Architecture - adding a renderer ................................... 63
11.11. GBP High Level Beryllium Architecture - adding a renderer ................................... 63
11.12. Basic view ........................................................................................................... 70
11.13. Governance view ................................................................................................ 71
11.14. Expressed policy .................................................................................................. 72
11.15. Delivered policy .................................................................................................. 73
11.16. Subject detail ...................................................................................................... 73
11.17. EPG detail ........................................................................................................... 74
11.18. Renderer state .................................................................................................... 75
11.19. Navigation menu ................................................................................................ 76
11.20. CRUD operations ................................................................................................ 77
11.21. L2/L3 Topology ................................................................................................... 78
11.22. Config Topology ................................................................................................. 78
11.23. Wizard ................................................................................................................ 83
11.24. Neutron Port ...................................................................................................... 85
11.25. Neutron Network ............................................................................................... 85
11.26. Neutron Subnet .................................................................................................. 86
11.27. Neutron Security Group and Rules ...................................................................... 86
11.28. Neutron Router .................................................................................................. 87
11.29. Neutron network mapping ................................................................................. 88
11.30. Neutron subnet mapping .................................................................................... 89
11.31. Neutron port mapping ....................................................................................... 89
11.32. OfOverlay within GBP ......................................................................................... 91
11.33. OfOverlay expanded view: .................................................................................. 92
11.34. OfOverlay Flow Pipeline ...................................................................................... 93
11.35. GBP and SFC integration environment ............................................................... 103
11.36. GBP and SFC symmetric chain environment ....................................................... 104
11.37. GBP and SFC assymmetric chain environment .................................................... 104
12.1. Address Observations .......................................................................................... 114
viii
12.2. Hosts .................................................................................................................. 115

12.3. STP status ........................................................................................................... 116
15.1. LISP Mapping Service Internal Architecture ......................................................... 130
18.1. NetIDE Network Engine Architecture .................................................................. 147
18.2. NetIDE Communication Flow .............................................................................. 148
21.1. overal architecture .............................................................................................. 156
21.2. configuring a host-only adapter .......................................................................... 161
24.1. Postman Operations ........................................................................................... 231
25.1. SFC-UI integration into ODL ................................................................................ 233
25.2. Soutbound REST Plugin integration into ODL ...................................................... 234
25.3. SFC-OVS integration into ODL ............................................................................. 235
25.4. SFC OpenFlow Renderer High Level Architecture ................................................. 240
25.5. SFC OpenFlow Renderer Typical Network Topology ............................................. 241
25.6. SFC OpenFlow Renderer Typical Network Topology ............................................. 244
25.7. SF Selection Architecture ..................................................................................... 250
25.8. Mozilla Firefox RESTClient ................................................................................... 251
25.9. Karaf Web UI ..................................................................................................... 252
25.10. select schedule type .......................................................................................... 260
25.11. rendered service path ....................................................................................... 261
33.1. VTN Overview ..................................................................................................... 291
33.2. VTN Construction ................................................................................................ 293
33.3. VTN Mapping ..................................................................................................... 294
33.4. VTN FlowFilter .................................................................................................... 297
33.5. VTN API .............................................................................................................. 298
33.6. LAB Setup ........................................................................................................... 300
33.7. Horizon GUI ........................................................................................................ 309
33.8. Hypervisors ......................................................................................................... 310
33.9. Create Network .................................................................................................. 311
33.10. Step 1 ............................................................................................................... 312
33.11. Step 2 ............................................................................................................... 313
33.12. Step 3 ............................................................................................................... 314
33.13. Instance Creation .............................................................................................. 315
33.14. Launch Instance ................................................................................................ 316
33.15. Launch Network ............................................................................................... 317
33.16. Load All Instances ............................................................................................. 318
33.17. Instance Console ............................................................................................... 319
33.18. Ping .................................................................................................................. 320
33.19. EXAMPLE DEMONSTRATING SINGLE CONTROLLER ........................................... 321
33.20. EXAMPLE DEMONSTRATING MULTIPLE CONTROLLERS ..................................... 323
33.21. Example that demonstrates vlanmap testing in Mininet Environment ................. 325
33.22. EXAMPLE DEMONSTRATING VTN STATIONS ..................................................... 327
33.23. Flow Filter ......................................................................................................... 331
33.24. PathMap ........................................................................................................... 334
33.25. Set-Up Diagram ................................................................................................. 340
ix
List of Tables
3.1. Supported XSQL Console Commands ...................................................................... 12
3.2. Supported XSQL Query Criteria Operators .............................................................. 13
15.1. LISP Address Formats .......................................................................................... 133
15.2. Nodes in the tutorial .......................................................................................... 135
25.1. Table Transport Ingress ....................................................................................... 241
25.2. Table Path Mapper ............................................................................................. 242
25.3. Table Next Hop .................................................................................................. 242
25.4. Table Transport Egress ........................................................................................ 242
x
Part I. Getting Started with OpenDaylight
This first part of the user guide covers the basic user operations of the OpenDaylight Release using the
generic base functionality.
1. OpenDaylight Controller Overview

The OpenDaylight controller is JVM software and can be run from any operating system
and hardware as long as it supports Java. The controller is an implementation of the
Software Defined Network (SDN) concept and makes use of the following tools:
• Maven: OpenDaylight uses Maven for easier build automation. Maven uses pom.xml
(Project Object Model) to script the dependencies between bundle and also to describe
what bundles to load and start.
• OSGi: This framework is the back-end of OpenDaylight as it allows dynamically

loading bundles and packages JAR files, and binding bundles together for exchanging
information.
• JAVA interfaces: Java interfaces are used for event listening, specifications, and forming
patterns. This is the main way in which specific bundles implement call-back functions for
events and also to indicate awareness of specific state.
• REST APIs: These are northbound APIs such as topology manager, host tracker, flow
programmer, static routing, and so on.
The controller exposes open northbound APIs which are used by applications. The OSGi
framework and bidirectional REST are supported for the northbound APIs. The OSGi
framework is used for applications that run in the same address space as the controller
while the REST (web-based) API is used for applications that do not run in the same address
space (or even the same system) as the controller. The business logic and algorithms reside
in the applications. These applications use the controller to gather network intelligence, run
its algorithm to do analytics, and then orchestrate the new rules throughout the network.
On the southbound, multiple protocols are supported as plugins, e.g. OpenFlow 1.0,
OpenFlow 1.3, BGP-LS, and so on. The OpenDaylight controller starts with an OpenFlow 1.0
southbound plugin. Other OpenDaylight contributors begin adding to the controller code.
These modules are linked dynamically into a Service Abstraction Layer (SAL).
The SAL exposes services to which the modules north of it are written. The SAL figures
out how to fulfill the requested service irrespective of the underlying protocol used
between the controller and the network devices. This provides investment protection to
the applications as OpenFlow and other protocols evolve over time. For the controller
to control devices in its domain, it needs to know about the devices, their capabilities,
reachability, and so on. This information is stored and managed by the Topology Manager.
The other components like ARP handler, Host Tracker, Device Manager, and Switch
Manager help in generating the topology database for the Topology Manager.
For a more detailed overview of the OpenDaylight controller, see the OpenDaylight
Developer Guide.
2
2. Using the OpenDaylight User Interface

(DLUX)
Table of Contents
Getting Started with DLUX ............................................................................................. 3
Logging In ...................................................................................................................... 3
Working with DLUX ........................................................................................................ 3
Viewing Network Statistics .............................................................................................. 4
Viewing Network Topology ............................................................................................. 4
Interacting with the YANG-based MD-SAL datastore ....................................................... 5
This section introduces you to the OpenDaylight User Experience (DLUX) application.
Getting Started with DLUX

DLUX provides a number of different Karaf features, which you can enable and disable
separately. In Beryllum they are: . odl-dlux-core . odl-dlux-node . odl-dlux-yangui . odl-dlux-
yangvisualizer
Logging In
To log in to DLUX, after installing the application:
1. Open a browser and enter the login URL http://<your-karaf-ip>:8181/index.html in your

browser (Chrome is recommended).
2. Login to the application with your username and password credentials.
Note
OpenDaylight’s default credentials are admin for both the username and
password.
Working with DLUX

After you login to DLUX, if you enable only odl-dlux-core feature, you will see only topology
application available in the left pane.
Note
To make sure topology displays all the details, enable the odl-l2switch-switch
feature in Karaf.
DLUX has other applications such as node, yang UI and those apps won’t show up, until
you enable their features odl-dlux-node and odl-dlux-yangui respectively in the Karaf
distribution.
3
Figure 2.1. DLUX Modules
Note
If you install your application in dlux, they will also show up on the left hand
navigation after browser page refresh.
Viewing Network Statistics

The Nodes module on the left pane enables you to view the network statistics and port
information for the switches in the network.
To use the Nodes module:
1. Select Nodes on the left pane. The right pane displays atable that lists all the nodes,
node connectors and the statistics.
2. Enter a node ID in the Search Nodes tab to search by node connectors.
3. Click on the Node Connector number to view details such as port ID, port name, number
of ports per switch, MAC Address, and so on.
4. Click Flows in the Statistics column to view Flow Table Statistics for the particular node
like table ID, packet match, active flows and so on.
5. Click Node Connectors to view Node Connector Statistics for the particular node ID.
Viewing Network Topology

The Topology tab displays a graphical representation of network topology created.
4
Note
DLUX does not allow for editing or adding topology information. The
topology is generated and edited in other modules, e.g., the OpenFlow plugin.
OpenDaylight stores this information in the MD-SAL datastore where DLUX can
read and display it.
To view network topology:
1. Select Topology on the left pane. You will view the graphical representation on the right
pane. In the diagram blue boxes represent the switches, the black represents the hosts
available, and lines represents how the switches and hosts are connected.
2. Hover your mouse on hosts, links, or switches to view source and destination ports.
3. Zoom in and zoom out using mouse scroll to verify topology for larger topologies.
Figure 2.2. Topology Module
Interacting with the YANG-based MD-SAL

datastore
The Yang UI module enables you to interact with the YANG-based MD-SAL datastore. For
more information about YANG and how it interacts with the MD-SAL datastore, see the
Controller and YANG Tools section of the OpenDaylight Developer Guide.
5
Figure 2.3. Yang UI
To use Yang UI:
1. Select Yang UI on the left pane. The right pane is divided in two parts.
2. The top part displays a tree of APIs, subAPIs, and buttons to call possible functions (GET,
POST, PUT, and DELETE).
Note
Not every subAPI can call every function. For example, subAPIs in the
operational store have GET functionality only.
Inputs can be filled from OpenDaylight when existing data from OpenDaylight is
displayed or can be filled by user on the page and sent to OpenDaylight.
Buttons under the API tree are variable. It depends on subAPI specifications. Common
buttons are:
• GET to get data from OpenDaylight,
• PUT and POST for sending data to OpenDaylight for saving
• DELETE for sending data to OpenDaylight for deleting.
You must specify the xpath for all these operations. This path is displayed in the same
row before buttons and it may include text inputs for specific path element identifiers.
6
Figure 2.4. Yang API Specification
3. The bottom part of the right pane displays inputs according to the chosen subAPI.
• Lists are handled as a special case. For example, a device can store multiple flows. In
this case "flow" is name of the list and every list element is identified by a unique key
value. Elements of a list can, in turn, contain other lists.
• In Yang UI, each list element is rendered with the name of the list it belongs to, its key,
its value, and a button for removing it from the list.
7
Figure 2.5. Yang UI API Specification
4. After filling in the relevant inputs, click the Show Preview button under the API tree to
display request that will be sent to OpenDaylight. A pane is displayed on the right side
with text of request when some input is filled.
Displaying Topology on the Yang UI

To display topology:
1. Select subAPI network-topology <topology revision number> == > operational == >

network-topology.
2. Get data from OpenDaylight by clicking on the "GET" button.
3. Click Display Topology.
8
Figure 2.6. DLUX Yang Topology
Configuring List Elements on the Yang UI

Lists in Yang UI are displayed as trees. To expand or collapse a list, click the arrow before
name of the list. To configure list elements in Yang UI:
1. To add a new list element with empty inputs use the plus icon-button + that is provided
after list name.
2. To remove several list elements, use the X button that is provided after every list
element.
9
Figure 2.7. DLUX List Elements
3. In the YANG-based data store all elements of a list must have a unique key. If you try to
assign two or more elements the same key, a warning icon ! is displayed near their name
buttons.
Figure 2.8. DLUX List Warnings
4. When the list contains at least one list element, after the + icon, there are buttons to
select each individual list element. You can choose one of them by clicking on it. In
10
addition, to the right of the list name, there is a button which will display a vertically
scrollable pane with all the list elements.
Figure 2.9. DLUX List Button1
11
3. Running XSQL Console Commands and

Queries
Table of Contents
XSQL Overview ............................................................................................................. 12
Installing XSQL .............................................................................................................. 12
XSQL Console Commands .............................................................................................. 12
XSQL Queries ................................................................................................................ 13
XSQL Overview
XSQL is an XML-based query language that describes simple stored procedures which parse
XML data, query or update database tables, and compose XML output. XSQL allows you to
query tree models like a sequential database. For example, you could run a query that lists
all of the ports configured on a particular module and their attributes.
The following sections cover the XSQL installation process, supported XSQL commands, and
the way to structure queries.
Installing XSQL
To run commands from the XSQL console, you must first install XSQL on your system:
1. Navigate to the directory in which you unzipped OpenDaylight
2. Start Karaf:
./bin/karaf
3. Install XSQL:
feature:install odl-mdsal-xsql
XSQL Console Commands

To enter a command in the XSQL console, structure the command as follows: odl:xsql
<XSQL command>
The following table describes the commands supported in this OpenDaylight release.
Table 3.1. Supported XSQL Console Commands

Command Description
r Repeats the last command you executed.
12
list vtables Lists the schema node containers that are currently installed. Whenever an
OpenDaylight module is installed, its YANG model is placed in the schema context.
At that point, the XSQL receives a notification, confirms that the module’s YANG
model resides in the schema context and then maps the model to XSQL by setting
up the necessary vtables and vfields. This command is useful when you need to
determine vtable information for a query.
list vfields <vtable name> Lists the vfields present in a specific vtable. This command is useful when you need
to determine vfields information for a query.
jdbc <ip address> When the ODL server is behind a firewall, and the JDBC client cannot connect to
the JDBC server, run this command to start the client as a server and establish a
connection.
exit Closes the console.
tocsv Enables or disables the forwarding of query output as a .csv file.
filename <filename> Specifies the .tocsv file to which the query data is exported. If you do not specify a
value for this option when the toccsv option is enabled, the filename for the query
data file is generated automatically.
XSQL Queries
You can run a query to extract information that meets the criteria you specify using the
information provided by the list vtables and list vfields <vtable name> commands. Any
query you run should be structured as follows:
select <vfields you want to search for, separated by a comma and a space> from <vtables
you want to search in, separated by a comma and a space> where <criteria> *<criteria
operator>;*
For example, if you want to search the nodes/node ID field in the nodes/node-connector
table and find every instance of the Hardware-Address object that contains BA in its text
string, enter the following query:
select nodes/node.ID from nodes/node-connector where Hardware-Address like
'%BA%';
The following criteria operators are supported:
Table 3.2. Supported XSQL Query Criteria Operators

Criteria Operators Description
= Lists results that equal the value you specify.
!= Lists results that do not equal the value you specify.
like Lists results that contain the substring you specify. For example, if you specify like %BC%, every
string that contains that particular substring is displayed.
< Lists results that are less than the value you specify.
> Lists results that are more than the value you specify.
and Lists results that match both values you specify.
or Lists results that match either of the two values you specify.
>= Lists results that are more than or equal to the value you specify.
⇐ Lists results that are less than or equal to the value you specify.
is null Lists results for which no value is assigned.
not null Lists results for which any value is assigned.
skip Use this operator to list matching results from a child node, even if its parent node does not
meet the specified criteria. See the following example for more information.
13
Example: Skip Criteria Operator

If you are looking at the following structure and want to determine all of the ports that
belong to a YY type module:
• Network Element 1
• Module 1, Type XX
• Module 1.1, Type YY
• Port 1
• Port 2
• Module 2, Type YY
• Port 1
• Port 2
If you specify Module.Type=YY in your query criteria, the ports associated with module 1.1
will not be returned since its parent module is type XX. Instead, enter Module.Type=YY or
skip Module!=YY. This tells XSQL to disregard any parent module data that does not meet
the type YY criteria and collect results for any matching child modules. In this example, you
are instructing the query to skip module 1 and collect the relevant data from module 1.1.
14
4. Setting Up Clustering
Table of Contents
Clustering Overview ...................................................................................................... 15
Single Node Clustering .................................................................................................. 15
Multiple Node Clustering ............................................................................................... 16
Clustering Overview
Clustering is a mechanism that enables multiple processes and programs to work together
as one entity. For example, when you search for something on google.com, it may seem
like your search request is processed by only one web server. In reality, your search request
is processed by may web servers connected in a cluster. Similarly, you can have multiple
instances of OpenDaylight working together as one entity.
Advantages of clustering are:
• Scaling: If you have multiple instances of OpenDaylight running, you can potentially do
more work and store more data than you could with only one instance. You can also
break up your data into smaller chunks (shards) and either distribute that data across the
cluster or perform certain operations on certain members of the cluster.
• High Availability: If you have multiple instances of OpenDaylight running and one of
them crashes, you will still have the other instances working and available.
• Data Persistence: You will not lose any data stored in OpenDaylight after a manual
restart or a crash.
The following sections describe how to set up clustering on both individual and multiple
OpenDaylight instances.
Single Node Clustering

To enable clustering on a single instance of OpenDaylight, perform the following steps:
1. Download, unzip, and run the OpenDaylight distribution
2. Install the clustering feature:
feature:install odl-mdsal-clustering
Note
This will enabled the cluster-ready version of the MD-SAL data store, but will
not actually create a cluster of multiple instances. The result is that you will get
data persistence, but not the scaling or high availability advantages.
15
Multiple Node Clustering

The following sections describe how to set up multiple node clusters in OpenDaylight.
Deployment Considerations
To implement clustering, the deployment considerations are as follows:
• To set up a cluster with multiple nodes, we recommend that you use a minimum of three
machines. You can set up a cluster with just two nodes. However, if one of the two
nodes fail, the cluster will not be operational.
Note
This is because clustering in OpenDaylight requires a majority of the nodes to
be up and one node cannot be a majority of two nodes.
• Every device that belongs to a cluster needs to have an identifier. OpenDaylight uses the
node’s role for this purpose. After you define the first node’s role as member-1 in the
akka.conf file, OpenDaylight uses member-1 to identify that node.
• Data shards are used to contain all or a certain segment of a OpenDaylight’s MD-SAL
datastore. For example, one shard can contain all the inventory data while another shard
contains all of the topology data.
If you do not specify a module in the modules.conf file and do not specify a shard
in module-shards.conf, then (by default) all the data is placed in the default
shard (which must also be defined in module-shards.conf file). Each shard has
replicas configured. You can specify the details of where the replicas reside in module-
shards.conf file.
• If you have a three node cluster and would like to be able to tolerate any single node
crashing, a replica of every defined data shard must be running on all three cluster
nodes.
Note
This is because OpenDaylight’s clustering implementation requires a majority
of the defined shard replicas to be running in order to function. If you define
data shard replicas on two of the cluster nodes and one of those nodes goes
down, the corresponding data shards will not function.
• If you have a three node cluster and have defined replicas for a data shard on each
of those nodes, that shard will still function even if only two of the cluster nodes are
running. Note that if one of those remaining two nodes goes down, the shard will not be
operational.
• It is recommended that you have multiple seed nodes configured. After a cluster member
is started, it sends a message to all of its seed nodes. The cluster member then sends a
join command to the first seed node that responds. If none of its seed nodes reply, the
cluster member repeats this process until it successfully establishes a connection or it is
shut down.
16
• After a node is unreachable, it remains down for configurable period of time (10
seconds, by default). Once a node goes down, you need to restart it so that it can rejoin
the cluster. Once a restarted node joins a cluster, it will synchronize with the lead node
automatically.
Setting Up a Multiple Node Cluster

To run OpenDaylight in a three node cluster, perform the following:
First, determine the three machines that will make up the cluster. After that, do the
following on each machine:
1. Copy the OpenDaylight distribution zip file to the machine.
2. Unzip the distribution.
3. Open the following .conf files:
• configuration/initial/akka.conf
• configuration/initial/module-shards.conf
4. In each configuration file, make the following changes:
a. Find every instance of the following lines and replace 127.0.0.1 with the hostname or
IP address of the machine on which this file resides and OpenDaylight will run:
netty.tcp {
hostname = "127.0.0.1"
Note
The value you need to specify will be different for each node in the
cluster.
b. Find the following lines and replace 127.0.0.1 with the hostname or IP address of any
of the machines that will be part of the cluster:
cluster {
seed-nodes = ["akka.tcp://[email protected]:2550"]
c. Find the following section and specify the role for each member node. Here we assign
the first node with the member-1 role, the second node with the member-2 role, and
the third node with the member-3 role:
roles = [
"member-1"
]
Note
This step should use a different role on each node.
d. Open the configuration/initial/module-shards.conf file and update the replicas so that

each shard is replicated to all three nodes:
17
replicas = [
"member-1",
"member-2",
"member-3"
]
For reference, view a sample config files below.
5. Move into the <karaf-distribution-directory>/bin directory.
6. Run the following command:

JAVA_MAX_MEM=4G JAVA_MAX_PERM_MEM=512m ./karaf
7. Enable clustering by running the following command at the Karaf command line:
feature:install odl-mdsal-clustering
OpenDaylight should now be running in a three node cluster. You can use any of the three
member nodes to access the data residing in the datastore.
Sample Config Files

Sample akka.conf file.
odl-cluster-data {
bounded-mailbox {
mailbox-type = "org.opendaylight.controller.cluster.common.actor.
MeteredBoundedMailbox"
mailbox-capacity = 1000
mailbox-push-timeout-time = 100ms
}
metric-capture-enabled = true
akka {
loglevel = "DEBUG"
loggers = ["akka.event.slf4j.Slf4jLogger"]
actor {
provider = "akka.cluster.ClusterActorRefProvider"
serializers {
java = "akka.serialization.JavaSerializer"
proto = "akka.remote.serialization.ProtobufSerializer"
}
serialization-bindings {
"com.google.protobuf.Message" = proto
}
}
remote {
log-remote-lifecycle-events = off
netty.tcp {
hostname = "10.194.189.96"
port = 2550
maximum-frame-size = 419430400
18
send-buffer-size = 52428800
receive-buffer-size = 52428800
}
}
cluster {
auto-down-unreachable-after = 10s
roles = [
"member-1"
]
}
}
}
odl-cluster-rpc {
bounded-mailbox {
mailbox-type = "org.opendaylight.controller.cluster.common.actor.
MeteredBoundedMailbox"
mailbox-capacity = 1000
mailbox-push-timeout-time = 100ms
}
metric-capture-enabled = true
akka {
loglevel = "INFO"
loggers = ["akka.event.slf4j.Slf4jLogger"]
actor {
provider = "akka.cluster.ClusterActorRefProvider"
}
remote {
log-remote-lifecycle-events = off
netty.tcp {
hostname = "10.194.189.96"
port = 2551
}
}
cluster {
auto-down-unreachable-after = 10s
}
}
}
Sample module-shards.conf file.
module-shards = [
{
name = "default"
shards = [
{
name="default"
19
replicas = [
"member-1",
"member-2",
"member-3"
]
}
]
},
{
name = "topology"
shards = [
{
name="topology"
replicas = [
"member-1",
"member-2",
"member-3"
]
}
]
},
{
name = "inventory"
shards = [
{
name="inventory"
replicas = [
"member-1",
"member-2",
"member-3"
]
}
]
},
{
name = "toaster"
shards = [
{
name="toaster"
replicas = [
"member-1",
"member-2",
"member-3"
]
}
]
}
]
20
Part II. Applications and Plugins
This second part of the user guide covers project specific usage instructions.
5. ALTO User Guide

Table of Contents
Overview ....................................................................................................................... 22
ALTO Architecture ......................................................................................................... 22
Configuring ALTO ......................................................................................................... 22
Administering or Managing ALTO ................................................................................. 23
Overview
The ALTO project provides support for Application Layer Traffic Optimization services
defined in RFC 7285.
In the Lithium release, ALTO uses the YANG model described in this draft.
ALTO Architecture
There are three kinds of ALTO packages in OpenDaylight.
1. Core The core packages include:
a. alto-model: Defines the YANG model of ALTO services in MD-SAL
b. service-api-rfc7285: Defines interfaces for ALTO services in AD-SAL
c. alto-northbound: Implements the RFC7285-compatible RESTful API
2. Basic The basic packages include:
a. Basic implementations of ALTO services:
i. alto-provider: Implements the services defined in alto-model
ii. simple-impl: Implements the services defined in service-api-rfc7285
b. Utilities:
i. alto-manager: Provides a karaf command line tool to manipulate network maps

and cost maps.
3. Service The service packages include:
a. alto-hosttracker: Generates a network map, a corresponding cost map and the

endpoint cost service based on l2switch.
Configuring ALTO
There are three packages that require their own configuration files, including alto-
provider, alto-hosttracker and simple-impl. However, the only configurable
option is the type of the data broker in all three configuration files.
22
Administering or Managing ALTO

To enable ALTO, the features must be installed first.
karaf > feature:install odl-alto-provider
karaf > feature:install odl-alto-manager
karaf > feature:install odl-alto-northbound
karaf > feature:install odl-alto-hosttracker
Managing Data with RESTCONF

After installing odl-alto-provider feature in karaf, it is possible to manage network-
maps and cost-maps using RESTCONF. Take a look at all the operations provided by alto-
model at the API service page which can be found at http://localhost:8181/
apidoc/explorer/index.html.
With the example input below you can insert a network map into the data store, either by
filling the form in the API doc page, or by using tools such as curl.
HOST_IP=localhost # IP address of the controller
CREDENTIAL=admin:admin # username and password for authentication
BASE_URL=$HOST_IP:8181/restconf/config
SERVICE_PATH=alto-service:resources/alto-service:network-maps/alto-
service:network-map
RESOURCE_ID=test_odl # Should match the one in the input file
curl -X PUT -H "content-type:application/yang.data+json" \
-d @example-input.json -u $CREDENTIAL \
http://$BASE_URL/$SERVICE_PATH/$RESOURCE_ID
{
"alto-service:network-map": [
{
"alto-service:map": [
{
"alto-service:endpoint-address-group": [
{
"alto-service:address-type": "ipv4",
"alto-service:endpoint-prefix": [
"192.0.2.0/24",
"198.51.100.0/25"
]
}
],
"alto-service:pid": "PID1"
},
{
{
"198.51.100.128/25"
]
}
],
},
{
23
{
"0.0.0.0/0"
]
},
{
"::/0"
]
}
],
}
],
"alto-service:resource-id": "test_odl",
"alto-service:tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
}
]
}
Use the following command to see the results:

service:network-map
RESOURCE_ID=test_odl
curl -X GET -u $CREDENTIAL http://$BASE_URL/$SERVICE_PATH/$RESOURCE_ID
Use DELETE method to remove the data from the data store.
service:network-map
RESOURCE_ID=test_odl
curl -X DELETE -H "content-type:application/yang.data+json" \
-u $CREDENTIAL http://$BASE_URL/$SERVICE_PATH/$RESOURCE_ID
Using alto-manager
The alto-manager package provides a karaf command line tool which wraps up the
functions described in the last section.
karaf > alto-create <type> <resource-file>
karaf > alto-delete <type> <resource-id>
Currently only network-map and cost-map are supported. Also the resource files used in
alto-manager follow the RFC7285-compatible format instead of RESTCONF format.
The following example shows how to use alto-manager to put a network map into the
data store.
karaf > alto-create network-map example-rfc7285-networkmap.json
24
{
"meta" : {
"resource-id": "test_odl",
"tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
},
"network-map" : {
"PID1" : {
"ipv4": [
"192.0.2.0/24",
"192.51.100.0/25"
]
},
"PID2": {
"ipv4": [
"192.51.100.128/25"
]
},
"PID3": {
"ipv4": [
"0.0.0.0/0"
],
"ipv6": [
"::/0"
]
}
}
}
Using alto-hosttracker
As a real instance of ALTO services, alto-hosttracker reads data from l2switch
and generates a network map with resource id hosttracker-network-map and a cost
map with resource id hostracker-cost-map. It can only work with OpenFlow-enabled
networks.
After installing the odl-alto-hosttracker feature, the corresponding network map

and cost map will be inserted into the data store. Follow the steps in how to read data with
RESTCONF to see the contents.
25
6. Authentication and Authorization Services
Table of Contents
Authentication Service ................................................................................................... 26
Administering OpenDaylight Authentication Services ..................................................... 32
OpenDaylight Authorization Service .............................................................................. 33
Authentication Service
Authentication uses the credentials presented by a user to identify the user.
Note
The Authentication user store provided in the Lithium release does not fully
support a clustered node deployment. Specifically, the AAA user store provided
by the H2 database needs to be synchronized using out of band means. The
AAA Token cache is however cluster-capable.
Authentication data model

A user requests authentication within a domain in which the user has defined roles. The
user chooses either of the following ways to request authentication:
• Provides credentials
• Creates a token scoped to a domain. In OpenDaylight, a domain is a grouping of

resources (direct or indirect, physical, logical, or virtual) for the purpose of access control.
Terms and definitions in the model

Token A claim of access to a group of resources on the controller
Domain A group of resources, direct or indirect, physical, logical, or virtual, for the
purpose of access control
User A person who either owns or has access to a resource or group of resources
on the controller
Role Opaque representation of a set of permissions, which is merely a unique

string as admin or guest
Credential Proof of identity such as username and password, OTP, biometrics, or

others
Client A service or application that requires access to the controller
Claim A data set of validated assertions regarding a user, e.g. the role, domain,
name, etc.
26
Authentication methods
There are three ways a user may authenticate in OpenDaylight:
• Basic HTTP Authentication
• Regular, non-token based, authentication with username/password.
• Token-based Authentication
• Direct authentication: A user presents username/password and a domain the user

wishes to access to the controller and obtains a timed (default is 1 hour) scoped access
token. The user then uses this token to access RESTCONF (for example).
• Federated authentication: A user presents credentials to a third-party Identity Provider

(for example, SSSD) trusted by the controller. Upon successful authentication, the
controller returns a refresh (unscoped) token with a list of domains that the user has
access to. The user then presents this refresh token scoped to a domain that the user
has access to obtain a scoped access token. The user then uses this access token to
access RESTCONF (for example).
Example with token authentication using curl:
(username/password = admin/admin, domain = sdn)

# Create a token
curl -ik -d 'grant_type=password&username=admin&password=admin&scope=sdn'
http://localhost:8181/oauth2/token
# Use the token (e.g., ed3e5e05-b5e7-3865-9f63-eb8ed5c87fb9) obtained from

above (default token validity is 1 hour):
curl -ik -H 'Authorization:Bearer ed3e5e05-b5e7-3865-9f63-eb8ed5c87fb9' http:/
/localhost:8181/restconf/config/toaster:toaster
Example with basic HTTP auth using curl:

curl -ik -u 'admin:admin' http://localhost:8181/restconf/config/
toaster:toaster
How the OpenDaylight Authentication Service works

In direct authentication, a service relationship exists between the user and the
OpenDaylight controller. The user and the controller establish trust that allows them to use,
and validate credentials. The user establishes user identity through credentials.
In direct authentication, a user request progresses through the following steps:
1. The user requests the controller administrator for a user account.
Associated with the user account are user credentials, initially created by the
administrator. OpenDaylight supports only username/password credentials. By
default, an administrator account is present in OpenDaylight out-of-the-box with the
default username and password being admin/admin. In addition to creating the user
account, the controller administrator also assigns roles to that account on one or more
27
domain. By default, there are two user roles; admin, and user, and there is only one
domain; sdn.
2. The user presents credentials in a token request to the token service within a domain.
3. The request is then passed on to the controller token endpoint.
4. The controller token endpoint uses the credential authentication entity which returns a
claim for the client.
5. The controller token entity transforms the claim (user, domain, and roles) into a token
which it then provides to the user.
In federated authentication, with the absence of a direct trust relationship between

the user and the service, a third-party Identity Provider (IdP) is used for authentication.
Federated authentication relies on third-party identity providers (IdP) to authenticate the
user.
The user is authenticated by the trusted IdP and a claim is returned to the OpenDaylight
authentication service. The claim is transformed into an OpenDaylight claim and
successively into a token that is passed on to the user.
In a federated authentication set-up, the OpenDaylight controller AAA module provides

SSSD claim support. SSSD can be used to map users in an external LDAP server to users
defined on the OpenDaylight controller.
Configuring Authentication service

Changes to AAA configurations can be made as follows:
For Authentication functionality via one of:
• Webconsole
• CLI (config command in the Karaf shell)
• Editing the etc/org.opendaylight.aaa.*.cfg files directly
For Token Cache Store settings via one of:
• Editing the 08-authn-config.xml configuration file in etc/opendaylight/karaf
• Using RESTCONF
Note
Configurations for AAA are all dynamic and require no restart.
Configuring Authentication
To configure features from the Web console:
1. Install the Web console:

feature:install webconsole
28
2. On the console (http://localhost:8181/system/console) (default Karaf username/

password: karaf/karaf), go to OSGi > Configuration > OpenDaylight AAA
Authentication Configuration.
a. Authorized Clients: List of software clients that are authorized to access

OpenDaylight northbound APIs.
b. Enable Authentication: Enable or disable authentication. (The default is enable.)
Configuring the token store

1. Open in a text editor etc/opendaylight/karaf/08-authn-config.xml
The fields you can configure are as follows:
a. timeToLive: Configure the maximum time, in milliseconds, that tokens are to be

cached. Default is 360000.
2. Save the file.
Note
When token’s are expired, they are lazily removed from the cache.
Configuring AAA federation

1. On the console, click OpenDaylight AAA Federation Configuration.
2. Use the Custom HTTP Headers or Custom HTTP Attributes fields to specify the HTTP
headers or attributes for federated authentication. Normally, additional specification
beyond the default is not required.
Note
As the changes you make to the configurations are automatically committed
when they are saved, no restart of the Authentication service is required.
Configuring federated authentication

Use the following steps to set up federated authentication:
1. Set up an Apache front-end and Apache mods for the OpenDaylight controller.
2. Set up mapping rules (from LDAP users to OpenDaylight users).
3. Use the ClaimAuthFilter in federation to allow claim transformation.
Mapping users to roles and domains

The OpenDaylight authentication service transforms assertions from an external federated
IdP into Authentication Service data:
1. The Apache web server which fronts OpenDaylight AAA sends data to SssdAuthFilter.
2. SssdAuthFilter constructs a JSON document from the data.
29
3. OpenDaylight Authentication Service uses a general purpose transformation mapper to

transform the JSON document.
Operational model
The mapping model works as follows:
1. Assertions from an IdP are stored in an associative array.
2. A sequence of rules is applied, and the first rule which returns success is considered a
match.
3. Upon success, an associative array of mapped values is returned.
• The mapped values are taken from the local variables set during the rule execution.
• The definition of the rules and mapped results are expressed in JSON notation.
Operational Model: Sample code

mapped = null
foreach rule in rules {
result = null
initialize rule.variables with pre-defined values
foreach block in rule.statement_blocks {

for statement in block.statements {
if statement.verb is exit {
result = exit.status
break
}
elif statement.verb is continue {
break
}
}
if result {
break
}
if result == null {
result = success
}
if result == success {
mapped = rule.mapping(rule.variables)
}
return mapped
Mapping Users
A JSON Object acts as a mapping template to produce the final associative array of name/
value pairs. The value in a name/value pair can be a constant or a variable. An example of a
mapping template and rule variables in JSON: Template:
{
"organization": "BigCorp.com",
"user: "$subject",
"roles": "$roles"
}
Local variables:
30
{
"subject": "Sally",
"roles": ["user", "admin"]
}
The final mapped result will be:

{
"organization": "BigCorp.com",
"user: "Sally",
"roles": ["user", "admin"]
}
Example: Splitting a fully qualified username into user and realm components
Some IdPs return a fully qualified username (for example, principal or subject). The fully
qualified username is the concatenation of the user name, separator, and realm name.
The following example shows the mapped result that returns the user and realm as
independent values for the fully qualified username is [email protected] .
The mapping in JSON:

{
"user": "$username",
"realm": "$domain"
}
The assertion in JSON:

{
"Principal": "[email protected]"
}
The rule applied:

[
[
["in", "Principal", "assertion"],
["exit", "rule_fails", "if_not_success"],
["regexp", "$assertion[Principal]", (?P<username>\\w+)@(?P<domain>.
+)"],
["set", "$username", "$regexp_map[username]"],
["set", "$domain", "$regexp_map[domain]"],
["exit, "rule_succeeds", "always"]
]
]
The mapped result in JSON:

{
"user": "bob",
"realm": "example.com"
}
Also, users may be granted roles based on their membership in certain groups.
The Authentication Service allows white lists for users with specific roles. The white lists
ensure that users are unconditionally accepted and authorized with specific roles. Users
who must be unconditionally denied access can be placed in a black list.
31
Administering OpenDaylight Authentication

Services
Actors in the System
OpenDaylight Controller administrator The OpenDaylight Controller administrator has the
following responsibilities:
• Author Authentication policies using the IdmLight Service API
• Provides credentials, usernames and passwords to users who request them
OpenDaylight resource owners Resource owners authenticate (either by means of

federation or directly providing their own credentials to the controller) to obtain an
access token. This access token can then be used to access resources on the controller. An
OpenDaylight resource owner enjoys the following privileges:
• Creates, refreshes, or deletes access tokens
• Gets access tokens from the Secure Token Service
• Passes secure tokens to resource users
OpenDaylight resource users Resource users do not need to authenticate: they can access
resources if they are given an access tokens by the resource owner. The default timeout for
access tokens is 1 hour (This duration is configurable.). An OpenDaylight resource user does
the following:
• Gets access tokens either from a resource owner or the controller administrator
• Uses tokens at access applications from the north-bound APIs
System Components
IdmLight Identity manager Stores local user authentication and authorization data,
provides an Admin REST API for CRUD operations.
Pluggable authenticators Provides domain-specific authentication mechanisms
Authenticator Authenticates users against and establishes claims
Authentication Cache Caches all authentication states and tokens
Authentication Filter Verifies tokens and extracts claims
Authentication Manager Contains the session token and authentication claim

store
IdmLight Identity manager

The Light-weight Identity Manager (IdmLight) Stores local user authentication and
authorization data, and roles and provides an Admin REST API for CRUD operations
32
on the users/roles/domains database. The IdmLight REST API is by default accessed via
the {controller baseURI:8181}/auth/v1/ API end point. Access to the API is restricted to
authenticated clients only, or those possessing a token:
Example: To retrieve the users list.

curl http://admin:admin@localhost:8181/auth/v1/users
The following document contains a detailed list of supported CRUD operations allowed by
the API:
https://wiki.opendaylight.org/images/a/ad/AAA_Idmlight_REST_APIs.xlsx
OpenDaylight Authorization Service

The authorization service currently included in OpenDaylight is of an experimental kind
and only briefly documented here. Authorization follows successful authentication and is
modeled on the Role Based Access Control (RBAC) approach for defining permissions and
decide access levels to API resources on the controller.
33
7. Armoury
Table of Contents
Overview ....................................................................................................................... 34
Armoury Architecture .................................................................................................... 34
Armoury Catalog ........................................................................................................... 34
Armoury Workload Manager ........................................................................................ 35
Armoury Driver Registry ................................................................................................ 35
Tutorials ........................................................................................................................ 35
This section describes how to use the Armoury feature in OpenDaylight and contains
contains configuration, administration, and management sections for the feature.
Overview
Just as compute needs to make requests to the controller to get networking resources in
order to provide its services, so too does the controller sometimes need to make requests of
the workload manager to get compute resources and/or network function (NF) (physical or
virtual) orchestration to provide its services.
Armoury Architecture
There are mainly three components :
• Armoury Catalog A registry or catalog of the necessary information (images, metadata,

templatized day 0 config, how to communicate with the NF, etc) to describe the NF to
the workload manager and/or network function (NF) (physical or virtual) orchestration.
• Armoury Workload Manager The most minimal possible API to allow applications to
request that the workload manager start/stop/etc the NF and some information from
the workload manager/nf orchestrator about the state of the NF.
• Armoury Driver Registry Example Drivers to talk to various workload managers

(OpenStack/Meseophere/Docker/ Kubernetes/etc).
Armoury Catalog
The NF Catalog contains metadata describing a NF.
Configuring Armoury Catalog

TBD: Describe how to configure Armoury Catalog after installation.
Administering Armoury Catalog

TBD: Include related command reference or operations for using Armoury Catalog.
34
Armoury Workload Manager

The Workload Manager defines RPCs to manage instances.
Configuring Armoury Workload Manager

TBD: Describe how to configure Armoury Workload Manager after installation.
Administering Armoury Workload Manager

TBD: Include related command reference or operations for using Armoury Workload
Manager.
Armoury Driver Registry

The Driver Registry Describes the driver that is used to talk with the workload manager
(OpenStack/Meseophere/Docker/Kubernetes/etc).
Configuring Armoury Driver Registry

TBD: Describe how to configure Armoury Driver Registry.
Administering Armoury Driver Registry

TBD: Include related command reference or operations for using Driver Registry.
Tutorials
Below are tutorials for Armoury.
Using Armoury Catalog

TBD: State the purpose of tutorial
Overview
TBD: An overview of the Armoury Catalog tutorial
Prerequisites
TBD: Provide any prerequisite information, assumed knowledge, or environment required
to execute the use case.
Target Environment
TBD: Include any topology requirement for the use case.
35
Instructions
TBD: Step by step procedure for using Armoury Catalog.
Using Armoury Workload Manager

Overview
TBD: An overview of the Armoury Workload Manager tutorial
Prerequisites
Target Environment
Instructions
TBD: Step by step procedure for using Armoury Workload Manager.
Using Armoury Driver Registry

Overview
TBD: An overview of the Armoury Driver Registry tutorial
Prerequisites
Target Environment
Instructions
TBD: Step by step procedure for using Armoury Driver Registry.
36
8. BGP User Guide
Table of Contents
Overview ....................................................................................................................... 37
Configuring BGP ............................................................................................................ 37
Configuration through RESTCONF ................................................................................. 41
Tutorials ........................................................................................................................ 45
Overview
The OpenDaylight Karaf distribution comes pre-configured with baseline BGP
configuration. You can find it in the etc/opendaylight/karaf directory and it consists of two
files:
• 31-bgp.xml (defines the basic parser and RIB support)
• 41-bgp-example.xml (which contains a sample configuration which needs to be

customized to your deployment)
The next sections will describe how to configure BGP manually or using RESTCONF.
Configuring BGP
RIB
<module>
<type>prefix:rib-impl</type>
<name>example-bgp-rib</name>
<rib-id>example-bgp-rib</rib-id>
<local-as>64496</local-as>
<bgp-id>192.0.2.2</bgp-id>
<cluster-id>192.0.2.3</cluster-id>
...
</module>
• rib-id - BGP RIB Identifier, in this configuration file you can specify more BGP RIBs by
copy-pasting the above module. These RIBs must have a unique rib-id and name.
• local-as - Our local AS number (where OpenDaylight is deployed), we use this in best
path selection
• bgp-id - Our local BGP identifier (the IP of the VM where OpenDaylight is deployed), we
use this in best path selection.
• cluster-id - Cluster Identifier, non-mandatory, if not specified, BGP Identifier will be used
MIGHT NOT BE NEEDED: depending on your BGP router, you might need to switch from
linkstate attribute type 99 to 29. Check with your router vendor. Change the field iana-
37
linkstate-attribute-type to true if your router supports type 29. This snippet is located in 31-
bgp.xml file.
<module>
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:linkstate">prefix:bgp-
linkstate</type>
<name>bgp-linkstate</name>
<iana-linkstate-attribute-type>true</iana-linkstate-attribute-type>
</module>
• iana-linkstate-attribute-type - IANA has issued an early allocation for the BGP Linkstate
path attribute (=29). To preserve (TYPE = 99) set value bellow to false; to use IANA
assigned type set the value to true or remove it as it’s true by default.
BGP Peer
The initial configuration is written so that it will be ignored to prevent the client from
starting with default configuration. Therefore the first step is to uncomment the module
containing bgp-peer.
<module>
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">prefix:bgp-
peer</type>
<name>example-bgp-peer</name>
<host>192.0.2.1</host>
<holdtimer>180</holdtimer>
<peer-role>ibgp</peer-role>
<rib>
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">prefix:rib-
instance</type>
</rib>
...
</module>
• name - BGP Peer name, in this configuration file you can specify more BGP Peers by copy-
pasting the above module. These peers must have a unique name.
• host - IP address or hostname of BGP speaker (IP where OpenDaylight should connect to
gather topology)
• holdtimer - unit: seconds
• peer-role - If peer role is not present, default value "ibgp" will be used (allowed values are
also "ebgp" and "rr-client"). This field is case-sensitive.
• rib - BGP RIB identifier
38
Configure Connection Attributes - OPTIONAL

<module>
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:reconnectstrategy">prefix:timed-
reconnect-strategy</type>
<name>example-reconnect-strategy</name>
<min-sleep>1000</min-sleep>
<max-sleep>180000</max-sleep>
<sleep-factor>2.00</sleep-factor>
<connect-time>5000</connect-time>
<executor>
<type xmlns:netty=
"urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-event-
executor</type>
<name>global-event-executor</name>
</executor>
</module>
• min-sleep - Minimum sleep time (miliseconds) in between reconnect tries
• max-sleep - Maximum sleep time (miliseconds) in between reconnect tries
• sleep-factor - Power factor of the sleep time between reconnect tries
• connect-time - How long we should wait (miliseconds) for the TCP connect attempt,
overrides default connection timeout dictated by TCP retransmits
BGP Speaker Configuration

Previous entries addressed the configuration of a BGP connection initiated by
OpenDaylight. OpenDaylight also supports BGP Speaker functionality and accepts incoming
BGP connections.
*The configuration of BGP speaker is located in: 41-bgp-example.xml:
<module>
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">prefix:bgp-peer-
acceptor</type>
<name>bgp-peer-server</name>



...

<peer-registry>
<type xmlns:prefix=
registry</type>
<name>global-bgp-peer-registry</name>
</peer-registry>
</module>
39
Changing speaker configuration - Changing binding address: Uncomment tag binding-

address and change the address to e.g. 127.0.0.1. The default binding address is 0.0.0.0.
- Changing binding port: Uncomment tag binding-port and change the port to e.g. 1790.
The default binding port is 179 as specified in BGP RFC. —
Incomming BGP Connections

BGP speaker drops all BGP connections from unknown BGP peers. The decision is made in
component bgp-peer-registry that is injected into the speaker (The registry is configured in
31-bgp.xml).
To add BGP Peer configuration into the registry, it is necessary to configure regular BGP
peer just like in example in 41-bgp-example.xml. Notice that the BGP peer depends on the
same bgp-peer-registry as bgp-speaker:
<module>
<type xmlns:prefix=
peer</type>
<host>192.0.2.1</host>
...
<peer-registry>
<type xmlns:prefix=
registry</type>
</peer-registry>
...
</module>
The BGP peer registers itself into the registry, which allows incoming BGP connections
handled by the bgp-speaker. (Config attribute peer-registry is optional for now to preserve
backwards compatibility). With this configuration, the connection to 192.0.2.1 is initiated
by OpenDaylight but will also be accepted from 192.0.2.1. In case both connections are
being established, only one of them will be preserved and the other will be dropped.
The connection initiated from device with lower bgp id will be dropped by the registry.
Each BGP peer must be configured in its own module. Note, that the name of the module
needs to be unique, so if you are configuring more peers, when changing the host, change
also the name. There is a way to configure the peer only for incoming connections (The
connection will not be initiated by the OpenDaylight, OpenDaylight will only wait for
incoming connection from the peer. The peer is identified by its IP address). To configure
peer only for incoming connection add attribute initiate-connection to peer’s configuration:
<module>
<type xmlns:prefix=
peer</type>
<host>192.0.2.1</host> // IP address or hostname
of the speaker
<initiate-connection>false</initiate-connection> // Connection will not
be initiated by ODL
...
</module>
40
• initiate-connection - if set to false OpenDaylight will not initiate connection to this peer.
Default value is true for all peers.
BGP Application Peer

A BGP speaker needs to register all peers that can be connected to it (meaning if a BGP
peer is not configured, the connection with OpenDaylight won’t be successful). As a first
step, configure RIB. Then, instead of configuring regular peer, configure this application
peer, with its own application RIB. Change the value in bold bgp-peer-id which is your local
BGP-ID that will be used in BGP Best Path Selection algorithm.
<module>
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-
application-peer</type>
<name>example-bgp-peer-app</name>
<bgp-peer-id>10.25.1.9</bgp-peer-id>
<target-rib>
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:rib-instance</
type>
</target-rib>
<application-rib-id>example-app-rib</application-rib-id>
...
</module>
• bgp-peer-id - Our local BGP identifier (the IP of the VM where OpenDaylight is deployed),
we use this in best path selection
• target-rib - RIB ID of existing RIB where the data should be transferred
• application-rib-id - RIB ID of local application RIB (all the routes that you put to
OpenDaylight will be displayed here)
Configuration through RESTCONF

Another method to configure BGP is dynamically through RESTCONF. Before you start,
make sure, you’ve completed steps 1-5 in Installation Guide. Instead of restarting Karaf,
install another feature, that provides you the access to restconf/config/ URLs.
feature:install odl-netconf-connector-all
To check what modules you have currently configured, check following link: http://
localhost:8181/restconf/config/network-topology:network-topology/topology/topology-
netconf/node/controller-config/yang-ext:mount/config:modules/ This URL is also used to
POST new configuration. If you want to change any other configuration that is listed here,
make sure you include the correct namespaces. RESTCONF will tell you if some namespace
is wrong.
To update an existing configuration use PUT and give the full path to the element you wish
to update.
It is vital that you respect the order of steps described in user guide.
41
RIB
First, configure RIB. This module is already present in the configuration, therefore we
change only the parameters we need. In this case, it’s bgp-rib-id and local-as.
URL: _ http://127.0.0.1:8181/restconf/config/network-topology:network-topology/
topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/
module/odl-bgp-rib-impl-cfg:rib-impl/example-bgp-rib
PUT:
<module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:rib-impl</
type>
<session-reconnect-strategy xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:protocol:framework">x:reconnect-
strategy-factory</type>
<name>example-reconnect-strategy-factory</name>
</session-reconnect-strategy>
<rib-id xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">example-bgp-
rib</rib-id>
<extensions xmlns=
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:spi">x:extensions</
type>
<name>global-rib-extensions</name>
</extensions>
<codec-tree-factory xmlns=
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">x:binding-
codec-tree-factory</type>
<name>runtime-mapping-singleton</name>
</codec-tree-factory>
<tcp-reconnect-strategy xmlns=
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:protocol:framework">x:reconnect-
strategy-factory</type>
<name>example-reconnect-strategy-factory</name>
</tcp-reconnect-strategy>
<data-provider xmlns=
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">x:binding-
async-data-broker</type>
<name>pingpong-binding-data-broker</name>
</data-provider>
<local-as xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">64496</local-as>
<bgp-dispatcher xmlns=
42
<type>bgp-dispatcher</type>
<name>global-bgp-dispatcher</name>
</bgp-dispatcher>
<dom-data-provider xmlns=
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">x:dom-async-data-
broker</type>
<name>pingpong-broker</name>
</dom-data-provider>
<local-table xmlns=
<type>bgp-table-type</type>
<name>ipv4-unicast</name>
</local-table>
<local-table xmlns=
</local-table>
<local-table xmlns=
<name>linkstate</name>
</local-table>
<local-table xmlns=
<name>flowspec</name>
</local-table>
<bgp-rib-id xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">192.0.2.2</bgp-
rib-id>
</module>
Important
MIGHT NOT BE NEEDED depending on your BGP router, you might need a
switch from linkstate attribute type 99 to 29. Check with your router vendor.
Switch the field to true if your router supports type 29.
URL: http://127.0.0.1:8181/restconf/config/network-topology:network-topology/
module/odl-bgp-linkstate-cfg:bgp-linkstate/bgp-linkstate
PUT:
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:linkstate">x:bgp-
linkstate</type>
<name>bgp-linkstate</name>
<iana-linkstate-attribute-type xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:linkstate">true</iana-
linkstate-attribute-type>
</module>
43
BGP Peer
We also need to add new module to configuration (bgp-peer). In this case, the whole
module needs to be configured. Please change values host, holdtimer and peer-role (if
necessary).
POST:
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-peer</
type>
<host xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">192.0.2.1</host>
<holdtimer xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">180</holdtimer>
<peer-role xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">ibgp</peer-role>
<rib xmlns"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
<type xmlns:x=
type>
</rib>
<peer-registry xmlns=
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-peer-
registry</type>
</peer-registry>
<advertized-table xmlns=
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-
type</type>
</advertized-table>
<type xmlns:x=
type</type>
</advertized-table>
<type xmlns:x=
type</type>
</advertized-table>
<type xmlns:x=
type</type>
<name>flowspec</name>
44
</advertized-table>
</module>
This is all necessary information that you need to get ODL connect to your speaker.
BGP Application Peer

Change the value bgp-peer-id which is your local BGP ID that will be used in BGP Best Path
Selection algorithm.
POST:
<type xmlns:x=
application-peer</type>
<name>example-bgp-peer-app</name>
<bgp-peer-id xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">10.25.1.9</bgp-
peer-id> 
<target-rib xmlns=
<type xmlns:x=
type>
</target-rib>
<application-rib-id xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">example-app-
rib</application-rib-id>
<data-broker xmlns=
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">x:dom-async-data-
broker</type>
<name>pingpong-broker</name>
</data-broker>
</module>
Tutorials
Viewing BGP Topology
This section summarizes how data from BGP can be viewed through RESTCONF. Currently it
is the only way to view the data.
Important
From Helium release the port changed from 8080 to 8181.
Network Topology View

Basic URL for network topology is http://localhost:8181/restconf/operational/network-
topology:network-topology/ .
45
If BGP is configured properly, it should display output similar to this one:

<network-topology>
<topology>
<topology-id>pcep-topology</topology-id>
<topology-types>
<topology-pcep/>
</topology-types>
</topology>
<topology>
<server-provided>true</server-provided>
<topology-id>example-ipv4-topology</topology-id>
<topology-types/>
</topology>
<topology>
<server-provided>true</server-provided>
<topology-id>example-linkstate-topology</topology-id>
<topology-types/>
</topology>
</network-topology>
BGP data as were sent from BGP speaker are listed in three topologies (if all three are
configured):
example-linkstate-topology - displays links and nodes advertised through linkstate Update

messages
http://localhost:8181/restconf/operational/network-topology:network-topology/
topology/example-linkstate-topology
example-ipv4-topology - display Ipv4 adresses of nodes in the topology
topology/example-ipv4-topology
example-ipv6-topology - display Ipv6 adresses of nodes in the topology
topology/example-ipv6-topology
Route Information Base (RIB) View

Another view of BGP data is through BGP RIBs, located here:
http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/
There are multiple RIBs configured:
• AdjRibsIn (per Peer) : Adjacency RIBs In, BGP routes as they come from BGP Peer
• EffectiveRib (per Peer) : BGP routes after applying Import policies
• LocRib (per RIB) : Local RIB, BGP routes from all peers
• AdjRibsOut (per Peer) : BGP routes that will be advertizes, after applying Export policies
This is how the output looks like, when address families for IPv4 and Linkstate were
configured:
46
<loc-rib>
<tables>
</attributes>
<safi>x:linkstate-subsequent-address-family</safi>
<afi>x:linkstate-address-family</afi>
</linkstate-routes>
</tables>
<tables>
</attributes>
<safi>x:unicast-subsequent-address-family</safi>
<afi>x:ipv4-address-family</afi>
</ipv4-routes>
</tables>
</loc-rib>
You can see details for each AFI by expanding the RESTCONF link:
IPv4 : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-
rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv4-
routes
Linkstate : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-
rib/loc-rib/tables/bgp-linkstate:linkstate-address-family/bgp-linkstate:linkstate-subsequent-
address-family/linkstate-routes
Populate RIB
If your peer is configured, you can populate the RIB by making following POST call to
RESTCONF:
URL: http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/
bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/
• where example-app-rib is your application RIB id (that you specified in the configuration)
and tables specifies AFI and SAFI of the data that you want to add.
POST:
Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
<ipv4-route>
<prefix>200.20.160.1/32</prefix>
<attributes>
<ipv4-next-hop>
<global>199.20.160.41</global>
</ipv4-next-hop><as-path/>
<multi-exit-disc>
<med>0</med>
</multi-exit-disc>
<local-pref>
<pref>100</pref>
</local-pref>
<originator-id>
<originator>41.41.41.41</originator>
</originator-id>
47
<origin>
<value>igp</value>
</origin>
<cluster-id>
<cluster>40.40.40.40</cluster>
</cluster-id>
</attributes>
</ipv4-route>
</ipv4-routes>
The request results in 204 No content. This is expected.
48
9. CAPWAP User Guide
Table of Contents
Overview ....................................................................................................................... 49
CAPWAP Architecture ................................................................................................... 49
Scope of CAPWAP Project ............................................................................................. 49
Installing CAPWAP ........................................................................................................ 49
Configuring CAPWAP .................................................................................................... 49
Administering or Managing CAPWAP ............................................................................ 50
Tutorials ........................................................................................................................ 50
This document describes how to use the Control And Provisioning of Wireless Access Points
(CAPWAP) feature in OpenDaylight. This document contains configuration, administration,
and management sections for the feature.
Overview
CAPWAP feature fills the gap OpenDaylight Controller has with respect to managing
CAPWAP compliant wireless termination point (WTP) network devices present in enterprise
networks. Intelligent applications (e.g. centralized firmware management, radio planning)
can be developed by tapping into the WTP network device’s operational states via REST
APIs.
CAPWAP Architecture
The CAPWAP feature is implemented as an MD-SAL based provider module, which helps
discover WTP devices and update their states in MD-SAL operational datastore.
Scope of CAPWAP Project

In the Lithium release, CAPWAP project aims to only detect the WTPs and store their basic
attributes in the operational data store, which is accessible via REST and JAVA APIs.
Installing CAPWAP
To install CAPWAP, download OpenDaylight and use the Karaf console to install the
following feature:
odl-capwap-ac-rest
Configuring CAPWAP
As of Lithium, there are no configuration requirements.
49
Administering or Managing CAPWAP

After installing the odl-capwap-ac-rest feature from the Karaf console, users can administer
and manage CAPWAP from the APIDOCS explorer.
Go to http://${ipaddress}:8181/apidoc/explorer/index.html, sign in, and expand the

capwap-impl panel. From there, users can execute various API calls.
Tutorials
Viewing Discovered WTPs
Overview
This tutorial can be used as a walk through to understand the steps for starting the
CAPWAP feature, detecting CAPWAP WTPs, accessing the operational states of WTPs.
Prerequisites
It is assumed that user has access to at least one hardware/software based CAPWAP
compliant WTP. These devices should be configured with OpenDaylight controller IP
address as a CAPWAP Access Controller (AC) address. It is also assumed that WTPs and
OpenDaylight controller share the same ethernet broadcast domain.
Instructions
1. Run the OpenDaylight distribution and install odl-capwap-ac-rest from the Karaf console.
2. Go to http://${ipaddress}:8181/apidoc/explorer/index.html
3. Expand capwap-impl
4. Click /operational/capwap-impl:capwap-ac-root/
5. Click "Try it out"
6. The above step should display list of WTPs discovered using ODL CAPWAP feature.
50
10. DIDM User Guide
Table of Contents
Overview ....................................................................................................................... 51
DIDM Architecture ........................................................................................................ 51
Overview
The Device Identification and Driver Management (DIDM) project addresses the need to
provide device-specific functionality. Device-specific functionality is code that performs a
feature, and the code is knowledgeable of the capability and limitations of the device.
For example, configuring VLANs and adjusting FlowMods are features, and there may
be different implementations for different device types. Device-specific functionality is
implemented as Device Drivers. Device Drivers need to be associated with the devices they
can be used with. To determine this association requires the ability to identify the device
type.
DIDM Architecture
The DIDM project creates the infrastructure to support the following functions:
• Discovery - Determination that a device exists in the controller management domain and
connectivity to the device can be established. For devices that support the OpenFlow
protocol, the existing discovery mechanism in OpenDaylight suffices. Devices that do
not support OpenFlow will be discovered through manual means such as the operator
entering device information via GUI or REST API.
• Identification – Determination of the device type.
• Driver Registration – Registration of Device Drivers as routed RPCs.
• Synchronization – Collection of device information, device configuration, and link

(connection) information.
• Data Models for Common Features – Data models will be defined to perform common
features such as VLAN configuration. For example, applications can configure a VLAN by
writing the VLAN data to the data store as specified by the common data model.
• RPCs for Common Features – Configuring VLANs and adjusting FlowMods are example
of features. RPCs will be defined that specify the APIs for these features. Drivers
implement features for specific devices and support the APIs defined by the RPCs. There
may be different Driver implementations for different device types.
51
11. Group Based Policy User Guide
Table of Contents
Overview ....................................................................................................................... 52
GBP Base Architecture and Value Proposition ................................................................ 54
Using the GBP UX interface ........................................................................................... 70
Using the GBP API ......................................................................................................... 83
Using OpenStack with GBP ............................................................................................ 84
Using the GBP OpenFlow Overlay (OfOverlay) renderer ................................................. 90
Using the GBP eBPF IO Visor Agent renderer ............................................................... 101
Using the GBP FaaS renderer ....................................................................................... 101
Using Service Function Chaining (SFC) with GBP Neutron Mapper and OfOverlay .......... 102
Demo/Development environment ............................................................................... 107
Overview
OpenDaylight Group Based Policy allows users to express network configuration in a
declarative versus imperative way.
This is often described as asking for "what you want", rather than "how to do it".
In order to achieve this Group Based Policy (herein referred to as GBP) is an

implementation of an Intent System.
An Intent System:
• is a process around an intent driven data model
• contains no domain specifics
• is capable of addressing multiple semantic definitions of intent
To this end, GBP Policy views an Intent System visually as:
52
Figure 11.1. Intent System Process and Policy Surfaces
• expressed intent is the entry point into the system.
• operational constraints provide policy for the usage of the system which modulates
how the system is consumed. For instance "All Financial applications must use a specific
encryption standard".
• capabilities and state are provided by renderers. Renderers dynamically provide their
capabilities to the core model, allowing the core model to remain non-domain specific.
• governance provides feedback on the delivery of the expressed intent. i.e. "Did we do
what you asked us?"
In summary GBP is about the Automation of Intent.
By thinking of Intent Systems in this way, it enables:
• automation of intent
By focusing on Model. Process. Automation, a consistent policy resolution process

enables for mapping between the expressed intent and renderers responsible for
providing the capabilities of implementing that intent.
• recursive/intent level-independent behaviour.
Where one person’s concrete is another’s abstract, intent can be fulfilled through a
hierarchical implementation of non-domain specific policy resolution. Domain specifics
53
are provided by the renderers, and exposed via the API, at each policy resolution
instance. For example:
• To DNS: The name "www.foo.com" is abstract, and it’s IPv4 address 10.0.0.10 is
concrete,
• To an IP stack: 10.0.0.10 is abstract and the MAC 08:05:04:03:02:01 is concrete,
• To an Ethernet switch: The MAC 08:05:04:03:02:01 is abstract, the resolution to a port

in it’s CAM table is concrete,
• To an optical network: The port maybe abstract, yet the optical wavelength is
concrete.
Note
This is a very domain specific analogy, tied to something most readers will
understand. It in no way implies the GBP should be implemented in an OSI type
fashion. The premise is that by implementing a full Intent System, the user is
freed from a lot of the constraints of how the expressed intent is realised.
It is important to show the overall philosophy of GBP as it sets the project’s direction.
In the Beryllium release of OpenDaylight, GBP focused on expressed intent, refactoring

of how renderers consume and publish Subject Feature Definitions for multi-renderer
support.
GBP Base Architecture and Value Proposition

Terminology
In order to explain the fundamental value proposition of GBP, an illustrated example is
given. In order to do that some terminology must be defined.
The Access Model is the core of the GBP Intent System policy resolution process.
54
Figure 11.2. GBP Access Model Terminology - Endpoints, EndpointGroups,

Contract
55
Figure 11.3. GBP Access Model Terminology - Subject, Classifier, Action
56
Figure 11.4. GBP Forwarding Model Terminology - L3 Context, L2 Bridge

Context, L2 Flood Context/Domain, Subnet
• Endpoints:
Define concrete uniquely identifiable entities. In Beryllium, examples could be a Docker

container, or a Neutron port
• EndpointGroups:
EndpointGroups are sets of endpoints that share a common set of policies.

EndpointGroups can participate in contracts that determine the kinds of communication
that are allowed. EndpointGroups consume and provide contracts. They also expose both
requirements and capabilities, which are labels that help to determine how contracts
will be applied. An EndpointGroup can specify a parent EndpointGroup from which it
inherits.
• Contracts:
Contracts determine which endpoints can communicate and in what way. Contracts
between pairs of EndpointGroups are selected by the contract selectors defined
by the EndpointGroup. Contracts expose qualities, which are labels that can help
EndpointGroups to select contracts. Once the contract is selected, contracts have clauses
that can match against requirements and capabilities exposed by EndpointGroups, as
well as any conditions that may be set on endpoints, in order to activate subjects that
can allow specific kinds of communication. A contract is allowed to specify a parent
contract from which it inherits.
57
• Subject
Subjects describe some aspect of how two endpoints are allowed to communicate.
Subjects define an ordered list of rules that will match against the traffic and perform
any necessary actions on that traffic. No communication is allowed unless a subject
allows that communication.
• Clause
Clauses are defined as part of a contract. Clauses determine how a contract should
be applied to particular endpoints and EndpointGroups. Clauses can match against
requirements and capabilities exposed by EndpointGroups, as well as any conditions that
may be set on endpoints. Matching clauses define some set of subjects which can be
applied to the communication between the pairs of endpoints.
Architecture and Value Proposition

GBP offers an intent based interface, accessed via the UX, via the REST API or directly from
a domain-specific-language such as Neutron through a mapping interface.
There are two models in GBP:
• the access (or core) model
• the forwarding model
Figure 11.5. GBP Access (or Core) Model
58
The classifier and action portions of the model can be thought of as hooks, with their
definition provided by each renderer about its domain specific capabilities. In GBP
Beryllium, there is one renderer, the OpenFlow Overlay renderer (OfOverlay).
These hooks are filled with definitions of the types of features the renderer can provide the
subject, and are called subject-feature-definitions.
This means an expressed intent can be fulfilled by, and across, multiple renderers
simultaneously, without any specific provisioning from the consumer of GBP.
Since GBP is implemented in OpenDaylight, which is an SDN controller, it also must address
networking. This is done via the forwarding model, which is domain specific to networking,
but could be applied to many different types of networking.
Figure 11.6. GBP Forwarding Model
Each endpoint is provisioned with a network-containment. This can be a:
• subnet
• normal IP stack behaviour, where ARP is performed in subnet, and for out of subnet,
traffic is sent to default gateway.
• a subnet can be a child of any of the below forwarding model contexts, but typically
would be a child of a flood-domain
• L2 flood-domain
• allows flooding behaviour.
59
• is a n:1 child of a bridge-domain
• can have multiple children
• L2 bridge-domain
• is a layer2 namespace
• is the realm where traffic can be sent at layer 2
• is a n:1 child of a L3 context
• L3 context
• is a layer3 namespace
• is the realm where traffic is passed at layer 3
• is a n:1 child of a tenant
A simple example of how the access and forwarding models work is as follows:
Figure 11.7. GBP Endpoints, EndpointGroups and Contracts
In this example, the EPG:webservers is providing the web and ssh contracts. The EPG:client
is consuming those contracts. EPG:client is providing the any contract, which is consumed
by EPG:webservers.
The direction keyword is always from the perspective of the provider of the contract. In
this case contract web, being provided by EPG:webservers, with the classifier to match TCP
destination port 80, means:
• packets with a TCP destination port of 80
• sent to (in) endpoints in the EPG:webservers
• will be allowed.
60
Figure 11.8. GBP Endpoints and the Forwarding Model
When the forwarding model is considered in the figure above, it can be seen that even
though all endpoints are communicating using a common set of contracts, their forwarding
is contained by the forwarding model contexts or namespaces. In the example shown,
the endpoints associated with a network-containment that has an ultimate parent of
L3Context:Sales can only communicate with other endpoints within this L3Context. In this
way L3VPN services can be implemented without any impact to the Intent of the contract.
High-level implementation Architecture

The overall architecture, including Neutron domain specific mapping, and the OpenFlow
Overlay renderer looks as so:
61
Figure 11.9. GBP High Level Beryllium Architecture
The major benefit of this architecture is that the mapping of the domain-specific-language
is completely separate and independent of the underlying renderer implementation.
For instance, using the Neutron Mapper, which maps the Neutron API to the GBP core
model, any contract automatically generated from this mapping can be augmented via
the UX to use Service Function Chaining, a capability not currently available in OpenStack
Neutron.
When another renderer is added, for instance, NetConf, the same policy can now be
leveraged across NetConf devices simultaneously:
62
Figure 11.10. GBP High Level Beryllium Architecture - adding a renderer
As other domain-specific mappings occur, they too can leverage the same renderers, as the
renderers only need to implement the GBP access and forwarding models, and the domain-
specific mapping need only manage mapping to the access and forwarding models. For
instance:
Figure 11.11. GBP High Level Beryllium Architecture - adding a renderer
63
In summary, the GBP architecture:
• separates concerns: the Expressed Intent is kept completely separated from the
underlying renderers.
• is cohesive: each part does it’s part and it’s part only
• is scalable: code can be optimised around model mapping/implementation, and

functionality re-used
Policy Resolution
Contract Selection
The first step in policy resolution is to select the contracts that are in scope.
EndpointGroups participate in contracts either as a provider or as a consumer of a contract.

Each EndpointGroup can participate in many contracts at the same time, but for each
contract it can be in only one role at a time. In addition, there are two ways for an
EndpointGroup to select a contract: either with either a:
• named selector
Named selectors simply select a specific contract by its contract ID.
• target selector.
Target selectors allow for additional flexibility by matching against qualities of the
contract’s target.
Thus, there are a total of 4 kinds of contract selector:
• provider named selector
Select a contract by contract ID, and participate as a provider.
• provider target selector
Match against a contract’s target with a quality matcher, and participate as a provider.
• consumer named selector
Select a contract by contract ID, and participate as a consumer.
• consumer target selector
Match against a contract’s target with a quality matcher, and participate as a consumer.
To determine which contracts are in scope, contracts are found where either the source
EndpointGroup selects a contract as either a provider or consumer, while the destination
EndpointGroup matches against the same contract in the corresponding role. So if
endpoint x in EndpointGroup X is communicating with endpoint y in EndpointGroup Y, a
contract C is in scope if either X selects C as a provider and Y selects C as a consumer, or vice
versa.
64
The details of how quality matchers work are described further in Matchers. Quality
matchers provide a flexible mechanism for contract selection based on labels.
The end result of the contract selection phase can be thought of as a set of tuples
representing selected contract scopes. The fields of the tuple are:
• Contract ID
• The provider EndpointGroup ID
• The name of the selector in the provider EndpointGroup that was used to select the
contract, called the matching provider selector.
• The consumer EndpointGroup ID
• The name of the selector in the consumer EndpointGroup that was used to select the
contract, called the matching consumer selector.
The result is then stored in the datastore under Resolved Policy.
Subject Selection
The second phase in policy resolution is to determine which subjects are in scope. The
subjects define what kinds of communication are allowed between endpoints in the
EndpointGroups. For each of the selected contract scopes from the contract selection
phase, the subject selection procedure is applied.
Labels called, capabilities, requirements and conditions are matched against to bring a
Subject into scope. EndpointGroups have capabilities and requirements, while endpoints
have conditions.
Requirements and Capabilities

When acting as a provider, EndpointGroups expose capabilities, which are labels
representing specific pieces of functionality that can be exposed to other EndpointGroups
that may meet functional requirements of those EndpointGroups.
When acting as a consumer, EndpointGroups expose requirements, which are labels that
represent that the EndpointGroup requires some specific piece of functionality.
As an example, we might create a capability called "user-database" which indicates that an

EndpointGroup contains endpoints that implement a database of users.
We might create a requirement also called "user-database" to indicate an EndpointGroup

contains endpoints that will need to communicate with the endpoints that expose this
service.
Note that in this example the requirement and capability have the same name, but the user
need not follow this convention.
The matching provider selector (that was used by the provider EndpointGroup to select the
contract) is examined to determine the capabilities exposed by the provider EndpointGroup
for this contract scope.
65
The provider selector will have a list of capabilities either directly included in the provider
selector or inherited from a parent selector or parent EndpointGroup. (See Inheritance).
Similarly, the matching consumer selector will expose a set of requirements.
Conditions
Endpoints can have conditions, which are labels representing some relevant piece of
operational state related to the endpoint.
An example of a condition might be "malware-detected," or "authentication-succeeded."

Conditions are used to affect how that particular endpoint can communicate.
To continue with our example, the "malware-detected" condition might cause an

endpoint’s connectivity to be cut off, while "authentication-succeeded" might open up
communication with services that require an endpoint to be first authenticated and then
forward its authentication credentials.
Clauses
Clauses perform the actual selection of subjects. A clause has lists of matchers in two
categories. In order for a clause to become active, all lists of matchers must match. A
matching clause will select all the subjects referenced by the clause. Note that an empty list
of matchers counts as a match.
The first category is the consumer matchers, which match against the consumer
EndpointGroup and endpoints. The consumer matchers are:
• Group Idenfication Constraint: Requirement matchers
Matches against requirements in the matching consumer selector.
• Group Identification Constraint: GroupName
Matches against the group name
• Consumer condition matchers
Matches against conditions on endpoints in the consumer EndpointGroup
• Consumer Endpoint Identification Constraint
Label based criteria for matching against endpoints. In Beryllium this can be used to label
endpoints based on IpPrefix.
The second category is the provider matchers, which match against the provider
EndpointGroup and endpoints. The provider matchers are:
• Group Idenfication Constraint: Capability matchers
Matches against capabilities in the matching provider selector.
• Group Identification Constraint: GroupName
66
Matches against the group name
• Consumer condition matchers
Matches against conditions on endpoints in the provider EndpointGroup
• Consumer Endpoint Identification Constraint
Label based criteria for matching against endpoints. In Beryllium this can be used to label
endpoints based on IpPrefix.
Clauses have a list of subjects that apply when all the matchers in the clause match. The
output of the subject selection phase logically is a set of subjects that are in scope for any
particular pair of endpoints.
Rule Application
Now subjects have been selected that apply to the traffic between a particular set of
endpoints, policy can be applied to allow endpoints to communicate. The applicable
subjects from the previous step will each contain a set of rules.
Rules consist of a set of classifiers and a set of actions. Classifiers match against traffic
between two endpoints. An example of a classifier would be something that matches
against all TCP traffic on port 80, or one that matches against HTTP traffic containing a
particular cookie. Actions are specific actions that need to be taken on the traffic before it
reaches its destination. Actions could include tagging or encapsulating the traffic in some
way, redirecting the traffic, or applying a service function chain.
Rules, subjects, and actions have an order parameter, where a lower order value means
that a particular item will be applied first. All rules from a particular subject will be applied
before the rules of any other subject, and all actions from a particular rule will be applied
before the actions from another rule. If more than item has the same order parameter, ties
are broken with a lexicographic ordering of their names, with earlier names having logically
lower order.
Matchers
Matchers specify a set of labels (which include requirements, capabilities, conditions, and
qualities) to match against. There are several kinds of matchers that operate similarly:
• Quality matchers
used in target selectors during the contract selection phase. Quality matchers provide a
more advanced and flexible way to select contracts compared to a named selector.
• Requirement and capability matchers
used in clauses during the subject selection phase to match against requirements and
capabilities on EndpointGroups
• Condition matchers
used in clauses during the subject selection phase to match against conditions on
endpoints
67
A matcher is, at its heart, fairly simple. It will contain a list of label names, along with a
match type. The match type can be either:
• "all"
which means the matcher matches when all of its labels match
• "any"
which means the matcher matches when any of its labels match,
• "none"
which means the matcher matches when none of its labels match.
Note a match all matcher can be made by matching against an empty set of labels with a
match type of "all."
Additionally each label to match can optionally include a relevant name field. For quality
matchers, this is a target name. For capability and requirement matchers, this is a selector
name. If the name field is specified, then the matcher will only match against targets or
selectors with that name, rather than any targets or selectors.
Inheritance
Some objects in the system include references to parents, from which they will inherit
definitions. The graph of parent references must be loop free. When resolving names, the
resolution system must detect loops and raise an exception. Objects that are part of these
loops may be considered as though they are not defined at all. Generally, inheritance works
by simply importing the objects in the parent into the child object. When there are objects
with the same name in the child object, then the child object will override the parent object
according to rules which are specific to the type of object. We’ll next explore the detailed
rules for inheritance for each type of object
EndpointGroups
EndpointGroups will inherit all their selectors from their parent EndpointGroups. Selectors
with the same names as selectors in the parent EndpointGroups will inherit their behavior
as defined below.
Selectors
Selectors include provider named selectors, provider target selectors, consumer named
selectors, and consumer target selectors. Selectors cannot themselves have parent selectors,
but when selectors have the same name as a selector of the same type in the parent
EndpointGroup, then they will inherit from and override the behavior of the selector in the
parent EndpointGroup.
Named Selectors
Named selectors will add to the set of contract IDs that are selected by the parent named
selector.
Target Selectors
68
A target selector in the child EndpointGroup with the same name as a target selector in the
parent EndpointGroup will inherit quality matchers from the parent. If a quality matcher
in the child has the same name as a quality matcher in the parent, then it will inherit as
described below under Matchers.
Contracts
Contracts will inherit all their targets, clauses and subjects from their parent contracts.
When any of these objects have the same name as in the parent contract, then the
behavior will be as defined below.
Targets
Targets cannot themselves have a parent target, but it may inherit from targets with the
same name as the target in a parent contract. Qualities in the target will be inherited from
the parent. If a quality with the same name is defined in the child, then this does not have
any semantic effect except if the quality has its inclusion-rule parameter set to "exclude." In
this case, then the label should be ignored for the purpose of matching against this target.
Subjects
Subjects cannot themselves have a parent subject, but it may inherit from a subject with
the same name as the subject in a parent contract. The order parameter in the child
subject, if present, will override the order parameter in the parent subject. The rules in the
parent subject will be added to the rules in the child subject. However, the rules will not
override rules of the same name. Instead, all rules in the parent subject will be considered
to run with a higher order than all rules in the child; that is all rules in the child will run
before any rules in the parent. This has the effect of overriding any rules in the parent
without the potentially-problematic semantics of merging the ordering.
Clauses
Clauses cannot themselves have a parent clause, but it may inherit from a clause with the
same name as the clause in a parent contract. The list of subject references in the parent
clause will be added to the list of subject references in the child clause. This is just a union
operation. A subject reference that refers to a subject name in the parent contract might
have that name overridden in the child contract. Each of the matchers in the clause are
also inherited by the child clause. Matchers in the child of the same name and type as a
matcher from the parent will inherit from and override the parent matcher. See below
under Matchers for more information.
Matchers
Matchers include quality matchers, condition matchers, requirement matchers, and

capability matchers. Matchers cannot themselves have parent matchers, but when there
is a matcher of the same name and type in the parent object, then the matcher in the
child object will inherit and override the behavior of the matcher in the parent object.
The match type, if specified in the child, overrides the value specified in the parent. Labels
are also inherited from the parent object. If there is a label with the same name in the
child object, this does not have any semantic effect except if the label has its inclusion-rule
parameter set to "exclude." In this case, then the label should be ignored for the purpose of
matching. Otherwise, the label with the same name will completely override the label from
the parent.
69
Using the GBP UX interface

Overview
These following components make up this application and are described in more detail in
following sections:
• Basic view
• Governance view
• Policy Expression view
• Wizard view
The GBP UX is access via:

http://<odl controller>:8181/index.html
Basic view
Basic view contains 5 navigation buttons which switch user to the desired section of
application:
• Governance – switch to the Governance view (middle of graphic has the same function)
• Renderer configuration – switch to the Policy expression view with Renderers section
expanded
• Policy expression – switch to the Policy expression view with Policy section expanded
• Operational constraints – placeholder for development in next release
Figure 11.12. Basic view
70
Governance view
Governance view consists from three columns.
Figure 11.13. Governance view
Governance view – Basic view – Left column
In the left column is Health section with Exception and Conflict buttons with no
functionality yet. This is a placeholder for development in further releases.
Governance view – Basic view – Middle column
In the top half of this section is select box with list of tenants for select. Once the tenant
is selected, all sub sections in application operate and display data with actual selected
tenant.
Below the select box are buttons which display Expressed or Delivered policy of Governance
section. In the bottom half of this section is select box with list of renderers for select. There
is currently only OfOverlay renderer available.
Below the select box is Renderer configuration button, which switch the app into the
Policy expression view with Renderers section expanded for performing CRUD operations.
Renderer state button display Renderer state view.
Governance view – Basic view – Right column
In the bottom part of the right section of Governance view is Home button which switch
the app to the Basic view.
In the top part is situated navigation menu with four main sections.
Policy expression button expand/collapse sub menu with three main parts of Policy
expression. By clicking on sub menu buttons, user will be switched into the Policy
expressions view with appropriate section expanded for performing CRUD operations.
71
Renderer configuration button switches user into the Policy expressions view.
Governance button expand/collapse sub menu with four main parts of Governance section.
Sub menu buttons of Governance section display appropriate section of Governance view.
Operational constraints have no functionality yet, and is a placeholder for development in

further releases.
Below the menu is place for view info section which displays info about actual selected
element from the topology (explained below).
Governance view – Expressed policy
In this view are displayed contracts with their consumed and provided EndpointGroups of
actual selected tenant, which can be changed in select box in the upper left corner.
By single-clicking on any contract or EPG, the data of actual selected element will be shown
in the right column below the menu. A Manage button launches a display wizard window
for managing configuration of items such as Service Function Chaining.
Figure 11.14. Expressed policy
Governance view – Delivered policy In this view are displayed subjects with their
consumed and provided EndpointGroups of actual selected tenant, which can be changed
in select box in the upper left corner.
By single-clicking on any subject or EPG, the data of actual selected element will be shown
in the right column below the menu.
By double-click on subject the subject detail view will be displayed with subject’s rules of
actual selected subject, which can be changed in select box in the upper left corner.
By single-clicking on rule or subject, the data of actual selected element will be shown in the
right column below the menu.
72
By double-clicking on EPG in Delivered policy view, the EPG detail view will be displayed
with EPG’s endpoints of actual selected EPG, which can be changed in select box in the
upper left corner.
By single-clicking on EPG or endpoint the data of actual selected element will be shown in
the right column below the menu.
Figure 11.15. Delivered policy
Figure 11.16. Subject detail
73
Figure 11.17. EPG detail
Governance view – Renderer state
In this part are displayed Subject feature definition data with two main parts: Action
definition and Classifier definition.
By clicking on the down/right arrow in the circle is possible to expand/hide data of

appropriate container or list. Next to the list node are displayed names of list’s elements
where one is always selected and element’s data are shown (blue line under the name).
By clicking on names of children nodes is possible to select desired node and node’s data
will be displayed.
74
Figure 11.18. Renderer state
Policy expression view

In the left part of this view is placed topology of actual selected elements with the buttons
for switching between types of topology at the bottom.
Right column of this view contains four parts. At the top of this column are displayed
breadcrumbs with actual position in the application.
Below the breadcrumbs is select box with list of tenants for select. In the middle part is
situated navigation menu, which allows switch to the desired section for performing CRUD
operations.
At the bottom is quick navigation menu with Access Model Wizard button which display
Wizard view, Home button which switch application to the Basic view and occasionally Back
button, which switch application to the upper section.
Policy expression - Navigation menu
To open Policy expression, select Policy expression from the GBP Home screen.
In the top of navigation box you can select the tenant from the tenants list to activate
features addicted to selected tenant.
In the right menu, by default, the Policy menu section is expanded. Subitems of this
section are modules for CRUD (creating, reading, updating and deleting) of tenants,
EndpointGroups, contracts, L2/L3 objects.
• Section Renderers contains CRUD forms for Classifiers and Actions.
• Section Endpoints contains CRUD forms for Endpoint and L3 prefix endpoint.
75
Figure 11.19. Navigation menu
76
Figure 11.20. CRUD operations
Policy expression - Types of topology
There are three different types of topology:
• Configured topology - EndpointGroups and contracts between them from CONFIG

datastore
• Operational topology - displays same information but is based on operational data.
• L2/L3 - displays relationships between L3Contexts, L2 Bridge domains, L2 Flood domains

and Subnets.
77
Figure 11.21. L2/L3 Topology
Figure 11.22. Config Topology
Policy expression - CRUD operations
78
In this part are described basic flows for viewing, adding, editing and deleting system
elements like tenants, EndpointGroups etc.
Tenants
To edit tenant objects click the Tenants button in the right menu. You can see the CRUD
form containing tenants list and control buttons.
To add new tenant, click the Add button This will display the form for adding a new
tenant. After filling tenant attributes Name and Description click Save button. Saving of
any object can be performed only if all the object attributes are filled correctly. If some
attribute doesn’t have correct value, exclamation mark with mouse-over tooltip will be
displayed next to the label for the attribute. After saving of tenant the form will be closed
and the tenants list will be set to default value.
To view an existing tenant, select the tenant from the select box Tenants list. The view form
is read-only and can be closed by clicking cross mark in the top right of the form.
To edit selected tenant, click the Edit button, which will display the edit form for selected
tenant. After editing the Name and Description of selected tenant click the Save button to
save selected tenant. After saving of tenant the edit form will be closed and the tenants list
will be set to default value.
To delete tenant select the tenant from the Tenants list and click Delete button.
To return to the Policy expression click Back button on the bottom of window.
EndpointGroups
For managing EndpointGroups (EPG) the tenant from the top Tenants list must be selected.
To add new EPG click Add button and after filling required attributes click Save button.
After adding the EPG you can edit it and assign Consumer named selector or Provider
named selector to it.
To edit EPG click the Edit button after selecting the EPG from Group list.
To add new Consumer named selector (CNS) click the Add button next to the Consumer
named selectors list. While CNS editing you can set one or more contracts for current CNS
pressing the Plus button and selecting the contract from the Contracts list. To remove the
contract, click on the cross mark next to the contract. Added CNS can be viewed, edited
or deleted by selecting from the Consumer named selectors list and clicking the Edit and
Delete buttons like with the EPG or tenants.
To add new Provider named selector (PNS) click the Add button next to the Provider
named selectors list. While PNS editing you can set one or more contracts for current PNS
pressing the Plus button and selecting the contract from the Contracts list. To remove the
contract, click on the cross mark next to the contract. Added PNS can be viewed, edited or
deleted by selecting from the Provider named selectors list and clicking the Edit and Delete
buttons like with the EPG or tenants.
To delete EPG, CNS or PNS select it in selectbox and click the Delete button next to the
selectbox.
79
Contracts
For managing contracts the tenant from the top Tenants list must be selected.
To add new Contract click Add button and after filling required fields click Save button.
After adding the Contract user can edit it by selecting in the Contracts list and clicking Edit
button.
To add new Clause click Add button next to the Clause list while editing the contract. While
editing the Clause after selecting clause from the Clause list user can assign clause subjects
by clicking the Plus button next to the Clause subjects label. Adding and editing action must
be submitted by pressing Save button. To manage Subjects you can use CRUD form like
with the Clause list.
L2/L3
For managing L2/L3 the tenant from the top Tenants list must be selected.
To add L3 Context click the Add button next to the L3 Context list ,which will display the
form for adding a new L3 Context. After filling L3 Context attributes click Save button.
After saving of L3 Context, form will be closed and the L3 Context list will be set to default
value.
To view an existing L3 Context, select the L3 Context from the select box L3 Context list.
The view form is read-only and can be closed by clicking cross mark in the top right of the
form.
If user wants to edit selected L3 Context, click the Edit button, which will display the
edit form for selected L3 Context. After editing click the Save button to save selected L3
Context. After saving of L3 Context, the edit form will be closed and the L3 Context list will
be set to default value.
To delete L3 Context, select it from the L3 Context list and click Delete button.
To add L2 Bridge Domain, click the Add button next to the L2 Bridge Domain list. This
will display the form for adding a new L2 Bridge Domain. After filling L2 Bridge Domain
attributes click Save button. After saving of L2 Bridge Domain, form will be closed and the
L2 Bridge Domain list will be set to default value.
To view an existing L2 Bridge Domain, select the L2 Bridge Domain from the select box L2
Bridge Domain list. The view form is read-only and can be closed by clicking cross mark in
the top right of the form.
If user wants to edit selected L2 Bridge Domain, click the Edit button, which will display
the edit form for selected L2 Bridge Domain. After editing click the Save button to save
selected L2 Bridge Domain. After saving of L2 Bridge Domain the edit form will be closed
and the L2 Bridge Domain list will be set to default value.
To delete L2 Bridge Domain select it from the L2 Bridge Domain list and click Delete button.
To add L3 Flood Domain, click the Add button next to the L3 Flood Domain list. This
will display the form for adding a new L3 Flood Domain. After filling L3 Flood Domain
80
attributes click Save button. After saving of L3 Flood Domain, form will be closed and the
L3 Flood Domain list will be set to default value.
To view an existing L3 Flood Domain, select the L3 Flood Domain from the select box L3
Flood Domain list. The view form is read-only and can be closed by clicking cross mark in the
top right of the form.
If user wants to edit selected L3 Flood Domain, click the Edit button, which will display the
edit form for selected L3 Flood Domain. After editing click the Save button to save selected
L3 Flood Domain. After saving of L3 Flood Domain the edit form will be closed and the L3
Flood Domain list will be set to default value.
To delete L3 Flood Domain select it from the L3 Flood Domain list and click Delete button.
To add Subnet click the Add button next to the Subnet list. This will display the form for
adding a new Subnet. After filling Subnet attributes click Save button. After saving of
Subnet, form will be closed and the Subnet list will be set to default value.
To view an existing Subnet, select the Subnet from the select box Subnet list. The view form
If user wants to edit selected Subnet, click the Edit button, which will display the edit form
for selected Subnet. After editing click the Save button to save selected Subnet. After
saving of Subnet the edit form will be closed and the Subnet list will be set to default value.
To delete Subnet select it from the Subnet list and click Delete button.
Classifiers
To add Classifier, click the Add button next to the Classifier list. This will display the form for
adding a new Classifier. After filling Classifier attributes click Save button. After saving of
Classifier, form will be closed and the Classifier list will be set to default value.
To view an existing Classifier, select the Classifier from the select box Classifier list. The view
form is read-only and can be closed by clicking cross mark in the top right of the form.
If you want to edit selected Classifier, click the Edit button, which will display the edit form
for selected Classifier. After editing click the Save button to save selected Classifier. After
saving of Classifier the edit form will be closed and the Classifier list will be set to default
value.
To delete Classifier select it from the Classifier list and click Delete button.
Actions
To add Action, click the Add button next to the Action list. This will display the form for
adding a new Action. After filling Action attributes click Save button. After saving of
Action, form will be closed and the Action list will be set to default value.
To view an existing Action, select the Action from the select box Action list. The view form
If user wants to edit selected Action, click the Edit button, which will display the edit form
for selected Action. After editing click the Save button to save selected Action. After saving
of Action the edit form will be closed and the Action list will be set to default value.
81
To delete Action select it from the Action list and click Delete button.
Endpoint
To add Endpoint, click the Add button next to the Endpoint list. This will display the form
for adding a new Endpoint. To add EndpointGroup assignment click the Plus button
next to the label EndpointGroups. To add Condition click Plus button next to the label
Condition. To add L3 Address click the Plus button next to the L3 Addresses label. After
filling Endpoint attributes click Save button. After saving of Endpoint, form will be closed
and the Endpoint list will be set to default value.
To view an existing Endpoint just, the Endpoint from the select box Endpoint list. The view
form is read-only and can be closed by clicking cross mark in the top right of the form.
If you want to edit selected Endpoint, click the Edit button, which will display the edit form
for selected Endpoint. After editing click the Save button to save selected Endpoint. After
saving of Endpoint the edit form will be closed and the Endpoint list will be set to default
value.
To delete Endpoint select it from the Endpoint list and click Delete button.
L3 prefix endpoint
To add L3 prefix endpoint, click the Add button next to the L3 prefix endpoint list. This
will display the form for adding a new Endpoint. To add EndpointGroup assignment, click
the Plus button next to the label EndpointGroups. To add Condition, click Plus button next
to the label Condition. To add L2 gateway click the Plus button next to the L2 gateways
label. To add L3 gateway, click the Plus button next to the L3 gateways label. After filling
L3 prefix endpoint attributes click Save button. After saving of L3 prefix endpoint, form will
be closed and the Endpoint list will be set to default value.
To view an existing L3 prefix endpoint, select the Endpoint from the select box L3 prefix
endpoint list. The view form is read-only and can be closed by clicking cross mark in the top
right of the form.
If you want to edit selected L3 prefix endpoint, click the Edit button, which will display
the edit form for selected L3 prefix endpoint. After editing click the Save button to save
selected L3 prefix endpoint. After saving of Endpoint the edit form will be closed and the
Endpoint list will be set to default value.
To delete Endpoint select it from the L3 prefix endpoint list and click Delete button.
Wizard
Wizard provides quick method to send basic data to controller necessary for basic usage of
GBP application. It is useful in the case that there aren’t any data in controller. In the first
tab is form for create tenant. The second tab is for CRUD operations with contracts and
their sub elements such as subjects, rules, clauses, action refs and classifier refs. The last tab
is for CRUD operations with EndpointGroups and their CNS and PNS. Created structure of
data is possible to send by clicking on Submit button.
82
Figure 11.23. Wizard
Using the GBP API

Please see:
• Using the GBP OpenFlow Overlay (OfOverlay) renderer
• Policy Resolution
• Forwarding Model
• the GBP demo and development environments for tips
It is recommended to use either:
• Neutron mapper
• the UX
If the REST API must be used, and the above resources are not sufficient:
• feature:install odl-dlux-yangui
• browse to: http://<odl-controller>:8181/index.html and select YangUI from the left

menu.
83
to explore the various GBP REST options
Using OpenStack with GBP

Overview
This section is for Application Developers and Network Administrators who are looking to
integrate Group Based Policy with OpenStack.
To enable the GBP Neutron Mapper feature, at the Karaf console:

feature:install odl-groupbasedpolicy-neutronmapper
Neutron Mapper has the following dependencies that are automatically loaded:
odl-neutron-service
Neutron Northbound implementing REST API used by OpenStack

odl-groupbasedpolicy-base
Base GBP feature set, such as policy resolution, data model etc.
odl-groupbasedpolicy-ofoverlay
REST calls from OpenStack Neutron are by the Neutron NorthBound project.
GBP provides the implementation of the Neutron V2.0 API.
Features
List of supported Neutron entities:
• Port
• Network
• Standard Internal
• External provider L2/L3 network
• Subnet
• Security-groups
• Routers
• Distributed functionality with local routing per compute
• External gateway access per compute node (dedicated port required)
• Multiple routers per tenant
• FloatingIP NAT
• IPv4/IPv6 support
The mapping of Neutron entities to GBP entities is as follows:
84
Neutron Port
Figure 11.24. Neutron Port
The Neutron port is mapped to an endpoint.
The current implementation supports one IP address per Neutron port.
An endpoint and L3-endpoint belong to multiple EndpointGroups if the Neutron port is in

multiple Neutron Security Groups.
The key for endpoint is L2-bridge-domain obtained as the parent of L2-flood-domain

representing Neutron network. The MAC address is from the Neutron port. An L3-endpoint
is created based on L3-context (the parent of the L2-bridge-domain) and IP address of
Neutron Port.
Neutron Network
Figure 11.25. Neutron Network
A Neutron network has the following characteristics:
• defines a broadcast domain
85
• defines a L2 transmission domain
• defines a L2 name space.
To represent this, a Neutron Network is mapped to multiple GBP entities. The first mapping
is to an L2 flood-domain to reflect that the Neutron network is one flooding or broadcast
domain. An L2-bridge-domain is then associated as the parent of L2 flood-domain. This
reflects both the L2 transmission domain as well as the L2 addressing namespace.
The third mapping is to L3-context, which represents the distinct L3 address space. The L3-
context is the parent of L2-bridge-domain.
Neutron Subnet
Figure 11.26. Neutron Subnet
Neutron subnet is associated with a Neutron network. The Neutron subnet is mapped to a
GBP subnet where the parent of the subnet is L2-flood-domain representing the Neutron
network.
Neutron Security Group
Figure 11.27. Neutron Security Group and Rules
86
GBP entity representing Neutron security-group is EndpointGroup.
Infrastructure EndpointGroups
Neutron-mapper automatically creates EndpointGroups to manage key infrastructure items

such as:
• DHCP EndpointGroup - contains endpoints representing Neutron DHCP ports
• Router EndpointGroup - contains endpoints representing Neutron router interfaces
• External EndpointGroup - holds L3-endpoints representing Neutron router gateway

ports, also associated with FloatingIP ports.
Neutron Security Group Rules
This is the most involved amongst all the mappings because Neutron security-group-
rules are mapped to contracts with clauses, subjects, rules, action-refs, classifier-refs, etc.
Contracts are used between EndpointGroups representing Neutron Security Groups. For
simplification it is important to note that Neutron security-group-rules are similar to a GBP
rule containing:
• classifier with direction
• action of allow.
Neutron Routers
Figure 11.28. Neutron Router
Neutron router is represented as a L3-context. This treats a router as a Layer3 namespace,

and hence every network attached to it a part of that Layer3 namespace.
This allows for multiple routers per tenant with complete isolation.
The mapping of the router to an endpoint represents the router’s interface or gateway
port.
87
The mapping to an EndpointGroup represents the internal infrastructure EndpointGroups

created by the GBP Neutron Mapper
When a Neutron router interface is attached to a network/subnet, that network/subnet

and its associated endpoints or Neutron Ports are seamlessly added to the namespace.
Neutron FloatingIP
When associated with a Neutron Port, this leverages the OfOverlay renderer’s NAT
capabilities.
A dedicated external interface on each Nova compute host allows for disitributed external
access. Each Nova instance associated with a FloatingIP address can access the external
network directly without having to route via the Neutron controller, or having to enable
any form of Neutron distributed routing functionality.
Assuming the gateway provisioned in the Neutron Subnet command for the external
network is reachable, the combination of GBP Neutron Mapper and OfOverlay renderer
will automatically ARP for this default gateway, requiring no user intervention.
Troubleshooting within GBP
Logging level for the mapping functionality can be set for package
org.opendaylight.groupbasedpolicy.neutron.mapper. An example of enabling TRACE
logging level on Karaf console:
log:set TRACE org.opendaylight.groupbasedpolicy.neutron.mapper
Neutron mapping example
As an example for mapping can be used creation of Neutron network, subnet and port.
When a Neutron network is created 3 GBP entities are created: l2-flood-domain, l2-bridge-
domain, l3-context.
Figure 11.29. Neutron network mapping
After an subnet is created in the network mapping looks like this.
88
Figure 11.30. Neutron subnet mapping
If an Neutron port is created in the subnet an endpoint and l3-endpoint are created. The
endpoint has key composed from l2-bridge-domain and MAC address from Neutron port. A
key of l3-endpoint is compesed from l3-context and IP address. The network containment
of endpoint and l3-endpoint points to the subnet.
Figure 11.31. Neutron port mapping
Configuring GBP Neutron

No intervention passed initial OpenStack setup is required by the user.
More information about configuration can be found in our DevStack demo environment on
the GBP wiki.
Administering or Managing GBP Neutron

For consistencies sake, all provisioning should be performed via the Neutron API. (CLI or
Horizon).
89
The mapped policies can be augmented via the GBP UX, to:
• Enable Service Function Chaining
• Add endpoints from outside of Neutron i.e. VMs/containers not provisioned in

OpenStack
• Augment policies/contracts derived from Security Group Rules
• Overlay additional contracts or groupings
Tutorials
A DevStack demo environment can be found on the GBP wiki.
Using the GBP OpenFlow Overlay (OfOverlay)

renderer
Overview
The OpenFlow Overlay (OfOverlay) feature enables the OpenFlow Overlay renderer, which
creates a network virtualization solution across nodes that host Open vSwitch software
switches.
Installing and Pre-requisites

From the Karaf console in OpenDaylight:
feature:install odl-groupbasedpolicy-ofoverlay
This renderer is designed to work with OpenVSwitch (OVS) 2.1+ (although 2.3 is strongly
recommended) and OpenFlow 1.3.
When used in conjunction with the Neutron Mapper feature no extra OfOverlay specific
setup is required.
When this feature is loaded "standalone", the user is required to configure infrastructure,
such as
• instantiating OVS bridges,
• attaching hosts to the bridges,
• and creating the VXLAN/VXLAN-GPE tunnel ports on the bridges.
The GBP OfOverlay renderer also supports a table offset option, to offset the pipeline post-
table 0. The value of table offset is stored in the config datastore and it may be rewritten at
runtime.
PUT http://{{controllerIp}}:8181/restconf/config/ofoverlay:of-overlay-config
90
{
"of-overlay-config": {
"gbp-ofoverlay-table-offset": 6
}
}
The default value is set by changing: <gbp-ofoverlay-table-offset>0</gbp-ofoverlay-table-

offset>
in file: distribution-karaf/target/assembly/etc/opendaylight/karaf/15-groupbasedpolicy-
ofoverlay.xml
To avoid overwriting runtime changes, the default value is used only when the OfOverlay
renderer starts and no other value has been written before.
OpenFlow Overlay Architecture

These are the primary components of GBP. The OfOverlay components are highlighted in
red.
Figure 11.32. OfOverlay within GBP
In terms of the inner components of the GBP OfOverlay renderer:
91
Figure 11.33. OfOverlay expanded view:
OfOverlay Renderer
Launches components below:
Policy Resolver
Policy resolution is completely domain independent, and the OfOverlay leverages process
policy information internally. See Policy Resolution process.
It listens to inputs to the Tenants configuration datastore, validates tenant input, then
writes this to the Tenants operational datastore.
From there an internal notification is generated to the PolicyManager.
In the next release, this will be moving to a non-renderer specific location.
Endpoint Manager
The endpoint repository operates in orchestrated mode. This means the user is responsible
for the provisioning of endpoints via:
• UX/GUI
• REST API
Note
When using the Neutron mapper feature, everything is managed transparently
via Neutron.
92
The Endpoint Manager is responsible for listening to Endpoint repository updates and
notifying the Switch Manager when a valid Endpoint has been registered.
It also supplies utility functions to the flow pipeline process.
Switch Manager
The Switch Manager is purely a state manager.
Switches are in one of 3 states:
• DISCONNECTED
• PREPARING
• READY
Ready is denoted by a connected switch:
• having a tunnel interface
• having at least one endpoint connected.
In this way GBP is not writing to switches it has no business to.
Preparing simply means the switch has a controller connection but is missing one of the
above complete and necessary conditions
Disconnected means a previously connected switch is no longer present in the Inventory

operational datastore.
Figure 11.34. OfOverlay Flow Pipeline
The OfOverlay leverages Nicira registers as follows:
• REG0 = Source EndpointGroup + Tenant ordinal
• REG1 = Source Conditions + Tenant ordinal
• REG2 = Destination EndpointGroup + Tenant ordinal
• REG3 = Destination Conditions + Tenant ordinal
• REG4 = Bridge Domain + Tenant ordinal
93
• REG5 = Flood Domain + Tenant ordinal
• REG6 = Layer 3 Context + Tenant ordinal
Port Security
Table 0 of the OpenFlow pipeline. Responsible for ensuring that only valid connections can
send packets into the pipeline:
cookie=0x0, <snip> , priority=200,in_port=3 actions=goto_table:2
cookie=0x0, <snip> ,
priority=121,arp,in_port=5,dl_src=fa:16:3e:d5:b9:8d,arp_spa=10.1.1.3
actions=goto_table:2
priority=120,ip,in_port=5,dl_src=fa:16:3e:d5:b9:8d,nw_src=10.1.1.3
priority=115,ip,in_port=5,dl_src=fa:16:3e:d5:b9:8d,nw_dst=255.255.255.255
cookie=0x0, <snip> , priority=112,ipv6 actions=drop
cookie=0x0, <snip> , priority=111, ip actions=drop
cookie=0x0, <snip> , priority=110,arp actions=drop
cookie=0x0, <snip> ,in_port=5,dl_src=fa:16:3e:d5:b9:8d actions=goto_table:2
cookie=0x0, <snip> , priority=1 actions=drop
Ingress from tunnel interface, go to Table Source Mapper:

Ingress from outside, goto Table Ingress NAT Mapper:

ARP from Endpoint, go to Table Source Mapper:

priority=121,arp,in_port=5,dl_src=fa:16:3e:d5:b9:8d,arp_spa=10.1.1.3
IPv4 from Endpoint, go to Table Source Mapper:

priority=120,ip,in_port=5,dl_src=fa:16:3e:d5:b9:8d,nw_src=10.1.1.3
DHCP DORA from Endpoint, go to Table Source Mapper:

priority=115,ip,in_port=5,dl_src=fa:16:3e:d5:b9:8d,nw_dst=255.255.255.255
Series of DROP tables with priority set to capture any non-specific traffic that should have
matched above:
cookie=0x0, <snip> , priority=112,ipv6 actions=drop
cookie=0x0, <snip> , priority=111, ip actions=drop
cookie=0x0, <snip> , priority=110,arp actions=drop
"L2" catch all traffic not identified above:
94
cookie=0x0, <snip> ,in_port=5,dl_src=fa:16:3e:d5:b9:8d actions=goto_table:2
Drop Flow:
cookie=0x0, <snip> , priority=1 actions=drop
Ingress NAT Mapper
Table offset+1.
ARP responder for external NAT address:

cookie=0x0, <snip> , priority=150,arp,arp_tpa=192.168.111.51,arp_op=1
actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:fa:16:3e:58:c3:dd-
>eth_src,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]-
>NXM_NX_ARP_THA[],load:0xfa163e58c3dd->NXM_NX_ARP_SHA[],move:NXM_OF_ARP_SPA[]-
>NXM_OF_ARP_TPA[],load:0xc0a86f33->NXM_OF_ARP_SPA[],IN_PORT
Translate from Outside to Inside and perform same functions as SourceMapper.

cookie=0x0, <snip> , priority=100,ip,nw_dst=192.168.111.51
actions=set_field:10.1.1.2->ip_dst,set_field:fa:16:3e:58:c3:dd-
>eth_dst,load:0x2->NXM_NX_REG0[],load:0x1->NXM_NX_REG1[],load:0x4-
>NXM_NX_REG4[],load:0x5->NXM_NX_REG5[],load:0x7->NXM_NX_REG6[],load:0x3-
>NXM_NX_TUN_ID[0..31],goto_table:3
Source Mapper
Table offset+2.
Determines based on characteristics from the ingress port, which:
• EndpointGroup(s) it belongs to
• Forwarding context
• Tunnel VNID ordinal
Establishes tunnels at valid destination switches for ingress.
Ingress Tunnel established at remote node with VNID Ordinal that maps to Source EPG,
Forwarding Context etc:
cookie=0x0, <snip>, priority=150,tun_id=0xd,in_port=3 actions=load:0xc-
>NXM_NX_REG0[],load:0xffffff->NXM_NX_REG1[],load:0x4->NXM_NX_REG4[],load:0x5-
>NXM_NX_REG5[],load:0x7->NXM_NX_REG6[],goto_table:3
Maps endpoint to Source EPG, Forwarding Context based on ingress port, and MAC:
cookie=0x0, <snip> , priority=100,in_port=5,dl_src=fa:16:3e:b4:b4:b1
actions=load:0xc->NXM_NX_REG0[],load:0x1->NXM_NX_REG1[],load:0x4-
>NXM_NX_REG4[],load:0x5->NXM_NX_REG5[],load:0x7->NXM_NX_REG6[],load:0xd-
>NXM_NX_TUN_ID[0..31],goto_table:3
Generic drop:
cookie=0x0, duration=197.622s, table=2, n_packets=0, n_bytes=0, priority=1
actions=drop
Destination Mapper
95
Table offset+3.
Determines based on characteristics of the endpoint:
• EndpointGroup(s) it belongs to
• Forwarding context
• Tunnel Destination value
Manages routing based on valid ingress nodes ARP’ing for their default gateway, and
matches on either gateway MAC or destination endpoint MAC.
ARP for default gateway for the 10.1.1.0/24 subnet:

cookie=0x0, <snip> , priority=150,arp,reg6=0x7,arp_tpa=10.1.1.1,arp_op=1
actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:fa:16:3e:28:4c:82-
>eth_src,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]-
>NXM_NX_ARP_THA[],load:0xfa163e284c82->NXM_NX_ARP_SHA[],move:NXM_OF_ARP_SPA[]-
>NXM_OF_ARP_TPA[],load:0xa010101->NXM_OF_ARP_SPA[],IN_PORT
Broadcast traffic destined for GroupTable:

priority=140,reg5=0x5,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00
actions=load:0x5->NXM_NX_TUN_ID[0..31],group:5
Layer3 destination matching flows, where priority=100+masklength. Since GBP now

support L3Prefix endpoint, we can set default routes etc:
cookie=0x0, <snip>,
priority=132,ip,reg6=0x7,dl_dst=fa:16:3e:b4:b4:b1,nw_dst=10.1.1.3
actions=load:0xc->NXM_NX_REG2[],load:0x1->NXM_NX_REG3[],load:0x5-
>NXM_NX_REG7[],set_field:fa:16:3e:b4:b4:b1->eth_dst,dec_ttl,goto_table:4
Layer2 destination matching flows, designed to be caught only after last IP flow (lowest
priority IP flow is 100):
cookie=0x0, duration=323.203s, table=3, n_packets=4, n_bytes=168,
priority=50,reg4=0x4,dl_dst=fa:16:3e:58:c3:dd actions=load:0x2-
>NXM_NX_REG2[],load:0x1->NXM_NX_REG3[],load:0x2->NXM_NX_REG7[],goto_table:4
General drop flow: cookie=0x0, duration=323.207s, table=3, n_packets=6, n_bytes=588,

priority=1 actions=drop
Policy Enforcer
Table offset+4.
Once the Source and Destination EndpointGroups are assigned, policy is enforced based on
resolved rules.
In the case of Service Function Chaining, the encapsulation and destination for traffic
destined to a chain, is discovered and enforced.
Policy flow, allowing IP traffic between EndpointGroups:

cookie=0x0, <snip> , priority=64998,ip,reg0=0x8,reg1=0x1,reg2=0xc,reg3=0x1
96
Egress NAT Mapper
Table offset+5.
Performs NAT function before Egressing OVS instance to the underlay network.
Inside to Outside NAT translation before sending to underlay:

cookie=0x0, <snip> , priority=100,ip,reg6=0x7,nw_src=10.1.1.2
actions=set_field:192.168.111.51->ip_src,goto_table:6
External Mapper
Table offset+6.
Manages post-policy enforcement for endpoint specific destination effects. Specifically for
Service Function Chaining, which is why we can support both symmetric and asymmetric
chains and distributed ingress/egress classification.
Generic allow:
cookie=0x0, <snip>, priority=100 actions=output:NXM_NX_REG7[]
Configuring OpenFlow Overlay via REST

Note
Please see the UX section on how to configure GBP via the GUI.
Endpoint
POST http://{{controllerIp}}:8181/restconf/operations/endpoint:register-
endpoint
{
"input": {
"endpoint-group": "<epg0>",
"endpoint-groups" : ["<epg1>","<epg2>"],
"network-containment" : "<fowarding-model-context1>",
"l2-context": "<bridge-domain1>",
"mac-address": "<mac1>",
"l3-address": [
{
"ip-address": "<ipaddress1>",
"l3-context": "<l3_context1>"
}
],
"*ofoverlay:port-name*": "<ovs port name>",
"tenant": "<tenant1>"
}
}
Note
The usage of "port-name" preceded by "ofoverlay". In OpenDaylight, base
datastore objects can be augmented. In GBP, the base endpoint model has no
renderer specifics, hence can be leveraged across multiple renderers.
OVS Augmentations to Inventory
97
PUT http://{{controllerIp}}:8181/restconf/config/opendaylight-inventory:nodes/
{
"opendaylight-inventory:nodes": {
"node": [
{
"id": "openflow:123456",
"ofoverlay:tunnel": [
{
"tunnel-type": "overlay:tunnel-type-vxlan",
"ip": "<ip_address_of_ovs>",
"port": 4789,
"node-connector-id": "openflow:123456:1"
}
]
},
{
"id": "openflow:654321",
"ofoverlay:tunnel": [
{
"tunnel-type": "overlay:tunnel-type-vxlan",
"ip": "<ip_address_of_ovs>",
"port": 4789,
"node-connector-id": "openflow:654321:1"
}
]
}
]
}
}
Tenants see Policy Resolution and Forwarding Model for details:
{
"policy:tenant": {
"contract": [
{
"clause": [
{
"name": "allow-http-clause",
"subject-refs": [
"allow-http-subject",
"allow-icmp-subject"
]
}
],
"id": "<id>",
"subject": [
{
"name": "allow-http-subject",
"rule": [
{
"classifier-ref": [
{
"direction": "in",
"name": "http-dest"
},
{
"direction": "out",
"name": "http-src"
}
98
],
"action-ref": [
{
"name": "allow1",
"order": 0
}
],
"name": "allow-http-rule"
}
]
},
{
"name": "allow-icmp-subject",
"rule": [
{
"classifier-ref": [
{
"name": "icmp"
}
],
"action-ref": [
{
"name": "allow1",
"order": 0
}
],
"name": "allow-icmp-rule"
}
]
}
]
}
],
"endpoint-group": [
{
"consumer-named-selector": [
{
"contract": [
"<id>"
],
"name": "<name>"
}
],
"id": "<id>",
"provider-named-selector": []
},
{
"consumer-named-selector": [],
"id": "<id>",
"provider-named-selector": [
{
"contract": [
"<id>"
],
"name": "<name>"
}
]
}
],
"id": "<id>",
99
"l2-bridge-domain": [
{
"id": "<id>",
"parent": "<id>"
}
],
"l2-flood-domain": [
{
"id": "<id>",
"parent": "<id>"
},
{
"id": "<id>",
"parent": "<id>"
}
],
"l3-context": [
{
"id": "<id>"
}
],
"name": "GBPPOC",
"subject-feature-instances": {
"classifier-instance": [
{
"classifier-definition-id": "<id>",
"name": "http-dest",
"parameter-value": [
{
"int-value": "6",
"name": "proto"
},
{
"int-value": "80",
"name": "destport"
}
]
},
{
"name": "http-src",
{
"int-value": "6",
"name": "proto"
},
{
"int-value": "80",
"name": "sourceport"
}
]
},
{
"name": "icmp",
{
"int-value": "1",
"name": "proto"
}
100
]
}
],
"action-instance": [
{
"name": "allow1",
"action-definition-id": "<id>"
}
]
},
"subnet": [
{
"id": "<id>",
"ip-prefix": "<ip_prefix>",
"parent": "<id>",
"virtual-router-ip": "<ip address>"
},
{
"id": "<id>",
"ip-prefix": "<ip prefix>",
"parent": "<id>",
"virtual-router-ip": "<ip address>"
}
]
}
}
Tutorials
Comprehensive tutorials, along with a demonstration environment leveraging Vagrant can
be found on the GBP wiki
Using the GBP eBPF IO Visor Agent renderer

Overview
The IO Visor renderer feature enables container endpoints (e.g. Docker, LXC) to leverage
GBP policies.
The renderer interacts with a IO Visor module from the Linux Foundation IO Visor project.

feature:install odl-groupbasedpolicy-iovisor odl-restconf
Installation details, usage, and other information for the IO Visor GBP module can be found
here: IO Visor github repo for IO Modules
Using the GBP FaaS renderer

Overview
The FaaS renderer feature enables leveraging the FaaS project as a GBP renderer.
101

feature:install odl-groupbasedpolicy-faas
More information about FaaS can be found here: https://wiki.opendaylight.org/view/

FaaS:GBPIntegration
Using Service Function Chaining (SFC) with GBP

Neutron Mapper and OfOverlay
Overview
Please refer to the Service Function Chaining project for specifics on SFC provisioning and
theory.
GBP allows for the use of a chain, by name, in policy.
This takes the form of an action in GBP.
Using the GBP demo and development environment as an example:
102
Figure 11.35. GBP and SFC integration environment
In the topology above, a symmetrical chain between H35_2 and H36_3 could take path:
H35_2 to sw1 to sff1 to sf1 to sff1 to sff2 to sf2 to sff2 to sw6 to H36_3
If symmetric chaining was desired, the return path is:
103
Figure 11.36. GBP and SFC symmetric chain environment
If asymmetric chaining was desired, the return path could be direct, or an entirely different
chain.
Figure 11.37. GBP and SFC assymmetric chain environment
All these scenarios are supported by the integration.
In the Subject Feature Instance section of the tenant config, we define the instances of the
classifier definitions for ICMP and HTTP:
"subject-feature-instances": {
"classifier-instance": [
104
{
"name": "icmp",
{
"name": "proto",
"int-value": 1
}
]
},
{
{
"int-value": "6",
"name": "proto"
},
{
"int-value": "80",
"name": "destport"
}
]
},
{
"name": "http-src",
{
"int-value": "6",
"name": "proto"
},
{
"int-value": "80",
"name": "sourceport"
}
]
}
],
Then the action instances to associate to traffic that matches classifiers are defined.
Note the SFC chain name must exist in SFC, and is validated against the datastore once
the tenant configuration is entered, before entering a valid tenant configuration into the
operational datastore (which triggers policy resolution).
"action-instance": [
{
"name": "chain1",
{
"name": "sfc-chain-name",
"string-value": "SFCGBP"
}
]
},
{
"name": "allow1",
}
]
},
When ICMP is matched, allow the traffic:
105
"contract": [
{
"subject": [
{
"name": "icmp-subject",
"rule": [
{
"name": "allow-icmp-rule",
"order" : 0,
"classifier-ref": [
{
"name": "icmp"
}
],
"action-ref": [
{
"name": "allow1",
"order": 0
}
]
}
]
},
When HTTP is matched, in to the provider of the contract with a TCP destination port of
80 (HTTP) or the HTTP request. The chain action is triggered, and similarly out from the
provider for traffic with TCP source port of 80 (HTTP), or the HTTP response.
{
"name": "http-subject",
"rule": [
{
"name": "http-chain-rule-in",
"classifier-ref": [
{
"direction": "in"
}
],
"action-ref": [
{
"name": "chain1",
"order": 0
}
]
},
{
"name": "http-chain-rule-out",
"classifier-ref": [
{
"name": "http-src",
"direction": "out"
}
],
"action-ref": [
{
"name": "chain1",
"order": 0
106
}
]
}
]
}
To enable asymmetrical chaining, for instance, the user desires that HTTP requests traverse
the chain, but the HTTP response does not, the HTTP response is set to allow instead of
chain:
{
"name": "http-chain-rule-out",
"classifier-ref": [
{
"name": "http-src",
"direction": "out"
}
],
"action-ref": [
{
"name": "allow1",
"order": 0
}
]
}
Demo/Development environment
The GBP project for Beryllium has two demo/development environments.
• Docker based GBP and GBP+SFC integration Vagrant environment
• DevStack based GBP+Neutron integration Vagrant environment
Demo @ GBP wiki
107
12. L2Switch User Guide
Table of Contents
Overview ..................................................................................................................... 108
L2Switch Architecture .................................................................................................. 108
Configuring L2Switch ................................................................................................... 109
Configuring Loop Remover .......................................................................................... 109
Configuring Arp Handler ............................................................................................. 110
Configuring Address Tracker ........................................................................................ 111
Configuring L2Switch Main .......................................................................................... 111
Running the L2Switch project ...................................................................................... 113
Create a network using mininet .................................................................................. 113
Generating network traffic using mininet .................................................................... 113
Checking Address Observations ................................................................................... 113
Checking Hosts ............................................................................................................ 114
Checking STP status of each link .................................................................................. 115
Miscellaneous mininet commands ................................................................................ 116
Overview
The L2Switch project provides Layer2 switch functionality.
L2Switch Architecture
• Packet Handler
• Decodes the packets coming to the controller and dispatches them appropriately
• Loop Remover
• Removes loops in the network
• Arp Handler
• Handles the decoded ARP packets
• Address Tracker
• Learns the Addresses (MAC and IP) of entities in the network
• Host Tracker
• Tracks the locations of hosts in the network
• L2Switch Main
• Installs flows on each switch based on network traffic
108
Configuring L2Switch
This sections below give details about the configuration settings for the components that
can be configured.
Configuring Loop Remover

• 52-loopremover.xml
• is-install-lldp-flow
• "true" means a flow that sends all LLDP packets to the controller will be installed on
each switch
• "false" means this flow will not be installed
• lldp-flow-table-id
• The LLDP flow will be installed on the specified flow table of each switch
• This field is only relevant when "is-install-lldp-flow" is set to "true"
• lldp-flow-priority
• The LLDP flow will be installed with the specified priority
• lldp-flow-idle-timeout
• The LLDP flow will timeout (removed from the switch) if the flow doesn’t forward a
packet for x seconds
• lldp-flow-hard-timeout
• The LLDP flow will timeout (removed from the switch) after x seconds, regardless of
how many packets it is forwarding
• graph-refresh-delay
• A graph of the network is maintained and gets updated as network elements go up/
down (i.e. links go up/down and switches go up/down)
• After a network element going up/down, it waits graph-refresh-delay seconds

before recomputing the graph
• A higher value has the advantage of doing less graph updates, at the potential cost
of losing some packets because the
109 graph didn’t update immediately.
• A lower value has the advantage of handling network topology changes quicker, at
the cost of doing more computation.
Configuring Arp Handler

• 54-arphandler.xml
• is-proactive-flood-mode
• "true" means that flood flows will be installed on each switch. With this flood flow,
each switch will flood a packet that doesn’t match any other flows.
• Advantage: Fewer packets are sent to the controller because those packets are
flooded to the network.
• Disadvantage: A lot of network traffic is generated.
• "false" means the previously mentioned flood flows will not be installed. Instead an
ARP flow will be installed on each switch that sends all ARP packets to the controller.
• Advantage: Less network traffic is generated.
• Disadvantage: The controller handles more packets (ARP requests & replies) and
the ARP process takes longer than if there were flood flows.
• flood-flow-table-id
• The flood flow will be installed on the specified flow table of each switch
• This field is only relevant when "is-proactive-flood-mode" is set to "true"
• flood-flow-priority
• The flood flow will be installed with the specified priority
• flood-flow-idle-timeout
• The flood flow will timeout (removed from the switch) if the flow doesn’t forward a
• flood-flow-hard-timeout
• The flood flow will timeout (removed from the switch) after x seconds, regardless of
how many packets it is forwarding
• arp-flow-table-id
110
• The ARP flow will be installed on the specified flow table of each switch
• This field is only relevant when "is-proactive-flood-mode" is set to "false"
• arp-flow-priority
• The ARP flow will be installed with the specified priority
• arp-flow-idle-timeout
• The ARP flow will timeout (removed from the switch) if the flow doesn’t forward a
• arp-flow-hard-timeout
• The ARP flow will timeout (removed from the switch) after arp-flow-hard-timeout
seconds, regardless of how many packets it is forwarding
Configuring Address Tracker

• 56-addresstracker.xml
• timestamp-update-interval
• A last-seen timestamp is associated with each address. This last-seen timestamp will
only be updated after timestamp-update-interval milliseconds.
• A higher value has the advantage of performing less writes to the database.
• A lower value has the advantage of knowing how fresh an address is.
• observe-addresses-from
• IP and MAC addresses can be observed/learned from ARP, IPv4, and IPv6 packets.
Set which packets to make these observations from.
Configuring L2Switch Main

• 58-l2switchmain.xml
• is-install-dropall-flow
• "true" means a drop-all flow will be installed on each switch, so the default action
will be to drop a packet instead of sending it to the controller
• "false" means this flow will not be installed

111
• dropall-flow-table-id
• The dropall flow will be installed on the specified flow table of each switch
• This field is only relevant when "is-install-dropall-flow" is set to "true"
• dropall-flow-priority
• The dropall flow will be installed with the specified priority
• dropall-flow-idle-timeout
• The dropall flow will timeout (removed from the switch) if the flow doesn’t forward
a packet for x seconds
• dropall-flow-hard-timeout
• The dropall flow will timeout (removed from the switch) after x seconds, regardless
of how many packets it is forwarding
• is-learning-only-mode
• "true" means that the L2Switch will only be learning addresses. No additional flows
to optimize network traffic will be installed.
• "false" means that the L2Switch will react to network traffic and install flows on the
switches to optimize traffic. Currently, MAC-to-MAC flows are installed.
• reactive-flow-table-id
• The reactive flow will be installed on the specified flow table of each switch
• This field is only relevant when "is-learning-only-mode" is set to "false"
• reactive-flow-priority
• The reactive flow will be installed with the specified priority
• reactive-flow-idle-timeout
• The reactive flow will timeout (removed from the switch) if the flow doesn’t forward
a packet for x seconds
• reactive-flow-hard-timeout 112
• The reactive flow will timeout (removed from the switch) after x seconds, regardless
of how many packets it is forwarding
Running the L2Switch project

To run the L2 Switch inside the Lithium OpenDaylight distribution simply install the odl-
l2switch-switch-ui feature;
feature:install odl-l2switch-switch-ui
Create a network using mininet

sudo mn --controller=remote,ip=<Controller IP> --topo=linear,3 --switch
ovsk,protocols=OpenFlow13
sudo mn --controller=remote,ip=127.0.0.1 --topo=linear,3 --switch
The above command will create a virtual network consisting of 3 switches. Each switch will
connect to the controller located at the specified IP, i.e. 127.0.0.1
sudo mn --controller=remote,ip=127.0.0.1 --mac --topo=linear,3 --switch

The above command has the "mac" option, which makes it easier to distinguish between
Host MAC addresses and Switch MAC addresses.
Generating network traffic using mininet

h1 ping h2
The above command will cause host1 (h1) to ping host2 (h2)
pingall
pingall will cause each host to ping every other host.
Checking Address Observations

Address Observations are added to the Inventory data tree.
The Address Observations on a Node Connector can be checked through a browser or a

REST Client.
http://10.194.126.91:8080/restconf/operational/opendaylight-inventory:nodes/
node/openflow:1/node-connector/openflow:1:1
113
Figure 12.1. Address Observations
Checking Hosts
Host information is added to the Topology data tree.
• Host address
• Attachment point (link) to a node/switch
This host information and attachment point information can be checked through a browser
or a REST Client.
http://10.194.126.91:8080/restconf/operational/network-topology:network-
topology/topology/flow:1/
114
Figure 12.2. Hosts
Checking STP status of each link

STP Status information is added to the Inventory data tree.
• A status of "forwarding" means the link is active and packets are flowing on it.
• A status of "discarding" means the link is inactive and packets are not sent over it.
The STP status of a link can be checked through a browser or a REST Client.
http://10.194.126.91:8080/restconf/operational/opendaylight-inventory:nodes/
node/openflow:1/node-connector/openflow:1:2
115
Figure 12.3. STP status
Miscellaneous mininet commands

link s1 s2 down
This will bring the link between switch1 (s1) and switch2 (s2) down
link s1 s2 up
This will bring the link between switch1 (s1) and switch2 (s2) up
link s1 h1 down
This will bring the link between switch1 (s1) and host1 (h1) down
116
13. L3VPN Service: User Guide
Table of Contents
Overview ..................................................................................................................... 117
Modules & Interfaces .................................................................................................. 117
Provisioning Sequence & Sample Configurations .......................................................... 121
Overview
L3VPN Service in OpenDaylight provides a framework to create L3VPN based on BGP-MP. It
also helps to create Network Virtualization for DC Cloud environment.
Modules & Interfaces

L3VPN service can be realized using the following modules -
VPN Service Modules

1. VPN Manager : Creates and manages VPNs and VPN Interfaces
2. BGP Manager : Configures BGP routing stack and provides interface to routing services
3. FIB Manager : Provides interface to FIB, creates and manages forwarding rules in
Dataplane
4. Nexthop Manager : Creates and manages nexthop egress pointer, creates egress rules in
Dataplane
5. Interface Manager : Creates and manages different type of network interfaces, e.g.,
VLAN, l3tunnel etc.,
6. Id Manager : Provides cluster-wide unique ID for a given key. Used by different modules
to get unique IDs for different entities.
7. MD-SAL Util : Provides interface to MD-SAL. Used by service modules to access MD-SAL
Datastore and services.
All the above modules can function independently and can be utilized by other services as
well.
Configuration Interfaces
The following modules expose configuration interfaces through which user can configure
L3VPN Service.
1. BGP Manager
2. VPN Manager
3. Interface Manager
117
4. FIB Manager
Configuration Interface Details

BGP Manager Interface
1. Data Node Path : /config/bgp:bgp-router/
a. Fields :
i. local-as-identifier
ii. local-as-number
b. REST Methods : GET, PUT, DELETE, POST
2. Data Node Path : /config/bgp:bgp-neighbors/
a. Fields :
i. List of bgp-neighbor
3. Data Node Path : /config/bgp:bgp-neighbors/bgp-neighbor/{as-number}/
a. Fields :
i. as-number
ii. ip-address
VPN Manager Interface

1. Data Node Path : /config/l3vpn:vpn-instances/
a. Fields :
i. List of vpn-instance
2. Data Node Path : /config/l3vpn:vpn-interfaces/vpn-instance
a. Fields :
i. name
ii. route-distinguisher
iii. import-route-policy
iv. export-route-policy
118
3. Data Node Path : /config/l3vpn:vpn-interfaces/
a. Fields :
i. List of vpn-interface
4. Data Node Path : /config/l3vpn:vpn-interfaces/vpn-interface
a. Fields :
i. name
ii. vpn-instance-name
5. Data Node Path : /config/l3vpn:vpn-interfaces/vpn-interface/{name}/adjacency
a. Fields :
i. ip-address
ii. mac-address
Interface Manager Interface

1. Data Node Path : /config/if:interfaces/interface
a. Fields :
i. name
ii. type
iii. enabled
iv. of-port-id
v. tenant-id
vi. base-interface
b. type specific fields
i. when type = l2vlan
A. vlan-id
ii. when type = stacked_vlan
119
A. stacked-vlan-id
iii. when type = l3tunnel
A. tunnel-type
B. local-ip
C. remote-ip
D. gateway-ip
iv. when type = mpls
A. list labelStack
B. num-labels
c. REST Methods : GET, PUT, DELETE, POST
FIB Manager Interface

1. Data Node Path : /config/odl-fib:fibEntries/vrfTables
a. Fields :
i. List of vrfTables
2. Data Node Path : /config/odl-fib:fibEntries/vrfTables/{routeDistinguisher}/
a. Fields :
i. route-distinguisher
ii. list vrfEntries
A. destPrefix
B. label
C. nexthopAddress
3. Data Node Path : /config/odl-fib:fibEntries/ipv4Table
a. Fields :
i. list ipv4Entry
A. destPrefix
B. nexthopAddress
120
Provisioning Sequence & Sample Configurations

Installation
1. Edit etc/custom.properties and set the following property:
vpnservice.bgpspeaker.host.name = <bgpserver-ip> <bgpserver-ip> here refers to the IP
address of the host where BGP is running.
2. Run ODL and install VPN Service feature:install odl-vpnservice-core
Use REST interface to configure L3VPN service
Pre-requisites:
1. BGP stack with VRF support needs to installed and configured
a. Configure BGP as specified in Step 1 below.
2. Create pairs of GRE/VxLAN Tunnels (using ovsdb/ovs-vsctl) between each switch and
between each switch to the Gateway node
a. Create l3tunnel interfaces corresponding to each tunnel in interfaces DS as specified in

Step 2 below.
Step 1 : Configure BGP

1. Configure BGP Router
REST API : PUT /config/bgp:bgp-router/
Sample JSON Data

{
"bgp-router": {
"local-as-identifier": "10.10.10.10",
"local-as-number": 108
}
}
2. Configure BGP Neighbors

REST API : PUT /config/bgp:bgp-neighbors/
Sample JSON Data

{
"bgp-neighbor" : [
{
"as-number": 105,
"ip-address": "169.144.42.168"
}
]
}
121
Step 2 : Create Tunnel Interfaces

Create l3tunnel interfaces corresponding to all GRE/VxLAN tunnels created with ovsdb
(refer Prerequisites). Use following REST Interface -
REST API : PUT /config/if:interfaces/if:interfacce
Sample JSON Data
{
"interface": [
{
"name" : "GRE_192.168.57.101_192.168.57.102",
"type" : "odl-interface:l3tunnel",
"odl-interface:tunnel-type": "odl-interface:tunnel-type-gre",
"odl-interface:local-ip" : "192.168.57.101",
"odl-interface:remote-ip" : "192.168.57.102",
"odl-interface:portId" : "openflow:1:3",
"enabled" : "true"
}
]
}
Following is expected as a result of these configurations

1. Unique If-index is generated
2. Interface-state operational DS is updated
3. Corresponding Nexthop Group Entry is created
Step 3 : OS Create Neutron Ports and attach VMs

At this step user creates VMs.
Step 4 : Create VM Interfaces

Create l2vlan interfaces corresponding to VM created in step 3
REST API : PUT /config/if:interfaces/if:interface
Sample JSON Data
{
"interface": [
{
"name" : "dpn1-dp1.2",
"type" : "l2vlan",
"odl-interface:of-port-id" : "openflow:1:2",
"odl-interface:vlan-id" : "1",
"enabled" : "true"
}
]
}
122
Step 5: Create VPN Instance

REST API : PUT /config/l3vpn:vpn-instances/l3vpn:vpn-instance/
Sample JSON Data

{
"vpn-instance": [
{
"description": "Test VPN Instance 1",
"vpn-instance-name": "testVpn1",
"ipv4-family": {
"route-distinguisher": "4000:1",
"export-route-policy": "4000:1,5000:1",
"import-route-policy": "4000:1,5000:1",
}
}
]
}

1. VPN ID is allocated and updated in data-store
2. Corresponding VRF is created in BGP
3. If there are vpn-interface configurations for this VPN, corresponding action is taken as
defined in step 5
Step 5 : Create VPN-Interface and Local Adjacency

this can be done in two steps as well
1. Create vpn-interface
REST API : PUT /config/l3vpn:vpn-interfaces/l3vpn:vpn-interface/
Sample JSON Data

{
"vpn-interface": [
{
"name": "dpn1-dp1.2",
}
]
}
Note
name here is the name of VM interface created in step 3, 4
2. Add Adjacencies on vpn-interafce

REST API : PUT /config/l3vpn:vpn-interfaces/l3vpn:vpn-interface/dpn1-dp1.3/adjacency
123
Sample JSON Data

{
"adjacency" : [
{
"ip-address" : "169.144.42.168",
"mac-address" : "11:22:33:44:55:66"
}
]
}
its a list, user can define more than one adjacency on a vpn_interface
Above steps can be carried out in a single step as following

{
"vpn-interface": [
{
"name": "dpn1-dp1.3",
"odl-l3vpn:adjacency": [
{
"odl-l3vpn:mac_address": "11:22:33:44:55:66",
"odl-l3vpn:ip_address": "11.11.11.2",
}
]
}
]
}

1. Prefix label is generated and stored in DS
2. Ingress table is programmed with flow corresponding to interface
3. Local Egress Group is created
4. Prefix is added to BGP for advertisement
5. BGP pushes route update to FIB YANG Interface
6. FIB Entry flow is added to FIB Table in OF pipeline
124
14. Link Aggregation Control Protocol User

Guide
Table of Contents
Overview ..................................................................................................................... 125
Link Aggregation Control Protocol Architecture ........................................................... 125
Configuring Link Aggregation Control Protocol ........................................................... 125
Administering or Managing Link Aggregation Control Protocol .................................... 126
Tutorials ...................................................................................................................... 126
Overview
This section contains information about how to use the LACP plugin project with
OpenDaylight, including configurations.
Link Aggregation Control Protocol Architecture

The LACP Project within OpenDaylight implements Link Aggregation Control Protocol
(LACP) as an MD-SAL service module and will be used to auto-discover and aggregate
multiple links between an OpenDaylight controlled network and LACP-enabled endpoints
or switches. The result is the creation of a logical channel, which represents the aggregation
of the links. Link aggregation provides link resiliency and bandwidth aggregation. This
implementation adheres to IEEE Ethernet specification 802.3ad.
Configuring Link Aggregation Control Protocol

This feature can be enabled in the Karaf console of the OpenDaylight Karaf distribution by
issuing the following command:
feature:install odl-lacp-ui
Note
1. Ensure that legacy (non-OpenFlow) switches are configured with LACP mode
active with a long timeout to allow for the LACP plugin in OpenDaylight to
respond to its messages.
2. Flows that want to take advantage of LACP-configured Link Aggregation

Groups (LAGs) must explicitly use a OpenFlow group table entry created
by the LACP plugin. The plugin only creates group table entries, it does not
program any flows on its own.
125
Administering or Managing Link Aggregation

Control Protocol
LACP-discovered network inventory and network statistics can be viewed using the
following REST APIs.
1. List of aggregators available for a node:

http://<ControllerIP>:8181/restconf/operational/opendaylight-
inventory:nodes/node/<node-id>
Aggregator information will appear within the <lacp-aggregators> XML tag.
2. To view only the information of an aggregator:

inventory:nodes/node/<node-id>/lacp-aggregators/<agg-id>
The group ID associated with the aggregator can be found inside the <lag-groupid>
XML tag.
The group table entry information for the <lag-groupid> added for the aggregator is
also available in the opendaylight-inventory node database.
3. To view physical port information.

inventory:nodes/node/<node-id>/node-connector/<node-connector-id>
Ports that are associated with an aggregator will have the tag <lacp-agg-ref>
updated with valid aggregator information.
Tutorials
The below tutorial demonstrates LACP LAG creation for a sample mininet topology.
Sample LACP Topology creation on Mininet

sudo mn --controller=remote,ip=<Controller IP> --topo=linear,1 --switch
The above command will create a virtual network consisting of a switch and a host. The
switch will be connected to the controller.
Once the topology is discovered, verify the presence of a flow entry with "dl_type" set to
"0x8809" to handle LACP packets using the below ovs-ofctl command:
ovs-ofctl -O OpenFlow13 dump-flows s1
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x300000000000001e, duration=60.067s, table=0, n_packets=0, n_bytes=0,
priority=5,dl_dst=01:80:c2:00:00:02,dl_type=0x8809 actions=CONTROLLER:65535
Configure an additional link between the switch (s1) and host (h1) using the below
command on mininet shell to aggregate 2 links:
126
mininet> py net.addLink(s1, net.get('h1'))

mininet> py s1.attach('s1-eth2')
The LACP module will listen for LACP control packets that are generated from legacy switch
(non-OpenFlow enabled). In our example, host (h1) will act as a LACP packet generator. In
order to generate the LACP control packets, a bond interface has to be created on the host
(h1) with mode type set to LACP with long-timeout. To configure bond interface, create a
new file bonding.conf under the /etc/modprobe.d/ directory and insert the below lines in
this new file:
alias bond0 bonding
options bonding mode=4
Here mode=4 is referred to LACP and the default timeout is set to long.
Enable bond interface and associate both physical interface h1-eth0 & h1-eth1 as members
of the bond interface on host (h1) using the below commands on the mininet shell:
mininet> py net.get('h1').cmd('modprobe bonding')
mininet> py net.get('h1').cmd('ip link add bond0 type bond')
mininet> py net.get('h1').cmd('ip link set bond0 address <bond-mac-address>')
mininet> py net.get('h1').cmd('ip link set h1-eth0 down')
mininet> py net.get('h1').cmd('ip link set h1-eth0 master bond0')
mininet> py net.get('h1').cmd('ip link set h1-eth1 down')
mininet> py net.get('h1').cmd('ip link set h1-eth1 master bond0')
mininet> py net.get('h1').cmd('ip link set bond0 up')
Once the bond0 interface is up, the host (h1) will send LACP packets to the switch (s1). The
LACP Module will then create a LAG through exchange of LACP packets between the host
(h1) and switch (s1). To view the bond interface output on the host (h1) side:
mininet> py net.get('h1').cmd('cat /proc/net/bonding/bond0')
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 2
Actor Key: 33
Partner Key: 27
Partner Mac Address: 00:00:00:00:01:01
Slave Interface: h1-eth0

MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:00:00:00:00:11
Aggregator ID: 1
Slave queue ID: 0
Slave Interface: h1-eth1
127
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:00:00:00:00:12
Aggregator ID: 1
Slave queue ID: 0
A corresponding group table entry would be created on the OpenFlow switch (s1) with
"type" set to "select" to perform the LAG functionality. To view the group entries:
mininet>ovs-ofctl -O Openflow13 dump-groups s1
OFPST_GROUP_DESC reply (OF1.3) (xid=0x2):
group_id=60169,type=select,bucket=weight:0,actions=output:1,output:2
To apply the LAG functionality on the switches, the flows should be configured with action
set to GroupId instead of output port. A sample add-flow configuration with output action
set to GroupId:
sudo ovs-ofctl -O Openflow13 add-flow s1
dl_type=0x0806,dl_src=SRC_MAC,dl_dst=DST_MAC,actions=group:60169
128
15. LISP Flow Mapping User Guide
Table of Contents
Overview ..................................................................................................................... 129
LISP Flow Mapping Architecture .................................................................................. 130
Configuring LISP Flow Mapping ................................................................................... 131
Textual Conventions for LISP Address Formats ............................................................. 132
Karaf commands ......................................................................................................... 133
LISP Flow Mapping Karaf Features .............................................................................. 134
Tutorials ...................................................................................................................... 134
LISP Flow Mapping Support ........................................................................................ 140
Overview
Locator/ID Separation Protocol
Locator/ID Separation Protocol (LISP) is a technology that provides a flexible map-and-
encap framework that can be used for overlay network applications such as data center
network virtualization and Network Function Virtualization (NFV).
LISP provides the following name spaces:
• Endpoint Identifiers (EIDs)
• Routing Locators (RLOCs)
In a virtualization environment EIDs can be viewed as virtual address space and RLOCs can
be viewed as physical network address space.
The LISP framework decouples network control plane from the forwarding plane by
providing:
• A data plane that specifies how the virtualized network addresses are encapsulated in
addresses from the underlying physical network.
• A control plane that stores the mapping of the virtual-to-physical address spaces, the
associated forwarding policies and serves this information to the data plane on demand.
Network programmability is achieved by programming forwarding policies such as

transparent mobility, service chaining, and traffic engineering in the mapping system;
where the data plane elements can fetch these policies on demand as new flows arrive. This
chapter describes the LISP Flow Mapping project in OpenDaylight and how it can be used
to enable advanced SDN and NFV use cases.
LISP data plane Tunnel Routers are available at LISPmob.org in the open source community
on the following platforms:
• Linux
• Android
129
• OpenWRT
For more details and support for LISP data plane software please visit the LISPmob web
site.
LISP Flow Mapping Service

The LISP Flow Mapping service provides LISP Mapping System services. This includes LISP
Map-Server and LISP Map-Resolver services to store and serve mapping data to data plane
nodes as well as to OpenDaylight applications. Mapping data can include mapping of
virtual addresses to physical network address where the virtual nodes are reachable or
hosted at. Mapping data can also include a variety of routing policies including traffic
engineering and load balancing. To leverage this service, OpenDaylight applications and
services can use the northbound REST API to define the mappings and policies in the LISP
Mapping Service. Data plane devices capable of LISP control protocol can leverage this
service through a southbound LISP plugin. LISP-enabled devices must be configured to use
this OpenDaylight service as their Map Server and/or Map Resolver.
The southbound LISP plugin supports the LISP control protocol (Map-Register, Map-
Request, Map-Reply messages), and can also be used to register mappings in the
OpenDaylight mapping service.
LISP Flow Mapping Architecture

The following figure shows the various LISP Flow Mapping modules.
Figure 15.1. LISP Mapping Service Internal Architecture
A brief description of each module is as follows:
130
• DAO (Data Access Object): This layer separates the LISP logic from the database, so that
we can separate the map server and map resolver from the specific implementation of
the mapping database. Currently we have an implementation of this layer with an in-
memory HashMap, but it can be switched to any other key/value store and you only
need to implement the ILispDAO interface.
• Map Server: This module processes the adding or registration of authentication tokens
(keys) and mappings. For a detailed specification of LISP Map Server, see LISP.
• Map Resolver: This module receives and processes the mapping lookup queries and
provides the mappings to requester. For a detailed specification of LISP Map Server, see
LISP.
• RPC/RESTCONF: This is the auto-generated RESTCONF-based northbound API. This

module enables defining key-EID associations as well as adding mapping information
through the Map Server. Key-EID associations and mappings can also be queried via this
API.
• GUI: This module enables adding and querying the mapping service through a GUI based
on ODL DLUX.
• Neutron: This module implements the OpenDaylight Neutron Service APIs. It provides
integration between the LISP service and the OpenDaylight Neutron service, and thus
OpenStack.
• Java API: The API module exposes the Map Server and Map Resolver capabilities via a
Java API.
• LISP Proto: This module includes LISP protocol dependent data types and associated
processing.
• In Memory DB: This module includes the in memory database implementation of the
mapping service.
• LISP Southbound Plugin: This plugin enables data plane devices that support LISP
control plane protocol (see LISP) to register and query mappings to the LISP Flow
Mapping via the LISP control plane protocol.
Configuring LISP Flow Mapping

In order to use the LISP mapping service for registering EID to RLOC mappings from
northbound or southbound, keys have to be defined for the EID prefixes first. Once
a key is defined for an EID prefix, it can be used to add mappings for that EID prefix
multiple times. If the service is going to be used to process Map-Register messages from the
southbound LISP plugin, the same key must be used by the data plane device to create the
authentication data in the Map-Register messages for the associated EID prefix.
The etc/custom.properties file in the Karaf distribution allows configuration of

several OpenDaylight parameters. The LISP service has the following properties that can be
adjusted:
lisp.mappingOverwrite (default: Configures handling of mapping updates. When set

true) to true (default) a mapping update (either through
the southbound plugin via a Map-Register message or
131
through a northbound API PUT REST call) the existing

RLOC set associated to an EID prefix is overwritten.
When set to false, the RLOCs of the update are merged
to the existing set.
lisp.smr (default: false) Enables/disables the Solicit-Map-Request (SMR)

functionality. SMR is a method to notify changes in an
EID-to-RLOC mapping to "subscribers". The LISP service
considers all Map-Request’s source RLOC as a subscriber
to the requested EID prefix, and will send an SMR
control message to that RLOC if the mapping changes.
lisp.elpPolicy (default: default) Configures how to build a Map-Reply southbound

message from a mapping containing an Explicit Locator
Path (ELP) RLOC. It is used for compatibility with
dataplane devices that don’t understand the ELP LCAF
format. The default setting doesn’t alter the mapping,
returning all RLOCs unmodified. The both setting adds
a new RLOC to the mapping, with a lower priority than
the ELP, that is the next hop in the service chain. To
determine the next hop, it searches the source RLOC of
the Map-Request in the ELP, and chooses the next hop,
if it exists, otherwise it chooses the first hop. The replace
setting adds a new RLOC using the same algorithm as
the both setting, but using the origin priority of the ELP
RLOC, which is removed from the mapping.
lisp.lookupPolicy (default: Configures the mapping lookup algorithm. When set to

northboundFirst) northboundFirst mappings programmed through the
northbound API will take precedence. If no northbound
programmed mappings exist, then the mapping
service will return mappings registered through
the southbound plugin, if any exists. When set to
northboundAndSouthbound the mapping programmed
by the northbound is returned, updated by the up/
down status of these mappings as reported by the
southbound (if existing).
lisp.mappingMerge (default: Configures the merge policy on the southbound

false) registrations through the LISP SB Plugin. When set to
false, only the latest mapping registered through the
SB plugin is valid in the southbound mapping database,
independent of which device it came from. When set to
true, mappings for the same EID registered by different
devices are merged together and a union of the locators
is maintained as the valid mapping for that EID.
Textual Conventions for LISP Address Formats

In addition to the more common IPv4, IPv6 and MAC address data types, the LISP control
plane supports arbitrary Address Family Identifiers assigned by IANA, and in addition to
those the LISP Canoncal Address Format (LCAF).
132
The LISP Flow Mapping project in OpenDaylight implements support for many of these
different address formats, the full list being summarized in the following table. While
some of the address formats have well defined and widely used textual representation,
many don’t. It became necessary to define a convention to use for text rendering of
all implemented address types in logs, URLs, input fields, etc. The below table lists the
supported formats, along with their AFI number and LCAF type, including the prefix used
for disambiguation of potential overlap, and examples output.
Table 15.1. LISP Address Formats

Name AFI LCAF Prefix Text Rendering
No Address 0 - no: No Address Present
IPv4 Prefix 1 - ipv4: 192.0.2.0/24
IPv6 Prefix 2 - ipv6: 2001:db8::/32
MAC Address 16389 - mac: 00:00:5E:00:53:00
Distinguished Name 17 - dn: stringAsIs
AS Number 18 - as: AS64500
AFI List 16387 1 list: {192.0.2.1,192.0.2.2,2001:db8::1}
Instance ID 16387 2 - [223] 192.0.2.0/24
Application Data 16387 4 appdata: 192.0.2.1!128!17!80-81!6667-7000
Explicit Locator Path 16387 10 elp: {192.0.2.1#192.0.2.2|lps#192.0.2.3}
Source/Destination Key 16387 12 srcdst: 192.0.2.1/32|192.0.2.2/32
Key/Value Address Pair 16387 15 kv: 192.0.2.1#192.0.2.2
Service Path 16387 N/A sp: 42(3)
Please note that the forward slash character / typically separating IPv4 and IPv6 addresses
from the mask length is transformed into %2f when used in a URL.
Karaf commands
In this section we will discuss two types of Karaf commands: built-in, and LISP specific.
Some built-in commands are quite useful, and are needed for the tutorial, so they will be
discussed here. A reference of all LISP specific commands, added by the LISP Flow Mapping
project is also included. They are useful mostly for debugging.
Useful built-in commands

help Lists all available command, with a short description of
each.
help <command_name> Show detailed help about a specific command.
feature:list [-i] Show all locally available features in the Karaf

container. The -i option lists only features that are
currently installed. It is possible to use | grep to filter
the output (for all commands, not just this one).
feature:install Install feature feature_name.

<feature_name>
133
log:set <level> <class> Set the log level for class to level. The default log
level for all classes is INFO. For debugging, or learning
about LISP internals it is useful to run log:set TRACE
org.opendaylight.lispflowmapping right after
Karaf starts up.
log:display Outputs the log file to the console, and returns control
to the user.
log:tail Continuously shows log output, requires Ctrl+C to

return to the console.
LISP specific commands

The available lisp commands can always be obtained by help mappingservice.
Currently they are:
mappingservice:addkey Add the default password password for the IPv4 EID
prefix 0.0.0.0/0 (all addresses). This is useful when
experimenting with southbound devices, and using the
REST interface would be combersome for whatever
reason.
mappingservice:mappings Show the list of all mappings stored in the internal non-
persistent data store (the DAO), listing the full data
structure. The output is not human friendly, but can be
used for debugging.
LISP Flow Mapping Karaf Features

LISP Flow Mapping has the following Karaf features that can be installed from the Karaf
console:
odl-lispflowmapping-msmr This includes the core features required to use the LISP
Flow Mapping Service such as mapping service and the
LISP southbound plugin.
odl-lispflowmapping-ui This includes the GUI module for the LISP Mapping
Service.
odl-lispflowmapping- This is the experimental Neutron provider module for

neutron LISP mapping service.
Tutorials
This section provides a tutorial demonstrating various features in this service.
Creating a LISP overlay

This section provides instructions to set up a LISP network of three nodes (one "client"
node and two "server" nodes) using LISPmob as data plane LISP nodes and the LISP Flow
Mapping project from OpenDaylight as the LISP programmable mapping system for the
LISP network.
134
Overview
The steps shown below will demonstrate setting up a LISP network between a client and
two servers, then performing a failover between the two "server" nodes.
Prerequisites
• OpenDaylight Beryllium
• The Postman Chrome App: the most convenient way to follow along this tutorial is to
use the Postman Chrome App to edit and send the requests. The project git repository
hosts a collection of the requests that are used in this tutorial in the resources/
tutorial/Beryllium_Tutorial.json.postman_collection file. You can
import this file to Postman by clicking Import at the top, choosing Download from link
and then entering the following URL: https://git.opendaylight.org/gerrit/
gitweb?p=lispflowmapping.git;a=blob_plain;f=resources/tutorial/
Beryllium_Tutorial.json.postman_collection;hb=refs/heads/stable/
beryllium. Alternatively, you can save the file on your machine, or if you have the
repository checked out, you can import from there. You will need to create a new
Postman Environment and define some variables within: controllerHost set to the
hostname or IP address of the machine running the ODL instance, and restconfPort
to 8181, if you didn’t modify the default controller settings.
• LISPmob version 0.5.x The README.md lists the dependencies needed to build it from
source.
• A virtualization platform
Target Environment
The three LISP data plane nodes and the LISP mapping system are assumed to be running
in Linux virtual machines, which have the eth0 interface in NAT mode to allow outside
internet access and eth1 connected to a host-only network, with the following IP
addresses (please adjust configuration files, JSON examples, etc. accordingly if you’re using
another addressing scheme):
Table 15.2. Nodes in the tutorial

Node Node Type IP Address
controller OpenDaylight 192.168.16.11
client LISPmob 192.168.16.30
server1 LISPmob 192.168.16.31
server2 LISPmob 192.168.16.32
service-node LISPmob 192.168.16.33
Note
While the tutorial uses LISPmob as the data plane, it could be any LISP-enabled
hardware or software router (commercial/open source).
135
Instructions
The below steps use the command line tool cURL to talk to the LISP Flow Mapping RPC
REST API. This is so that you can see the actual request URLs and body content on the page.
1. Install and run OpenDaylight Beryllium release on the controller VM. Please follow the
general OpenDaylight Beryllium Installation Guide for this step. Once the OpenDaylight
controller is running install the odl-lispflowmapping-msmr feature from the Karaf CLI:
feature:install odl-lispflowmapping-msmr
It takes quite a while to load and initialize all features and their dependencies. It’s worth
running the command log:tail in the Karaf console to see when the log output is
winding down, and continue with the tutorial after that.
2. Install LISPmob on the client, server1, server2, and service-node VMs following the
installation instructions from the LISPmob README file.
3. Configure the LISPmob installations from the previous step. Starting from the
lispd.conf.example file in the distribution, set the EID in each lispd.conf file
from the IP address space selected for your virtual/LISP network. In this tutorial the EID
of the client is set to 1.1.1.1/32, and that of server1 and server2 to 2.2.2.2/32.
4. Set the RLOC interface to eth1 in each lispd.conf file. LISP will determine the RLOC
(IP address of the corresponding VM) based on this interface.
5. Set the Map-Resolver address to the IP address of the controller, and on the client the
Map-Server too. On server1 and server2 set the Map-Server to something else, so that
it doesn’t interfere with the mappings on the controller, since we’re going to program
them manually.
6. Modify the "key" parameter in each lispd.conf file to a key/password of your choice
(password in this tutorial).
Note
The resources/tutorial directory in the stable/beryllium branch of the
project git repository has the files used in the tutorial checked in, so you can
just copy the files to /root/lispd.conf on the respective VMs. You will
also find the JSON files referenced below in the same directory.
7. Define a key and EID prefix association in OpenDaylight using the RPC REST API for the
client EID (1.1.1.1/32) to allow registration from the southbound. Since the mappings
for the server EID will be configured from the REST API, no such association is necessary.
Run the below command on the controller (or any machine that can reach controller, by
replacing localhost with the IP address of controller).
curl -u "admin":"admin" -H "Content-type: application/json" -X POST \

http://localhost:8181/restconf/operations/odl-mappingservice:add-key \
--data @add-key.json
where the content of the add-key.json file is the following:
136
{
"input": {
"eid": {
"address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
"ipv4-prefix": "1.1.1.1/32"
},
"mapping-authkey": {
"key-string": "password",
"key-type": 1
}
}
}
8. Verify that the key is added properly by requesting the following URL:

http://localhost:8181/restconf/operations/odl-mappingservice:get-key \
--data @get1.json
where the content of the get1.json file can be derived from the add-key.json file by
removing the mapping-authkey field. The output the above invocation should look like
this:
{"output":{"mapping-authkey":{"key-type":1,"key-string":"password"}}}
9. Run the lispd LISPmob daemon on all VMs:
lispd -f /root/lispd.conf
10.The client LISPmob node should now register its EID-to-RLOC mapping in OpenDaylight.
To verify you can lookup the corresponding EIDs via the REST API

http://localhost:8181/restconf/operations/odl-mappingservice:get-mapping
\
--data @get1.json
An alternative way for retrieving mappings from ODL using the southbound interface is
using the lig open source tool.
11.Register the EID-to-RLOC mapping of the server EID 2.2.2.2/32 to the controller, pointing
to server1 and server2 with a higher priority for server1

http://localhost:8181/restconf/operations/odl-mappingservice:add-mapping
\
--data @mapping.json
where the mapping.json file looks like this:
{
"input": {
"mapping-record": {
"recordTtl": 1440,
"action": "NoAction",
"authoritative": true,
"eid": {
137
"ipv4-prefix": "2.2.2.2/32"
},
"LocatorRecord": [
{
"locator-id": "server1",
"priority": 1,
"weight": 1,
"multicastPriority": 255,
"multicastWeight": 0,
"localLocator": true,
"rlocProbed": false,
"routed": true,
"rloc": {
"address-type": "ietf-lisp-address-types:ipv4-afi",
"ipv4": "192.168.16.31"
}
},
{
"locator-id": "server2",
"priority": 2,
"weight": 1,
"routed": true,
"rloc": {
"address-type": "ietf-lisp-address-types:ipv4-afi",
"ipv4": "192.168.16.32"
}
}
]
}
}
}
Here the priority of the second RLOC (192.168.16.32 - server2) is 2, a higher numeric
value than the priority of 192.168.16.31, which is 1. This policy is saying that server1
is preferred to server2 for reaching EID 2.2.2.2/32. Note that lower priority value has
higher preference in LISP.
12.Verify the correct registration of the 2.2.2.2/32 EID:

http://localhost:8181/restconf/operations/odl-mappingservice:get-mapping
\
--data @get2.json
where get2.json can be derived from get1.json by changing the content of the
Ipv4Address field from 1.1.1.1 to 2.2.2.2.
13.Now the LISP network is up. To verify, log into the client VM and ping the server EID:
ping 2.2.2.2
14.Let’s test fail-over now. Suppose you had a service on server1 which became unavailable,
but server1 itself is still reachable. LISP will not automatically fail over, even if the
mapping for 2.2.2.2/32 has two locators, since both locators are still reachable and uses
the one with the higher priority (lowest priority value). To force a failover, we need to
138
set the priority of server2 to a lower value. Using the file mapping.json above, swap the
priority values between the two locators (lines 14 and 28 in mapping.json) and repeat
the request from step 11. You can also repeat step 12 to see if the mapping is correctly
registered. If you leave the ping on, and monitor the traffic using wireshark, you can
see that the ping traffic to 2.2.2.2 will be diverted from the server1 RLOC to the server2
RLOC.
With the default OpenDaylight configuration the failover should be near instantaneous
(we observed 3 lost pings in the worst case), because of the LISP Solicit-Map-Request
(SMR) mechanism that can ask a LISP data plane element to update its mapping for
a certain EID (enabled by default). It is controlled by the lisp.smr variable in etc/
custom.porperties. When enabled, any mapping change from the RPC interface
will trigger an SMR packet to all data plane elements that have requested the mapping
in the last 24 hours (this value was chosen because it’s the default TTL of Cisco IOS xTR
mapping registrations). If disabled, ITRs keep their mappings until the TTL specified in
the Map-Reply expires.
15.To add a service chain into the path from the client to the server, we can use an Explicit
Locator Path, specifying the service-node as the first hop and server1 (or server2) as the
second hop. The following will achieve that:

http://localhost:8181/restconf/operations/odl-mappingservice:add-mapping
\
--data @elp.json
where the elp.json file is as follows:
{
"input": {
"mapping-record": {
"recordTtl": 1440,
"action": "NoAction",
"authoritative": true,
"eid": {
"ipv4-prefix": "2.2.2.2/32"
},
"LocatorRecord": [
{
"locator-id": "ELP",
"priority": 1,
"weight": 1,
"routed": true,
"rloc": {
"address-type": "ietf-lisp-address-types:explicit-
locator-path-lcaf",
"explicit-locator-path": {
"hop": [
{
"hop-id": "service-node",
"address": "192.168.16.33",
"lrs-bits": "strict"
139
},
{
"hop-id": "server1",
"address": "192.168.16.31",
"lrs-bits": "strict"
}
]
}
}
}
]
}
}
}
After the mapping for 2.2.2.2/32 is updated with the above, the ICMP traffic from client
to server1 will flow through the service-node. You can confirm this in the LISPmob logs,
or by sniffing the traffic on either the service-node or server1. Note that service chains
are unidirectional, so unless another ELP mapping is added for the return traffic, packets
will go from server1 to client directly.
16.Suppose the service-node is actually a firewall, and traffic is diverted there to support
access control lists (ACLs). In this tutorial that can be emulated by using iptables
firewall rules in the service-node VM. To deny traffic on the service chain defined above,
the following rule can be added:
iptables -A OUTPUT --dst 192.168.16.31 -j DROP
The ping from the client should now have stopped.
In this case the ACL is done on the destination RLOC. There is an effort underway in the
LISPmob community to allow filtering on EIDs, which is the more logical place to apply
ACLs.
17.To delete the rule and restore connectivity on the service chain, delete the ACL by issuing
the following command:
iptables -D OUTPUT --dst 192.168.16.31 -j DROP
which should restore connectivity.
LISP Flow Mapping Support

For support the lispflowmapping project can be reached by emailing the developer mailing
list: [email protected] or on the #opendaylight-lispflowmapping
IRC channel on irc.freenode.net.
Additional information is also available on the Lisp Flow Mapping wiki
140
16. Messaging4Transport User Guide
Table of Contents
Overview ..................................................................................................................... 141
Architecture ................................................................................................................ 141
Administering or Managing Messaging4Transport ....................................................... 142
Overview
The OpenDaylight controller is based on an MD-SAL allows the modeling of data, RPCs,
and notifications. Because of this model basis, adding new northbound bindings to the
controller is simple, and everything modeled becomes exposed automatically. Currently
the MD-SAL has RESTCONF northbound bindings, while more bindings such as AMQP and
XMPP can easily be implemented and integrated. Messaging4Transport attempts to build
more northbound interfaces to MD-SAL, with message-oriented middleware protocols.
Messaging4Transport Beryllium offers an AMQP northbound to MD-SAL.
Architecture
Advanced Message Queuing Protocol (AMQP) is an open standard application layer
protocol for message-oriented middleware. Messaging4Transport adds AMQP bindings
to the MD-SAL, which would automatically make all MD-SAL APIs available via that
mechanism. Messaging4Transport is built as an independent Karaf feature, that exposes
the MD-SAL data tree, RPCs, and notifications via AMQP, when installed. While AMQP is
the focus for the Beryllium Release, other message-oriented transport protocols will be
considered for future releases.
A message broker internal or external to OpenDaylight receives the messages that are
published by the MD-SAL, and sends them to the subscribers. Hence, the broker functions
as an intermediary in messages from the controller to the listeners, and vice versa.
ActiveMQ has been chosen as the default external broker in the Messaging4Transport
Beryllium.
Installing Karaf Features

Install Messaging4Transport by using the karaf console.
feature:install odl-mdsal-all odl-messaging4transport-api odl-
messaging4transport
ActiveMQ Integration with Karaf

ActiveMQ broker can be integrated into the Karaf environment. The ActiveMQ OSGi
integration instructions page is for Karaf 2.x. Please see the Karaf updates page for further
updates.
Since OpenDaylight Beryllium is built on Karaf 3.x, the instructions are given below to install
and activate ActiveMQ OSGi bundle into Karaf.
141
• Installing ActiveMQ in Karaf feature:repo-add activemq 5.9.0

feature:install activemq-broker
• Installing hawtio in Karaf.
hawtio provides a user-friendly web user interface, that can be installed optionally to work
with the project.
feature:repo-add hawtio 1.4.51
feature:install hawtio
Administering or Managing Messaging4Transport

The broker can be a stand-alone or a Karaf-based broker integrated into OpenDaylight.
Just install the bundles as shown below for Karaf based integration. In such a case, broker
will start with OpenDaylight. The publisher publishes the data tree. At least a dummy
listener should be started before the publisher to receive the published messages.
You may further configure the broker by modifying the ActiveMQ configuration file
in ODL_INSTALLATION_DIR/karaf/target/assembly/etc/org.apache.activemq.server-
default.cfg
Make sure to set the transport connections in karaf/target/assembly/etc/activemq.xml,

which is set by default in ActiveMQ stand-alone implementation; but not in the Karaf
implementation.
It is suggested to limit concurrent connections to just 1000. However, probably we will

need more concurrency, based on the requirements. Setting it to 100,000 for now.
<transportConnectors>


<transportConnector name="openwire" uri="tcp://0.0.0.0:61616?
maximumConnections=100000&wireFormat.maxFrameSize=104857600"/>
<transportConnector name="amqp" uri="amqp://0.0.0.0:5672?
maximumConnections=100000&wireFormat.maxFrameSize=104857600"/>


<peer-address>172.20.161.50</peer-address>

<tcp-port>64999</tcp-port>

<password>default</password>

<mode>speaker</mode>
<version>version4</version>
<description>Connection to ASR1K</description>

<connection-timers>

<hold-time-min-acceptable>45</hold-time-min-acceptable>
<keep-alive-time>30</keep-alive-time>
</connection-timers>
</connection>
<connection>


268
<tcp-port>64999</tcp-port>

<password>default</password>

<mode>listener</mode>
<version>version4</version>
<description>Connection to ISR</description>

<connection-timers>


<reconciliation-time>120</reconciliation-time>
<hold-time>90</hold-time>
<hold-time-min>90</hold-time-min>
<hold-time-max>180</hold-time-max>
</connection-timers>
</connection>
</connections>
</input>
• Delete Connection POST http://127.0.0.1:8181/restconf/operations/sxp-

controller:delete-connection
</input>
• Add Binding Entry POST http://127.0.0.1:8181/restconf/operations/sxp-controller:add-

entry
<ip-prefix>192.168.2.1/32</ip-prefix>
<sgt>20</sgt >
</input>
• Update Binding Entry POST http://127.0.0.1:8181/restconf/operations/sxp-

controller:update-entry
<original-binding>
<sgt>20</sgt>
</original-binding>
<new-binding>
<sgt>30</sgt>
</new-binding>
</input>
• Delete Binding Entry POST http://127.0.0.1:8181/restconf/operations/sxp-

controller:delete-entry
<sgt>30</sgt >
</input>
• Get Node Bindings
269
This RPC gets particular device bindings. An SXP-aware node is identified with a unique
Node-ID. If a user requests bindings for a Speaker 20.0.0.2, the RPC will search for an
appropriate path, which contains 20.0.0.2 Node-ID, within locally learnt SXP data in the
SXP database and replies with associated bindings. POST http://127.0.0.1:8181/restconf/
operations/sxp-controller:get-node-bindings
<requested-node>20.0.0.2</requested-node>
</input>
• Get Binding SGTs POST http://127.0.0.1:8181/restconf/operations/sxp-controller:get-

binding-sgts
</input>
Use cases for SXP

Cisco has a wide installed base of network devices supporting SXP. By including SXP
in OpenDaylight, the binding of policy groups to IP addresses can be made available
for possible further processing to a wide range of devices, and applications running on
OpenDaylight. The range of applications that would be enabled is extensive. Here are just a
few of them:
OpenDaylight based applications can take advantage of the IP-SGT binding information.
For example, access control can be defined by an operator in terms of policy groups, while
OpenDaylight can configure access control lists on network elements using IP addresses,
e.g., existing technology.
Interoperability between different vendors. Vendors have different policy systems.

Knowing the IP-SGT binding for Cisco makes it possible to maintain policy groups between
Cisco and other vendors.
OpenDaylight can aggregate the binding information from many devices and communicate
it to a network element. For example, a firewall can use the IP-SGT binding information
to know how to handle IPs based on the group-based ACLs it has set. But to do this with
SXP alone, the firewall has to maintain a large number of network connections to get the
binding information. This incurs heavy overhead costs to maintain all of the SXP peering
and protocol information. OpenDaylight can aggregate the IP-group information so
that the firewall need only connect to OpenDaylight. By moving the information flow
outside of the network elements to a centralized position, we reduce the overhead of
the CPU consumption on the enforcement element. This is a huge savings - it allows the
enforcement point to only have to make one connection rather than thousands, so it can
concentrate on its primary job of forwarding and enforcing.
OpenDaylight can relay the binding information from one network element to others.
Changes in group membership can be propagated more readily through a centralized
model. For example, in a security application a particular host (e.g., user or IP Address) may
be found to be acting suspiciously or violating established security policies. The defined
response is to put the host into a different source group for remediation actions such as
a lower quality of service, restricted access to critical servers, or special routing conditions
270
to ensure deeper security enforcement (e.g., redirecting the host’s traffic through an
IPS with very restrictive policies). Updated group membership for this host needs to be
communicated to multiple network elements as soon as possible; a very efficient and
effective method of propagation can be performed using OpenDaylight as a centralized
point for relaying the information.
OpenDayLight can create filters for exporting and recieving IP-SGTT bindings used on
specific peer groups, thus can provide more complex maintaining of policy groups.
Although the IP-SGT binding is only one specific piece of information, and although SXP is
implemented widely in a single vendor’s equipment, bringing the ability of OpenDaylight to
process and distribute the bindings, is a very specific immediate useful implementation of
policy groups. It would go a long way to develop both the usefulness of OpenDaylight and
of policy groups.
271
28. TCPMD5 User Guide
Table of Contents
Overview ..................................................................................................................... 272
Configuring TCPMD5 manually .................................................................................... 272
Configuring TCPMD5 through RESTCONF .................................................................... 275
This user guide describes the configuration for Border Gateway Protocol (BGP) and Path
Computation Element Protocol (PCEP) using MD5 authentication. It is destined for users
who build applications using MD5 library.
Overview
The TCPMD5 library provides access to RFC-2385 MD5 Signature Option on operating
systems which support it in their TCP stack. This option has been historically used to protect
BGP sessions, but is equally useful for protecting PCEP sessions.
Important
Before you continue with steps in this user guide, make sure BGP and/or
PCEP is configured properly.
TCPMD5 authentication is disabled by default. To enable it (for both protocols),

uncomment the contents of 20-tcpmd5.xml. You can find this configuration file in your
OpenDaylight directory etc/opendaylight/karaf .
Caution
If the connection can not be established, there are no warnings or errors, so
be sure to double check your configuration and passwords.
Configuring TCPMD5 manually

BGP
Important
Make sure your 20-tcpmd5.xml has its content uncommented.
To enable TCPMD5 for the BGP protocol, perform the following steps:
1. In 31-bgp.xml uncomment the TCP MD5 section:
272

<md5-channel-factory>
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:tcpmd5:netty:cfg">prefix:md5-
channel-factory</type>
<name>md5-client-channel-factory</name>
</md5-channel-factory>
<md5-server-channel-factory>
<type xmlns:prefix=
server-channel-factory</type>
<name>md5-server-channel-factory</name>
</md5-server-channel-factory>
2. In 41-bgp-example.xml add <password> tag to module example-bgp-peer.

<module>
<type xmlns:prefix=
peer</type>
<host>10.25.2.27</host>
<rib>
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:cfg">prefix:rib</
type>
</rib>
<advertized-table>
<type xmlns:prefix=
table-type</type>
</advertized-table>
<advertized-table>
<type xmlns:prefix=
table-type</type>
</advertized-table>
<advertized-table>
<type xmlns:prefix=
table-type</type>
</advertized-table>
<password>changeme</password>
</module>
273
Note
Setting a password on other BGP devices is out of scope for this document.
PCEP
Important
Make sure your 20-tcpmd5.xml has its content uncommented.
To enable TCPMD5 for PCE protocol, perform the following steps:
1. In 32-pcep.xml uncomment the TCPMD5 section:

<md5-channel-factory>
<type xmlns:prefix=
<md5-server-channel-factory>
<type xmlns:prefix=
2. In 39-pcep-provider.xml uncomment following section:

<client>
<address>192.0.2.2</address>
<password>changeme</password>
</client>
Important
Change the <address> value to the address of PCC, the one that is advertized
to PCE and provide password matching the one set on PCC.
Note
Setting a password on PCC is out of scope for this document.
274
Configuring TCPMD5 through RESTCONF

Important
Before you start, make sure, you have installed features for BGP and/or PCEP.
Install another feature, that will provide you the access to restconf/config/
URLs.
feature:install odl-netconf-connector-all
This log message indicates successful start of netconf-connector: Netconf connector

initialized successfully
• To check what modules you have currently configured, check following link: http://
netconf/node/controller-config/yang-ext:mount/config:modules/
• To check what services you have currently configured, check following link: http://
netconf/node/controller-config/yang-ext:mount/config:services/
These URLs are also used to POST new configuration. If you want to change any other
configuration that is listed here, make sure you include the correct namespaces. The correct
namespace for <module> is always urn:opendaylight:params:xml:ns:yang:controller:config.
The namespace for any other fields can be found by finding given module in configuration
yang files.
Note
RESTCONF will tell you if some namespace is wrong.
To enable TCPMD5 for either one of the protocols, enable TCPMD5 modules and services:
Caution
You have to make separate POST requests for each module/service!
*URL: http://localhost:8181/restconf/config/network-topology:network-topology/
POST:
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:tcpmd5:jni:cfg">x:native-key-
access-factory</type>
<name>global-key-access-factory</name>
</module>
275
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:tcpmd5:netty:cfg">x:md5-
client-channel-factory</type>
<key-access-factory xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:tcpmd5:netty:cfg">
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:tcpmd5:cfg">x:key-access-
factory</type>
</key-access-factory>
</module>
<type xmlns:prefix=
server-channel-factory-impl</type>
<server-key-access-factory xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:tcpmd5:netty:cfg">
<type xmlns:x=
factory</type>
</server-key-access-factory>
</module>
URL: http://localhost:8181/restconf/config/network-topology:network-topology/
topology/topology-netconf/node/controller-config/yang-ext:mount/config:services/
POST:
<service xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
<type xmlns:x=
factory</type>
<instance>
<provider>/modules/module[type='native-key-access-factory'][name='global-
key-access-factory']</provider>
</instance>
</service>
<type xmlns:x=
<instance>
<provider>/modules/module[type='md5-client-channel-factory'][name='md5-
client-channel-factory']</provider>
</instance>
</service>
276
<type xmlns:prefix=
<instance>
<provider>/modules/module[type='md5-server-channel-factory-impl'][name='md5-
server-channel-factory']</provider>
</instance>
</service>
BGP
Caution
You have to introduce modules and services mentioned in the previous section.
Your BGP client needs to be ALREADY configured. Check User Guide for BGP.
Caution
You need to copy and paste FULL module in order to replace it. This guide
shows you part you need to change.
1. Enabling TCPMD5 in BGP configuration:
odl-bgp-rib-impl-cfg:bgp-dispatcher-impl/global-bgp-dispatcher
PUT:
<type xmlns:x=
dispatcher-impl</type>
<name>global-bgp-dispatcher</name>
<md5-channel-factory xmlns=
<type xmlns:x=
<md5-server-channel-factory xmlns=
<type xmlns:x=
...
</module>
Caution
277
1. Set password:
odl-bgp-rib-impl-cfg:bgp-peer/example-bgp-peer
PUT:
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-peer</
type>
<password xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">changeme</
password>
...
</module>
PCEP
Caution
You have to introduce modules and services mentioned in the previous section.
Caution
1. Enable TCPMD5 in PCEP configuration:
odl-pcep-impl-cfg:pcep-dispatcher-impl/global-pcep-dispatcher
PUT:
278
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:pcep:impl">x:pcep-dispatcher-
impl</type>
<name>global-pcep-dispatcher</name>
<md5-channel-factory xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:pcep:impl">
<type xmlns:x=
<md5-server-channel-factory xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:pcep:impl">
<type xmlns:x=
...
</module>
Caution
1. Set password:
odl-pcep-impl-cfg:pcep-topology-provider/pcep-topology
PUT:
<type xmlns:x=
"urn:opendaylight:params:xml:ns:yang:controller:pcep:topology:provider">x:pcep-
topology-provider</type>
<name>pcep-topology</name>
<client xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:pcep:topology:provider">
<address xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:pcep:topology:provider">192.0.
2.2</address> 
<password>changeme</password> 
</client>
...
</module>
279
29. TSDR H2 datastore User Guide
Table of Contents
Overview ..................................................................................................................... 280
TSDR Architecture ....................................................................................................... 280
Configuring TSDR with default datastore H2 ............................................................... 280
Administering or Managing TSDR with default datastore H2 ........................................ 280
This document describes how to use the embedded JPA datastore H2, which is the
default datastore (recommended for non-production use case) introduced as part of
OpenDaylight Time Series Data Respository(TSDR) project. This store captures the time
series data. This document contains configuration, administration, management, using, and
troubleshooting sections for the feature.
Overview
In the Lithium Release of Time Series Data Repository (TSDR), time series metrics
corresponding to the OpenFlow statistics are captured. For users trying out things on their
laptop or non-production environment, TSDR functionality can be enabled with default
datastore H2 by installing the feature odl-tsdr-all.
TSDR Architecture
The following wiki pages capture the TSDR Model/Architecture
a. https://wiki.opendaylight.org/view/
TSDR_Data_Storage_Service_and_Persistence_with_HBase_Plugin
b. https://wiki.opendaylight.org/view/TSDR_Data_Collection_Service
Note in Lithium the DataCollection Service is implemented just for OpenFlow Statistics
metrics.
Configuring TSDR with default datastore H2

The H2 based storage files get stored automatically in <karaf install folder>/tsdr/ directory.
If you want to change the default storage location, the configuration file to change can
be found in <karaf install folder>/etc directory. The filename is org.ops4j.datasource-
metric.cfg. Change the last portion of the url=jdbc:h2:./tsdr/metric to point to different
directory.
Administering or Managing TSDR with default

datastore H2
Once the TSDR default datastore feature (odl-tsdr-all) is enabled, the TSDR captured
OpenFlow statistics metrics can be accessed from Karaf Console by executing the command
280
tsdr:list <metric-category> <starttimestamp> <endtimestamp>
wherein
• <metric-category> = any one of the following categories FlowGroupStats,

FlowMeterStats, FlowStats, FlowTableStats, PortStats, QueueStats
• <starttimestamp> = to filter the list of metrics starting this timestamp
• <endtimestamp> = to filter the list of metrics ending this timestamp
If either of <starttimestamp> or <endtimestamp> is not specified, this command displays

the latest 1000 metrics captured.
With TSDR functionality with default H2 datastore you get an additional command
tsdr:purgeAll
This will purge the entire collected tsdr metrics record.
281
30. TSDR HBase Data Store User Guide
Table of Contents
Overview ..................................................................................................................... 282
TSDR with HBase Data Store Architecture .................................................................... 282
Configuring TSDR with HBase Data Store .................................................................... 283
Administering or Managing TSDR HBase Data Store .................................................... 283
Tutorials ...................................................................................................................... 284
This document describes how to use HBase to capture time series data using Time Series
Data Repository (TSDR) feature in the OpenDaylight Lithium release. This document
contains configuration, administration, management, usage, and troubleshooting sections
for the feature.
Overview
The Time Series Data Repository (TSDR) project in OpenDaylight (ODL) creates a
framework for collecting, storing, querying, and maintaining time series data in then
OpenDaylight SDN controller. TSDR provides the framework for plugging in proper data
collectors to collect various time series data and store into TSDR data stores. With a
common data model and generic TSDR data persistence APIs, the user could choose various
data stores to be plugged into TSDR Persistence framework. In Lithium, two types of data
stores are supported: HBase NoSQL database and H2 relational database.
With the capabilities of data collection, storage, query, aggregation, and purging provided
by TSDR, network administrators could leverage various data driven appliations built on
top of TSDR for security risk detection, performance analysis, operational configuration
optimization, traffic engineering, and network analytics with automated intelligence.
TSDR with HBase Data Store Architecture

TSDR contains the following services and components: * Data Collection Service * Data
Storage Service * TSDR Persistence Layer with data stores as plugins * TSDR Data Stores *
Data Query Service * Data Aggregation Service * Data Purging Service
Data Collection Service handles the collection of time series data into TSDR and hands it
over to Data Storage Service. Data Storage Service stores the data into TSDR through TSDR
Persistence Layer. TSDR Persistence Layer provides generic Service APIs allowing various
data stores to be plugged in. Data Aggregation Service aggregates time series fine-grained
raw data into course-grained roll-up data to control the size of the data. Data Purging
Service periodically purges both fine-grained raw data and course-granined aggregated
data according to user-defined schedules.
In Lithium, we implemented Data Collection Service, Data Storage Service, TSDR Persistence
Layer, TSDR HBase Data Store, and TSDR H2 Data Store. Among these services and
components, time series data is communicated using a common TSDR data model, which
is designed and implemented for the abstraction of time series data commonalities. With
these functions, TSDR will be able to collect the data from the data sources and store
282
them into one of the TSDR data stores: either HBase Data Store or H2 Data Store. We also
provided a simple query command from Karaf console for the user to retrieve TSDR data
from the data stores.
A future release will contain Data Aggregation service, Data Purging Service, and a full-
fledged Data Query Service with Norghbound APIs.
Configuring TSDR with HBase Data Store

After installing HBase Server on the same VM as the OpenDaylight Controller, if the user
accepts the default configuration of the HBase Data Store, the user can directly proceed
with the installation of HBase Data Store from Karaf console.
Optionally, the user can configure TSDR HBase Data Store following HBase Data Store
Configuration Procedure.
• HBase Data Store Configuration Steps
• Open the file etc/tsdr-persistence-hbase.peroperties under karaf distribution directory.
• Edit the following parameters:
• HBase server name
• HBase server port
• HBase client connection pool size
• HBase client write buffer size
After the configuration of HBase Data Store is complete, proceed with the installation of
HBase Data Store from Karaf console.
• HBase Data Store Installation Steps
• Start Karaf Console
• Run the following commands from Karaf Console: feature:install odl-tsdr-hbase
Administering or Managing TSDR HBase Data

Store
• Using Karaf Command to retrieve data from HBase Data Store The user can retrieve the
data from HBase data store using the following commands from Karaf console:
tsdr:list
tsdr:list <CategoryName> <StartTime> <EndTime>
Typing tab will get the context prompt of the arguments when typeing the command in
Karaf console.
• Troubleshooting issues with log files
283
• Karaf logs Similar to other OpenDaylight components and features, TSDR HBase
Data Store writes logging information to Karaf logs. All the information messages,
warnings, error messages, and debug messages are written to Karaf logs.
• HBase logs For HBase system level logs, the user can check standard HBase server logs,
which is under <HBase-installation-directory>/logs.
Tutorials
How to use TSDR to collect, store, and view OpenFlow
Interface Statistics
Overview
This tutorial describes an example of using TSDR to collect, store, and view one type of time
series data in OpenDaylight environment.
Prerequisites
You would need to have the following as prerequisits: * One or multiple OpenFlow enabled
switches. Alternatively, you can use mininet to simulate such a switch. * Successfully
installed OpenDaylight Controller. * Successfully installed HBase Data Store following
TSDR HBase Data Store Installation Guide. * Connect the OpenFlow enabled switch(es) to
OpenDaylight Controller. ===== Target Environment HBase data store is only supported in
Linux operation system.
Instructions
• Start OpenDaylight controller.
• Connect OpenFlow enabled switch(es) to the controller.
**If using mininet, run the following commands from mininet command line:
• mn --topo single,3 --controller remote,ip=172.17.252.210,port=6653 --switch

**If using real switch(es), the OpenDaylight controller should be able to discover the
network toplogy containing the switches.
• Install tsdr hbase feature from Karaf:
• feature:install odl-tsdr-hbase
• run the following command from Karaf console:
• tsdr:list InterfaceStats
You should be able to see the interface statistics of the switch(es) from the HBase Data
Store. If there are too many rows, you can use "tsdr:list InterfaceStats|more" to view it
page by page.
284
By tabbing after "tsdr:list", you will see all the supported data categories. For example,
"tsdr:list FlowStats" will output the Flow statistics data collected from the switch(es).
285
31. TTP CLI Tools User Guide
Table of Contents
Overview ..................................................................................................................... 286
TTP CLI Tools Architecture ........................................................................................... 286
Overview
Table Type Patterns are a specification developed by the Open Networking Foundation
to enable the description and negotiation of subsets of the OpenFlow protocol. This is
particularly useful for hardware switches that support OpenFlow as it enables the to
describe what features they do (and thus also what features they do not) support. More
details can be found in the full specification listed on the OpenFlow specifications page.
TTP CLI Tools Architecture

The TTP CLI Tools use the TTP Model and the YANG Tools/RESTCONF codecs to translate
between the Data Transfer Objects (DTOs) and JSON/XML.
286
32. Unified Secure Channel
Table of Contents
Overview ..................................................................................................................... 287
USC Channel Architecture ............................................................................................ 287
Installing USC Channel ................................................................................................. 288
Configuring USC Channel ............................................................................................ 288
Administering or Managing USC Channel .................................................................... 288
Tutorials ...................................................................................................................... 288
This document describes how to use the Unified Secure Channel (USC) feature in
OpenDaylight. This document contains configuration, administration, and management
sections for the feature.
Overview
In enterprise networks, more and more controller and network management systems
are being deployed remotely, such as in the cloud. Additionally, enterprise networks are
becoming more heterogeneous - branch, IoT, wireless (including cloud access control).
Enterprise customers want a converged network controller and management system
solution. This feature is intended for device and network administrators looking to use
unified secure channels for their systems.
USC Channel Architecture

• USC Agent
• The USC Agent provides proxy and agent functionality on top of all standard protocols
supported by the device. It initiates call-home with the controller, maintains live
connections with with the controller, acts as a demuxer/muxer for packets with the
USC header, and authenticates the controller.
• USC Plugin
• The USC Plugin is responsible for communication between the controller and the USC
agent . It responds to call-home with the controller, maintains live connections with
the devices, acts as a muxer/demuxer for packets with the USC header, and provides
support for TLS/DTLS.
• USC Manager
• The USC Manager handles configurations, high availability, security, monitoring, and
clustering support for USC.
• USC UI
• The USC UI is responsible for displaying a graphical user interface representing the
state of USC in the OpenDaylight DLUX UI.
287
Installing USC Channel

To install USC, download OpenDaylight and use the Karaf console to install the following
feature:
odl-usc-channel-ui
Configuring USC Channel

This section gives details about the configuration settings for various components in USC.
The USC configuration files for the Karaf distribution are located in distribution/karaf/
target/assembly/etc/usc
• certificates
• The certificates folder contains the client key, pem, and rootca files as is necessary for
security.
• akka.conf
• This file contains configuration related to clustering. Potential configuration properties

can be found on the akka website at http://doc.akka.io
• usc.properties
• This file contains configuration related to USC. Use this file to set the location of
certificates, define the source of additional akka configurations, and assign default
settings to the USC behavior.
Administering or Managing USC Channel

After installing the odl-usc-channel-ui feature from the Karaf console, users can administer
and manage USC channels from the the UI or APIDOCS explorer.
Go to http://${ipaddress}:8181/index.html, sign in, and click on the USC side menu tab.
From there, users can view the state of USC channels.
Go to http://${ipaddress}:8181/apidoc/explorer/index.html, sign in, and expand the usc-

channel panel. From there, users can execute various API calls to test their USC deployment
such as add-channel, delete-channel, and view-channel.
Tutorials
Below are tutorials for USC Channel
Viewing USC Channel

The purpose of this tutorial is to view USC Channel
288
Overview
This tutorial walks users through the process of viewing the USC Channel environment
topology including established channels connecting the controllers and devices in the USC
topology.
Prerequisites
For this tutorial, we assume that a device running a USC agent is already installed.
Instructions
• Run the OpenDaylight distribution and install odl-usc-channel-ui from the Karaf console.
• Go to http://${ipaddress}:8181/apidoc/explorer/index.html
• Execute add-channel with the following json data:
• {"input":{"channel":{"hostname":"127.0.0.1","port":1068,"remote":false}}}
• Go to http://${ipaddress}:8181/index.html
• Click on the USC side menu tab.
• The UI should display a table including the added channel from step 3.
289
33. Virtual Tenant Network (VTN)
Table of Contents
VTN Overview ............................................................................................................. 290
VTN OpenStack Configuration ..................................................................................... 299
VTN Usage Examples ................................................................................................... 321
VTN Overview
OpenDaylight Virtual Tenant Network (VTN) is an application that provides multi-tenant
virtual network on an SDN controller.
Conventionally, huge investment in the network systems and operating expenses are
needed because the network is configured as a silo for each department and system. So,
various network appliances must be installed for each tenant and those boxes cannot be
shared with others. It is a heavy work to design, implement and operate the entire complex
network.
The uniqueness of VTN is a logical abstraction plane. This enables the complete separation
of logical plane from physical plane. Users can design and deploy any desired network
without knowing the physical network topology or bandwidth restrictions.
VTN allows the users to define the network with a look and feel of conventional L2/L3
network. Once the network is designed on VTN, it will automatically be mapped into
underlying physical network, and then configured on the individual switch leveraging
SDN control protocol. The definition of logical plane makes it possible not only to hide
the complexity of the underlying network but also to better manage network resources.
It achieves reducing reconfiguration time of network services and minimizing network
configuration errors.
290
Figure 33.1. VTN Overview
It is implemented as two major components
• VTN Manager
• VTN Coordinator
VTN Manager
An OpenDaylight Controller Plugin that interacts with other modules to implement
the components of the VTN model. It also provides a REST interface to configure VTN
components in ODL controller. VTN Manager is implemented as one plugin to the
OpenDaylight controller. This provides a REST interface to create/update/delete VTN
components. The user command in VTN Coordinator is translated as REST API to VTN
Manager by the ODC Driver component. In addition to the above mentioned role, it also
provides an implementation to the OpenStack L2 Network Functions API.
Features Overview
• odl-vtn-manager provides VTN Manager’s JAVA API.
• odl-vtn-manager-rest provides VTN Manager’s REST API.
• odl-vtn-manager-neutron provides the integration with Neutron interface.
REST API
VTN Manager provides REST API for virtual network functions.
Here is an example of how to create a virtual tenant network.
291
curl --user "admin":"admin" -H "Accept: application/json" -H \

"Content-type: application/json" -X POST \
http://localhost:8282/controller/nb/v2/vtn/default/vtns/Tenant1 \
-d '{"description": "My First Virtual Tenant Network"}'
You can check the list of all tenants by executing the following command.
curl --user "admin":"admin" -H "Accept: application/json" -H \
"Content-type: application/json" -X GET \
http://localhost:8282/controller/nb/v2/vtn/default/vtns
REST API documentation for VTN Manager, please refer: https://jenkins.opendaylight.org/

releng/view/vtn/job/vtn-merge-master/lastSuccessfulBuild/artifact/manager/northbound/
target/site/wsdocs/rest.html
VTN Coordinator
The VTN Coordinator is an external application that provides a REST interface for a
user to use the VTN Virtualization. It interacts with VTN Manager plugin to implement
the user configuration. It is also capable of multiple controller orchestration. It realizes
Virtual Tenant Network (VTN) provisioning in OpenDaylight Controllers (ODC). In
the OpenDaylight architecture VTN Coordinator is part of the network application,
orchestration and services layer. VTN Coordinator has been implemented as an external
application to the OpenDaylight controller. This component is responsible for the VTN
virtualization. VTN Coordinator will use the REST interface exposed by the VTN Manger to
realize the virtual network using the OpenDaylight controller. It uses OpenDaylight APIs
(REST) to construct the virtual network in ODCs. It provides REST APIs for northbound VTN
applications and supports virtual networks spanning across multiple ODCs by coordinating
across ODCs.
For VTN Coordinator REST API, please refer: https://wiki.opendaylight.org/view/

OpenDaylight_Virtual_Tenant_Network_%28VTN%29:VTN_Coordinator:RestApi
Network Virtualization Function

The user first defines a VTN. Then, the user maps the VTN to a physical network, which
enables communication to take place according to the VTN definition. With the VTN
definition, L2 and L3 transfer functions and flow-based traffic control functions (filtering
and redirect) are possible.
Virtual Network Construction

The following table shows the elements which make up the VTN. In the VTN, a virtual
network is constructed using virtual nodes (vBridge, vRouter) and virtual interfaces and
links. It is possible to configure a network which has L2 and L3 transfer function, by
connecting the virtual intrefaces made on virtual nodes via virtual links.
vBridge The logical representation of L2 switch function.

vRouter The logical representation of router function.
vTep The logical representation of Tunnel End Point - TEP.
vTunnel The logical representation of Tunnel.
292
vBypass The logical representation of connectivity between

controlled networks.
Virtual interface The representation of end point on the virtual node.
Virtual Linkv(vLink) The logical representation of L1 connectivity between
virtual interfaces.
The following figure shows an example of a constructed virtual network. VRT is defined as
the vRouter, BR1 and BR2 are defined as vBridges. interfaces of the vRouter and vBridges
are connected using vLinks.
Figure 33.2. VTN Construction
Mapping of Physical Network Resources

Map physical network resources to the constructed virtual network. Mapping identifies
which virtual network each packet transmitted or received by an OpenFlow switch belongs
to, as well as which interface in the OpenFlow switch transmits or receives that packet.
There are two mapping methods. When a packet is received from the OFS, port mapping is
first searched for the corresponding mapping definition, then VLAN mapping is searched,
and the packet is mapped to the relevant vBridge according to the first matching mapping.
Port mapping Maps physical network resources to an interface of

vBridge using Switch ID, Port ID and VLAN ID of the
incoming L2 frame. Untagged frame mapping is also
supported.
VLAN mapping Maps physical network resources to a vBridge using VLAN
ID of the incoming L2 frame.Maps physical resources of a
particular switch to a vBridge using switch ID and VLAN ID
of the incoming L2 frame.
293
MAC mapping Maps physical resources to an interface of vBridge

using MAC address of the incoming L2 frame(The initial
contribution does not include this method).
VTN can learn the terminal information from a terminal that is connected to a switch which
is mapped to VTN. Further, it is possible to refer that terminal information on the VTN.
• Learning terminal information VTN learns the information of a terminal that belongs to
VTN. It will store the MAC address and VLAN ID of the terminal in relation to the port of
the switch.
• Aging of terminal information Terminal information, learned by the VTN, will be

maintained until the packets from terminal keep flowing in VTN. If the terminal gets
disconnected from the VTN, then the aging timer will start clicking and the terminal
information will be maintained till timeout.
The following figure shows an example of mapping. An interface of BR1 is mapped to port
GBE0/1 of OFS1 using port mapping. Packets received from GBE0/1 of OFS1 are regarded
as those from the corresponding interface of BR1. BR2 is mapped to VLAN 200 using VLAN
mapping. Packets with VLAN tag 200 received from any ports of any OFSs are regarded as
those from an interface of BR2.
Figure 33.3. VTN Mapping
294
vBridge Functions
The vBridge provides the bridge function that transfers a packet to the intended virtual
port according to the destination MAC address. The vBridge looks up the MAC address
table and transmits the packet to the corresponding virtual interface when the destination
MAC address has been learned. When the destination MAC address has not been learned,
it transmits the packet to all virtual interfaces other than the receiving port (flooding). MAC
addresses are learned as follows.
• MAC address learning The vBridge learns the MAC address of the connected host. The
source MAC address of each received frame is mapped to the receiving virtual interface,
and this MAC address is stored in the MAC address table created on a per-vBridge basis.
• MAC address aging The MAC address stored in the MAC address table is retained as long
as the host returns the ARP reply. After the host is disconnected, the address is retained
until the aging timer times out. To have the vBridge learn MAC addresses statically, you
can register MAC addresses manually.
vRouter Functions
The vRouter transfers IPv4 packets between vBridges. The vRouter supports routing, ARP
learning, and ARP aging functions. The following outlines the functions.
• Routing function When an IP address is registered with a virtual interface of the vRouter,
the default routing information for that interface is registered. It is also possible to
statically register routing information for a virtual interface.
• ARP learning function The vRouter associates a destination IP address, MAC address
and a virtual interface, based on an ARP request to its host or a reply packet for an
ARP request, and maintains this information in an ARP table prepared for each routing
domain. The registered ARP entry is retained until the aging timer, described later,
times out. The vRouter transmits an ARP request on an individual aging timer basis and
deletes the associated entry from the ARP table if no reply is returned. For static ARP
learning, you can register ARP entry information manually. *DHCP relay agent function
The vRouter also provides the DHCP relay agent function.
Flow Filter Functions

Flow Filter function is similar to ACL. It is possible to allow or prohibit communication
with only certain kind of packets that meet a particular condition. Also, it can perform a
processing called Redirection - WayPoint routing, which is different from the existing ACL.
Flow Filter can be applied to any interface of a vNode within VTN, and it is possible to the
control the packets that pass interface. The match conditions that could be specified in
Flow Filter are as follows. It is also possible to specify a combination of multiple conditions.
• Source MAC address
• Destination MAC address
• MAC ether type
295
• VLAN Priority
• Source IP address
• Destination IP address
• DSCP
• IP Protocol
• TCP/UDP source port
• TCP/UDP destination port
• ICMP type
• ICMP code
The types of Action that can be applied on packets that match the Flow Filter conditions
are given in the following table. It is possible to make only those packets, which match
a particular condition, to pass through a particular server by specifying Redirection in
Action. E.g., path of flow can be changed for each packet sent from a particular terminal,
depending upon the destination IP address. VLAN priority control and DSCP marking are
also supported.
Pass Pass particular packets matching the specified conditions.

Drop Discards particular packets matching the specified
conditions.
Redirection Redirects the packet to a desired virtual interface. Both
Transparent Redirection (not changing MAC address)
and Router Redirection (changing MAC address) are
supported.
The following figure shows an example of how the flow filter function works.
If there is any matching condition specified by flow filter when a packet being transferred
within a virtual network goes through a virtual interface, the function evaluates the
matching condition to see whether the packet matches it. If the packet matches the
condition, the function applies the matching action specified by flow filter. In the example
shown in the figure, the function evaluates the matching condition at BR1 and discards the
packet if it matches the condition.
296
Figure 33.4. VTN FlowFilter
Multiple SDN Controller Coordination

With the network abstractions, VTN enables to configure virtual network across multiple
SDN controllers. This provides highly scalable network system.
VTN can be created on each SDN controller. If users would like to manage those multiple
VTNs with one policy, those VTNs can be integrated to a single VTN.
As a use case, this feature is deployed to multi data center environment. Even if those data
centers are geographically separated and controlled with different controllers, a single
policy virtual network can be realized with VTN.
Also, one can easily add a new SDN Controller to an existing VTN or delete a particular SDN
Controller from VTN.
In addition to this, one can define a VTN which covers both OpenFlow network and
Overlay network at the same time.
Flow Filter, which is set on the VTN, will be automatically applied on the newly added SDN
Controller.
Coordination between OpenFlow Network and L2/L3

Network
It is possible to configure VTN on an environment where there is mix of L2/L3 switches
as well. L2/L3 switch will be shown on VTN as vBypass. Flow Filter or policing cannot be
configured for a vBypass. However, it is possible to treat it as a virtual node inside VTN.
297
Virtual Tenant Network (VTN) API

VTN provides Web APIs. They are implemented by REST architecture and provide the access
to resources within VTN that are identified by URI. User can perform the operations like
GET/PUT/POST/DELETE against the virtual network resources (e.g. vBridge or vRouter) by
sending a message to VTN through HTTPS communication in XML or JSON format.
Figure 33.5. VTN API
Function Outline
VTN provides following operations for various network resources.
Resources GET POST PUT DELETE

VTN Yes Yes Yes Yes
vBridge Yes Yes Yes Yes
vRouter Yes Yes Yes Yes
vTep Yes Yes Yes Yes
vTunnel Yes Yes Yes Yes
vBypass Yes Yes Yes Yes
vLink Yes Yes Yes Yes
Interface Yes Yes Yes Yes
Port map Yes No Yes Yes
Vlan map Yes Yes Yes Yes
Flowfilter (ACL/ Yes Yes Yes Yes
redirect)
Controller information Yes Yes Yes Yes
Physical topology Yes No No No
information
Alarm information Yes No No No
Example usage
The following is an example of the usage to construct a virtual network.
• Create VTN
curl --user admin:adminpass -X POST -H 'content-type: application/json' \
298
-d '{"vtn":{"vtn_name":"VTN1"}}' http://172.1.0.1:8083/vtn-webapi/vtns.json
• Create Controller Information

-d '{"controller": {"controller_id":"CONTROLLER1","ipaddr":"172.1.0.1",
"type":"odc","username":"admin", \
"password":"admin","version":"1.0"}}' http://172.1.0.1:8083/vtn-webapi/
controllers.json
• Create vBridge under VTN

-d '{"vbridge":{"vbr_name":"VBR1","controller_id": "CONTROLLER1",
"domain_id": "(DEFAULT)"}}' \
http://172.1.0.1:8083/vtn-webapi/vtns/VTN1/vbridges.json
• Create the interface under vBridge

-d '{"interface":{"if_name":"IF1"}}' http://172.1.0.1:8083/vtn-webapi/vtns/
VTN1/vbridges/VBR1/interfaces.json
VTN OpenStack Configuration

This guide describes how to set up OpenStack for integration with OpenDaylight
Controller.
While OpenDaylight Controller provides several ways to integrate with OpenStack, this
guide focus on the way which uses VTN features available on OpenDaylight controller.In
the integration, VTN Manager work as network service provider for OpenStack.
VTN Manager features, enable OpenStack to work in pure OpenFlow environment in which
all switches in data plane are OpenFlow switch.
Requirements
To use OpenDaylight as Network Service Provider for OpenStack.
Components
• OpenDaylight Controller.
• OpenStack Control Node.
• OpenStack Compute Node.
• OpenFlow Switch like mininet(Not Mandatory).
The VTN features support multiple OpenStack nodes. You can deploy multiple OpenStack
Compute Nodes. In management plane, OpenDaylight Controller, OpenStack nodes and
OpenFlow switches should communicate with each other. In data plane, Open vSwitches
299
running in OpenStack nodes should communicate with each other through a physical or
logical OpenFlow switches. The core OpenFlow switches are not mandatory. Therefore, you
can directly connect to the Open vSwitch’s.
Figure 33.6. LAB Setup
Note
Ubuntu 14.04 was used in both the nodes and Vsphere was used for this
howto.
Configuration
Server Preparation
• Install Ubuntu 14.04 LTS in two servers (OpenStack Control node and Compute node
respectively)
• While installing, Ubuntu mandates creation of a User, we created the user "stack"(We
will use the same user for running devstack) NOTE: You can also have multiple Compute
nodes. TIP: Please do minimal Install to avoid any issues in devstack bringup
User Settings - Login to both servers - Disable Ubuntu Firewall

sudo ufw disable
300
• Optionally install these packages
sudo apt-get install net-tools
• Edit sudo vim /etc/sudoers and add an entry as follows
stack ALL=(ALL) NOPASSWD: ALL
Network Settings - Checked the output of ifconfig -a, two interfaces were listed eth0
and eth1 as indicated in the image above. - We had connected eth0 interface to the
Network where OpenDaylight is reachable. - eth1 interface in both servers were connected
to a different network to act as data plane for the VM’s created using the OpenStack. -
Manually edited the file : sudo vim /etc/network/interfaces and made entries as follows
stack@ubuntu-devstack:~/devstack$ cat /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loop-back network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address <IP_ADDRESS_TO_REACH_ODL>
netmask <NET_MASK>
broadcast <BROADCAST_IP_ADDRESS>
gateway <GATEWAY_IP_ADDRESS>
auto eth1
iface eth1 inet static
address <IP_ADDRESS_UNIQ>
netmask <NETMASK>
Note
Please ensure that the eth0 interface is the default route and it is able to reach
the ODL_IP_ADDRESS NOTE: The entries for eth1 are not mandatory, If not
set, we may have to manually do "ifup eth1" after the stacking is complete to
activate the interface
Finalize - reboot both nodes after the user and network settings to have the network
settings applied to the network - Login again and check the output of ifconfig to ensure
that both interfaces are listed
OpenDaylight Settings and Execution

vtn.ini
• VTN uses the configuration parameters from vtn.ini file for the OpenStack integration.
• These values will be set for the OpenvSwitch, in all the participating OpenStack nodes.
• A configuration file vtn.ini'' needs to be created manually in the 'configuration directory.
• The contents of vtn.ini should be as follows:
301
bridgename=br-int portname=eth1 protocols=OpenFlow13 failmode=secure
• The values of the configuration parameters must be changed based on the user
environment.
• Especially, "portname" should be carefully configured, because if the value is wrong,

OpenDaylight controller fails to forward packets.
• Other parameters works fine as is for general use cases.
• bridgename
• The name of the bridge in Open vSwitch, that will be created by OpenDaylight
Controller.
• It must be "br-int".
• portname
• The name of the port that will be created in the vbridge in Open vSwitch.
• This must be the same name of the interface of OpenStack Nodes which is used for
interconnecting OpenStack Nodes in data plane.(in our case:eth1)
• By default, if vtn.ini is not created, VTN uses ens33 as portname.
• protocols
• OpenFlow protocol through which OpenFlow Switch and Controller communicate.
• The values can be OpenFlow13 or OpenFlow10.
• failmode
• The value can be "standalone" or "secure".
• Please use "secure" for general use cases.
Start OpenDaylight
• Please install the feature odl-vtn-manager-neutron that provides the integration with
Neutron interface.
feature:install odl-vtn-manager-neutron
Tip
After running OpenDaylight, please ensure OpenDaylight listens to the
ports:6633,6653, 6640 and 8080
Tip
Please allow the ports in firewall for the devstack to be able to communicate
with OpenDaylight.
302
Note
* 6633/6653 - OpenFlow Ports * 6640 - Open vSwitch Manager Port * 8282 -
Port for REST API
Devstack Setup
VTN Devstack Script
• The local.conf is a user-maintained settings file. This allows all custom settings for
DevStack to be contained in a single file. This file is processed strictly in sequence. The
following datas are needed to be set in the local.conf file:
• Set the Host_IP as the detection is unreliable.
• Set FLOATING_RANGE to a range not used on the local network, i.e. 192.168.1.224/27.
This configures IP addresses ending in 225-254 to be used as floating IPs.
• Set FLAT_INTERFACE to the Ethernet interface that connects the host to your local
network. This is the interface that should be configured with the static IP address
mentioned above.
• If the *_PASSWORD variables are not set, we will be prompted to enter values during the
execution of stack.sh.
• Set ADMIN_PASSWORD . This password is used for the admin and demo accounts set up
as OpenStack users. We can login to the OpenStack GUI with this credentials only.
• Set the MYSQL_PASSWORD. The default here is a random hex string which is
inconvenient if you need to look at the database directly for anything.
• Set the RABBIT_PASSWORD. This is used by messaging services used by both the nodes.
• Set the service password. This is used by the OpenStack services (Nova, Glance, etc) to
authenticate with Keystone.
DevStack Control
local.conf(control)
#IP Details
HOST_IP=<CONTROL_NODE_MANAGEMENT_IF_IP_ADDRESS>#Please Add The Control Node IP
Address in this line
FLAT_INTERFACE=<FLAT_INTERFACE_NAME>
SERVICE_HOST=$HOST_IP
#Instance Details
MULTI_HOST=1
#config Details
RECLONE=yes #Make it "no" after stacking successfully the first time
VERBOSE=True
LOG_COLOR=True
LOGFILE=/opt/stack/logs/stack.sh.log
SCREEN_LOGDIR=/opt/stack/logs
#OFFLINE=True #Uncomment this after stacking successfully the first time
303
#Passwords
ADMIN_PASSWORD=labstack
MYSQL_PASSWORD=supersecret
RABBIT_PASSWORD=supersecret
SERVICE_PASSWORD=supersecret
SERVICE_TOKEN=supersecrettoken
ENABLE_TENANT_TUNNELS=false
#Services
disable_service rabbit
enable_service qpid
enable_service quantum
enable_service n-cpu
enable_service n-cond
disable_service n-net
enable_service q-svc
enable_service q-dhcp
enable_service q-meta
enable_service horizon
enable_service quantum
enable_service tempest
ENABLED_SERVICES+=,n-api,n-crt,n-obj,n-cpu,n-cond,n-sch,n-novnc,n-cauth,n-
cauth,nova
ENABLED_SERVICES+=,cinder,c-api,c-vol,c-sch,c-bak
#ML2 Details
Q_PLUGIN=ml2
Q_ML2_PLUGIN_MECHANISM_DRIVERS=opendaylight
Q_ML2_TENANT_NETWORK_TYPE=local
Q_ML2_PLUGIN_TYPE_DRIVERS=local
enable_service neutron
enable_service odl-compute
ODL_MGR_IP=<ODL_IP_ADDRESS> #Please Add the ODL IP Address in this line
OVS_PHYSICAL_BRIDGE=br-int
Q_OVS_USE_VETH=True
url=http://<ODL_IP_ADDRESS>:8080/controller/nb/v2/neutron #Please Add the ODL
IP Address in this line
username=admin
password=admin
DevStack Compute
local.conf(compute)
#IP Details
HOST_IP=<COMPUTE_NODE_MANAGEMENT_IP_ADDRESS> #Add the Compute node Management
IP Address
SERVICE_HOST=<CONTROLLEr_NODE_MANAGEMENT_IP_ADDRESS> #Add the cotnrol Node
Management IP Address here
#Instance Details
MULTI_HOST=1
#config Details
RECLONE=yes #Make thgis "no" after stacking successfully once
#OFFLINE=True #Uncomment this line after stacking successfuly first time.
VERBOSE=True
LOG_COLOR=True
LOGFILE=/opt/stack/logs/stack.sh.log
SCREEN_LOGDIR=/opt/stack/logs
304
#Passwords
#Services
ENABLED_SERVICES=n-cpu,rabbit,neutron
#ML2 Details
Q_PLUGIN=ml2
Q_ML2_PLUGIN_MECHANISM_DRIVERS=opendaylight
Q_ML2_PLUGIN_TYPE_DRIVERS=local
enable_service odl-compute
ODL_MGR_IP=<ODL_IP_ADDRESS> #ADD ODL IP address here
ENABLE_TENANT_TUNNELS=false
Q_OVS_USE_VETH=True
#Details of the Control node for various services
[[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]]
Q_HOST=$SERVICE_HOST
MYSQL_HOST=$SERVICE_HOST
RABBIT_HOST=$SERVICE_HOST
GLANCE_HOSTPORT=$SERVICE_HOST:9292
KEYSTONE_AUTH_HOST=$SERVICE_HOST
KEYSTONE_SERVICE_HOST=$SERVICE_HOST
NOVA_VNC_ENABLED=True
NOVNCPROXY_URL="http://<CONTROLLER_NODE_IP_ADDRESS>:6080/vnc_auto.html" #Add
Controller Node IP address
VNCSERVER_LISTEN=$HOST_IP
VNCSERVER_PROXYCLIENT_ADDRESS=$VNCSERVER_LISTEN
Devstack Kilo_Liberty Control Node

#IP Details
HOST_IP=<CONTROL_NODE_MANAGEMENT_IF_IP_ADDRESS> #Please Add The Control Node
IP Address in this line
SERVICE_HOST=$HOST_IP
LOGFILE=stack.sh.log
SCREEN_LOGDIR=/opt/stack/data/log
LOG_COLOR=False
enable_service q-agt
disable_service q-l3
enable_service n-cauth
enable_service neutron
enable_service tempest
ENABLE_TENANT_TUNNELS=True
NEUTRON_CREATE_INITIAL_NETWORKS=False
#enable_plugin networking-odl http://git.openstack.org/openstack/networking-
odl stable/kilo # Please uncomment this line if you
305
want to use stable/kilo branch

odl stable/liberty # Please uncomment this line if you
want to use stable/liberty branch
ODL_MODE=externalodl
ODL_MGR_IP=<ODL_IP_ADDRESS> # Please Add the ODL IP Address in this line
ODL_PORT=8080
ODL_USERNAME=admin
ODL_PASSWORD=admin
Q_OVS_USE_VETH=True
VNCSERVER_PROXYCLIENT_ADDRESS=$SERVICE_HOST
VNCSERVER_LISTEN=0.0.0.0
[agent]
minimize_polling=True
Devstack Kilo_Liberty Compute Node

#IP Details
HOST_IP=<COMPUTE_NODE_IP_ADDRESS>
SERVICE_HOST=<CONTROL_NODE_IP_ADDRESS>
LOGFILE=stack.sh.log
SCREEN_LOGDIR=/opt/stack/data/log
LOG_COLOR=False
RECLONE=yes # Make it "no" after stacking successfully the first time
#OFFLINE=True # Uncomment this after stacking successfully the first time
disable_all_services
NOVA_VNC_ENABLED=True
ENABLE_TENANT_TUNNELS=True
NEUTRON_CREATE_INITIAL_NETWORKS=False
odl stable/kilo # Please uncomment this line if you
want to use stable/kilo branch
odl stable/liberty # Please uncomment this line if you
want to use stable/liberty branch
ODL_MODE=compute
ODL_MGR_IP=<ODL_IP_ADDRESS> # Please Add the ODL IP Address in this line
ODL_PORT=8080
ODL_USERNAME=admin
ODL_PASSWORD=admin
VNCSERVER_PROXYCLIENT_ADDRESS=$HOST_IP
VNCSERVER_LISTEN=0.0.0.0
306
[agent]
minimize_polling=True
Note
We have to comment OFFLINE=TRUE in local.conf files, this will make all the
installations to happen automatically. RECLONE=yes only when we set up the
DevStack environment from scratch.
Get Devstack (All nodes)

• Install git application using
• sudo apt-get install git
• Get devstack
• git clone https://git.openstack.org/openstack-dev/devstack;
• Switch to stable/Juno Version branch
• cd devstack
• git checkout stable/juno
Note
If you want to use stable/kilo Version branch, Please execute the below
command in devstack folder
git checkout stable/kilo
Note
If you want to use stable/liberty Version branch, Please execute the below
command in devstack folder
git checkout stable/liberty
Stack Control Node

local.conf: DevStack Control.
cd devstack in the controller node
• Copy the contents of local.conf for juno (devstack control node) from DevStack Control
and save it as "local.conf" in the "devstack".
• Copy the contents of local.conf for kilo and liberty (devstack control node) from
Devstack Kilo_Liberty Control Node and save it as "local.conf" in the "devstack".
307
• Please modify the IP Address values as required.
• Stack the node

./stack.sh
Verify Control Node stacking
• stack.sh prints out Horizon is now available at http://

<CONTROL_NODE_IP_ADDRESS>:8080/
• Execute the command sudo ovs-vsctl show in the control node terminal and verify if the
bridge br-int is created.
Stack Compute Node

local.conf: DevStack Compute.
cd devstack in the controller node
• Copy the contents of local.conf for juno (devstack compute node) from DevStack
Compute and save it as "local.conf" in the "devstack".
• Copy the contents of local.conf file for kilo and liberty (devstack compute node) from
Devstack Kilo_Liberty Compute Node and save it as "local.conf" in the "devstack".
• Please modify the IP Address values as required.
• Stack the node

./stack.sh
Verify Compute Node Stacking
• stack.sh prints out This is your host ip: <COMPUTE_NODE_IP_ADDRESS>
• Execute the command sudo ovs-vsctl show in the control node terminal and verify if the
bridge br-int is created.
• The output of the ovs-vsctl show will be similar to the one seen in control node.
Additional Verifications
• Please visit the OpenDaylight DLUX GUI after stacking all the nodes, http://
<ODL_IP_ADDRESS>:8181/dlux/index.html. The switches, topology and the ports that
are currently read can be validated.
Tip
If the interconnected between the Open vSwitch is not seen, Please bring up
the interface for the dataplane manually using the below comamnd
ifup <interface_name>
308
Tip
Some versions of Open vSwitch, drop packets when there is a table-miss, So
please add the below flow to all the nodes with Open vSwitch version (>=2.1)
ovs-ofctl --protocols=OpenFlow13 add-flow br-int

priority=0,actions=output:CONTROLLER
Tip
Please Accept Promiscuous mode in the networks involving the interconnect.
Create VM from Devstack Horizon GUI

• Login to http://<CONTROL_NODE_IP>:8080/ to check the horizon GUI.
Figure 33.7. Horizon GUI
Enter the value for User Name as admin and enter the value for Password as labstack.
309
• We should first ensure both the hypervisors(control node and compute node) are
mapped under hypervisors by clicking on Hpervisors tab.
Figure 33.8. Hypervisors
• Create a new Network from Horizon GUI.
• Click on Networks Tab.
• click on the Create Network button.
310
Figure 33.9. Create Network
• A popup screen will appear.
• Enter network name and click Next button.
311
Figure 33.10. Step 1
• Create a sub network by giving Network Address and click Next button .
312
• Specify the additional details for subnetwork (please refer the image for your reference).
313
• Click Create button
• Create VM Instance
• Navigate to Instances tab in the GUI.
314
Figure 33.13. Instance Creation
• Click on Launch Instances button.
315
Figure 33.14. Launch Instance
• Click on Details tab to enter the VM details.For this demo we are creating Ten
VM’s(instances).
• In the Networking tab, we must select the network,for this we need to drag and drop
the Available networks to Selected Networks (i.e.,) Drag vtn1 we created from Available
networks to Selected Networks and click Launch to create the instances.
316
Figure 33.15. Launch Network
• Ten VM’s will be created.
317
Figure 33.16. Load All Instances
• Click on any VM displayed in the Instances tab and click the Console tab.
318
Figure 33.17. Instance Console
• Login to the VM console and verify with a ping command.
319
Figure 33.18. Ping
Verification of Control and Compute Node after VM creation

• Every time a new VM is created, more interfaces are added to the br-int bridge in Open
vSwitch.
• Use sudo ovs-vsctl show to list the number of interfaces added.
• Please visit the DLUX GUI to list the new nodes in every switch.
Using the DLUX GUI

For more information see the chapter on DLUX above.
References
• http://devstack.org/guides/multinode-lab.html
• https://wiki.opendaylight.org/view/File:Vtn_demo_hackfest_2014_march.pdf
320
VTN Usage Examples

How to configure L2 Network with Single Controller
Overview
This example provides the procedure to demonstrate configuration of VTN Coordinator
with L2 network using VTN Virtualization(single controller). Here is the Example
for vBridge Interface Mapping with Single Controller using mininet. mininet details
and set-up can be referred at below URL: https://wiki.opendaylight.org/view/
OpenDaylight_Controller:Installation#Using_Mininet
Figure 33.19. EXAMPLE DEMONSTRATING SINGLE CONTROLLER
Requirements
mininet@mininet-vm:~$ sudo mn --controller=remote,ip=<controller-ip> --topo

tree,2
• mininet> net
s1 lo: s1-eth1:h1-eth0 s1-eth2:s2-eth1

s2 lo: s2-eth1:s1-eth2 s2-eth2:h2-eth0
h1 h1-eth0:s1-eth1
h2 h2-eth0:s2-eth2
Configuration
• Create a Controller
curl --user admin:adminpass -H 'content-type: application/json' -X POST -

d '{"controller": {"controller_id": "controllerone", "ipaddr":"10.0.0.2",
"type": "odc", "version": "1.0", "auditstatus":"enable"}}' http://127.0.0.
1:8083/vtn-webapi/controllers.json
321
• Create a VTN
curl --user admin:adminpass -H 'content-type: application/json' -X POST -d

'{"vtn" : {"vtn_name":"vtn1","description":"test VTN" }}' http://127.0.0.
1:8083/vtn-webapi/vtns.json
• Create a vBridge in the VTN
curl --user admin:adminpass -H 'content-type: application/json' -X POST

-d '{"vbridge" : {"vbr_name":"vBridge1","controller_id":"controllerone",
"domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/
vbridges.json
• Create two Interfaces into the vBridge

'{"interface": {"if_name": "if1","description": "if_desc1"}}' http://127.0.0.
1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces.json

• Get the list of logical ports configured
Curl --user admin:adminpass -H 'content-type: application/json' -X GET http:/

/127.0.0.1:8083/vtn-webapi/controllers/controllerone/domains/$DEFAULT$/
logical_ports.json
• Configure two mappings on the interfaces
curl --user admin:adminpass -H 'content-type: application/json' -X PUT -d

'{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:03-s3-eth1"}}'
http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces/if1/
portmap.json
portmap.json
Verification
Please verify whether the Host1 and Host3 are pinging. * Send packets from Host1 to Host3
|mininet> h1 ping h3
How to configure L2 Network with Multiple Controllers

• This example provides the procedure to demonstrate configuration of VTN Coordinator
with L2 network using VTN Virtualization Here is the Example for vBridge Interface
Mapping with Multi-controller using mininet.
322
Figure 33.20. EXAMPLE DEMONSTRATING MULTIPLE CONTROLLERS
Requirements
• Configure multiple controllers using the mininet script given below: https://
wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN
%29:Scripts:Mininet#Network_with_Multiple_Paths_for_delivering_packets
Configuration
• Create a VTN

'{"vtn" : {"vtn_name":"vtn3"}}' http://127.0.0.1:8083/vtn-webapi/vtns.json
• Create two Controllers

'{"controller": {"controller_id": "odc1", "ipaddr":"10.100.9.52", "type":
"odc", "version": "1.0", "auditstatus":"enable"}}' http://127.0.0.1:8083/vtn-
webapi/controllers.json

'{"controller": {"controller_id": "odc2", "ipaddr":"10.100.9.61", "type":
• Create two vBridges in the VTN like, vBridge1 in Controller1 and vBridge2 in Controller2
curl --user admin:adminpass -H 'content-type: application/json' -

X POST -d '{"vbridge" : {"vbr_name":"vbr1","controller_id":"odc1",
vbridges.json
323
curl --user admin:adminpass -H 'content-type: application/json' -

X POST -d '{"vbridge" : {"vbr_name":"vbr2","controller_id":"odc2",
vbridges.json
• Create vBridge Interfaces

'{"interface": {"if_name": "if1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/
vtn3/vbridges/vbr1/interfaces.json



• Get the list of logical ports configured

curl --user admin:adminpass -H 'content-type: application/json' -X GET http:/
/127.0.0.1:8083/vtn-webapi/controllers/odc1/domains/$DEFAULT$/logical_ports/
detail.json
• Create boundary and vLink

curl --user admin:adminpass -H 'content-type: application/json' -X
POST -d '{"boundary": {"boundary_id": "b1", "link": {"controller1_id":
"odc1", "domain1_id": "(DEFAULT)", "logical_port1_id": "PP-
OF:00:00:00:00:00:00:00:01-s1-eth3", "controller2_id": "odc2", "domain2_id":
"(DEFAULT)", "logical_port2_id": "PP-OF:00:00:00:00:00:00:00:04-s4-eth3"}}}'
http://127.0.0.1:8083/vtn-webapi/boundaries.json

POST -d '{"vlink": {"vlk_name": "vlink1" , "vnode1_name": "vbr1",
"if1_name":"if2", "vnode2_name": "vbr2", "if2_name": "if2", "boundary_map":
{"boundary_id":"b1","vlan_id": "50"}}}' http://127.0.0.1:8083/vtn-webapi/
vtns/vtn3/vlinks.json
• Configure port-map on the interfaces

http://127.0.0.1:8083/vtn-webapi/vtns/vtn3/vbridges/vbr1/interfaces/if1/
portmap.json

http://127.0.0.1:8083/vtn-webapi/vtns/vtn3/vbridges/vbr2/interfaces/if1/
portmap.json
Verification
Please verify whether Host h2 and Host h6 are pinging. * Send packets from h2 to h6
mininet> h2 ping h6
324
How To Test Vlan-Map In Mininet Environment

Overview
This example explains how to test vlan-map in a multi host scenario.
Figure 33.21. Example that demonstrates vlanmap testing in Mininet

Environment
Requirements
• Save the mininet script given below as vlan_vtn_test.py and run the mininet script in the
mininet environment where Mininet is installed.
Mininet Script
https://wiki.opendaylight.org/view/
OpenDaylight_Virtual_Tenant_Network_(VTN):Scripts:Mininet#Network_with_hosts_in_different_vlan
• Run the mininet script
sudo mn --controller=remote,ip=192.168.64.13 --custom vlan_vtn_test.py --topo

mytopo
Configuration
Please follow the below steps to test a vlan map using mininet: * Create a controller
1:8083/vtn-webapi/controllers
• Create a VTN
325
curl -X POST -H 'content-type: application/json' -H 'username: admin' -H

'password: adminpass' -d '{"vtn" : {"vtn_name":"vtn1","description":"test
VTN" }}' http://127.0.0.1:8083/vtn-webapi/vtns.json
• Create a vBridge(vBridge1)
curl -X POST -H 'content-type: application/json' -H 'username: admin'

-H 'password: adminpass' -d '{"vbridge" : {"vbr_name":"vBridge1",
"controller_id":"controllerone","domain_id":"(DEFAULT)" }}' http://127.0.0.
1:8083/vtn-webapi/vtns/vtn1/vbridges.json
• Create a vlan map with vlanid 200 for vBridge vBridge1

'password: adminpass' -d '{"vlanmap" : {"vlan_id": 200 }}' http://127.0.0.
1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/vlanmaps.json
• Create a vBridge (vBridge2)
curl -X POST -H 'content-type: application/json' -H 'username: admin'

-H 'password: adminpass' -d '{"vbridge" : {"vbr_name":"vBridge2",
"controller_id":"controllerone","domain_id":"(DEFAULT)" }}' http://127.0.0.
1:8083/vtn-webapi/vtns/vtn1/vbridges.json
• Create a vlan map with vlanid 300 for vBridge vBridge2

'password: adminpass' -d '{"vlanmap" : {"vlan_id": 300 }}' http://127.0.0.
1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge2/vlanmaps.json
Verification
Ping all in mininet environment to view the host reachability.
mininet> pingall
h1 -> X h3 X h5 X
h2 -> X X h4 X h6
h3 -> h1 X X h5 X
h4 -> X h2 X X h6
h5 -> h1 X h3 X X
h6 -> X h2 X h4 X
How To View Specific VTN Station Information.

This example demonstrates on how to view a specific VTN Station information.
326
Figure 33.22. EXAMPLE DEMONSTRATING VTN STATIONS
Requirement
$ sudo mn --custom /home/mininet/mininet/custom/topo-2sw-2host.py --

controller=remote,ip=10.100.9.61 --topo mytopo
mininet> net
s1 lo: s1-eth1:h1-eth0 s1-eth2:s2-eth1

s2 lo: s2-eth1:s1-eth2 s2-eth2:h2-eth0
h1 h1-eth0:s1-eth1
h2 h2-eth0:s2-eth2
• Generate traffic by pinging between hosts h1 and h2 after configuring the portmaps
respectively
mininet> h1 ping h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_req=1 ttl=64 time=16.7 ms
Configuration
Create Controller.
curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -
1:8083/vtn-webapi/controllers.json
Create a VTN.
curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -
d '{"vtn" : {"vtn_name":"vtn1","description":"test VTN" }}' http://127.0.0.
327
Create a vBridge in the VTN.
curl -v --user admin:adminpass -H 'content-type: application/json' -X POST

-d '{"vbridge" : {"vbr_name":"vBridge1","controller_id":"controllerone",
vbridges.json
Create two Interfaces into the vBridge.
curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d

Configure two mappings on the interfaces.
curl -v --user admin:adminpass -H 'content-type: application/json' -X PUT -d

portmap.json
portmap.json
Get the VTN stations information.
curl -v -X GET -H 'content-type: application/json' -H 'username: admin'

-H 'password: adminpass' "http://127.0.0.1:8083/vtn-webapi/vtnstations?
controller_id=controllerone&vtn_name=vtn1"
Verification
curl -v -X GET -H 'content-type: application/json' -H 'username: admin'
-H 'password: adminpass' "http://127.0.0.1:8083/vtn-webapi/vtnstations?
controller_id=controllerone&vtn_name=vtn1"
{
"vtnstations": [
{
"domain_id": "(DEFAULT)",
"interface": {},
"ipaddrs": [
"10.0.0.2"
],
"macaddr": "b2c3.06b8.2dac",
"no_vlan_id": "true",
"port_name": "s2-eth2",
"station_id": "178195618445172",
"switch_id": "00:00:00:00:00:00:00:02",
"vnode_name": "vBridge1",
"vnode_type": "vbridge",
"vtn_name": "vtn1"
},
{
"domain_id": "(DEFAULT)",
"interface": {},
"ipaddrs": [
328
"10.0.0.1"
],
"macaddr": "ce82.1b08.90cf",
"no_vlan_id": "true",
"port_name": "s1-eth1",
"station_id": "206130278144207",
"switch_id": "00:00:00:00:00:00:00:01",
"vnode_name": "vBridge1",
"vnode_type": "vbridge",
"vtn_name": "vtn1"
}
]
}
How To View Dataflows in VTN

This example demonstrates on how to view a specific VTN Dataflow information.
Configuration
The same Configuration as Vlan Mapping Example(https://wiki.opendaylight.org/view/
OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Coordinator:RestApi:How_to_test_vlan-
map_in_Mininet_environment)
Verification
Get the VTN Dataflows information
curl -v -X GET -H 'content-type: application/json' --user 'admin:adminpass'

"http://127.0.0.1:8083/vtn-webapi/dataflows?controller_id=controllerone&
srcmacaddr=924c.e4a3.a743&vlan_id=300&switch_id=00:00:00:00:00:00:00:02&
port_name=s2-eth1"
{
"dataflows": [
{
"controller_dataflows": [
{
"controller_id": "controllerone",
"controller_type": "odc",
"egress_domain_id": "(DEFAULT)",
"egress_port_name": "s3-eth3",
"egress_station_id": "3",
"egress_switch_id": "00:00:00:00:00:00:00:03",
"flow_id": "29",
"ingress_domain_id": "(DEFAULT)",
"ingress_port_name": "s2-eth2",
"ingress_station_id": "2",
"ingress_switch_id": "00:00:00:00:00:00:00:02",
"match": {
"macdstaddr": [
"4298.0959.0e0b"
],
"macsrcaddr": [
"924c.e4a3.a743"
],
"vlan_id": [
329
"300"
]
},
"pathinfos": [
{
"in_port_name": "s2-eth2",
"out_port_name": "s2-eth1",
"switch_id": "00:00:00:00:00:00:00:02"
},
{
"switch_id": "00:00:00:00:00:00:00:01"
},
{
"switch_id": "00:00:00:00:00:00:00:03"
}
]
}
],
"reason": "success"
}
]
}
How To Configure Flow Filters Using VTN

Overview
The flow-filter function discards, permits, or redirects packets of the traffic within a VTN,
according to specified flow conditions The table below lists the actions to be applied when
a packet matches the condition:
Action Function
Pass Permits the packet to pass. As options, packet transfer
priority (set priority) and DSCP change (se t ip-dscp) is
specified.
Drop Discards the packet.
Redirect Redirects the packet to a desired virtual interface. As an
option, it is possible to change the MAC address when the
packet is transferred.
330
Figure 33.23. Flow Filter
Following steps explain flow-filter function:
• When a packet is transferred to an interface within a virtual network, the flow-filter

function evaluates whether the transferred packet matches the condition specified in the
flow-list.
• If the packet matches the condition, the flow-filter applies the flow-list matching action
specified in the flow-filter.
Requirements
To apply the packet filter, configure the following:
• Create a flow-list and flow-listentry.
• Specify where to apply the flow-filter, for example VTN, vBridge, or interface of vBridge.
Configure mininet and create a topology:

$ mininet@mininet-vm:~$ sudo mn --controller=remote,ip=<controller-ip> --topo
tree
Please generate the following topology

$ mininet@mininet-vm:~$ sudo mn --controller=remote,ip=<controller-ip> --topo
tree,2
mininet> net
c0
h1 h1-eth0:s2-eth1
h2 h2-eth0:s2-eth2
h3 h3-eth0:s3-eth1
331
h4 h4-eth0:s3-eth2
Configuration
• .Create a controller

-d '{"controller": {"controller_id": "controller1", "ipaddr":"10.100.9.61",
1:8083/vtn-webapi/controllers
• Create a VTN

'{"vtn" : {"vtn_name":"vtn_one","description":"test VTN" }}' http://127.0.0.
• Create two vBridges

-d '{"vbridge" : {"vbr_name":"vbr_one^C"controller_id":"controller1",
"domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/
vbridges.json
'{"vbridge" :
{"vbr_name":"vbr_two","controller_id":"controller1",
"domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/
vbridges.json
• Create vBridge interfaces

1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces.json
1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces.json

http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/
if1/portmap.json
http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/
if2/portmap.json
• Create Flowlist

'{"flowlist": {"fl_name": "flowlist1", "ip_version":"IP"}}' http://127.0.0.
1:8083/vtn-webapi/flowlists.json
• Create Flowlistentry
curl -v --user admin:adminpass -H 'content-type: application/json' -X

POST -d '{"flowlistentry": {"seqnum": "233","macethertype": "0x8000",
332
"ipdstaddr": "10.0.0.3","ipdstaddrprefix": "2","ipsrcaddr": "10.0.0.2",

"ipsrcaddrprefix": "2","ipproto": "17","ipdscp": "55","icmptypenum":"232",
"icmpcodenum": "232"}}' http://127.0.0.1:8083/vtn-webapi/flowlists/flowlist1/
flowlistentries.json
• Create vBridge Interface Flowfilter
curl -v --user admin:adminpass -X POST -H 'content-type: application/json' -d

'{"flowfilter" : {"ff_type": "in"}}' http://127.0.0.1:8083/vtn-webapi/vtns/
vtn_one/vbridges/vbr_two/interfaces/if1/flowfilters.json
Flow filter demonstration with DROP action-type

curl -v --user admin:adminpass -X POST -H 'content-type: application/
json' -d '{"flowfilterentry": {"seqnum": "233", "fl_name": "flowlist1",
"action_type":"drop", "priority":"3", "dscp":"55" }}' http://127.0.0.1:8083/
vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if1/flowfilters/in/
flowfilterentries.json
Verification
As we have applied the action type "drop" , ping should fail.
mininet> h1 ping h3
From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
In controller you can see the DROP action type information as below, here action as DROP.
osgi> readflows 0000000000000003
[FlowOnNode[flow =Flow[match = Match [fields={DL_VLAN=DL_VLAN(0), IN_PORT=
IN_PORT(OF|1@OF|00:00:00:00:00:00:00:03), DL_DST=DL_DST(4e:08:1d:a6:05:08),
DL_SRC=DL_SRC(be:15:00:a4:96:13)}, matches=15], actions = [DROP],
priority = 10, id = 0, idleTimeout = 0, hardTimeout = 300], tableId =
0, sec = 18, nsec = 475000000, pkt = 20, byte = 1232], FlowOnNode[flow
=Flow[match = Match [fields={DL_VLAN=DL_VLAN(0), IN_PORT=IN_PORT(OF|
3@OF|00:00:00:00:00:00:00:03), DL_DST=DL_DST(be:15:00:a4:96:13), DL_SRC=
DL_SRC(4e:08:1d:a6:05:08)}, matches=15], actions = [OUTPUT[OF|1@OF|
00:00:00:00:00:00:00:03]], priority = 10, id = 0, idleTimeout = 0, hardTimeout
= 0], tableId = 0, sec = 18, nsec = 489000000, pkt = 10, byte = 812]]
Flow filter demonstration with PASS action-type

curl -v --user admin:adminpass -X PUT -H 'content-type: application/
json' -d '{"flowfilterentry": {"seqnum": "233", "fl_name": "flowlist1",
"action_type":"pass", "priority":"3", "dscp":"55" }}' http://127.0.0.1:8083/
vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if1/flowfilters/in/
flowfilterentries/233.json
Verification
mininet> h1 ping h3
333
In controller you can see the PASS action type information by executing the following
command:
osgi> readflows 0000000000000003
How To Use VTN To Make Packets Take Different Paths

This example demonstrates on how to create a specific VTN Path Map information.
Figure 33.24. PathMap
Requirement
• Save the mininet script given below as pathmap_test.py and run the mininet script in the
mininet environment where Mininet is installed.
• Create topology using the below mininet script:
from mininet.topo import Topo

class MyTopo( Topo ):
"Simple topology example."
def __init__( self ):
"Create custom topo."
# Initialize topology
Topo.__init__( self )
# Add hosts and switches
leftHost = self.addHost( 'h1' )
rightHost = self.addHost( 'h2' )
leftSwitch = self.addSwitch( 's1' )
middleSwitch = self.addSwitch( 's2' )
middleSwitch2 = self.addSwitch( 's4' )
rightSwitch = self.addSwitch( 's3' )
# Add links
self.addLink( leftHost, leftSwitch )
334
self.addLink( leftSwitch, middleSwitch )

self.addLink( leftSwitch, middleSwitch2 )
self.addLink( middleSwitch, rightSwitch )
self.addLink( middleSwitch2, rightSwitch )
self.addLink( rightSwitch, rightHost )
topos = { 'mytopo': ( lambda: MyTopo() ) }
mininet> net
c0
s1 lo: s1-eth1:h1-eth0 s1-eth2:s2-eth1 s1-eth3:s4-eth1
s3 lo: s3-eth1:s2-eth2 s3-eth2:s4-eth2 s3-eth3:h2-eth0
h1 h1-eth0:s1-eth1
h2 h2-eth0:s3-eth3
• Generate traffic by pinging between hosts h1 and h2 before creating the portmaps
respectively
mininet> h1 ping h2
Configuration
• Create Controller

d '{"controller": {"controller_id": "odc", "ipaddr":"10.100.9.42", "type":
• Create a VTN

'{"vtn" : {"vtn_name":"vtn1","description":"test VTN" }}' http://127.0.0.
• Create a vBridge in the VTN

POST -d '{"vbridge" : {"vbr_name":"vBridge1","controller_id":"odc",
vbridges.json
• Create two Interfaces into the vBridge

335

portmap.json
portmap.json
• Generate traffic by pinging between hosts h1 and h2 after creating the portmaps
respectively
mininet> h1 ping h2
• Get the VTN Dataflows information
curl -X GET -H 'content-type: application/json' --user 'admin:adminpass'

"http://127.0.0.1:8083/vtn-webapi/dataflows?&switch_id=
00:00:00:00:00:00:00:01&port_name=s1-eth1&controller_id=odc&srcmacaddr=de3d.
7dec.e4d2&no_vlan_id=true"
• Create a Flowcondition in the VTN
curl --user admin:admin -H 'content-type: application/json' -X PUT

-d '{"name": "flowcond_1","match": [{"index": 1,"ethernet": {"src":
"ca:9e:58:0c:1e:f0","dst": "ba:bd:0f:e3:a8:c8","type": 2048},"inetMatch":
{"inet4": {"src": "10.0.0.1","dst": "10.0.0.2","protocol": 1}}}]}' http://10.
100.9.42:8282/controller/nb/v2/vtn/default/flowconditions/flowcond_1
• Create a Pathmap in the VTN
curl --user admin:admin -H 'content-type: application/json' -X PUT -d

'{"index": 10, "condition":"flowcond_1", "policy":1, "idleTimeout": 300,
"hardTimeout": 0}' http://10.100.9.42:8282/controller/nb/v2/vtn/default/
pathmaps/1
• Get the Path policy information
curl --user admin:admin -H 'content-type: application/json' -X GET -d

'{"id": 1,"default": 100000,"cost": [{"location": {"node": {"type":
"OF","id": "00:00:00:00:00:00:00:01"},"port": {"type": "OF","id": "3",
"name": "s1-eth3"}},"cost": 1000},{"location": {"node": {"type": "OF",
"id": "00:00:00:00:00:00:00:04"},"port": {"type": "OF","id": "2","name":
"s4-eth2"}},"cost": 1000},{"location": {"node": {"type": "OF", "id":
"00:00:00:00:00:00:00:03"},"port": {"type": "OF","id": "3","name": "s3-
eth3"}},"cost": 100000}]}' http://10.100.9.42:8282/controller/nb/v2/vtn/
default/pathpolicies/1
Verification
• Before applying Path policy information in the VTN
336
"pathinfos": [
{
"switch_id": "00:00:00:00:00:00:00:01"
},
{
"switch_id": "00:00:00:00:00:00:00:02"
},
{
"switch_id": "00:00:00:00:00:00:00:03"
}
]
}
• After applying Path policy information in the VTN
{
"pathinfos": [
{
"switch_id": "00:00:00:00:00:00:00:01"
},
{
"switch_id": "00:00:00:00:00:00:00:04"
},
{
"switch_id": "00:00:00:00:00:00:00:03"
}
]
}
VTN Coordinator(Troubleshooting HowTo)

Overview
This page demonstrates Installation troubleshooting steps of VTN Coordinator.
OpenDaylight VTN provides multi-tenant virtual network functions on OpenDaylight
controllers. OpenDaylight VTN consists of two parts:
• VTN Coordinator.
• VTN Manager.
VTN Coordinator orchestrates multiple VTN Managers running in OpenDaylight Controllers,

and provides VTN Applications with VTN API. VTN Manager is OSGi bundles running in
OpenDaylight Controller. Current VTN Manager supports only OpenFlow switches. It
handles PACKET_IN messages, sends PACKET_OUT messages, manages host information,
337
and installs flow entries into OpenFlow switches to provide VTN Coordinator with virtual
network functions. The requirements for installing these two are different.Therefore, we
recommend that you install VTN Manager and VTN Coordinator in different machines.
List of installation Troubleshooting How to’s

How to install VTN Coordinator?
• https://wiki.opendaylight.org/view/
OpenDaylight_Virtual_Tenant_Network_(VTN):Installation:VTN_Coordinator
After executing db_setup, you have encountered the error "Failed to setup database"?
The error could be due to the below reasons * Access Restriction
The user who owns /usr/local/vtn/ directory and installs VTN Coordinator, can only start
db_setup. Example :
The directory should appear as below (assuming the user as "vtn"):
# ls -l /usr/local/
drwxr-xr-x. 12 vtn vtn 4096 Mar 14 21:53 vtn
If the user doesnot own /usr/local/vtn/ then, please run the below command
(assuming the username as vtn),
chown -R vtn:vtn /usr/local/vtn
• Postgres not Present
1. In case of Fedora/CentOS/RHEL, please check if /usr/pgsql/<version>

directory is present and also ensure the commands initdb, createdb,pg_ctl,
psql are working. If, not please re-install postgres packages
2. In case of Ubuntu, check if /usr/lib/postgres/<version> directory is
present and check for the commands as in the previous step.
• Not enough space to create tables
Please check df -k and ensure enough free space is available.
• If the above steps do not solve the problem, please refer to the log file for the exact
problem
/usr/local/vtn/var/dbm/unc_setup_db.log for the exact error.
What are the things to check after vtn_start?

• list of VTN Coordinator processes
• Run the below command ensure the Coordinator daemons are running.
Command: /usr/local/vtn/bin/unc_dmctl status

Name Type IPC Channel PID
----------- ----------- -------------- ------
drvodcd DRIVER drvodcd 15972
lgcnwd LOGICAL lgcnwd 16010
phynwd PHYSICAL phynwd 15996
• Issue the curl command to fetch version and ensure the process is able to respond.
338
How to debug a startup failure? The following activities take place in order during
startup
• Database server is started after setting virtual memory to required value,Any database
startup errors will be reflected in any of the below logs.
/usr/local/vtn/var/dbm/unc_db_script.log.
/usr/local/vtn/var/db/pg_log/postgresql-*.log (the pattern will have
the date)
• uncd daemon is kicked off, The daemon in turn kicks off the rest of the daemons.
Any uncd startup failures will be reflected in /usr/local/vtn/var/uncd/

uncd_start.err.
After setting up the apache tomcat server, what are the aspects that should be
checked.
Please check if catalina is running.
The command ps -ef | grep catalina | grep -v grep should list a catalina
process
If you encounter an erroneous situation where the REST API is always failing.
Please ensure the firewall settings for port:8282(Lithium release) or
port:8083(Post Lithium release) and enable the same.
How to debug a REST API returning a failure message? Please check the /usr/share/
java/apache-tomcat-7.0.39/logs/core/core.log for failure details.
REST API for VTN configuration fails, how to debug? The default log level for all
daemons is "INFO", to debug the situation TRACE or DEBUG logs may be needed. To
increase the log level for individual daemons, please use the commands suggested below
/usr/local/vtn/bin/lgcnw_control loglevel trace -- upll daemon log
/usr/local/vtn/bin/phynw_control loglevel trace -- uppl daemon log
/usr/local/vtn/bin/unc_control loglevel trace -- uncd daemon log
/usr/local/vtn/bin/drvodc_control loglevel trace -- Driver daemon log
After setting the log levels, the operation can be repeated and the log files can be referred
for debugging.
Problems while Installing PostgreSQL due to openssl. Errors may occur when trying
to install postgreSQL rpms. Recently PostgreSQL has upgraded all their binaries to use
the latest openssl versions with fix for http://en.wikipedia.org/wiki/Heartbleed Please
upgrade the openssl package to the latest version and re-install. For RHEL 6.1/6.4 : If you
have subscription, Please use the same and update the rpms. The details are available in the
following link https://access.redhat.com/site/solutions/781793 ACCESS-REDHAT
rpm -Uvh http://mirrors.kernel.org/centos/6/os/x86_64/Packages/openssl-1.0.
1e-15.el6.x86_64.rpm
rpm -ivh http://mirrors.kernel.org/centos/6/os/x86_64/Packages/openssl-
devel-1.0.1e-15.el6.x86_64.rpm
For other linux platforms, Please do yum update, the public respositroes will have the latest
openssl, please install the same.
339
Support for Microsoft SCVMM 2012 R2 with ODL VTN

Introduction
System Center Virtual Machine Manager (SCVMM) is Microsoft’s virtual machine support
center for window’s based emulations. SCVMM is a management solution for the
virtualized data center. You can use it to configure and manage your virtualization host,
networking, and storage resources in order to create and deploy virtual machines and
services to private clouds that you have created.
The VSEM Provider is a plug-in to bridge between SCVMM and OpenDaylight.
Microsoft Hyper-V is a server virtualization developed by Microsoft, which provides

virtualization services through hypervisor-based emulations.
Figure 33.25. Set-Up Diagram
The topology used in this set-up is:
• A SCVMM with VSEM Provider installed and a running VTN Coordinator and
OpenDaylight with VTN Feature installed.
• PF1000 virtual switch extension has been installed in the two Hyper-V servers as it
implements the OpenFlow capability in Hyper-V.
• Three OpenFlow switches simulated using mininet and connected to Hyper-V.
• Four VM’s hosted using SCVMM.
340
It is implemented as two major components:
• SCVMM
• OpenDaylight (VTN Feature)
• VTN Coordinator
VTN Coordinator
OpenDaylight VTN as Network Service provider for SCVMM where VSEM provider is added
in the Network Service which will handle all requests from SCVMM and communicate
with the VTN Coordinator. It is used to manage the network virtualization provided by
OpenDaylight.
Installing HTTPS in VTN Coordinator

• System Center Virtual Machine Manager (SCVMM) supports only https protocol.
Apache Portable Runtime (APR) Installation Steps
• Enter the command "yum install apr" in VTN Coordinator installed machine.
• In /usr/bin, create a soft link as "ln –s /usr/bin/apr-1-config /usr/bin/apr-config".
• Extract tomcat under "/usr/share/java" by using the below command "tar -xvf apache-
tomcat-7.0.56.tar.gz –C /usr/share/java".
Note
Please go through the bleow link to download apache-tomcat-7.0.56.tar.gz file,
https://archive.apache.org/dist/tomcat/tomcat-7/v7.0.56/bin/
• Please go to the directory "cd /usr/share/java/apache-tomcat-7.0.56/bin and unzip

tomcat-native.gz using this command "tar -xvf tomcat-native.gz".
• Go to the directory "cd /usr/share/java/apache-tomcat-7.0.56/bin/tomcat-native-1.1.27-

src/jni/native".
• Enter the command "./configure --with-apr=/usr/bin/apr-config".
• Enter the command "make" and "make install".
• Apr libraries are successfully installed in "/usr/local/apr/lib".
Enable HTTP/HTTPS in VTN Coordinator
Enter the command "system-config-firewall-tui" to enable firewall settings in server.
Create a CA’s private key and a self-signed certificate in server
• Execute the following command "openssl req -x509 -days 365 -extensions v3_ca -newkey
rsa:2048 –out /etc/pki/CA/cacert.pem –keyout /etc/pki/CA/private/cakey.pem" in a
single line.
341
Argument Description
Country Name Specify the country code. For example, JP
State or Province Name Specify the state or province. For example, Tokyo
Locality Name Locality Name For example, Chuo-Ku
Organization Name Specify the company.
Organizational Unit Name Specify the department, division, or the like.
Common Name Specify the host name.
Email Address Specify the e-mail address.
• Execute the following commands: "touch /etc/pki/CA/index.txt" and "echo 00 > /etc/pki/
CA/serial" in server after setting your CA’s private key.
Create a private key and a CSR for web server
• Execute the following command "openssl req -new -newkey rsa:2048 -out csr.pem –
keyout /usr/local/vtn/tomcat/conf/key.pem" in a single line.
• Enter the PEM pass phrase: Same password you have given in CA’s private key PEM pass
phrase.
Argument Description
Country Name Specify the country code. For example, JP
State or Province Name Specify the state or province. For example, Tokyo
Locality Name Locality Name For example, Chuo-Ku
Organization Name Specify the company.
Organizational Unit Name Specify the department, division, or the like.
Common Name Specify the host name.
Email Address Specify the e-mail address.
A challenge password Specify the challenge password.
An optional company name Specify an optional company name.
Create a certificate for web server
• Execute the following command "openssl ca –in csr.pem –out /usr/local/vtn/tomcat/

conf/cert.pem –days 365 –batch" in a single line.
• Enter pass phrase for /etc/pki/CA/private/cakey.pem: Same password you have given in
CA’s private key PEM pass phrase.
• Open the tomcat file using "vim /usr/local/vtn/tomcat/bin/tomcat".
• Include the line " TOMCAT_PROPS="$TOMCAT_PROPS -Djava.library.path=\"/usr/local/

apr/lib\"" " in 131th line and save the file.
Edit server.xml file and restart the server
• Open the server.xml file using "vim /usr/local/vtn/tomcat/conf/server.xml" and add the
below lines.
<Connector port="${vtn.port}" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
SSLCertificateFile="/usr/local/vtn/tomcat/conf/cert.pem"
SSLCertificateKeyFile="/usr/local/vtn/tomcat/conf/key.pem"
342
SSLPassword=same password you have given in CA's private key PEM pass phrase
connectionTimeout="20000" />
• Save the file and restart the server.
• To stop vtn use the following command.

/usr/local/vtn/bin/vtn_stop
• To start vtn use the following command.

/usr/local/vtn/bin/vtn_start
• Copy the created CA certificate from cacert.pem to cacert.crt by using the following
command,
openssl x509 –in /etc/pki/CA/cacert.pem –out cacert.crt
Checking the HTTP and HTTPS connection from client
• You can check the HTTP connection by using the following command:
curl -X GET -H 'contenttype:application/json' -H 'username:admin' -
H 'password:adminpass' http://<server IP address>:8083/vtn-webapi/
api_version.json
• You can check the HTTPS connection by using the following command:
curl -X GET -H 'contenttype:application/json' -H 'username:admin' -
H 'password:adminpass' https://<server IP address>:8083/vtn-webapi/
api_version.json --cacert /etc/pki/CA/cacert.pem
• The response should be like this for both HTTP and HTTPS:
{"api_version":{"version":"V1.2"}}
Prerequisites to create Network Service in SCVMM machine, Please

follow the below steps
1. Please go through the below link to download VSEM Provider zip file, https://
nexus.opendaylight.org/content/groups/public/org/opendaylight/vtn/application/
vtnmanager-vsemprovider/1.0.0-Lithium/vtnmanager-vsemprovider-1.0.0-Lithium-bin.zip
2. Unzip the vtnmanager-vsemprovider-1.0.0-Lithium-bin.zip file anywhere in your SCVMM

machine.
3. Stop SCVMM service from "service manager⇐tools⇐servers⇐select system center virtual

machine manager" and click stop.
4. Go to "C:/Program Files" in your SCVMM machine. Inside "C:/Program Files", create a

folder named as *"ODLProvider".
5. Inside "C:/Program Files/ODLProvider", create a folder named as "Module" in your

SCVMM machine.
6. Inside "C:/Program Files/ODLProvider/Module", Create two folders named as

"Odl.VSEMProvider" and "VSEMOdlUI" in your SCVMM machine.
343
7. Copy the "VSEMOdl.dll" file from "ODL_SCVMM_PROVIDER/ODL_VSEM_PROVIDER" to

"C:/Program Files/ODLProvider/Module/Odl.VSEMProvider" in your SCVMM machine.
8. Copy the "VSEMOdlProvider.psd1" file from "application/vsemprovider/

VSEMOdlProvider/VSEMOdlProvider.psd1" to "C:/Program Files/ODLProvider/
Module/Odl.VSEMProvider" in your SCVMM machine.
9. Copy the "VSEMOdlUI.dll" file from "ODL_SCVMM_PROVIDER/

ODL_VSEM_PROVIDER_UI" to "C:/Program Files/ODLProvider/Module/VSEMOdlUI" in
your SCVMM machine.
10.Copy the "VSEMOdlUI.psd1" file from "application/vsemprovider/VSEMOdlUI" to "C:/

Program Files/ODLProvider/Module/VSEMOdlUI" in your SCVMM machine.
11.Copy the "reg_entry.reg" file from "ODL_SCVMM_PROVIDER/Register_settings" to

your SCVMM desktop and double click the "reg_entry.reg" file to install registry entry in
your SCVMM machine.
12.Download "PF1000.msi" from this link, https://www.pf-info.com/License/en/index.php?

url=index/index_non_buyer and place into "C:/Program Files/Switch Extension Drivers"
in your SCVMM machine.
13.Start SCVMM service from "service manager⇐tools⇐servers⇐select system center virtual

machine manager" and click start.
System Center Virtual Machine Manager (SCVMM)

It supports two major features:
• Failover Clustering
• Live Migration
Failover Clustering
A single Hyper-V can host a number of virtual machines. If the host were to fail then all of
the virtual machines that are running on it will also fail, thereby resulting in a major outage.
Failover clustering treats individual virtual machines as clustered resources. If a host were to
fail then clustered virtual machines are able to fail over to a different Hyper-V server where
they can continue to run.
Live Migration
Live Migration is used to migrate the running virtual machines from one Hyper-V server to
another Hyper-V server without any interruptions. Please go through the below video for
more details,
• https://youtu.be/34YMOTzbNJM
SCVMM User Guide

• Please go through the below link for SCVMM user guide: https://wiki.opendaylight.org/
images/c/ca/ODL_SCVMM_USER_GUIDE_final.pdf
344
• Please go through the below links for more details
• OpenDaylight SCVMM VTN Integration: https://youtu.be/iRt4dxtiz94
• OpenDaylight Congestion Control with SCVMM VTN: https://

youtu.be/34YMOTzbNJM
345
34. NETCONF User Guide
Table of Contents
Overview ..................................................................................................................... 346
Southbound (netconf-connector) ................................................................................. 346
Northbound (NETCONF servers) .................................................................................. 353
NETCONF testtool ....................................................................................................... 355
Overview
NETCONF is an XML based protocol used for configuration and monitoring of devices in the
network. The base NETCONF protocol is described in RFC-6241.
NETCONF in OpenDaylight: OpenDaylight controller supports NETCONF protocol as a

northbound server as well as a southbound plugin.
Southbound (netconf-connector)
NETCONF southbound plugin is capable of connecting to remote NETCONF devices and
expose their configuration/operational datastores, rpcs and notifications as MD-SAL mount
points. These mount points allow applications and remote users (over RESTCONF) to
interact with the mounted devices.
In terms of RFCs, the connector supports:
• RFC-6241,
• RFC-5277,
• RFC-6022,
Netconf-connector is fully model driven (utilising YANG modeling language) so in

addition to the above RFCs, it supports any data/RPC/notifications described by a YANG
model that is implemented by the device.
Tip
NETCONF southbound can be activated by installing odl-netconf-
connector-all Karaf feature.
Netconf-connector configuration
There are 2 ways for configuring netconf-connector (as is for any other module) NETCONF
or RESTCONF. This guide focuses on using RESTCONF.
Default configuration
The default configuration contains all the necessary dependencies (file: 01-netconf.xml) and
a single instance of netconf-connector (file: 99-netconf-connector.xml) called controller-
346
config which connects itself to the NETCONF northbound in OpenDaylight in a loopback

fashion. The connector mounts the NETCONF server for config-subsystem in order to enable
RESTCONF protocol for config-subsystem. This RESTCONF still goes via NETCONF, but using
RESTCONF is much more user friendly than using NETCONF.
Spawning additional netconf-connectors while the controller is running

Preconditions:
1. OpenDaylight is running
2. In Karaf, you must have the netconf-connector installed (at the Karaf prompt, type:
feature:install odl-netconf-connector-all); the loopback NETCONF mountpoint will be
automatically configured and activated
3. Wait until log displays following entry: RemoteDevice{controller-config}: NETCONF

connector initialized successfully
To configure a new netconf-connector you need to send following request to RESTCONF:
POST http://localhost:8181/restconf/config/network-topology:network-topology/
topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules
Headers: Accept application/xml Content-Type application/xml

<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">prefix:sal-
netconf-connector</type>
<name>new-netconf-device</name>
<address xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">127.
0.0.1</address>
<port xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">830</
port>
<username xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">admin</
username>
<password xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">admin</
password>
<tcp-only xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">false</
tcp-only>
<event-executor xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:netty">prefix:netty-event-
executor</type>
</event-executor>
<binding-registry xmlns=
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">prefix:binding-
broker-osgi-registry</type>
<name>binding-osgi-broker</name>
347
</binding-registry>
<dom-registry xmlns=
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">prefix:dom-broker-
osgi-registry</type>
<name>dom-broker</name>
</dom-registry>
<client-dispatcher xmlns=
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:config:netconf">prefix:netconf-
client-dispatcher</type>
<name>global-netconf-dispatcher</name>
</client-dispatcher>
<processing-executor xmlns=
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:threadpool</
type>
<name>global-netconf-processing-executor</name>
</processing-executor>
<keepalive-executor xmlns=
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:scheduled-
threadpool</type>
<name>global-netconf-ssh-scheduled-executor</name>
</keepalive-executor>
</module>
This spawns a new netconf-connector which tries to connect to (or mount) a NETCONF
device at 127.0.0.1 and port 830. You can check the configuration of config-subsystem’s
configuration datastore. The new netconf-connector will now be present there. Just invoke:
GET http://localhost:8181/restconf/config/network-topology:network-topology/topology/
topology-netconf/node/controller-config/yang-ext:mount/config:modules
The response will contain the module for new-netconf-device.
Right after the new netconf-connector is created, it writes some useful metadata into the
datastore of MD-SAL under the network-topology subtree. This metadata can be found at:
GET http://localhost:8181/restconf/operational/network-topology:network-topology/
Information about connection status, device capabilities etc. can be found there.
Connecting to a device not supporting NETCONF monitoring

The netconf-connector in OpenDaylight relies on ietf-netconf-monitoring support when
connecting to remote NETCONF device. The ietf-netconf-monitoring support allows
netconf-connector to list and download all YANG schemas that are used by the device.
NETCONF connector can only communicate with a device if it knows the set of used
schemas (or at least a subset). However, some devices use YANG models internally but do
not support NETCONF monitoring. Netconf-connector can also communicate with these
devices, but you have to side load the necessary yang models into OpenDaylight’s YANG
model cache for netconf-connector. In general there are 2 situations you might encounter:
348
1. NETCONF device does not support ietf-netconf-monitoring but it does list all its YANG
models as capabilities in HELLO message
This could be a device that internally uses only ietf-inet-types YANG model with revision
2010-09-24. In the HELLO message that is sent from this device there is this capability
reported:
urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=
2010-09-24
For such devices you only need to put the schema into folder cache/schema inside your
Karaf distribution.
Important
The file with YANG schema for ietf-inet-types has to be called ietf-inet-
[email protected]. It is the required naming format of the cache.
2. NETCONF device does not support ietf-netconf-monitoring and it does NOT list its
YANG models as capabilities in HELLO message
Compared to device that lists its YANG models in HELLO message, in this case there
would be no capability with ietf-inet-types in the HELLO message. This type of device
basically provides no information about the YANG schemas it uses so its up to the user of
OpenDaylight to properly configure netconf-connector for this device.
Netconf-connector has an optional configuration attribute called yang-module-capabilities

and this attribute can contain a list of "YANG module based" capabilities. So by setting
this configuration attribute, it is possible to override the "yang-module-based" capabilities
reported in HELLO message of the device. To do this, we need to modify the configuration
of netconf-connector by adding this xml (It needs to be added next to the address, port,
username etc. configuration elements):
<yang-module-capabilities xmlns=
<capability xmlns=
urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&
amp;revision=2010-09-24
</capability>
</yang-module-capabilities>
Remember to also put the YANG schemas into the cache folder.
Note
For putting multiple capabilities, you just need to replicate the capability xml
element inside yang-module-capability element. Capability element is modeled
as a leaf-list. With this configuration, we would make the remote device report
usage of ietf-inet-types in the eyes of netconf-connector.
Reconfiguring Netconf-Connector While the Controller is Running

It is possible to change the configuration of a running module while the whole controller
is running. This example will continue where the last left off and will change the
349
configuration for the brand new netconf-connector after it was spawned. Using one
RESTCONF request, we will change both username and password for the netconf-
connector.
To update an existing netconf-connector you need to send following request to RESTCONF:
PUT http://localhost:8181/restconf/config/network-topology:network-topology/topology/
topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-sal-
netconf-connector-cfg:sal-netconf-connector/new-netconf-device
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">prefix:sal-
netconf-connector</type>
<name>new-netconf-device</name>
<username xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">bob</
username>
<password xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">passwd</
password>
<tcp-only xmlns=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">false</
tcp-only>
<event-executor xmlns=
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:netty">prefix:netty-event-
executor</type>
</event-executor>
<binding-registry xmlns=
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">prefix:binding-
broker-osgi-registry</type>
<name>binding-osgi-broker</name>
</binding-registry>
<dom-registry xmlns=
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">prefix:dom-broker-
osgi-registry</type>
<name>dom-broker</name>
</dom-registry>
<client-dispatcher xmlns=
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:config:netconf">prefix:netconf-
client-dispatcher</type>
<name>global-netconf-dispatcher</name>
</client-dispatcher>
<processing-executor xmlns=
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:threadpool</
type>
<name>global-netconf-processing-executor</name>
</processing-executor>
350
<keepalive-executor xmlns=
<type xmlns:prefix=
"urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:scheduled-
threadpool</type>
<name>global-netconf-ssh-scheduled-executor</name>
</keepalive-executor>
</module>
Since a PUT is a replace operation, the whole configuration must be specified along with
the new values for username and password. This should result in a 2xx response and
the instance of netconf-connector called new-netconf-device will be reconfigured to use
username bob and password passwd. New configuration can be verified by executing:
topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-sal-
netconf-connector-cfg:sal-netconf-connector/new-netconf-device
With new configuration, the old connection will be closed and a new one established.
Destroying Netconf-Connector While the Controller is Running

Using RESTCONF one can also destroy an instance of a module. In case of netconf-
connector, the module will be destroyed, NETCONF connection dropped and all resources
will be cleaned. To do this, simply issue a request to following URL:
DELETE http://localhost:8181/restconf/config/network-topology:network-topology/
module/odl-sal-netconf-connector-cfg:sal-netconf-connector/new-netconf-device
The last element of the URL is the name of the instance and its predecessor is the type of
that module (In our case the type is sal-netconf-connector and name new-netconf-device).
The type and name are actually the keys of the module list.
Netconf-connector utilisation
Once the connector is up and running, users can utilize the new Mount point instance. By
using RESTCONF or from their application code. This chapter deals with using RESTCONF
and more information for app developers can be found in the developers guide or in the
official tutorial application ncmount that can be found in the coretutorials project:
• https://github.com/opendaylight/coretutorials/tree/stable/lithium/ncmount
Reading data from the device

Just invoke (no body needed):
topology/topology-netconf/node/new-netconf-device/yang-ext:mount/
This will return the entire content of operation datastore from the device. To view just the
configuration datastore, change operational in this URL to config.
351
Writing configuration data to the device

In general, you cannot simply write any data you want to the device. The data have to
conform to the YANG models implemented by the device. In this example we are adding
a new interface-configuration to the mounted device (assuming the device supports Cisco-
IOS-XR-ifmgr-cfg YANG model). In fact this request comes from the tutorial dedicated to
the ncmount tutorial app.
POST http://localhost:8181/restconf/config/network-topology:network-topology/
topology/topology-netconf/node/new-netconf-device/yang-ext:mount/Cisco-IOS-XR-ifmgr-
cfg:interface-configurations
<interface-configuration xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-
cfg">
<active>act</active>
<interface-name>mpls</interface-name>
<description>Interface description</description>
<bandwidth>32</bandwidth>
<link-status></link-status>
</interface-configuration>
Should return 200 response code with no body.
Tip
This call is transformed into a couple of NETCONF RPCs. Resulting
NETCONF RPCs that go directly to the device can be found
in the OpenDaylight logs after invoking log:set TRACE
org.opendaylight.controller.sal.connect.netconf in the Karaf
shell. Seeing the NETCONF RPCs might help with debugging.
This request is very similar to the one where we spawned a new netconf device. That’s
because we used the loopback netconf-connector to write configuration data into config-
subsystem datastore and config-subsystem picked it up from there.
Invoking custom RPC

Devices can implement any additional RPC and as long as it provides YANG models for it,
it can be invoked from OpenDaylight. Following example shows how to invoke the get-
schema RPC (get-schema is quite common among netconf devices). Invoke:
POST http://localhost:8181/restconf/operations/network-topology:network-topology/
topology/topology-netconf/node/new-netconf-device/yang-ext:mount/ietf-netconf-
monitoring:get-schema
<input xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<identifier>ietf-yang-types</identifier>
<version>2013-07-15</version>
</input>
This call should fetch the source for ietf-yang-types YANG model from the mounted device.
Netconf-connector + Netopeer
Netopeer (an open-source NETCONF server) can be used for testing/exploring NETCONF
southbound in OpenDaylight.
352
Netopeer installation
Docker container with netopeer will be used in this guid. To install docker and start the
netopeer image perform following steps:
1. Install docker http://docs.docker.com/linux/step_one/
2. Start the netopeer image:

docker run -rm -t -p 1831:830 dockeruser/netopeer
3. Verify netopeer is running by invoking (netopeer should send its HELLO message right
away:
ssh root@localhost -p 1831 -s netconf
(password root)
Mounting netopeer NETCONF server

Preconditions:
• OpenDaylight is started with features odl-restconf-all and odl-netconf-

connector-all.
• Netopeer is up and running in docker
Now just follow the chapter: Spawning netconf-connector. In the payload change the:
• name to e.g. netopeer
• usernam/password to your system credentials
• ip to localhost
• port to 1831.
After netopeer is mounted successfully, its configuration can be read using RESTCONF by
invoking:
topology-netconf/node/netopeer/yang-ext:mount/
Northbound (NETCONF servers)

OpenDaylight provides 2 types of NETCONF servers:
• NETCONF server for config-subsystem(listening by default on port 1830)
• Serves as a default interface for config-subsystem and allows users to spawn/

reconfigure/destroy modules(or applications) in OpenDaylight
• NETCONF server for MD-SAL(listening by default on port 2830)
• Serves as an alternative interface for MD-SAL (besides RESTCONF) and allows users
to read/write data from MD-SAL’s datastore and to invoke its rpcs (NETCONF
notifications are not available in the Lithium release of OpenDaylight)
353
Note
The reason for having 2 NETCONF servers is that config-subsystem and MD-SAL
are 2 different components of OpenDaylight and require different approach
for NETCONF message handling and data translation. These 2 components will
probably merge in the future.
NETCONF server for config-subsystem

This NETCONF server is the primary interface for config-subsystem. It allows the users to
interact with config-subsystem in a standardized NETCONF manner.
In terms of RFCs, these are supported:
• RFC-6241,
• RFC-5277,
• RFC-6470
• (partially, only the schema-change notification is available in Lithium release)
• RFC-6022,
For regular users it is recommended to use RESTCONF + the controller-config loopback

mountpoint instead of using pure NETCONF. How to do that is spesific for each
component/module/application in OpenDaylight and can be found in their dedicated user
guides
NETCONF server for MD-SAL

This NETCONF server is just a generic interface to MD-SAL in OpenDaylight. It uses the
stadard MD-SAL APIs and serves as an alternative to RESTCONF. It is fully model driven and
supports any data and rpcs that are supported by MD-SAL.
In terms of RFCs, these are supported:
• RFC-6241,
• RFC-6022,
Notifications over NETCONF are not supported in the Lithium release.
Tip
Install NETCONF northbound for MD-SAL by installing feature: odl-netconf-
mdsal in karaf. Default binding port is 2830.
Configuration
The default configuration can be found in file: 08-netconf-mdsal.xml. The file contains the
configuration for all necessary dependencies and a single SSH endpoint starting on port
354
2830. There is also a (by default disabled) TCP endpoint. It is possible to start multiple
endpoints at the same time either in the initial configuration file or while OpenDaylight is
running.
The credentials for SSH endpoint can also be configured here, the defaults are admin/
admin. Credentials in the SSH endpoint are not yet managed by the centralized AAA
component and have to be configured separately.
Verifying MD-SAL’s NETCONF server

After the NETCONF server is available it can be examined by e.g. a command line ssh tool:
ssh admin@localhost -p 2830 -s netconf
The server will respond by sending its HELLO message and can be used as a regular
NETCONF server from now on.
Mounting the MD-SAL’s NETCONF server

To perform this operation, just spawn a new netconf-connector as described in Spawning
netconf-connector. Just change the ip to "127.0.0.1" port to "2830" and its name to
"controller-mdsal".
Now the MD-SAL’s datastore can be read over RESTCONF via NETCONF by invoking:
topology/topology-netconf/node/controller-mdsal/yang-ext:mount
Note
This might not seem very useful, since MD-SAL can be accessed directly
from RESTCONF or from Application code, but the same method can be
used to mount and control other OpenDaylight instances by the "master
OpenDaylight".
NETCONF testtool
NETCONF testtool is a set of standalone runnable jars that can:
• Simulate NETCONF devices(suitable for scale testing)
• Stress/Performance test NETCONF devices
• Stress/Performance test RESTCONF devices
These jars are part of OpenDaylight’s controller project and are built from the NETCONF
codebase in OpenDaylight.
Tip
Download testtool from OpenDaylight Nexus at: http://
nexus.opendaylight.org/#nexus-search;quick~netconf-testtool
355
Nexus contains 3 executable tools:
• executable.jar - device simulator
• stress.client.tar.gz - NETCONF stress/performance measuring tool
• perf-client.jar - RESTCONF stress/performance measuring tool
Tip
Each executable tool provides help. Just invoke java -jar <name-of-the-
tool.jar> --help
NETCONF device simulator

Detailed information for NETCONF device simulator can be found at: https://
wiki.opendaylight.org/view/OpenDaylight_Controller:Netconf:Testtool
NETCONF stress/performance measuring tool

This is basically a NETCONF client that puts NETCONF servers under heavy load of NETCONF
RPCs and measures the time until a configurable amount of them is processed.
RESTCONF stress-performance measuring tool

Very similar to NETCONF stress tool with the difference of using RESTCONF protocol instead
of NETCONF.
356
35. YANG-PUSH
Table of Contents
Overview ..................................................................................................................... 357
YANG-PUSH Architecture ............................................................................................. 358
YANG-PUSH Catalog .................................................................................................... 358
YANG-PUSH Workload Manager .................................................................................. 358
Configuring YANG-PUSH Workload Manager ............................................................... 358
Administering YANG-PUSH Workload Manager ........................................................... 359
Tutorials ...................................................................................................................... 359
This section describes how to use the YANG-PUSH feature in OpenDaylight and contains
contains configuration, administration, and management sections for the feature.
Overview
YANG PUBSUB project allows applications to place subscriptions upon targeted subtrees of
YANG datastores residing on remote devices. Changes in YANG objects within the remote
subtree can be pushed to an OpenDaylight MD-SAL and to the application as specified
without a requiring the controller to make a continuous set of fetch requests.
YANG-PUSH capabilities available

This module contains the base code which embodies the intent of YANG-PUSH
requirements for subscription as defined in {i2rs-pub-sub-requirements} [https://
datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/]. The mechanism for
delivering on these YANG-PUSH requirements over Netconf transport is defined in
{netconf-yang-push} [netconf-yang-push: https://tools.ietf.org/html/draft-ietf-netconf-
yang-push-00].
Note that in the current release, not all capabilities of draft-ietf-netconf-yang-push

are realized. Currently only implemented is create-subscription RPC support from ietf-
[email protected]; and this will be for periodic subscriptions only. There of
course is intent to provide much additional functionality in future OpenDaylight releases.
Future YANG-PUSH capabilities

Over time, the intent is to flesh out more robust capabilities which will allow OpenDaylight
applications to subscribe to YANG-PUSH compliant devices. Capabilities for future releases
will include:
Support for subscription change/delete: modify-subscription rpc support for all

mountpoint devices or particular mountpoint device delete-subscription rpc support for all
mountpoint devices or particular mountpoint device
Support for static subscriptions: This will enable the receipt of subscription updates pushed
from publishing devices where no signaling from the controller has been used to establish
the subscriptions.
357
Support for additional transports: NETCONF is not the only transport of interest to
OpenDaylight or the subscribed devices. Over time this code will support Restconf
and HTTP/2 transport requirements defined in {netconf-restconf-yang-push} [https://
tools.ietf.org/html/draft-voit-netconf-restconf-yang-push-01]
YANG-PUSH Architecture
The code architecture of Yang push consists of two main elements
YANGPUSH Provider YANGPUSH Listener
YANGPUSH Provider receives create-subscription requests from applications and then

establishes/registers the corresponding listener which will receive information pushed by
a publisher. In addition, YANGPUSH Provider also invokes an augmented OpenDaylight
create-subscription RPC which enables applications to register for notification as per
rfc5277. This augmentation adds periodic time period (duration) and subscription-id
values to the existing RPC parameters. The Java package supporting this capability is
“org.opendaylight.yangpush.impl”. YangpushDomProvider is the class which supports this
YANGPUSH Provider capability.
The YANGPUSH Listener accepts update notifications from a device after they
have been de-encapsulated from the NETCONF transport. The YANGPUSH Listener
then passes these updates to MD-SAL. This function is implemented via the
YangpushDOMNotificationListener class within the “org.opendaylight.yangpush.listner”
Java package. Applications should monitor MD-SAL for the availability of newly pushed
subscription updates.
YANG-PUSH Catalog
The NF Catalog contains metadata describing a NF.
Configuring YANG-PUSH Catalog

TBD: Describe how to configure YANG-PUSH Catalog after installation.
Administering YANG-PUSH Catalog

TBD: Include related command reference or operations for using YANG-PUSH Catalog.
YANG-PUSH Workload Manager

The Workload Manager defines RPCs to manage instances.
Configuring YANG-PUSH Workload Manager

TBD: Describe how to configure YANG-PUSH Workload Manager after installation.
358
Administering YANG-PUSH Workload Manager

TBD: Include related command reference or operations for using YANG-PUSH Workload
Manager.
Tutorials
Below are tutorials for YANG-PUSH.
Using YANG-PUSH Catalog

Overview
TBD: An overview of the YANG-PUSH Catalog tutorial
Prerequisites
Target Environment
There are no topology requirement for using YANG-PUSH. A single node able interact
as per https://tools.ietf.org/html/draft-ietf-netconf-yang-push-00 is sufficient to use this
capability.
Instructions
TBD: Step by step procedure for using YANG-PUSH Catalog.
Using YANG-PUSH Workload Manager

Overview
TBD: An overview of the YANG-PUSH Workload Manager tutorial
Prerequisites
Target Environment
359
Instructions
TBD: Step by step procedure for using YANG-PUSH Workload Manager.
360

BK User Guide 20160221

Uploaded by

Copyright:

Available Formats

BK User Guide 20160221

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BK User Guide 20160221

Uploaded by

Copyright:

Available Formats

Op enDaylight

OpenDaylight User Guide

This guide describes how to use and deploy OpenDaylight.

10. DIDM User Guide ............................................................................................ 51

Architecture ................................................................................................ 141

Service Function Scheduling Algorithms ....................................................... 249

Tutorials ...................................................................................................... 359

12.2. Hosts .................................................................................................................. 115

1. OpenDaylight Controller Overview

• OSGi: This framework is the back-end of OpenDaylight as it allows dynamically

2. Using the OpenDaylight User Interface

Getting Started with DLUX

1. Open a browser and enter the login URL http://<your-karaf-ip>:8181/index.html in your

2. Login to the application with your username and password credentials.

Working with DLUX

Figure 2.1. DLUX Modules

Viewing Network Statistics

To use the Nodes module:

2. Enter a node ID in the Search Nodes tab to search by node connectors.

Viewing Network Topology

To view network topology:

Figure 2.2. Topology Module

Interacting with the YANG-based MD-SAL

Figure 2.3. Yang UI

To use Yang UI:

• GET to get data from OpenDaylight,

• PUT and POST for sending data to OpenDaylight for saving

• DELETE for sending data to OpenDaylight for deleting.

Figure 2.4. Yang API Specification

Figure 2.5. Yang UI API Specification

Displaying Topology on the Yang UI

1. Select subAPI network-topology <topology revision number> == > operational == >

2. Get data from OpenDaylight by clicking on the "GET" button.

3. Click Display Topology.

Figure 2.6. DLUX Yang Topology

Configuring List Elements on the Yang UI

Figure 2.7. DLUX List Elements

Figure 2.8. DLUX List Warnings

Figure 2.9. DLUX List Button1

3. Running XSQL Console Commands and

1. Navigate to the directory in which you unzipped OpenDaylight

XSQL Console Commands

Table 3.1. Supported XSQL Console Commands

The following criteria operators are supported:

Table 3.2. Supported XSQL Query Criteria Operators

Example: Skip Criteria Operator

• Module 1.1, Type YY

Advantages of clustering are:

Single Node Clustering

1. Download, unzip, and run the OpenDaylight distribution

2. Install the clustering feature:

Multiple Node Clustering

Setting Up a Multiple Node Cluster

1. Copy the OpenDaylight distribution zip file to the machine.

2. Unzip the distribution.

3. Open the following .conf files:

4. In each configuration file, make the following changes:

d. Open the configuration/initial/module-shards.conf file and update the replicas so that

For reference, view a sample config files below.