[j-nsp] EX4550: LACP channels short lost after commit

Olivier Benghozi olivier.benghozi at wifirst.fr
Sun Nov 1 11:55:02 EST 2015


You can have mixed config for slow/fast (but you want to have slow on each side) since "the transmitter honors the receiver’s rate" (juniper doc).

If the link stays up but is no longer contiguous (a 10G wave over older transmission equipments, an L2VPN link...), you'll have a longer delay to detect that the port must be taken out of the LAG.
If the link just shuts, it will be taken out of the LAG "immediately".


> Le 1 nov. 2015 à 12:20, Jeff Meyers <Jeff.Meyers at gmx.net> a écrit :
> 
> Hi Olivier,
> 
> thanks for your reply. At least it is something, that can be solved then ;-)
> 
> I have two follow-up questions:
> 
> - can I change it to periodic slow without any impact (because the other side is still on slow) or will that have to happen simultaneously because expecting fast does also mean it sends those packets fast?
> 
> - since slow means longer conversion times: will a link down event still wait for the channel member to timeout or will this be handled as an instant member failure?
> 
> 
> Thanks!
> 
> Jeff
> 
> Am 30.10.2015 um 15:05 schrieb Olivier Benghozi:
>> Infamous LAG LACP flap...
>> I think there are several factors: crappy Junos code, LACP is CPU
>> managed (at least on EX), so a pike in CPU (or a latency in the
>> dedicated process) can break LAGs (make them flap in fact).
>> I had some similar issues with SRX code.
>> 
>> Go for slow LACP rate (30 seconds instead of 1 second, like Cisco by
>> default), it will probably work around it efficiently...
>> Suggestion for your ae config:
>> 
>> aggregated-ether-options {
>>     link-speed 10g;
>>     lacp {
>>         active;
>>         periodic slow;
>>     }
>> }
>> 
>> 
>>> Le 30 oct. 2015 à 14:38, Jeff Meyers <Jeff.Meyers at gmx.net
>>> <mailto:Jeff.Meyers at gmx.net <mailto:Jeff.Meyers at gmx.net>>> a écrit :
>>> 
>>> Hi everybody,
>>> 
>>> yesterday we had a very small hickup on a bunch of EX4550 doing Layer2
>>> only in a Virtual-Chassis. According to the logfiles, there were some
>>> LACP changes on multiple independent channels on various fpcs so I
>>> couldn't spot just one VC member as a source.
>>> 
>>> Now, just 1 hour ago, I saw more or less the same messages after a
>>> commit: http://nopaste.linux-dev.org/?797124
>>> 
>>> 
>>> Is this something I should worry about? At least there didn't seem to
>>> be any problem visible in the network but I'm quite unsure if this is
>>> just related to the commit (but doesn't happen every commit) because
>>> the EX needs to activate the new configuration (just added one vlan to
>>> a 10GE port not in a channel) or if there is something suspicious
>>> going on.
>>> 
>>> We are currently running 12.3R4.6 on the VC with 3 members.
>>> 
>>> 
>>> Thanks for any suggestions!
>>> 
>>> 
>>> Best,
>>> Jeff



More information about the juniper-nsp mailing list