Practicing Responsible SSL Inspection in an SD-WAN Environment

One benefit driving enterprise SD-WAN adoption is improved branch connectivity to cloud applications via direct internet access (DIA). When performed securely, DIA cuts bandwidth costs and ensures a consistent user experience.

Looking at an SD-WAN fabric, WAN aggregation may seem outdated as headquarters and core locations no longer need to serve as fortified gateways to the internet. Despite these architectural changes, core locations can excel as aggregation points for more challenging security operations, such as Transport Layer Security (TLS) decryption, often called by its more common name, Secure Socket Layer (SSL) inspection.

Security remains a top concern across the WAN. Enterprises want to detect the latest malware threats, yet the latest research shows that 70% of malware attacks are estimated to be hidden in encrypted TLStraffic that network and security teams cannot see. With encrypted internet traffic increasing, SSL inspection has been promoted a solution for finding hidden malware, but this is misleading for a number of reasons.

To Decrypt or Not

Though some SD-WAN vendors may tout their SSL inspection capabilities—such as hardware acceleration or off-loading—as evidence of product superiority, indiscriminate decryption across the WAN is not a sound practice. Decrypting sensitive traffic can violate privacy and data laws, and establishing whitelist policies to avoid violations is time-consuming and, at best, educated guesswork. Furthermore, many enterprise teams do not have the compute resources for wholesale SSL inspection, forcing them to suffer performance degradation as traffic enters the WAN.

Cisco addressed this challenge by developing a proprietary process known as Encrypted Traffic Analytics(ETA). With ETA enabled, Cisco SD-WAN platforms, such as the Integrated and Aggregated Services Routers (ISR and ASR), as well as the Enterprise Network Compute System (ENCS) hosting virtual devices, are able to categorize malicious traffic without performing decryption. Enabling ETA allows your SD-WAN fabric more precise network policies, where any traffic flagged as questionable can then be backhauled to core locations for responsible decryption.

This is a unique process we call SSL Aggregation.

Reasons to adopt SSL Aggregation

While Cisco SD-WAN enables industry-leading, zero-touch branch security capabilities, such as stateful firewalling, URL filtering, DNS monitoring, and Snort IPS, it is recommended to backhaul any traffic ETA flags as questionable to core locations for three main reasons:

◈ Greater physical space at core locations allows for more robust security layering, including products that are different from, or go beyond, what’s available through SD-WAN. A next-generation firewall (NGFW) with SSL Inspection, next-generation anti-virus (NGAV) that can detect fileless malware, or SIEM technology can help to remediate and log vulnerabilities after the malicious traffic is decrypted for inspection.

◈ Many enterprises manage thousands of branch office locations in their SD-WAN fabric. Even if SSL inspection capabilities exist at branch and remote office locations, the complexity of such data could overwhelm network and security teams. By consolidating malicious data flows into fewer ingress points, security management is simplified.

◈ Metadata created in conjunction with ETA can alert to zero-day threats that evade threat intelligence. Sending the flagged traffic to secure core locations is the safest practice when aiming to retain and utilizing data.

Given their superiority as secure hubs to isolate and examine malicious traffic, core locations make effective aggregation points for practicing responsible SSL inspection in an SD-WAN environment. Architecting this process is simple with Cisco.

Architecting SSL Aggregation

Combined with a Cisco Stealthwatch license, Cisco routing and compute platforms become ETA intelligent, able to identify potential hazards in encrypted traffic. The following Cisco platforms are recommended in a standard SSL Aggregation architecture:

◈ At the Branch: Deploying a 1000 or 4000 Series Integrated Services Router (ISR 1000; ISR 4000), or a 5000 Series Enterprise Network Compute System (ENCS 5000) will allow your branch locations to feed key telemetry data into Stealthwatch, enabling ETA across the SD-WAN fabric.

◈ Core/Colo/Campus/HQ: Because these core locations will receive high volumes of aggregated traffic, deploying 1000 Series Aggregated Services Router (ASR 1000) is recommended to handle increased flows. A Cisco Firepower Threat Defense (FTD) Next-Generation Firewall (NGFW) can decrypt the malicious traffic at the core and detect the threat.

Continue reading

Digital Transformation: Lesson’s learned at Cisco’s Media and Entertainment Industry Roundtable

Recently I had the great opportunity to host and moderate Cisco’s most recent Media Roundtable in Barcelona, Spain in conjunction with Cisco Live EMEAR with over 30 attendees.  During this event we had representation from some of the leading European Media organizations and partners including the likes of the BBC, Sony, France Television, SIC, Telefonica, Videlio, TF1, Dorna, Arqiva, Radio France, and Talpa TV along with our team at Cisco in attendance.  At this session we started to uncover how IP is transforming the Media Supply Chain in ways that are affecting their business in three areas:  Business Transformation, Technology Transformation and Operational Transformation or collectively what we at Cisco call “Digital Transformation”.  Let me dig into some of that discussion and some insights I gathered.

To set some context to the discussion we focused on the initial entry into the Media Supply Chain by focusing on the SDI to IP Transition or what many think of as the area of the Media Supply Chain focused on the live or near live acquisition of content.  This is an area that has had lots of visibility over the past two years with the introduction of new industry standards and trade groups, new technology solutions, new facilities being built, and new ways of thinking all while the needs of the staff to operate and execute this are changing dramatically.

Business transformation:

The key theme expressed during the discussion was that these media organizations are thinking about flexibility and use cases for manipulating the content that they now will have at their hands in far greater ways than ever before in the Media & Entertainment industry.  Some shared feedback that they were hyper focused on how IP would allow for new channels or digital channels for distribution and the revenue models to support that similar to how Canal + explains it in this video.  There was also interest and opinions in the role of the industry standards bodies in terms of how they are incorporating formats and whether those apply or not to their real life situations.  Some interesting debates on that specific topic for sure!  Some discussed how IP could offer flexibility to their environments and impact staffing, facilities and such.  Regardless it was clear that the move to IP creates some opportunities and goals that many are still trying to uncover.

Technology transformation:

Much of the discussion was around how to monitor and operate an IP Fabric environment.  Monitoring, flows, security and automation all bubbled up during the discussion but as we progressed the discussion we drilled into how this technology transformation was forcing the need for full interoperability between the Media and Broadcast Ecosystem Partners and folks like Cisco who provide the network and security aspects of these systems and innovation needed.  This “open interop” and “expanded partner ecosystem” has proven to be a hallmark of our strategy within Cisco’s Media and Entertainment strategy and this roundtable reinforced that direction.  The key now is to see how the industry keeps up and evolves to meet the demands of the content providers.

Operational Transformation:

This was an unexpected area of discussion, in which many of the customers and partners shared with us the challenges they have around workforce needs, training, and skilled labor needed by their own staff as well as the staffs of the ecosystem partners and systems integrators. It was clear that more awareness to training programs such as Cisco’s IP Fabric for Media basic and advanced training are needed and desired by the market.  We also shared that Cisco is working hard to “industrialize” the media ecosystem by creating programs and incentives to create consistent delivery partners of these systems through the IP Fabric for Media Partner Authorization Program. Here partners have a way to distinguish themselves as a trusted advisor to deliver these systems by investing in labs, training and ecosystem interoperability and thus Cisco’s ability to recommend them to the market.  Partners like Diversified Systems and WWT have already received their badge for this distinction but it was clear that we need to get more partners around the world to leverage this type of program to ensure successful project delivery.

In all, it was clear that transitioning to IP is top of mind for Media organizations due to the abundance of benefits it can bring however this transition also brings many concerns therefore there is a need to work together with the right partners and systems integrators to make the transition more seamless and effective.

Continue reading

Taking the Full Power of Hyperconverged Infrastructure to the Edge with HyperFlex Anywhere

We at Cisco have been on a mission; a mission to create the design patterns for the next generation of datacenters and private clouds. These design patterns are simpler than anything seen before, more performant than anything out there, and include the enterprise-class resiliency that our customers can count on.

Cisco shook up the server industry in 2009 with an architecture that extracted the personality of both server and fabric away from the metal, and codified it into policy. A few years later, we led the transition to converged infrastructure stacks—a space we still lead in. In 2016, we realized that Hyperconverged Infrastructure (HCI) could be built in a much more elegant manner than was available at that time. We codesigned hardware, software, networking, and management, creating a deeply engineered system with a superior architecture. We then introduced HyperFlex 2.0 in 2017, with a focus on application performance, and beat the competition in independent testing. In 2018, we released version 3.0 of HyperFlex, with support for multiple hypervisors, multiple container frameworks, and integrations that bridge to a multicloud world.

Today at Cisco Live Barcelona, I am happy to report that we are announcing HyperFlex 4.0—which extends Cisco’s HyperFlex platform from the core to the edge. HyperFlex 4.0 is a truly unique and innovative platform engineered to meet the requirements for deploying HCI in edge environments at a global scale.

Data Center Anywhere – There’s Nothing Centered about the Data Center Anymore

Every cloud or data center is built for one reason – to run applications. However, today’s applications are increasingly diverse and distributed. They generate data in disparate locations and consume it from disparate locations. To further the point, it is estimated that by 2022, 50% of enterprise-generated data will be created and processed outside the traditional, centralized data center or cloud[1]. As data pools outside the traditional datacenter, datacenters themselves must follow the data to branch, remote, and edge locations.

Our latest HyperFlex offering is designed with this new reality in mind, delivering an elastic datacenter-in-a-box to wherever the data resides, be it at the core or at the edge.

HyperFlex Anywhere – Simplifying the Branch Deployment

Deploying HCI to multiple sites at a state-wide, national or global scale can be a complex task. Conventional offerings require staging in a central location, sending trucks from there to each site, moving IT teams from location to location, and manual installs. This process can be fraught with problems. Errors can get introduced due to fat fingering. Edge sites can get stale before the entire footprint is even installed. And the entire process can be very time consuming. HyperFlex with Cisco Intersight revolutionizes this process. HyperFlex Edge nodes ship ready to deploy directly from the factory to the edge sites along with connectors to Cisco Intersight in the cloud. This allows us to leverage the power and reach of the Intersight cloud to provide a fully automated, zero touch installation of the HyperFlex Edge clusters.

We can now deliver deployment and lifecycle management benefits at scale; and deliver this remotely from the cloud. In addition to this, HyperFlex Edge and Intersight also allows our ROBO and Edge customers to:

◈ deploy a single and simplified hyperconverged architecture across their core, hybrid cloud, and edge – simplifying operations

◈ meet aggressive cost envelopes for infrastructure deployment at scale for edge and branch locations

◈ deploy clusters as small as 2-nodes (and up to 4 nodes) – a form factor that fits the needs of edge sites

◈ drive data resiliency without the expense (through our industry leading innovations around an invisible cloud-based witness resident in Intersight)

◈ simplify operations through centralized lifecycle management and actionable intelligence from Intersight.

In addition to the Intersight Cloud for Infrastucture management, we are also now integrated with Citrix Cloud Services. This enables customers to quickly and easily provision hundreds and thousands of virtual desktops and virtual applications from anywhere using Citrix cloud.

HyperFlex Anywhere – Performance without Compromise

The second key theme in today’s HyperFlex announcement is all about performance—one of our key differentiators and an area where Cisco will continue to lead. Although some of our competitors talk down the importance of performance because it is the Achilles Heel of their solution, we at Cisco take the opposite approach. We believe that performance matters and is key to enabling mission critical applications and minimizing total customer spend.

The reason is simple. HCI has now matured to the point where it runs more and more of a company’s critical business applications. Poor HCI performance can impact customer experience, team effectiveness, and ultimately, a company’s bottom line. On the other hand, a high Performance HCI solution like HyperFlex can not only reduce these risks but also have a significant impact on TCO, both in terms of cost saving and cost avoidance for customers. When you can do more work with less resources, it means you need less hardware, less associated software licenses, and even more important, less operation overhead. These savings can add up quickly.

Yes, performance matters. And that’s why our latest HyperFlex release ups the game on performance yet again by utilizing Intel®Optane™caching and all NVMe capacity drives. We worked closely with Intel to develop the HX220c M5 All NVMe nodes and were the first to market with a fully engineered all NVMe HCI system that incorporates full reliability, availability, and serviceability (RAS) functionality. This includes hot plug capabilities to enable enterprise-grade All-NVMe systems for our customers’ business critical applications.

We’ve also added a new hardware offload engine to the latest release, called the HyperFlex Acceleration Engine. This engine is an optional add-on PCIe card with an onboard FPGA, and gives our customers the ability to offload processing from the CPU, thereby freeing up those cycles for actual application workloads. In addition, the hardware acceleration provides higher performance, further extending our lead in this area and maximizing economic value for our customers.

And finally, along with all the other new features mentioned above, this release delivers further enhancements for cloud native applications with support for RedHat Openshift Container Platform as well as support for the Kubernetes Container Storage Interface (CSI).

Our Mission Continues

HyperFlex Anywhere enables Cisco customers to extend the simplicity of hyperconvergence from the core to the edge, to address a multitude of workloads and use cases. Our new HyperFlex 4.0 release and Intersight innovations, are engineered to meet the unique requirements for deploying hyperconverged infrastructure in edge and ROBO environments, at a global scale, and with superior performance.

We are proud to have been recognized in 2018 by both Forrester and Gartner as a leader in the hyperconverged infrastructure space and look forward to continuing our mission of providing customers with the innovations they need to accelerate their digital transformation.

Continue reading

Security in Utilities: an architectural approach for partners.

When we talk about Utilities, we usually refer mainly to the companies that supply electricity to business and residential consumers. However, there are several other types of Utilities including Water, Gas and Waste Management companies just to name a few. All of them face the same types of security threats, in the past few years there have been a number of incidents, for example public warning systems have been hacked and turned on in the middle of the night. There have also been attacks on the systems that control gas pipelines shutting down the gas flow for several hours.

Many of these attacks have happened not because of the actual lack of IT security measures or precautions, but in my cases due to organizational failures, whereby security data has been released to a third-party contractor without taking the necessary data protection procedures to avoid these incidents from happening.

In order to prevent security incidents from happening companies have to evolve their security approach to a phased security architecture:

◈ First Phase: modernize the connectivity of the transmission and distribution systems, including zone segmentation, controlled conduits and following standards such as ISA -95,99 / IEC 62443 / NERC /NIST.

◈ Second Phase: providing visibility of the data that is going through the equipment and systems all the way to the control area. This requires Application Control and Threat Control.

◈ Third Phase: convergence of security policies across all the different layers, including policy driven responses and deeper vision and control.

This phased security architectural approach can be used by partners across different types of Utilities. The most important thing to highlight is that partners should provide their customers with a consistent risk assessment followed by an architecture that addresses the potential gaps discovered through this assessment.

There are some use case themes that partners can discuss with their customers to address the different types of potential vulnerabilities their industrial infrastructure might have, including:

◈ Secure Connectivity: what devices can connect to what control systems; what type of communications can happen between different systems.

◈ Secure Remote Access: what are the access control measures, how can secure access be provided.

◈ Threat Control: what devices are vulnerable; how can you protect any vulnerable assets.

◈ Safe Environment: what type of protection is being provided in the networking infrastructure and what type of protection is being provided on the devices themselves.

In order to address the security requirements of all different types of Utilities we now have Cisco IoT Threat Defense which converges a security architecture and services to help industrial companies defend their IoT devices and keep their business running.

The main idea is to look at the individual environments that need some form of Cybersecurity, then mapping them to the products that Cisco partners can deliver by using the Cisco Validated Designs to define how to bring a particular solution forward.

There are four different areas that we focus on: Segmented Access Control for both IT and OT environments; Visibility and Analysis of potentially dangerous behavior to/from IoT devices; Secure Access into the OT network; and finally, Professional Security Services to assess the baseline risk, manage OT environments and perform incident response.

Continue reading

Improved performance and pay-as-you-go in Microsoft Azure

According to a recent IDC survey 85% of organizations are evaluating or using the public cloud1. As customers begin deploying workloads in the public cloud having a high-performing solution that allows them to securely extend their on-premises network to the cloud is critical. The Cisco CSR 1000V is a full-featured IOS-XE router that provides a secure way to connect your public cloud deployment to your on-premises network.

We are constantly working with our cloud partners to deliver new features and improved scale and performance. The latest software release for CSR 1000V (IOS-XE 16.10.1) delivers a number of significant enhancements for CSR 1000V on Microsoft Azure.

