OpenDaylight is an open source project aiming to be a common tool across the networking industry - for enterprises, service providers, and manufacturers. It provides a highly available, multi-protocol infrastructure geared at building and managing software-defined networking deployments. Based on a Model Driven Service Abstraction Layer, the platform is extensible and allows users to create applications to communicate with a wide variety of south-bound protocols and hardware.

In other words, OpenDaylight is a framework used to solve networking-related use cases in both software-defined networking and network function virtualization domains.

To download the OpenDaylight software, select the Beryllium-SR4 release available at this link:

https://www.opendaylight.org/downloads

Download the ZIP or the tarball, and once extracted, get into that folder through the command line, and you are ready to play with the recipes.

The recipes in this chapter will present fundamental use cases that one can solve using OpenDaylight.

A common and widely used network emulator, Mininet, is going to be required to perform various recipes within this book.

Prior to any recipe, as a requirement, you will need a running version of Mininet. To achieve this, please follow the steps explained in the Mininet documentation:

http://mininet.org/download/

OpenFlow is a vendor-neutral, standard communications interface defined to enable the interaction between the control and forwarding channels of an SDN architecture. The OpenFlowPlugin project intends to support implementations of the OpenFlow specification as it evolves. It currently supports OpenFlow versions 1.0 and 1.3.2. In addition, to support the core OpenFlow specification, OpenDaylight Beryllium also includes preliminary support for the table type patterns and OF-CONFIG specifications.

The OpenFlow southbound plugin currently provides the following components:

• Flow management
• Group management
• Meter management
• Statistics polling

Let's connect an OpenFlow switch to OpenDaylight.

This recipe requires an OpenFlow switch. If you don't have any, you can use a Mininet-VM with OvS installed. You can download Mininet-VM from the following website:

https://github.com/mininet/mininet/wiki/Mininet-VM-Images

Any version should work.

The following recipe will be presented using a Mininet-VM with OvS 2.0.2.

Perform the following steps:

1. Start the OpenDaylight distribution using the karaf script. Using this script will give you access to the Karaf CLI:

$ ./bin/karaf

2. Install the user-facing feature responsible for pulling in all dependencies needed to connect an OpenFlow switch:

opendaylight-user@root>feature:install odl-openflowplugin-all  

It might take a minute or so to complete the installation.

3. Connect an OpenFlow switch to OpenDaylight.

As mentioned in the Getting ready section, we will use Mininet-VM as our OpenFlow switch as this VM runs an instance of OpenVSwitch:

mininet@mininet-vm:~$ sudo ovs-vsctl add-br br0  

mininet@mininet-vm:~$ sudo ovs-vsctl set-controller br0 tcp: ${CONTROLLER_IP}:6633  

mininet@mininet-vm:~$ sudo ovs-vsctl show
0b8ed0aa-67ac-4405-af13-70249a7e8a96
  Bridge "br0"
    Controller "tcp: ${CONTROLLER_IP}:6633"
      is_connected: true
    Port "br0"
      Interface "br0"
        type: internal
  ovs_version: "2.0.2"  

Once the feature is installed, OpenDaylight is listening to connections on port 6633 and 6640. Setting up the controller on the OpenFlow-capable switch will immediately trigger a callback on OpenDaylight. It will create the communication pipeline between the switch and OpenDaylight so they can communicate in a scalable and non-blocking way.

The OpenDaylight component responsible for connecting remote NETCONF devices is called the NETCONF southbound plugin, aka the netconf-connector. Creating an instance of the netconf-connector will connect a NETCONF device. The NETCONF device will be seen as a mount point in the MD-SAL, exposing the device configuration and operational data store and its capabilities. These mount points allow applications and remote users (over RESTCONF) to interact with the mounted devices.

The netconf-connector currently supports RFC-6241, RFC-5277, and RFC-6022.

The following recipe will explain how to connect a NETCONF device to OpenDaylight.

This recipe requires a NETCONF device. If you don't have any, you can use the NETCONF test tool provided by OpenDaylight. It can be downloaded from the OpenDaylight Nexus repository:

