Apstra Blog

Managing Multiple Network Technologies in the Data Center

Updated Nov 28, 2016

serious-data-technician-lookin.jpegOperating a data center network using switching products from multiple vendors is costly and often quite hard to do. Design, provisioning and operations of these products requires teams to be educated or certified in the technologies that each product requires. The cost of this can be untenable. The only real alternatives for enterprises are to spend money to build and maintain internal expertise in competing vendor technologies, or to remain in what is really technological captivity — lock-in — by the networking equipment vendor of choice.

This issue extends beyond maintaining expertise in each vendor’s technology. So long as vendor operating environments differ, we have to build multiple, separate processes for all stages in the network lifecycle. Such vendor-specific processes may differ materially from one another. Different scripting, ZTP, monitoring, and automation among other capabilities are expected. And, little help is on the way from network equipment suppliers; maintaining lock-in through the use of disparate processes is actively sought by vendors.

Data center network products generally share a common underlying platform (e.g. Linux, commercial silicon), but interaction with and use of that technology often requires vendor specific knowledge. So data center network devices are not the same, despite similarities under the covers. Whether we use multiple vendor technologies or just one, the cost maintaining multiple teams and processes, or living with lock-in, is invariably high.

Use of bare metal switching with a common NOS does not solve the problem. Bare metal switches are generic; use of them forgoes potentially substantial hardware advantages offered with non-white box solutions. Network engineers have a choice of two sub-optimal options; generic hardware with Linux, or proprietary solutions with widely divergent methods of design, configuration, operations and automation.

An obvious solution is to build a network operating system to control physical network equipment from multiple vendors, based upon the intent of the network architect. In such an environment, vendor products would be abstracted into appearing to the operator as generic switching elements which can be managed in a common manner. Design, configuration, provisioning and operations would then be performed only once — regardless of the number of equipment suppliers.

This is the Apstra AOS solution methodology, and the details are explained in this video.

 

Follow Apstra

Follow Apstra

 

Subscribe to Email Updates

 

The Journey Towards Self-Operating Networks

 

 

Topics

More

 

Share this Post