Prevent VM's from sniffing in bridge interface

[alebeta]

Hello friends,

I have a bridge interface vmbr2 which is serving VLANs and not subnets not inside of a VLAN.

When I assign a IP from a subnet that is not inside of a VLAN, that VM can sniff all the traffic going through the bridge (YEP... really really bad...).

I would like to know if there is a way to stop VMs to have the possibility to see the bridge all traffic. So far VLAN for that specific network is not possible.

If more details are needed please let me know

all the best

 

[spirit]

This is not normal, you shouldn't see traffic of other vms.

it could happen if the bridge is configured with "bridge_maxage 0", where it don't remember mac address table, and flood traffic on all ports.

do you have any special tuning on your bridge ?

 

[alebeta]

This is not normal, you shouldn't see traffic of other vms.

it could happen if the bridge is configured with "bridge_maxage 0", where it don't remember mac address table, and flood traffic on all ports.

do you have any special tuning on your bridge ?

Hi Spirit thanks for your answer,

the configured had been done with OVS creating a vmbr2 bridge interface with the physical interface of server

Here are relevant config from `interfaces` file:

allow-vmbr2 eno2
iface eno2 inet manual
    ovs_type OVSPort
    ovs_bridge vmbr2

auto vmbr2
iface vmbr2 inet manual
    ovs_type OVSBridge
    ovs_ports eno2

Then the VMs are using vmbr2 as bridge, and the ones who need to use the subnet without vlan tag are the ones with the issue.

thanks in advance

 

[spirit]

do you see the problem, if you isolate the vmbr2 from external world with removing eno2, and create 3 vms on this vmbr2 (1without vlan tag, and 2 others in a vlan). can you also see the traffic on the vm without vlan tag ?

I would like to verify that it could come from somewhere outside the server (physical network or other server)

 

[alebeta]

Hi @spirit

I can not remove eno2, because it is on production. there would be a different way to debug it?

thanks

 

[spirit]

Maybe this blog cloud help you, if it's really a mac learning problem

http://arthurchiao.art/blog/ovs-unknown-unicast-flooding-under-distributed-gw/

try, you should see mac address on the vm on right port/tap interface

"ovs-appctl fdb/show vmbr2"

it's also possible to increase aging time:

ovs-vsctl set bridge vmbr2 other_config:mac-aging-time=600.

(you should check your physical switch mac aging time)

(10min is generally ok to be bigger than almost all os arp timeout)