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
