Hi Victor, I believe there is a case which isn't caught by my code. If a flowmod wildcards the vlan field, the neoMatch struct will also wildcard the vlan field and there this will be ignored in the matching process and therefore result in the behaviour you see.
What you want to express is that there was no vlan tag in this packet before this flowmod. So I think what you should set is the vlan id in the match to 0xffff and unwildcard the vlan field. This should solve you problem. Having said all this, it may make sense for the action to unwildcard the field it is verifying, I need to think about that a little. Let me know if that works for you. Cheers. -- Ali On Sep 12, 2013, at 6:01 PM, Victor Torres <vit...@poli.ufrj.br> wrote: > 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
