[rfe] openvswitch based firewall driver

This is describing the "how" and not the "what". The what, if I read between the lines, is that you'd like to be able to use security groups on OVS without the need for a Linuxbridge. The reasons for this include performance and easier debugging.

Regardless, this is a good thing, and I believe we should move forward with this. I expect once we get to the Neutron patches and devref we'll hit the "connection tracking support isn't in a release OVS verison yet" issue, but lets deal with it there.

BTW: Who should this be assigned to? Kuba?

> This is describing the "how" and not the "what". The what, if I read between the lines, is that you'd like to be able to use security groups on OVS without the need for a Linuxbridge. The reasons for this include performance and easier debugging.

Yes

> BTW: Who should this be assigned to? Kuba?

And yes :) I forgot to assign, sorry.

I will update the description, so the "what" is available for newcomers to this rfe. Thanks Kyle for defining the "what".

Discussed at the neutron-drivers meeting, moved to triaged, work can now proceed with this RFE. Thanks for the response Jakub!

next step is to report a BP and write spec in nova-spec?

This RFE might not get into Liberty because of conntrack support was not released with OVS 2.4 [1] We can prepare a driver though, that can be tested with experimental OVS [2] and eventually merge it after OVS 2.5 is released. But I'm not sure when is this gonna happen.

[1] http://openvswitch.org/pipermail/announce/2015-June/000074.html
[2] https://github.com/justinpettit/ovs/tree/conntrack

Guys,

Why not use NFTables, instead of OpenFlow Rules?

From what I'm seeing, a much better approach for managing Security Groups on OpenStack, will be to get rid of: "iptables", "ip6tables", "arptables", "ebtables", "ipset"... In favor of "nft".

It will work with OpenvSwitch too!

This way, a single framework, lets call it "nftables-firewall-driver" (instead of "ovs-firewall-driver"), might work for both OpenvSwitch and pure Linux Bridge deployments...

NFTables can also, bring native (NAT66) for a NAT-based IPv6 Floating IP (which I dislike very much but, it is there)...

What do you guys think?

http://people.netfilter.org/2014/wiki/index.php/List_of_presentations

http://people.netfilter.org/2014/wiki/images/0/04/NFWS2014-OVS%2Bconntrack.pdf

Cheers!
Thiago

Hi Thiago,

   After some thought I don't think we should push back on implementing an nftables-firewall-driver, or ovs/ct driver.

   why not having both and checking what works best? I cannot help too much on nft, since I don't have expertise on it (yet), but I would be glad to review any related patches, and learn on the way if you're willing to push that work.

the OVS/CT solution would eliminate absolutely everything except ovs/openflow.

OVS + NFT still means mixing two technologies. LB + NFT probably would see a lot of benefits.

Thiago, can you post a link here to your NFT proposal for cross reference?

Btw Thiago, I think you wanted to reference this one: http://people.netfilter.org/2014/wiki/images/9/9f/NFWS_-_OVS_NAT.pdf

Hi Thiago,

thanks for alternative proposal.

Can you please elaborate more how nft would work in case we don't use hybrid plugging (i.e. ovs-interface->veth->linuxbridge->tap) but plug tap directly as ovs interface? As per our ovs experts, this can't work. The aim of this rfe is to get rid of hybrid plug.

Also we should consider solutions performance wise. Having one driver is good for developers as it's easier to maintain but for the end-user this is transparent and in my opinion we should be focused on what is best for users. Do you have any performance benchmarks comparing those two approaches (ovs+conntrack vs nft)?

Thank you!

Jakub, is there any up to date code that we can look at to stuck our teeth into ovs firewall? This is starving, and it's about time we deliver on the promise of OVS-based firewalling. Although ovs support is not quite there yet, we can still allow people to experiment with it the same way the OVN folks do.

Hi Armando,
I'm working on it, I'll send first still WIP patch tomorrow. I'm not available 25th-29th Nov thus I'm not very optimistic it will get a good shape before m1. m2 milestone sounds more realistic.

Related fix proposed to branch: master
Review: https://review.openstack.org/249337

Ok, as per drivers meeting let's keep the work rolling, and get this RFE updated to cover the latest QoS meeting details (no modification to the API), that was @armax concern on comment #8.

Also, we need to file a high level spec, or a devref explaining the high level of the thing, to gain user visibility on the proposed user workflow.

Reviewed: https://review.openstack.org/191148
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=a94777a005f5619e70dab609211b8550cb75981d
Submitter: Jenkins
Branch: master

commit a94777a005f5619e70dab609211b8550cb75981d
Author: Jakub Libosvar <email address hidden>
Date: Fri Jun 12 15:40:21 2015 +0000

    Add test cases to testing firewall drivers

    Part of this patch is also preparation for having common test plan for
    firewall driver testing.

    Following test cases were implemented:
     - dhcp works by default
     - dhcp server is prevented on vm by default
     - ip spoofing from vm
     - allowed address pairs allows traffic to given ip
     - arp can go through
     - ingress/egress traffic with src/dest port ranges

    Related-bug: #1461000
    Change-Id: Ib00c99f236855e6556f43f4ffc55014c73b077bb

Reviewed: https://review.openstack.org/197468
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=a459950da3900ad09475975f69570bfac7714ca3
Submitter: Jenkins
Branch: master

commit a459950da3900ad09475975f69570bfac7714ca3
Author: Jakub Libosvar <email address hidden>
Date: Tue Jun 30 12:46:30 2015 +0000

    Add firewall blink + remote SG functional tests

    This tests that firewall still does its purpose even when rules are
    being updated. That means there is no short period of time where
    security groups are inactive during update.

    Part of this patch introduces Pinger class. This object provides
    capability of sending ICMP packets asynchronously and after
    it's stopped it provides statistics like how many packets were
    sent and how many were received. Note the difference between
    assert_ping() functions, which are synchronous.

    Another testing of remote security groups is also added.

    Related-bug: #1461000
    Change-Id: I6251ee264396f8dbc9b284758b96e5cdc6ac500b

status update: http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-01-28-22.20.log.txt

Reviewed: https://review.openstack.org/249337
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=ef29f7eb9a2a37133eacdb7f019b48ec3f9a42c3
Submitter: Jenkins
Branch: master

commit ef29f7eb9a2a37133eacdb7f019b48ec3f9a42c3
Author: Jakub Libosvar <email address hidden>
Date: Tue Sep 1 15:50:48 2015 +0000

    Open vSwitch conntrack based firewall driver

    This firewall requires OVS 2.5+ version supporting conntrack and kernel
    conntrack datapath support (kernel>=4.3). For more information, see
    https://github.com/openvswitch/ovs/blob/master/FAQ.md

    As part of this new entry points for current reference firewalls were
    added.

    Configuration:
    in openvswitch_agent.ini:
        - in securitygroup section set firewall_driver to openvswitch

    DocImpact
    Closes-bug: #1461000

    Co-Authored-By: Miguel Angel Ajo Pelayo <email address hidden>
    Co-Authored-By: Amir Sadoughi <email address hidden>

    Change-Id: I13e5cda8b5f3a13a60b14d80e54f198f32d7a529

Is this fix available for Kilo release also?

@Balaji: This is a new feature that will come out with Mitaka release. It won't be backported to Liberty, neither Kilo.

This is IMPRESSIVE!! Thanks guys!

Whew can I test it?

I have Neutron 8.0.0 b2 running on Xenial, is it available on b2 now?

On 17 February 2016 at 20:15, OpenStack Infra <email address hidden>
wrote:

> Reviewed: https://review.openstack.org/249337
> Committed:
> https://git.openstack.org/cgit/openstack/neutron/commit/?id=ef29f7eb9a2a37133eacdb7f019b48ec3f9a42c3
> Submitter: Jenkins
> Branch: master
>
> commit ef29f7eb9a2a37133eacdb7f019b48ec3f9a42c3
> Author: Jakub Libosvar <email address hidden>
> Date: Tue Sep 1 15:50:48 2015 +0000
>
> Open vSwitch conntrack based firewall driver
>
> This firewall requires OVS 2.5+ version supporting conntrack and kernel
> conntrack datapath support (kernel>=4.3). For more information, see
> https://github.com/openvswitch/ovs/blob/master/FAQ.md
>
> As part of this new entry points for current reference firewalls were
> added.
>
> Configuration:
> in openvswitch_agent.ini:
> - in securitygroup section set firewall_driver to openvswitch
>
> DocImpact
> Closes-bug: #1461000
>
> Co-Authored-By: Miguel Angel Ajo Pelayo <email address hidden>
> Co-Authored-By: Amir Sadoughi <email address hidden>
>
> Change-Id: I13e5cda8b5f3a13a60b14d80e54f198f32d7a529
>
>
> ** Changed in: neutron
> Status: In Progress => Fix Released
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1461000
>
> Title:
> [rfe] openvswitch based firewall driver
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/neutron/+bug/1461000/+subscriptions
>

Hi Thiago,

I'm happy you want to try it out. :)

Unfortunately the driver was merged recently to master and AFAIK is not available in b2. If you want to try it, you must install Neutron from source.

Oh, that's okay! I'll wait for new package on Ubuntu...

So, no more hybrid bridges when with OpenvSwitch? :-D

I also can't wait to try it with OVS+DPDK... Do you know if
ovs-firewall-driver will works with OVS-2.5 when with DPDK too?

Thanks!

On 23 February 2016 at 13:17, Jakub Libosvar <email address hidden> wrote:

> Hi Thiago,
>
> I'm happy you want to try it out. :)
>
> Unfortunately the driver was merged recently to master and AFAIK is not
> available in b2. If you want to try it, you must install Neutron from
> source.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1461000
>
> Title:
> [rfe] openvswitch based firewall driver
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/neutron/+bug/1461000/+subscriptions
>

I am afraid this won't work with OVS+DPDK. See bug 1531205 for more details.

Hey Armando,

Thank you for the heads up!

Let me ask you guys something, and BTW, forgive to ask this here, on a bug
report, but I think it is related...

Right now, if I run:

sudo apt install neutron-openvswitch-agent

On Ubuntu Xenial (proposed enabled), I'm seeing this:

---
root@mitaka-1:~# apt install neutron-openvswitch-agent
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  dpdk libdpdk0 openvswitch-common openvswitch-switch
---

And this is IMPRESSIVE!

However, let me ask this:

Will be possible to use, at the same time (same Network and Compute nodes /
Host Agregate):

1- Regular OVS bridges without DPDK for VXLAN Networks, with OVS-Firewall
and;

2- OVS powered by DPDK for Provider Networks (without any firewall, current
case).

?

I have NFV Instances that are also, DPDK L2 Bridges running on KVM, that
are physically wired using Provider Networks (flat and vlans).

So, for the Instance vNICs (eth1 and eth2) that are used as a bridge, I
don't want any kind of firewall and I want OVS+DPDK under it but, for SSH
into the Instance (via its eth0), it is still regular VXLAN with Security
Groups - OVS-Firewall now (no need for DPDK under eth0 / VXLAN)...

I'm curious about this specially because the OVS Ubuntu package, makes use
of Debian's Alternatives subsystem, and we need to choose one OVS
(default), or another (with DPDK), via "update-alternatives", so, will be
possible to select OVS with DPDK but, use regular bridges as well?

Thanks in advance!

Best,
Thiago

On 24 February 2016 at 01:03, Armando Migliaccio <<email address hidden>
> wrote:

> I am afraid this won't work with OVS+DPDK. See bug 1531205 for more
> details.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1461000
>
> Title:
> [rfe] openvswitch based firewall driver
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/neutron/+bug/1461000/+subscriptions
>

Hi Thiago,

it will be better to raise these questions at https://ask.openstack.org/ - conversation may get bigger and this is an rfe bug after all.