Network Automation using YANG Models across XE, XR, & NX

Lab Introduction and Overview


A Trip Down Memory Lane, A Historical Look...

It has been sometime now since the concept of Software Defined Networks (SDN) has entered the networking industry and marketplace. The fundamental principle of SDN is to interact with networks programmatically to deploy, control, change, manage, and monitor network devices using open interfaces. This concept overlaps with how networks are interacted with today and thus, can be difficult to adopt. However, the biggest value-add to an individual network engineer, organization, or even company is the business problems that can be solved adopting network programmability and automation.

Some may argue that this concept has been around for a long time in our industry. They would not inherently be wrong. RFC3535 was published in May 2003 and provides an overview of a workshop held in 2002 between network operators and network protocol developers around network management through programmable means. Topics discussed included SNMP, the command line interface (CLI) over Telnet/SSH, HTTP/HTML, and XML as various management technologies. SNMP was found, as we know, to be widely deployed for monitoring, but it was lacking significantly in its ability to be used for configuration due to the lack of writable MIBs along with the lack of ability to retrieve configuration. The norm in the industry is CLI automation over either Telnet or SSH since almost all network devices have a builtin CLI interface; however, limitations with heterogeneous environments and parsing of unstructured data make scripts extremely difficult to maintain. Devices with embedded web servers have their issues with trying to parse HTML from web pages. And lastly, XML, was actually determined to be easily read and favorable to machines, but is rather verbose and lacks common acceptance.

From the aforementioned workshop and RFC, it was recommended to the IETF to focus on a standardization around a programmatic configuration management interface, specifically with XML-based schemas, otherwise, network operators would default back to the CLI. Further, configuration data and operational data should be clearly delineated.

Over the next 10 years, various RFCs were published. The first being RFC4741, later obsoleted by RFC6241, and RFC4742. These defined the Network Configuration Protocol (NETCONF) and NETCONF over SSH that specifies a new interface in which a network device be managed and configured using XML encoding. However, these did not specify or standardize on a configuration data model and surely did not look to leverage the existing CLI. Several years later, RFC6020 (YANG 1.0), later obsoleted by RFC7950 (YANG 1.1), which is the current version), was drafted that specified a new configuration modeling language called YANG (Yet Another Next Generation). Subsequent RFCs were drafted specifying specific YANG data modules, such as for interfaces or IP. The latest developments include RFC7951, which specifies the use of JSON encoding and RFC8040, which introduces an HTTP-based protocol interface, RESTCONF, that can use both XML or JSON encodings for network device configuration management.


Objectives of the Lab

The evolution that these RFCs represent has become known as Model Driven Programmability (MDP) in the industry. A different skill-set other than understanding network protocols is becoming required. The goal of this lab is to provide an overview of MDP across Cisco's IOS XE, IOS XR, and NX-OS platforms and the tooling, both open-source and Cisco provided, to enable you along this journey.

Upon completion of this lab, we hope that you walk away with the following skill-sets to place in your toolkit of knowledge such that the lessons learned are useful in your day-to-day operations:

  • Basic understanding of YANG
  • Familiarity with NETCONF
  • Ability to install the tools and packages associated with MDP
  • Python tips and tricks for working with MDP packages
  • An understanding of the role of Ansible in provisioning and orchestration
  • Foundational insight to take YANG models and convert them into usable Python
  • When and where to use YDK
  • Ability to use ydk-gen for various MDP scenarios
  • Comfort working with Python scripting and PDB
  • Familiarity with XML based RPCs
  • Knowledge of the capabilities and limitations of MDP

Lab Information

The lab topologies can be found by clicking the topology icon in the upper-right corner, or here:

Any connection information can be found by clicking the icon in the top-right.

We hope you enjoy!