https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/netconf/netconf-testtool/1.0.4-Beryllium-SR4/netconf-testtool-1.0.4-Beryllium-SR4-executable.jar

Perform the following steps:

1. Start the OpenDaylight Karaf distribution using the karaf script. Using this script will give you access to the Karaf CLI:

$ ./bin/karaf  

2. Install the user-facing feature responsible for pulling in all dependencies needed to connect a NETCONF device:

opendaylight-user@root>feature:install odl-netconf-topology odl-restconf  

It might take a minute or so to complete the installation.

3. Start your NETCONF device.

If you want to use the NETCONF test tool, it is time to simulate a NETCONF device using the following command:

$ java -jar netconf-testtool-1.0.1-Beryllium-SR4-executable.jar --device-count 1 

<node xmlns="urn:TBD:params:xml:ns:yang:network-topology"> 
<node-id>new-netconf-device</node-id> 
<host xmlns="urn:opendaylight:netconf-node-topology">127.0.0.1</host> 
<port xmlns="urn:opendaylight:netconf-node-topology">17830</port> 
<username xmlns="urn:opendaylight:netconf-node-topology">admin</username> 
<password xmlns="urn:opendaylight:netconf-node-topology">admin</password> 
<tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only> 
</node> 

Once you have completed the request, send it. This will spawn a new netconf-connector that connects to the NETCONF device at the provided IP address and port using the provided credentials.

6. Verify that the netconf-connector has correctly been pushed and get information about the connected NETCONF device.

First, you could look at the log to see if any errors occurred. If no error has occurred, you will see the following:

2016-05-07 11:37:42,470 | INFO  | sing-executor-11 | NetconfDevice                    | 253 - org.opendaylight.netconf.sal-netconf-connector - 1.3.0.Beryllium | RemoteDevice{new-netconf-device}: Netconf connector initialized successfully 

<node xmlns="urn:TBD:params:xml:ns:yang:network-topology"> 
<node-id>new-netconf-device</node-id> 
  <host xmlns="urn:opendaylight:netconf-node-topology">127.0.0.1</host> 
  <port xmlns="urn:opendaylight:netconf-node-topology">17830</port> 
  <username xmlns="urn:opendaylight:netconf-node-topology">admin</username> 
  <password xmlns="urn:opendaylight:netconf-node-topology">admin</password> 
  <tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only> 
<schema-cache-directory xmlns="urn:opendaylight:netconf-node-topology">new_netconf_device_cache</schema-cache-directory> 
  <reconnect-on-changed-schema xmlns="urn:opendaylight:netconf-node-topology">false</reconnect-on-changed-schema> 
  <connection-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">20000</connection-timeout-millis> 
  <default-request-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">60000</default-request-timeout-millis> 
  <max-connection-attempts xmlns="urn:opendaylight:netconf-node-topology">0</max-connection-attempts> 
  <between-attempts-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">2000</between-attempts-timeout-millis> 
  <sleep-factor xmlns="urn:opendaylight:netconf-node-topology">1.5</sleep-factor> 
  <keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">120</keepalive-delay> 
</node>

Once the request to connect a new NETCONF device is sent, OpenDaylight will set up the communication channel used for managing and interacting with the device. At first, the remote NETCONF device will send its hello-message defining all of the capabilities it has. Based on this, the netconf-connector will download all the YANG files provided by the device. All those YANG files will define the schema context of the device.

At the end of the process, some exposed capabilities might end up as unavailable, for two possible reasons:

1. The NETCONF device provided a capability in its hello-message, but hasn't provided the schema.
2. OpenDaylight failed to mount a given schema due to YANG violation(s).

OpenDaylight parses YANG models as per RFC 6020; if a schema is not respecting the RFC, it could end up as an unavailable-capability.

If you encounter one of these situations, looking at the logs will pinpoint the reason for such a failure.

Once the NETCONF device is connected, all its capabilities are available through the mount point. View it as a pass-through directly to the NETCONF device.

To see the data contained in the device data store, use the following request:

• Type: GET
• Headers:

Authorization: Basic YWRtaW46YWRtaW4=

• URL: http://localhost:8080/restconf/config/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device/yang-ext:mount/

