Looking back at historic implementations, we had a fixed set of hardware or networks geared for catering services to the end users. End users also had a limited set of connection options to access a limited set of networks or connected resources. As the number of users increased, a simple solution was to add additional hardware or network gear. However, with the surge of different end user devices, such as mobile phones, and high data demand and up time requirements for end users, managing the increasing amount of hardware and additional connections becomes a complex task.

A simple device failure or cable failure might impact the entire set of connected hardware or network gears, which would create a widespread downtime for end users, resulting in a loss of man hours both in terms of productivity and trust. Think of a large internet service provider (ISP) with recurring outages, with each outage affecting a large set of both enterprise and home users. If a new ISP were to enter the market with reliability as its unique selling point, people would not think twice before jumping to the new provider. Effectively, this could result in a loss of business and ultimately, a closure situation for the earlier provider because of the decreasing reliability and trust among its current set of users.

To handle this type of situation, one solution that has emerged is the usability of the same set of devices or network hardware to perform different functions using the same hardware platform. This has been made possible through a combination of SDN and programmable networks (PNs).

SDN takes care of control plane configurations for data to automatically reroute to a path that is the best available for a specific source to the destination. For example, let's say we need to reach destination D from source A. The best path to reach D is A -> C -> D.

Now, in the case of legacy traffic flow, unless C is down or practically shut, the traffic will not flow from A -> B -> D (unless special complex configurations are done on each network gear/device). In an SDN environment, using OpenFlow as the underlying protocol, the controller will detect any issues in the path of A -> C -> D, and based upon certain issues (like packet drop or congestion in the path), would make an intelligent decision to ensure there is a new path for the data to flow from A -> B -> D.

As we see in this case, even with no physical issues on C, SDN already takes care of identifying the best path for the data to flow on, which effectively results in the best achievable performance for end users with reliability.

PN is an addition which is a collection of hardware devices in the network layer that can be programmed to behave in a different way based upon the requirements. Think of a switch acting as a router by changing its functionality through a written piece of code. Let's say we get an influx of new end users and we need to have a high switching capacity in the network layer. Some of the devices can now act as a switch rather than a router. This ensures a two-fold benefit:

• Using the same set of hardware based upon the demand and requirements, the hardware can be reused to handle new scenarios without introducing more complexity into the network by adding an additional set of hardware.
• Better control over the flow of traffic with the additional capability of securing traffic through the same set of devices. This is introduced by adding ACLs for traffic to flow from a certain set of devices, and even ensuring that a device handles only a particular type of traffic and sends the remaining traffic to other devices that are specifically programmed to handle that particular traffic. Think of it, as video with voice traffic going from a different set of devices to ensure optimal performance and load on specific devices using the same set of hardware that we currently have.

A major component of PNs (the collective name for programmable network devices), is the use of APIs that are provided by various network vendors like Cisco, Arista, and Juniper. By calling these APIs we can ensure that each of the devices from specific vendors can easily talk to each other (exchange information is a unified format), and can change the behavior of a specific hardware based upon the API calls. One example that is common in today's market is Cisco Nexus 9000 series devices. These are modular or fixed switches (with different variations), and by using OpenFlow gives us the ability to programmatically alter their behavior based upon dynamic requirements.

Taking this switch as an example, direct access to application-specific integrated circuit (ASIC) chip-level programming is also exposed, which ensures that the ASICs can also be programmed based upon the requirement along with the software-level variations. With SDN in place, controllers can take advantage of OpenFlow and the APIs exposed on these switches to control the role of these switches.

Cisco also provides a Power on Auto Provisioning (PoAP) feature to multiple devices (primarily on the Nexus platform) that helps achieve auto provisioning and commissioning as soon as a new device boots. A basic overview of this process is, if a Nexus device with the PoAP feature enabled boots and is unable to find any startup config, it locates a Dynamic Host Configuration Protocol (DHCP) server in the network and bootstraps using the IP address and DNS information obtained from that DHCP server. It also fetches a customized script that is executed on the device that has instructions to download and install the relevant software image files and specific configurations for that device.

A big advantage of this type of feature is that we can spin up new devices within one to two minutes by just powering it up and connecting it to a network which has DHCP functionality to fetch relevant information to new devices in the network. Think of the legacy way of bringing a router live with multiple hours of human intervention versus the current way of booting up a router, and the router taking care of itself without any human intervention.

