I've been using Linux Bridge for years on physical hardware to create a transparent firewall. We are moving this set-up to virtual machines. I'm running into a problem with MAC addresses bouncing between switch ports and need help diagnosing the problem. I've looked online all day yesterday and I can't find a similar symptom.
The set-up:
We have two networks that we want to firewall and a network that we want to NAT. We are using VMware ESX 4.0 server to host the virtual machine which is Debian Squeeze with Linux kernel 2.6.30 and brctl 1.2. I've created two bridges (br0 and br1) and I assign an IP address to br0 and none to br1 so that it is transparent. We are using VGT (Virtual Guest Tagging) for our VLANs for eth0 and eth1 is using VST (Virtual Switch Tagging) for it's VLAN. br0 holds eth0.1 and eth0.11 and br1 holds eth0.2 and eth0.12. eth1 has an IP address of 192.168.1.1 and does NAT though iptables. I've set the virtual portgroup in ESX that is connected to eth0 to accept promiscuous mode.
For the most part things work fine, however, every once and a while the Mac address of a machine on the firewalled side of the switch will show up on the non-firewalled side and for about 1 minute all traffic to/from the machine ceases. This happend much more frequently when I was using purley VST for the bridges. I also get the error "eth0.1: received packet with own address as source" in the logs, again much less frequently with VGT than with VST.
I would like help tracking down the cause of these two problems, but I don't know where to go from here. I've sniffed the traffic on the interface listed in the error message, but all I've seen is a broadcast packet that matches the description of the error.
Thank you,
Robert LeBlanc
Life Sciences & Undergraduate Education Computer Support
Brigham Young University
I'm still working on this problem and this is the new information that I have regarding it. It seems that unicast traffic works just fine, but broadcast traffic is causing the MAC to bounce between ports. Here is a snif on eth1 while doing ping -b on a machine on the other side of 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
Here is the bridge config:
test:/home/rleblanc# brctl show br1
bridge name bridge id STP enabled interfaces
br0 8000.020000510001 no eth1.1002
eth1.769
The interfaces:
lsgw2:/home/rleblanc# ifconfig
br0 Link encap:Ethernet HWaddr 02:00:00:51:00:01
inet addr:10.0.1.2 Bcast:10.0.1.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fe8c:68a8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:348834 errors:0 dropped:0 overruns:0 frame:0
TX packets:305785 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:51104894 (48.7 MiB) TX bytes:57145288 (54.4 MiB)
eth1 Link encap:Ethernet HWaddr 00:50:56:8c:68:a8
inet6 addr: fe80::250:56ff:fe8c:68a8/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:2446112 errors:0 dropped:0 overruns:0 frame:0
TX packets:1160767 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:664454061 (633.6 MiB) TX bytes:442231660 (421.7 MiB)
eth1.769 Link encap:Ethernet HWaddr 02:00:00:51:00:01
inet6 addr: fe80::250:56ff:fe8c:68a8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:588579 errors:0 dropped:0 overruns:0 frame:0
TX packets:580062 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:68490433 (65.3 MiB) TX bytes:394788346 (376.4 MiB)
eth1.1002 Link encap:Ethernet HWaddr 02:00:00:51:00:02
inet6 addr: fe80::250:56ff:fe8c:68a8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:275070 errors:0 dropped:0 overruns:0 frame:0
TX packets:330181 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:333860364 (318.3 MiB) TX bytes:26596772 (25.3 MiB)
I found a list thread that mentioned that bridging VLANs with the same MAC address could cause problems, so I've set each of the VLAN interfaces to have a unique locally administered MAC, this has not helped with this problem. I also get a lot of messages like "eth1.769: received packet with own address as source address" in syslog, but running a tcpdump does not seem to show what packets they are and the ping -b does not make them show up.
I'm running Debian Squeeze with stock kernel:
Linux lsgw2 2.6.30-2-amd64 #1 SMP Mon Dec 7 05:21:45 UTC 2009 x86_64 GNU/Linux
And Bridge utils:
test:/home/rleblanc# brctl -V
bridge-utils, 1.2
Any ideas would be helpful.
Thanks,
Robert LeBlanc
Life Sciences & Undergraduate Education Computer Support
Brigham Young University
_______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