Adding yang-ext:mount/ to the URL will access the mount point created for new-netconf-device. This will show the configuration data store. If you want to see the operational one, replace config with operational in the URL.

If your device defines the YANG model, you can access its data using the following request:

• Type: GET
• Headers:

Authorization: Basic YWRtaW46YWRtaW4=

• URL: http://localhost:8080/restconf/config/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device/yang-ext:mount/<module>:<container>

The <module> represents a schema defining the <container>. The <container> can either be a list or a container. It is not possible to access a single leaf. You can access containers/lists within containers/lists. The last part of the URL would look like this:

.../ yang-ext:mount/<module>:<container>/<sub-container>

In order to invoke an RPC on the remote device, you should use the following request:

• Type: POST
• Headers:

Accept: application/xml

Content-Type: application/xml

Authorization: Basic YWRtaW46YWRtaW4=

• URL: http://localhost:8080/restconf/config/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device/yang-ext:mount/<module>:<operation>

This URL is accessing the mount point of new-netconf-device, and through this mount point we're accessing the <module> to call its <operation>. The <module> represents a schema defining the RPC and <operation> represents the RPC to call.

Removing a netconf-connector will drop the NETCONF session and all resources will be cleaned. To perform such an operation, use the following request:

• Type: DELETE
• Headers:

Authorization: Basic YWRtaW46YWRtaW4=

• URL: http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device

By looking closer at the URL, you can see that we are removing the netconf node-idnew-netconf-device.

YANGUI is a user interface application through which one can navigate among all YANG models available in the OpenDaylight controller. Not only does it aggregate all data models, it also enables their usage. Using this interface, you can create, remove, update, and delete any part of the model-driven data store. It provides a nice, smooth user interface making it easier to browse through the model(s).

This recipe will guide you through those functionalities.

This recipe only requires the OpenDaylight controller and a web browser.

Perform the following steps:

1. Start your OpenDaylight distribution using the karaf script. Using this client will give you access to the Karaf CLI:

$ ./bin/karaf

2. Install the user-facing feature responsible to pull in all dependencies needed to use YANGUI:

opendaylight-user@root>feature:install odl-dlux-yangui  

It might take a minute or so to complete the installation.

3. Navigate to http://localhost:8181/index.html#/yangui/index:
   • Username: admin
   • Password: admin

Once logged in, all modules will be loaded until you see this message at the bottom of the screen:

Loading completed successfully

You should see the API tab listing all YANG models in the following format:

<module-name> rev.<revision-date>

For instance:

• cluster-admin rev.2015-10-13
• config rev.2013-04-05
• credential-store rev.2015-02-26

By default, there isn't much you can do with the provided YANG models. So let's connect an OpenFlow switch to better understand how to use this YANGUI. To do so, please refer to the first recipe, Connecting OpenFlow switches, step 2.

Once done, refresh your web page to load newly added modules.

4. Look for opendaylight-inventory rev.2013-08-19 and select the operational tab, as nothing will yet be in the config data store. Then click on nodes and you'll see a request bar at the bottom of the page with multiple options.

You can either copy the request to the clipboard to use it in your browser, send it, show a preview of it, or define a custom API request.

For now, we will only send the request.

You should see Request sent successfully and under this message should be the retrieved data. As we only have one switch connected, there is only one node. All the switch operational information is now printed on your screen.

OpenDaylight has a model-driven architecture, which means that all of its components are modeled using YANG. While installing features, OpenDaylight loads YANG models, making them available within the MD-SAL data store.

YANGUI is a representation of this data store. Each schema represents a subtree based on the name of the module and its revision-date. YANGUI aggregates and parses all those models. It also acts as a REST client; through its web interface we can execute functions such as GET, POST, PUT, and DELETE.

The example shown previously can be improved upon, as there was no user YANG model loaded. For instance, if you mount a NETCONF device containing its own YANG model, you could interact with it through YANGUI.

You would use the config data store to push/update some data, and you would see the operational data store updated accordingly. In addition, accessing your data would be much easier than having to define the exact URL, as mentioned in the Mounting a NETCONF device recipe.

• Using API doc as a REST API client

