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 Note: This topic was created from a
reply on the
SSA: VSB member change not sync config to replaced unit topic.
