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 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) Mickey > Mickey > >> >> -- >> Russell Bryant >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev >> _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