First, the release adds support for Microsoft Accelerated Networking which will enable customers to achieve 4x the throughput of the current CSR 1000V software release. Also, CSR 1000V will be launching support for customers to leverage pay-as-you-go, allowing for hourly consumption of the CSR. All of these improvements mean customers will be able to leverage better scale and performance for the CSR in Microsoft Azure.

Improved performance with Accelerated Networking

Cisco is adding support for Microsoft Accelerated Networking in the IOS-XE 16.10.1 software release for the CSR 1000V. By leveraging Accelerated Networking CSR 1000V is able to achieve up to a 4x increase in throughput performance across the existing instance types.

Figure 1 – Image from Microsoft Azure Documentation on Accelerate Networking

With accelerated networking, network traffic arrives at the VM’s network interface (NIC), and then is forwarded directly to the VM by-passing the host and the virtual switch. By allowing the CSR 1000V direct access to the network interface (NIC) Cisco and Microsoft are able to achieve significant improvements in the maximum throughput of the virtual router.

Azure Pay-as-you-Go

This new release for CSR 1000V also marks the launch of a new way to consume CSR 1000V on Azure. Customers will now be able to launch an hourly pay-as-you-go instance of CSR 1000V from the Azure Marketplace. With hourly pay-as-you-go, users can spin up CSR 1000V and consume it for a defined period of time based on their needs. When they are finished they can spin it down and only pay for the length of time they used it instead of being locked into an annual or multi-year contract. This pay-as-you-go instance of CSR 1000V will support all of the existing deployment models that are available today for customers who choose the bring-your-own-license consumption model for CSR 1000V.

Smart Licensing Only

In this release CSR 1000V will support only Smart Licensing. In previous release the CSR 1000V also supported classic ePAK licensing. Going forward all future releases of software for CSR 1000V will support only Smart Licensing which greatly simplifies licensing for the customer and provides greater flexibility and visibility to the licenses they own. Customers can use the Cisco Smart Software Manager (CSSM) to view all of the smart licenses they own in one place. For customers who have classic ePAK licenses they should convert their classic license to a smart licenses using the Licenses Registration Portal prior to upgrading to the 16.10.1 release.

This video provides step-by-step details on how to convert your existing classic ePAK licenses to a smart license.

Continue reading

The Legacy Continues with a Modern Classic

With the ISR 900 Series, Cisco continues a 26 year pedigree.

1993 was a much simpler time. A gallon of gas cost $1.16. The Space Shuttle was still flying. Beanie Babies were launched. Intel introduced the Pentium processor to power Windows 3.1. Jurassic Park and Mrs. Doubtfire were leading the box office while Snoop Dogg and Rage Against the Machine had breakout hits. Is this making anyone else feel nostalgic or just old?

1993 was also the year that Cisco introduced something that would forever change the landscape of networking in remote offices – the Cisco 2500 Series. For the first time there was a compact affordable Enterprise router with a huge spectrum of available interfaces and features to hammer just about any networking nail. The 2500 was so reliable that they can still be found in offices and data centers around the world more than a quarter century after being introduced. (I confess that I still use several 2511-RJ as terminal servers.)

Capability with Simplicity

So, what made the Cisco 2500 so great and how does that relate to a router being introduced in 2019? The answer is simple – literally. Simplicity with capability in the form of features and interfaces. The 2500 was never the fastest router in the market, but the flexibility and reliability made it a trusted friend for IT staff. With literally thousands of features and any interface type you were likely, or even unlikely, to run into, the 2500 could do it all.

That initial success led to the Cisco 2600 and 3600 Series which would morph into the first generation of Integrated Services Routers followed by the ISR G2 and 800 Series routers all running the same Cisco IOS® operating system. That’s a direct unbroken line of platforms running the same operating system since the earliest Cisco Routers, while adding new features and hardening the whole time. There just isn’t another piece of software with that pedigree anywhere.

Modern Hardware for a New Take on a Classic

The ISR 900 Series builds on that solid foundation with rock-solid 21st century hardware. The Cisco 900 Series is a silent, fan-less chassis designed to fit into any office. With that comes the interfaces you need today including LTE (available soon), ADSL/VDSL, Gigabit Ethernet WAN and switching. Modern components bring Cisco IOS performance on par with current branch routers including high performance encrypted VPN and firewall. Thousands of features you expect from a Cisco Branch Router, including some the 2500 never dreamed of, are built in such as MPLS, IPSLA, AVC, PfR and more with performance that’s more than 100 times what the 2500 could dream of.

