Hey Bjoern,
Thanks for checking. This unfortunately is the only machine on the LAN
with epairs, so I guess we run out of possible explanations then :(
Just to make sure, I will be running memory tests all night.
It's probably a long shot, but could this is related to the if_tap
problem I mailed about earlier on freebsd-stable@ list? If so, I'm very
interested in testing the result once you did the patching you mentioned
in that thread. Is there a way for me to know when you've done so? If
you like I would also volunteer to test these patches before they're
merged with any kind of source tree.
Frank
On 9/2/2010 4:28 PM, Bjoern A. Zeeb wrote:
On Thu, 2 Sep 2010, Frank Razenberg wrote:
Hey Frank,
I do have an openvpn setup which also creates a bridge. At one point
in time it conflicted with the bridge0 interface used for the jails.
The openvpn 'up' script did the following:
#!/bin/sh
/sbin/ifconfig bridge0 create
/sbin/ifconfig bridge0 addm nfe0 addm $dev up
/sbin/ifconfig $dev up
It may have executed a couple of times while bridge0 already existed
and had the epairs as members. I don't recall the epair's 'a'-end
having different ethernet addresses before, but I haven't
specifically looked at them. I don't believe I do any manual
collision detection.
Ok, then this is strange than unless if_bridge(4) is doing it. No,
doesn't seem so and I wouldn't have expected it either:
lion3# ifconfig epair99 create
epair99a
lion3# ifconfig epair99a
epair99a: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
1500
ether 02:00:00:00:09:0a
lion3# ifconfig epair99b
epair99b: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
1500
ether 02:00:00:00:0a:0b
lion3# ifconfig bridge0 create
lion3# ifconfig bridge0 up
lion3# ifconfig bridge0 addm epair99a
lion3# ifconfig epair99a
epair99a: flags=8942<BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
metric 0 mtu 1500
ether 02:00:00:00:09:0a
lion3# ifconfig epair99a up
lion3# ifconfig epair99b up
lion3# ifconfig epair99a
epair99a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
metric 0 mtu 1500
ether 02:00:00:00:09:0a
lion3# ifconfig bridge0
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
mtu 1500
ether be:de:50:ce:29:3b
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: epair99a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 9 priority 128 path cost 2000
lion3# ifconfig bridge0 addm ix1
lion3# ifconfig epair99a
epair99a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
metric 0 mtu 1500
ether 02:00:00:00:09:0a
lion3# ifconfig bridge0
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
mtu 1500
ether be:de:50:ce:29:3b
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: ix1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 6 priority 128 path cost 20000
member: epair99a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 9 priority 128 path cost 2000
As you can see the epair99a interface still has the same ether address
02:00:00:<if:index>:0a as when intiially created.
There is either some memory corruption or other magic happening for you.
I'm not sure whether this answers your questions, if you need any
more info please let me know.
Are you having multiple machines with epairs bridge to the same LAN?
If so you may have collisions of epair<N>b nodes with overlapping ether
addresses, which IPv6 ND6 DAD (duplicate address detection) would
notice. You would probably find multiple 02:00:00:00:07:0b addresses
on different machines. Which also means that you'll have to do manual
ether address assignments (see 3rd paragraph of the DESCRIPTION
section in the epair(4) manual page.
/bz
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
