IDC White Paper shows ROI of 462% for Cisco SD-Access and Assurance

We are pleased to announce the publication of a new IDC white paper, sponsored by Cisco, that examines the business value realized by customers who have adopted Cisco’s Software-Defined Access (SD-Access) and Assurance solutions. The study showed some very impressive results, such as an average projected five-year return on investment (ROI) of 462%.

Cisco DNA Assurance and Cisco SD-Access are two major components of Cisco’s Digital Network Architecture, and are implemented using the Cisco DNA Center management platform. Together, these enable organizations to apply business intent to the network, creating unprecedented levels of visibility and control across the entire enterprise network.

Real customers sharing real experiences

For anyone who has been skeptical about our claims about the benefits of Assurance and SD-Access, this report should help sway your opinion.  There are many firsthand accounts from customers who are using these solutions in their networks, not just as demos or proof of concepts, but to actually run their IT operations. Participants in the study represented a range of business sizes and industry verticals, making it even more impressive that the results were so positive across the board.

Cisco DNA provides real benefits

According to the IDC authors, customers initially turned to SD-Access and Assurance to make managing complex operations easier, prepare for anticipated growth, and become more proactive in their approach to network management. What they discovered was that as network management becomes easier and performance improves, staff productivity increases and greater innovation company-wide becomes possible.

Some highlights of the results

◉ Average annual benefits of $3.18 million on a per organization basis
◉ 462% five-year ROI
◉ 9-month payback period
◉ 49% more efficient network management staff
◉ 35% more efficient network security teams
◉ 86% reduction in unplanned downtime

A key reason that the measured ROI was so high is that the time savings is compounded across all areas of network management and extends to non-IT personnel as well. Customers reported a wide range of positive benefits. With Cisco SD-Access, security is both more effective and easier to deploy and maintain. With Cisco Assurance, service issues are easier to track down and are detected earlier. These improvements lead to reduced downtime and improved application performance.

Source: IDC 2020

Cisco DNA solves real problems

Legacy network processes are inefficient and do not scale to the number of clients and devices now in use today. As the scale of the network increases, the friction inherent in manual processes for onboarding and managing connectivity cause a cascade of difficulties such as:

◉ Less than optimum experience for network users.
◉ Policy enforcement becomes more and more complex and inefficient.
◉ Holes open up in security policies.
◉ Network operators do not have visibility into what is happening in the network at any given moment.
◉ Problems take time to identify and solve, making users frustrated and slowing productivity across the company.

We believe this report helps prove that SD-Access and Assurance aren’t just shiny new toys. These solve real problems experienced by most network operators. With these solutions, you can proactively solve problems. You can match policy to the user, not the machine. You can automate routine tasks and roll out changes more quickly, making your network and your business more agile and able to respond to changing conditions.

Here is a concrete example that one of the customers in the study shared about their experience with SD-Access that illustrates this point about time savings:

A big thing for us is the rapid deployment or moving of different segmented networking groups. For example, right in the middle of one of our projects we had one of the labs moved. But it took 4 hours instead of what would have been about a month prior to SD-Access.

Continue reading

AI for Networking: Separating the Hype from Reality

Networks support explosive growth in traffic volume, connected mobile and IoT devices, and interconnected applications and microservices needed to deliver required services. Today’s networks generate massive amounts of data that exceed the ability of human operators to manage, much less understand.

With unprecedented increases in network complexity and scale, AI is no longer just “a nice to have” – it is becoming essential to helping NetOps teams maintain service and network assurance. Network strategists already know this: More than 50% identify AI as a priority investment needed to deliver their ideal network.

AI: What can’t it do?

However, there are also a lot of over-blown expectations. As the engineering lead on AI for networking at Cisco, I often find myself in conversations about very futuristic, and somewhat unrealistic AI-enabled scenarios. It can be quite entertaining – but we also need to remember that today’s AI technology is not a panacea for every networking ailment.

For now, and for the next few years, AI will only help fully automate a limited set of straightforward use cases. In most cases, that require more complex and flexible analysis, AI will simply help human operators make quantifiably better and faster decisions.

