Automation Win: Document Cisco ACI Configuration

This blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.

A while ago I complained how the GUI- or API-based orchestration (or intent-based) systems make it hard to figure out what exactly has been configured because they can’t give you a single text configuration file that you could track with version-control software.

Dirk Feldhaus found the situation so ridiculous that he decided to create an Ansible playbook that collects and dumps tenant parameters configured on a Cisco ACI tenant as a homework assignment in the Building Network Automation Solutions online course. As he explained the problem:

It can be difficult in the APIC GUI to get a quick overview for certain configuration parameters because these values are hidden in different subtrees of the GUI. For example, if you want to check if all Bridge Domains have a certain parameter set this can be really complicated. A list containing only those parameters you're interested in would be a great help.

Cisco ACI is not the only system where you’d face this challenge. VMware vCenter, VMware NSX, OpenStack, Amazon Web Services... pretty much any system that has REST API as the only configuration mechanism has the same problem.

Interestingly, he decided to dump the collected information in an Excel spreadsheet instead of a text file. Here’s his reasoning:

Most people are familiar with Excel and sorting and filtering mechanisms. In that way, they can easily get the information they're looking for from the report.

Like most other attendees in the network automation course he published his solution on GitHub, so you can easily adopt it to your needs and (for example), create a text-, HTML- or PDF report instead of an Excel spreadsheet.

I use wkhtmltopdf to create PDF documents from HTML source.

Hope you’ll find his solution useful and/or inspiring. Happy automating!

8 comments:

  1. The solution to the problem is known as infrastructure as code in combination with version control and remote state. I thought you were writing a blog post about that. So what's your progress?
    Replies
    1. I have been involved in system automation for 13+ years (Data Models, Templates, etc) and I am a little bit bored by all those discoveries & achievements in this area we see in last few years.

      When I started doing automation in 2005 the only questions we were asked: does it make any economic sense? If yes, then automate. No special philosophy involved, just pure economy.

      I want to say: if the automation is really needed people will follow this path.
    2. @Gogus: I could take the same approach. I could say "we had automation in 1993, so it's nothing new, let's move on". Instead I decided to try to persuade networking engineers stuck in the CLI era to move forward. Everyone needs a few windmills in his life, and I seem pretty good at finding them.

      Interestingly, as someone wrote recently, automation is like losing weight (or a visit to a dentist). It's often not a rational decision - you try to postpone it as long as possible, but once you get started, it's hard to figure out how you managed to live without it for so long.

      As for "if the automation is really needed people will follow this path." - totally agree with that, but sometimes the need must be huge to force everyone to drop their established habits.

      @Anonymous: would love to see what you wrote on this topic. Merging a few buzzwords into a sentence is easy.
    3. @Ivan, I am your content subscriber as you know. For me automation is a boring topic. We call this part of a job pure development. Nothing fancy.
      What I am looking for are new ideas, smart observation, etc. Something what very experience people could share with us and make me thinking. I recall some Greg Ferro podcasts series called 'Future of the networking'....

  2. But APIC does give you an output in text if you want.

    apic-1x# show running-config leaf 101
    # Command: show running-config leaf 101
    # Time: Wed Jun 6 10:10:29 2018
    leaf 101
    template hsrp group-policy default tenant common
    exit
    vrf context tenant Shared vrf Shared l3out shared
    router-id 10.0.1.101
    ip route 0.0.0.0/0 10.0.0.17
    route-map shared_in
    scope global
    exit
    route-map shared_out
    scope global
    exit
    route-map shared_shared
    scope global
    exit
    exit
    vrf context tenant Shared-infrastructure vrf Shared-infrastructure l3out shared-infrastructure
    router-id 10.0.1.101
    ip route 0.0.0.0/0 10.0.0.33
    route-map shared-infrastructure_in
    scope global
    exit
    route-map shared-infrastructure_out
    scope global
    exit
    route-map shared-infrastructure_shared
    scope global
    exit
    exit
    vrf context tenant common vrf shared l3out shared
    router-id 10.0.1.101
    ip route 0.0.0.0/0 10.0.0.1
    route-map shared_in
    scope global
    exit
    route-map shared_out
    scope global
    match bridge-domain NID-39
    exit
    exit
    route-map shared_shared
    scope global
    exit
    exit
    interface vlan 114
    vrf member tenant common vrf shared
    ip address 10.0.0.3/28
    ip address 10.0.0.2/28 secondary
    ip router ospf default area 0.0.0.1
    exit
    interface vlan 116
    vrf member tenant Shared vrf Shared
    ip address 10.0.0.19/28
    ip address 10.0.0.18/28 secondary
    exit
    interface vlan 117
    vrf member tenant Shared-infrastructure vrf Shared-infrastructure
    ip address 10.0.0.35/28
    ip address 10.0.0.34/28 secondary
    exit
    interface ethernet 1/4
    # channel-group leaf-sw-1-2-coreR1-2 vpc
    exit
    interface ethernet 1/5
    # policy-group standard-10g-access
    exit
    interface ethernet 1/6
    # policy-group standard-10g-access
    switchport access vlan 501 tenant Legacy application VLANS epg VLAN32
    exit
    interface ethernet 1/7
    # policy-group standard-1g-access
    switchport trunk allowed vlan 2131 tenant Legacy application VLANS epg VLAN2131
    switchport trunk allowed vlan 2150 tenant Legacy application VLANS epg VLAN2150
    exit
    interface ethernet 1/8
    # policy-group standard-10g-access
    switchport access vlan 501 tenant Legacy application VLANS epg VLAN32
    exit
    interface ethernet 1/9
    # policy-group standard-10g-access
    switchport trunk allowed vlan 1049 tenant DIT application DIT epg NID-692
    switchport trunk allowed vlan 118 tenant Shared application NID-14 epg NID-14
    switchport trunk allowed vlan 119 tenant Shared application NID-15 epg NID-15
    switchport trunk allowed vlan 120 tenant Shared application NID-18 epg NID-18
    Replies
    1. I had a discussion with someone else on this same topic and told him the same thing. In his opinion the configuration file you get from APIC is too large to be useful (in reasonably large deployment), and didn't give him the per-tenant information he wanted to see.

      But I agree - if all you need is version control of APIC configuration, you can get it done relatively easily (contrary to most other examples I mentioned in that same list).
  3. Hello, I'm also long term reader of ipspace. What I'd Like to see ist more about other options when you talk about new/old topics, i.e. there are other vendors on this planet, not only those starting with "C". Well I can remember "A"s, too. Take in noname/consumer hardware, aswell. Why can't you use vendor D, N, H for feature X, although those vendors promote it...
    Replies
    1. Hi Michael!

      Do explore my blog posts a bit more - you might notice that I mention vendor C only when they have something unique (like multi-site EVPN enabled by their ASICs). Also, I'm sick-and-tired of dealing with vendor marketing. It's much better to focus on fundamentals and understanding technology - that enables you to figure out why some stuff won't work on your own (but yes, it does require some extra work).

      If you want to know more about numerous vendors, you could also watch my webinars, for example this one https://my.ipspace.net/bin/list?id=DCFabric. Or this one if you're interested in whitebox switching https://my.ipspace.net/bin/list?id=OpenNetworking. There are even some free webinars dealing with those topics: http://www.ipspace.net/Subscription/Free

      Finally, it's not my fault that Cisco is the only vendor that has a data center fabric controller, or that many engineers find dealing with said controller relevant ;)

      Ivan
Add comment
Sidebar