Networks are evolving from hundreds or thousands of individual devices to the Software-Defined Network paradigm of a single fabric under a central controller. The GUI on top of an SDN controller isn't sufficient and we will still need automation. This presentation describes how Ansible can add value to configuration management of a Cisco Application Centric Infrastructure (ACI) infrastructure. It demonstrates how Ansible modules can use the northbound REST API interface of the Application Policy Infrastructure Controller (APIC).

1. Copyright © 2015 World Wide Technology, Inc. All rights reserved.
Ansible Durham Meetup
Using Ansible for Cisco ACI deployment
17 June 2015
Joel W. King
Technical Solutions Architect
Enterprise Networking Solutions
Engineering and Innovations

2. whoami
• Software Defined Network Discipline Lead at World Wide Technology, Inc.
• Past Experience
• NetApp – Technical Solutions Architect, Digital Video Surveillance – Big Data – E-Series
• Cisco – Technical Leader - Enterprise Systems Engineering (ESE) – Cisco Validated Designs (CVDs)
• Network Architect – AMP Incorporated – LAN / WAN design for 150 location global network
• Flash cutover of AMP’s network from OSPF to EIGRP using Perl and Telnet ~ 1996
• CCIE No. 1846 (retired)
• Participated on Networking Panel at AnsibleFest NYC 2015
joel.king@wwt.com
@joel_w_king
www.slideshare.net/joelwking
github.com/joelwking/ansible-aci

3. Agenda
• Why Ansible?
• How Ansible interfaces with Cisco Nexus Switches
• Nexus 9000 Series NX-OS Programmability (NX-API)
• Application Centric Infrastructure (ACI mode)
• Why we need automation for Software-Defined Networking (SDN)
• Ansible Modules for ACI
• Demo- Find the MAC address
• Demo- Apply ACI policy, run Docker application
• ACI workflow using Ansible, developing configuration libraries
• Summary

4. How I got started with Ansible
• Cisco Nexus switches have a variety of network programmability features.
• We had use cases with everything but Orchestration and NX-API.
• I thought installing an agent might be a pain point!
Power
On
Auto
Provisio
ning
(POAP)
Nexus 9K
NX-API
RPC / REST API
Python
Interpreter
Bash shell
Introduction
to Python
Programming
on Nexus
Switches
Nexus Data Broker
w/ REST API
NXOS ACI
Orchestration APIC
REST API
OpenFlow
Security-Defined
Routing

