Network Infrastructure APIs
This chapter is from the book
This chapter is from the book
This chapter is from the book
In the preceding chapter, we explained the power of model-driven DevOps and the use of data models. To start the journey toward model-driven DevOps, your infrastructure must be consumable in a programmatic way. Therefore, in this chapter we discuss the concept of consumable infrastructure. Consumable infrastructure, simply put, is infrastructure that is interacted with through APIs via data models. Consumable infrastructure rapidly responds to the needs of an organization through APIs and platform-based simplification. As we explore later, we want to look at the network in terms of consuming services and capabilities and not just automating specific tasks. Consumable infrastructure greatly reduces the complexity of automation and makes it more accessible to operators as opposed to requiring deep programming expertise.
APIs
An application programming interface (API) is a way for two applications to interact with each other. In contrast, a command-line interface is a way for a human to interact with an application to retrieve data or make configuration changes. In the context of IT infrastructure, an API interaction is usually a two-way communication where some data is sent from an application to a device or controller platform for the purposes of retrieving operational information or making configuration changes.
APIs are a critical component of model-driven DevOps. As the name implies, model-driven DevOps makes heavy use of data models. API software on a device takes data and, using a data model to decipher that data, configures the various components of the device the way the manufacturer intended.
When network infrastructure is treated as a set of APIs, configuration consists of moving data, generally in the form of JSON or XML, between those APIs. This capability makes network operations more like cloud and application development. This type of interaction is a significant improvement over the legacy human-optimized CLI interaction.
The most common model-driven APIs for network devices use the NETCONF protocol with YANG data models. NETCONF pushes the data models encoded in XML over a secure transport layer and provides several operational advantages over CLI, including
■ Installation, manipulation, and deletion methods for configuration data
■ Multiple configuration data stores (such as candidate, running, startup)
■ Configuration validation and testing
■ Differentiation between configuration and state data
■ Configuration rollback
Why API over CLI?
For decades, network engineers have used CLIs to configure network devices. A CLI is, for the most part, an effective human-to-device interface. When it comes to automating network devices, however, a CLI is a poor computer-to-network device interface. The main reason for this is that most CLIs are meant to be human readable; therefore, most CLIs have a language-like construction that makes it easier for humans to use. Unfortunately, human languages are difficult for computers to use.
To illustrate, let’s first look at a simple example of configuring the hostname on a Cisco IOS device. We use Ansible because it is one of the most popular ways of automating network devices, but the problem we are about to describe exists with most any CLI-based method of automation. Using Ansible parlance, we describe the desired end state of the hostname of a particular device. A hostname is a great use case because it is a scalar (that is, a single value). To change the hostname, the Ansible ios_config module does a simple textual comparison of the configuration. To set the hostname using Ansible, you would use the following YAML in a playbook:
- ios_config:
lines:
- hostname newname
If hostname newname is not present, it sends that line to the device. Even if a different hostname is present on the target device, because hostname is a scalar, the old hostname gets replaced by the desired hostname. However, as Bob painfully discovered, a list of NTP servers is more difficult. Suppose you’ve set the NTP server to 1.1.1.1 with the following YAML:
- ios_config:
lines:
- ntp server 1.1.1.1
Now you want to change your NTP server to 2.2.2.2, so you modify the YAML:
- ios_config:
lines:
- ntp server 2.2.2.2
Simple, right? But the problem is that you would end up with two NTP servers in the configuration:
ntp server 1.1.1.1 ntp server 2.2.2.2
The reason is that the Ansible ios_config module does not see ntp server 2.2.2.2 present in the configuration, so it sends the line. However, because ntp server is a list, it adds a new NTP server instead of replacing the existing one, giving you two NTP servers (one that you do not want). To end up with just 2.2.2.2 as your NTP server, you would have to know that 1.1.1.1 was already defined as an NTP server and explicitly remove it. This is also the case with ACLs, IP prefix-lists, and any other list in IOS. The Ansible ios_config module (as well as the cli_config module) does not have a native way to describe the desired end state of something simple like NTP servers on a network device, much less something more complex like OSPF, QoS, or Multicast.
There are clearly ways to address this situation. For example, the Ansible ios_config module could be improved to know how to parse IOS syntax and look for any existing NTP server configuration and remove it, just as a human would. One problem with this approach, however, is that this more capable module would be re-implementing IOS parsing rules outside of IOS. This means that vendor changes to the IOS CLI would necessitate changes to the ios_config Ansible module, creating a maintainability problem that would often result in lagging functionality. Furthermore, this approach would need to be taken with every vendor and/or device CLI available, making this approach unscalable.
The better way is to use an API. APIs are specifically designed for programmatic configuration of devices. To illustrate the advantages of the model-driven method using an API, let’s use the netconf-console utility to get and set the NTP servers on a Cisco IOS-XE device. First, let’s see the current list of NTP servers. Listing 3-1 illustrates how to retrieve NTP configuration using netconf-console.
LISTING 3-1 Using netconf-console to Retrieve NTP Configuration
# netconf-console –host <device IP> --port 830 –user admin –password admin –db running
–get-config –xpath /native/ntp
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<ntp>
<server xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-ntp">
<server-list>
<ip-address>1.1.1.1</ip-address>
</server-list>
<server-list>
<ip-address>2.2.2.2</ip-address>
</server-list>
</server>
</ntp>
</native>
</data>
Although this example is a wordier rendering of the same configuration, it is deterministic. All the NTP servers and their associated configuration are organized into one section of the tree. We can deal with it as a separate entity as opposed to being thrown in at the same level with other configuration information. Also, note that we were able to ask the device for just the NTP configuration information. No parsing required.
Now let’s change the NTP servers. First, we take the previous output, change the IP address of the second NTP server, and specify that this operation should replace the server section with operation='replace'. The content of Listing 3-2 would normally go into a file named ntp.xml.
LISTING 3-2 XML to Change NTP Configuration
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<ntp>
<server xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-ntp" operation='replace'>
<server-list>
<ip-address>1.1.1.1</ip-address>
</server-list>
<server-list>
<ip-address>3.3.3.3</ip-address>
</server-list>
</server>
</ntp>
</native>
Then we can push the XML payload to the device using netconf-console, as shown in Listing 3-3.
LISTING 3-3 Using netconf-console to Change NTP Configuration
# netconf-console –host <device IP> --port 830 –user admin –password admin –db running –edit-config ntp.xml <ok xmlns="urn:ietf:params:xml:ns:8equire:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:8equire:base:1.0"/>
The ok in the XML response indicates that the device accepted the change. Now let’s retrieve the NTP configuration and verify the results, as shown in Listing 3-4.
LISTING 3-4 Using netconf-console to Verify Configuration Change
# netconf-console –host <device IP> --port 830 –user admin –password admin –db
running –get-config –xpath /native/ntp
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<ntp>
<server xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-ntp">
<server-list>
<ip-address>1.1.1.1</ip-address>
</server-list>
<server-list>
<ip-address>3.3.3.3</ip-address>
</server-list>
</server>
</ntp>
</native>
</data>
The first thing that you might notice is that this was a lot of work just to change the NTP server. In the same way that human-to-device interfaces are not optimal for computers, computer-to-device interfaces are not optimal for humans. Having a machine-friendly, deterministic, and repeatable way of making changes in the environment is the necessary foundation for effective automation. Assembling a series of programmable operations into more complex workflows is where you start to see real efficiency advantages.
Even though computer-to-device interfaces might look daunting at first and are not optimal for humans, humans still need to understand them in order to help computers use them for automation. Figure 3-1 takes a closer look at this concept. Here we take data (the list of NTP servers that should be configured) from our source of truth, encode it into a payload as defined by a data model (XML in the case of NETCONF), and send the payload to the API (NETCONF in this case).
)
FIGURE 3-1 Encoding Data
This generic workflow can accommodate a host of use cases and APIs. For example, we can use a RESTCONF interface by simply changing the encoding to JSON (but using the same data model) and sending it to a RESTful interface. We can even stretch this notion to CLI-only devices by taking the data, encoding it as textual configuration tailored to that device, and delivering it via SSH. This yields a flexible framework, illustrated in Figure 3-2, with the flexibility to deliver the data via any encoding to any device using any API.
)
FIGURE 3-2 Encoding Data for Different APIs
This approach works for physical network infrastructure, but it also works for cloud infrastructure. For example, AWS CloudFormation is just source of truth data encoded in JSON using a data model and delivered via an API using an SDK like Boto3 for Python. Therefore, thinking in this manner allows you to use the same methodology for your entire IT infrastructure.