SSA: VSB member change not sync config to replaced unit

[Volker_Kull]

SSA: VSB member change not sync config to replaced unit Using the kb:14688 the VSB replace procedure does not copy the existing configuration of the replaced VSB member. VSB is up and working. Using the stored config at local flash ends with error because of wrong chassis ID. Looking at B/C-Series we had no problems changing a stack member and have back the whole configuration of the replaced units. Having a much more featured SSA/S-series I expect that this function is implemented and working.

[dfroe]

Hi Chris, thanks for your explanation. I think your first suggestion might be an acceptable workaround. It still assumes that our customer always has (to have) a backup of the latest configuration, preferable saved on all slots of a bond. Then a "configure append" should be everything which is required to apply the old configuration. I did not know whether leaving the old serial number in the configure append file might break something. However for me this feels a bit like still being caught in a beta-test phase. I would expect each unit of a VSB to always carry a complete working copy of the whole system/bond. Then the system should be able to detect a newly attached device and copy/apply the existing configuration to that unit. Many of our customers already have stacked secure switches and they know how easy it is to replace a defective unit within a stack. There you do not have to worry about manually copying any configurations and especially you do not have to always keep a separate backup file to be prepared in case of a hardware failure. Then we started to deploy core and datacenter switches (S and 7k series) together with the promising vsb feature, and now after the first hardware failures they have to see how difficult and fault-prone the procedure of replacing a defective unit within such a vsb is. So please forward the thoughts we collected in this topic to engineering; hoping the VSB feature behaves similiar to a stack in the future. However thanks again for your explanations and suggestions; though we would be happy to find such vital information in the knowledge base and/or configuration guide. David

[Tamera_Rousseau]

Hi David, because you are suggesting this in a future release, I am going to post this as an idea for consideration. Thank you! Please reference the new topic here: VSB feature behaves similar to a stackable

[Anonymous]

David, At this time doing some kind of configure command is required. There is however no need to edit or change the config file prior to configuring it on the new chassis. There are a couple different options that can be used. I'll try to briefly outline them. (not really good at brief) One option is the following: On the replacement unit: Add any require license configure bonding chassis and system id configure bonding ports enable bonding At this point, connect the replacement unit to the existing VSB switch. Bonding should come up and be functional, but no configuration will be present on the replacement unit(other than the bonding lines you added). Assuming you have a copy of the config on the still configured VSB switch(switch 1), use the configure command with the append option to reload the entire config (does not require a reboot) 'configure slot1/filename append' While some lines in the config will error out because they are already in the config this should allow the entire config to get pushed to the replacement unit (switch 2) and begin functioning normally without a reboot. If you don't have a copy of the config on the box, you will need to either TFTP it onto the still configured unit(switch 1), or you can utilize a USB stick(with an adapter) in the micro/mini USB port on the front of the unit. ---------------- The second option requires a little less configuration work but you have to get the configuration file on the replacement unit. As you had stated, this can be done either via TFTP or via the micro/mini usb port on the front of the switch. Once the configuration is either on the box, or is seen on the USB stick when attached (will show up when doing a 'dir' command), you can run one of the following commands. 'configure usb2/filename chassis-id 2' or 'configure slot2/filename chassis-id 2' (depends on where the file is) The chassis-id option tells the replacement unit which part of the configuration it should use. Once the unit reboots with the correct config, it can be connected to the other VSB switch and bond normally. Engineering is considering providing a method to indicate you want to override the replacement device's configuration (it has a non default config in order to start the bond.) Or possibly automate the configuration when a completely unconfigured replacement is connected to bond ports of a chassis that is missing its partner. I hope this information is helpful. Chris

[dfroe]

Hi Chris, is this additional step really necessary (replacing the serial number within the config file, uploading the config, and finally issuing a configure on the new chassis)? Then I see two (major) disadvantages of a SSA VSB -- compared to what we (and our customers) are used from the secure stack devices. 1) I always need to have a saved backup of the latest switch config. Because when a unit if the VSB fails, the config for those ports will be lost and there seems to be no way to recover the full configuration of all units afterwards. 2) I have to copy the backup config on my pc, open it with a notepad, replace the serial number within the config, save it, and transfer it via tftp to the VSB. This actually is not very comfortable. Already the tftp transfer might be hard if you do not have a dedicated management port pre-configured on your VSB. Within a stack/vsb a hardware replacement should be possible without any manual config modifications (expect setting the vsb ports of course). We expected the VSB procedures to be similiar compared to a secure stack switch. There you just have to unplug the defective unit, attach the new one, and there you go. That's pretty neat. I would expect a hardware replacement procedure for SSA/VSB datacenter devices which is (at least) as comfortable and fast as with secure stack access switches. Do you have some thoughts about this? Is it really that complicated to replace a unit within a VSB? kind regards David