Mailing List Archive

Salman,

For FCX (and ICX6610 unless you need mixed family stacking) you should
stick to the 7.3.0 code train. I recommend going to 7.3.0h. 7.3.0j is
newer, however I had stack communication issues with it (just like you're
seeing with 7.4f).


--Jon (works for Brocade)


On Thu, Jun 5, 2014 at 5:26 AM, salman sadiq <salmanravian@gmail.com> wrote:

> Dear Team,
> We have around 300 FCX HPOE switches in a campus network. All of
> them are stacks. After upgrading to 7.4f we have seen a lot of stack sync
> issues. The standby unit in all the cases seems to be the source of the
> problem. Rebooting the stack causes the standby unit to go unresponsive
> unless the unit is hard rebooted. The show stack connection command shows
> the following.
>
> sh stack connection
>
> Probing the topology. Please wait ...
>
> telnet@SW1-XXX#
>
> active standby
>
> +---+ +---+
>
> -2/1| 1 |2/2--2/1| 2 |2/2-
>
> | +---+ +---+ |
>
> | |
>
> |------------------------|
>
>
>
>
>
> **** Error! there should be 2 links, but 0.*
>
> **** Error! no CPU to CPU: u1 -x- u2,*
>
> From another switch
>
> active standby
> +---+ +---+ +---+ +---+ +---+ +---+
> -2/1| 1 |2/2--2/1| 2 |2/2--2/1| 3 |2/2--2/1| 4 |2/2--2/1| 5 |2/2--2/1| 6
> |2/2-
> | +---+ +---+ +---+ +---+ +---+
> +---+ |
> |
> |
> |
> |
> |
> +---+ |
> ------------------------------------------------------------------2/2| 7
> |2/1-
> +---+
>
> *** Error! should have 7 links, but 5: missing u2-u3, u3-u4, .
> Link 1: u7 -- u1, num=1
> 1: 1/2/1 (P0) <---> 7/2/2 (P1)
> Link 2: u2 -- u1, num=1
> 1: 1/2/2 (P1) <---> 2/2/1 (P0)
> Link 3: u5 -- u4, num=1
> 1: 4/2/2 (P1) <---> 5/2/1 (P0)
> Link 4: u6 -- u5, num=1
> 1: 5/2/2 (P1) <---> 6/2/1 (P0)
> Link 5: u7 -- u6, num=1
> 1: 6/2/2 (P1) <---> 7/2/1 (P0)
> *** Error! no CPU to CPU: u1 -x- u3,
> *** Error! no CPU to CPU: u2 -x- u3,
> *** Error! no CPU to CPU: u3 -x- u4,
> *** Error! no CPU to CPU: u3 -x- u5,
> *** Error! no CPU to CPU: u3 -x- u6,
> *** Error! no CPU to CPU: u3 -x- u7,
>
>
> Anyone has seen this before? I'm working with the TAC but they seem to be
> clueless as of now.
>
> BR
> Salman
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

On 05/06/2014 12:58, Jon Maiman wrote:
> For FCX (and ICX6610 unless you need mixed family stacking) you should
> stick to the 7.3.0 code train. I recommend going to 7.3.0h.

I'm seeing some bad memory leak issues on 7.3.00h which weren't present in
7.3.00d (on ti-x24 not fcx, so ymmv). Not sure which exact version they
appeared, but am losing ~5% memory per week on affected boxes. Haven't
found the root cause yet, but suspect snmp polling.

Also, all versions of 7.3 and 7.4 leak about 4k of memory every time you
run nagios check_ssh against them. This is fixed in 8.x and there are
plans to fix it in 7.4.00h, but not 7.3.

Nick


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

We have FCX HPOE switches with fcxs07400b and all are working fine sinc last 2 year.



Are you booting from layer 2 or 3.





#
active standby
+---+ +---+ +---+
-2/1| 1 |2/2--2/1| 3 |2/2--2/1| 2 |2/2-
| +---+ +---+ +---+ |
| |
|-------------------------------------|


trunk probe results: 3 links
Link 1: u2 -- u1, num=1
1: 1/2/1 (P0) <---> 2/2/2 (P1)
Link 2: u3 -- u1, num=1
1: 1/2/2 (P1) <---> 3/2/1 (P0)
Link 3: u3 -- u2, num=1
1: 2/2/1 (P0) <---> 3/2/2 (P1)
CPU to CPU packets are fine between 3 units.

#sh<mailto:SSH@ITD-3FLR-Stk2#sh> ver
Copyright (c) 1996-2012 Brocade Communications Systems, Inc. All rights reserved.
UNIT 1: compiled on Oct 03 2012 at 08:19:10 labeled as FCXS07400b


Regards
Rajesh Singh,
ÑÇÌêÔ ÓæÌ
Sr. Network Engineer,
åçæÏÓ ÔÈãÇÊ Ãèä
Abu Dhabi Media
P.O. Box 114140, Abu Dhabi, United Arab Emirates
Tel +971.2.41.44.901[X], Mob +971.50.66.26.412[X]


________________________________
From: foundry-nsp [foundry-nsp-bounces@puck.nether.net] on behalf of Jon Maiman [jonmaiman@gmail.com]
Sent: Thursday, June 05, 2014 3:58 PM
To: salman sadiq
Cc: foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] Brocade FCX Stack Issue

Salman,

For FCX (and ICX6610 unless you need mixed family stacking) you should stick to the 7.3.0 code train. I recommend going to 7.3.0h. 7.3.0j is newer, however I had stack communication issues with it (just like you're seeing with 7.4f).


--Jon (works for Brocade)


On Thu, Jun 5, 2014 at 5:26 AM, salman sadiq <salmanravian@gmail.com<mailto:salmanravian@gmail.com>> wrote:
Dear Team,
We have around 300 FCX HPOE switches in a campus network. All of them are stacks. After upgrading to 7.4f we have seen a lot of stack sync issues. The standby unit in all the cases seems to be the source of the problem. Rebooting the stack causes the standby unit to go unresponsive unless the unit is hard rebooted. The show stack connection command shows the following.

sh stack connection
Probing the topology. Please wait ...
telnet@SW1-XXX#
active standby
+---+ +---+
-2/1| 1 |2/2--2/1| 2 |2/2-
| +---+ +---+ |
| |
|------------------------|


*** Error! there should be 2 links, but 0.
*** Error! no CPU to CPU: u1 -x- u2,

From another switch

active standby
+---+ +---+ +---+ +---+ +---+ +---+
-2/1| 1 |2/2--2/1| 2 |2/2--2/1| 3 |2/2--2/1| 4 |2/2--2/1| 5 |2/2--2/1| 6 |2/2-
| +---+ +---+ +---+ +---+ +---+ +---+ |
| |
| |
| +---+ |
------------------------------------------------------------------2/2| 7 |2/1-
+---+

*** Error! should have 7 links, but 5: missing u2-u3, u3-u4, .
Link 1: u7 -- u1, num=1
1: 1/2/1 (P0) <---> 7/2/2 (P1)
Link 2: u2 -- u1, num=1
1: 1/2/2 (P1) <---> 2/2/1 (P0)
Link 3: u5 -- u4, num=1
1: 4/2/2 (P1) <---> 5/2/1 (P0)
Link 4: u6 -- u5, num=1
1: 5/2/2 (P1) <---> 6/2/1 (P0)
Link 5: u7 -- u6, num=1
1: 6/2/2 (P1) <---> 7/2/1 (P0)
*** Error! no CPU to CPU: u1 -x- u3,
*** Error! no CPU to CPU: u2 -x- u3,
*** Error! no CPU to CPU: u3 -x- u4,
*** Error! no CPU to CPU: u3 -x- u5,
*** Error! no CPU to CPU: u3 -x- u6,
*** Error! no CPU to CPU: u3 -x- u7,


Anyone has seen this before? I'm working with the TAC but they seem to be clueless as of now.

BR
Salman

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp


---------------------------------------------------------------------------------------
DISCLAIMER
This message (including any attachments) is confidential and intended solely for the person or organization to whom it is addressed. It may contain privileged and confidential information. If you are not the intended recipient, you should not copy, distribute or take any action in reliance on it. If you have received this message in error, please notify us immediately by telephoning or E-mailing the sender. This footnote also confirms that this E-mail message has been scanned for the presence of computer viruses.
---------------------------------------------------------------------------------------
Please consider the environment before printing this email

Nick,

We had issues with an SSH monitor as well.
Disabling that fixes the memory leak (1% mem e3xtra per day used)

-Ronald


Met vriendelijke groet,
With kind regards,

Ronald Esveld
senior network engineer

Qi ict

Delftechpark 35-37
Postbus 402, 2600 AK Delft


T : +31 15 888 0 444
F : +31 15 888 0 445
E : mailto:ronald.esveld@qi.nl
I : http://www.qi.nl

-----Oorspronkelijk bericht-----
Van: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] Namens Nick Hilliard
Verzonden: donderdag 5 juni 2014 14:22
Aan: Jon Maiman; salman sadiq
CC: foundry-nsp@puck.nether.net
Onderwerp: Re: [f-nsp] Brocade FCX Stack Issue

On 05/06/2014 12:58, Jon Maiman wrote:
> For FCX (and ICX6610 unless you need mixed family stacking) you should
> stick to the 7.3.0 code train. I recommend going to 7.3.0h.

I'm seeing some bad memory leak issues on 7.3.00h which weren't present in 7.3.00d (on ti-x24 not fcx, so ymmv). Not sure which exact version they appeared, but am losing ~5% memory per week on affected boxes. Haven't found the root cause yet, but suspect snmp polling.

Also, all versions of 7.3 and 7.4 leak about 4k of memory every time you run nagios check_ssh against them. This is fixed in 8.x and there are plans to fix it in 7.4.00h, but not 7.3.

Nick


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Hi,
We were 7.2d and 7.4d before the upgrade. The reason for upgrade was dhcp
snooping bug in 7.4f pre releases. Due to this bug the switch with DHCP
Snooping enabled drops type 4 dhcp packets on untrusted ports. Hence any
client trying to send a dhcp decline to the dhcp server, in our case as a
result of duplicate ip assigment, fails. Thus the DHCP cannot detect a
duplicate IP resulting in the poor client stuck with an ip that it cannot
utilize. The client eventually sends a discover again and the DHCP server
keeps offering the same IP which is already on the network.

We are using the routing code. Have you seen memory leak on 7.4f as well?
The two problems I've seen on 7.4f are
stack sync issues
Arp table having a lot of entries in "Pending" state.

BR
Salman


On Fri, Jun 6, 2014 at 11:30 AM, Ronald Esveld <ronald.esveld@qi.nl> wrote:

> Nick,
>
> We had issues with an SSH monitor as well.
> Disabling that fixes the memory leak (1% mem e3xtra per day used)
>
> -Ronald
>
>
> Met vriendelijke groet,
> With kind regards,
>
> Ronald Esveld
> senior network engineer
>
> Qi ict
>
> Delftechpark 35-37
> Postbus 402, 2600 AK Delft
>
>
> T : +31 15 888 0 444
> F : +31 15 888 0 445
> E : mailto:ronald.esveld@qi.nl
> I : http://www.qi.nl
>
> -----Oorspronkelijk bericht-----
> Van: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] Namens Nick
> Hilliard
> Verzonden: donderdag 5 juni 2014 14:22
> Aan: Jon Maiman; salman sadiq
> CC: foundry-nsp@puck.nether.net
> Onderwerp: Re: [f-nsp] Brocade FCX Stack Issue
>
> On 05/06/2014 12:58, Jon Maiman wrote:
> > For FCX (and ICX6610 unless you need mixed family stacking) you should
> > stick to the 7.3.0 code train. I recommend going to 7.3.0h.
>
> I'm seeing some bad memory leak issues on 7.3.00h which weren't present in
> 7.3.00d (on ti-x24 not fcx, so ymmv). Not sure which exact version they
> appeared, but am losing ~5% memory per week on affected boxes. Haven't
> found the root cause yet, but suspect snmp polling.
>
> Also, all versions of 7.3 and 7.4 leak about 4k of memory every time you
> run nagios check_ssh against them. This is fixed in 8.x and there are
> plans to fix it in 7.4.00h, but not 7.3.
>
> Nick
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>