The basic distributed switching in OpenDaylight is provided by the L2Switch project, proving layer 2 switch functionality. This project is built on top of the OpenFlowPlugin project, as it uses its capabilities to connect and interact with an OpenFlow switch.

The L2Switch project has the following features/components:

• Packet handler: Decodes the incoming packets, and dispatches them appropriately. It defines a packet lifecycle in three stages:
  1. Decode
  2. Modify
  3. Transmit
• Loop remover: Detects loops in the network and removes them.
• Arp handler: Handles ARP packets provided by the packet handler.
• Address tracker: Gathers MAC and IP addresses from network entities.
• Host tracker: Tracks hosts' locations in the network.
• L2Switch main: Installs flows on the switches present in the network.

This recipe requires an OpenFlow switch. If you don't have any, you can use a Mininet-VM with OvS installed.

You can download Mininet-VM from their website https://github.com/mininet/mininet/wiki/Mininet-VM-Images. All versions should work.

This recipe will be presented using a Mininet-VM with OvS 2.0.2.

Perform the following steps:

1. Start your OpenDaylight distribution using the karaf script. Using this script will give you access to the Karaf CLI:

$ ./bin/karaf 

2. Install the user-facing feature responsible for pulling in all dependencies needed to enable basic distributed switching:

opendaylight-user@root>feature:install odl-l2switch-switch-ui  

It might take a few minutes to complete the installation.

3. Creating a network using Mininet:

• Log in to Mininet-VM using:
  • Username: mininet
  • Password: mininet
• Clean current Mininet state:

If you're using the same instance as before, you want to clear its state. We previously created one bridge, br0, so let's delete it:

mininet@mininet-vm:~$ sudo ovs-vsctl del-br br0  

• Create the topology:

In order to do so, use the following command:

mininet@mininet-vm:~$ sudo mn --controller=remote,ip=${CONTROLLER_IP}--topo=linear,3 --switch ovsk,protocols=OpenFlow13  

Using this command will create a virtual network provisioned with three switches that will connect to the controller specified by ${CONTROLLER_IP}. The previous command will also set up links between switches and hosts.

We will end up with three OpenFlow nodes in the opendaylight-inventory:

• Type: GET
• Headers:

Authorization: Basic YWRtaW46YWRtaW4=

• URL: http://localhost:8080/restconf/operational/opendaylight-inventory:nodes

