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!
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.
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.
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'....
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
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).
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