Just One More Thing

There’s also one more throwback to classic small branch routers you might notice in the new Cisco 900 Series ISR and that’s the internal power supply. The Cisco 921 & 931 ISRs do away with the external power supply “brick” common to branch office devices and brings the power supply inside the router which can really clean up a cluttered branch environment.  Getting the power supply inside a passively cooled chassis with a wide temperature range is a big engineering deal. Yes, I really did just geek out over a power supply.

The Cisco 900 Series is a modern classic. It complements other members of the ISR portfolio, such as the ISR 1000 Series and ISR 4000 Series, while providing an easy migration path for Cisco 800 Series users. It isn’t the fastest or flashiest member of the ISR family. What it is is a solid, reliable performer with the features you need to sort out the most complex of network nightmares. Isn’t that what most IT professionals really want when the business is on the line?

This is just a teaser for what you can expect from the Cisco ISR 900 Series. Head on over to the Cisco ISR 900 Series page, cisco.com/go/isr900, for all the details.

Continue reading

Cisco DNA Center Network Automation with Template Programmer API – Part 1

Using APIs to apply templates to network devices

Cisco DNA center provides Day0 to Day-N support for network device automation.

This blog looks at one aspect of automation, the template programmer. Specifically, it covers the API’s used to apply templates to network devices.

Template programmer uses the velocity templating language for templates. The templates are created via the template editor and are applied via the User Interface or programmatically via the API.

This initial blog is going to cover the basics of finding templates, getting a specific version and applying a template to a device. To better illustrate how the API calls can be used in a practical manner, I am going to use a small python script published on github.

I am going to use a common (practical example) template of changing the vlan assigned to an interface on a switch. The template will take two variables:

◈ An interface name (e.g. gig1/0/20)
◈ A vlan number (e.g. 20)

Interaction with PnP Day0

For those familiar with this blog series, I have covered day0 configuration with Network PnP and also some basic velocity examples.

Day-0 templates are applied only when the device first contacts the controller and is onboarded to the network. Depending on your operational model, the day0 configuration might be quite small (just enough to establish secure connectivity) and day-N templates are used to apply ongoing configuration changes.

Step 1 – Listing Templates

The first step is to find the templates available on the Cisco DNA Center.

If you downloaded the example script, you can just run it with no arguments to see a list of templates.

(in order to run this script you will need to either edit the dnac_config.py file, or set the appropriate environment variables to customize your DNA Center and loging credentials – as outlined in the README). The template of interest is called “Adam/int-vlan” .

The API call is shown below. When the script is run without any argumnets, it prints the names of all templates. The first part of the name is the template project. In this case “Adam”. A project is just a folder to group templates.

$ ./template.py
Available Templates:
https://dnac:443/dna/intent/api/v1/template-programmer/template
  Adam/acl
  Adam/binding
  Adam/int-vlan
  Adam/interface-des
  DB/prefix
  Onboarding Configuration/9300
  Onboarding Configuration/advanced
  Onboarding Configuration/basic
  Onboarding Configuration/encs-9k
  Production/base
  Production/comp1
  Production/interfaces

Step 2– Getting the latest version

To get more details on a particular template, the script can be run with the –template <template-name> option. The latest version of the template (Version: 10) is selected.

The TemplateId is then used to return the body of this version of the template.

The body is quite simple, applying an access vlan to the given switch port. This is shown in green.

The script also requires two parameters ({“vlan”:””,”interface”:””})

$ ./template.py --template Adam/int-vlan
Looking for: Adam/int-vlan
https://dnac:443/dna/intent/api/v1/template-programmer/template
TemplateId: 610a718c-0a71-484b-a632-a79b64192cb7 Version: 11

https://dnac:443/dna/intent/api/v1/template-programmer/template/610a718c-0a71-484b-a632-a79b64192cb7
Showing Template Body:
interface $interface
  switchport access vlan $vlan

Required Parameters for template body: {"vlan":"","interface":""}

Bindings []

Step 3– Applying the template

The script can be executed with a device (ip address) and params provided. Note the params are in single quote to avoid shell issues.

