On Sat, Jul 30, 2016 at 4:19 PM, Mickey Spiegel <mickeys....@gmail.com> wrote:
> On Fri, Jul 29, 2016 at 10:28 AM, Mickey Spiegel <emspi...@us.ibm.com> > wrote: > > > > -----"dev" <dev-boun...@openvswitch.org> wrote: ----- > >> To: Mickey Spiegel <mickeys....@gmail.com> > >> From: Russell Bryant > >> Sent by: "dev" > >> Date: 07/29/2016 10:02AM > >> Cc: ovs dev <dev@openvswitch.org> > >> Subject: Re: [ovs-dev] [PATCH] ovn: Add second ACL stage > >> > >> On Fri, Jul 29, 2016 at 12:47 AM, Mickey Spiegel <mickeys....@gmail.com > > > >> wrote: > >> > >>> > >>> This patch adds a second logical switch ingress ACL stage, and > >>> correspondingly a second logical switch egress ACL stage. This > >>> allows for more than one ACL-based feature to be applied in the > >>> ingress and egress logical switch pipelines. The features > >>> driving the different ACL stages may be configured by different > >>> users, for example an application deployer managing security > >>> groups and a network or security admin configuring network ACLs > >>> or firewall rules. > >>> > >>> Each ACL stage is self contained. The "action" for the > >>> highest-"priority" matching row in an ACL stage determines a > >>> packet's treatment. A separate "action" will be determined in > >>> each ACL stage, according to the ACL rules configured for that > >>> ACL stage. The "priority" values are only relevant within the > >>> context of an ACL stage. > >>> > >>> ACL rules that do not specify an ACL stage are applied to the > >>> default "acl" stage. > >>> > >>> Signed-off-by: Mickey Spiegel <mickeys....@gmail.com> > >> > >> > >> Could you expand on why priorities in a single stage aren't enough to > >> satisfy the use case? > > > > If two features are configured independently with a mix of > > prioritized allow and drop rules, then with a single stage, a > > new set of ACL rules must be produced that achieves the same > > behavior. This is sometimes referred to as an "ACL merge" > > algorithm, for example: > > > http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp39514 > > > > In the worst case, for example when the features act on different > > packet fields (e.g. one on IP address and another on L4 port), > > the number of rules required can approach > > (# of ACL1 rules) * (# of ACL2 rules). > > > > While it is possible to code up such an algorithm, it adds > > significant complexity and complicates whichever layer > > implements the merge algorithm, either OVN or the CMS above. > > > > By using multiple independent pipeline stages, all of this > > software complexity is avoided, achieving the proper result > > in a simple and straightforward manner. > > > > Recent network hardware ASICs tend to have around 8 or 10 ACL > > stages, though they tend to evaluate these in parallel given > > all the emphasis on low latency these days. > > Throwing in an example to illustrate the difference between one > ACL stage and two ACL stages: > > If two separate ACL stages: > Feature 1 > acl from-lport 100 (tcp == 80) allow-related > acl from-lport 100 (tcp == 8080) allow-related > acl from-lport 100 (udp) allow-related > acl from-lport 100 (ip4.src == 10.1.1.0/24 && tcp) allow-related > > Feature 2 > acl2 from-lport 300 (ip4.dst == 172.16.10.0/24) allow-related > acl2 from-lport 300 (ip4.dst == 192.168.20.0/24) allow-related > acl2 from-lport 200 (ip4.dst == 172.16.0.0/20) drop > acl2 from-lport 200 (ip4.dst == 192.168.0.0/16) drop > acl2 from-lport 100 (ip4.dst == 172.16.0.0/16) allow-related > > Combined in one stage, to get the equivalent behavior, this would require: > from-lport 300 (ip4.dst == 172.16.10.0/24 && tcp == 80) allow-related > from-lport 300 (ip4.dst == 172.16.10.0/24 && tcp == 8080) allow-related > from-lport 300 (ip4.dst == 172.16.10.0/24 && udp) allow-related > from-lport 300 (ip4.dst == 172.16.10.0/24 && ip4.src == 10.1.1.0/24 && > tcp) allow-related > from-lport 300 (ip4.dst == 192.168.20.0/24 && tcp == 80) allow-related > from-lport 300 (ip4.dst == 192.168.20.0/24 && tcp == 8080) allow-related > from-lport 300 (ip4.dst == 192.168.20.0/24 && udp) allow-related > from-lport 300 (ip4.dst == 192.168.20.0/24 && ip4.src == 10.1.1.0/24 && > tcp) allow-related > from-lport 200 (ip4.dst == 172.16.0.0/20) drop > from-lport 200 (ip4.dst == 192.168.0.0/16) drop > from-lport 100 (ip4.dst == 172.16.0.0/16 && tcp == 80) allow-related > from-lport 100 (ip4.dst == 172.16.0.0/16 && tcp == 8080) allow-related > from-lport 100 (ip4.dst == 172.16.0.0/16 && udp) allow-related > from-lport 100 (ip4.dst == 172.16.0.0/16 && ip4.src == 10.1.1.0/24 && > tcp) allow-related > Or have an address set, "addrset1", which contains {172.16.10.0/24, 192.168.20.0/24, 172.16.0.0/20, 192.168.0.0/16, 172.16.0.0/16}. acl from-lport 100 (ip4.dst == $addrset1 && tcp && tcp.dst == {80, 8080}) allow-related acl from-lport 100 (ip4.dst == $addrset1 && udp) allow-related acl from-lport 100 (ip4.dst == $addrset1 && ip4.src == 10.1.1.0/24 && tcp) allow-related > > If there are more IP addresses in feature 2, then the number > of ACL rules will climb geometrically: > (4 feature 1 rules * # feature 2 allow-related rules + # feature 2 drop > rules) > > With 2 separate ACL stages, the rules just go straight into > the corresponding ACL table, no merge required: > (# feature 1 rules + # feature 2 rules) > Thanks for elaborating. I'm not opposed. It seems harmless if not being used. Can you update the docs to indicate the specific accepted values for "stage"? It currently sounds like you can use as many stages as you want to me. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
