BRKACI-2770 Automating ACI PDF

BRKACI-2770
Automating ACI
Steve Sharman – Technical Solutions Architect

Russ Whitear – Consulting Systems Engineer
Abstract
Automating ACI explores the use of popular automation tools running
configuration tasks against an ACI network.
The session will be based on real world use cases where we’ll use different
automation tools to configure ACI network interfaces, tenants/VRFs/BDs,
contracts, and finally we’ll deploy a complete application stack using the
previously configured objects.
Technologies discussed will include APIC, Visore, Postman, Ansible, UCS

Director, and CloudCenter.
BRKACI-2770 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Session objectives
This session will provide attendees with an understanding

of the ACI policy model along with the basic skills
required in order to automate an ACI fabric to create an
internal private cloud.
Before we start, let’s get to know each other …
Agenda
• Why Automate?
• ACI Primer
• ACI Policy Model
• Automation Use Cases
• Automating with UCS Director
• Automating with Postman
• Automating with Ansible
• Automating with CloudCenter
• Summary
Let’s start with an
obvious question…
Why are customers looking to use automation in
their Data Centers…?
There are actually many different reasons:
• Cost reduction
• Simplicity
• Consistent configuration (Policy conformance, elimination of human error)
• Reduction in maintenance windows
• Reduction in time consuming repetitive tasks
• Structured changes during the business day
• Service Catalogue for IT services
• Elastic scaling
Automation means different things to different
people…!
DEVELOPER Platform Team
SecOps Engineer DEVOPS
DEVSECOPS
DEV-TEST
SRE Platform Team NetDevOps
SCRUM Lead
Network
NetOps
Application Architect
Placeholder text Reliability
SYSTEMS ENG DevOps Engineer SRE

DEVOPS ENG Placeholder CHAOS ENG
Infrastructure DEV FullSTACK
TEST-DEV
FULL-STACK
NETDEVOPS
Different Mindsets
REQUEST
Change Management Mindset DevOps Mindset

Avoid failure, Change is Risky and Complex, Embrace failure, Change is good, Active
Empowered accountability, Limited Feedback collaboration, Empowered accountability,
Systems, Manual Feedback systems, Automation
The Rise of the Developer
“We are no longer rolling code by hand—bespoke, crafted from scratch
and stored in a private stash. Instead, developers integrate and connect
existing pieces together. We fork and adapt. Code becomes a cumulative,
open-sourced effort. We are a community of developers working
together.”
It means each
“This new way of working together has a surprising effect.
dev has tremendous influence on which tools get adopted .
The revelation is that developers have become a critical go-to-market
distribution channel. If developers don't like a product, they won't use it. Period.
No amount of pressure from a CIO can change that .
Developers will always find a work-around that works better.”
https://www.sequoiacap.com/article/rise-of-the-developer
What is Core vs Context for Network Admins…?
Routing Change
BGP, OSPF Control
Interface
Security
Configuration
Fault Finding
Time for a change of mindset
Cloud
Lets
Internal is
useITthe
is
quicker
so
“cloud”
slow..! Why
Hownot
canpresent the
I exit the
network as just
change control
another cloud…?
loop…?
Cloud is
cheaper
I’m in control
Tools, tools, and more tools…!
Application
What is “core”
Presentation to networking…?
Session
Transport Access Lists
Network Routing
Data Link Interfaces
Physical
There is no perfect automation tool…!
Applications
Virtual Machines
Contracts
Application Profiles,
Endpoint Groups
Tenants, VRFs, Bridge

Domains
Interfaces
A quick ACI Primer…
Physically Building the ACI Network
Management options: Benefits:

• GUI • Distributed, Centralised Management
• CLI • Full traffic visibility*
• XML/JSON • Self documenting
• Scripting • Integrated virtual and physical
• Open API network
• Automation • Integrated L4-7 device management
• Policy defined network
* Excludes pre encapsulated/encrypted traffic
ACI Consumption Model
Interface Configuration Interface Consumption
Fabric | Access Policies Tenants
• VLANs • Tenants
• Domains • VRFs
• AAEP • Route Leaking
• Interface Policies • L2/L3out
• Leaf Policy Groups • Bridge Domains
• Leaf Profiles • EPGs
• Switch Profiles • Contracts
Step 1: Configure the network interfaces
Security Domains
Restricts VLANs, Switches,
Interfaces, Tenants
Tenants Leaf Switches

