Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: foundry

LAG behavior on MLXe-4

 

 

nsp foundry RSS feed   Index | Next | Previous | View Threaded


frnkblk at iname

Mar 8, 2012, 9:30 PM

Post #1 of 5 (1109 views)
Permalink
LAG behavior on MLXe-4

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
Attachments: smime.p7s (6.36 KB)


niels=foundry-nsp at bakker

Mar 9, 2012, 8:55 AM

Post #2 of 5 (1053 views)
Permalink
Re: LAG behavior on MLXe-4 [In reply to]

* frnkblk [at] iname (Frank Bulk) [Fri 09 Mar 2012, 06:47 CET]:
[..]
>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'

If one of the sides stops sending LACP frames, then the LAG will go
down. Use a static LAG if you don't want keepalives.

I am not familiar with your unnamed transport but obviously at least
one party has to initiate for an LACP link to come up.


-- Niels.

--
_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


wimclend at gmail

Mar 9, 2012, 10:27 AM

Post #3 of 5 (1063 views)
Permalink
Re: LAG behavior on MLXe-4 [In reply to]

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>
> To: <foundry-nsp [at] puck>
> 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>
>
> ------------------------------
>


_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


georgeb at gmail

Mar 9, 2012, 10:46 AM

Post #4 of 5 (1052 views)
Permalink
Re: LAG behavior on MLXe-4 [In reply to]

On Fri, Mar 9, 2012 at 10:27 AM, William McLendon <wimclend [at] gmail> wrote:
> 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
>

As is the case with Static on one side and Passive on the other. A
static lag will not transmit LACP and so the passive side will not
link up (and neither will an active, in this case). If one side is
"Static" or "On" then both sides need to be static or on. If one side
is active, then the other side must be either active or passive. If
one side is passive, then the other side must be active.

Active -> Passive works
Active -> Active works
Static -> Static works
Passive -> Passive will not work
Static -> Passive will not work
Static -> Active will not work

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


frnkblk at iname

Mar 10, 2012, 9:59 PM

Post #5 of 5 (1058 views)
Permalink
Re: LAG behavior on MLXe-4 [In reply to]

Thanks for all the clarification received on and off list. I was operating
under the understanding that when in passive mode it fell back to static,
but that's not the case.

Thanks,

Frank

-----Original Message-----
From: foundry-nsp-bounces [at] puck
[mailto:foundry-nsp-bounces [at] puck] On Behalf Of George B.
Sent: Friday, March 09, 2012 12:46 PM
To: William McLendon
Cc: foundry-nsp [at] puck
Subject: Re: [f-nsp] LAG behavior on MLXe-4

On Fri, Mar 9, 2012 at 10:27 AM, William McLendon <wimclend [at] gmail>
wrote:
> 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
>

As is the case with Static on one side and Passive on the other. A
static lag will not transmit LACP and so the passive side will not
link up (and neither will an active, in this case). If one side is
"Static" or "On" then both sides need to be static or on. If one side
is active, then the other side must be either active or passive. If
one side is passive, then the other side must be active.

Active -> Passive works
Active -> Active works
Static -> Static works
Passive -> Passive will not work
Static -> Passive will not work
Static -> Active will not work

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp
Attachments: smime.p7s (6.36 KB)

nsp foundry RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.