Baystack 5510 stacking

[webtensive]

Has anyone seen any issues where 5510 stacks fail after power resets? We have seen a couple instances where a stack is functioning fine, then after a power hit the switches seem to fight over base. I'm running 3.0.1 code, haven't tried 4.0.x code yet.

 

[Jynxx]

Yes, but we have 2 stacks of 4 that are running a 4-port MLT between them. After a reboot, with the MLT hooked together, they would freak out and sometimes not detect some switches in the stack at all.

Bridging loops can also cause issues likek this. Make sure spanning tree fast learning is on for all interfaces, or, if these are not yet in production, just un-hook all patch cables and try it that way.

I assume that your "base" unit is set to base and the slave unit is not. I also assume, for the cascades, that down on switch 1 is going to up on switch 2 and that up on switch 1 is going to down on switch 2.

What does the "display hardware units" show?

=============================================

I would definately upgrade to 4.0 code...especially if you want to be able to use G4 and G5 Macs with gig nics and have them work properly when transmitting to devices that are NOT gig. Major, major buffering issues... Has to due with the fact that Macs running at gig use a TCP send window size of 64k and the fact that the switches only have 1MB of buffer space per 4 ports (I believe).

Upgrade to 4.0...both the image and diagnostic file...then reset to factory defaults. After that is done, go in to the command line and type:

>ena
#config t
(config)#qos agent buffer maximum
(config)#qos agent queue-set 4
(config)#end
#logout

Then reboot the stack.

This sets the queues up to be most like a Baystack 380 which does not have the buffer allocation issue.

This will get around the gig issues with Macs.

Another issue that was resolved, is an incorrect timer value for 100meg devices. If you connect a Cisco router to them, you will notice frequent interface up/downs in the logs...but they transition so fast you can't even see the link light go out and the switch does not see link failures. When they typed in the clocking value for 100meg, they used the same value for that at gig. Causes interfaces to bounce...but generally so fast that most devices will not notice. 800Mhz iMacs (the white pod ones with the monitor arm) notice though... Only certain chip makes are affected.

Don't even ask how I know all of this...the story is MUCH too long.

So, in other words...upgrade.

 

[123456789456321]

Here is the solution of your problem:

- Make sure on the back of 5510, dip switch is set for BASE.[Only for one unit in a stack]

- When ever the first unit fails, the 2nd unit will autimatically take the charge and will act like BAse with amber led in the front pannel, IF @nd unit is accessible by others units in the stack.

Original unit act as normal during that time and will become BAse after the reboot.

Network Consultant
MCP/CCNA/CCNP

 

[mhurley131]

Sorry...this is a little off topic.

Jynx, I have a question about the link drop problem you described. I have seen instances with users plugged into a baystack 470 where this has happend also. You don't see the link drop, but we have link trapping enabled, and there are tons of trap messages sent about a port going up and down. We moved a few users to a baystack 450 to see if the problem was perhaps noise on the line, but the traps were not being reported by the 450.

Do you know if the problem you reported about the 5510 is also a problem with the 470??