VRFs, subnets, security Profiles Concrete Model
(Configuration applied)
rules etc Collection of switches
Leaf Interfaces Logical Model

Profiles
Collection of interface IDs (Configuration defined)
Interface Selectors
Interface IDs
AAEP Leaf Interfaces Interface Policies

Collection of allowed Policy Groups Interface settings
VLANs, VXLANs etc Interface type and settings
Domains
Where VLANs, VXLANs
etc are consumed
Pools
List of VLANs, VXLANs etc
Configure additional interfaces
Option 1
on Leaf switches
Switch Policies Switch Policies Switch Policies
Leaf Profiles Leaf Profiles Leaf Profiles
Leafs_101_and_102 Leafs_103_and_104 Leafs_105_and_106
Interface Policies Interface Policies Interface Policies

Leaf Profiles
Profile mapped
aligned to Leaf Profiles Leaf Profiles Leaf Profiles
switches Leafs_101_and_102 Leafs_103_and_104 Leafs_105_and_106
Interface Selectors Interface Selectors Interface Selectors

1/1, 1/2, 1/3…. 1/11, 1/12, 1/13…. 1/21, 1/22, 1/23….
Leaf Policy Groups Leaf Policy Groups Leaf Policy Groups

ESX_Hosts Linux_Hosts Windows_Hosts
Domains AAEP Interface Policies

Ciscolive-vds-01 all_vlans cdp-enabled
Pools Domains
all_vlans physical_servers
Option 2 Switch Policies
Leaf Profiles
Leafs_101_and_102
Switch Policies
Leaf Profiles
Leafs_103_and_104
Switch Policies
Leaf Profiles
Leafs_105_and_106
Interface Policies Configure additional Leaf

Leaf Profiles switches with selected Leaf
Leaf Profiles aligned to ESX_Hosts
Leaf Profile mapped to Profile
attached device i.e.
switches
ESX_Hosts
Interface Selectors
1/1, 1/2, 1/3….
Leaf Policy Groups

ESX_Hosts

Pools
all_vlans
Step 2: Use the network interfaces
How should you design your Tenants…?
There are four options…
Tenant: common Tenant: common Tenant: common Tenant: Ciscolive
VRF: vrf-01 VRF: vrf-01 VRF: vrf-01 VRF: vrf-01
Bridge Domain Bridge Domain Bridge Domain
Bridge Domain
EPG EPG
Application Profile: EPG EPG Application Profile:
Application Profile: Application Profile:
Tenant: Ciscolive Tenant: Ciscolive
Typically used when VRFs and subnets VRFs are available to VRFs and subnets
RBAC isn’t a strong are all in the all Tenants, however are dedicated to an
requirement and one Common Tenant – subnets are specific individual Tenant –
team owns all the this means that any to a given Tenant typically this is tied
configuration Tenant can use any into RBAC rules for
subnet access to APIC from
multiple teams
Where should you “place” Contracts and Filters…?
Contract Filter Contract
Contract
Filter Filter
Contract Filter
Typically used when Filters in the Contracts and Filters Contracts and Filters
RBAC isn’t a strong Common Tenant in a “user” tenant in a “user” tenant
requirement and one allows any Tenant to with shared with private
team owns all the consume them in networking networking
configuration their contracts
Step 3: Should you use Network Centric mode or
Application Centric mode…?
What is meant by Network Centric mode and
Application Centric mode…?
• Network Centric mode [naming] or Application Centric mode [naming] are simply terms to
describe how the ACI network configuration is named, for example is a VLAN named
“VLAN-10” or is a VLAN named “Web”
• Having the network configuration named after network objects (subnets/VLANs) is the
traditional way of configuring a network
• Having the network configuration named after applications running on the network
provides improved application visibility, simpler troubleshooting, and simpler auditing
• An application may represent an actual application such as “online banking”, or it may
represent an infrastructure service such as “ESX infrastructure”
• Typically customers use Network Centric mode [naming] to describe legacy VLANs and
subnets, and Application Centric mode [naming] to describe applications on the network
• Both naming modes can be used concurrently
There are only three deployment options for
Bridge Domains (subnets) and EPGs
Option 1: Single EPG on a Single BD with a Single
Subnet – “Standard Networking”
Tenant: Ciscolive
VRF: vrf-01
BD: 192.168.10.x_24 BD: 192.168.11.x_24 BD: 192.168.12.x_24

