Bandwidth reset to default after Migration from 7.22 to 8.5

After we have migrate from 7.22 to 8.5, we found that there are some different in the config between 7.22 & 8.5. The bandwidth settings of the monitored device will use default value instead of we tailor-made value we set in 7.22.

Is that we have missed out some config files from 7.22 while we upgrade to 8.5?

Thanks!

Find more posts tagged with

Accepted answers

tdanner

I'm sorry about the loss of your custom settings. We have realized that this was the wrong way to implement this new feature. Starting with 8.5.1, upgrades from pre-8.5 will treat all existing interface bandwidth values as custom and not overwrite them. It's too late to save the custom settings for users who upgraded to 8.5.0 (they have already been overwritten), but at least people who go directly from 8.1 and earlier to 8.5.1 won't have to suffer this.

All comments

vhcato

A new feature was added to 8.5 which will automatically update interface speeds upon detecting a change. They also added a checkbox allowing you to tell it to not dynamically change the speeds of interfaces where you have administratively assigned the speeds. During the upgrade process, it reverts to the discovered BW for all interfaces and discards any statically assigned speeds, as there was previously no mechanism to specify that the desire is to have them remain static. I don't know if there's really any way around that, as it somehow has to implement the feature during the upgrade, but doesn't have any way to know which ones should remain as-is, and which ones should take advantage of the new dynamic feature.

tdanner

vhcato

I'm sorry about the loss of your custom settings. We have realized that this was the wrong way to implement this new feature. Starting with 8.5.1, upgrades from pre-8.5 will treat all existing interface bandwidth values as custom and not overwrite them. It's too late to save the custom settings for users who upgraded to 8.5.0 (they have already been overwritten), but at least people who go directly from 8.1 and earlier to 8.5.1 won't have to suffer this.

Tim, is this really the best approach? I can't speak for everyone, but in our case, less than 1% of the interfaces we monitor actually have speeds administratively altered from their dynamically derived speeds (VPN links with differing TX vs RX speeds). For all the others, we would want to take advantage of the dynamically derived speeds. Based on some custom properties we have configured, we can easily formulate a SQL query to change the other 99%+ interfaces to use the dynamic values, but some might not have the SQL knowledge to do so, so they might be left to think they need to go back and uncheck the checkbox on all the interfaces where they want to take advantage of the dynamic values.

Again, not intending to speak for anyone, but I imagine the majority of the monitored interfaces out there are better suited to use the dynamically derived speeds (without the need to go back and turn that feature on for each interface). It might be easier to be aware that this is an upgrade "issue", and go back and change the speeds on the ones you wish to remain static (at least for some).

That being said, I understand you want the upgrade process to be as least intrusive to people's current configurations as possible.

tdanner

You are right - we can do better. I've changed 8.5.1 to use set the Custom Bandwidth option if either the InBandwidth or OutBandwidth differs from the InterfaceSpeed, otherwise the Custom Bandwidth will be off and In/OutBandwidth will track what SNMP reports.

I think this will cover the case you brought up with asymmetric VPN links and most other uses of Custom Bandwidth while allowing users to benefit from the automatic bandwidth update in the general case.