$ /template.py --template Adam/int-vlan --device 10.10.50.2 --params '{"vlan":"20","interface":"gig1/0/20"}'
Looking for: Adam/int-vlan
https://dnac:443/dna/intent/api/v1/template-programmer/template
TemplateId: 610a718c-0a71-484b-a632-a79b64192cb7 Version: 11

https://dnac:443/dna/intent/api/v1/template-programmer/template/610a718c-0a71-484b-a632-a79b64192cb7
Showing Template Body:
interface $interface
  switchport access vlan $vlan

Required Parameters for template body: {"interface":"","vlan":""}

Bindings []

Up to this point, the output is the same as before. The payload for applying the template is below. Some notes:

◈ The targetInfo can be a list, which means multiple devices can be provisioned at the same time.
◈ Each target has its own set of parameters.
◈ The target device can be specified in multiple ways. In this example “MANAGED_DEVICE_IP” is the type, and the IP of the device is 10,.10.50.2. UUID is also supported.
◈ The templateId is also required.

{'targetInfo': [{'params': {u'interface': u'gig1/0/20', u'vlan': u'20'},
                'type': 'MANAGED_DEVICE_IP',
                'id': '10.10.50.2'}],
'forcePushTemplate': False,
'templateId': u'610a718c-0a71-484b-a632-a79b64192cb7'}

The POST call to https://dnac:443/dna/intent/api/v1/template-programmer/template/deploy returns a task, which contains a deploymentId which needs to be polled for completion.

Executing template on:10.10.50.2, with Params:{"vlan":"20","interface":"gig1/0/20"}
payload {'targetInfo': [{'params': {u'interface': u'gig1/0/20', u'vlan': u'20'}, 'type': 'MANAGED_DEVICE_IP', 'id': '10.10.50.2'}], 'forcePushTemplate': False, 'templateId': u'610a718c-0a71-484b-a632-a79b64192cb7'}
https://dnac:443/dna/intent/api/v1/template-programmer/template/deploy
Response {u'duration': u'0 seconds', u'deploymentId': u'Deployment of Template: 610a718c-0a71-484b-a632-a79b64192cb7.ApplicableTargets: [10.10.50.2]Template Deployemnt Id: 41ac69b9-8f2b-43a5-bb4b-622936f0f244', u'endTime': u'', u'startTime': u''}

The deploymentId status needs to be polled until the deployment is competed.

waiting for deploymentId 41ac69b9-8f2b-43a5-bb4b-622936f0f244
https://dnac:443/api/v1/template-programmer/template/deploy/status/41ac69b9-8f2b-43a5-bb4b-622936f0f244
{u'status': u'INIT', u'templateName': u'int-vlan', u'projectName': u'Adam', u'devices': [{u'status': u'IN_PROGRESS', u'name': u'', u'detailedStatusMessage': None, u'deviceId': u'e05075e8-eb5b-42f5-9f60-d56380702655', u'startTime': u'04:33:56 15/01/2019', u'duration': u'0 minutes 0 seconds', u'endTime': u'', u'ipAddress': u'e05075e8-eb5b-42f5-9f60-d56380702655'}], u'deploymentId': u'41ac69b9-8f2b-43a5-bb4b-622936f0f244', u'startTime': u'', u'duration': u'0 seconds', u'endTime': u'', u'templateVersion': u'11'}
Task=41ac69b9-8f2b-43a5-bb4b-622936f0f244 has not completed yet. Sleeping 2 seconds...
https://dnac:443/api/v1/template-programmer/template/deploy/status/41ac69b9-8f2b-43a5-bb4b-622936f0f244
{u'status': u'SUCCESS', u'templateName': u'int-vlan', u'projectName': u'Adam', u'devices': [{u'status': u'SUCCESS', u'name': u'', u'detailedStatusMessage': u'Provisioning success for template int-vlan', u'deviceId': u'e05075e8-eb5b-42f5-9f60-d56380702655', u'startTime': u'04:33:56 15/01/2019', u'duration': u'0 minutes 2 seconds', u'endTime': u'', u'ipAddress': u'e05075e8-eb5b-42f5-9f60-d56380702655'}], u'deploymentId': u'41ac69b9-8f2b-43a5-bb4b-622936f0f244', u'startTime': u'', u'duration': u'0 seconds', u'endTime': u'04:33:57 15/01/2019', u'templateVersion': u'11'}