GW:192.168.10.1/24 GW:192.168.11.1/24 GW:192.168.12.1/24
Advertise Externally: Yes Advertise Externally: Yes Advertise Externally: Yes
Application Profile: MyApp
EPG: Web EPG: App EPG: DB

vDS: Ciscolive-vds-01 vDS: Ciscolive-vds-01 Path: 101/1/1-2
VLAN: dynamic VLAN: dynamic VLAN: 12
vDS
Portgoup: Portgoup:
Ciscolive:MyApp:Web Ciscolive:MyApp:App
VM VM VM VM VM VM
Option 2: Multiple EPGs on a Single BD with a Single
Subnet – µSegmentation in IP space
Tenant: Ciscolive
VRF: vrf-01
BD: 192.168.10.x_24
GW:192.168.10.1/24
Advertise Externally: Yes

vDS
Portgoup: Portgoup:
VM VM VM VM VM VM
Option 3: Multiple EPGs on a Single BD with Multiple
Subnets – IP secondary
Tenant: Ciscolive
VRF: vrf-01
BD: multiple_subnets
GW:192.168.10.1/24
GW:192.168.11.1/24
Advertise Externally: Yes

vDS
Portgoup: Portgoup:
Servers in either 192.168.10.x

VM VM VM VM VM VM or 192.168.11.x subnets
How would I migrate
from “Network Centric”
mode [naming] to
“Application Centric”
mode [naming]…?
Why change what’s already working…?
How will you discover your application

dependencies…?
How long will it take to migrate…?
What will be the operational impact…?
Migrating from Network Centric [Naming] to Application
Centric [Naming]
Tenant: common
VRF: vrf-01
Outside
BD
192.168.10.x_24
Contract
EPG (VLAN) EPG (VLAN) EPG (VLAN) EPG (VLAN)
VLAN-10 Web App DB
Application Profile: 192.168.10.x_24 Application Profile: Online-Banking
Tenant: Classic Tenant: Production
Contract Contract
Contracts and/or Firewalls between different security
zones
EPG (VLAN) EPG (VLAN)

Secure contracts High Security
Web Web
between zones
Contract

Medium Security
App App
Contract

Low Security
DB DB
Contract
Application Profile: Online-Banking Application Profile: Investment-Banking
Tenant: Production
Optional default
contract within a zones
Let’s quickly spin up an
environment on a
simulator
BRKACI-2770 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
Use Case: #1
Interface configuration
using UCSD
Application
is interface configuration
Presentation “core” to networking…?
Session
Network Routing
Physical
Why choose UCS Director for automation…?
Pros: Cons
• Off the shelf commercial product with full support • Some Scripting (JavaScript) maybe required for
• Drag and Drop Workflow Orchestrator with Rollback Extensibility Beyond OOB Tasks
• ~250 ACI Tasks Out of the Box
• End User Portal for Catalogue Consumption
• Support for Cisco and non Cisco products – Compute,
Network, Storage, VM Deployment etc.
• Extensive Northbound API
Why automate interface configuration…?
Configuring network interfaces is a time consuming
and repetitive task that is prone to human error
Should interface configuration be considered a

“core” role of the network team…?
Could the interface configuration be delegated to

the “server/infrastructure” team…?
Use case #1: Interface Configuration using UCSD
Predefined parameters
• Leaf Switch Profile
• Leaf Interfaces Profiles
• Leaf Interface Policy Groups
• Leaf Interface Policies
• AAEP
• Domain
• VLAN Pool
Required parameters
• Leaf(s) ID
• Interface ID
• Interface Description
• Server type
Configure additional interfaces
on Leaf switches
Switch Policies Switch Policies Switch Policies
Leaf Profiles Leaf Profiles Leaf Profiles
Leafs_101_and_102 Leafs_103_and_104 Leafs_105_and_106
Interface Policies Interface Policies Interface Policies

Leaf Profiles
Profile mapped
aligned to Leaf Profiles Leaf Profiles Leaf Profiles
switches Leafs_101_and_102 Leafs_103_and_104 Leafs_105_and_106
Int Sel Int Sel Int Sel Int Sel Int Sel Int Sel Int Sel Int Sel Int Sel
1/1 1/2 1/3 … … … 1/46 1/47 1/48
Description Description Description Description Description Description Description Description Description
Leaf Policy Groups Leaf Policy Groups Leaf Policy Groups

