[ovs-discuss] ARP strom with OVS

Edu Serra neosepia at gmail.com
Mon Jul 8 18:40:06 UTC 2013


Hi,

Our topology consists of 2 VM on one host machine running KVM, every VM has
2 interfaces.

An openvswitch instance running on the host, which has 2 logical separate
bridges, one for management and the other for internal usage between VM's.

We wanted, through one of the bridges, to use it for management of all VM's
as well as the host. So a trunk (VLAN 100) arrives at the host and gets to
the first bridge in openvswitch. Then after, we configure an internal port
(tagged 100) for the host, and 2 additional ports, each one connected to
each VM and also tagged 100. Until here it is all ok, connectivity works
just fine, and from vlan 100 we can get to all machines (be them VM's or
the host, for management purposes).

Now we wanted to have separate completly internal networks which aim to
generate internal trafic between the VMs. We configured an additional
bridge connected to the VM's as well in another 2 interfaces (1 for each
VM) to create another network just for those 2 VM's (this connection is
separated VLAN tagged 150).

Problem: The very same moment one of the machines send an ARP request in
the internal network, the ARP gets replicated even on the other network
(VLAN 100) to the point the very same host hungs up having 2 VM's running
at 100%.

In the beggining, we have thought vlan's would solve the problem and help
segment the two networks and avoid the arp storm. Then we tried to make the
hosts not to announce or answer back ARP requests that were not directly
related to their interface. Nothing has worked.

We tried this very same thing setting a controller properly installed, but
still doesen't explain why without controller the ARP storm gets across the
the 2 VLANS.

Any help on the case would be much appreciated. Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20130708/2331d8c2/attachment.html>


More information about the discuss mailing list