Hey Aran,

yep ..these are the steps i took:

1) "copy running-config startup-config"
2) "copy startup-config tftp://mytftpserver/backup.config"
3) "copy tftp://mytftpserver/m9200-xxxxx.bin bootflash:m9200-xxxx.bin"
4) "copy tftp://mytftpserver/m9200-xxxx-kickstart-xxx.bin bootflash:m9200-xxx-kickstart-xx.bin
5) "dir bootflash:" ...verified everything looked good
6) "show version image bootflash:m9200-xxxx.bin and m9200-xxx-kickstart-xx.bin" - looks good, displayed correct version.
7) "install all system bootflash:m9200-xxx.bin kickstart bootflash:m9200-xxx-kickstart-xx.bin

so it did its thing ..rebooted the switch and came up ok. Then i ran "show install all status" ..says successful. I was like ..cool ..that was easy, but then when i ran "show vsan" ..it only displays vsan 4096.

Yikes! I know you hate to hear phrases like this, but "I have never seen that happen".

OK, dumb question time. Did you issue 'copy run start' prior to the code upgrade to ensure that the existing running config was saved to nvram? A reboot of the switch will dump whatever is running in memory i.e. the running config.

And you used the 'install all system bootflash:xxx.bin kickstart bootflash:xxx.bin' command?

Yikes again. Try creating a VSAN now, populating it with a few zones and activate the zoneset, then save the running config and then reboot the switch.

I wonder if it is not saving the config properly?

I would definitely call in EMC though to dig into it. That is not normal behavior at all. Scary to think if that had been a production switch. But like I said, I have not seen that on a Cisco switch before. Very odd.

yeah ..i re-created my VSANs again ..saved them and bounced the switch again. All is there ...weird and scary stuff.

It's must be the Jamaica mob that hacked your switch....
no really... this sure is scary stuff since in a week or 2 I have to do the very same thing at a large telecom company... in production !

Did you create a service request ? I'm very curious what the outcome is, because this is exactly the thing we don't want to see in prooduction !

Exactly what I was thinking !

Hello,

I'm trying to understand how the switch came with that code loaded on it. 3.2(2a) was never EMC GA and shouldn't have been on the switch. Was the switch purchased from EMC? If so, did you know if an EMC Service request was ever opened so I can look into this further?

Thank you.

sorry for the typo ..switch came with 3.2.2c pre-installed. I have opened a ticket (sev 3) but have not been contacted by support yet. I can provide "show techsupport" tomorrow. Do you see something wrong in the steps i took to upgrade the switch ?


Thanks

Hello,

There are various bugs with upgrades from 3.2(2c) but none should have caused the configuration of the VSANs to disappear. Did you see the VSAN configuration in the backed up running / startup config?

Is there a reason why you did the upgrades, instead of EMC field? EMC field has access to documents and knowledgebase articles that you as a customer wouldn't have access to. Change Control is also done for EMC upgrades which can catch a variety of upgrade issues.

Can you provide the EMC case number so I can look into it?

Thank you.

Just performed the 3.2(1a) to 3.2(3a) upgrade on a couple of 9124's and all went well and quickly !

apparently bootflash was corrupted on this 9222i, according to Cisco upgrade fixed it but at the same time any previous configuration changes were deleted. After the upgrade i was able to create VSANs, modify other configurations, saved running config to startup and bounced the switch ..everything is fine.

We did upgrade another 9222i and it had no problems whatsoever.

I just got 2 brand new 9222i's in. Now I have to convince our management that we really need to test tehse things before we're starting to use them.

Your scenario will be tested.