5. … after a little research
• Downloaded The Benefits of Agentless Architecture
• Installed Ansible on Ubuntu in Virtual Box
git clone git://github.com/ansible/ansible.git --recursive
• Found in the FAQs: ansible_connection=local
• Enabled NX-API
NEX-9396-A-TRNG-CLASS(config)# feature nxapi
NEX-9396-A-TRNG-CLASS(config)# end
NEX-9396-A-TRNG-CLASS# copy run start
[###########################] 100%
Copy complete.
• Wrote an Ansible module for NX-API !
NX-API Developer Sandbox

6. Cisco Application-Centric Infrastructure (ACI)
• A data center fabric with three components:
• Nexus 9000 Series Switches and the Cisco Application Virtual Switch (AVS)
• SDN architecture based on a policy framework for configuration, management, security
• Cisco Application Policy Infrastructure Controllers (APIC)
• Nexus switches in the fabric are plug-n-play.
• All functions of the controller
are exposed via REST APIs.
• The Web GUI designed for
initial configuration, a
tool for automation. Cisco APIC Python SDK
(“cobra”)
CLI admin@apic1:aci>

7. Cisco Nexus Data Center Switching
• If you are looking to Cisco for a Data Center switch, it will be a Nexus 9000.
• Nexus 9000 runs in either of two modes:
• NX-OS
• Application Centric Infrastructure – ACI
• Networks need Automation & Programmability.
• NX-API enables a northbound REST interface on individual NX-OS switches
• Nexus 3000 NX-API supported NX-OS 6.0(2)U4(1).
• NX-OS release 7.x enables NX-API on Cisco Nexus 5000 and 6000
• APIC is the Software Defined Networking controller for ACI
• Ansible | Tower can be your automation engine.

8. Ansible and Nexus Switches
• Nexus 9K switches run either ACI
mode or NX-OS mode.
• Enhancements to NX-OS
including feature nx-api in
Nexus 3K, 7K, 5K, etc.
• NX-API provide HTTP based APIs
for configuration management –
XML or JSON
• Application Policy Infrastructure
Controller – APIC is a CentOS
central controller managing
Nexus 9K in ACI mode.
• Ansible can manage the APIC
either ‘agentless’ or local
modules via REST API
SSH – TCP/22
Users, API
NTP – UDP / 123
HTTP(s) TCP/80:443
HTTP(s) TCP/80:443
SSH – TCP/22
GitHub
HTTPS TCP/443
LDAP – TCP / 389
ESX
Server
Windows
Systems
Linux
DockerAmazon
Web Services
Agentless
Ansible / Tower
REST API
connection: local
feature nx-api
Nexus 3000 | 9000
CentOS
Nexus 9000
github.com/joelwking/ansible-aci

9. Why do I need automation with ACI?
• Using the ACI GUI is time consuming and prone to human error.
• WWT Integration Technology Center
(ITC) is the hub of our
global deployments and
supply chain programs.
• Customers use the ITC to
stage their data center
infrastructure prior to
deployment.

10. Ansible Modules

11. Ansible Core Modules
• APIC is a Linux host.
• $ ./bin/ansible -m setup APIC --ask-pass
• /etc/ansible/hosts
• Using APIC cli interface in Ansible
"ansible_distribution": "CentOS",
"ansible_distribution_major_version": "6",
"ansible_distribution_release": "Final",
"ansible_distribution_version": "6.3",
[APIC]
10.255.139.149 ansible_ssh_user=admin
https://github.com/joelwking/ansible-aci/blob/master/apic_cli_example.yml

12. Ansible ACI Modules
• aci_gather_facts.py
• Gather Facts using Class or
Managed Object Queries
• https://youtu.be/Ec_ArXjgryo
• aci_install_config.py
• Configures the fabric via
ACI controller (APIC) northbound
REST API interface.
• https://youtu.be/PGBYIxEsqU8
• This module issues POST of XML,
the APIC will create or update object as required.
• Deletions implemented by including status="deleted“ in the XML
APIC

13. Gathering Facts: Types of Queries
• Managed Objects (MO) are abstract representations of physical / logical entity.
• Contain a set of configurations and properties.
• Organized in a tree structure called the Management Information Tree.
get /api/mo/uni/tn-ACME.jsonget /api/class/fvTenant.json
tn-mgmt tn-ACMEtn-infra tn-mgmt tn-ACMEtn-infra
Object-level queryClass-level query

14. Managed Object Query
• Managed Object Queries and Class Queries are handled by the same module,
aci_gather_facts.py
• The difference is the URI specified as argument to the module,
• In either case, the answer set is a list of objects, typically the Class Query will have
more than one element in the list.
• If the REST call is successful, but the results are null, the list is empty.
• Example playbook for Managed Object query:
https://github.com/joelwking/ansible-aci/blob/master/aci_mo_example.yml

15. Class Query: Find MAC address given IP
fvCEp A client endpoint attaching to the network.
./bin/ansible-playbook find_macaddress.yml
---
# https://github.com/joelwking/ansible-aci/blob/master/find-macaddress.yml
- name: Ansible ACI Demo of gathering facts using a class query
hosts: prod-01
connection: local
gather_facts: no
vars:
IPaddr: 198.51.100.4
tasks:
- name: Find the MAC address given an IP address
aci_gather_facts:
queryfilter: 'eq(fvCEp.ip, "{{IPaddr}}")'
URI: /api/class/fvCEp.json
host: "{{hostname}}"
username: admin
password: "{{password}}"
- name: use msg format
debug: msg=" ManagementIP {{ fvCEp[0].ip }} mac {{ fvCEp[0].mac }} encap {{ fvCEp[0].encap
}} "
TASK: [use msg format]
*****************************************
ok: [prod-01] => {
"msg": " ManagementIP 198.51.100.4
mac 00:50:56:B6:1C:CC encap vlan-2142 "
}
Filter results based on ip address specified
Can anyone tell me the flaw in this logic?

16. Importing Playbook into Tower
• Logon Tower
• Create directory /var/lib/awx/projects/find-macaddress
• Copy the contents of the playbook
into a file in the directory,
e.g. find-macaddress.yml
• I commented out the variable,
IPaddr, Tower will prompt.
• Create a project,
• Create a job template,
• Run job template.

17. Demo: Find the MAC address
https://youtu.be/t03ty5Y295U

18. Install ACI Configuration
• Ansible module aci_install_config.py
• Configures the fabric via
ACI controller (APIC) northbound
REST API interface.
• Reads the XML file specified as an argument
• Authenticates with the APIC
• Issues HTTP Post with the URL specified.
• Key Point
• Gather Facts provided the MAC and ‘dn’ based
on a Tenant and IP address
• Now we can programmatically build a
troubleshooting policy and load into tenant.
• By automating the creation of monitoring
and troubleshooting policies, we save time.

19. $ cat initiate_traceroute.yml
---
- name: Initiate Traceroute between two hosts
hosts: prod-01
connection: local
gather_facts: no
vars:
local_path: /home/administrator/ansible/CFGS
fvTenant: A10_DEMO
tasks:
- name: Install the traceroute configuration
aci_install_config:
xml_file: "{{ local_path }}/traceroutepTrEp_A10_clientserver.xml"
URI: "/api/mo/uni/tn-{{fvTenant}}.xml"
host: "{{hostname}}"
username: admin
password: "{{password}}"
Install ACI Configuration
Endpoint-to-Endpoint Traceroute Policy
./bin/ansible-playbook initiate_traceroute.yml
<fvTenant>
<traceroutepTrEp adminSt="start" descr="traceroute policy for client to server 10"
dn="uni/tn-A10_DEMO/trEp-CLIENT_SERVER10" name="CLIENT_SERVER10"
payloadSz="1460">
<traceroutepRsTrEpSrc
tDn="uni/tn-A10_DEMO/ap-SMALL_SERVERS/epg-CLIENT/cep-00:50:56:9A:79:5C"/>
<traceroutepRsTrEpDst
tDn="uni/tn-A10_DEMO/ap-SMALL_SERVERS/epg-SERVER/cep-00:50:56:9A:6A:03"/>
</traceroutepTrEp>
</fvTenant>
traceroutepTrEp_A10_clientserver.xml

