Hi Panos, I am glad to hear that you are using FlowVisor. Responses inline.
> We are currently building an openflow setup on our production > network and we have the following : > > HP Openflow switch <--> Flowvisor ------> Experimental-Floodlight-Controller > |-------------> > Fallback-Floodlight-Controller > > We currently have two slices on flowvisor (each on its own > FlowEntry), one slice pointing to the Experimental-Floodlight controller with > high priority and another slice pointing to our Fallback-Floodlight > controller with lower priority. The idea is that everything goes to the > Experimental-Floodlight controller but if we have to change it and the > controller is not up, everything should be forwarded to the > Fallback-Floodlight controller so that normal network operation continues. Unfortunately this is not possible for the time being. If you configure two slices which share the same flowspace distinguished only by priority then all the control traffic goes to the slice with the higher priority. If that controller is down, then nothing is forwarded. I would consider implementing such a feature, so feel free to submit a feature request. Although, most controllers when they initially connect to a switch clear its flow table, this could have disastrous effects in your scenario. > > It seems that the current behavior we are seeing is that if the > Experimental-Floodlight controller is down, nothing gets forwarded to our > Fallback-Floodlight controller. Do I understand it correctly that if we put > both slices next to each other in one FlowEntry, then each request will be > broadcasted to both slices, thus having the Fallback-Floodlight-Controller > responding even when the Experimental-Floodlight-Controller would be running? Unfortunately, there can only be one writer slice per flowspace. Sending the same message to multiple controllers is dangerous because for example only one controller can really take action on a given flowmod. In your setup, I would recommend that you slice your network into a production environment and an experimental one. In this way people, relying on the proper functioning of the network are not affected by the experimental controller going down. > > Thanks a lot for your help, > Panos > > > > > > > > _______________________________________________ > openflow-discuss mailing list > [email protected] > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss _______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
