Re: duplicate epair ipv6 addresses

2010-09-02 Thread Frank Razenberg 

 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 2
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



___
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"

Re: duplicate epair ipv6 addresses

2010-09-02 Thread Bjoern A. Zeeb 

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 2
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

--
Bjoern A. Zeeb  Welcome a new stage of life.
___
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"

Re: duplicate epair ipv6 addresses

2010-09-02 Thread Frank Razenberg 

 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 
metric 0 mtu 1500

   options=80008
   ether 00:22:15:bb:6d:6f
   inet 10.31.45.10 netmask 0xff00 broadcast 10.31.45.255
   media: Ethernet autoselect (1000baseT )
   status: active
lo0: flags=8049 metric 0 mtu 16384
   options=3
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
   inet6 ::1 prefixlen 128
   inet 127.0.0.1 netmask 0xff00
   nd6 options=3
bridge0: flags=8843 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
   ifmaxaddr 0 port 6 priority 128 path cost 2000
   member: epair1a flags=143
   ifmaxaddr 0 port 5 priority 128 path cost 2000
   member: epair0a flags=143
   ifmaxaddr 0 port 4 priority 128 path cost 2000
   member: nfe0 flags=143
   ifmaxaddr 0 port 1 priority 128 path cost 55
epair0a: flags=8943 
metric 0 mtu 1500

   ether 02:9a:c6:00:04:0a
epair1a: flags=8943 
metric 0 mtu 1500

   ether 02:da:d1:00:05:0a
epair2a: flags=8943 
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



___
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"

Re: duplicate epair ipv6 addresses

2010-09-02 Thread Bjoern A. Zeeb 

On Thu, 2 Sep 2010, Frank Razenberg wrote:

Hey,


base
nfe0: flags=8943 metric 0 mtu 
1500

   options=80008
   ether 00:22:15:bb:6d:6f
   inet 10.31.45.10 netmask 0xff00 broadcast 10.31.45.255
   media: Ethernet autoselect (1000baseT )
   status: active
lo0: flags=8049 metric 0 mtu 16384
   options=3
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
   inet6 ::1 prefixlen 128
   inet 127.0.0.1 netmask 0xff00
   nd6 options=3
bridge0: flags=8843 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
   ifmaxaddr 0 port 6 priority 128 path cost 2000
   member: epair1a flags=143
   ifmaxaddr 0 port 5 priority 128 path cost 2000
   member: epair0a flags=143
   ifmaxaddr 0 port 4 priority 128 path cost 2000
   member: nfe0 flags=143
   ifmaxaddr 0 port 1 priority 128 path cost 55
epair0a: flags=8943 metric 0 
mtu 1500

   ether 02:9a:c6:00:04:0a
epair1a: flags=8943 metric 0 
mtu 1500

   ether 02:da:d1:00:05:0a
epair2a: flags=8943 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

--
Bjoern A. Zeeb  Welcome a new stage of life.
___
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"

Re: duplicate epair ipv6 addresses

2010-09-02 Thread Frank Razenberg 

 Sorry Yavuz,
Here they are:


base
nfe0: flags=8943 metric 
0 mtu 1500

options=80008
ether 00:22:15:bb:6d:6f
inet 10.31.45.10 netmask 0xff00 broadcast 10.31.45.255
media: Ethernet autoselect (1000baseT )
status: active
lo0: flags=8049 metric 0 mtu 16384
options=3
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff00
nd6 options=3
bridge0: flags=8843 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
ifmaxaddr 0 port 6 priority 128 path cost 2000
member: epair1a flags=143
ifmaxaddr 0 port 5 priority 128 path cost 2000
member: epair0a flags=143
ifmaxaddr 0 port 4 priority 128 path cost 2000
member: nfe0 flags=143
ifmaxaddr 0 port 1 priority 128 path cost 55
epair0a: flags=8943 
metric 0 mtu 1500

ether 02:9a:c6:00:04:0a
epair1a: flags=8943 
metric 0 mtu 1500

ether 02:da:d1:00:05:0a
epair2a: flags=8943 
metric 0 mtu 1500

ether 02:ea:c6:00:06:0a


jail1
lo0: flags=8049 metric 0 mtu 16384
options=3
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff00
nd6 options=3
epair0b: flags=8843 metric 0 mtu 
1500

ether 02:00:00:00:05:0b
inet6 fe80::ff:fe00:50b%epair0b prefixlen 64 scopeid 0x2
inet 10.31.45.11 netmask 0xff00 broadcast 10.31.45.255
nd6 options=3


jail2
lo0: flags=8049 metric 0 mtu 16384
options=3
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff00
nd6 options=3
epair1b: flags=8843 metric 0 mtu 
1500

ether 02:00:00:00:06:0b
inet6 fe80::ff:fe00:60b%epair1b prefixlen 64 scopeid 0x2
inet 10.31.45.12 netmask 0xff00 broadcast 10.31.45.255
nd6 options=3


jail3
lo0: flags=8049 metric 0 mtu 16384
options=3
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff00
nd6 options=3
epair2b: flags=8843 metric 0 mtu 
1500

ether 02:00:00:00:07:0b
inet6 fe80::ff:fe00:70b%epair2b prefixlen 64 scopeid 0x2
inet 10.31.45.13 netmask 0xff00 broadcast 10.31.45.255
nd6 options=3

Frank


On 9/2/2010 1:10 PM, yavuz gokirmak wrote:

Hi Frank,

You forgot to paste ifconfigs..


On 2 September 2010 14:06, Frank Razenberg > wrote:


Hi Yavuz,

Thanks for your response. I've pasted the ifconfig output from all
jails below.
I've tried restarting all my jails. Stopping all 3 is no problem,
but when I try to bring up the first jail again, I get a kernel
panic. This seems reproducable; it happen 5/5 times I tried.

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
faujlt virtual address = 0x290
fault code = supervisor data, page not present

I do believe however this is related to my 'other' issue which I
posted at

http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058531.html,
for which the solutions seems to be waiting for Bjoern to apply
some patches.

No matter which jails are active, pinging to ffe80:2::ff:fe00:70b
results in
ping: cannot resolve ffe80:2::ff:fe00:70b: Unknown host

Frank



On 9/2/2010 8:09 AM, yavuz gokirmak wrote:

Hi,
Firstly, it seems that your second jail tries to get
"fe80:2::ff:fe00:70b" address. But I think that second jail
should take an address like "fe80:2::ff:fe00:60b" because its mac
address is "02:00:00:00:06:0b". This is strange, could you send
ifconfig outputs from jails...

Secondly, if I were you, I would create only first jail and try
to ping "ffe80:2::ff:fe00:70b". Try to understand who is holding
this address.

best regards..

yavuz


On 1 September 2010 20:33, Frank Razenberg mailto:fr...@zzattack.org>> wrote:

 Hi,

I'm receiving some messages regarding a possibly duplicate
IPv6 address when starting a vnet jail. I have 3 jails, and
the second one get started is generating some errors.
Starting the third one does not generate any similar error
messages. I've pasted the relevant log sections below:

fileserve's /var/log/messages
Sep  1 17:16:08 fileserve sm-mta[2102]: NOQUEUE:
SYSERR(root): opendaemonsocket: daemon Daemon0: cannot bind:
Address already in use
Sep  1 17:16:08 fileserve sm-mta[2102]: daemon Daemon0:
problem creating SMTP socket
...
Sep  1 17:16:08 fil