Public bug reported: Nowadays, when using openvswitch-agent with security groups we must use hybrid bridging, i.e. per instance we have both openvswitch bridge and linux bridge. The rationale behind this approach is to set filtering rules matching on given linux bridge.
The hybrid bridging looks like a workaround, it is slow, harder to debug and make things very complicated to work NFV (specially instances running L2 Bridge applications (DPDK for example)... If you do not use OpenvSwitch, and stick with Linux Bridges only, you have a much simpler setup, no hybrid bridges and easier to debug, nevertheless, you still make use of tons of solutions, like for example: * iptables; * ip6tables; * artables; * ebtables; * ipset... On the other hand, if we manage to create the nftables-firewall-driver for Neutron, we'll end up with a much consistent, simpler and faster solution for the project. Basically, we just need 1 binary: * nft. Also, NFTables might work, as-is, for both Linux Bridges and OpenvSwitch! Without involving hybrid bridging!!! One single and elegant solution, to solve all problems at once. http://people.netfilter.org/2014/wiki/index.php/List_of_presentations http://people.netfilter.org/2014/wiki/images/0/04/NFWS2014-OVS%2Bconntrack.pdf Not to mention that with NFTables. we can have native NAT66 (which I dislike very much but, it is there, because NAT is a ugly workaround to deal with IPv4 exhaustion, it have nothing to do with IPv6), that might help us to create Floating IPv6 using the very same approach for Floating IPv4. Please, keep in mind that a Floating IPv6 using NAT66 is very, very bad, and it should be disabled by default. A better Floating IPv6 can be designed without any kind of NAT. Plus, with NFTables, we might create something like Suricata- as-a-service (or "IDSaaS"), because NFTables is much more powerful than iptables, that it improves IDE systems... For example: https://home.regit.org/2014/02/suricata-and-nftables/ So, a Neutron nftables-firewall-driver will deprecated everything related to old tools (listed above) and it will bring a much more consistent solution for the project. Time to move to NFTables! Cheers! Thiago ** Affects: neutron Importance: Undecided Status: New ** Tags: bridge driver firewall ids nftables -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1508155 Title: [rfe] NFTables Firewall Driver Status in neutron: New Bug description: Nowadays, when using openvswitch-agent with security groups we must use hybrid bridging, i.e. per instance we have both openvswitch bridge and linux bridge. The rationale behind this approach is to set filtering rules matching on given linux bridge. The hybrid bridging looks like a workaround, it is slow, harder to debug and make things very complicated to work NFV (specially instances running L2 Bridge applications (DPDK for example)... If you do not use OpenvSwitch, and stick with Linux Bridges only, you have a much simpler setup, no hybrid bridges and easier to debug, nevertheless, you still make use of tons of solutions, like for example: * iptables; * ip6tables; * artables; * ebtables; * ipset... On the other hand, if we manage to create the nftables-firewall-driver for Neutron, we'll end up with a much consistent, simpler and faster solution for the project. Basically, we just need 1 binary: * nft. Also, NFTables might work, as-is, for both Linux Bridges and OpenvSwitch! Without involving hybrid bridging!!! One single and elegant solution, to solve all problems at once. http://people.netfilter.org/2014/wiki/index.php/List_of_presentations http://people.netfilter.org/2014/wiki/images/0/04/NFWS2014-OVS%2Bconntrack.pdf Not to mention that with NFTables. we can have native NAT66 (which I dislike very much but, it is there, because NAT is a ugly workaround to deal with IPv4 exhaustion, it have nothing to do with IPv6), that might help us to create Floating IPv6 using the very same approach for Floating IPv4. Please, keep in mind that a Floating IPv6 using NAT66 is very, very bad, and it should be disabled by default. A better Floating IPv6 can be designed without any kind of NAT. Plus, with NFTables, we might create something like Suricata- as-a-service (or "IDSaaS"), because NFTables is much more powerful than iptables, that it improves IDE systems... For example: https://home.regit.org/2014/02/suricata-and-nftables/ So, a Neutron nftables-firewall-driver will deprecated everything related to old tools (listed above) and it will bring a much more consistent solution for the project. Time to move to NFTables! Cheers! Thiago To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1508155/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
