Feedback on sx500 stacking behavior

[danielj80]

I've recently purchased a a few SG500-28 and SG500-28p switches, and on the whole have been very pleased with them. I do, however, have a couple pieces of feedback about how the switches handle stack changes.

1) It seems that the 10 minute interval used in the rubric to pick a master is not fine-grained enough. For instance, I moved the power cords on both switches in a running two-unit stack today. I unplugged one switch (unit 2), re-routed the power cord, and plugged it back in. After waiting for the the switch to come up and stabilize, I did the same to the other switch (unit 1, initial master). After plugging unit 1 back in, the whole stack appeared to reboot, since both switches had very low uptime, and unit 1 wanted to be master. If I had waited more than 10 minutes between switches, this would not have happened, as unit 2 would have retained its master role. If would be great if the time increment used to help pick a master was more fine grained, or better yet, if the stack didn't need to reboot to change the master back.

2) It would be great if traffic continued to be forwarded by the backup stack member during the transition to it taking over being master. I realize it's only for a few seconds, but I would love to see traffic (at least layer 2) continued to be passed.

If solutions to my concerns could find their way into a future release, I would be thrilled. If I'm wrong about one or more of my statements, I'd love to be corrected.

Thanks!

[Tom Watts]

Hi Dani, I'm trying to reproduce what you've said using a couple SF-500-24P for "1".

To recap what I am doing-

• Have 1 switch select itself as the master, the second switch select itself as the slave
• Remove the power source from the slave switch
• Reconnect the power source to the slave switch

During the slave boot up process, as expected this is the output and the stack LED remains in position #2.

------------------------------------

-- Unit Number 2 --

------------------------------------

19-Jul-2012 17:57:23 %Entity-I-SEND-ENT-CONF-CHANGE-TRAP: entity configuration c

hange trap.

19-Jul-2012 17:57:38 %INIT-I-InitCompleted: Initialization task is completed

-----------------------------------

-- Unit Number 2  Master Enabled --

-----------------------------------

19-Jul-2012 17:57:46 %MLDP-I-SLAVE: Switching to the Slave Mode.

19-Jul-2012 17:57:46 %MLDP-I-CONNECT: Connection to Unit 1 is established.

• Wait for complete boot up (in this case I waited 3 minutes for arguments sake)
• Disconnect the power source from the master switch
• Reconnect the power source from the master switch

After removing power from the master then putting power back on, here is the out-

-----------------------------------

-- Unit Number 1  Master Enabled --

-----------------------------------

Tapi Version: v1.9.5

Core Version: v1.9.5

19-Jul-2012 17:57:46 %MLDP-I-MASTER: Switching to the Master Mode.

19-Jul-2012 17:57:46 %Stack-I-STCK-CFG-CHNG: Configuration changed: chain

-----------------------------------

-- Unit Number 1  Master Enabled --

-----------------------------------

Tapi Version: v1.9.5

Core Version: v1.9.5

19-Jul-2012 17:57:46 %MLDP-I-MASTER: Switching to the Master Mode.

19-Jul-2012 17:57:46 %Stack-I-STCK-CFG-CHNG: Configuration changed: chain

Additionally, when the original master established, the slave switch, all lights flash on during the synch up (which is your point #2, it will drop traffic for a brief moment) and my original master is the master.

It appears to me as if everything just went back to normal when the original master came back online without any confusions who is who.

Can you correct my process if I deviated from your information?

-Tom
Please mark answered for helpful posts

[danielj80]

Tom,

It does appear there is a difference. For me, the order of operations:

• Reboot backup.
• Wait for backup to boot.
• Wait ~1 minute after backup booted to stabilize
• Shutdown master.
  • Backup takes over with small pause in traffic forwarding
• Wait ~1 minute
• Start master
  • A few seconds before master fully stabilizes, the backup switch reboots. My conclusion the master hasn't fully stabilized is drawn from the link lights cycling a couple times on the master while the backup is rebooting.

The Admin guide describes exactly what I'm seeing, so my feedback is more of a feature request than a bug report, as it is expected behaivoir in a two unit stack (master/backup, no slaves):

p75

Master/Backup Switchover

When a master fails or when you configure a force master on the backup unit, a

switchover occurs.

The backup unit becomes the master, and all of its processes and protocol stacks

are initialized to take responsibility for the entire stack. As a result, there is

temporarily no traffic forwarding in this unit, but slave units remain active.

p76

Reconnecting the Original Master Unit After Failover

After failover, if the original master is connected again, the master selection

process is performed. If the original master (unit 1) is reselected to be the master,

the current master (unit 2, which was the original backup unit) is rebooted and

becomes the backup once again.