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

2015-11-01 Thread Jeff Meyers

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



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

2015-11-01 Thread Olivier Benghozi
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  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 >> >> 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

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

2015-10-30 Thread 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  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

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

2015-10-30 Thread Jeff Meyers

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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp