Bug 1421022 - Neutron-linuxbridge-agent startup bridge configuration
Summary: Neutron-linuxbridge-agent startup bridge configuration
Alias: None
Product: RDO
Classification: Community
Component: openstack-neutron
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
: trunk
Assignee: Assaf Muller
QA Contact: Ofer Blaut
Depends On:
TreeView+ depends on / blocked
Reported: 2017-02-10 06:49 UTC by kalle.happonen
Modified: 2021-01-13 07:13 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-01-13 07:13:18 UTC

Attachments (Terms of Use)

Description kalle.happonen 2017-02-10 06:49:48 UTC
Description of problem:
In a recent update (Liberty), the systemd unitfile for neutron-linuxbridge-agent was updated in the openstack-neutron-linuxbridge rpm.


This line was added to the file.

This is great for compute nodes. However, if you are running a linuxbridge only setup (no OVS), the neutron-linuxbridge-agent also runs on the network nodes (in a standard l3 agent setup). 

The network nodes have nothing from OpenStack's side controlling the iptables rules for the bridge interfaces. The change in packaging explicitly turns on firewalling for the bridge interfaces.

In our case a package update, and a restart of the service, killed all customer network traffic, and we no idea why. Luckily we did this only on one network node, so we could migrate the routers away, and cause only a moderate customer impact.

Forcing iptables on the bridges should probably not be done on the network nodes, since there are no standards about handling the bridge traffic filtering on them, and in the default scenario of no firewall control for the, it blocks all traffic.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Set up a linuxbridge-only network node with standard iptable rules
2. Start neutron-linuxbridge-agent
3. Witness the lack of customer network traffic

Actual results:
Customer traffic going through the network node stops.

Expected results:
No impact on customer traffic.

Additional info:

Comment 2 Ihar Hrachyshka 2017-05-24 21:53:14 UTC
Whatever your networking configuration is, I don't see a reason why it should depend on kernel modules loaded. You may need to define additional iptables rules that would allow traffic you need on bridges you expose to customer traffic. What we do in the new service file is we enable ability to define such rules. It's up to consumers of the tables (l2 agent, or your host networking configuration) to set actual rules everything up.

Unless I completely misunderstood your problem, it seems to me it's a lack of iptables configuration that is a problem here, not the change in the service unit file. If you believe otherwise, (meaning, you can't solve it with explicit iptables rules), then please reopen the bug.

Comment 3 kalle.happonen 2017-05-29 05:04:39 UTC
The module loading itself is not a big issue. This part of the script is.

for proto in arp ip ip6; do
    /usr/sbin/sysctl -w net.bridge.bridge-nf-call-${proto}tables=1

It explicitly sets calling of iptables on bridge devices. This is a change from the previous packaging, and this is very hard to override in a nice way. I had to prevent this from running on the network nodes by overriding the calling of the script.


The problem is that on compute nodes, the iptables rules are managed automatically for dynamically created devices. On the network node you have nothing managing the rules, you have to specify them by hand.

So the end result is that you would have to somehow come up with firewall rules that would work on dynamically created and removed bridge devices with arbitrary IP ranges. This is very hard to do, especially without interfering with your other traffic at the same time. And the rules you should try to create is "allow all traffic on the bridge interfaces, since it's filtered elsewhere".

The net.bridge.bridge-nf-call-${proto}tables=0 accomplishes the same thing without the associated problems. It can't of course be set to the default either, since it would break compute node security groups.

The end result is that I think this should be admin-definable depending on the node types.

I did reopen this bug now. If you do not consider this a bug for a pure linuxbridge installation after this explanation either, feel free to close this again.

Comment 4 Yatin Karel 2021-01-13 07:13:18 UTC
Liberty is EOL long ago, closing the bug as EOL, if you feel it's still applicable for supported release please re open for that release so it can be fixed.

Note You need to log in before you can comment on or make changes to this bug.