Baystack 450 Cascade Problem 1

[Aaron1to1]

Hi,

Can anyone help with a problem: I support a large LAN of 21 DataCabinets each one an individual VLAN. The connectivity is as follows:
2 x BPS2k switches fibered back to 2 x 8600's running MLT.
(Firmware 3.0.0.5 & 3.0.3.08)
These are cascaded back to various numbers of B450-24Ts using cascade modules
(Firmware v4.3)
My question is this: Every so often, the BPS2k's BASE lights flash and in doing so - drop the stack to that cab. After various re-boots the cab sorts itself back out. Also the Base BPS2k can lose its VLAN and Spanning tree info - causing a broadcast storm on the 8600's (Very Bad!!) - anyone have any ideas what the issue could be - thankyou

 

[whiskeytrain]

Are your 8600's setup with an IST between them? Would you be able to provide some more detail about your BPS to 450 cascades. How many stacks do you have? We have a mountain of BPS and 450 stacks(same rev's of code) and have not had any problems like what is happening to you. Has it worked correctly until some point in the recent past, or was it never stable?

 

[pgerth]

If you are losing one or more switches in the stack it could be the cascade cables. It's usually the longer one , the old ones were white/grey the new ones are black. We chased problems like this for several months at one of our sites until we got the new cables in

---p

 

[Aaron1to1]

Guys - Yes I am running IST between the 8600's - The customer site that I manage are running about 21 stacks of switches. This problem to be fair hasnt happened to every stack, but to about 4 or 5 of them approx 1 a month or so at a time, and are completely random in nature.

The stacks have all worked in the past - and are currently working complelely fine (touch wood!), but I know sometime soon - a stack will fail showing all up and down cascade lights on the stack to flash - like they were running different versions of code.

The way in which I've setup the stacks back to the 8600's are as follows:

switch 1 in the stack (set to base) has a fiber link back to an 8600

This is cascaded to switch 2 also an 8600 which is fibered back to a second 8600. This switch is cascaded to a B450-24T switch 3, cascaded to B450-24T switch 4 - and so and so on. The final B450-24T in the stack then cascades back to BPS2k switch 1 - to complete the stack.

Both Gbit fiber links are MLT'd together and are running 3 VLANS (1 is on by default and not used, VLAN 1999 - is a management VLAN, and a specific VLAN for that CAB eg 31 or 41 or 51 depending on what cab it is).

Question: Could both BPS2k's be "fighting" for control of the stack at any point? - is it better to only have 1 BPS2k per stack?? - sorry for the length of this post.

 

[whiskeytrain]

What code do you have on the 8600s? Are you using SMLT on the two 8600's for the gig links to the stack(s)MLTs?

 

[mmits]

Darney, how are the 2 8600's setup?

 

[JohnJohn]

We had this same issue. Turned out to be a bad breaker in a panel to the closet and the stack was rebooting and the base was lost. Seemed to be when the base booted after the rest of the stack.

John

 

[storm14]

We had a similar problem with the BPSs on hybrid stacks if I understand this is the way your connecting the 450s. Once we remove the BPSs and ran a pure stack vs hybrid our problems went away. Hope this helps.

 

[gford]

Is switch one in your stack the base, if so try making the last switch the base member, it helped us

 

[rjenk]

Hybrid stacks with two BPS2000's and 450's should not be a problem. I am running about 50 closets with that configuration and have not encountered any issues so long as you ensure that the same version of software is loaded on the BPS2000's and 450's.

As for any "fighting" between devices, as long as there is only one cascade module set to base, there should not be any issues.

I would double check the cascade modules, perhaps pulling them out and re-seating them. In my experience, the cascade modules are the weak spot in the design. I have encountered some flaky things that were related to the cascade modules.