Once completed, the status is displayed. The status (SUCCESS/FAIL), time taken, template name, version and deviceId are all shown.

Response:
{
  "status": "SUCCESS",
  "templateName": "int-vlan",
  "projectName": "Adam",
  "devices": [
    {
      "status": "SUCCESS",
      "name": "",
      "detailedStatusMessage": "Provisioning success for template int-vlan",
      "deviceId": "e05075e8-eb5b-42f5-9f60-d56380702655",
      "startTime": "04:33:56 15/01/2019",
      "duration": "0 minutes 2 seconds",
      "endTime": "",
      "ipAddress": "e05075e8-eb5b-42f5-9f60-d56380702655"
    }
  ],
  "deploymentId": "41ac69b9-8f2b-43a5-bb4b-622936f0f244",
  "startTime": "",
  "duration": "0 seconds",
  "endTime": "04:33:57 15/01/2019",
  "templateVersion": "11"
}

The interface Gig1/0/20 on the switch has successfully been provisioned into vlan 20.

Tips and Traps

One of the most obvious issues when testing is an error message related to “deployed with same params”, an example appears below.

Executing template on:10.10.50.2, with Params:{"vlan":"20","interface":"gig1/0/20"}
payload {'targetInfo': [{'params': {u'interface': u'gig1/0/20', u'vlan': u'20'}, 'type': 'MANAGED_DEVICE_IP', 'id': '10.10.50.2'}], 'forcePushTemplate': False, 'templateId': u'610a718c-0a71-484b-a632-a79b64192cb7'}
https://dnac:443/dna/intent/api/v1/template-programmer/template/deploy
Response {u'duration': u'0 seconds', u'deploymentId': u'Deployment of Template: 610a718c-0a71-484b-a632-a79b64192cb7.ApplicableTargets: [10.10.50.2],Template int-vlan:11 is already deployed with same params,. Not deploying it.None of the targets are applicable for the template. Hence not deploying', u'endTime': u'', u'startTime': u''}
Error: 11 is already deployed with same params,. Not deploying it.None of the targets are applicable for the template. Hence not deploying

By default Cisco DNA Center will not deploy the same template, with the same parameters twice (if the first attempt was successful). There are times where you may want to change this behaviour. The –force option can be used to set the ‘forcePushTemplate’: False, option to True.
One other thing you may find confusing is the following message.

Executing template on:10.10.50.20, with Params:{"vlan":"20","interface":"gig1/0/20"}
payload {'targetInfo': [{'params': {u'interface': u'gig1/0/20', u'vlan': u'20'}, 'type': 'MANAGED_DEVICE_IP', 'id': '10.10.50.20'}], 'forcePushTemplate': False, 'templateId': u'610a718c-0a71-484b-a632-a79b64192cb7'}
https://dnac:443/api/v1/template-programmer/template/deploy
Response {u'duration': u'0 seconds', u'deploymentId': u'Deployment of Template: 610a718c-0a71-484b-a632-a79b64192cb7.nonApplicableTargets: {10.10.50.20=Device is not applicable for the template due to mismatch of deviceType or softwareType or softwareVersion}.ApplicableTargets: NoneNone of the targets are applicable for the template. Hence not deploying', u'endTime': u'', u'startTime': u''}
Error: Deployment of Template: 610a718c-0a71-484b-a632-a79b64192cb7.nonApplicableTargets: {10.10.50.20=Device is not applicable for the template due to mismatch of deviceType or softwareType or softwareVersion}.ApplicableTargets: NoneNone of the targets are applicable for the template. Hence not deploying

At first glance, you might think the device type of the template does not match that of the device. This could be true however, somewhat confusingly, it could also be the device IP address cannot be found on the controller. Be careful with devices that have multiple IP addresses, make sure you use the same IP as the controller used to discover and manage the device. In this case 10.10.50.20 is not a valid device in the controller inventory. 10.10.50.2 was used in the earlier examples.

The final thing to be careful of is some parameters might be “typed”. For example, I could have type “int” for vlan in this example (rather than a string). Make sure the payload reflects that.

Continue reading