From owner-freebsd-virtualization@FreeBSD.ORG Thu Sep 2 14:53:26 2010 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F31D1065696 for ; Thu, 2 Sep 2010 14:53:26 +0000 (UTC) (envelope-from frank@zzattack.org) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id E905A8FC34 for ; Thu, 2 Sep 2010 14:53:25 +0000 (UTC) Received: by ewy4 with SMTP id 4so345097ewy.13 for ; Thu, 02 Sep 2010 07:53:24 -0700 (PDT) Received: by 10.213.13.142 with SMTP id c14mr81715eba.84.1283439204569; Thu, 02 Sep 2010 07:53:24 -0700 (PDT) Received: from [10.31.45.197] (21-78-ftth.onsneteindhoven.nl [88.159.78.21]) by mx.google.com with ESMTPS id z55sm831630eeh.15.2010.09.02.07.53.21 (version=SSLv3 cipher=RC4-MD5); Thu, 02 Sep 2010 07:53:21 -0700 (PDT) Message-ID: <4C7FBA31.9000205@zzattack.org> Date: Thu, 02 Sep 2010 16:52:33 +0200 From: Frank Razenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org References: <4C7E8E7C.7090708@zzattack.org> <4C7F8551.6020901@zzattack.org> <4C7FA623.2010802@zzattack.org> <20100902134953.C31898@maildrop.int.zabbadoz.net> <4C7FB15D.8040906@zzattack.org> <20100902142102.R31898@maildrop.int.zabbadoz.net> In-Reply-To: <20100902142102.R31898@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: duplicate epair ipv6 addresses X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 14:53:26 -0000 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 metric 0 mtu > 1500 > ether 02:00:00:00:09:0a > lion3# ifconfig epair99b > epair99b: flags=8842 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 > 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 > metric 0 mtu 1500 > ether 02:00:00:00:09:0a > lion3# ifconfig bridge0 > bridge0: flags=8843 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 > ifmaxaddr 0 port 9 priority 128 path cost 2000 > lion3# ifconfig bridge0 addm ix1 > lion3# ifconfig epair99a > epair99a: flags=8943 > metric 0 mtu 1500 > ether 02:00:00:00:09:0a > lion3# ifconfig bridge0 > bridge0: flags=8843 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 > ifmaxaddr 0 port 6 priority 128 path cost 20000 > member: epair99a flags=143 > 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::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 epairb 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 >