Bug 185660 - lagg(4) IPv6-related problem with interface creation
Summary: lagg(4) IPv6-related problem with interface creation
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-net (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-11 16:50 UTC by Michael Moll
Modified: 2015-12-14 19:16 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Moll freebsd_committer freebsd_triage 2014-01-11 16:50:00 UTC
With the following in /etc/rc.conf:
cloned_interfaces="lagg0"
ifconfig_em0="up"
ifconfig_em1="up"
ifconfig_lagg0="up laggproto lacp laggport em0 laggport em1 192.168.200.8/24"
ifconfig_lagg0_ipv6="inet6 2001:x:x:x::8/64"
ipv6_defaultrouter="2001:x:x:x::1"
defaultrouter="192.168.200.1"
ipv6_activate_all_interfaces="YES"
ip6addrctl_policy="ipv6_prefer"

a successful startup looks like this:
Created clone interfaces: lagg0.
lagg0: IPv6 addresses on em0 have been removed before adding it as a member to prevent IPv6 address scope violation.
lagg0: link state changed to DOWN
lagg0: IPv6 addresses on em1 have been removed before adding it as a member to prevent IPv6 address scope violation.
Starting Network: lo0 em0 em1 lagg0.

However, about 70% of boots result in this:
Created clone interfaces: lagg0.
em0: link state changed to UP
em1: link state changed to UP
[hang]

When doing Ctrl-T at this point I get:
load: 1.51  cmd: ifconfig 606 [*in6_multi_mtx] 17.80r 0.00u 0.72s 0% 1940k

How-To-Repeat: I have a second box (different board, also with em-Interfaces) with the same behaviour.
Comment 1 Michael Moll freebsd_committer freebsd_triage 2014-01-26 14:26:21 UTC
after removing
ipv6_activate_all_interfaces="YES"
from /etc/rc.conf everything works fine.

Maybe a race condition in the IPv6 code?
Comment 2 Michael Moll freebsd_committer freebsd_triage 2015-12-14 19:16:47 UTC
can't reproduce with a recent 10-STABLE version