BRKDCN 2025

BRKDCN-2025
Maximizing Network
Programmability and
Automation with NX-OS
Nicolas Delecroix
Technical Marketing Engineer, DCNBU
ndelecro@cisco.com
Open NX-OS
• Extensibility, automation and streaming
telemetry features of NX-OS running
in standalone mode on Nexus 9K.
• Every feature discussed in this

presentation is supported on every
Nexus 9K model.
• Some features are also supported on

Nexus 3K/5K/7K. This is summarized
at the end of the presentation.
BRKDCN-2025 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Objectives
• Share with you the latest Open NX-OS

innovations.
10.60.0.110 - - [14/Dec/2018 10:07:12] "POST /network/Cisco-

NX-OS-device%3ASystem%2Feps-items HTTP/1.0" 200 -
• Show code, apps and demos based on >>> URL
>>> TM-HTTP-VER
: /network/Cisco-NX-OS-
device%3ASystem%2Feps-items
: 1.0.0
real-world use cases.

>>> TM-HTTP-CNT : 1
>>> Content-Type : application/json
>>> Content-Length : 3730
Path => Cisco-NX-OS-device:System/eps-items
node_id_str : 93180-EX-2
collection_id : 161
data_source : YANG
data : {
• Provide you with ways to get started in

minutes.
Agenda • Extending NX-OS
• Docker and Kubernetes
• NX-SDK
• Automating NX-OS
• NX-API
• Ansible
• SaltStack
• NETCONF, YANG, OpenConfig, YDK
• Monitoring NX-OS
• Streaming Telemetry
Extending NX-OS
Docker
Securely Run 3rd Party Apps Prior to NX-OS 9.2(1)
• Prior to NX-OS 9.2(1), the only solution
is the Guest Shell.
• It works fine but...
• Only one Guest Shell instance can be
defined.
• The container Linux distribution is
always CentOS.
• The setup of apps in the Guest Shell
must be done from a Nexus 9K.
• Re-using and distributing Guest Shell
images can be done with the
import/export feature, but is fairly
limited.
• No container orchestration support.
Docker Engine
NX-OS 9.2(1) – July 2018
• Available on all Nexus 9K models,

and on Nexus 3K models equipped
with 8G+ of memory.
• Standard Docker engine with all the

commands supported:
docker run/pull/push/kill/info Nexus 9K
etc.
Standardization, Flexibility, and Efficiency
Guest Shell Docker Engine
Number of container instances One Many
Access to storage and network Yes Yes
Linux distribution type CentOS Any
Container manipulation NX-OS CLI (# guestshell *) Standard Linux docker tool
primitives
Definition of the container Must be done on a Nexus 9K Can be done from any
image content computer supporting Docker
Repository of existing None Docker Hub
container images
Container orchestration None Docker Swarm or Kubernetes
What Apps are Interesting to Host on N9K with Docker?
• Monitoring agents • Automation agents (Chef, Puppet,

• Open-source agents: OpenTSDB, SaltStack...)
Ganglia, Nagios, etc. • Intrusion Detection
Monitor both standard Linux • DNSFlow agent to detect phishing
components (CPU, memory, activity
interface counters), and NX-OS • Custom Intrusion Detection agents
(routes, buffers,...)
• Automatic configuration backup to
• Custom agents: ECMP load a private Git repository
balancing, PTP accuracy…
Demo: Docker on
Nexus 9K
switch(config)# feature bash-shell
switch(config)# run bash sudo su
bash-4.3#
# Start Docker
bash-4.3# service docker start
# Check the status

bash-4.3# service docker status
dockerd (pid 3597) is running...
# Persist on reload of switch:

bash-4.3# chkconfig --add docker
# Start an alpinelnx docker container:

bash-4.3# docker run --name=alpine -it alpine
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
4fe2ade4980c: Pull complete
Digest: sha256:621c2f39f8133acb8e64023a94dbdf0d5ca81896102b9e57c0dc184cadaf5528
Status: Downloaded newer image for alpine:latest
/ #
/ # grep PRETTY_NAME /etc/os-release
PRETTY_NAME="Alpine Linux v3.8"
/ #
Kubernetes
© 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
Nexus 9K as a Kubernetes Node
Deploying a nginx app via a Replication Controller
[devops@server ~]$ kubectl get node
NAME STATUS AGE
10.122.84.34 Ready 16m
127.0.0.1 Ready 22m
[devops@server ~]$ kubectl apply –f replication.yaml

replicationcontroller "nginx" created
[devops@server ~]$ kubectl describe –f replication.yaml

Name: nginx
Namespace: default
Image(s): nginx
Selector: app=nginx
Labels: app=nginx
Replicas: 2 current / 2 desired
Pods Status: 2 Running / 0 Waiting / 0 Succeeded / 0 Failed
No volumes.
Events:
FirstSeen LastSeen Count From Type Reason Message
--------- -------- ----- ---- -------- ------ -------
17s 17s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-zqfpz
17s 17s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-jij40
[devops@server ~]$
• NX-SDK
• NX-API
• Ansible
• SaltStack
NX-SDK
Tighter Integration of Custom Linux Apps
with NX-OS
• NX-SDK is a simple, flexible and powerful set of APIs for
custom on-box applications to gain access to NX-OS infra
functionalities.
• Apps are still regular Linux programs. They just use the NX-SDK
APIs.
• Apps run natively as NX-OS features just like the Cisco-developed
features.
• Startup and management of the apps is handled by NX-OS.
Your NX-SDK App Your NX-SDK App Your NX-SDK App Nexus 9K
Linux 4.1
NX-SDK APIs
NX-OS Infrastructure
(CLI Manager, Syslog Manager, RIB Manager...) CLI
Your Your Native Native Nexus 9K
NX-SDK App NX-SDK App NX-OS Feature NX-OS Feature Linux 4.1
NX-SDK APIs
(CLI Manager, Syslog Manager, RIB Manager...) CLI
NX-SDK Features
NX-OS 7.0(3)I6(1) – May 2017
• Python and C++ support. • Gain access to NX-OS CLI:

cli = sdk.getCliParser()
• Definition of custom CLIs:
• Config and show commands. • Create a new custom CLI config
• Callback handler with your code command:
cli.newConfigCmd("threshold_cmd",
gets invoked when the CLI gets "threshold <value>")
executed. cli.updateParam("<value>",
"Threshold value in Mbps",
• Generation of custom syslogs. nx_sdk_py.P_INTEGER)
• Add our command handler callback for

custom CLI:
myCmd = pyCmdHandler()
cliP.setCmdHandler(myCmd)
NX-SDK Features
NX-OS 7.0(3)I7(3) – February 2018
• RIB APIs: • Gain access to NX-OS RIB:

ribMgr = sdk.getRibMgr()
• Route lookup.
• Route events. Get notified upon
• Register a RIB callback handler, that
updates: route add, route
will be invoked when a route event
remove, next-hop change.
happens:
• Granularity: prefix, protocol, myRibCb = pyRibHandler()
address family, VRF. ribMgr.setRibMgrHandler(myRibCb)
• Streaming Telemetry support.

• Subscribe for route events:
ribMgr.watchL3Route("direct")
ribMgr.watchL3Route("bgp")
NX-OS Structured Data Model
• Object Store:
sys
• Hierarchical tree-structure representing switch configuration and
state.
• Comprised of Managed Objects (MOs) representing an element of bgp ospf
configuration or operational state.
• Data Management Engine (DME): read/write interface to the inst inst
object store.
• Object store documentation and examples on cisco.com: dom dom
https://developer.cisco.com/site/nxapi-dme-model-
reference-api/#. peer peer
• Browse the object store on the switch itself:

https://<switch management IP>/visore.html.
NX-SDK Features
NX-OS 9.2(2) – November 2018
• DME APIs: sys
• Get, add, remove objects.

bgp ospf
• Lookup objects.
• Event notifications upon object inst inst
change. dom dom
• Interface and MAC APIs.

peer peer
• Go language.
Direct DME access
Your NX-SDK Your NX-SDK Native NX-OS Native NX-OS Nexus 9K

App App Feature Feature
Linux 4.1
NX-SDK APIs
(CLI Manager, Syslog Manager, RIB Manager...)
CLI
Data Management Engine (DME)

Write Object Store Read
BGP Data VLAN Data QoS Data
Code and installation guide
https://github.com/CiscoDevNet/NX-SDK/tree/master/examples
NX-SDK Use Cases
ECMP Imbalance Monitoring
• Automatically detect ECMP bundles.

• Define a load threshold via a custom
CLI. Spine Spine Spine Spine
• Monitor the load of ECMP member links

to detect hashing imbalance.
VTEP VTEP VTEP VTEP VTEP VTEP VTEP
• When high load i.e., hashing imbalance

is detected:
• Display a custom syslog.
• Trigger a streaming telemetry event.
NX-SDK Use Cases
FEX Pre-Provisioning
• Pre-configure Host Interfaces (HIFs) before

attaching a FEX.
• When a FEX comes online, the pre-provisioned
configurations are applied.
• Nexus 5K/7K feature but currently not available
on N9K.
• NX-SDK solution:
• Define the FEX HIF configuration in a bootflash file switch# conf t
switch(config)# slot 110
fex-FEX_ID-config
switch(config-slot)# provision
• The NX-SDK app detects when a FEX comes model N2K-C2232P
online...
switch(config)# interface e110/1/1
• ... And automatically pushes the FEX HIF switch(config-if)# ...
configuration to NX-OS.
NX-SDK Use Cases
Precision Timing Protocol (PTP) Monitoring
• Display a custom syslog upon:

• Change of interface PTP state: master /
slave / passive / disabled.
switch# show ptp clock
• Change of PTP Grandmaster. PTP Device Type: Boundary clock
• High clock correction, with threshold Clock Identity :
defined via a custom CLI. 00:fe:c8:ff:fe:09:7f:f3
Clock Domain: 0
Number of PTP ports: 3
Priority1 : 255
• Rogue Grandmaster enforcement: Priority2 : 255
• Define interfaces which must only be Clock Quality:
Class : 248
connected to PTP slaves. Accuracy : 254
• When detecting a connection to a Offset (log variance) : 65535
master, automatically shut them down.
NX-SDK Use Cases
Storm Control Persistence Protection
• Storm Control: shut down an interface victim of storm traffic.

• If enabled, the shutdown happens immediately in the current
NX-OS implementation.
• NX-SDK enhancements:
• Shut it down only if storm traffic is persisting after a given interval of time.
• Interfaces can be automatically brought back up after an interval of time.
• Both time intervals are defined by custom CLIs:
switch(config)# storm.py ?
shut-interval Interval in seconds after which the interfaces on which storm
traffic persists are shut down
unshut-interval Interval in seconds after which the interfaces that got shut
down by the app are brought back up
• Pop quiz: how many lines of code does it take?

• NX-SDK
• NX-API
• Ansible
• SaltStack
Automating NX-OS
Telnet NX-API NX-API
SNMP NETCONF / RESTCONF / gRPC
or CLI REST
Client YANG Clients
SSH Client Client
Management Server
Your NX- Native NX-OS Nexus 9K

SDK Apps Features

NX-SDK APIs NGINX Server Agent YANG Agents
NX-OS Infra
(CLI Mgr, Syslog Mgr, ...) CLI

Transaction Commit Object Store Status: Success or Raise Fault
NX-API
{
"jsonrpc": "2.0",
"method": "cli",
CLI "params": {
"cmd": "show version",
Request "version": 1
Management },
Server }
"id": 1
{
"jsonrpc": "2.0",
"result": {
"body": {
"bios_cmpl_time": "03/02/2017",
JSON "bootflash_size": 7906304,
"kickstart_ver_str": "7.0(3)I7(3)",
Response "chassis_id": "Nexus 9508",
... Nexus 9K
NX-API Rollback on Error
• When a sequence of commands is sent
via NX-API, the only possible behavior
prior to NX-OS 9.2(1) is to stop upon
getting the first error.
• But all the previous commands that
went fine are still in the running config. 2000
This can lead to inconsistent
entries
configurations, especially for elements
that depend on limited hardware total
resources. Example with a large ACL 
• NX-OS 9.2(1) supports rollback-on-
error:
• A checkpoint is automatically created
before executing the first command.
• Upon hitting an error, NX-API automatically
rolls back to the checkpoint.
switch# sh ip access-lists myACL
IP access list myACL

1 permit udp 1.1.134.116/32 any
2 permit udp 1.1.12.89/32 any
3 permit udp 1.1.108.204/32 any
...
switch# sh ip access-lists myACL | wc lines

130
switch#© 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
switch# sh ip access-lists myACL
switch#
Get Started With Just Two Commands
• Ready-to-use Docker container with:
• Pre-built Python environment.
• NX-API libraries and apps.
[devops@server ~]$ docker run -it ndelecro/nx-os-programmability

Status: Downloaded newer image for docker.io/ndelecro/nx-os-
programmability:latest
root@a3d1f69d8067:~#
• https://hub.docker.com/r/ndelecro/nx-os-programmability/
• https://github.com/ndelecro/nx-os-programmability/blob/master/Dockerfile
Status: Downloaded newer image for docker.io/ndelecro/nx-os-programmability:latest
root@a3d1f69d8067:~# cd NX-API_CLI/VXLAN_BGP_EVPN/
root@a3d1f69d8067:~/NX-API_CLI/VXLAN_BGP_EVPN# ./1.Create_L2VNI.py vteps 42 42000 239.1.1.1 e1/41
root@a3d1f69d8067:~# cd NX-API_CLI/VXLAN_BGP_EVPN/
root@a3d1f69d8067:~/NX-API_CLI/VXLAN_BGP_EVPN# ./1.Create_L2VNI.py vteps 42 42000 239.1.1.1 e1/41
****** VTEP 93180-EX-1 ******
vlan 42
vn-segment 42000
int nve1
member vni 42000
mcast-group 239.1.1.1
suppress-arp
evpn
vni 42000 l2
rd auto
route-target import auto
route-target export auto
int e1/41
switchport access vlan 42
****** VTEP 93180-EX-2 ******

vlan 42
...
• NX-SDK
• NX-API
• Ansible
• SaltStack
Ansible
Benefits of Ansible
• No developer skills needed.
Management Server
• NX-OS modules abstract the CLI.
Ansible Controller • Can also re-use existing CLI
templates.
Inventory Modules
• Easy authentication, transport,
grouping of target devices.
Playbooks Config
• Idempotency.
• Parallelization.
Configure
• Advanced features:
• Variables • Events
Targets
• Conditionals • Loops
Management NX-API NX-API NETCONF / RESTCONF / gRPC
SSH SNMP
Server CLI REST YANG

SDK Apps Features

NX-OS Infra


VXLAN BGP EVPN Automation
[devops@server ~]$ cat vxlan.yml
---
- name: Create L2VNI
hosts: nxos_vteps
tasks:
- name: Create VLAN and map to to VNI
nxos_vlan:
vlan_id: 2200
mapped_vni: 20200
- name: Add L2VNI to Overlay

nxos_vxlan_vtep_vni:
interface: nve1
vni: 20200
...
Blue: Ansible keyword or module name

White: a value that you define © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
VXLAN BGP EVPN Automation
[devops@server ~]$ cat vxlan.yml
...
tasks:
- name: Create VLAN and map to to VNI
nxos_vlan:
vlan 2200
vlan_id: 2200 vn-segment 20200
mapped_vni: 20200
- name: Add L2VNI to Overlay interface nve1

nxos_vxlan_vtep_vni: no shutdown
interface: nve1 host-reachability protocol bgp
vni: 20200
member vni 20200
multicast_group: 239.239.239.100
suppress_arp: true suppress-arp
mcast-group 239.239.239.100
[devops@server ~]$ ansible-playbook vxlan.yml
PLAY [Create L2VNI] ************************************************************
TASK [Create VLAN and map to to VNI] *******************************************

ok: [93180-FX-2]
changed: [92160-1]
ok: [92160-2]
ok: [93180-EX-1]
changed: [93180-EX-2]
TASK [Add L2VNI to Overlay] ****************************************************

changed: [92160-1]
...
PLAY RECAP *********************************************************************

92160-1 : ok=5 changed=4 unreachable=0 failed=0
92160-2 : ok=5 changed=3 unreachable=0 failed=0
93180-EX-1 : ok=5 changed=3 unreachable=0 failed=0
93180-FX-2 : ok=5 changed=3 unreachable=0 failed=0
[devops@server ~]$ BRKDCN-2025 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 53
What’s the Cleanest Way to Handle This Error?
[devops@server ~]$ cat vxlan.yml Config prior to the playbook
... execution:
tasks:
- name: Create VLAN and map to to VNI interface nve1
nxos_vlan: no shutdown
vlan_id: 2200 host-reachability protocol bgp
mapped_vni: 20200 member vni 20200
admin_state: up suppress-arp
ingress-replication protocol bgp
interface: nve1
vni: 20200
suppress_arp: true
[devops@server ~]$ cat rollback.yml
...
Checkpoint and Rollback! tasks:
- name: Create checkpoint
nxos_rollback:
checkpoint_file: backup.cfg
- name: VXLAN config

block:
- name: Create VLAN and map to the VNI
nxos_vlan:
vlan_id: 2200
mapped_vni: 20200
admin_state: up
interface: nve1
vni: 20200
rescue:
- name: Rollback to checkpoint
nxos_rollback:
rollback_to: backup.cfg
[devops@server ~]$ ansible-playbook rollback.yml
TASK [Create checkpoint]
*************************************************************************************************
changed: [93180-FX-2]
TASK [Create VLAN and map to the VNI]

*************************************************************************************************
*************************************************************************************************

*************************************************************************************************
TASK [Add L2VNI to Overlay]

*************************************************************************************************
fatal: [93180-FX-2]: FAILED! => {"changed": false, "clierror": "Cannot associate a multicast group
or vrf to an ingress replication vni.\n\n", "code": "400", "msg": "CLI execution error", "output":
...
*************************************************************************************************

*************************************************************************************************
TASK [Add L2VNI to Overlay]

*************************************************************************************************
fatal: [93180-FX-2]: FAILED! => {"changed": false, "clierror": "Cannot associate a multicast group
or vrf to an ingress replication vni.\n\n", "code": "400", "msg": "CLI execution error", "output":
...
TASK [Rollback to checkpoint]

*************************************************************************************************
PLAY RECAP
*************************************************************************************************
[devops@server ~]$
Upgrade or Downgrade NX-OS at Scale
---
- name: Install NX-OS
hosts: my_switches
tasks:
- name: Enable scp-server feature
nxos_feature:
feature: scp-server
state: enabled
- name: Copy NX-OS image to the switch

nxos_file_copy:
local_file: /devops/img/nxos.7.0.3.I7.5a.bin
- name: Install NX-OS

nxos_install_os:
system_image_file: nxos.7.0.3.I7.5a.bin
register: install_state
- debug:
var: install_state BRKDCN-2025 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 60
[devops@server ~]$ ansible-playbook install_nxos.yml
PLAY [Install NX-OS] **************************************************************
TASK [Gathering Facts] ************************************************************

ok: [93180-EX-1]
TASK [Enable scp-server feature] **************************************************

TASK [Copy NX-OS image] ***********************************************************

ok: [93180-EX-1]
TASK [Install NX-OS]
************************************************************************************************
TASK [debug] ***********************************************************************************

ok: [93180-EX-1] => {
"install_state": {
"changed": true,
"failed": false,
"install_state": [
"Compatibility check is done:",
"Module bootable Impact Install-type Reason",
"------ -------- -------------- ------------ ------",
" 1 yes disruptive reset Incompatible image for ISSU",
"Images will be upgraded according to following table:",
"Module Image Running-Version(pri:alt) New-Version Upg-Required",
"------ ---------- ---------------------------------------- -------------------- ------------",
" 1 nxos 9.2(1) 7.0(3)I7(3) yes",
" 1 bios v07.64(05/17/2018):v07.45(12/04/2015) v07.61(04/06/2017) no",
"--------------------------------------",
"Module 1: Refreshing compact flash and upgrading bios/loader/bootrom."
]
}
}
PLAY RECAP *************************************************************************************

[devops@server ~]$
Apply a Patch Based on the NX-OS Version
---
- name: Patch
hosts: nxos_vteps
vars:
my_patch: nxos.CSCve91311_n9000.rpm
my_ver: 7.0(3)I6(1)
tasks:
- name: Get the NX-OS version
nxos_facts:
gather_subset: "!interfaces"
- debug:
var: ansible_net_version
- name: Apply OSPF patch

nxos_smu:
pkg: "{{ my_patch }}"
when: ansible_net_version == "{{ my_ver }}" Blue: Ansible keyword or module
Orange:
© 2019 Cisco and/or itsyour
affiliates. Allvariables
rights reserved. Cisco Public
Apply a Patch Based on the NX-OS Version
--- TASK [Get the NX-OS version] ***************
- name: Patch ok: [93180-FX-2]
hosts: nxos_vteps ok: [92160-1]
vars: ok: [93180-EX-1]
my_patch: nxos.CSCve91311_n9000.rpm
my_ver: 7.0(3)I6(1) TASK [debug] *******************************
ok: [93180-EX-1] => {
tasks: "ansible_net_version": "7.0(3)I6(1)"
- name: Get the NX-OS version }
nxos_facts: ok: [92160-1] => {
gather_subset: "!interfaces" "ansible_net_version": "7.0(3)I7(2)"
}
- debug: ok: [93180-FX-2] => {
var: ansible_net_version "ansible_net_version": "7.0(3)I7(3)"
}
nxos_smu: TASK [Apply patch] *************************
pkg: "{{ my_patch }}" skipping: [92160-1]
when: ansible_net_version == "{{ my_ver }}" skipping: [93180-FX-2]
If the Patch Was Applied, Display the OSPF State
tasks:
...
nxos_smu:
when: ansible_net_version == "{{ my_ver }}"
notify:
- Get OSPF neighbors
- Display OSPF neighbors
handlers:
- name: Get OSPF neighbors
nxos_command:
commands: ["show ip ospf neighbors"]
register: ospf_neighbors
- name: Display OSPF neighbors

debug:
var: ospf_neighbors Blue: Ansible keyword or module
Orange: your variables
Red:
© 2019 your
Cisco and/or handlers
its affiliates. All rights reserved. Cisco Public
If the Patch Was Applied, Display the OSPF State
tasks: TASK [Apply OSPF patch] ********************
... skipping: [92160-1]
- name: Apply OSPF patch skipping: [93180-FX-2]
nxos_smu: changed: [93180-EX-1]
when: ansible_net_version == "{{ my_ver }}" RUNNING HANDLER [Get OSPF neighbors] *******
notify: ok: [93180-EX-1]
- Get OSPF neighbors
- Display OSPF neighbors RUNNING HANDLER [Display OSPF neighbors] ***
ok: [93180-EX-1] => {
handlers: "ospf_neighbors": {
- name: Get OSPF neighbors ...
nxos_command: "addr": "10.0.0.2",
commands: ["show ip ospf neighbors"] "drstate": " -",
register: ospf_neighbors "intf": "Eth1/49",
"priority": "1",
- name: Display OSPF neighbors "rid": "100.100.100.100",
debug: "state": "FULL",
var: ospf_neighbors "uptime": "PT1M2S"
Challenge of Ansible Loops
---
- name: Create VLANs
hosts: nxos_vteps • How long do you think it
gather_facts: no takes to execute on one
tasks:
switch?
- name: Create VLANs •  12 minutes
nxos_vlan:
vlan_id: "{{ item.vlan_id }}" • Why?
loop:
- { vlan_id: 100 }
- { vlan_id: 101 }
- { vlan_id: 102 }
... 50 VLANs total
Source: https://www.ansible.com/blog/accelerate-ansible-networking-aggregate-resources
1. Connect via SSH or NX-API

2. Execute nxos_vlan module for VLAN 100
.
.
.
.
502. Disconnect SSH or NX-API
503. Display Playbook recap
 503 steps
Performance at Scale with Aggregation
Source: https://www.ansible.com/blog/accelerate-ansible-networking-aggregate-resources
1. Connect via SSH or NX-API

2. Execute nxos_vlan module
• Generate VLAN commands for entire set
• Execute in one task
3. Disconnect SSH or NX-API
4. Display Playbook recap
 4 steps
--- • 15 seconds
hosts: nxos_vteps • 98% improvement!
gather_facts: no
tasks:
nxos_vlan:
aggregate:
- { vlan_id: 100 }
- { vlan_id: 101 }
- { vlan_id: 102 }
... 50 VLANs total
https://github.com/ndelecro/nx-os-programmability/tree/master/Ansible/2.5
Get Started With Just Two Commands
Ready-to-use Docker container with Ansible installed and configured, and
NX-OS playbooks available:
root@a3d1f69d8067:~# ansible-playbook ~/Ansible/vxlan_nxapi.yml
PLAY [Create L2VNI]

*************************************************************************************************
TASK [Create VLAN and map to to VNI]

*************************************************************************************************
PLAY RECAP
*************************************************************************************************
root@a3d1f69d8067:~#
• NX-SDK
• NX-API
• Ansible
• SaltStack
SaltStack
SaltStack Overview
• Automation tool, comparable to Chef, Puppet and Ansible.
• Target devices can be servers and switches.
• Agent-based architecture, similar to Chef and Puppet.
• Agents are called minions.
• Master and minions communicate over a high-speed

ZeroMQ bus.
• Execution module: accomplish a specific task (like
configure NX-OS).
• Event-driven capabilities. The master listens to events
from the minions over the high-speed bus, and contains
the reaction logic.
Salt States (nxos.py)
Salt Execution Module (nxos.py)

Linux Server
Salt Master
High-speed bus
Salt Minion
Guest Shell or Docker
NX-API Nexus 9K
NX-OS CLI
[devops@server ~]$ salt 93180-EX-2 grains.get nxos
93180-EX-2:
----------
hardware:
----------
Device name:
93180-EX-2
bootflash:
7906304 kB
software:
----------
NXOS:
version 9.2(1)
[devops@server ~]$ salt 93180-EX-2 grains.get nxos:software:NXOS

93180-EX-2:
version 9.2(1)
[devops@server ~]$
NX-OS Execution Module
• NX-OS module for Salt: nxos
• Show commands: nxos.show
• Add, delete, and save config

commands, static or templatized:
• nxos.config
• nxos.delete_config
• nxos.save_running_config
[devops@server ~]$ salt 93180-EX-2 nxos.show 'show version’
93180-EX-2:
- Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (C) 2002-2018, Cisco and/or its affiliates.
All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under their
own licenses, such as open source. This software is provided "as
is," and unless otherwise stated, there is no warranty, express or
...
[devops@server ~]$ salt 93180-EX-2 nxos.show 'show version' raw_text=False
93180-EX-2:
|_
----------
TABLE_package_list:
----------
ROW_package_list:
----------
package_id:
----------
bios_cmpl_time:
05/17/2018
bios_ver_str:
07.64
bootflash_size:
7906304
chassis_id:
Nexus9000 93180YC-EX chassis
[devops@server ~]$ salt '93*' nxos.config commands="['vlan 42']"
93240-FX2-1:
COMMAND_LIST: vlan 42
---
+++
@@ -34,7 +34,7 @@
rmon event 4 description WARNING(4) owner PMON@WARNING
rmon event 5 description INFORMATION(5) owner PMON@INFO
-vlan 1
+vlan 1,42
vrf context management

ip route 0.0.0.0/0 10.60.0.254
93180-EX-2:
COMMAND_LIST: vlan 42
... © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
[devops@server ~]$ cat /srv/salt/vlans.j2
{% for vlan in vlans %}
vlan {{ vlan }}
{% endfor %}
[devops@server ~]$ salt 93180-EX-2 nxos.config \

> config_file=salt://vlans.j2 context="{'vlans': ['100, 110, 120’]}"
93180-EX-2:
COMMAND_LIST: vlan 100, 110, 120
---
+++
@@ -48,7 +48,7 @@
ip pim ssm range 232.0.0.0/8
ip igmp snooping vxlan
system vlan long-name
-vlan 1,20,42-46,666-667,2200-2202,3200-3201
+vlan 1,20,42-46,100,110,120,666-667,2200-2202,3200-3201
vlan 666
name L3VNI_VLAN_666_for_tenant-20000
vn-segment 20666
[devops@server ~]$ © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
States
• Reusable configuration templates.
• Similar to Ansible playbooks.
• Let’s apply the following state:
[devops@server ~]$ cat /srv/salt/nexus.sls

Create user nicolas:
nxos.user_present:
- name: Nicolas
- password: cisco
[devops@server ~]$
[devops@server ~]$ salt 93180-EX-2 state.apply nexus
93180-EX-2:
----------
ID: Create user Nicolas
Function: nxos.user_present
Name: Nicolas
Result: True
Comment: User set correctly
Started: 14:10:17.737023
Duration: 5490.00000022 ms
Changes:
----------
password:
----------
new:
COMMAND_LIST: username nicolas password 5 $5$TQ9LMz
---
+++
@@ -32,6 +32,7 @@
username admin password 5 $5$B24gk.2x$ role network-admin

+username nicolas password 5 $5$TQ9LMz role network-operator
ip domain-lookup
old:
Installation Steps of Salt Minion on Nexus 9K
Let’s Leverage Docker!
• From NX-OS, enter the switch Native Bash Shell

• In the switch Native Bash Shell:
• Enable Docker and start the pre-built container ndelecro/nxos-onbox-salt-minion
• Configure the Salt master DNS and key
• Start the minion
• On the master, accept the minion key
• The detailed steps are at https://github.com/ndelecro/nx-os-
programmability/wiki/NX-OS-Salt-Minion-Docker-Installation-Steps.
• Running a NX-OS version that doesn’t support Docker yet? Not a problem 
https://github.com/ndelecro/nx-os-programmability/wiki/NX-OS-Salt-
Minion-Guest-Shell-Installation-Steps
Installation Steps of Salt Master
Turn-Key Method
• The nx-os-programmability Docker image contains a turn-key Salt Master.
• It’s pre-installed, pre-configured, ready to use.
• It also contains sample NX-OS top files and state files.
• From any machine with the Docker engine, run:

bash# docker run --name=salt-master --hostname=salt-master -p 4505:4505 -p
4506:4506 -p 443:443 -it ndelecro/nx-os-programmability bash
• You’re now inside the container. Start the Salt Master:
root@338feef4a018:/# salt-master –d
• Validation:
root@338feef4a018:/# salt --version
salt 2018.3.3 (Oxygen)
root@338feef4a018:/#
• NX-SDK
• NX-API
• Ansible
• SaltStack
NETCONF, YANG,
OpenConfig, YDK
NX-OS OpenConfig Support
Core Feature Set for Multi-Vendor Solution
Model NX-OS 7.0(3)I7(5) NX-OS 9.2(2)
AAA 0.3.0
ACL 1.0.0
AFT (Abstract Forwarding Table, similar to
0.3.1
FIB)
BGP 2.1.0 (partial) 4.0.1
Interfaces 1.0.2 (partial) 2.0.0
ISIS 0.3.3
Local Routing 1.0.0 (partial) 1.0.1
MPLS 2.4.1
Network Instance (VRF) 0.8.1
OSPF 0.1.1
Packet Match AKA ACL 1.0.0
NX-OS OpenConfig Support
Core Feature Set for Multi-Vendor Solution
Model NX-OS 7.0(3)I7(5) NX-OS 9.2(2)
Platform including LC, port, transceiver 0.8.0
Policy Forwarding AKA PBR 0.2.0
Routing Policy: Prefix Lists and Route
2.0.1 2.0.1
Maps
Segment Routing 0.0.3
STP 0.2.0
System (Date & Time, NTP, DNS...) 0.3.0
VLAN 1.0.2 (partial) 1.0.2
Read all VRFs with OpenConfig
<get-config>
<source>
<running/>
</source>
<filter>
<network-instances xmlns="http://openconfig.net/yang/network-instance">
<network-instance/>
</network-instances>
</filter>
</get-config>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<data>
<network-instances xmlns="http://openconfig.net/yang/network-instance">
<network-instance>
<config>
<description/>
<enabled>true</enabled>
<name>default</name>
<type>L3VRF</type>
</config>
<name>default</name>
</network-instance>
<network-instance>
<config>
<description/>
<enabled>true</enabled>
<name>Testing1</name>
<type>L3VRF</type>
</config>
...
NX-OS Native YANG Support
For the Complete Feature-Set
• ACL • OSPF
• QoS • HSRP
• Segment Routing • Syslog
• VXLAN F&L and BGP EVPN • NTP
• ARP • Route Policy
• Interfaces • HSRP
• VLAN • L2 and L3 Tables
• IPv4 and IPv6 for interfaces • SNMP
• RBAC • MPLS
• Tunnels • Static Route
• VRRPv2 and v3 • Streaming Telemetry Configuration
Supported protocols for OpenConfig and Native models are NETCONF, RESTCONF, and gRPC.
How Do I Create and Transport Those YANG Payloads?
• Read the models definitions at

https://github.com/YangModels,
and derive the payload?
• Possible, but not easy.
• Let’s explore simpler options...
https://developer.cisco.com/site/cisco-nexus-nx-api-references
https://developer.cisco.com/site/cisco-nexus-nx-api-references
Ansible as a Generic NETCONF Engine
vxlan.j2 Jinja2 template vxlan_generic.yml playbook
<config> ---
<System xmlns="http://cisco.com/ns/..."> - name: VXLAN NETCONF GENERIC
<bd-items> hosts: netconf_vteps
<bd-items>
<BD-list> tasks:
- name: TEMPLATE
<fabEncap>vlan-{{vlan_id}}</fabEncap>
template:
<accEncap>vxlan-{{vxlan_id}}</accEncap>
src: vxlan.j2
<name>{{vlan_name}}</name> dest: vxlan.config
</BD-list> vars:
</bd-items> vlan_id: 42
</bd-items> vxlan_id: 90042
</System> vlan_name: ansible jinja
</config>
- name: VXLAN
netconf_config:
datastore: running
BRKDCN-2025 src:
© 2019 Cisco and/or vxlan.config
its affiliates. All rights reserved. Cisco Public 104
Beyond Payloads: Code APIs
• Let’s generate APIs that follow
exactly the YANG models
definitions.
• They will automatically create the
YANG payloads (edit-config).
• They will also automatically decode
the payloads received from the
switch (get-config).
• Let’s also have those APIs validate
the data we feed them, and the
return data from the switch.
• While we’re at it, let’s abstract the
communication to the switches too!
YANG Development Kit (YDK)
Telnet NX-API NX-API
SNMP
or CLI REST
Client
Client YDK
SSH Client
Management Server

SDK Apps Features

NX-OS Infra

Demo: VXLAN BGP EVPN
Automation on NX-OS
with YDK
Choosing an Automation
Strategy
100
90
80
70
60
50
40
30
20
10
0
Transport Abstraction Data Model Simplicity Customization Developer Skills Turn-Key
■ NX-API Script ■ Ansible NX-OS Modules ■ SaltStack with NX-OS Modules
■ Ansible NETCONF with ■ YDK with ■ DCNM

NX-OS / OpenConfig Models NX-OS / OpenConfig Models © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
100
90
80
70
60
50
40
30
20
10
0

100
90
80
70
60
50
40
30
20
10
0

100
90
80
70
60
50
40
30
20
10
0

100
90
80
70
60
50
40
30
20
10
0

• NX-SDK
• NX-API
• Ansible
• SaltStack
Monitoring NX-OS with
Streaming Telemetry
Telemetry Collector
Server
HTTP / HTTPS gRPC Nexus 9K

or or
UDP UDP
JSON Encoder GPB Encoder
NX-OS
NX-OS Telemetry Engine Telemetry CLI
Configuration
CLI Output Object YANG

switch# show running-config telemetry
telemetry
destination-group 1
ip address 10.60.0.96 port 5000 protocol HTTP encoding JSON
sensor-group 1
data-source NX-API
path "show mac address-table" depth 0
sensor-group 2
sys
data-source DME
path sys/intf/phys-[eth1/41]-dbgIfIn depth 0
path sys/acl/ipv4/name-CLEUR/seq-10 depth 0
bgp ospf
filter-condition gt(ipv4aclACE.packets,"10000")
path sys/bgp depth unbounded
inst inst
subscription 1
dst-grp 1
snsr-grp 1 sample—interval 5000
snsr-grp 2 sample-interval 30000 BRKDCN-2025 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 118
Streaming Telemetry of YANG Models
NX-OS 9.2(1)
switch# show running-config telemetry

telemetry
destination-group 1
ip address 10.60.0.96 port 5000 protocol HTTP encoding JSON
sensor-group 1
data-source YANG
path openconfig-bgp:bgp
path Cisco-NX-OS-device:System/eps-items
subscription 1
dst-grp 1
snsr-grp 1 sample—interval 5000
Choice of Telemetry Collector Options
10.60.0.110 - - [14/Dec/2018 10:07:12] "POST /network/Cisco-
• Do-It-Yourself
NX-OS-device%3ASystem%2Feps-items HTTP/1.0" 200 -
>>> URL : /network/Cisco-NX-OS-
device%3ASystem%2Feps-items
>>> TM-HTTP-VER : 1.0.0
• Simple Python receiver for JSON over HTTP

>>> TM-HTTP-CNT : 1
>>> Content-Type : application/json
>>> Content-Length : 3730
Path => Cisco-NX-OS-device:System/eps-items
http://cs.co/telemetry_receiver
node_id_str : 93180-EX-2
collection_id : 161
data_source : YANG
data : {
• Elasticsearch, Logstash, Kibana, InfluxDB, Grafana...

Get started:
https://hub.docker.com/r/dockercisco/telemetryreceiver
https://hub.docker.com/r/dockercisco/elklat
• Turn-key: Cisco Network Insights Resources

• DCNM or ACI
• Software + Hardware Telemetry
Conclusion
N3K N5K/N6K/7K N9K
Docker and
Yes No Yes
Kubernetes
NX-SDK Yes No Yes
NX-API CLI Yes Yes Yes
Ansible Yes Yes Yes
SaltStack Yes Yes Yes
YANG Yes (*) No Yes
YDK Yes (*) No Yes
Streaming
Yes (*) No Yes
Telemetry
(*) On models equipped with 8GB+ of memory.

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#BRKDCN-2025
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

BRKDCN 2025

Uploaded by

Copyright:

Available Formats

You might also like

BRKDCN 2025

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BRKDCN 2025

Uploaded by

Copyright:

Available Formats

BRKDCN-2025

• Every feature discussed in this

• Some features are also supported on

• Share with you the latest Open NX-OS

10.60.0.110 - - [14/Dec/2018 10:07:12] "POST /network/Cisco-

• Show code, apps and demos based on >>> URL

real-world use cases.

• Provide you with ways to get started in

• Available on all Nexus 9K models,

• Standard Docker engine with all the

• Monitoring agents • Automation agents (Chef, Puppet,

# Check the status

# Persist on reload of switch:

# Start an alpinelnx docker container:

[devops@server ~]$ kubectl apply –f replication.yaml

[devops@server ~]$ kubectl describe –f replication.yaml

• Python and C++ support. • Gain access to NX-OS CLI:

• Add our command handler callback for

• RIB APIs: • Gain access to NX-OS RIB:

• Streaming Telemetry support.

• Browse the object store on the switch itself:

• DME APIs: sys

• Get, add, remove objects.

change. dom dom

• Interface and MAC APIs.

Your NX-SDK Your NX-SDK Native NX-OS Native NX-OS Nexus 9K

Data Management Engine (DME)

BGP Data VLAN Data QoS Data

• Automatically detect ECMP bundles.

• Monitor the load of ECMP member links

• When high load i.e., hashing imbalance

• Pre-configure Host Interfaces (HIFs) before

• Display a custom syslog upon:

• Storm Control: shut down an interface victim of storm traffic.

• Pop quiz: how many lines of code does it take?

Your NX- Native NX-OS Nexus 9K

SNMP NETCONF / RESTCONF / gRPC

Data Management Engine (DME)

BGP Data VLAN Data QoS Data

IP access list myACL

switch# sh ip access-lists myACL | wc lines

[devops@server ~]$ docker run -it ndelecro/nx-os-programmability

****** VTEP 93180-EX-2 ******

Your NX- Native NX-OS Nexus 9K

SNMP NETCONF / RESTCONF / gRPC

Data Management Engine (DME)

BGP Data VLAN Data QoS Data

- name: Add L2VNI to Overlay

Blue: Ansible keyword or module name

- name: Add L2VNI to Overlay interface nve1

TASK [Create VLAN and map to to VNI] *******************************************

TASK [Add L2VNI to Overlay] ****************************************************

PLAY RECAP *********************************************************************

- name: VXLAN config

TASK [Create VLAN and map to the VNI]

TASK [Create VLAN and map to the VNI]

TASK [Add L2VNI to Overlay]

TASK [Create VLAN and map to the VNI]

VTEP 93180-EX-2