LACP does not react to a LINK DOWN - NEXUS 3xxx

[jssalgado]

We have 2 NEXUS Switches in VPC and a port-channel with 2 10G members link (one member in every switch), all this in SITE A. On the other hand, we have a SITE B with the same hardware configuration.   The port-channel between SITES carries only a 802.1q TRUNK with a few vlans.    Between these 2 SITES there is a DWDM WAN, and sometimes this type of network presents little commutations inside the DWDM Network (less than 50msec) only for one of the LINKs and the particular NEXUS switch receives a LINK DOWN, however the LACP does not remove that LINK from the port-channel immediately.  So The problem is that the traffic on the failed link does not switch to the other member link causing all type of problems. The question is: Should the LACP protocol remove the affected link from the port-channel immediatly when the Switch receives a LINK DOWN?  Or It has to wait for the 90  sec (by default 3 x 30sec(hello))?

[marce1000]

                        >...and the particular NEXUS switch receives a LINK DOWN
  - Depends on how you define this , if that does not include a physical link down event on the cisco nexus lcap  interface because of the WAN infrastructure then LACP will not care (initially and or immediately)

 M.

[jssalgado]

Thanks so much 'Marce1000', for the analysis and comments. Since the switches are not connected back-to-backup they don't see a L1 down. The DWDM network has been configure to maintain the port up (L1) and you may be right, they never see a physical interface down, so LACP must time out at the third hello (90 sec).  We’ll ask to reconfigure the DWDM network, so that it reflects the problem at L1 and we’ll expect LACP react this time, removing the link from the port-channel.

Thanks again for your answer.

[MHM Cisco World]

The question is: Should the LACP protocol remove the affected link from the port-channel immediatly when the Switch receives a LINK DOWN?  Or It has to wait for the 90  sec (by default 3 x 30sec(hello))?
All non L1 protocol depend on L1 status for fast recover,

what I meaning that 

LACP depend on L1 status to remove one of member port, 
BUT that not so optimal in all case 
some case (like your case) the two pair is not direct connect, this prevent L1 from detect the link failed. 
here LACP can not depend on L1 status so it will use missing hello message to declare the member port is down. that why the 90 sec delay between link down and LACP detect it. 

this lead to some real issue because the STP timeout is less than 90 and hence the STP is detect link down and start new elect but LACP still assume the link UP. 

solution for this case 
config lacp fast  

[jssalgado]

Thanks so much 'MHM'. As I told 'Marce1000', for the analysis and comments. Since the switches are not connected back-to-backup, the DWDM network has been configure to maintain the port up (L1) and you may be right, they never see a physical interface down, so LACP must time out at the third hello (90 sec).  We’ll ask to reconfigure the DWDM network, so that it reflects the problem at L1 and we’ll expect LACP react this time, removing the link from the port-channel.

Thanks again for your answer. Both of you focused the ISSUE similarly.

[MHM Cisco World · Accepted solution]

Try use fast LAC (if the Link is support this fast LACP hello message).