Day 12: Master Slave SDN Controller Architecture

In the previous post, I was struggling to figure out why all controllers can install flows in all switches irrespective of the code. Well, today the mystery is getting resolved.

I found this book that explains beautifully the various roles that a controller can play. The three roles are:

• Equal : this happens by default all the equal controllers in a network that are connected to the switch can add and delete flows from it
• Slave: it has a read-only limitation to the switch openflow tables
• Master: very similar to the switch, but only 1 master can be connected to the switch at that point of time, and no other flows can intercept the communication between switch and master.

I highly recommend you go through the above link to get a better picture.

Since the default role of any controller is "Equal", we couldn't really differentiate between the three controller flows yesterday. But one good news from this is that we don't really need extensive coding to assign controller roles, in fact it is just a one line code. But the one line code ensures that a particular controller remains the master throughout the communication. Thus coding will be required to dynamically determine and change the role of the controllers. We shall be looking into the same in a few days.

Now, let's look at how to achieve the master-slave architecture. 

1. Firstly, build the network till the point where we had built it in the previous post
2. Continuing where we left off, we now have to find out the role of the controller it is presently in*. To do this, we shall execute the below code:
   
   > ryu-manager ryu.app.ofctl_rest ryu/app/simple_switch_13.py (Controller terminal)
   > sudo apt-get install curl (open new terminal)
   > curl -X GET http://localhost:8080/stats/switches
      This will give an array as an output: [1,2] which signifies the DPIDs of the switches connected in the network
   
   > curl -X GET http://localhost:8080/stats/role/switch-dpid
   > curl -X POST -d '{"dpid": switch-dpid, "role":"MASTER"}'
   > curl -X POST -d '{"dpid": switch-dpid, "role":"EQUAL"}'
   > curl -X POST -d '{"dpid": switch-dpid, "role":"SLAVE"}'
3. Run the pingall command on mininet to see the connections
4. With this, you have successfully built the master-slave architecture

*The role of the controller will reside in the SDN switch. Why is this so? This is because one switch may be connected to more than one controller. Each controller can have a different role with respect to that switch. The same controller can act as a Slave to one switch and as a master to another. This is the reason the role of the controller is present in the switch, since essentially the controller code is same.

Thus to retrieve the role, we need to ask the switch. Depending on what role the controller is already serving the switch, we can change the role using the above given commands.

If you observe carefully, we are executing an extra Ryu library today - ofctl_rest. This is to enable the controller to talk to and forth between the switch. The curl commands serve as the REST APIs which need ofctl_rest running in the background.

One thing I have not been able to do today is experiment with how Master, Equal and Slave configurations affect the flow table installations. We shall experiment with the same in tomorrow's post.

Also, if you happen to know the curl commands to drop packets with certain match fields, do let me know. I'm having a little trouble there.

PS: 

> curl -X POST -d '{"dpid":1, "priority":1, "match":{"ipv4_src": SRC_ADDR, "ipv4_dst": DST_ADDR}, "actions": []}' http://localhost:8080/stats/flowentry/add

is not working for me, although it doesn't give any errors.