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