AI: What can it do?

So, what can AI help us do today? One of the most common AI techniques, machine learning (ML) offers unique capabilities that operators can use to assure required network performance.

ML algorithms are certainly very powerful, but they also have a reputation of being difficult to design, tune, and adapt to a variety of situations and sometimes have been known to produce results that may be difficult to interpret.

With Cisco AI Network Analytics, we have created a learning platform that solves issues where ML provides an indisputable and impactful benefit for network operators over existing technologies and approaches. This is possible thanks to the combination of two factors: (1) decades of experience in building some the world’s largest and most advanced networks and (2) deep expertise in ML algorithms that can effectively process networking data.

AI and ML have some useful applications

Let’s look at one of the more useful ML use cases – complex event processing. When applying ML to network telemetry, it is possible to establish dynamic baselines of what constitutes normal operating conditions for a given intent.

For example, the ML model(s) may be used to predict what should be the lower-upper bounds for a given KPI, for example, Wi-Fi on-boarding times. On-boarding refers to the set of complex tasks triggered when a wireless client attempts to join a wireless network.  Joining a network successfully and seamlessly contributes significantly to the Quality of Experience for the end user. Being able to monitor such complex, multidimensional KPIs so as to detect abnormal onboarding times, along with determining potential root causes should an issue occur, is a fundamental task for IT teams.

In this instance, Machine Learning (ML) allows for computing models used to predict the upper and lower bounds of the KPIs for on-boarding. KPIs falling outside a prediction as provided by the ML model would be considered “abnormal” for that unique network involved, and thus would be candidates for raising an alarm (that is, an alarm based on a learned bound, not based on a static value).

The figure below shows a predicted “band” (shown in green) of normal values for the percentage of failed onboarding sessions. As we can see, at some point the percentage of failed onboarding sessions (blue line) became abnormal (falling outside the green band), considering a number of network variables involved, as analyzed by the ML algorithm in use. This departure from normal to abnormal behavior for this network is denoted by the red section of the time-line in the diagram shown.

Predicted range of normal values for the percentage of failed onboarding sessions

A second ML use case that has a lot of potential is correlated insights. ML can provide deeper insights and visibility into the operation of the network and even help predict when an anomalous condition is likely to occur in the future.

A third important use case would be root-causing. In some cases, an ML algorithm may be able to detect anomalies with associated root causing, whereas in other situations more than one ML algorithm may be used in conjunction with anomaly detection to provide root causing.

IBN and AI as disrupters

AI and advanced networking technologies like IBN are disrupting how things are done, especially for networking operations. Testing of new applications can be done in minutes instead of weeks. Troubleshooting gets significantly easier when an assurance engine identifies root causes and recommends fixes. In fact, when armed with powerful dashboards that offer actionable insights, a future network operator may only need to look in a handful of places, as opposed to plowing through heaps of possible causes.

The intent-based networking (IBN) vision is that network teams will simply define the required behavior, and the network will know how to continuously align itself with what the business needs.

Continue reading

CLEUR Preview! Source of Truth Driven Network Automation

It’s a new year and a new decade, so it’s time for a NEW BLOG about network automation. I am getting ready for Cisco Live Europe 2020 and want to give everyone a preview of some of what I’ll be talking about in my session How DevNet Sandbox Built an Automated Data Center Network in Less than 6 Months – DEVNET-1488. If you’ll be in Barcelona, please register and join me for a look at how we approached this project with a goal to “innovate up to the point of panic” and brought in a lot of new NetDevOps and network automation processes.  But don’t worry if you’re reading this from far off in the future, or aren’t attending CLEUR, this blog will still be wildly entertaining and useful!

Today’s blog I want to build on those by showing where the details that provide the INPUT to the automation comes from – something often called the Source of Truth.

What is a Source of Truth?

If you’ve been kicking around the network automation space for awhile, you may have run across this term… or maybe you haven’t, so let me break it down for you.

