On Thu, Aug 13, 2020 at 4:08 AM Tony Liu <tonyliu0...@hotmail.com> wrote: > > > -----Original Message----- > > From: Numan Siddique <num...@ovn.org> > > Sent: Wednesday, August 12, 2020 10:25 AM > > To: Tony Liu <tonyliu0...@hotmail.com> > > Cc: ovs-discuss@openvswitch.org > > Subject: Re: [ovs-discuss] [OVN] not-equal in ACL > > > > On Wed, Aug 12, 2020 at 10:41 PM Tony Liu <tonyliu0...@hotmail.com> > > wrote: > > > > > > > -----Original Message----- > > > > From: Numan Siddique <num...@ovn.org> > > > > Sent: Wednesday, August 12, 2020 2:17 AM > > > > To: Tony Liu <tonyliu0...@hotmail.com> > > > > Cc: ovs-discuss@openvswitch.org > > > > Subject: Re: [ovs-discuss] [OVN] not-equal in ACL > > > > > > > > On Mon, Aug 10, 2020 at 11:11 PM Tony Liu <tonyliu0...@hotmail.com> > > > > wrote: > > > > > > > > > > Hi Numan, > > > > > > > > > > Create a new thread here to follow up ACL questions. > > > > > > > > > > > > > I think this is a big problem here. We should not use "!=" > > > > > > > > in logical flows, although OVN allows. > > > > > > > > > > > > > > Is this a generic recommendation or for certain cases? > > > > > > > Is it OK to add an ACL with "!=", like below? > > > > > > > > > > > > > > ovn-nbctl acl-add 12b1681c-b3e7-4ec9-b324-e780d9dfdc0d > > > > > > > from-lport > > > > 1005 > > > > > > > 'ip4.dst == 192.168.0.0/16 && inport != > > > > > > > "d93619c3-dab9-4f6d-8261-4211f6937fd1"' drop > > > > > > > > > > > > > > > > > > This is a generic recommendation. The above ACL would also > > > > > > result in many OF flows. > > > > > > > > > > > > To handle cases like above, you can add a couple of ACLs like > > > > > > below > > > > with > > > > > > high priority flow to allow the desired inport and low priority > > > > > > ACL > > > > to > > > > > > drop all the traffic. > > > > > > > > > > > > ovn-nbctl acl-add 12b1681c-b3e7-4ec9-b324-e780d9dfdc0d > > > > > > from-lport > > > > > > 1006 'ip4.dst == 192.168.0.0/16 && inport == > > > > > > "d93619c3-dab9-4f6d- > > > > 8261- > > > > > > 4211f6937fd1"' allow ovn-nbctl acl-add 12b1681c-b3e7-4ec9-b324- > > > > > > e780d9dfdc0d from-lport > > > > > > 1005 'ip4.dst == 192.168.0.0/16"' drop > > > > > > > > > > In my case, two LS connect to one LR who has external access. > > > > > There are 3 ports on each LS. > > > > > * vm_port > > > > > * gw_port (connect to LR) > > > > > * svc_port (localport for DHCP and metadata) > > > > > > > > > > What I want is to disable the connection between two LS while > > > > > allow external access for them. > > > > > > > > > > Option #1, create one ACL for each VM on each LS. > > > > > ======== > > > > > acl-add $ls from-lport 1005 'ip4.dst == 192.168.0.0/16 && inport > > > > > == > > > > "$vm_port"' drop > > > > > ======== > > > > > This works fine for me, but the ACL has to be per VM. > > > > > > > > > > Option #2, create one ACL to exclude gw_port and svc_port. > > > > > ======== > > > > > acl-add $ls from-lport 1005 'ip4.dst == 192.168.0.0/16 && inport > > > > > != > > > > "$gw_port" && inport != "svc_port"' drop > > > > > ======== > > > > > As you mentioned, this is not recommended, cause it will result > > > > > many OF flows. I actually tried, but I don't see any OF flows > > > > > created for that ACL. Is there any policy in ovn-controller to not > > > > > translate such policy to OF flow? > > > > > > > > > > Option #3, as you suggested, I tried 2 ACLs. > > > > > ======== > > > > > acl-add $ls from-lport 1006 'ip4.dst == 192.168.0.0/16 && (inport > > > > > == > > > > "$gw_port" || inport == "svc_port")' allow > > > > > acl-add $ls from-lport 1005 'ip4.dst == 192.168.0.0/16' drop > > > > > ======== On compute node, I see the "drop" OF flow only, not the > > > > > "allow" flow. > > > > > Am I missing anything here? > > > > > > > > > > > > > If there is a logical flow like - "inport == port1 && .....", > > > > ovnm-controller which binds this logical port converts like logical > > > > flow to OF rule. > > > > Other ovn-controller ignore this logical flow. I think that's what > > > > happening in your case. > > > > > > I don't quite get it. Are you saying, ovn-controller on compute node > > > ignores the rule because those ports are not all bound on that > > > chassis? The gw_port and svc_port are not bound to any chassis by any > > > ovn-controller. > > > > > > I don't know what you mean by "its not bound to any chassis". Are these > > lports part of the logical switch ? or logical router ? > > In NB, they are LS ports in logical_switch_port table. > GW port is "router" port to connect to LR. > SVC port is "localport" port to provide DHCP and metadata service. > > In SB, GW port is "patch" port and SVC port is "localport" port. > Those two ports are not bound to any specific chassis. > "chassis" column in port_binding table is empty. > They exist on all chassis who has VM launched on that LS. > VM port is bound to specific chassis where the VM is launched. > > I didn't quite get your comments. My guess is that, ovn-controller > on a chassis ignores the rule with GW port and SVC port, because > they are not bound to that chassis. Is that true? > > If that is true, I'd say it's a bug. Because once a LS bound to > a chassis (VM on LS is launched on that chassis.), those ports > ports should not be ignored by ovn-controller.
I should have been more clear. The logical ports of type "" (normal lports) are ignored by other ovn-controllers if inport has a match for them. Also ACLs are applied to normal VIF logical ports. Thanks Numan > > > I don't think there is any bug. > > > > > If that's true, I'd say it's a bug. gw_port and svc_port exist on all > > > chassis who has VM launched on that logical switch. > > > ovn-controller on those chassis should not ignore the ACL. > > > Otherwise, those ports can't be used in ACL at all. > > > > > > > I think there are many ways to solve your case. > > > > > > > > 1. Have separate logical router for each logical switch and connect > > > > these logical routers to your provider network logical switch. > > > > > > I thought about that. If I have 5K such networks, I will need 5K > > > logical routers, also 5K routes on underlay physical router pointing > > > to those logical routers. Without enabling BGP (I haven't tried > > > Neutron BGP agent), it's going to be 5K static routes on underlay > > > router. That's why I make a choice in the middle between one router > > > for all networks and one router for each network. > > > > > > > 2. Add ACLs on the egress pipeline. I'd suggest this rather than on > > > > the ingress pipeline. > > > > > > I'd like to drop the packet as early as possible to get better > > > performance. How much difference between dropping packet on ingress > > > pipeline vs. egress pipeline? If not much, I am fine to add ACL on > > > egress pipeline. > > > > You could also add an in-gress pipeline. In that case you can match on > > "ip4.dst == the other switch cidr && inport == pg1".. > > If the port is ignored by ovn-controller, isn't the PG going to be > ignore as well? Or they are handled differently? > > > Thanks! > > Tony > > > > Thanks > > Numan > > > > > > > > > If your first LS1 cidr is 192.168.0.0/24 and the 2nd LS2 cidr is > > > > 172.168.0.0/24 then on add the below ACL on LS1 > > > > > > > > ovn-nbctl pg-add pg1 <LS1 lpor> > > > > ovn-nbctl acl-add pg1 to-lport 1002 "ip4.src == 172.168.0.0/24 && > > > > outport == @pg1" drop ovn-nbctl acl-add pg1 to-lport 1001 "ip && > > > > outport == @pg1" allow > > > > > > > > ovn-nbctl pg-add pg2 <LS2 lports> > > > > ovn-nbctl acl-add pg2 to-lport 1002 "ip4.src == 192.168.0.0/24 && > > > > outport == @pg2" drop ovn-nbctl acl-add pg2 to-lport 1001 "ip && > > > > outport == @pg2" allow > > > > > > Will give it a try. > > > > > > Thanks! > > > Tony > > > > Please note that I haven't tested these ACLs. > > > > > > > > Thanks > > > > Numan > > > > > > > > > > > > > > Thanks! > > > > > > > > > > Tony > > > > > > > > > > _______________________________________________ > > > > > discuss mailing list > > > > > disc...@openvswitch.org > > > > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > > > > > > > _______________________________________________ > > > discuss mailing list > > > disc...@openvswitch.org > > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > > > _______________________________________________ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
