OpenDaylight Cookbook: Deploy and operate software-defined networking in your organization

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:

$ ./bin/karaf

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

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

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"

${CONTROLLER_IP} is the IP address of the host running OpenDaylight.

We're establishing a TCP connection. For a more secure connection, we could use TLS protocol; however, this will not be included in this book as this is beyond the scope of the book.

Once the OpenFlow switch is connected, send the following request to get information regarding the switch:

Authorization: Basic YWRtaW46YWRtaW4=

This will list all the nodes under the opendaylight-inventory subtree of MD-SAL that stores OpenFlow switch information. As we connected our first switch, we should have only one node there. It will contain all the information that the OpenFlow switch has, including its tables, its ports, flow statistics, and so on.

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.

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:

$ ./bin/karaf 

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

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

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

This will simulate one device that will be bound to port 17830.

Send the following request using RESTCONF:

By looking closer at the URL you will notice that the last part is new-netconf-device. This must match the node-id that we will define in the payload.

Accept: application/xml

Content-Type: application/xml

Authorization: Basic YWRtaW46YWRtaW4=

<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.

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 

Once the new netconf-connector is created, some useful metadata is written into the MD-SAL's operational data store under the network-topology subtree. To retrieve this information, you should send the following request:

Authorization: Basic YWRtaW46YWRtaW4=

We're using new-netconf-device as the node-id because this is the name we assigned to the netconf-connector in a previous step.

This request will provide information about the connection status and device capabilities. The device capabilities are all the YANG models the NETCONF device is providing in its hello-message that was used to create the schema context.

As mentioned previously, the netconf-connector contains various configuration elements. Those fields are non-mandatory, with default values. If you do not wish to override any of these values, you shouldn't provide them:

Using this configuration, your payload would look like this:

<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:

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.

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

Perform the following steps:

$ ./bin/karaf

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

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

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:

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.

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.

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:

$ ./bin/karaf

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

It might take a few minutes to complete the installation.

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

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:

Authorization: Basic YWRtaW46YWRtaW4=

This request will return the following:

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

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.

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):

Authorization: Basic YWRtaW46YWRtaW4=

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.

Authorization: Basic YWRtaW46YWRtaW4=

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.

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:

Authorization: Basic YWRtaW46YWRtaW4=

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.

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:

Authorization: Basic YWRtaW46YWRtaW4=

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.

opendaylight-user@root>logout

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

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

In order to use LACP, you have to ensure that legacy (non-OpenFlow) switches are configured with the LACP mode active with a long timeout to allow the LACP plugin to respond to its messages.

The sample code for this recipe is available at:

https://github.com/jgoodyear/OpenDaylightCookbook/tree/master/chapter1/chapter1-recipe5

Perform the following steps:

$ ./bin/karaf

opendaylight-user@root>feature:install odl-lacp-ui

It might take a few minutes to complete the installation.

In order to do so, use the following command:

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

This command will create a virtual network containing one switch, connected to ${CONTROLLER_IP}.

We will end up with one OpenFlow node in the opendaylight-inventory:

Authorization: Basic YWRtaW46YWRtaW4=

This request will return the following:

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

mininet@mininet-vm:~$ sudo ovs-ofctl -O OpenFlow13 dump-flows s1
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x3000000000000003, duration=185.98s, table=0, n_packets=0, n_bytes=0, priority=5,dl_dst=01:80:c2:00:00:02,dl_type=0x8809 actions=CONTROLLER:65535

The flow is using ether type 0x8809, which is the one defined for LACP.

mininet> py net.addLink(s1, net.get('h1'))
<mininet.link.Link object at 0x7fe1fa0f17d0>
mininet> py s1.attach('s1-eth2')

Use the terminal window opened at step 4 to access this directory and create a file bonding.conf with this content:

alias bond0 bonding 
options bonding mode=4

mode=4 refers to LACP, and by default the timeout is set to be long.

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 ${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')

Make sure to change ${MAC_ADDRESS} with an appropriate MAC address.

Once the created bond0 interface is up, host1 will send LACP packets to switch1. OpenDaylight LACP's module will create the link aggregation group on the switch1 (s1).

To visualize the bound interface, you can use the following command:

mininet> py net.get('h1').cmd('cat /proc/net/bonding/bond0')

mininet@mininet-vm:~$ sudo ovs-ofctl -O Openflow13 dump-groups s1
OFPST_GROUP_DESC reply (OF1.3) (xid=0x2):
group_id=41238,type=select,bucket=weight:0,actions=output:1,bucket=weight:0,actions=output:2
group_id=48742,type=all,bucket=weight:0,actions=drop

Let's focus on the first entry: the flow type is select, which means that the packets are processed by a single bucket in the group as well as have two buckets assigned with the same weight. Each bucket represents a given port on the switch, port 1 (s1-eth1) and 2 (s1-eth2) respectively, in this example.

sudo ovs-ofctl -O Openflow13 add-flow s1 dl_type=0x0806,dl_src=SRC_MAC,dl_dst=DST_MAC,actions=group:60169

It leverages the OpenFlowPlugin project providing the basic communication channel between OpenFlow capable switches and OpenDaylight. The LCAP project implements the Link Aggregation Control Protocol as a service in MD-SAL. Using the packet processing service, it will receive and process LACP packets. Based on a periodic state machine, it will define whether or not to maintain an aggregation.

This recipe does not require anything more than OpenDaylight itself.

The sample code for this recipe is available at:

https://github.com/jgoodyear/OpenDaylightCookbook/tree/master/chapter1/chapter1-recipe7

Perform the following steps:

$ ./bin/karaf

opendaylight-user@root>feature:install odl-aaa-authn

It might take a few minutes to complete the installation.

Authorization: Basic YWRtaW46YWRtaW4=

{ 
  "users": [ 
    { 
      "userid": "admin@sdn", 
      "name": "admin", 
      "description": "admin user", 
      "enabled": true, 
      "email": "", 
      "password": "**********", 
      "salt": "**********", 
      "domainid": "sdn" 
    }, 
    { 
      "userid": "user@sdn", 
      "name": "user", 
      "description": "user user", 
      "enabled": true, 
      "email": "", 
      "password": "**********", 
      "salt": "**********", 
      "domainid": "sdn" 
    } 
  ] 
}  

First, you need the userid that can be retrieved using the previous request. For this tutorial, we will use userid=user@sdn.

To update the password for this user, do the following request:

Authorization: Basic YWRtaW46YWRtaW4=

This is the basic admin/admin authorization. We will not modify this one.

{ 
  "userid": "user@sdn", 
  "name": "user", 
  "description": "user user", 
  "enabled": true, 
  "email": "", 
  "password": "newpassword", 
  "domainid": "sdn" 
} 

Once sent, you will receive the acknowledged payload.

You should now be logged in with the new, updated password for the user.

The AAA project supports role-based access control (RBAC) based on the Apache Shiro permissions system. It defines a REST application used to interact with the h2 database. Each table has its own REST endpoint that can be used using a REST client to modify the h2 database content, such as the user information.

This recipe will require three distinct VMs that will be spawned using Vagrant 1.7.4 https://www.vagrantup.com/downloads.html.

The Vagranfile for the VM is available at https://github.com/adetalhouet/cluster-nodes.

Perform the following steps:

The mentioned repository in the Getting ready section is providing a Vagrantfile spawning VMs with the following network characteristics:

These are the steps to follow:

$ git clone https://github.com/adetalhouet/cluster-nodes.git  
$ cd cluster-nodes 
$ export NUM_OF_NODES=3 
$ vagrant up

After a few minutes, to make sure the VMs are correctly running, execute the following command in the cluster-nodes folder:

$ vagrant status 
Current machine states: 
node-1                    running (virtualbox) 
node-2                    running (virtualbox) 
node-3                    running (virtualbox)

This environment represents multiple VMs. The VMs are all listed preceding with their current state. For more information about a specific VM, run vagrant status NAME.

The credentials of the VMs are:

We now have three VMs available at those IP addresses:

In order to deploy the cluster, we will use the cluster-deployer script provided by OpenDaylight:

$ git clone https://git.opendaylight.org/gerrit/integration/test.git 
$ cd test/tools/clustering/cluster-deployer/

You will need the following information:

192.168.50.151, 192.168.50.152, 192.168.50.153

vagrant/vagrant

$ODL_ROOT

$ cd templates/multi-node-test/ 
$ ls -1 
akka.conf.template 
jolokia.xml.template 
module-shards.conf.template 
modules.conf.template 
org.apache.karaf.features.cfg.template 
org.apache.karaf.management.cfg.template

We are currently located in the cluster-deployer folder:

$ pwd 
test/tools/clustering/cluster-deployer

We need to create a temp folder, so the deployment script can put some temporary files in there:

$ mkdir temp

Your tree architecture should look like this:

$ tree 
. 
├── cluster-nodes 
├── distribution-karaf-0.4.0-Beryllium.zip 
└── test 
    └── tools 
        └── clustering 
            └── cluster-deployer 
                ├── deploy.py 
                ├── kill_controller.sh 
                ├── remote_host.py 
                ├── remote_host.pyc 
                ├── restart.py 
                ├── temp 
                └── templates 
                    └── multi-node-test

Now let's deploy the cluster using this command:

$ python deploy.py --clean --distribution=../../../../distribution-karaf-0.4.0-Beryllium.zip --rootdir=/home/vagrant --hosts=192.168.50.151,192.168.50.152,192.168.50.153 --user=vagrant --password=vagrant --template=multi-node-test

If the process went fine, you should see similar logs while deploying:

https://github.com/jgoodyear/OpenDaylightCookbook/tree/master/chapter1/chapter1-recipe8

Let's use Jolokia to read the cluster's nodes data store:

Let's request on node 1, located under 192.168.50.151, its config data store for the network-topology shard:

Authorization: Basic YWRtaW46YWRtaW4=

{ 
    "request": { 
        "mbean": "org.opendaylight.controller:Category=Shards,name=member-1-shard-topology-config,type=DistributedConfigDatastore", 
        "type": "read" 
    }, 
    "status": 200, 
    "timestamp": 1462739174, 
    "value": { 
        --[cut]-- 
        "FollowerInfo": [ 
            { 
                "active": true, 
                "id": "member-2-shard-topology-config", 
                "matchIndex": -1, 
                "nextIndex": 0, 
                "timeSinceLastActivity": "00:00:00.066" 
            }, 
            { 
                "active": true, 
                "id": "member-3-shard-topology-config", 
                "matchIndex": -1, 
                "nextIndex": 0, 
                "timeSinceLastActivity": "00:00:00.067" 
            } 
        ], 
        --[cut]-- 
        "Leader": "member-1-shard-topology-config", 
        "PeerAddresses": "member-2-shard-topology-config: akka.tcp://[email protected]:2550/user/shardmanager-config/member-2-shard-topology-config, member-3-shard-topology-config: akka.tcp://[email protected]:2550/user/shardmanager-config/member-3-shard-topology-config", 
        "RaftState": "Leader", 
        --[cut]-- 
        "ShardName": "member-1-shard-topology-config", 
        "VotedFor": "member-1-shard-topology-config", 
        --[cut]-- 
} 

The result presents a lot of interesting information such as the leader of the requested shard, which can be seen under Leader. We can also see the current state (under active) of followers for this particular shard, represented by its id. Finally, it provides the addresses of the peers. Addresses can be found in the AKKA domain, as AKKA is the tool used to enable a node's wiring within the cluster.

By requesting the same shard on another peer, you would see similar information. For instance, for node 2 located under 192.168.50.152:

Authorization: Basic YWRtaW46YWRtaW4=

{ 
    "request": { 
        "mbean": "org.opendaylight.controller:Category=Shards,name=member-2-shard-topology-config,type=DistributedConfigDatastore", 
        "type": "read" 
    }, 
    "status": 200, 
    "timestamp": 1462739791, 
    "value": { 
        --[cut]-- 
        "Leader": "member-1-shard-topology-config", 
        "PeerAddresses": "member-1-shard-topology-config: akka.tcp://[email protected]:2550/user/shardmanager-config/member-1-shard-topology-config, member-3-shard-topology-config: akka.tcp://[email protected]:2550/user/shardmanager-config/member-3-shard-topology-config", 
        "RaftState": "Follower", 
        --[cut]-- 
        "ShardName": "member-2-shard-topology-config", 
        "VotedFor": "member-1-shard-topology-config", 
        --[cut]-- 
    } 
}  

We can see the peers for this shard as well as that this node is voted node 1 - to be elected the shard leader.

OpenDaylight clustering heavily relies on AKKA technology to provide the building blocks for the clustering components, especially for operations on remote shards. The main reason for using AKKA is because it suits the existing design of MD-SAL, as it is already based on the actor model.

OpenDaylight clustering components include: