Prior to Cisco I had a gig as a Systems Engineer at a
Gold partner and one of the frequent tasks were software upgrades. Every now
and then I would ask TAC for SW recommendation. Now, as a CSE myself, I
figured I can't recommend customers any software
version because there is not “one fits all” release available (even if I really want to help). I have a lot of
tickets (most of them are configuration assistance though) with different
software releases and I am not aware of all the issues (defects) present in a
particular SW release. If a software release is published on CCO and not
deferred, Cisco supports this release. As a side note, Cisco AS has
what is called “Bug scrub”, where they can provide an overview of known defects
pertained to a particular setup.
How
to understand the SW release naming:
There
are two main images for ACI fabric:
1.
There is an ACI image for an APIC controller with the name aci-apic-dk9.3.2.1m.iso where 3.2.1m is SW version;
2.
There is a switch image for leaves and spines with the name aci-n9000-dk9.13.2.1m.bin where 13.2.1m is SW version;
Let’s
take a look at the following example:
SW release number: 3.2.1m
3.2 – a number of a major release
1m - a number of a maintenance release
Maintenance releases don’t contain major code changes and new features,
the main objective of these is defect fixing.
Long
live and short lived release:
the difference between those is TAC support duration:
Long
Lived releases: up to 18 months
Short
Lived releases: ~6 months
Long Lived
releases are recommended for setups that won’t be upgraded frequently
Currently
available long lived releases:
2.1(x)
2.2(x)
3.2(x)
All
official information about recommended versions can be found on CCO in Release
Notes:
Recommended Cisco APIC and Cisco Nexus 9000 Series ACI-Mode Switches
Releases
A
couple of tips before upgrading your ACI fabric:
- Always check software upgrade guide and don't go for big leaps between the SW releases; https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/2-x/managing_ACI_fabric_upgrades_and_downgrades/b_Managing_ACI_Fabric_Upgrades_and_Downgrades/b_Managing_ACI_Fabric_Upgrades_and_Downgrades_chapter_01.html
- Always check recommended CIMC version of APIC controller for your target SW release;
- Always make a backup or snapshot of the APIC;
- Always check the MD5 hash for uploaded SW release and compare it with that on CCO:
apic1# cd /firmware/fwrepos/fwrepo
a8661788d13a57f046567c6c5b8895ab
aci-apic-dk9.3.2.1l.bin
- Make a screenshot of faults, present in your fabric or save "moquery -c faultInst > /data/techsupport/faults_before_an_upgrade.txt" output to a file. Then you can compare a status of your fabric with its original state (do the same for system health);
- After the APIC upgrade wait until the cluster is fully fit and compare it to #4;
- Don't upgrade leaves in VPC pairs simultaneously (as of 3.x they won’t upgrade together anyway!), however, as a best practice, don't put them in the same maintenance group.
Here
are a few basic commands to verify ACI fabric after an upgrade:
APIC:
show controller
acidiag avread
acidiag rvread
acidiag fnvread
moquery -c faultInst
show cores
show firmware upgrade status
show firmware upgrade status detail
show health history
Leaf/Spine:
show
version
show
module
acidiag
fnvread
show
vpc
show
port-channel summary
show
vrf
show
ip route vrf VRF_NAME
iping
-V VRF_NAME x.x.x.x where
x.x.x.x is ip of a target endpoint
Comments
Post a Comment