[pox-dev] Problems with spanning tree when running multiple controllers

[Murphy McCauley]

The discovery and spanning_tree components assume that all switches use the same controller.  This controller builds up a single "view" of the network.  This assumption generally also works if you have multiple controllers controlling "islands" of switches, with no loops between islands.

In your case, however, this assumption doesn't hold true, and each controller can only get a sort of partial view of the network which sort of overlaps in responsibility with the partial view held by another controller.

To solve this sort of problem, you need to incorporate controller-to-controller communication in one way or another.  The possibilities for accomplishing this comprise a huge space.  In my opinion, picking the "right" point in this space depends on the goals, environment, and so on.  Also note that SDN starts to look like traditional networking here.  For example, the propagation of routes through a conventional routing protocol is a fairly strong analog for sharing of data between controllers.  Indeed, one could use an OpenFlow-based implementation of traditional protocols (STP, ISIS, etc.) to solve problems of inter-controller information.  Conceptually there's not really much difference except that in traditional networking, there are the same number of control elements and packet-handling elements, and in SDN there's no fixed relationship (though a lot of SDN work -- including the discovery and spanning_tree components in POX -- have focused on the case of one control element and N packet-handling elements).

It might be worth asking: do you really need to do discovery/spanning tree?  Could you just precompute the paths to use?

-- Murphy

On Dec 3, 2013, at 2:05 PM, Maciej Korczyński <maciej.korczynski at gmail.com> wrote:

> Hi everyone,
> I've built a mininet network composed of 20 switches in a full mesh (or tree) with multiple hosts attached to each of switches. When I use only one pox controller then all hosts can communicate each other without any problems. However, I need two controllers. I successfully created the scenario with two controllers (c0 and c1). Every switch with a probability equal to 0.5 is assigned to either c0 or c1 (please see my partial code below). 
> Here is my problem: when I run two pox controllers, some hosts can't communicate each other. I also put some logs from controllers at the end. It's clearly a problem with openflow.discovery openflow.spanning_tree (I tried to run my scenario with a loop free tree topology and without above mentioned openflow components and it worked fine), but I need them to provide connectivity in topologies with loops (e.g. full mesh).
> Thank you very much for your help,
> Maciej
> 
> /.................................................................................................................................................................................
> ./pox.py forwarding.l2_learning openflow.of_01 --port=6633 openflow.discovery openflow.spanning_tree --no-flood --hold-down
> ./pox.py forwarding.l2_learning openflow.of_01 --port=6644 openflow.discovery openflow.spanning_tree --no-flood --hold-down
> /.................................................................................................................................................................................
> 
> if __name__ == '__main__':
>     lg.setLogLevel( 'info' )
>     info( "*** Initializing Mininet and kernel modules\n" )
>     OVSKernelSwitch.setup()
>     info( "*** Creating network\n" )
> 
>     #********************* TOPOLOGY **********************
>     #maximal number of connected hosts
>     b = 20
>     a = 20
>     topology = Treepro(a,b) # Mesh7pro(a,b,1)
> 
>     #********************* CONTROLLERS **********************
> 
>     # our controller
>     c0 = RemoteController( 'c0', ip='127.0.0.1', port=6633)
>     # dump controller (simple switching)
>     c1 = RemoteController( 'c1', ip='127.0.0.1', port=6644)
> 
>     prob = 0.5
>     cmap = {}
> 
>     for i in range(0,a):
> 	if (random.random() < prob):
> 		cmap['s%s' % (i+1)] = c1
> 	else:
> 		cmap['s%s' % (i+1)] = c0
> 
>     class MultiSwitch( OVSKernelSwitch ):
>     	def start( self, controllers ):
>         	return OVSKernelSwitch.start( self, [ cmap[ self.name ] ] )
> 
> 
>     #********************* BUILD NETWORK **********************
>     # network = Mininet( topo=topology, controller=lambda name: RemoteController( name, defaultIP='127.0.0.1' ), listenPort=6632 , switch=OVSKernelSwitch)
> 
>     network = Mininet( topo=topology, switch=MultiSwitch, build=False )
>     network.controllers = [ c0, c1 ]
>     network.build()
> 
>     info( "*** Starting network\n" )
>     network.start()
> 
> 
>    #********** NETWORK MAINTENANCE AND ATTACK ****************
> 
>     sleep(20) # spaning tree
>     info( "*** Running ping test\n" )
> 
>     pingNet(network)
>     info( "*** Sleeping, soon finishing\n")
>     sleep(5)
> 
>     info( "*** Stopping network\n" )
>     network.stop()
> 
> /.................................................................................................................................................................................
> 
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:openflow.discovery:Received LLDP packet from unknown switch
> INFO:openflow.discovery:Received LLDP packet from unknown switch
> INFO:openflow.discovery:Received LLDP packet from unknown switch
> INFO:openflow.discovery:Received LLDP packet from unknown switch
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:openflow.discovery:Received LLDP packet from unknown switch
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:packet:(dhcp parse) warning DHCP packet data too short to parse header: data len 86
> INFO:openflow.discovery:Received LLDP packet from unknown switch
> 
> 
> 
>