ESX_Hosts Linux_Hosts Windows_Hosts

Pools Domains
all_vlans physical_servers
Let’s see UCSD in
action…
Quick step by step
walkthrough…
What happens on the
ACI fabric…?
Note the SR for rollback purposes
How do I remove the
configuration…?
What happens behind
the scenes…?
What does the UCSD
configuration look
like…?
To really get the most
out of automation we
need to understand the
ACI Policy Model and
how to use the API
What is the ACI Policy Model…?
The ACI policy model enables the specification of application requirements
policies. The APIC automatically renders policies in the fabric infrastructure.
When a user or process initiates an administrative change to an object in the

fabric, the APIC first applies that change to the policy model. This policy
model change then triggers a change to the actual managed endpoint.
This approach is called a model-driven framework.
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/aci-fundamentals/b_ACI-
Fundamentals/b_ACI-Fundamentals_chapter_010001.html
https://{{apic}}/
Managed Objects Policy Universe
APIC Controllers Tenants – User, Fabric, Access, Layer 4-7 AAA, Security
VM Domains …
… Common … Inventory … Services
Tenant
Application Filter
Outside Network Bridge Domain VRF Contract
Profile
Subnet Subject
EPG
Object data can be accessed
in different ways, either by calling the object Class (e.g. all
fvBD) or by calling an object by name (e.g. tn-Ciscolive)
The HTTP methods that we invoke are:

POST, GET, DELETE
Managed Objects
https://{{apic}}/api/node/mo/uni/{{dn}}.json?{{filter}}
https://{{apic}}/api/node/class/{{class}}.json?{{filter}}
Distinguished Name – Name of Object Object Class - Types of Object

