> -----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 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
