Mailing List Archive: nsp: foundry

LAG behavior on MLXe-4

Index | Next | Previous | View Threaded

frnkblk at iname

Mar 8, 2012, 9:30 PM

Post #1 of 5 (590 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 (550 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 (555 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 (549 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 (554 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)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads