[Bridge] Need help writing ebtables rules

Robert LeBlanc robert at leblancnet.us
Tue Jan 19 14:30:21 PST 2010


So, I've found the problem with my VMware bridge and need help 'fixing' it.
Short story is, since the virtual switch in ESX is not a true Layer 2
switch, VMware uses some short cuts to improve performance. They allow
physical adapters to be connected to one virtual switch and a VM will be
assigned a physical adapter and only send traffic out that one adapter, but
can receive traffic on any adapter. This works great for the common case as
the VMs are load balanced between NICs. In my case with a bridge it causes
problems.

When broadcast traffic is sent, the traffic is reflected by switches farther
up and seen as duplicates in the VM. Here is the layout: ESX server in HP
chassis with 4 NICs, each NIC is connected to one of 4 switches in the HP
chassis. The 4 HP chassis switches are connected to a set of HP Procurve
switches. When a VM behind the bridge VM sends a broadcast messages, it goes
out one NIC, to one of the HP chassis switches, to the Procurve switch,
which sends the broadcast on all ports, back to another HP chassis switch
connected to another NIC on the ESX server and gets sent to the VM causing
the duplicate. With real switches, you would create trunk groups and would
not have this problem.

So, I need some clever ebtables rules to drop this duplicate traffic. I used
ebtables years ago and then found that I could do what I needed with
iptables so I abandoned it. Needless to say, my ebtables foo is not very
good. Here is some of the duplicate traffic as seen by the bridge:

test:/home/rleblanc# tcpdump -i eth1 ether host 00:50:56:8c:2e:6a
tcpdump: WARNING: eth1: no IPv4 address
assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96
bytes
09:31:36.826198 vlan 1002, p 0, IP 10.0.1.1 > 10.0.1.255: ICMP echo request,
id 64780, seq 1, length 64
09:31:36.826226 vlan 769, p 0, IP 10.0.1.1 > 10.0.1.255: ICMP echo request,
id 64780, seq 1, length 64
09:31:36.826632 vlan 769, p 0, IP 10.0.1.1 > 10.0.1.255: ICMP echo request,
id 64780, seq 1, length 64
09:31:36.826647 vlan 1002, p 0, IP 10.0.1.1 > 10.0.1.255: ICMP echo request,
id 64780, seq 1, length 64
09:31:37.826022 vlan 1002, p 0, IP 10.0.1.1 > 10.0.1.255: ICMP echo request,
id 64780, seq 2, length 64
09:31:37.826044 vlan 769, p 0, IP 10.0.1.1 > 10.0.1.255: ICMP echo request,
id 64780, seq 2, length 64
09:31:37.826497 vlan 769, p 0, IP 10.0.1.1 > 10.0.1.255: ICMP echo request,
id 64780, seq 2, length 64
09:31:37.826517 vlan 1002, p 0, IP 10.0.1.1 > 10.0.1.255: ICMP echo request,
id 64780, seq 2, length 64
09:31:38.826016 vlan 1002, p 0, IP 10.0.1.1 > 10.0.1.255: ICMP echo request,
id 64780, seq 3, length 64
09:31:38.826036 vlan 769, p 0, IP 10.0.1.1 > 10.0.1.255: ICMP echo request,
id 64780, seq 3, length 64
09:31:38.826444 vlan 769, p 0, IP 10.0.1.1 > 10.0.1.255: ICMP echo request,
id 64780, seq 3, length 64
09:31:38.826462 vlan 1002, p 0, IP 10.0.1.1 > 10.0.1.255: ICMP echo request,
id 64780, seq 3, length 64
^C

12 packets
captured

12 packets received by
filter

0 packets dropped by kernel

Thank you,

Robert LeBlanc
Life Sciences & Undergraduate Education Computer Support
Brigham Young University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/bridge/attachments/20100119/9fb35636/attachment.htm 


More information about the Bridge mailing list