This request will return the following:

            --[cut]- 
      { 
        "id": "openflow:1", 
            --[cut]- 
      }, 
      { 
        "id": "openflow:2", 
            --[cut]- 
      }, 
      { 
        "id": "openflow:3", 
            --[cut]- 

4. Generate network traffic using mininet.

Between two hosts using ping:

mininet> h1 ping h2 

The preceding command will cause host1 (h1) to ping host2 (h2), and we can see that host1 is able to reach h2.

Between all hosts:

mininet> pingall 

The pingall command will make all hosts ping all other hosts.

5. Checking address observations.

This is done thanks to the address tracker that observes address tuples on a switch's port (node-connector).

This information will be present in the OpenFlow node connector and can be retrieved using the following request (for openflow:2, which is the switch 2):

• Type: GET
• Headers:

Authorization: Basic YWRtaW46YWRtaW4=

• URL: http://localhost:8080/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/node-connector/openflow:2:1

This request will return the following:

{ 
  "nodes": { 
    "node": [ 
      { 
        "id": "openflow:2", 
        "node-connector": [ 
          { 
            "id": "openflow:2:1", 
            --[cut]-- 
            "address-tracker:addresses": [ 
              { 
                "id": 0, 
                "first-seen": 1462650320161, 
                "mac": "7a:e4:ba:4d:bc:35", 
                "last-seen": 1462650320161, 
                "ip": "10.0.0.2" 
              } 
            ] 
          }, 
            --[cut]-- 

This result means the host with the mac address 7a:e4:ba:4d:bc:35 has sent a packet to switch 2 and that port 1 of switch 2 handled the incoming packet.

6. Checking the host address and attachment point to the node/switch:

• Type: GET
• Headers:

Authorization: Basic YWRtaW46YWRtaW4=

• URL: http://localhost:8080/restconf/operational/network-topology:network-topology/topology/flow:1/

This will return the following:

            --[cut]-- 
<node> 
    <node-id>host:c2:5f:c0:14:f3:1d</node-id> 
    <termination-point> 
        <tp-id>host:c2:5f:c0:14:f3:1d</tp-id> 
    </termination-point> 
    <attachment-points> 
        <tp-id>openflow:3:1</tp-id> 
        <corresponding-tp>host:c2:5f:c0:14:f3:1d</corresponding-tp> 
        <active>true</active> 
    </attachment-points> 
    <addresses> 
        <id>2</id> 
        <mac>c2:5f:c0:14:f3:1d</mac> 
        <last-seen>1462650434613</last-seen> 
        <ip>10.0.0.3</ip> 
        <first-seen>1462650434613</first-seen> 
    </addresses> 
    <id>c2:5f:c0:14:f3:1d</id> 
</node> 
            --[cut]-- 

address contains information about the mapping between the MAC address and the IP address, and attachment-points defines the mapping between the MAC address and the switch port.

7. Checking the spanning tree protocol status for each link.

The spanning tree protocol status can be either forwarding, meaning packets are flowing on an active link, or discarding, indicating packets are not sent as the link is inactive.

To check the link status, send this request:

• Type: GET
• Headers:

Authorization: Basic YWRtaW46YWRtaW4=

• URL: http://localhost:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:2/node-connector/openflow:2:2

This will return the following:

{ 
  "node-connector": [ 
    { 
      "id": "openflow:2:2", 
                  --[cut]-- 
      "stp-status-aware-node-connector:status": "forwarding", 
      "opendaylight-port-statistics:flow-capable-node-connector-statistics": {} 
      } 
    } 
  ] 
} 

In this case, all packets coming in port 2 of switch 2 will be forwarded on the established link.

8. Checking created links.

In order to check the links created, we are going to send the same request as the one sent at step 6, but we will focus on a different part of the response:

• Type: GET
• Headers:

Authorization: Basic YWRtaW46YWRtaW4=

• URL: http://localhost:8080/restconf/operational/network-topology:network-topology/topology/flow:1/

The different part this time is the following:

            --[cut]-- 
<link> 
    <link-id>host:7a:e4:ba:4d:bc:35/openflow:2:1</link-id> 
    <source> 
        <source-tp>host:7a:e4:ba:4d:bc:35</source-tp> 
        <source-node>host:7a:e4:ba:4d:bc:35</source-node> 
    </source> 
    <destination> 
        <dest-node>openflow:2</dest-node> 
        <dest-tp>openflow:2:1</dest-tp> 
    </destination> 
</link> 
<link> 
    <link-id>openflow:3:1/host:c2:5f:c0:14:f3:1d</link-id> 
    <source> 
        <source-tp>openflow:3:1</source-tp> 
        <source-node>openflow:3</source-node> 
    </source> 
    <destination> 
        <dest-node>host:c2:5f:c0:14:f3:1d</dest-node> 
        <dest-tp>host:c2:5f:c0:14:f3:1d</dest-tp> 
    </destination> 
</link> 
            --[cut]-- 

It represents links that were established while setting the topology earlier. It also provides the source, destination node, and termination point.

It leverages the OpenFlowPlugin project providing the basic communication channel between OpenFlow capable switches and OpenDaylight. The layer 2 discovery is handled by an ARP listener/responder. Using it, OpenDaylight is able to learn and track network entity addresses. Finally, using graph algorithms, it is able to detect the shortest path and remove loops within the network.

It is possible to change or increase basic configuration of the L2Switch component to perform more accurate operations.

We have presented L2Switch usage with the default configuration.

To change the configuration, here are the steps to follow:

1. Execute the two first points mentioned previously.
2. Stop OpenDaylight:

opendaylight-user@root>logout  

3. Navigate to $ODL_ROOT/etc/opendaylight/karaf/.
4. Open the configuration file you want to modify.
5. Perform your modification.

6. Save the file and re-execute the steps mentioned in the How to do it section.

The new configuration should now be applied.