Similarly, using the APIs (NX-API is the underlying terminology used for Nexus API), better visibility in terms of packet flow and monitoring is also being exposed from Cisco, and, using simple scripts written in any language (like Python), the path and flow of traffic can be modified based upon the results returned back through the call of those APIs.

Taking another example, we have network device vendor Arista. Arista has introduced Arista Extensible Operating System (EOS), which is a highly modular and Linux-based network OS. Using Arista EOS, managing multiple devices becomes easy as it has the ability to provide extensive APIs (Linux kernel-based and additional ones related to Arista), and call APIs for various vendors to configure and deploy numerous end nodes. A feature introduced by Arista called Smart System Upgrade (SSU), ensures that as we perform OS upgrades on Arista devices, it restarts its services with the upgraded OS versions but without rebooting to ensure minimal traffic interruption during upgrades. These features ensure that we have resiliency and up time even when we have new patches and OS upgrades rolled out on the data centers or multiple devices at once.

Arista EOS provides extended functionality for the devices to be managed through APIs by providing a set of APIs call eAPI. eAPI can be used to configure Arista devices by calling the eAPI framework from any scripting or programmable language. Let's see a very basic example of how to manage an Arista switch using eAPI. 

We need to configure eAPI on the Arista switch:

Arista> enable
Arista# configure terminal
Arista(config)# management api http-commands
Arista(config-mgmt-api-http-cmds)# no shutdown
Arista(config-mgmt-api-http-cmds)# protocol http
Arista(config-mgmt-api-http-cmds)#end

This ensures that the Arista eAPI functionality is enabled on the router, and we can use HTTP protocol to interact with the API. We can also switch between the options of eAPI available over HTTPS, by using the command protocol https.

To verify if our configuration is correct, we use the command show management api http-commands, as follows:

Arista# show management api http-commands 
Enabled: Yes 
HTTPS server: shutdown, set to use port 443 
HTTP server: running, set to use port 80

We can check if the eAPI framework is now accessible using the browser command http://<ip of router>.

A couple of examples from Arista depict the output that we get using the URL (in this case we have HTTPS enabled instead of HTTP):

Here we see a set of commands passed (show version and show hostname), and the response from the API confirms the result set. Additionally, the Command Response Documentation tab shows us the available APIs that can be used for reference:

Let's see how to call the same in Python:

As a prerequisite we need to install jsonrpclib, which can be found at URL https://pypi.python.org/pypi/jsonrpclib. This is used to parse the remote procedure call (RPC) in JSON format. Once done, the following code will result in the same set of values that we got using the browser:

from jsonrpclib import Server 
switch = Server( "https://admin:[email protected]/command-api" ) 
response = switch.runCmds( 1, [ "show hostname" ] ) 
print ("Hello, my name is: ", response[0][ "hostname" ] )
response = switch.runCmds( 1, [ "show version" ] ) 
print ("My MAC address is: ", response[0][ "systemMacAddress" ] )
print ("My version is: ", response[0][ "version" ])

The preceding code gives the following output:

Hello, my name is: Arista 
My MAC address is: 08:00:27:0e:bf:31 
My version is: 4.14.5F

In a similar way, Arista has also introduced a library for Python that can be used as an alternate to jsonrpclib. The library pyeapi, which can be found at URL https://pypi.python.org/pypi/pyeapi, is a Python wrapper for the Arista EOS eAPI. Going by the example, here is how we can access the same set of devices using pyeapi.

From the developer page, here is an example that depicts how we can use pyeapi for API handling on Arista:

>>> from pprint import pprint as pp
>>> node = pyeapi.connect(transport='https', host='veos03', username='eapi', password='secret', return_node=True)
>>> pp(node.enable('show version'))
[{'command': 'show version',
  'encoding': 'json',
  'result': {u'architecture': u'i386',
             u'bootupTimestamp': 1421765066.11,
             u'hardwareRevision': u'',
             u'internalBuildId': u'f590eed4-1e66-43c6-8943-cee0390fbafe',
             u'internalVersion': u'4.14.5F-2209869.4145F',
             u'memFree': 115496,
             u'memTotal': 2028008,
             u'modelName': u'vEOS',
             u'serialNumber': u'',
             u'systemMacAddress': u'00:0c:29:f5:d2:7d',
             u'version': u'4.14.5F'}}]

Looking at both Cisco and Arista (which are two major players in the cloud and SDN marketplace), we can combine both Arista eAPI and Cisco NX-API to manage our entire data center inventory, and work on some tasks like the provisioning of new devices or upgrading of current devices with no or minimal impact, which in turn ensures scalability, reliability, and uptime in the business processes.