Let’s say you are diving into a project to automate the interface configuration for your routers.  You’re going to need 2 things (well likely more than 2, but for this argument we’ll tackle 2).

First, you’ll need to develop the “code” that applies your desired standards for interface configuration.  This often includes building some configuration template and logic to apply that template to a device.  This code might be Python, Ansible, or some other tool/language.

Second, you need to know what interfaces need to be configured, and the specifics for each interface.  This often includes the interface name (ie Ethernet1/1), IP address info, descriptions, speed/duplex, switch port mode, and so on.  This information could be stored in a YAML file (a common case for Ansible), a CSV file, dictionaries and lists in Python, or somewhere else.

Then your code from the “first” will read in the details from the “second” to complete the project.

The “Source of Truth” is that second thing.  It is simply the details that are the desired state of the network.  Every project has a “Source of Truth”, even if you don’t think of it that way.  There are many different tools/formats that your source of truth might take.

Simple Sources of Truth include YAML and CSV files and are great for small projects and when you are first getting started with automation.  However, many engineers and organizations often find themselves reaching a point in their automation journey where these simple options are no longer meeting their needs.  It could be because of the sheer amount of data becomes unwieldy.  Or maybe it’s the relationships between different types of data.  Or it could be that the entire team just isn’t comfortable working in raw text for their information.

When text based options aren’t meeting the needs anymore, organizations might turn to more feature rich applications to act as their Source of Truth.  Applications like Data Center Infrastructure Management (DCIM) and IP Address Management (IPAM) can definitely fill the role of the Source of Truth.  But there is a key difference in using a DCIM/IPAM tool as an automation Source of Truth from how we’ve traditionally used them.

How a DCIM or IPAM becomes a Source of Truth

In the past (before automation), the data and information in these tools was often entered after a network was designed, built, and configured.  The DCIM and IPAM data was a “best effort” representation of the network typically done begrudgingly by engineers who were eager to move onto the next project.  And if we are honest with ourselves, we likely never trusted the data in there anyway.  The only real “Source of Truth” for how the network was configured was the actual network itself.  Want to know what the desired configuration for a particular switch was?  Well go log into it and look.

With Source of Truth driven network automation, we spin the old way on its head.  The first place details about the network are entered isn’t at the CLI for a router, but rather into the IPAM/DCIM tool.  Planning the IP addresses for each router interface – go update the Source of Truth.  Creating the list of VLANs for a particular site – go update the Source of Truth.  Adding a new network to an existing site – go update the Source of Truth.

The reason for the change is that the code you run to build the network configuration will read in the data for each specific device from the Source of Truth at execution time.  If the data isn’t in your DCIM/IPAM tool, then the automation can’t work.  Or if the data isn’t correct in the DCIM/IPAM tool, then the automation will generate incorrect configuration.

It’s also worth noting now that a Source of Truth can be used as part of network validation and health tests as well as for configuration.  Writing a network test case with pyATS and Genie to verify all your interfaces are configured correctly?  Well how do you know what is “correct”?  You’d read it from your Source of Truth.  I call that “Source of Truth driven Network Validation” and I’ll tackle it more specifically in a future blog post.

Source of Truth Driven Automation in Action!

Enough exposition, let’s see this in action.

The Source of Truth that we use in DevNet Sandbox for most information is Netbox.  Netbox is an open source DCIM/IPAM tool originally developed by the network automation team at Digital Ocean for their own needs, and has been popular with many engineers and enterprises looking for a tool of their own.

Let’s suppose we need to add a new network to our main internal admin environment in the Sandbox with the following basic information.

◉ The name of the network will be demo-sourceoftruth

◉ It will need an IP prefix assigned to it from the appropriate IP space

◉ Ethernet 1/3 on the switch sjcpp-leaf01-1 needs to be configured as an access port for this network

The automation to do the actual configuration of the VLAN, SVI, interface config, etc is already done, what I need to do is update the Source of Truth that will drive the automation. This involves the following steps:

1. Creating a new VLAN object

2. Allocating an available prefix and assigning to the new VLAN

3. Updating the details for port Ethernet 1/33 to be an access port on this VLAN

Note: You can click on the screen images that follow to enlarge for easier viewing.

Step 1: Creating a new VLAN object

I start in Netbox at the Tenant view for our Admin environment. From here I can easily view all the DCIM and IPAM details for this environment.

I click on VLANs to see the current list of VLANs.

The “Group” column represents the VLAN Group in Netbox – which is a way to organize VLANs that are part of the same switching domain where a particular VLAN id has significance.  This new network will be in the “Internal” group.  I click on “Internal” on any of the VLANs to quickly jump to that part of Netbox so I can find an available VLAN id to use.

I see that there are 4 VLANs available between 25 and 30, and I click on the green box to add a new on in that space.

I provide the new name for this network, and indicate it’s role will be for “Sandbox Systems”.  As this new network will be part of the Admin Tenant, I select the proper Group and Tenant from the drop downs.  Netbox supports creating custom fields for data that you need, and we’ve created a field called “Layer3 Enabled on Switched Fabric” to indicate whether SVIs should be setup for a network.  In this case that is True.  After providing the details, I click “Create” to create this new VLAN.

Step 2: Allocating an available prefix and assigning to the new VLAN

Netbox is a full featured IPAM, so let’s walkthrough allocating a prefix for the VLAN.

I start at the Supernet for admin networks at this site, 10.101.0.0/21 to find an available prefix.

I click on the Available range, to jump to the “Add a New Prefix” interface.

I start by updating the Prefix to be the proper size I want, picking the Role (this matches the VLAN role), providing a good description so folks know what this is for.  I then choose the new VLAN we just created to associate this prefix to using the drop downs and search options provided in the UI.  Lastly I pick the Admin tenant and click “Create”

Now if I go back and look at the VLANs associated with the Admin Tenant, I can see our new VLAN in the list with the Prefix allocated.

Step 3: Updating the details for port Ethernet 1/3 to be an access port on this VLAN

The final step in Netbox is to indicate the physical switch interfaces that will have devices connected to this new VLAN.

I navigate in Netbox to the device details page for the relevant switch.  At the bottom of the page are all the interfaces on the device.  I find interface Ethernet 1/3 and click the “Edit” button.

I update the interface configuration with an appropriate Description, set the 802.1Q Mode to Access, and select our new VLAN as the Untagged VLAN for the port.  Then click “Update” to save the changes.

Applying the New Network Configuration

With our Source of Truth now updated with the new network information, we simply need our network automation to read this data in and configure the network.  There are many ways this could be done, including a fully automated option where a webhook from Netbox kicks off the automation.  In our environment we are adopting network automation in stages as we build experience and confidence.  Our current status is that we execute the automation to process the data from the Source of Truth to update the network configuration manually.

When I run the automation to update the network configuration with the new Source of Truth info, here are the changes to the vlan-tenant configuration for our admin environment.

hapresto@nso1-preprod(config)# load merge nso_generated_configs/vlan-tenant_admin.xml

Loading.

1.78 KiB parsed in 0.00 sec (297.66 KiB/sec)

hapresto@nso1-preprod(config)# show configuration

vlan-tenant admin

  network demo-sourceoftruth

    vlanid 26

    network 10.101.1.0/28

    layer3-on-fabric true

    connections switch-pair sjcpp-leaf01

      interface 1/3

      description "Demonstration VLAN for Blog - Interface Config"

      mode access

Here you can see the new network being created, along with the VLAN id, prefix, and even the physical interface configurations.  All this detail was pulled directly from Netbox by our automation process.

And if you’d like to see the final network configuration that will be applied to the network after processing the templates in our network service by NSO, here it is.

    device {

        name sjcpp-leaf01-1

        data vlan 26

              name demo-sourceoftruth

             !

             interface Vlan26

              no shutdown

              vrf member admin

              ip address 10.101.1.2/28

              no ip redirects

              ip router ospf 1 area 0.0.0.0

              no ipv6 redirects

              hsrp version 2

              hsrp 1 ipv4

               ip 10.101.1.1

               preempt

               priority 110

              exit

             exit

             interface Ethernet1/3

              switchport mode access

              switchport access vlan 26

              no shutdown

              description Demonstration VLAN for Blog - Interface Config

              mtu 9216

             exit

    }

    device {

        name sjcpp-spine01-1

        data vlan 26

              name demo-sourceoftruth

             !

    }

Note: The service also updates vCenter to create a new port-group for the vlan, as well as Cisco UCS, but I’m only showing the typical network configuration here.

Finishing Up!

Hopefully this gives you a better idea about how a Source of Truth fits into network automation projects, and how a tool like Netbox provides this important feature for enterprises.

Continue reading

ACI Anywhere Now Extending From On-Premises to AWS Cloud

Cisco is pleased to announce availability of a brand-new solution, Cisco Cloud ACI on AWS. This solution automates management of end-to-end connectivity and enforcement of consistent network security policies for applications running in on-prem data centers and AWS public cloud regions.

Decentralized Data Means Cloud Growth

Enterprises, large and small, are expanding to the cloud to build applications that engage their customers. And their developers and IT teams must manage their private and public cloud environments.

IDC expects spending on cloud IT infrastructure to grow at a five-year compound annual growth rate (CAGR) of 11.2%, reaching $82.9 billion in 2022, and accounting for 56.0% of total IT infrastructure spend. Public cloud data centers will account for 66.0% of this amount, growing at an 11.3% CAGR. Spending on private cloud infrastructure will grow at a CAGR of 12.0%*.

Due to this massive shift in the decentralization of data, increasing cloud acceptance, and move to hybrid environments, businesses need a network that can empower the data center to go securely anywhere. Innovation should only be limited by imagination, not technology. Cisco’s ACI Anywhere with Cloud ACI is the bridge.

Multicloud Doesn’t Need to Mean Complexity

As the adoption of multicloud strategies grow, the industry is demanding consistent policy, security, and visibility everywhere, with a simplified operating model. IT organizations are challenged to maintain governance, compliance, agility, flexibility, and TCO optimization for legacy, virtualized, and next-generation applications across multiple on-premises sites and clouds.

Highly complex operational models today are the result of diverse and disjointed visibility and troubleshooting capabilities, with no correlation across different cloud service providers. There are multiple panes of glass to configure, manage, monitor, and operate these multicloud instances. And there are inconsistent segmentation capabilities today across hybrid instances that pose security, compliance and governance challenges.

Cisco Cloud ACI Extends ACI Capabilities from On-premises to Public Cloud

Cisco ACI delivers control and visibility based on application network policy. With the next phase, Cisco ACI extends this policy-driven automation from on-premises to public cloud instances.

Cisco Cloud ACI runs natively in public clouds and delivers the following key capabilities:

Automated and secure hybrid connectivity through unified management. Through a single pane of glass (ACI Multi-Site Orchestrator), users can configure inter-site connectivity, define policies, and monitor the health of network infrastructure across hybrid environments. Inter-site connectivity includes (i) An underlay network for IP reachability (IPsec VPN over the Internet, or through AWS Direct Connect*) and (ii) an overlay network between the on-premises and cloud sites that runs BGP EVPN as its control plane and uses VXLAN encapsulation and tunneling as its data plane.

Enable consistent security posture, governance, and compliance through a common policy abstraction. Cisco ACI on AWS uses group-based network and security policy models.Cloud ACI translates ACI policies into cloud-native policy constructs. The logical network constructs of Cisco ACI (tenants, VRFs, endpoint groups (EPGs), and contracts etc) translate into AWS networking constructs (user accounts, Virtual Private Cloud (VPC), and security groups, plus security group rules and network access-control lists etc.). This enables consistent network segmentation, access control, and isolation across hybrid deployments.

Enable elasticity for resources across on-premises data center and public cloud. Enable secure workload mobility and preserve the application policies, network segmentation, and identity of the workload (IP mobility*).

Facilitate workload migration across hybrid environments. Enable secure workload mobility and preserve the application policies, network segmentation, and identity of the workload (IP mobility*).

Enable business continuity and disaster recovery. Allow organizations to maintain or quickly resume mission-critical applications using a back-up and recovery site in the public cloud.

What makes Cisco’s Cloud ACI different and relevant for you

Cloud ACI provides a common policy abstraction and consumes AWS public APIs to deliver policy consistency and segmentation. As such, Cloud ACI is not confined to bare-metal instances in AWS and does not require deployment of agents in cloud workloads to achieve segmentation.

With Cisco ACI, customers can carry all their network and security policies across data centers, colocations, and clouds. Cisco ACI automates cross-domain service chaining of application traffic across physical and virtual L4-L7 devices to scale, and seamlessly integrates bare-metal servers, virtual machines, and containers under a single policy framework.

Cisco ACI also has the industry’s broadest tech-partner ecoysystem and integrates with a variety of solutions ranging from Cisco AppDynamics, CloudCenter to F5, ServiceNow, Splunk, SevOne, and Datadog. Customers can leverage widely adopted tools such as Terraform and Ansible to achieve end-to-end workflow-based automation. AWS customers can tap into the rich cross-silo insights through ACI integrations with AWS technologies like Amazon CloudWatch* and Amazon Simple Notification Service (Amazon SNS)* to fine tune the network for better throughput, latency, path selection, security and cost optimization.

Have ACI Anywhere with Cloud ACI on AWS

As the industry’s most deployed, open SDN platform, Cisco delivers advanced capabilities on AWS and simplifies multicloud deployments with Cisco Cloud ACI. With the Cloud ACI architecture, customers and analysts see the benefit of seamless layer-in policy consistency, operational simplicity and the flexibility to leverage services offered by public clouds.

“ESG Research validates that companies are increasingly adopting a hybrid cloud approach to deliver the best service for their customers. In fact, many are adopting a Multicloud policy” says Bob Laliberte, Practice Director and Senior Analyst with the Enterprise Strategy Group. “However, these distributed compute environments create significant management complexity. Cisco ACI Anywhere, and more specifically, Cloud ACI on AWS is helping to consolidate and simplify management across the on-premises data center and the popular AWS cloud environment, something that we expect will be well received by all market segments.”

Continue reading

New XR Programmability Learning Labs and Sandbox Let You Explore

Turning team focus to network automation and programmability

I came from a network service provider background. Then, when I starting working at Cisco, I was working on the Cisco Security network team. The global network we built, owned, and managed was much like a service provider network. We had lots of transit links, and circuits with service providers, and tons of peering links, and sessions all over the world. Managing this was a full-time job, and I am just talking about managing the WAN (wide area network) here. Which is why, like many of you and other network teams out there whose network requires speed, scale, and data analytics, my team and I turned our focus to network automation and programmability.

The majority of our network devices (both core and edge) were running IOS XR. IOS XR has always been one of my favorite platforms, so it was with great excitement that when I began working for the Cisco DevNet team, my specialist area would be working with the IOS XR teams and platform.

What is new to learn here?

A great question, I am pleased you asked! We have built a dedicated sandbox environment for IOS XR programmability and learning labs to go with this.  The IOS XR Programmability sandbox and learning labs provide an environment where developers and network engineers can explore the programmability options available in this routing platform. These include:

◈ Model Driven Programmability with YANG Data Models, NETCONF and gRPC
◈ Streaming Telemetry
◈ Service-Layer APIs
◈ Application Hosting

What gear can you access in the sandbox?

We wanted to build a sandbox that provides the right level of simplicity for users to get started while offering a flexible platform they can build on. The sandbox provides two Cisco IOS XRv 9000 devices (R1 and R2) connected back to back, plus a Linux host that acts as a development box (DevBox). The image version on Sandbox tile is 6.4.1 this is available on both the two IOS-XR nodes.

