I am going to mark this as won't fix as the linuxbridge agent is
unmaintained and experimental on the master branch.
** Changed in: neutron
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1849463
Title:
linuxbridge packet forwarding issue with vlan backed networks
Status in neutron:
Won't Fix
Bug description:
This is related to: https://bugs.launchpad.net/os-vif/+bug/1837252
In Ubuntu 18.04 using Ubuntu Cloud Archives (UCA) and Stein os-vif
version 1.15.1 is deployed.
According to the bug #1837252/OSSA-2019-004/CVE-2019-15753 this
version is vulnerable to unicast packet broadcasting to all bridge
members resulting in traffic interception due to disabled mac-learning
(ageing set to 0). The fix is to set ageing to the default of 300.
With this vulnerable set up instances using vlan-backed networks have
working traffic flows as expected since all packets are being
distributed to all members.
The FDB entries show:
# bridge fdb | grep -e tapb2b8c5ff-8c -e brqa50c5b7b-db -e ens256.3002 | grep
-v -e ^01:00:5e -e ^33:33
00:16:3e:ba:fa:33 dev ens256.3002 vlan 1 master brqa50c5b7b-db permanent
00:16:3e:ba:fa:33 dev ens256.3002 master brqa50c5b7b-db permanent
fe:16:3e:0d:c0:42 dev tapb2b8c5ff-8c vlan 1 master brqa50c5b7b-db permanent
fe:16:3e:0d:c0:42 dev tapb2b8c5ff-8c master brqa50c5b7b-db permanent
Showmacs confirm:
# brctl showmacs brqa50c5b7b-db
port no mac addr is local? ageing timer
2 00:16:3e:ba:fa:33 yes 0.00
2 00:16:3e:ba:fa:33 yes 0.00
1 fe:16:3e:0d:c0:42 yes 0.00
1 fe:16:3e:0d:c0:42 yes 0.00
However, once ageing is enabled by either `brctl setageing
brqa50c5b7b-db 300` or upgrading to UCA/Train with os-vif 1.17.0
traffic flows directed towards tapb2b8c5ff-8c are not being forwarded.
Traffic coming from tapb2b8c5ff-8c is being forwarded correctly
through the bridge and exits ens236.3002.
Only incoming traffic destined for tapb2b8c5ff-8c' MAC is being
dropped or not forwarded.
the FDB entries show:
# bridge fdb | grep -e tapb2b8c5ff-8c -e brqa50c5b7b-db -e ens256.3002 | grep
-v -e ^01:00:5e -e ^33:33
00:50:56:89:64:e0 dev ens256.3002 master brqa50c5b7b-db
00:16:3e:ba:fa:33 dev ens256.3002 vlan 1 master brqa50c5b7b-db permanent
fa:16:3e:f8:76:cf dev ens256.3002 master brqa50c5b7b-db
00:16:35:bf:5f:e5 dev ens256.3002 master brqa50c5b7b-db
fa:16:3e:0d:c0:42 dev ens256.3002 master brqa50c5b7b-db
00:50:56:89:69:d9 dev ens256.3002 master brqa50c5b7b-db
9e:dc:1b:a2:9b:2e dev ens256.3002 master brqa50c5b7b-db
00:16:3e:ba:fa:33 dev ens256.3002 master brqa50c5b7b-db permanent
0e:c7:c3:cd:8d:fa dev ens256.3002 master brqa50c5b7b-db
fe:16:3e:0d:c0:42 dev tapb2b8c5ff-8c vlan 1 master brqa50c5b7b-db permanent
fe:16:3e:0d:c0:42 dev tapb2b8c5ff-8c master brqa50c5b7b-db permanent
Showmacs confirm:
# brctl showmacs brqa50c5b7b-db
port no mac addr is local? ageing timer
2 00:16:35:bf:5f:e5 no 0.16
2 00:16:3e:ba:fa:33 yes 0.00
2 00:16:3e:ba:fa:33 yes 0.00
2 00:50:56:89:64:e0 no 0.10
2 00:50:56:89:69:d9 no 0.20
2 0e:c7:c3:cd:8d:fa no 0.10
2 9e:dc:1b:a2:9b:2e no 0.12
2 fa:16:3e:0d:c0:42 no 20.00
2 fa:16:3e:f8:76:cf no 13.33
1 fe:16:3e:0d:c0:42 yes 0.00
1 fe:16:3e:0d:c0:42 yes 0.00
This shows the Guest (fa:16:3e:0d:c0:42) as Non-Local originating
ens256.3002 instead of tapb2b8c5ff-8c which I suspect causes packets
not being forwarded into tapb2b8c5ff-8c.
The VM has now no means of ingress connectivity to the vlan backed
network but outgoing packets are still being forwarded fine.
It's important to note that instances using vXlan backed networks
function without issues when ageing is set. The issue seems therefore
limited to vlan backed networks.
One significant difference in the FDB table between vlan and vxlan
backed networks is the device which holds the guest MAC. On vxlan
backed networks, this MAC is mapped to the tap device inside the FDB
I have 2 pcap recordings of DHCP traffic, one from the bridge and one
from the tap showing traffic flowing out of the tap but not returning
despite replies arriving on the bridge interface.
iptables have been rules out by prepending a -j ACCEPT at the top of
the neutron-linuxbri-ib2b8c5ff-8 chain.
I talked to @ralonsoh and @seam-k-mooney on IRC yesterday about this
issue and both suggested me to open this bug report.
Let me know if there is any logs/sysctl/settings I should append.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1849463/+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
