Week 6 of the DevNet Grind – Cisco Network Mgmt, IOS XE, Meraki, Difference in Data Planes, DNA Center, ACI, and NX-OS reviewed!

Network Automation and a list of the benefits it brings to Network Management

Automation saves business operational expense (OPEX) when tasks can be automated, and before diving into the systems that bring this Automation at scale, wanted to review some the basic benefits it brings to the Enterprise Network:

• Device Provisioning – Automation makes device provisioning much easier / faster / off-site storage (Cloud Controllers) / less human error / more efficient
• Device Software Management – Automating Software updates in the way that say Meraki does makes it easy to stay current, as it downloads and boots into its own firmware, and you the admin can schedule this manually or automatically when new firmware is available
• Compliance Checks – Automation methods allow for a unique ability to audit large networks for config errors and automatically patch issues found with regression tests
• Reporting – Automation decreases the manual effort to keep up documentation, as most platforms have a very easy automated config back solution, rather than copy / pasting running configs every time you make an update to a device
• Troubleshooting – Real time error checking makes network config analysis fast / simple
• Data Collection and Telemetry – Collection of network baseline traffic and telemetry is important to know when something is off (issues are arising), and makes them easier to identify as many Automated platforms have streaming data collection off the box

Cisco IOS XE Platforms

IOS is Internetwork Operating System just like an IOS Device, however XE indicates it is Next Gen “programmable” device platforms, which brings with it the benefits discussed in the YANG / NETCONF / RESTCONF post in terms of locking sessions / candidate configs / Etc.

One of its key benefits is that it doesn’t just run on top of Linux like IOS devices, but is like working in a Linux platform, even being able to jump into a Python IDE prompt on the device itself to write a script / config. with the Control Plane and Data Plane completely separate – The Control Plane stores / maps / signals devices as needed to move data and the Data Plane only contains the End User Data and that is it (a lot like the CCNP explanation I posted).

With IOS XE this is “Model Driven Programmability” with robust management / easy provisioning / device automation / RESTCONF or NETCONF to use as needed with YANG.

To enable Model-Drive Programmability on these Next Gen devices (CSR1000v IOS 16.x) the command is “netconf-yang” in user exec mode on the CLI via SSH (as NETCONF can also ride over port 22 SSH) to start it, whereas RESTCONF requires “ip http secure-server” then “restconf” on the CLI then it should start accepting programmatic input.

A review of the Management / Control / Data Planes in Automated Networks

In IOS devices it is easier to define as they are all pretty similar, however with different solutions like DNA Center / Meraki / SD-WAN / Etc it might get a bit less clear, but the fundamentals of where things operate at will define where the plane resides.

For example with Meraki it is “Dashboard” that is the Management Plane (as this is where devices are provisioned / managed from), the Data Plane is the Meraki Cloud as this is instructs the Meraki Appliances on how they must operate, and the Devices like MX / MS / MR are the Data Plane that are actually pushing the packets across the wire.

The concepts are the same, you just need to adjust the idea to the model of the solution, as I’ve seen different explanations of these Planes when speaking about different products but the underlying mechanisms are really the same just not defined on a single device but rather the Orchestration of entire networks / devices from a centralized controller.

Cisco DNA (Digital Network Architecture) Center

This is the foundational platform for “Intent-Based” networking, integrating network management / automation / assurance / monitoring / analytics / security all into one platform, using a Web-Based GUI dashboard and RESTful Intent API to programmatically talk to devices.

It also supports all 360 degree directional services (important for exam day):

• “Northbound” – The Intent API Provides specific capabilities of the DNA Center platform
• “Eastbound” – Servers for Asynchronous Event Notifications via Webhooks or Email
• “Southbound” – Multivendor SDKs are used to integrate non-Cisco devices into DNA Center
• “Westbound” – Integration / Assurance / IT Svc Mgmt (ITSM) like ServiceNow

The DNA Center Web-Based GUI features

Below are some of the main features used via the Web-Based GUI for DNA Center:

• Design – Design the network with intuitive workflows based on device placement
• Policy – Define / Manage Device and End User profile for highly secure access and network segmentation
• Provision – Deployment and Policy based automation to deliver services to the network based on priority and simplifies deployment, such as “zero touch device provisioning” and software management
• Assurance – Telemetry and notification for application perform and events in real time
• Platform – Information and documentation for DNA Center Intent API by supporting 3rd party applications to integrate them into DNA Center for data gathering / control, which means integration of third party applications into the Automation Workflow

