Okay as you saw in last post, we have come up with a set of approaches to solve our problem statement. In this blog we will tell you the modifications we did in OpenVswitch for supporting multiple controllers.
We modified the 'ovs-vsctl' file in order to give a new command-line argument support. The new argument was "net-split" on specifying which a function called as "cmd_split_network()" will be called. The command is called from Mininet like this:
self.cmd( 'ovs-vsctl net-split' , obj )
Here ovs-vsctl is being called with an argument net-split and passing an object which contains the details of how the network should be split. In OpenVswitch they have used callback functions to be called whenever a command-line is being specified. So we had to register the function "cmd_split_network()' we wrote with the 'net-split' command.
{"net-split", 1, 1, NULL, cmd_split_network, NULL, "", RW}
So when Mininet calls ovs-vsctl with net-split argument, the function 'cmd_split_network()' is called. This function creates a file in which we will store the details of network split i.e., a table-like data will be stored which the switch can refer to when a new packet comes in and then find out which controller it has to talk to depending on the source address of the incoming packet.
Wow..if only life was that simple!! We have modified ovs-vsctl to create a file which will store the data sent by Mininet. But the problem here is that when Mininet creates processes for switches and hosts, it gives each process a separate code-space but they all share they same file system. So when a file for forwarding is created by a switch, all switches share the same file. We can solve this by appending each switches forwarding instructions in each row but then there is another problem. There is clarity between the commonality of how both Mininet and OpenVswitch refer or distinguishes each switch so that a switch will look at only its row in the file and know which controller to talk to.
As we now, we are trying to solve the above problem. You will see how much we succeed in our next post.
We modified the 'ovs-vsctl' file in order to give a new command-line argument support. The new argument was "net-split" on specifying which a function called as "cmd_split_network()" will be called. The command is called from Mininet like this:
self.cmd( 'ovs-vsctl net-split' , obj )
Here ovs-vsctl is being called with an argument net-split and passing an object which contains the details of how the network should be split. In OpenVswitch they have used callback functions to be called whenever a command-line is being specified. So we had to register the function "cmd_split_network()' we wrote with the 'net-split' command.
{"net-split", 1, 1, NULL, cmd_split_network, NULL, "", RW}
So when Mininet calls ovs-vsctl with net-split argument, the function 'cmd_split_network()' is called. This function creates a file in which we will store the details of network split i.e., a table-like data will be stored which the switch can refer to when a new packet comes in and then find out which controller it has to talk to depending on the source address of the incoming packet.
Wow..if only life was that simple!! We have modified ovs-vsctl to create a file which will store the data sent by Mininet. But the problem here is that when Mininet creates processes for switches and hosts, it gives each process a separate code-space but they all share they same file system. So when a file for forwarding is created by a switch, all switches share the same file. We can solve this by appending each switches forwarding instructions in each row but then there is another problem. There is clarity between the commonality of how both Mininet and OpenVswitch refer or distinguishes each switch so that a switch will look at only its row in the file and know which controller to talk to.
As we now, we are trying to solve the above problem. You will see how much we succeed in our next post.
No comments:
Post a Comment