ACI Config Backup via Python

The configuration backup/rollback tool in ACI is a great feature that has saved my ass many times.

Any time I start making changes, I go do a one-time backup. If I get too far down a wrong path, I can easily rollback to that snapshot to set the fabric right again.

One thing that always bugged me though, was the inability to give that backup a customizable, user-friendly name.

I discovered this week that if we trigger that backup via the cobra SDK, we can assign any name we want. Here is the code, which is also available on my Github page.

#!/usr/bin/env python

# list of packages that should be imported for this code to work
import cobra.mit.access
import cobra.mit.request
import cobra.mit.session
import cobra.model.fabric
import cobra.model.pol
import cobra.model.config
import credentials
from cobra.internal.codec.xmlcodec import toXMLStr
import requests.packages.urllib3
requests.packages.urllib3.disable_warnings()

def take_backup ():
#Login to APIC
ls = cobra.mit.session.LoginSession('https://'+credentials.ACI_login["ipaddr"], credentials.ACI_login["username"], credentials.ACI_login["password"])
md = cobra.mit.access.MoDirectory(ls)
md.login()

polUni = cobra.model.pol.Uni('')
fabricInst = cobra.model.fabric.Inst(polUni)

backup = cobra.model.config.ExportP(fabricInst, name="backup_created_with_python", snapshot="true", adminSt="triggered")

c = cobra.mit.request.ConfigRequest()
c.addMo(fabricInst)
md.commit(c)

take_backup()
Advertisements

Update yer APICs (To Live and Die in ACI)

A scenario I ran across last week that I anticipate coming up again: new ACI fabric install and the version of code on the switches is newer than the code on the APICs. In this case the APICs won’t recognize the leaf switches, so I can’t add them to the fabric.

All of the equipment was fresh out of the box, everything was cabled correctly. I did the initial setup on the APICs, but when I went to start adding members to the fabric, there was nothing. I consoled into the leaf switches, a pair of 93180YC-EX, to see what version of code they had. They are running 12.1, which would equal something in the 2.1 code train.

The APICs were running 1.0 code, well before the 93180s were introduced as a product. So it made sense that it wouldn’t recognize them. So how do we get them to talk?

I thought maybe I could downgrade the switches to a lower version. I copied code and moved it into the bootflash directory and tried to run the setup-clean.sh script to get them to boot into that older version of code. That did not work and I didn’t want to start changing too much with the boot order for fear of bricking a switch.

The second option is to upgrade the APICs, but I can’t upgrade them via the normal means because my fabric isn’t built meaning that my APICs haven’t formed a cluster as of yet.

The process to upgrade the APICs in a standalone fashion is actually pretty straightforward.

  • Assuming you’ve downloaded the APIC code (2.0(2g) in my case), access the server via CIMC.
  • Login to the CIMC and launch KVM console.
  • Once in there, click on activate virtual media and map the CD/DVD to the ISO file you’ve downloaded.
  • Next reboot the server and press F6 during the bootup process to manually select boot location. Choose your mapped virtual media.
  • Follow the on-screen prompts to install the new OS.

In my case it took about 30-45 minutes to load the new OS. Once the new image is installed it will bring you to the initial fabric startup screen again.

One warning is that you will need Java to launch the KVM console. That always brings it own joys.

I imagine this scenario will present itself more often as new switches are introduced into the nexus 9K line.

There is a Cisco reference document here.