CM fails to retain device group configuration for Optimization Policies after upgrade to 5.3.1
Over 150+ WAAS in production. CM upgraded from 4.4.5c to 5.3.1. Then all devices upgraded to 5.3.1. Optimization Policies are defined in the group setting AllWAASGroup. After all the devices were upgraded, the CM fails to retain the device group setting for the Optimization Policies and reverts to "Select a device group".
Devices > device name > Configure > Acceleration > Optimization Policies = Select a device group
Even after selecting the AllWAASGroup, the CM will revert to 'Select a device group' after 1 polling cycle.
1) Anyone else experience this?
2) Will upgrading the CM to 5.3.5 fix this binding issue?
It has been along time, but I seem to remember having an issue with my Optimization policies when I went from 4.4.7 - 5.0.x My fix for it was to do a fresh install from CD to my CM and get the updated default Optimization policies which were considerably different from the policies that I had been upgrading with since 4.1.x. The most important difference was in the "Class-default" policy at the very bottom which does "TFO with DRE Adaptive and LZ" which was different from the default in 4.1 which I seem to recall being TFO Only. I only have 15 WAAS in production, so changing them to a new CM was not very painful. The Class-default change made a HUGE difference in WAN performance.
document any special configurations you have made, and do a "Restore default", in 4.x, I had 4 special configuration policies I had created, I removed all of them and only have 1 since upgrading to 5.x because 5.x didn't have the same issues.
You may also want to go to:
"Device Groups > AllWAASGroup > Device Group Home" and do a "Restore default optomization policies" and "Force group settings"
I'm upgrading to 5.3.5 during our weekend maintenance window and will see if that resolves the issue. However, I suspect you are correct about the policies - I will probably need to restore to defaults and then reapply the special configs - which for us, are a significant number and not a trivial task to undertake.
Update: After upgrading the CM from 5.3.1 to 5.3.5, the CM still fails to retain the device group setting for the Optimization Policies. It still reverts to 'Select a device group' after 1 polling cycle.
I'll open up a TAC case and see if they have something better to offer than restoring the default policies and manually adding all of our custom policies since that is a significant undertaking.
Final Update and resolution: TAC was able to review all the logs and find 7 optimization policies that 'failed' thereby causing the device group setting for the Optimization Policies to drop and revert to "Select a device group".
Of those 7 policies, some were custom and some were the default Cisco WAAS policies. I reviewed what was common in the 7 policies. Not all were 'custom' policies, yet still flagged as an issue. All 7 policies had a description with content that no longer fit the field parameters. Indeed, while many of our policies have descriptions, most still fit within these 'new' field parameters. It appears that the field length and allowable characters have changed again with the 5.x code. After updating just the description field for those 7 policies, followed by a force settings to devices in the AllWAASGroup, all devices now retain the device group settings for the optimization policies.
Topology & Design:
Two ACI fabrics
Stretching VLANs using OTV
Both fabrics are advertising BD subnets into same routing domain
Some BDs(or say VLANs) are stretched, but some are not.
Endpoints can move betwee...
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
Topology &Design:Traffic flow within same fabric:Endpoint moves to Fabric-2Bounce Entry Times OutTraffic Black-holedSummarySolutionAppendix:
In the Previous articles of ACI Automation, we are using Postman/Newman a...