20. • Tower initiates Python modules
to apply policy to tenant in ACI
fabric.
• Tower initiates Python application
installed in Docker container
on client machine.
Ansible Tower – Apply ACI policy and run Docker app
x-docker-client
x-docker-server-1
.10
.1
.1
.10
192.0.2.0 / 24
TEST-NET-1
198.51.100.0 / 24
TEST-NET-2
Bridge Domain
TEST-NET-2
Bridge Domain
TEST-NET-1
management network
policy
app

21. Demo: Apply ACI policy, run Docker app
https://youtu.be/t03ty5Y295U?t=1m49s

22. Developing Configuration Libraries

23. Using Playbooks to Organize your Workflow
• While developing ACI configurations, I found myself
using Ansible Playbooks
to organize my work.
• The total configuration is broken into distinct,
verified steps.
• The configuration snippits can be shared among
engineers as ACI ‘best practice’ configs.
• Repository on WWT’s GitHub Enterprise server
atc-ops / aci-config-templates

24. Configure via the GUI
configure
Verify |
test
Save XML
Incorporate
into
playbook
automate

25. Verify and Test the configuration
configure
Verify |
test
Save XML
Incorporate
into
playbook
automate

26. Save the config snippet as XML
<fvTenant>
<traceroutepTrEp adminSt="start" descr="traceroute policy for client to server 10"
dn="uni/tn-A10_DEMO/trEp-CLIENT_SERVER10" name="CLIENT_SERVER10" ownerKey="" ownerTag="" payloadSz="56">
<traceroutepRsTrEpSrc tDn="uni/tn-A10_DEMO/ap-SMALL_SERVERS/epg-CLIENT/cep-00:50:56:9A:79:5C"/>
<traceroutepRsTrEpDst tDn="uni/tn-A10_DEMO/ap-SMALL_SERVERS/epg-SERVER/cep-00:50:56:9A:6A:03"/>
</traceroutepTrEp>
</fvTenant>
configure
Verify |
test
Save XML
Incorporate
into
playbook
automate

27. Incorporate into Playbook
---
- name: Deploy Tenant for A10 ADC
hosts: prod-01
connection: local
gather_facts: no
vars:
local_path: /home/administrator/ansible/CFGS
fvTenant: A10_DEMO
L4L7: vnsLDevVip_A10.xml
tasks:
- name: Loop through the variables to deploy the tenant
aci_install_config:
xml_file: "{{ local_path }}/{{ item }}"
URI: "/api/mo/uni/tn-{{fvTenant}}.xml"
host: "{{hostname}}"
username: admin
password: "{{password}}"
with_items:
- fvTenant_A10_DEMO.xml # Create Tenant
- vzFilter_A10_TCP_SMALL_SERVERS.xml # Create Filter
- vzBrCP_A10_CONTRACT_SUBJ.xml # Create Contract and Subject
- fvCtx_A10_DEMO.xml # Create Pritx_A10_DEMO.xml
- fvBD_A10_BRIDGE_DOMAIN.xml # Create Bridge Domains
- fvAP_A10_APP.xml # Create Application EPGs
- traceroutepTrEp_A10_clientserver.xml # Create traceroute policy
- "{{ L4L7 }}" # Create L4-L7 Services
configure
Verify |
test
Save XML
Incorporate
into
playbook
automate

28. Automate
configure
Verify |
test
Save XML
Incorporate
into
playbook
automate

29. Configuration Libraries
• ACI needs a library of ‘best practice’ configurations.
• Network engineers create configurations using
the APIC GUI.
• Configurations are tested, verified and then saved
in XML.
• The configuration snippets are organized into a
playbook.
• Only the with_items loop needs be changed in the
playbook.
• XML files can be converted into templates.
• Playbooks, XML and Templates stored in Git Repo.

30. Key Take-away
• Networks are evolving from individual devices to the SDN paradigm
of a single fabric under a central controller.
• Cisco ACI is an SDN implementation which abstracts the network devices,
the fabric is plug-n-play, provides central management and visibility.
• The GUI on top of an SDN controller isn't sufficient and we will still need automation
• Eliminate the hands in operations -
• No keyboard errors,
• No incomplete configurations,
• Build libraries of ‘best practice’ configurations.
• Network Engineers can use Ansible to automate Nexus switches to more closely align with
DevOps.

31. Thanks to our sponsors… and contributors
www.slideshare.net/joelwking