[f-nsp] LAG behavior on MLXe-4

[William McLendon]

if LACP is used, at least one side must be configured as Active (it will send the LACP PDUs).  both sides can be active, but both sides can not be passive, or it will not work because neither side would be sending LACP PDUs, and thus not know about each other.


Will


> 
> Date: Thu, 8 Mar 2012 23:30:41 -0600
> From: "Frank Bulk" <frnkblk at iname.com>
> To: <foundry-nsp at puck.nether.net>
> Subject: [f-nsp] LAG behavior on MLXe-4
> Message-ID: <0a1e01ccfdb5$c4a753f0$4df5fbd0$@iname.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> Our transport gear's Ethernet card does not send or process LACP packets
> during a soft reboot, so the transport (Active) and Brocade MLXe-4 (Active)
> LAG went down during our last maintenance window on the transport network.
> Tonight we changed the configuration of the Brocade MLXe-4 to passive by
> using the command "deploy passive" command.  The LAG stayed up.
> 
> To test our theory that we can avoid LAG failures during maintenance on the
> transport side by changing the transport side to 'Passive' or 'On/Static',
> we changed the transport side to 'Passive'.  Well, the LAG went down.  I
> then changed the transport side to 'On/Static' and the LAG still stayed
> down.  We restored the link by returning the transport side to 'Active'.
> 
> What are we doing wrong here?  Or is there a bug somewhere?  Shouldn't the
> LAG stay up in the following two configurations:
> 	transport 'Passive' and Brocade MLXe-4 'Passive'
> 	transport 'On/Static' and Brocade MLXe-4 'Passive'
> 
> Frank
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 6517 bytes
> Desc: not available
> URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20120308/a9e303ee/attachment-0001.p7s>
> 
> ------------------------------
>