duplicate epair ipv6 addresses

Frank Razenberg frank at zzattack.org
Thu Sep 2 14:53:26 UTC 2010


  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
>



More information about the freebsd-virtualization mailing list