On Wed, Aug 12, 2020 at 10:41 PM Tony Liu <[email protected]> wrote: > > > -----Original Message----- > > From: Numan Siddique <[email protected]> > > Sent: Wednesday, August 12, 2020 2:17 AM > > To: Tony Liu <[email protected]> > > Cc: [email protected] > > Subject: Re: [ovs-discuss] [OVN] not-equal in ACL > > > > On Mon, Aug 10, 2020 at 11:11 PM Tony Liu <[email protected]> > > 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 ? 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".. 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 > > > [email protected] > > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > > > _______________________________________________ > discuss mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
