Date: Thu, 02 Sep 2010 16:52:33 +0200 From: Frank Razenberg <frank@zzattack.org> To: freebsd-virtualization@freebsd.org Subject: Re: duplicate epair ipv6 addresses Message-ID: <4C7FBA31.9000205@zzattack.org> In-Reply-To: <20100902142102.R31898@maildrop.int.zabbadoz.net> References: <4C7E8E7C.7090708@zzattack.org> <AANLkTikasp%2B6nFuCrDnAy7Vt4-7Lgbyza7AexQ_MCVyH@mail.gmail.com> <4C7F8551.6020901@zzattack.org> <AANLkTinX1G0ncjXrqhs4L6suJJXsywGQ2KS0q9auYxKD@mail.gmail.com> <4C7FA623.2010802@zzattack.org> <20100902134953.C31898@maildrop.int.zabbadoz.net> <4C7FB15D.8040906@zzattack.org> <20100902142102.R31898@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C7FBA31.9000205>