When upgrading SG300 from 1.1.8 to 1.2.0, configuration file does not take properly

[telecastle]

Originally, my  client had SG300-28 (purchased by mistake) instead of SG300-28p. I had  configured SG300-28 from CLI and CCA (CCA is a requirement for the Small  Business Pro department to support the voice solution). I then tftp'ed  the config to my laptop. When I replaced SG300-28 with SG300-28p, I  upgraded the firmware that came with it (pre 1.1.8) to firmware 1.2.0.  Then, I tftp'ed the config from my laptop to the SG300-28p startup  configuration and reloaded the switch. After the reload, I was not able  to regain IP connectivity to the switch, and I had to use the console  cable to get into the switch to see what happened. What I saw was the IP  address originally assigned to interface VLAN 101 in the SG300-28 config being assigned to interface VLAN1 in the newly installed SG300-28p. Therefore, I had to remove that IP from interface VLAN1 and put it under interface VLAN101 while being connected to the switch via a console cable.

A  few days later, I realized that the ip default-gateway command  that I had configured in SG300-28 and had saved in the config on my  laptop, did not take when I tftp'ed the config to SG300-28p. So, even  though I was able to administer the switch from a laptop connected to  one of the switche's ports, I could not administer it via a VPN  connection. I have confirmed that the cofig file on my laptop has the correct configuration, and this must mean that the configuration created  in SG300-28 running firmware 1.1.8 does not play nicely with SG300-28p  running firmware 1.2.0. I hope these are just some growing pains because a firmware upgrade messing with the existing good configuration is a disaster scenario. I think this deserves being brought up here for the Small Business Pro folks to investigate this issue and correct it in the next firmware upgrade.

[rmanthey]

Hello telecastel,

yea the SG and SF model switches don't run a true IOS. Most of the config file will be XML format and when a firmware upgrade comes out it changes the structure of the code at times so when you go between firmware's that are too far off or even different models, it changes the line where a the code will look for that string. If you were to upgrade a switch with a configuration on it from version 1 to 2 then you should have a problem, but if you go from version 1 to 5 and skip some versions we recommend stepping up the firmware or resetting the switch to factory defaults and rebuilding the configuration.

Thanks for contacting Small Business Support.

Cisco Small Business Support Center

Randy Manthey

CCNA, CCNA - Security

[telecastle]

So, in this case, the models only differ in that SG300-28 has no POE, and SG300-28p has POE. Other than that, it's exactly the same switch with the same number of ports and the same port speed. The original configuration file was built in firmware 1.1.8, and when it was applied to firmware 1.2.0, the switch confused VLAN100 with VLAN1 and also failed to apply the ip default-gateway command. I believe firmware 1.2.0 was the next iteration from 1.8.0, so one can't get any closer between firmware revisions.

If you have a working system in production, a firmware upgrade should not affect the configuration ingegrity after the switch is reloaded. Otherwise, a production environment will be adversely affected. Rebuilding your configuration from scratch for the new firmware is not an option that any sane person would consider for the production environment. What it means is that people should refrain from upgrading firmware unless the new firmware has a feature that they absolutely must have.  In my opinion, if this is the approach that Cisco Small Business Pro takes to firmware upgrades, I would never recommend such equipment to any of my clients. It's a nightmare for both the client and the consultant.

I hope you guys are working on the resolution. I can understand that going from one (old) major release to another (new) major release may cause inconsistencies in the configuration file, but as long as one keeps upgrading to current firmware releases, such inconsistencies must never be allowed to occur. The new firmware release must be thoroughly tested for such inconsistencies, and the bugs must be worked out before a new firmware release is published.

[nimusell]

Hello Telecastle,

Thank you for sharing your issues with the Support Community. My name is Nico Muselle from Cisco Sofia SBSC.

The only thing I could think of that would cause this kind of behaviour is that your switches were not both configured the same when uploading the config. Meaning that most probably, the config you had on the SG300-28 was a layer 3 configuration, while the upgraded SG300-28P was still in layer 2, meaning you did not change the system mode before you uploaded the configuration. Could this be the case ?

I've been looking for release notes for the 1.1.2.0 firmware version but unfortunately this is not available on the Cisco website at this moment. I'll see if I can get a hold of it to verify if any incompatibility issues are mentioned.

Edit : the Sx300 FW 1.1.2.0 release notes can be found here, but no such problems are mentioned when upgrading from v 1.1.1.8 to 1.1.2.0.

Hope this helps,

Best regards,

Nico Muselle

Sr. Network Engineer - CCNA - CCNA Security

[rmanthey]

Hello Telecastle,

The only way I was able to reproduce the issue you were experiencing is if I didn't copy the running config to the startup config before upgrading the firmware. I tried several times in both directions going from 1.1.1.8 to 1.1.2.0 and back. Every time my configurations came over in the new firmware.

Can you verify the startup config is correct before upgrading the firmware, then verify the same startup config in the new version?

Cisco Small Business Support Center

Randy Manthey

CCNA, CCNA - Security