Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 03 Feb 2014 10:29:56 +0100
From:      Ben <mailinglists@niessen.ch>
To:        Scott Long <scott4long@yahoo.com>
Cc:        FreeBSD Net <freebsd-net@freebsd.org>
Subject:   Re: kern/185967: Link Aggregation LAGG: LACP not working in 10.0
Message-ID:  <52EF6194.5060305@niessen.ch>
In-Reply-To: <B2A60D0D-26AA-4EB4-B5E6-D44164C9AE83@yahoo.com>
References:  <52EF50A7.1050205@niessen.ch> <1C608452-6F29-486D-BC0F-CCC7853665C7@yahoo.com> <52EF55FE.8030901@niessen.ch> <1798FE17-5718-4125-8B00-1B00DC44B828@yahoo.com> <52EF5D1E.2000306@niessen.ch> <B2A60D0D-26AA-4EB4-B5E6-D44164C9AE83@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Yes, via sysctl and /etc/sysctl.conf

I waited now roughly 20 minutes without touching it but no difference.

No, I only see these transmit messages, no receive.

Thanks
Ben

On 03.02.2014 10:25, Scott Long wrote:
> Did you set it to 0 via the sysctl?  You might need to wait for several=
 minutes if you set it after setting up the links.
>
> Also, the message that you=92re seeing is from your machine transmittin=
g PDU packets.  Are you seeing any "lacpdu receive=94 messages on the con=
sole?
>
> Thanks,
> Scott
>
> On Feb 3, 2014, at 2:10 AM, Ben <mailinglists@niessen.ch> wrote:
>
>> Hi,
>>
>> I set strict mode to 0 but no use. I do receive PDU messages.
>>
>> igb0: lacpdu transmit
>> actor=3D(...)
>> actor.state=3D4d<ACTIVITY,AGGREGATION,SYNC,DEFAULTED>
>> partner=3D(...)
>> partner.state=3D0
>> maxdelay=3D0
>>
>> Thanks
>> Ben
>>
>> On 03.02.2014 10:03, Scott Long wrote:
>>> Hi,
>>>
>>> Unfortunately, you can=92t control the strict mode globally.  My apol=
ogies for this mess, I=92ll make sure that it=92s fixed for FreeBSD 10.1.=
  If the sysctl doesn=92t help then maybe consider compiling a custom ker=
nel with it defaulted to 0.  You=92ll need to open /sys/net/ieee802ad_lac=
p.c and look for the function lacp_attach().  You=92ll see the strict_mod=
e assign underneath that.  I=92ll also send you a patch in a few minutes.=
  Until then, try enabling net.link.lagg.lacp.debug=3D1 and see if you=92=
re receiving heartbeat PDU=92s from your switch.
>>>
>>> Scott
>>>
>>> On Feb 3, 2014, at 1:40 AM, Ben <mailinglists@niessen.ch> wrote:
>>>
>>>> Hi Scott,
>>>>
>>>> I had tried to set it in /etc/sysctl.conf but seems it didnt work. B=
ut will I try again and report back.
>>>>
>>>> The settings of the switch have not been changed and are set to LACP=
. It worked before so I guess the switch should not be the problem. Maybe=
 some incompatibility between FreeBSD + igb-driver + switch (Juniper EX33=
00-48T).
>>>>
>>>> I will update you after setting the sysctl setting. It seems to be "=
dynamic", I guess 0 reflects the index of LACP lagg devices. Can I switch=
 off the strict mode globally in /etc/sysctl.conf?
>>>>
>>>> Thanks for your help.
>>>>
>>>> Regards
>>>> Ben
>>>>
>>>> On 03.02.2014 09:31, Scott Long wrote:
>>>>> Hi,
>>>>>
>>>>> You=92re probably running into the consequences of r253687.  Check =
to see the value of =91sysctl net.link.lagg.0.lacp.lacp_strict_mode=92. I=
f it=92s =911=92 then set it to 0.  My original intention was for this to=
 default to 0, but apparently that didn=92t happen.  However, the fact th=
at strict mode doesn=92t seem to work at all for you might hint that your=
 switch either isn=92t configured correctly for LACP, or doesn=92t actual=
ly support LACP at all.  You might want to investigate that.
>>>>>
>>>>> Scott
>>>>>
>>>>> On Feb 3, 2014, at 1:17 AM, Ben <mailinglists@niessen.ch> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I upgraded from FreeBSD 9.2-RELEASE to 10.0-RELEASE. FreeBSD 9.2 w=
as configured to use LACP with two igb devices.
>>>>>>
>>>>>> Now it stopped working after the upgrade.
>>>>>>
>>>>>> This is a screenshot of ifconfig -a after the upgrade to FreeBSD 1=
0.0-RELEASE: http://tinypic.com/view.php?pic=3D28jvgpw&s=3D5#.Uu9PXT1dVPM
>>>>>>
>>>>>> A PR is currently open: http://www.freebsd.org/cgi/query-pr.cgi?pr=
=3Dkern/185967
>>>>>>
>>>>>> It is set to low, but I would like somebody to have a look into it=
 as it obviously has a great influence on our infrastructure. The only wa=
y to "solve" it is currently switching back to FreeBSD 9.2.
>>>>>>
>>>>>> The suggested fix "use failover" seems not to work.
>>>>>>
>>>>>> Thank you for your help.
>>>>>>
>>>>>> Best regards
>>>>>> Ben
>>>>>> _______________________________________________
>>>>>> freebsd-net@freebsd.org mailing list
>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.=
org"
>>>>> _______________________________________________
>>>>> freebsd-net@freebsd.org mailing list
>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.o=
rg"
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> freebsd-net@freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.or=
g"
>>> _______________________________________________
>>> freebsd-net@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org=
"
>>>
>>>
>>>
>>>
>> _______________________________________________
>> freebsd-net@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
> !DSPAM:1,52ef6078888821231914487!
>
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52EF6194.5060305>