look into niky's weird flowmod expansion

[billsnow]

The weird expansion that we saw, is that although the flow_mod as given it was allowed by the flowspace rules, the FV installed 3 extra flows. In particular in the FV there were the following rules for a slice : rule 60: FlowEntry[dpid=[00:00:00:12:e2:b8:f3:d0],ruleMatch=[OFMatch[tp_dst=9080]],actionsList=[Slice:smartre=4],id=[104771450],priority=[150],] rule 61: FlowEntry[dpid=[00:00:00:12:e2:b8:f3:d0],ruleMatch=[OFMatch[tp_src=9080]],actionsList=[Slice:smartre=4],id=[104773029],priority=[150],] rule 62: FlowEntry[dpid=[00:00:00:12:e2:b8:f3:d0],ruleMatch=[OFMatch[tp_dst=9081]],actionsList=[Slice:smartre=4],id=[104774619],priority=[150],] rule 63: FlowEntry[dpid=[00:00:00:12:e2:b8:f3:d0],ruleMatch=[OFMatch[tp_src=9081]],actionsList=[Slice:smartre=4],id=[104776183],priority=[150],] rule 64: FlowEntry[dpid=[00:00:00:12:e2:b8:f3:d0],ruleMatch=[OFMatch[tp_dst=9082]],actionsList=[Slice:smartre=4],id=[104777748],priority=[150],] rule 65: FlowEntry[dpid=[00:00:00:12:e2:b8:f3:d0],ruleMatch=[OFMatch[tp_src=9082]],actionsList=[Slice:smartre=4],id=[104779388],priority=[150],] I assume that all these rules are connected with OR, i.e. if the packet match any of these rules it will be given the the smartre slice. When the controller of the slice tries to install a flow of the type tp_src=9080 and tp_dst=* then this according to rule 61 is allowed, and it doesn't conflict with any other rules, so it should be installed as is, however I think that multiple rules are installed : tp_src=9080 and tp_dst=9080 (from rule 60) tp_src=9080 and tp_dst=9081 (from rule 62) tp_src=9080 and tp_dst=9082 (from rule 64) and tp_src=9080 and tp_dst=* (from rule 61) The first three flows are redundant. I am not convinced that this is a bug, but given that the last rule includes the other three then only the last one should be installed. You can imagine that if there are more wildcards in the flow then the number of flows that are installed might grow significantly. Also out of curiosity, what will happen if there is a different slice that has a higher priority rule for only one of tp_dst, let's say the aster*X tp_dst 10001? Will the FV install a flow for all the possible tp_dst other than 10001, or there is a way to install a flow that would negate a port, i.e. tp_dst!=10001?

Comments
Comment by Niky Riga [ 16/Aug/11 ] I was able to reproduce this problem, in a simpler setting. I used the same setup described above so the description is still valid (minus the flowspace rule numbers). I have captured FV's configuration file and the tcpdumps between the flowvisor and the controller and the flowvisor and the switches, which are attached here. When the controller tries to install a flow that wildcards everything but the TP_SRC field (e.g pkt 45 in fv_ctrl.pcap), the fv installs 4 flows at the same priority (last 4 flowmods in pkt 103 in fv_sw.pcap) where the first 3 are redundant since the fourth one covers them and the fourth is actually the correct flowmod based to the flowspace.

Comment by William Snow [ 01/Oct/12 ] This needs to be turned into a test case before closing

Original Jira issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-44