Daya/Som, We can think of deterministic implementation as well since it will solve problem we are facing now. As mentioned in one of the solution of changing the priority based on SG can make it more deterministic. But we need to have priority associated with the SG itself as otherwise it will be challenging to identify first and last SG as we can add and remove them randomly. Since openstack does not provide any sequencing , we require a logic which can associate the priority to the SG in netvirt.
This will not solve the issue Vishal mentioned where two SR( security rule )in a SG with one rule being the subset of other, we will not able to predict which will be hit first as all SR in a SG still have same priority. Thanks Aswin On Thu, Oct 13, 2016 at 6:00 PM, Dayavanti Gopal Kamath < dayavanti.gopal.kam...@ericsson.com> wrote: > Hi som, > > while SG may work this way, and ordering might not matter, as a service > ACL should definitely implement it as an ordered list, to be more generic, > and be able to support other classifier based features with minimal > changes. There was goal for SGs at some point (long back, I think during G > or H ), to add deny acl’s, but I don’t know the latest status. > > > > Question for all, how does the netvirt community feel about changing SG > impl to be an ordered list for Carbon. > > > > Prio-wise, we do get some uncertainty between different SGs applied on a > port, since Openstack does not provide any sequencing between SGs but > that’s a problem for the operator to solve I think,the code should only > ensure default SG has the lowest priority, and we could apply SGs in > reduced priority order as and when they are applied, ie first group gets > highest prio, and last group gets lowest prio. > > > > Thanks, > > daya > > > > > > > > *From:* Somashekar B [mailto:somasheka...@altencalsoftlabs.com] > *Sent:* Thursday, October 13, 2016 4:53 PM > *To:* Dayavanti Gopal Kamath <dayavanti.gopal.kam...@ericsson.com>; > jozef.baci...@pantheon.tech; netvirt-...@lists.opendaylight.org; > openflowplugin-dev@lists.opendaylight.org > > *Subject:* RE: [netvirt-dev] [openflowplugin-dev] Need inputs on handling > deletion of flows which have common attributes > > > > Hi Daya, > > > > Currently, all the flows corresponding to SG rules (irrespective of SG) > have same priority. > > One basic question here, does ordering at a SG level or SG rules level > really matter? Becoz whatever we specify in SG rules are for allow traffic > only. There are no deny rules. So I believe sequencing shouldn't matter > unless if we are specifically looking for flow statistics. Also there are > no attributes in openstack which specifically mention about the sequence > numbers. SG and rules are just passed as an array to ODL. So in case if we > have to maintain sequencing, we will be following the array indexing. > > > > With your inputs on making use of priority, I think we can have different > priorities based on port + SG. This would create multiple flows on switch. > So the issue doesn’t arise. > > Hope SG priorities doesn’t matter. > > > > Please share your thoughts. > > > > Thanks, > > Somashekar > > > > > > *From:* Dayavanti Gopal Kamath [mailto:dayavanti.gopal.kam...@ericsson.com > <dayavanti.gopal.kam...@ericsson.com>] > *Sent:* Thursday, October 13, 2016 2:18 PM > *To:* Somashekar Byrappa <somasheka...@altencalsoftlabs.com>; > jozef.baci...@pantheon.tech; netvirt-...@lists.opendaylight.org; > openflowplugin-dev@lists.opendaylight.org > *Subject:* RE: [netvirt-dev] [openflowplugin-dev] Need inputs on handling > deletion of flows which have common attributes > > > > Hi som, > > I would question the need for this usecase itself. > > > > sg rules would be an ordered list, which need to be applied in sequence, > so when these rules are programmed in the tables, we cannot have any > interleaving between rules from different SGs. I think this is a contract > that cannot be violated. For e.g > > if SG1 has rule1, rule2, rule3 and SG2 has rule4,rule2, rule5. We need to > make sure the tables contain 2 instances of rule 2, in both these ordered > lists. The relative priority between all rules of SG1 and all rules of SG2 > is a separate issue of course, and a separate discussion on whether these > prios are deterministic. > > Basic point is, we need to ensure the sequencing is intact within a group, > either by adjusting the priorities or adding more specific match criteria, > for different SGs. > > > > 2ndly, and more broadly, this does not sound typical to apply multiple SGs > to the same VM, and additionally have the same rule in each such SG. This > would call for some re-organization of the SG rules themselves, so from my > perspective, we need not have huge design changes in the code to support > such a use case. > > > > Thanks, > > daya > > > > *From:* netvirt-dev-boun...@lists.opendaylight.org [ > mailto:netvirt-dev-boun...@lists.opendaylight.org > <netvirt-dev-boun...@lists.opendaylight.org>] *On Behalf Of *Somashekar B > *Sent:* Thursday, October 13, 2016 12:49 PM > *To:* jozef.baci...@pantheon.tech; netvirt-...@lists.opendaylight.org; > openflowplugin-dev@lists.opendaylight.org > *Subject:* Re: [netvirt-dev] [openflowplugin-dev] Need inputs on handling > deletion of flows which have common attributes > > > > Thanks Jozef for your inputs. > > Maybe a common module needs to be written which can handle this scenario > instead of every application module handling on their own. > > > > Anymore inputs from others? Or else for time being, I will handle this in > security groups module itself. > > > > Thanks, > > Somashekar > > > > *From:* Jozef Bacigál [mailto:jozef.baci...@pantheon.tech > <jozef.baci...@pantheon.tech>] > *Sent:* Friday, October 7, 2016 3:58 PM > *To:* Somashekar B <somasheka...@altencalsoftlabs.com>; netvirt-dev@lists. > opendaylight.org; openflowplugin-dev@lists.opendaylight.org > *Subject:* RE: [openflowplugin-dev] Need inputs on handling deletion of > flows which have common attributes > > > > Hi Somashekar, > > > > from Plugin POV it is quite impossible to handle this use case without a > performance impact. On the device you can’t store two identical flows and > you can’t store flow id as you mentioned below. But the plugins > reconciliation working on change event so if you delete one flow on > configuration it will be deleted on switch and reconciliation won’t start > check all configuration unless you disconnect device. So yes, it would be > better approach to handle this use case from the application side instead > to let the plugin always check everything on each event. > > > > Jozef > > > > *From:* Somashekar B [mailto:somasheka...@altencalsoftlabs.com > <somasheka...@altencalsoftlabs.com>] > *Sent:* Thursday, October 6, 2016 1:09 PM > *To:* netvirt-...@lists.opendaylight.org; openflowplugin-dev@lists. > opendaylight.org > *Subject:* [openflowplugin-dev] Need inputs on handling deletion of flows > which have common attributes > > > > Hi All, > > > > I am looking for all your inputs for the below issue. > > > > *Issue*: Create multiple flows with different flowId, keeping rest of the > attributes same. > > In this case, there will be multiple flow entries in config DS, but a > single flow on the switch. > > When we delete one of this overlapping flow, flow gets deleted on the > switch. > > > > *Use case:* > > > > We can associate multiple security groups to a VM from Openstack. > > Each rule in the security group (SG) generally gets translated to a flow > in one of the ACL tables (41/252) based on the direction (ingress/egress). > > Let’s say we create multiple SGs having few overlapping rules (highlighted > in yellow) among each other like below: > > > > | sg1 | ingress, IPv4, 22/tcp, remote_ip_prefix: 20.20.20.0/24 > | > > | | ingress, IPv4, icmp, remote_ip_prefix: 20.20.20.0/24 > | > > | sg2 | ingress, IPv4, 22/tcp, remote_ip_prefix: 20.20.20.0/24 > | > > > > > > When we associate both SGs (sg1 and sg2) to a VM, ACL module creates three > flow entries totally in config DS. > > For the above two overlapping rules, two flow entries are created in > config DS with different flowId, rest all the other attributes remains same. > > *This would result in a single flow on the switch as flowId is not a flow > attribute on the switch.* > > > > cookie=0x6900000, duration=11.895s, table=252, n_packets=0, n_bytes=0, > priority=61010,ct_state=+new+trk,tcp,metadata=0x10000000000/ > 0x1fffff0000000000,nw_src=20.20.20.0/24,tp_dst=22 > actions=ct(commit,zone=5000),resubmit(,220) > > cookie=0x6900000, duration=75.237s, table=252, n_packets=0, n_bytes=0, > priority=61010,ct_state=+new+trk,icmp,metadata=0x10000000000/ > 0x1fffff0000000000,nw_src=20.20.20.0/24 actions=ct(commit,zone=5000), > resubmit(,220) > > > > Problem arises when we dissociate one of the SGs (let’s say, sg2) from the > VM. In this case, we delete one of the overlapping flow from config DS. > > This would result in deletion of flow from the switch. Even though there > is another flow entry (having same data with different flow ID) in the > config DS, this flow gets deleted from the switch. > > This is how we generally handle all DCN/DTCN. > > > > This is a common problem which might occur in other situations as well. > > > > Question is how to handle this kind of scenario? > > Which module should handle this? Plugin or applications? > > > > In case, if we need to handle it from the applications side, we could > think of below option: > > > > 1. When adding a flow to config DS, > > a. Construct the flow id using the match criteria which would > generate same flow ID for all the overlapping rules. So that only one flow > will be created for all overlapping rules. > > b. With the constructed flowId, query config DS to check if flow > already exists. > > i. If > no, add this flow with flow name something like: *ACL-<counter>*. Counter > would signify the number of overlapping flows configured. > > ii. If > yes, update the flow name by incrementing the counter. Eg: ACL-2 > > 2. In case of deleting flow from config DS, > > a. Construct the flow ID as mentioned in 1.a > > b. With the constructed flowId, query config DS to check if flow > already exists. > > i. If > no, ignore. > > ii. If > yes, check the counter value in the flow name (ACL-2), if its value is 1, > delete the flow else decrement the counter and update the flow in config DS. > > > > *Cons of this approach: * > > One additional read call to config DS during > addition/deletion of every flow. > > > > Please share your thoughts to handle it optimally. > > > > > > Thanks, > > Somashekar > > Jozef*Bacigál* > > Software Engineer > > > Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia > R&D centrum / Janka Kráľa 9 / 974 01 Banská Bystrica / Slovakia > +421 908 766 972 / jozef.baci...@pantheon.tech > reception: +421 2 206 65 114 / www.pantheon.sk > > [image: Image removed by sender. logo] > > > > _______________________________________________ > netvirt-dev mailing list > netvirt-...@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/netvirt-dev > >
_______________________________________________ openflowplugin-dev mailing list openflowplugin-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
