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
