| 2018-05-04 03:21:10 |
Hong Hui Xiao |
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. |
Environment:
Installation: devstack
Dataplane: OpenVSwitch
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. |
|