Role-Based Access Control

DNA Center starts with Admins that can create “role-based” users that can log in and access only information needed to perform the job role, these roles include:

• SUPER-ADMIN-ROLE – Complete access to DNA Center
• NETWORK-ADMIN-ROLE – Create and Manage devices
• OBSERVER-ROLE – Read only access (GET only)

The DNA Center Appliance itself a Rack Mountable unit, while its components it manages could range from routers / switches / AP’s, to Virtualized / Software-Defined Network platforms (NFVIS Platforms).

Cisco DNA Center Intent Based API

This is the RESTful Intent Based API (not Web-Based GUI) that is used to communicate via HTTP Verbs (POST / GET / PUT) via JSON Structures to discover and control the network, and flows in a Hierarchical groups known as Domains / Sub-Domains as follows:

Domain – Purpose of Domain – Sub-Domains

• Authentication – User Authentication and session token generation – Authentication
• Know Your Network – Discover and Manage sites / topologies / devices / users / issues – Sites / Topology / Devices / Clients / Users / Issues
• Site Management – Enterprise network Provisioning / Onboarding / Deployment / Software Image Management – Site Design / Network Settings / Software Image / Management / Device Onboarding (PnP) / Configuration / Templates
• Connectivity – Manage and Configure SD-Access fabric / Wired / Non-Fabric wireless including SSID / Wireless Profiles / RF Profiles / APs – SDA / Non-Fabric Access / Wireless
• Operational Tasks – Command (CLI) / Task and Tag Mgmt / Network Discovery – Command Runner / Network Discovery / Path Trace / File / Task / Flag
• Policy – Applications / Application Sets / Application Policy Mgmt – Application Policy
• Event Management – Configure and manage event-based notifications to external handlers – Event Management

The API operates off the following DNA Center Life Cycle:

1. Early Field Trial (EFT)
2. Beta
3. Supported
4. Deprecated
5. Sunset Header
6. Retired

There is also a “Developer Toolkit” available via NETWORK-ADMIN and SUPER-ADMIN roles for additional features built in for beta “Try it” functionality.

All Intent API methods respond with a JSON structured content payload, HTTP return codes indicates whether the operation was successful or not, one point I would definitely know for exam day is that POST and PUT responses are executed Asycnhronously meaning that you might receive a 2xx status code back indicating success but it doesn’t mean the operation has been completed as of that response.

A Request that HAS been successfully executed should contain an “executionId” / “exectionstatusurl” / status “message” in its response.

There is more content than I could ever bother to type here, to review the full Cisco DNA Center Documentation to get a feel for different topics discussed, visit the link below:

https://www.cisco.com/c/en/us/support/cloud-systems-management/dna-center/series.html

https://developer.cisco.com/docs/dna-center/api/1-3-3-x/

^^^ The second is specific to API Verbiage for different commands / tasks.

Cisco ACI (Application Centric Infrastructure) aka Cobra SDKs!

I see the term “Cobra SDK” used in conjunction a lot with ACI in sample questions on Cisco webinars so I figured that was good to point out right in the header.

ACI runs the Nexus 9000 Switches and is the Cisco SDN Solution controlled via a Centralized Mgmt System which is called the APIC or Application Policy Infrastructure Controller, which manages and provides automation / policy / management / application / health monitoring for devices on the Fabric in a Programmatic way both to Physical or Virtual Appliances.

ACI allows for its entire Infrastructure to be opened for programmatic access rather than just feature sub-sets by providing access to the entire ACI Object Model, which represents the complete configuration and run-time state of every software and hardware component in the ACI Infrastructure. It provides access via REST API Interfaces making it easy to access and manipulate the config or run-time state, accepting and returning HTTP or HTTPS REST API Calls containing either JSON or XML Data Formats containing API Methods or Managed Object (MO) descriptions.

ACI is commonly used in Conjunction with Automation Tools like Ansible / Puppet / Chef to manage the Infrastructure in its entirety with applications in mind, while being able to integrates security / mgmt / policy / monitoring tools.

Tools used with ACI

Aside from Cobra which is ACI’s Python SDK toolkit, here is a list of Tools for ACI:

• Cobra – Python SDK for ACI
• Cisco ACI Toolkit – Less features than Cobra
• ARYA – APIC Rest Python Adapter, converts XML / JSON to Python code for consumption
• ACIrb – Ruby Based APIC REST API which uses Ruby language patterns
• CLI – Tradional Command Line Interface management
• Ansible modules for ACI / MSO (Multi-Site Orchestrator) – Modules for Ansible built specifically for the ACI Platform / Fabric

How REST APIs / Web Sockets can interact with ACI

Given that ACI is an entirely open model, REST APIs can use GET requests to examine data, and in turn use POST or PUTs to change the run-time config, and Web Sockets can also be used for real-time pushed bashed alerting / event notification.

A couple things I thought worth noting with importance for ACI on exam day:

POST and DELETE methods are considered “idempotent” meaning the operation can be repeated over and over without different results, while GET is “nullipotent” because it performs no operation (is read-only), so it never tries to perform a change.

Targets of REST API Calls fall under one of the following two types:

• DN (Distinguished Name) – identifies specific target object, mapping directly to the URL
• RN (Relative Name) – Names the Parent Object but not its siblings

ACI uses the same URI type as seen in the REST API post, with the transport type / host address / resources / query / etc, with Cobra SDK performing a “Subscription” to the ACI Tenant to monitor it for changes, so changes can be immediately made upon notification or events.

Cobra currently supports username / password and Cert based Authentication.

Cisco Meraki

Meraki is Cisco’s Cloud Based all-in-one / single-pane network management solution for enter Organizations, where the physical appliances are basically door stoppers unless “claimed” to a network and a license applied to allow it to operate – Then it will check into “Dashboard” for the Organization / Network it was assigned to.

It does Firewall (MX) / Switch (MS) / Wireless APs (MR) / Video Cameras (MV) in addition to other Enterprise features like MDM (Meraki Device Manager) which you enroll devices to the Meraki Network Dashboard and it can then push out policies / access / revoke access entirely to a company asset / get geo-location on the device / real time logging / automatic firmware updates / automatic failover if two WAN interfaces are configured.

Below I will go through my own home network to review some of the options, I only have a single network I for some reason named “Meraki-Wifi” so there is no over-arching Organization, however an Organization with a Network created for each individual site.

One amazing thing Meraki does incredibly well is Auto-VPN where the MX devices dynamically create IPSec VPN tunnels Automatically over one or Both WAN interfaces depending on how its configured, and has built in Change-Log / Real Time Traffic monitor / Packet Capture built in.

Below I will go through some screen shots of my own network to point out some of the amazing features of this networking solution, the only drawback being is if something goes wrong, you are at the mercy of Meraki Support as you cannot get into the CLI of these devices.

With that, a tour through the Single-Pane Meraki Dashboard:

The Network-Wide tab is the “General” settings for that particular Network in the org:

• Clients – Lists every device seen by the Meraki, even if its connected to a non-Meraki device
• Topology – Meraki builds a L2 and L3 Topology as it sees the network
• Packet Capture – Amazingly powerful tool that outputs in .pcap or shows the capture right in the packet capture output window to take a quick glance at events
• Event Log – All events logged on the network in real-time (or very close to it)
• Map & Floor Plans – Doesn’t fill in Dynamically but can create a floor mapping of where your devices are at inside your building for reference
• General – This is where you set things like SAML Auth, SNMP, Network Name, Timezone, Location and Scanning Analytics for APIs, POST URLs for APIs, API Integration, Firmware, Cisco Umbrella Integration, everything you can basically imagine!
• Administration – Where you set Admins with “Role based” that can be either Full Org Access, Read-Only, Full or RO access to specific networks, this is the page to configure new admins
• Alerts – Everything alerting / Webhook configuration
• Group Policies – To create Content Filtering / QoS / BW Limits / any kind of access control group to apply to certain users / devices on the network
• Users – Commonly used for Client VPN User setup, can also define user access control to your wifi on this page
• Add devices – A place to add devices specifically to this network, however I do that elsewhere (in the Org portion at the bottom which I will review) this is where you can add MX / MS / MR devices once claimed via “Inventory” to your Organization as a whole

