> > After your very helpful reply, I think my question summarizes to: the > neoMatch struct does have a wildcarded Vlan, but shouldn't it be > changed to 22 (in my previous test) by the > "setDataLayerVirtualLan(22)" before the compare? Are you saying that > "setDataLayerVirtualLan()" won't change the field if the original is > Wildcarded? That would explain a lot. >
No the setDataLayerVirtualLan will set the value, but sadly it does not modify the wildcard field. So, arguably, FV should do that when it is checking values. If you feel strongly about this please feel free to submit a bug report. > I'm sorry for insisting on this, but may I have access to the source > of the "org.openflow.protocol" package? FlowVisor imports and uses > this (like messages and match structures) a lot of times and I can't > look into it in detail because it seems to be missing sources. If you > could give me any direction on how to get/understand it I would be > really appreciated. > openflowj is available at https://bitbucket.org/openflowj/openflowj > > > Best regards, > > Victor T. > > > On 13 September 2013 03:31, Ali Al-Shabibi <[email protected]> > wrote: >> Hi Victor, >> >> I believe there is a case which isn't caught by my code. If a flowmod >> wildcards the vlan field, the neoMatch struct will also wildcard the vlan >> field and there this will be ignored in the matching process and therefore >> result in the behaviour you see. >> >> What you want to express is that there was no vlan tag in this packet before >> this flowmod. So I think what you should set is the vlan id in the match to >> 0xffff and unwildcard the vlan field. This should solve you problem. >> >> Having said all this, it may make sense for the action to unwildcard the >> field it is verifying, I need to think about that a little. >> >> Let me know if that works for you. >> >> Cheers. >> >> -- >> Ali >> >> On Sep 12, 2013, at 6:01 PM, Victor Torres <[email protected]> wrote: >> >>> Hello Ali, >>> >>> I'm sorry for not supporting my statement before. I've prepared some >>> logs of what I did, which I hope will help you to understand better: >>> >>> 1) This is the FlowSpace: http://pastebin.com/FMNzVNaF >>> It contains only one rule, and its match is only dl_vlan = 1. >>> >>> 2) This is the POX code I'm using to send the FlowMod: >>> http://pastebin.com/m8tnqfP8 >>> Worth noticing that dl_vlan is Wildcarded, and the Action tries to >>> change de dl_vlan to 22. >>> >>> 3) This is the FlowVisor log: http://pastebin.com/xS8kdTUq >>> I've shut it down as soon as the flow was installed so as to not >>> generate too much text. I've tried signaling in the file where the >>> test Flow_Mod begins processing. >>> >>> 4) This is the switches' Flow Table, as reported by Mininet: >>> http://pastebin.com/x8M32QrJ >>> The wildcarded dl_vlan was rewritten to the allowed value (1), the >>> dl_src and dl_dst were maintained from the original Flow_Mod and the >>> Action is still changing dl_vlan to 22. >>> >>> I hope this is helpful, is there anything else I can provide that can help >>> more? >>> >>> By the way, if I may ask, is it possible to get sources for OFMatch >>> and the other structures that don't seem to be included in the >>> FlowVisor java source? With that I could investigate the problem >>> further. >>> >>> >>> Best regards, >>> >>> Victor T. >>> >>> On 12 September 2013 15:50, Ali Al-Shabibi <[email protected]> >>> wrote: >>>> I just reproduced this on a 1.2 FlowVisor and the flowmod is disallowed as >>>> expected. >>>> >>>> Could you send me you flowspace and perhaps a packet capture of whats >>>> going on? >>>> >>>> >>>> Cheers. >>>> >>>> -- >>>> Ali >>>> >>>> On Sep 12, 2013, at 11:09 AM, Victor Torres <[email protected]> wrote: >>>> >>>>> Hello Ali, >>>>> >>>>> According to fvctl: >>>>> >>>>> FlowVisor version : flowvisor-1.2.0 >>>>> FlowVisor DB version : 2 >>>>> >>>>> The bug in the previous version was about this >>>>> "setDataLayerVirtualLan()"? Because this behaviour seems to repeat for >>>>> nw_src, nw_dst, dl_src, dl_dst, tp_src and tp_dst, and they all seem >>>>> to use a similar method. >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Victor T. >>>>> >>>>> On 12 September 2013 14:55, Ali Al-Shabibi <[email protected]> >>>>> wrote: >>>>>> Hmm this sounds like a bug that we had in a previous version of FV. >>>>>> Could you tell me what version you are running? >>>>>> >>>>>> Cheers. >>>>>> >>>>>> -- >>>>>> Ali >>>>>> >>>>>> On Sep 12, 2013, at 4:30 AM, Victor Torres <[email protected]> wrote: >>>>>> >>>>>>> Hello Ali, >>>>>>> >>>>>>> I can't really thank you enough! I do have a situation I would like >>>>>>> some help with. >>>>>>> >>>>>>> Given the previous example situation, the fact is that I've tried it >>>>>>> in a "real" (mininet) setup and the FLOW_MOD from Alice do arrive at >>>>>>> the switch performing the action (SetVlanID(22)) even though its not >>>>>>> permitted. To be more precise, if I send a FlowMod matching dl_vlan >>>>>>> other than 1 (permitted in our example FlowSpace), it promptly >>>>>>> generates an error, indicating that there were no matches. >>>>>>> >>>>>>> Since it yields an error in the case dl_vlan != 1, and it doesn't for >>>>>>> dl_vlan=* (wildcard), I do believe the problem is not in the MATCH >>>>>>> mechanism but actually in the >>>>>>> "neoMatch.setDataLayerVirtualLan(this.virtualLanIdentifier);", because >>>>>>> it seems that the dl_vlan is not being updated to the intended >>>>>>> Action's dl_vlan (22 in the example) for the match test. >>>>>>> >>>>>>> I don't seem to have clear access to both the source for the mentioned >>>>>>> method or the match mechanism, so I would like to ask you if you can >>>>>>> confirm this behaviour. >>>>>>> >>>>>>> >>>>>>> Thanks again! >>>>>>> >>>>>>> Victor T. >>>>>>> >>>>>>> On 12 September 2013 03:17, Ali Al-Shabibi >>>>>>> <[email protected]> wrote: >>>>>>>>> Thank you again and I'm sorry for bothering so much. After all this >>>>>>>>> time theres one thing that I couldn't really figure out: >>>>>>>> >>>>>>>> No worries, it's really not a problem. >>>>>>>> >>>>>>>>> >>>>>>>>> Suppose I have only one FlowSpace rule giving WRITE permissions to >>>>>>>>> ALICE, and the match of this FlowSpace rule is dl_vlan=1. ALICE then >>>>>>>>> tries a FLOW_MOD (with an all-wildcarded match) with >>>>>>>>> Action:SetVlanID(22) >>>>>>>>> >>>>>>>>> Given this piece of code from FVActionVirtualLanId and what I think >>>>>>>>> it does: >>>>>>>>> >>>>>>>>> 1) FVMatch neoMatch = new FVMatch(match); >>>>>>>>> 2) neoMatch.setDataLayerVirtualLan(this.virtualLanIdentifier); >>>>>>>>> 3) List<FlowEntry> flowEntries = >>>>>>>>> fvClassifier.getSwitchFlowMap().matches(fvClassifier.getDPID(), >>>>>>>>> neoMatch); >>>>>>>>> >>>>>>>>> 1) Create a new match from the match of the FLOW_MOD (which was all >>>>>>>>> wildcarded). This means the 'neoMatch' will be exactly the same as >>>>>>>>> 'match', right? (in this case, all wildcarded) >>>>>>>> >>>>>>>> Yup, that's exactly right. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 2) The 'neoMatch' created earlier will have its dl_vlan changed from >>>>>>>>> whatever it was (wildcard) to the dl_vlan specified by the Action of >>>>>>>>> the FlowMod (22), right? >>>>>>>> >>>>>>>> Correct again. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 3) The whole FlowSpace is compared to <dpid , neoMatch> and >>>>>>>>> overlapping entries are returned. My worst problem is here: if what I >>>>>>>>> said in 2) is correct, is it correct for it to say that neoMatch(with >>>>>>>>> dl_vlan=22) and the only FlowSpace rule (with dl_vlan=1) overlap? Can >>>>>>>>> it be a Subset or a Superset if the same field has different values in >>>>>>>>> them? >>>>>>>> >>>>>>>> In this case there is no match and the whole flowmod is disallowed. >>>>>>>> Simply put, Alice does not have access to vlan 22 and there cannot >>>>>>>> emit an action which will rewrite to that vlan. >>>>>>>> >>>>>>>> Do you have a specific use case in mind? Perhaps I could help you with >>>>>>>> that. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you very very very much again! >>>>>>>>> >>>>>>>>> Victor T. >>>>>>>>> >>>>>>>>> On 11 September 2013 20:43, Ali Al-Shabibi >>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> 1) When I send a FLOW_MOD with an Action to change de DL_VLAN, we >>>>>>>>>>> talk >>>>>>>>>>> about SwitchFlowMap, which seems to come from the FlowSpaceUtil. >>>>>>>>>>> Does >>>>>>>>>>> this mean that this SwitchFlowMap and the FlowEntries it talks about >>>>>>>>>>> are from the configured FlowSpace rules? >>>>>>>>>> >>>>>>>>>> Yes those are the ones. >>>>>>>>>> >>>>>>>>>>> 2) If the above is correct, about the entity FlowEntry, what does it >>>>>>>>>>> mean by "ActionList"? I'm confused because we only provide >>>>>>>>>>> permissions >>>>>>>>>>> in the FlowSpace, not actions? Would this be a "hook" for adding a >>>>>>>>>>> future feature? >>>>>>>>>> >>>>>>>>>> The action list in FlowEntry is a little confusing sorry. That >>>>>>>>>> action list is actually used to store the persmissions a slice has >>>>>>>>>> on this flowspace entry. So for example, alice has write permissions >>>>>>>>>> and bob only has read permissions. >>>>>>>>>> >>>>>>>>>> Cheers. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks again, I think I'm really getting somewhere! =) >>>>>>>>>>> >>>>>>>>>>> Victor T. >>>>>>>>>>> >>>>>>>>>>> On 11 September 2013 00:31, Ali Al-Shabibi >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> Hi Victor, >>>>>>>>>>>> >>>>>>>>>>>> So what you are saying is correct. When a FlowMod arrives from a >>>>>>>>>>>> controller we know which slice/controller it's from. Therefore, >>>>>>>>>>>> the flowmod's match struct is matched against the flowspace of >>>>>>>>>>>> that slice. Then, for every flowspace rules matching the flowmod's >>>>>>>>>>>> match the original flowmod is expanded; ie. a new flowmod, which >>>>>>>>>>>> is the a composition of the original flowmod and the flowspace >>>>>>>>>>>> rule, is pushed to the switch. >>>>>>>>>>>> >>>>>>>>>>>> I don't if you found this page but it could help you understand >>>>>>>>>>>> how flowmods are handled -> >>>>>>>>>>>> https://github.com/OPENNETWORKINGLAB/flowvisor/wiki/FlowMod-Message >>>>>>>>>>>> >>>>>>>>>>>> Cheers. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Ali >>>>>>>>>>>> >>>>>>>>>>>> On Sep 10, 2013, at 7:46 PM, Victor Torres <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hello again Ali, >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you for all you support so far. I think theres no way for >>>>>>>>>>>>> me but >>>>>>>>>>>>> to go into FlowVisor's code. So, at first, I have a question and >>>>>>>>>>>>> appreciate any direction on how to go on with this: >>>>>>>>>>>>> >>>>>>>>>>>>> At first, I'm really interested in how FLOW_MOD messages are >>>>>>>>>>>>> handled. >>>>>>>>>>>>> According to the FV Wiki >>>>>>>>>>>>> (https://github.com/OPENNETWORKINGLAB/flowvisor/wiki/IO-Overview), >>>>>>>>>>>>> is >>>>>>>>>>>>> it correct to say that a FLOW_MOD message from a controller/slice >>>>>>>>>>>>> will >>>>>>>>>>>>> pass through a SLICER that will match it against the flowspace, >>>>>>>>>>>>> rewrite it and push it to the switch? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks again, >>>>>>>>>>>>> >>>>>>>>>>>>> Victor T. >>>>>>>>>>>>> >>>>>>>>>>>>> On 3 September 2013 13:45, Ali Al-Shabibi >>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>> 1) So FV does update its FlowTable Cache from OF Messages going >>>>>>>>>>>>>>> Switch <-> Controller. But when you say "at most every 30s, >>>>>>>>>>>>>>> means that if it doesn't get any update it asks the switch for >>>>>>>>>>>>>>> its FlowTable? The FlowMod thing means that the FlowVisor asks >>>>>>>>>>>>>>> periodically for the switch for modified flows? >>>>>>>>>>>>>> >>>>>>>>>>>>>> So if no controller or user requests flowtable stats, FV does >>>>>>>>>>>>>> not store anything in its cache nor does it make any periodic >>>>>>>>>>>>>> requests. But if your controller asks for the flowtable then if >>>>>>>>>>>>>> it does not have a copy of the flowtable or if the cache is old, >>>>>>>>>>>>>> it will fetch the flowtable from the switch. Otherwise it will >>>>>>>>>>>>>> return the cached values. The reasoning behind this is: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. There may be many controllers sitting on top of FV, therefore >>>>>>>>>>>>>> there may be many more flow table requests. >>>>>>>>>>>>>> 2. On some switch implementations, asking for the flowtable is >>>>>>>>>>>>>> an expensive operation (ie. forwarding may be delayed) >>>>>>>>>>>>>> >>>>>>>>>>>>>> For those two reasons, flowvisor caches the flowtable. Of >>>>>>>>>>>>>> course, you can change the refresh rate if you know your >>>>>>>>>>>>>> switches do not suffer from those issues. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2) If a slice controller wants to install a flow that changes >>>>>>>>>>>>>>> the VLAN tag from A to B for a given flow, FV only approves it >>>>>>>>>>>>>>> if the slice has Read/Write permissions on flowspace with >>>>>>>>>>>>>>> dl_vlan=A and dl_vlan=B? >>>>>>>>>>>>>> >>>>>>>>>>>>>> That's is correct. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> If dl_vlan is wildcarded then everything is allowed, right? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yup that's right as well. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Finally, if its set to NONE it cannot install or mod flows that >>>>>>>>>>>>>>> have (to have) actions that change Vlan Tags? >>>>>>>>>>>>>> >>>>>>>>>>>>>> And correct again ;) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sorry for asking so much but since these particular questions >>>>>>>>>>>>>>> are very important for our research I would lilke to understand >>>>>>>>>>>>>>> it as accurately as possible. >>>>>>>>>>>>>> >>>>>>>>>>>>>> No worries, ask as many question as you can. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you very much! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Victor T. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3 September 2013 13:04, Ali Al-Shabibi >>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>> Hi Victor, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1) Does FlowVisor updates its FlowDB as OF Messages pass >>>>>>>>>>>>>>>> through it? Or does it asks directly the switches for their >>>>>>>>>>>>>>>> Flow Tables? Reading the source code I'm inclined to think of >>>>>>>>>>>>>>>> the first option. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You are mostly right. Flowvisor stores a cache of the flowtable >>>>>>>>>>>>>>> which it refreshes at most every 30s (this is configurable in >>>>>>>>>>>>>>> versions 1+ of FV). One important note is that flowmods are not >>>>>>>>>>>>>>> stored when they are pushed down by a controller, but rather >>>>>>>>>>>>>>> they are periodically read from the datapath. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2) I would like to be able to keep a certain controller from >>>>>>>>>>>>>>>> installing or modding Flows that change the VLAN Tag of a >>>>>>>>>>>>>>>> packet, for instance. Can you point out a direction to do >>>>>>>>>>>>>>>> this? I was investigating the source code, but I'm not sure >>>>>>>>>>>>>>>> if I should try to implement a new Callback type or something >>>>>>>>>>>>>>>> like that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> FV will disallow a controller from pushing or modding a vlan >>>>>>>>>>>>>>> tag if either that vlan tag is not in the flowspace associated >>>>>>>>>>>>>>> to that controller or if dl_vlan is set to none. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If I get to any results I would gladly pull it in the future. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That would be fantastic. Let me know if you need more help. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Big thanks! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Victor T. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 30 August 2013 18:46, Ali Al-Shabibi >>>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>>> Hi Victor, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Currently, you cannot specify which openflow actions are >>>>>>>>>>>>>>>> allowed on a per flowspace basis. This is clearly a desirable >>>>>>>>>>>>>>>> feature but unfortunately we have not addressed it yet. We >>>>>>>>>>>>>>>> would welcome any pull requests/contributions in this >>>>>>>>>>>>>>>> direction. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cheers. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Ali >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Aug 30, 2013, at 11:58 AM, Victor Torres >>>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Does anybody know if it is possible to define allowed/denied >>>>>>>>>>>>>>>>> actions for slices in FlowVisor? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Victor T. >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> 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