• tn-{{name}} • fvTenant - Tenant
• tn-{{name}}/BD-{{name}} • fvBD – Bridge Domain
• tn-{{name}}/ap-{{name}} • fvAp – Application Profile
• tn-{{name}}/ap-{{name}}/epg-{{name}} • fvAEPg – EPG
• … • …
How do I understand all the MOs…?
You could read the documentation, but….
https://{{apic}}/doc/html
….Postman and visore are your friends…!
https://{{apic}}/visore.html
Targeting Queries
Query Target Filters – Single object retrieved
self
https://{{apic}}/api/node/mo/uni/tn-common/BD-192.168.10.0_24.json?query-target=self
Query Target Filters – List of Twelve objects retrieved
children
https://{{apic}}/api/node/mo/uni/tn-common/BD-192.168.10.0_24.json?query-target=children
Query Target Filters – List of Fourteen objects retrieved
subtree
https://{{apic}}/api/node/mo/uni/tn-common/BD-192.168.10.0_24.json?query-target=subtree
rsp – Tree of objects retrieved
subtree
https://{{apic}}/api/node/mo/uni/tn-common/BD-192.168.10.0_24.json?rsp-subtree=full
Audience quiz time…..!!
Advanced Queries
https://{{apic}}/api/node/class/fvAEPg.json?query-
target=subtree&query-target-
filter=and(wcard(fvRsBd.tnFvBDName,"10.52.249.96_27"))
https://{{apic}}/api/node/class/fvBD.json?query-
target=subtree&query-target-
filter=and(eq(fvRsBDToOut.tnL3extOutName,"OSPF_to_external_
vrf-global"))
https://{{apic}}/api/node/class/fvIfConn.json?query-target-
filter=and(eq(fvIfConn.encap,"vlan-8"))
https://github.com/spsharman/ | https://github.com/rwhitear42
Use Case: #2
Bridge Domain
configuration using
Postman and Runner
Application
is routing configuration
Session
Network Routing
Physical
Why use Postman…?
Pros: Cons
• No/little scripting experience required • Some knowledge of JSON/XML required
• Both network and server operating systems can be
managed
• It’s extremely easy to use
Step 1: Build your required object(s) in the GUI
Tenant: Common Tenant: Ciscolive
VRF: vrf-01 VRF: vrf-01
Route Leak 0.0.0.0/0
BD: 192.168.10.x_24 BD: 192.168.11.x_24 BD: 192.168.12.x_24

GW:192.168.10.1/24 GW:192.168.11.1/24 GW:192.168.12.1/24
Ext Switch: 6ka

VRF: global Application Profile: MyApp

vDS: Ciscolive-vds-01 vDS: Ciscolive-vds-01 vDS: Ciscolive-vds-01
VLAN: dynamic VLAN: dynamic VLAN: dynamic
Ext Switch: 6kb
VRF: global
vDS
Portgoup: Portgoup: Portgoup:
Ciscolive:MyApp:Web Ciscolive:MyApp:App Ciscolive:MyApp:DB
VM VM VM VM VM VM VM VM VM
Step 2: Save your configuration
Tenant: Common Tenant: Ciscolive
VRF: vrf-01 VRF: vrf-01
Route Leak 0.0.0.0/0
BD: 192.168.10.x_24 BD: 192.168.11.x_24 BD: 192.168.12.x_24

GW:192.168.10.1/24 GW:192.168.11.1/24 GW:192.168.12.1/24
Ext Switch: 6ka

VRF: global Application Profile: MyApp

vDS: Ciscolive-vds-01 vDS: Ciscolive-vds-01 vDS: Ciscolive-vds-01
VLAN: dynamic VLAN: dynamic VLAN: dynamic
Ext Switch: 6kb
VRF: global
vDS
Portgoup: Portgoup: Portgoup:
Ciscolive:MyApp:Web Ciscolive:MyApp:App Ciscolive:MyApp:DB
VM VM VM VM VM VM VM VM VM
Step 3: Prettify your JSON
Provided Contract
Step 4: Understand/modify the code

Contract name
Application Profile
“path” to the Domain
Application Profile
Endpoint Group
Application Profile
name Domain name
(VMM)
Endpoint Group name
Children of the
Application Profile
Children of the
Endpoint Group
Bridge Domain
Bridge Domain name
Step 5: Create Postman environment
Step 6: POST the modified content back to APIC
https://{{apic}}/api/node/mo/.json?rsp-subtree=modified
We can now use Runner to make bulk changes
Step 7: Select parameters to use Provided Contract
as variables
Contract name
(variable)
Application Profile
“path” to the Application
Profile (variable) Domain
Endpoint Group
Application Profile
name (variable) Domain name
(VMM) (variable)
“path” to the Endpoint
New “status” Group (variable)
object (variable)
Endpoint Group
name (variable)
New “status”
object (variable) Bridge Domain
Bridge Domain name

(variable)
Step 8: Create a variable file
Option: created
Option: created,modified
Option: deleted
Step 9: Create a POST and Insert JSON with variables
Step 10: Select file with input variables
Step 11: Monitor output
Bridge Domains – before Runner
Postman Runner BD Video
Bridge Domains – after Runner
Use Case: #3
Contract configuration
using Ansible
Application
is ACL configuration
Session
Network Routing
Physical
Configuring Contracts is a function typically executed
by the network team, however the rules are
requested by the application team
Therefore why not allow the application team to

automatically configure their own rules…?
Contracts are similar to ACL or firewall entries
Outside Inside
ubuntu-01 ubuntu-02
permit ubuntu-01 ubuntu-02 tcp 5201
EPG: portgroup-01 EPG: portgroup-02

vDS: Ciscolive-vds-01 vDS: Ciscolive-vds-01
VLAN: dynamic VLAN: dynamic
Contract: Consumer Contract: Provider
ubuntu-01 ubuntu-02
Contract: permit_to_portgroup-02
Contract components
Contract: Options:
permit_to_{{ prov_ap_name }}_{{ prov_epg_name }} Scope, Qos, DSCP, Tag
Options:
Contracts may have
more than one Subject Apply Both Directions
Subject: Reverse Filter Ports
{{ subj_name }} Service Graph
QoS
DSCP
Filter: Options:
{{ subj_name }}_src_any_to_dst_tcp_{{ dst_port }} Tag
Filters may have more

than one entry Options:
Entries: Src / Dst ports
any | {{ dst_port }} Flags
Stateful
Where should you “place” Contracts and Filters…?
Contract Filter Contract
Contract
Filter Filter
Contract Filter
Typically used when Filters in the Contracts and Filters Contracts and Filters
RBAC isn’t a strong Common Tenant in a “user” tenant in a “user” tenant
requirement and one allows any Tenant to with shared with private
team owns all the consume them in networking networking
configuration their contracts
Prior to this presentation we deployed a new
WordPress application in our lab
Two Tier WordPress Application
Tenant: Common
VRF: vrf-01
BD: 10.52.249.96_27 BD: 192.168.3.x_24

GW:10.52.249.97 GW:192.168.3.1/24
Advertise Externally: Yes Advertise Externally: Yes
Application Profile: wpCL19_631
EPG: WSERVER_1 EPG: DSERVER_1

vDS
Portgoup: Portgoup:
Ciscolive:wpCL19_631:WSERVER_1 Ciscolive:wpCL19_631:DSERVER_1
VM VM VM VM VM VM
...but our application is failing…
Error establishing a database connection
Tenant: Common
VRF: vrf-01
BD: 10.52.249.96_27 BD: 192.168.3.x_24

GW:10.52.249.97 GW:192.168.3.1/24
Advertise Externally: Yes Advertise Externally: Yes
EPG: WSERVER_1 EPG: DSERVER_1

vDS
Portgoup: Portgoup:
Ciscolive:wpCL631:WSERVER_1 Ciscolive:wpCL631:DSERVER_1
10.52.249.123 VM VM 192.168.3.119
We have a couple of Ansible Playbooks that can
help diagnose and fix the issue…
How did we start writing
the playbook to
automate adding
connectivity…?
First things first…
1. Gather minimum 1. Use Postman and 1. Start writing the
required information visore to gather and Playbook…!
(User supplied) test the required API
calls 2. Learn to hate the
1. Source IP address indentation used by
2. Destination IP address 2. Define the list of tasks YAML
3. Protocol Type (Plays) to perform
3. Start again with
4. Port to be opened 3. Check whether there individual Plays
are existing Ansible
modules available to 4. Merge the Plays into a
perform the tasks Playbook
4. User aci_rest module

for everything else
Now let’s start filling in
the blanks…!
What is Ansible…?
• Open Source • Version 2.7.5

• ACI support - 2.4
• Automation, Configuration & Orchestration
• Agentless, Push Model
• Most *NIX flavors can be control machine
• Windows Not Supported • Idempotent
• Can manage different systems • YAML based

• ACI, IOS, NX-OS, IOS-XR
Why use Ansible…?
Pros: Cons:
• No/little scripting experience required • Some knowledge of JSON/XML required
• Both network and server operating
systems can be managed
• Inbuilt modules for many devices to be
managed (Not just ACI)
• Idempotence
Ansible Components
• Control Machine – Used to configure and push playbooks/plays to target
systems
• Target Systems – Systems we want Ansible to control/automate
• Inventory files – Text based host files for target systems
• INI or YAML based
• Playbook – Series of plays/automation tasks
• YAML based
• Modules – reusable scripts that perform tasks in Ansible
Ansible ACI Modules
• Perform specific tasks (Create Tenant/VRF/BD)
• Already installed when you install Ansible
• Written in Python
• Can develop your own modules
• 60 ACI modules as of 2.7
• To see all Ansible Modules – ansible-doc -l
• ACI specific ones – ansible-doc -l | grep ^aci
DEVNET-1797 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 157
again….Postman and visore are your friends…!
https://{{apic}}/visore.html
Use Postman to validate queries
Let’s look at the Playbook…
Ansible Playbook breakdown
Start of YAML ---
# Just a comment
Comment - name: What do we want to execute against
Name of hosts: "{{ apic }}"
Playbook connection: local
gather_facts: no
Hosts from
inventory tasks:
Connection is - name: Create Tenant
aci_tenant:
local to this
host hostname: "{{ apic }}"
username: "{{ apic_username }}"
Collects password: "{{ apic_password }}"
information tenant: "CiscoLive"
about targets description: "Tenant configured by Ansible"
validate_certs: no
state: present
The scope of the Contract has
been pre-defined
Prompt for user input
Define some Facts (Variables)
to be used later
Use the aci_config_snapshot
module to take a snapshot
Use the aci_rest module to discover
the source IP/EPG mapping from
the fvCEp Class
Extract the Tenant, App Profile and
EPG name from the source dn
Use the aci_rest module to discover
the destination IP/EPG mapping
from the fvCEp Class
Extract the Tenant, App Profile and
EPG name from the destination dn
Create a Filter based on the
protocol type and destination port
Create a Filter entry based on the
destination port
Create a Contract based on the
destination Application Profile and
EPG
Add the Subject and Filter to the
Contract
Bind the Contract to the Provider
EPG
Bind the Contract to the Consumer
EPG
Let’s open SSH from the Web server to the
Database server
Application deployment
using CloudCenter
Application
What is “core”
Presentation to networking…?
Session
Network Routing
Physical
Why use Cisco CloudCenter…?
Pros: Cons
• Supports both public and private clouds • Less flexible naming convention
• Allows Application Teams to consume the network as
part of the application deployment
• Allows the Application Teams to control access to
their applications
• Both network and server operating systems can be
managed
• Governance
• Rollback (application and network)
Summary
Summary
• There is no perfect automation tool
• Select the tool that best serves the requirements of your users
• Postman and visore are your friends to understand the API
• Automate time consuming, repetitive tasks
Cisco Webex Teams
Questions?
Use Cisco Webex Teams (formerly Cisco Spark)
to chat with the speaker after the session
How
1 Find this session in the Cisco Events Mobile App
2 Click “Join the Discussion”
3 Install Webex Teams or go directly to the team space
4 Enter messages/questions in the team space
cs.co/ciscolivebot#BRKACI-2770
Complete your online
session survey
• Please complete your Online Session
Survey after each session
• Complete 4 Session Surveys & the Overall
Conference Survey (available from
Thursday) to receive your Cisco Live T-
shirt
• All surveys can be completed via the Cisco
Events Mobile App or the Communication
Stations
Don’t forget: Cisco Live sessions will be available for viewing

on demand after the event at ciscolive.cisco.com
Continue Your Education
Demos in Meet the Related

Walk-in
the Cisco engineer sessions
self-paced
Showcase labs 1:1
meetings
Thank you

BRKACI-2770 Automating ACI PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

BRKACI-2770 Automating ACI PDF

Hochgeladen von

Copyright:

Verfügbare Formate

BRKACI-2770

Steve Sharman – Technical Solutions Architect

Technologies discussed will include APIC, Visore, Postman, Ansible, UCS

This session will provide attendees with an understanding

SYSTEMS ENG DevOps Engineer SRE

Change Management Mindset DevOps Mindset

Transport Access Lists

Data Link Interfaces

Tenants, VRFs, Bridge

Management options: Benefits:

Tenants Leaf Switches

Leaf Interfaces Logical Model

AAEP Leaf Interfaces Interface Policies

Interface Policies Interface Policies Interface Policies

Interface Selectors Interface Selectors Interface Selectors

Leaf Policy Groups Leaf Policy Groups Leaf Policy Groups

Domains AAEP Interface Policies

Interface Policies Configure additional Leaf

Leaf Policy Groups

Domains AAEP Interface Policies

Bridge Domain Bridge Domain Bridge Domain

Application Profile: EPG EPG Application Profile:

Application Profile: Application Profile:

Tenant: Ciscolive Tenant: Ciscolive

Contract Filter Contract

Tenant: Ciscolive Tenant: Ciscolive

BD: 192.168.10.x_24 BD: 192.168.11.x_24 BD: 192.168.12.x_24

Application Profile: MyApp

EPG: Web EPG: App EPG: DB

Application Profile: MyApp

EPG: Web EPG: App EPG: DB

Application Profile: MyApp

EPG: Web EPG: App EPG: DB

Servers in either 192.168.10.x

How will you discover your application

How long will it take to migrate…?

What will be the operational impact…?

Tenant: Classic Tenant: Production

EPG (VLAN) EPG (VLAN)

EPG (VLAN) EPG (VLAN)

EPG (VLAN) EPG (VLAN)

Application Profile: Online-Banking Application Profile: Investment-Banking

Transport Access Lists

Data Link Interfaces

Should interface configuration be considered a

Could the interface configuration be delegated to

Interface Policies Interface Policies Interface Policies

Leaf Policy Groups Leaf Policy Groups Leaf Policy Groups

Domains AAEP Interface Policies

When a user or process initiates an administrative change to an object in the

This approach is called a model-driven framework.

The HTTP methods that we invoke are:

Distinguished Name – Name of Object Object Class - Types of Object

• tn-{{name}}/BD-{{name}} • fvBD – Bridge Domain

• tn-{{name}}/ap-{{name}} • fvAp – Application Profile

• tn-{{name}}/ap-{{name}}/epg-{{name}} • fvAEPg – EPG

Transport Access Lists

Data Link Interfaces

BD: 192.168.10.x_24 BD: 192.168.11.x_24 BD: 192.168.12.x_24

Ext Switch: 6ka

EPG: Web EPG: App EPG: DB

BD: 192.168.10.x_24 BD: 192.168.11.x_24 BD: 192.168.12.x_24

Ext Switch: 6ka