• Appliance status – Get real time Uplink Statistics, IP SLAs, latency, packet loss, tools to perform tests on your MX device
• Security Center – This is where you will see Security Events depending on how AMP is setup in “Threat Protection” assuming your have an Enterprise Security license
• Route Table – The IP Route Table of both connected and static routes (I am not sure how much Dynamic routing is integrated into Meraki as of now)
• Addressing and VLANs – This is where you review your VLANs / SVI IPs / MX Interface Configuration to change Trunks by default allowing all VLANs to tailor to needs
• Site-to-Site VPN – This is where you can configure Auto-VPN, or non-Meraki Peer VPN
• Client VPN – This is where you configure your Client VPN settings that they will need to setup on their local VPN Adapter (unfortunately Meraki doesn’t use Anyconnect)
• Active Directory – Where you can define your Active Directory Server and a user to login for AD Authentication of Client VPN users
• SD-WAN and Traffic Shaping – This is an amazing tool and so easy to use, in this page you can configure flow preferences (if you want certain host IP’s or subnets based on source or destination to leave out WAN 1 or WAN 2, set Load-Balancing between both interfaces, set QoS for both Video and Voice or whatever needs priority in your network, BW limits either on the WAN interfaces itself or per-user limit (then use a group policy to allow some users to not be limited or define their IP’s in the QoS portion of the page), just tons of amazing stuff!
• Threat Protection – This is where you configure AMP if you have a Security License for Dashboard, and define what levels of protection you want from IDS to heavy duty IPS
• Access Control – This is where you can set certain types of access control like clicking through a splash page to “Accept terms of use” or full blown Sign-on Auth with RADIUS or LDAP
• Splash Page – This is where you would configure a splash page for Access Control
• Wireless Concentrator – This sets the policy of roaming allowed while connected to wireless being provided by the MX itself (if it has Wifi capabilities) and VPN Client users

• Switches – Get a graphical front panel of the switch / switch ports with different colors or icons that show if a port is encountering errors / down / blocked by STP / Green (in use), is fully interactive so you can click on a port on the front panel to get specific port details
• Switch Ports – This is where you get a list of all Switchport Configs (Trunk Access) / Descriptions / VLAN info / Configure Port Mirror / Configure Port-Channels / a good overview of all ports on all switches at a glance
• DHCP Servers and ARP – This shows what DHCP Servers have been seen / used, if any are blocked, and any ARP table that the switch contains (I’ve found this ARP Table surprisingly not informative in my time working with Meraki)
• Routing and DHCP – This is where you configure L3 Routing and ACL’s on the switch if you configure it to operate at Layer 3
• Access Policy – This is to configure Access Control on certain VLANs / perform Authentication to gain access / also used in MDM for Device Enrollment
• Port Schedules – You can configure a time that certain ports will be active during, and shut them off over certain periods of time, never used it but awesome feature
• Switch Settings – QoS policies / MTU Config / STP Config / Multicast config / Power Supply stuff
• Staged Upgrades – Show if there are any current firmware upgrades staged and when they will execute, or can configure them on this page (and another spot also in Org)

I won’t go through this list, but you can see real time heat maps of RF Spectrums / Wireless bands to determine which Wireless Channel may be best to use that has the least interference, setup Access Control, configure SSIDs, has a heatmap that phones don’t even need to connect to that will detect their wireless beacons being sent out just pinging the AP to see it is there and generate a heat map of which AP’s saw the most traffic throughout the entire day.

So if your a retail store, you can literally map out how people are commonly navigating your store, so you can put your promotional or featured items in a hot spot to get more attention, or possibly see more access than you would expect from an area that should not have a lot of activity on the flip side of that coin – So many cool settings!

• Overview – This shows a list of your networks, how many devices they have, device health, BW usage, and the columns can be edited to show just about any info you are looking for
• Change Log – You can see every change ever made by which admin at which time since this Organization was created, that comes in very handy in troubleshooting!
• Login Attempts – This shows admin login attempts, and can be a bit confusing if for example you have one admin account assigned to several Orgs like you are an MSP or consultant with multiple customers, this will show on every Org that you had logged in that the admin account / email is associated too (I’ve run into funny situations with that one)
• Location Analytics – Generally for Wireless, this will show the traffic that the device has seen whether it is connected or just got a signal / wireless probes from a device passing by
• Configuration Template – This can use other networks as “Templates” to add new networks to the Organization in dashboard, assuming they contain the same devices / architecture
• VPN Status – Status of Auto-VPN and Non-Meraki Peers, gives all VPN related info like what interfaces they are using and when they are torn down / rebuilt / if they are active (this is the same as under the Security Appliance tab)
• Firmware Upgrades – Shows which devices have available stable release candidate firmware for their network devices, can schedule an automated update overnight, or perform it manually on the spot
• Summary Report – From my interaction with this page, it is end user / device utilization data, including top BW hog sites and hosts, the different utilization throughout the day, which can help to establish an emergency maintenance window during production hours when changes from troubleshooting would have least user impact

I won’t go through the last column as they are all pretty self-explanatory, licensing to apply licenses to make your Meraki gear non-door stoppers, Inventory is used to “Claim” devices by serial # then assign them to a network, Administrators is where you setup Admin users and roles for them, settings is Org wide settings which contains Access Control (Authentication) / SNMP / Policy Enforcement (strong passwords, must change every x days) / Org name / Threat Grid Integration and Dashboard API Access (Both to Enable and a URL to go to API profile).

Some different API types and services to know about for Meraki:

• Dashboard API – Is RESTful service for device provisioning / mgmt / monitoring
• Webhook API – Provides real time network alerts on health or event logging
• Location Streaming API – HTTP Post Method providing Wifi and BlueTooth client Geo-Location info on clients (Heat Map)
• External Captive Portal (EXCAP) API – Enables Org to build out custom engagement models at Wifi Access Points
• MV Sense API – Combines REST APIs and realtime MQTT stream support oversight of physical space to produce a heat map of the busiest parts of a still frame camera stream

With that last item the MV Sense it uses a sort of “on demand” REST API for almost real time data capturing of the Camera Data, while also being called for historical data of recorded events on the camera, MQTT-based Protocols use a Publish / Subscribe connection between the client and server with the MV Sense being the Server and Cameras the Clients, MQTT APIs enable a real time feed of camera data along with light level reading (and heat maps).

EXCAP Portal are essentially user facing splash pages with terms of service policy, legal warnings, or if the data is being collected and used for any purposes and whether they agree to that to get onto your open wifi network.

API Format requests will look like “curl –request GET -L \” in the beginning line to retrieve data from the target Org or Network, where if info is being retrieved from the Organization you will not see “networks” keyword or Resource on the end of the API Call, whereas if the API is targets all Networks or a specific Network it will specify that info towards the end of the API URL / URI.

So Meraki is incredibly fun to work with, its simply and makes sense, though that lack of your total management of the device is more a management at scale with slim IT resources deployment or for mid-level Enterprise Cloud gear that generally works just fine.

Cisco NX-OS (Nexus Series Switches)

The Cisco Nexus series is meant to be used for Data Center Fabric, which can be managed in a similar way to IOS-XE like a Linux machine rather than just a network device running on top of Linux OS, and plays well with Automation Tools (Ansible / Puppet / Chef) / IOS-XE deployments / Programmatic Models with a REST API and capable of speaking RESTCONF and NETCONF via YANG Data Models in the respective Data Formats.

NX-OS Switch Architecture operates like a Native Linux Stack with all Physical and Logical interfaces mapping to the Linux Kernel to perform operational tasks, also utilizing VRFs and Linux Namespaces to allow for segregation / network isolation capabilities.

REST API for NX-OS service is provided using an NGINX web server!

Nexus switches are used both in Private Cloud Data Center to Service Providers, so it has no problem scaling to as large or small of a deployment as is needed, and provides all network services as a regular switch with L3 operations built in (no need to enable) to perform routing between VLANs (Inter-VLAN Routing) and natively using OSPF as its Dynamic Routing Protocol.

NX-OS runs individual Linux Containers (LXCs) directly on the hardware platform by providing it access to CentOS 7-based Guest Shell, supporting custom functionality to the device in a secure and isolated shell.

It can also use Telemetry services Ganglia, Splunk, Nagious with other NX-OS switches.

Being that NX-OS operates using individual LXC’s, to configure NETCONF or RESTCONF you must first enable bash-shell via “feature bash-shell” followed by either “feature restconf” or “feature netconf” to turn on the programmatic service for use in the LXC.

Given how robust NSO and SD-WAN is I will make that its own POST soon here!

After starting to discuss NSO and then looking at the depth of information, I think this post contains enough of Cisco Network Management for one chunk of reading, as NSO (Network Services Orchestrator) and SD-WAN are very much alike but with some profound differences as well in what they aim to achieve but how they achieve it is very close.

However, I will get that up ASAP to move onto Collaboration and Compute platforms which are thankfully fairly slim compared to the Security and Network Management info.

Getting close to wrapping up the theory and hitting the labbing 🙂 Until next time!