Date: Thu, 02 Sep 2010 16:14:53 +0200 From: Frank Razenberg <frank@zzattack.org> To: freebsd-virtualization@freebsd.org Subject: Re: duplicate epair ipv6 addresses Message-ID: <4C7FB15D.8040906@zzattack.org> In-Reply-To: <20100902134953.C31898@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Bjoern, 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. I'm not sure whether this answers your questions, if you need any more info please let me know. Frank On 9/2/2010 3:51 PM, Bjoern A. Zeeb wrote: > On Thu, 2 Sep 2010, Frank Razenberg wrote: > > Hey, > >> base >> nfe0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> >> metric 0 mtu 1500 >> options=80008<VLAN_MTU,LINKSTATE> >> ether 00:22:15:bb:6d:6f >> inet 10.31.45.10 netmask 0xffffff00 broadcast 10.31.45.255 >> media: Ethernet autoselect (1000baseT <full-duplex>) >> status: active >> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 >> options=3<RXCSUM,TXCSUM> >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >> inet6 ::1 prefixlen 128 >> inet 127.0.0.1 netmask 0xff000000 >> nd6 options=3<PERFORMNUD,ACCEPT_RTADV> >> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 >> mtu 1500 >> ether de:3b:7a:d8:3a:98 >> 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: epair2a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> >> ifmaxaddr 0 port 6 priority 128 path cost 2000 >> member: epair1a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> >> ifmaxaddr 0 port 5 priority 128 path cost 2000 >> member: epair0a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> >> ifmaxaddr 0 port 4 priority 128 path cost 2000 >> member: nfe0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> >> ifmaxaddr 0 port 1 priority 128 path cost 55 >> epair0a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> >> metric 0 mtu 1500 >> ether 02:9a:c6:00:04:0a >> epair1a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> >> metric 0 mtu 1500 >> ether 02:da:d1:00:05:0a >> epair2a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> >> metric 0 mtu 1500 >> ether 02:ea:c6:00:06:0a > > What makes me wonder is why the ether addresses of all three "a" > epair ends are non-default? Do you know what changed them? Did you > do do avoid collisions with possibly other epairs bridged to a 2nd > machine over nfe0? > > /bz >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C7FB15D.8040906>