Public bug reported:
Environment:
Version: Ocata/Stable
Nodes: Two nodes. One node with controller services and network
services(dvr_snat), the other node with compute service and network
services(dvr)
Setups to reproduce:
1. Create networks and DVR and connect them, enable snat.
2. Boot one VM in compute node
3. Ping 8.8.8.8 inside the VM
4. tcpdump the tap device of VM
Observation:
$ sudo tcpdump -nei tap8b25d590-09
fa:16:3e:63:0c:57 > fa:16:3e:c8:7a:67, ethertype IPv4 (0x0800), length 98:
10.0.0.6 > 8.8.8.8: ICMP echo request, id 22273, seq 343, length 64
fa:16:3e:c8:7a:67 > fa:16:3e:ba:67:74, ethertype IPv4 (0x0800), length 98:
10.0.0.6 > 8.8.8.8: ICMP echo request, id 22273, seq 343, length 64
fa:16:3e:ba:67:74 > fa:16:3e:63:0c:57, ethertype IPv4 (0x0800), length 98:
8.8.8.8 > 10.0.0.6: ICMP echo reply, id 22273, seq 343, length 64
Relationship between IP address and MAC address:
VM 10.0.0.6 fa:16:3e:63:0c:57
qr-xxx 10.0.0.1 fa:16:3e:c8:7a:67
sg-xxx 10.0.0.8 fa:16:3e:ba:67:74
Error:
VM should not capture "fa:16:3e:c8:7a:67 > fa:16:3e:ba:67:74",
because it should be an unicast from qr-xxx to sg-xxx. It appears that
in br-int, there is no fdb record for fa:16:3e:ba:67:74, so br-int will
flood frames destined to "fa:16:3e:ba:67:74" to every port in the same
local VLAN. So, VM can capture this unknown unicast.
Since every device in the same local VLAN on the same br-int can
capture the flooded unknown unicast, it will have impact on performance
and security.
Expect:
"qr-xxx to sg-xxx" should mainly be unicast.
** Affects: neutron
Importance: Undecided
Assignee: Hong Hui Xiao (xiaohhui)
Status: New
** Changed in: neutron
Assignee: (unassigned) => Hong Hui Xiao (xiaohhui)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1767811
Title:
[DVR] br-int in compute node will send unknown unicast to sg-xxx
Status in neutron:
New
Bug description:
Environment:
Version: Ocata/Stable
Nodes: Two nodes. One node with controller services and network
services(dvr_snat), the other node with compute service and network
services(dvr)
Setups to reproduce:
1. Create networks and DVR and connect them, enable snat.
2. Boot one VM in compute node
3. Ping 8.8.8.8 inside the VM
4. tcpdump the tap device of VM
Observation:
$ sudo tcpdump -nei tap8b25d590-09
fa:16:3e:63:0c:57 > fa:16:3e:c8:7a:67, ethertype IPv4 (0x0800), length
98: 10.0.0.6 > 8.8.8.8: ICMP echo request, id 22273, seq 343, length 64
fa:16:3e:c8:7a:67 > fa:16:3e:ba:67:74, ethertype IPv4 (0x0800), length
98: 10.0.0.6 > 8.8.8.8: ICMP echo request, id 22273, seq 343, length 64
fa:16:3e:ba:67:74 > fa:16:3e:63:0c:57, ethertype IPv4 (0x0800), length
98: 8.8.8.8 > 10.0.0.6: ICMP echo reply, id 22273, seq 343, length 64
Relationship between IP address and MAC address:
VM 10.0.0.6 fa:16:3e:63:0c:57
qr-xxx 10.0.0.1 fa:16:3e:c8:7a:67
sg-xxx 10.0.0.8 fa:16:3e:ba:67:74
Error:
VM should not capture "fa:16:3e:c8:7a:67 > fa:16:3e:ba:67:74",
because it should be an unicast from qr-xxx to sg-xxx. It appears that
in br-int, there is no fdb record for fa:16:3e:ba:67:74, so br-int
will flood frames destined to "fa:16:3e:ba:67:74" to every port in the
same local VLAN. So, VM can capture this unknown unicast.
Since every device in the same local VLAN on the same br-int can
capture the flooded unknown unicast, it will have impact on
performance and security.
Expect:
"qr-xxx to sg-xxx" should mainly be unicast.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1767811/+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
