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 <ali.al-shab...@stanford.edu> 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 <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
