Ah cool, glad you found your fix. In the PORT_MOD message the config hold the configuration for your port. The mask then allows you to select the field you would like to set. This way you can flip a single bit in your config value without changing the remaining values and use the mask to change only that bit and leave the rest as is. Make sense?
Cheers. -- Ali On 26 Dec 2013, at 23:02, Victor Torres <vit...@poli.ufrj.br> wrote: > Ali, > > Thanks again for the reply. I went a little bit deeper to investigate > it, and actually I think I've found the answer! > > It seems that the Spanning Tree algorithm we used (similar to the one > in POX repo) was sending PORT_MOD messages to the ports setting MASK > always to NO_FLOOD, causing FlowVisor to not expand the output action > correctly. Seems it was not FV's fault this time. =D > > But since we are at it, would you know the difference between these > CONFIG and MASK parameters of port_mod? I've searched a lot without > conclusion. > > Thanks again for the great help, and sorry for bothering with > something that, in the end, ended up not being FV. > > Wish you a happy new year! (with this solved, I'll get some sleep, and > no more OpenFlow in 2013 for me) > > > Best regards, > > Victor T. > > > On 27 December 2013 00:36, Ali Al-Shabibi <ali.al-shab...@stanford.edu> wrote: >> [Inline] >> >>> After investigating, I've figured out that the case was that, when a >>> host sent an ARP request (for the IP of the other host), POX received >>> a packet-in and then tried to put an output=FLOOD rule on the switch. >>> Without FlowVisor, the rule was installed OK, and all ports (except >>> for the packet in_port) were included in the action. But with >>> FlowVisor, only port 0 (local, right?) is included in the action. >>> >> >> Hmm that is very strange. Could you send me your flowspace configuration? >> >>> That slice currently has acces to ANY match in ALL dpids (via >>> flowspace). Then I tried putting that slice as the >>> "default_flood_perm" in FlowVisor's general config and the arp/ping >>> worked fine. >>> >>> If I may complement, I was checking out the way FlowVisor handles >>> output actions >>> (https://github.com/OPENNETWORKINGLAB/flowvisor/blob/1.4-MAINT/src/org/flowvisor/message/actions/FVActionOutput.java). >>> I think that by putting that slice in the "default_flood_perm", it >>> entered one of those "shortcuts" and executed fine. >>> >>> But, according to the last part of that .java, even if the slice >>> doesn't have "default_flood_perms", FlowVisor should translate that >>> OFP_FLOOD into all allowed ports of the slice (in that switch), right? >>> So that my ping would work even without those flood_perms. >> >> Yes that is correct, something seems to be broken here. Could you send me a >> packet capture of FV receiving FLOOD actions and rewriting them incorrectly. >> >>> >>> My original question was because, if I really need to have those >>> "default flood perms" to everyone trying an output=FLOOD, why not be >>> able to specify more than one slice per switch? >> >> You can only specify one slice because otherwise slices would receive >> packets for which they are not responsible for. The whole default floodperm >> feature is dangerous in general anyway. >> >>> >>> >>> Sorry for the long message and thanks again! >>> >>> >>> Best regards, >>> >>> Victor T. >>> >>> On 26 December 2013 18:40, Ali Al-Shabibi <ali.al-shab...@stanford.edu> >>> wrote: >>>> Hi Victor, >>>> >>>> By default FlowVisor tags LLDP packets coming from a controller so that >>>> when the packet comes back it can figure out which slice/controller to >>>> send it to. This way every controller sees the entire physical network >>>> (modulo its flowspace). Does this not work for you? Could you explain >>>> what you are trying to achieve? >>>> >>>> Cheers. >>>> >>>> -- >>>> Ali >>>> >>>> On 25 Dec 2013, at 20:09, Victor Torres <vit...@poli.ufrj.br> wrote: >>>> >>>>> Hello, >>>>> >>>>> I would like to know if there is a way to put multiple slices to >>>>> "default flood permissions" over all DPIDs, or to put multiple slices >>>>> as having Flood Permissions over a specific DPID. Everytime I try, it >>>>> overwrites it instead. >>>>> >>>>> This is critical for a testbed environment we are setting up. If there >>>>> is a reason for this being not implemented, I would be very glad if >>>>> anyone could tell me. >>>>> >>>>> >>>>> >>>>> Thanks in advance, >>>>> >>>>> Victor T. >>>>> _______________________________________________ >>>>> openflow-discuss mailing list >>>>> openflow-discuss@lists.stanford.edu >>>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>> >> _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
