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 <vit...@poli.ufrj.br> 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 <ali.al-shab...@stanford.edu> > 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 <ali.al-shab...@stanford.edu> >>> 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 <ali.al-shab...@stanford.edu> >>>>> 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 <vit...@poli.ufrj.br> 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 <ali.al-shab...@stanford.edu> >>>>>>> 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 >>>>>>>>> <ali.al-shab...@stanford.edu> 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 >>>>>>>>>> <ali.al-shab...@stanford.edu> 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 <vit...@poli.ufrj.br> >>>>>>>>>> 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 >>>>>>>>>>> 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
