[ovs-discuss] [OVN] not-equal in ACL

Numan Siddique numans at ovn.org
Wed Aug 12 17:25:24 UTC 2020


On Wed, Aug 12, 2020 at 10:41 PM Tony Liu <tonyliu0592 at hotmail.com> wrote:
>
> > -----Original Message-----
> > From: Numan Siddique <numans at ovn.org>
> > Sent: Wednesday, August 12, 2020 2:17 AM
> > To: Tony Liu <tonyliu0592 at hotmail.com>
> > Cc: ovs-discuss at openvswitch.org
> > Subject: Re: [ovs-discuss] [OVN] not-equal in ACL
> >
> > On Mon, Aug 10, 2020 at 11:11 PM Tony Liu <tonyliu0592 at 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 ?

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
> > > discuss at openvswitch.org
> > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> > >
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>


More information about the discuss mailing list