Hi,
I am seeing a strange issue with a fairly simple bridge I have setup (for
openvpn in bridge mode).
eth0 --- [ openvpn machine (tap0) ] --- eth1
The bridge is between tap0 and eth1 on a debian machine running on ESX 4. (tap0
being the openvpn tunnel interface). Intermittently, I see openvpn client MAC
addresses on port 2 (eth1). When this happens, their vpn link stops working,
since arp replies are being sent back via the wrong interface. But after a
random amount of time, it will change back to port 1 (tap0) and start working
again. Sometimes this is quick, sometimes it doesn't happen for hours.
Anyone else had these issues? I've searched the archives, and come across
several people who seem to have had similar problems - but haven't found one
that has a solution yet.
I'd appreciate any suggestions on where I should start looking to find out
why/how these MAC's are being learnt on the wrong interface...
brctl show br0:
bridge name bridge id STP enabled
interfaces
br0 8000.005056b804c2 no
eth1
tap0
brctl showstp br0:
br0
bridge id 8000.005056b804c2
designated root 8000.005056b804c2
root port 0
path cost 0
max age 20.00
bridge max age 20.00
hello time 2.00
bridge hello time 2.00
forward delay 5.00
bridge forward delay 5.00
ageing time 300.01
hello timer 1.19
tcn timer 0.00
topology change timer 0.00 gc timer
2.19
flags
eth1 (2)
port id 8002 state
forwarding
designated root 8000.005056b804c2 path cost
100
designated bridge 8000.005056b804c2 message age timer
0.00
designated port 8002 forward
delay timer 0.00
designated cost 0
hold timer 0.19
flags
tap0 (1)
port id 8001 state
forwarding
designated root 8000.005056b804c2 path cost
100
designated bridge 8000.005056b804c2 message age timer
0.00
designated port 8001 forward
delay timer 0.00
designated cost 0
hold timer 0.19
flags
eg:
brctl showmacs br0:
port no mac addr is local? ageing
timer
2 00:50:56:b8:04:c2 yes 0.00
1 00:ff:46:97:7f:d5 yes
0.00
2 7a:6e:9f:28:12:79 no
0.56
7a:6e:9f:28:12:79 -- the openvpn client
00:ff:.... -- tap0
00:50:56... -- eth1
Thanks,
Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.linux-foundation.org/pipermail/bridge/attachments/20100108/555484b7/attachment-0001.htm
Robert LeBlanc
2010-Jan-11 17:16 UTC
[Bridge] MAC intermittently being learnt on wrong port
On Thu, Jan 7, 2010 at 8:25 PM, Ryan King <ryank at staff.globaldial.com>wrote:> Hi, > > > > I am seeing a strange issue with a fairly simple bridge I have setup (for > openvpn in bridge mode). > > > > eth0 --- [ openvpn machine (tap0) ] --- eth1 > > > > The bridge is between tap0 and eth1 on a debian machine running on ESX 4. > (tap0 being the openvpn tunnel interface). Intermittently, I see openvpn > client MAC addresses on port 2 (eth1). When this happens, their vpn link > stops working, since arp replies are being sent back via the wrong > interface. But after a random amount of time, it will change back to port 1 > (tap0) and start working again. Sometimes this is quick, sometimes it > doesn't happen for hours. > > > > Anyone else had these issues? I've searched the archives, and come across > several people who seem to have had similar problems - but haven't found one > that has a solution yet. > > > > I'd appreciate any suggestions on where I should start looking to find out > why/how these MAC's are being learnt on the wrong interface... > > > > > > brctl show br0: > > > > bridge name bridge id STP enabled > interfaces > > br0 8000.005056b804c2 > no eth1 > > > tap0 > > > > > > brctl showstp br0: > > > > br0 > > bridge id 8000.005056b804c2 > > designated root 8000.005056b804c2 > > root port > 0 path > cost 0 > > max age > 20.00 bridge max age > 20.00 > > hello time > 2.00 bridge hello time > 2.00 > > forward delay 5.00 > bridge forward delay 5.00 > > ageing time 300.01 > > hello timer > 1.19 tcn > timer 0.00 > > topology change timer 0.00 gc > timer 2.19 > > flags > > > > > > eth1 (2) > > port id 8002 > state forwarding > > designated root 8000.005056b804c2 path > cost 100 > > designated bridge 8000.005056b804c2 message age > timer 0.00 > > designated port 8002 > forward delay timer 0.00 > > designated cost > 0 hold > timer 0.19 > > flags > > > > tap0 (1) > > port id 8001 > state forwarding > > designated root 8000.005056b804c2 path > cost 100 > > designated bridge 8000.005056b804c2 message age > timer 0.00 > > designated port 8001 > forward delay timer 0.00 > > designated cost > 0 hold > timer 0.19 > > flags > > > > > > eg: > > brctl showmacs br0: > > > > port no mac addr is local? > ageing timer > > 2 00:50:56:b8:04:c2 yes > 0.00 > > 1 00:ff:46:97:7f:d5 yes > 0.00 > > 2 7a:6e:9f:28:12:79 no > 0.56 > > > > 7a:6e:9f:28:12:79 -- the openvpn client > > 00:ff:.... -- tap0 > > 00:50:56... -- eth1 > > > > > > > > > > > > Thanks, > > > > Ryan >I too am seeing this problem, I've tested with Lenny and Squeeze on ESX 4 and still see the same problem. I am anxiously awaiting some help on how to troubleshoot the problem. This is a big hang up for me. I don't know if the virtual switch is sending out multiple replies or what, I'm going to set this up on some physical hardware and compare. I don't know what else to do. Thanks, 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/20100111/adf9fb34/attachment.htm
Stephen Hemminger
2010-Jan-11 18:18 UTC
[Bridge] MAC intermittently being learnt on wrong port
On Fri, 8 Jan 2010 03:25:10 +0000 Ryan King <ryank at staff.globaldial.com> wrote:> Hi, > > I am seeing a strange issue with a fairly simple bridge I have setup (for openvpn in bridge mode). > > eth0 --- [ openvpn machine (tap0) ] --- eth1 > > The bridge is between tap0 and eth1 on a debian machine running on ESX 4. (tap0 being the openvpn tunnel interface). Intermittently, I see openvpn client MAC addresses on port 2 (eth1). When this happens, their vpn link stops working, since arp replies are being sent back via the wrong interface. But after a random amount of time, it will change back to port 1 (tap0) and start working again. Sometimes this is quick, sometimes it doesn't happen for hours. > > Anyone else had these issues? I've searched the archives, and come across several people who seem to have had similar problems - but haven't found one that has a solution yet. > > I'd appreciate any suggestions on where I should start looking to find out why/how these MAC's are being learnt on the wrong interface... >By default the address of the bridge interface is the minimum of all the interfaces, and the tap one is generated randomly; that might be your problem. So either: 1. force a specific MAC address on the tap interface or 2. force the the MAC address of the bridge interface to be that of eth