The new IOS XR programmability sandbox lets you explore programmability options available in this routing platform.

The all-new learning labs and track

You can use the IOS-XR programmability learning track to familiarize yourself with the rich set of programmable interfaces and APIs offered by IOS-XR. The goal of this track is to introduce you to the architectural tenets of the IOS-XR network stack and showcase how APIs at every layer of the stack – from Manageability APIs like YANG models, CLI, ZTP hooks to Service Layer APIs at the network infrastructure layer can be used to completely transform the way you manage and provision your network.

◈ IOS-XR CLI automation Cisco IOS-XR offers a comprehensive portfolio of APIs at every layer of the network stack, allowing users to leverage automated techniques to provision and manage the lifecycle of a network device. In this module, we start with the basics: the Command Line Interface (CLI) has been the interaction point for expect-style scripters (TCL, expect, pexpect etc.) for ages; but these techniques relying on send/receive buffers are prone to errors and inefficient code. This is where the new onbox ZTP libraries come handy. Use them for automated device bring-up or to automate Day1 and Day2 behavior of the device through deterministic APIs and return values in a rich Linux environment on the router.

◈ IOS-XR Model-Driven Automation: YANG models Cisco IOS-XR offers a comprehensive portfolio of APIs at every layer of the network stack, allowing users to leverage automated techniques to provision and manage the lifecycle of a network device. APIs that are derived, documented and versioned using deterministic models are contractually obliged to match the expectations laid out by the model. Following this ethos, in IOS-XR, all the capabilities of the software, traditionally offered through the Command Line Interface (configuration commands, show commands, exec commands) are mapped to equivalent Config and Oper YANG models backed by the internal IOS-XR Database called SYSDB. In this module, we start taking the first steps towards model-driven programmability as we dive deeper into IOS-XR Yang models. We look at the interaction with these models with tools such as ncclient, YDK or gRPC clients and tips to map your CLI configurations to corresponding YANG-Modeled XML/JSON representations.

◈ IOS-XR Streaming Telemetry: SNMP is dead! It is time to move away from slow, polling techniques employed by SNMP for monitoring that are unable to meet the cadence or scale requirements associated with modern networks. Further, Automation is often misunderstood to be a one-way street of imperative (or higher-layer declarative) commands that help bring a network to an intended state. However, a core aspect of automation is the ability to monitor real-time state of a system during and post the automation process to accomplish a feedback loop that helps make your automation framework more robust and accurate across varied circumstances. In this module, we learn how Streaming Telemetry capabilities in IOS-XR are all set to change network monitoring for the better – allowing tools to subscribe to structured data, contractually obliged to the YANG models representing operational state of the IOS-XR internal database (SYSDB) at a cadence and scale that are orders of magnitude higher than SNMP.

◈ IOS-XR Service-Layer APIs: Cisco IOS-XR offers a comprehensive portfolio of APIs at every layer of the network stack. For most automation use cases, the manageability layer that provides the CLI, YANG models and Streaming Telemetry capabilities, is adequate. However, over the last few years, we have seen a growing reliance in web-scale and large-scale Service Provider networks on off-box Controllers or on-box agents that extract away the state machine of a traditional protocol or feature and marry their operation to the requirements of a specific set of applications on the network. These agents/controllers require highly performant access to the lowest layer of the network stack called the Service Layer and the model-driven APIs built at this layer are called the Service-Layer APIs. With the ability to interact with RIB, the Label Switch Database (LSD), BFD events, interface events and more capabilities coming in the future, it is time to take your automation chops to the next level.

The sandbox provides two Cisco IOS XRv 9000 devices (R1 and R2) connected back to back, plus a Linux host that acts as a development box (DevBox).

Getting Started

The development box includes a “hello world” sample app to check the uptime on routers to get you started.

hello-ydk.py

The script illustrates a minimalistic app that prints the uptime of a device running Cisco IOS XR. The script opens a NETCONF session to a device via the devices IP address, reads the system time and prints the formatted uptime.

Sample Output:

Continue reading