Software drives the promise of the interoperable network
Interoperability in networks is essential now, a reality that vendors increasingly acknowledge. Learn how the networking industry is changing to accommodate the need for openness.
Interoperability among networking vendors has always been a bane for network engineers. Even creating an interoperable network using platforms from the same vendor can be a problem. The networking industry is changing quickly as it embraces programmability and a software-driven paradigm, but interoperability issues persist as vendors remain reluctant to sacrifice a profitable, closed system for an open one. But in an era where the industry demands openness, that reluctance appears to be fading away.
Interoperable networks: Something old, some things new
The concept of a programmable infrastructure isn't new. The largest vendors -- among them Cisco, with Prime Infrastructure, and Juniper Networks, with Contrail -- have been making attempts for years. Smaller and newer vendors have the ability to position themselves differently and pivot more quickly. Take Cumulus Networks, for example, which provided a completely programmable interface from its inception. Yet even some of these programmable interfaces are limited to their own platforms, making them a very restricted infrastructure without much semblance of interoperability.
The difference today is vendors both large and small are beginning to open their operating systems through industry-standard interfaces such as open APIs, NETCONF, and on-box Linux and Python. The idea is to enable a greater level of automation and orchestration of network devices, usually by employing some sort of controller specific to that vendor.
For example, Cisco proposed to reduce the time needed to provision an interoperable network through the use of its Software-Defined Access, or SD Access, software that treats the network as a single entity with multiple pieces to orchestrate. Using a central dashboard, an engineer can manage all the components of a network using policy, rather than device by device via the command-line interface.
However, this approach only works for managing an entirely Cisco network. Though there are certainly advantages to having an entire network made up of a handful of vendors -- or only one -- a multivendor network is more the rule than the exception.
Editor's note: Most recently, Cisco took its first significant steps to separate its software from its underlying hardware, allowing customers to use the Nexus operating system on any white box switch while allowing some third-party applications to run on its certain switches and routers.
What vendors that aren't Cisco do
From a product-positioning perspective, a networking vendor trying to sell an interoperable network management platform must make sure that platform can work with devices from other vendors. The reason for this isn't because Cisco, Juniper or Extreme want you to buy their network management platform rather than sell you their switches and routers. Instead, there is an understanding that very few customers will ever completely replace the entirety of their network in one fell swoop.
Since openness is the linchpin to this new way of networking, non-networking vendors can also create products to manage a multivendor environment.
To that end, vendors are working toward interoperability by basing their products on open networking standards and open source models. Cisco and Juniper, for example, make portions of their code available on GitHub in an effort to make their technology available to a wider community.
This is a significant change from the old way networking vendors did things. It also opens the door for smaller vendors to develop tools that can integrate with many vendors' devices, thereby providing a new avenue for sales and increased market share.
Extreme Networks Inc. sells a variety of switch platforms, but its network management platform, Workflow Composer, integrates with non-Extreme switches. However, they all must be able to communicate using the same industry-standard protocols, in this case, Python's Network Automation and Programmability Abstraction Layer with Multivendor support library. This integration also applies to visibility software and ticketing systems a networking team might use.
Since openness is the linchpin to creating the interoperable network, non-networking vendors are also able to create products that manage a multivendor environment. NetBrain Technologies, for example, does not make switches or routers. Instead, it markets network automation software that works with dozens of vendors. Engineers use the tool to make network operations programmable from a single conduit rather than log into devices individually.
Until recently, network automation relied on engineers developing homegrown Perl, Python or Ansible scripts -- or some combination of these -- to automate device provisioning and Day 2 activities. Because network hardware vendors are now opening up their operating systems, the latest trend in network management is tools that abstract away the need for homegrown scripts. As a result, engineers can simply purchase a software license and run a network management platform that speaks to a wide variety of devices across their networks.
This is a new way of approaching networking -- from the perspective of both the engineer and networking vendor. More open and powerful software also opens the door to true network vendor interoperability. This shift in how devices are managed across a network is long overdue and is a welcome change in the way we manage our networks.
