Completed first round of upgrade from 4.1.3b to 4.1.5b
This past weekend we upgraded some of our boxes from 4.1.3b to 4.1.5b. We upgraded our Active and Standby CMs, our data center 7341s and two 674s at one of our remote sites.We plan to let this run for a few weeks then we'll upgrade the rest of our remote WAEs.
So far it seems to have gone well. Our configurations were maintained and our scheduled reports continued to work too.
One issue we have come across is in regards to the 'strong password' policy. 4.1.5b requires the use of strong passwords. You can find it mentioned in the Release notes. However, the release notes state that this feature is disabled by default. We have come to find out that isn't true if you have SSL AO enabled. Since SSL AO is enabled by default, if you upgrade to 4.1.5b then the strong password policy is also enabled. This becomes a problem when a remote WAE goes offline then comes back online and tries to re-register with the CM. The CM will refuse the registration of the remote WAE because of the default username/password that is on each WAE. We don't currently use the SSL AO, so we were able to fix our problem by disabling the SSL AO feature on all of our WAEs. Another option may have been to change the default username/password to adhere to the newer password policy requirements.
Re: Completed first round of upgrade from 4.1.3b to 4.1.5b
Good question. For us, there were four software defects that were impacting our service. The most notable was a bug with MAPI AO and TFO overload. Our remote sites are deployed with two 674s installed inline. When the first WAE (closest to the users) would exceed its TCP limit, it spills over to the other WAE at the same site. Unfortunately, we experienced a problem with Outlook clients. When their Outlook TCP sessions spilled over to the other WAE their Outlook client would hang. The users had to shut down their client and restart the session.
The list of bugs we were trying to get resolved by going to 4.1.3b were:
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...