Cisco Live Recap - ACI is not Cisco's only SDN Solution

153756157_jpg

After attending Cisco Live last week, I thought of the various product announcements made, and one of the key items is the expansion of their SDN approach.

When many people think of Cisco’s SDN strategy, they instinctively think of ACI (Application Centric Infrastructure). While ACI is a key part of their strategy, Cisco announced new SDN capabilities across their Nexus switches, which include:

  • Programmable network – enhancements to the NX-OS that enable network configuration and management using GNU/Linux tool chains (i.e., shell access). The systems also support Linux containers that enable the running of agent software within a safe sandbox within the switches.
  • Programmable fabric – provisioning support for BGP-EVPN (Ethernet VPN) VXLAN.

In addition, if you look outside the Nexus line, there are SDN solutions such as Cisco iWAN (Intelligent WAN), which works with their Application Policy Infrastructure Controller Enterprise Module (APIC EM). It provides an incremental approach for adopting SDN technologies since it is compatible with existing devices such as Cisco 4000 series Integrated Service Routers (ISR).

What’s apparent is that one size for SDN does not fit all. It depends on who you are and what you do. Service providers and IaaS/cloud providers have different needs compared to enterprise customers for scale, desire different toolkits for management, and possess different skill sets and access to DevOps style staff.

Enterprise networking infrastructure, on the other hand, has smaller scale than service providers, but may include a diverse set of requirements stemming from legacy applications (and their networking requirements). And IT management may not have access to sophisticated DevOps staff. For those environments, a turnkey approach based on ACI and its policy model makes sense.

Without going into the details of each of the technologies in this blog, I want to tie this strategy back to the keynote presentation by John Chambers, Cisco’s current CEO, that emphasized the importance of architectures, solutions, and outcomes.

While some people may want Cisco to create an single, overarching architecture for SDN, careful examination shows that it does not make sense to unify it, given the scope of their product line range, and the diversity of customers and use cases they bring.

Service providers have needs that are different from enterprises, and the solution they seek is something highly customizable, with the outcome being a flexible network that can scale. Other vendors provide highly programmable functions, such as Cumulus Networks’ Cumulus Linux or Juniper Networks' broad product line (including Contrail), which suit their strengths with service provider customers.

Enterprise customers may want a solution that is turn-key, using a network that adapts its operation to a range of applications. The outcome is agility and lowered OpEx, and products such as ACI are suitable.

A solution-based approach is not unique to Cisco. Companies such as Extreme Networks have adopted a solution-based strategy. I believe these changes are a reflection of the desire of IT customers to get clarity in the adoption of IT infrastructure, which may include devices and software from different product lines and even different vendors. Professional services and systems integrators will take an important role in this world. They may recommend and deploy the appropriate SDN solution from the menu Cisco provides, or potentially customize software to tailor it to a customer’s needs.

The news of the SDN approaches is important and interesting in its own right, but to me, its alignment with a solution-based approach is equally interesting.

federal cybersecurity analysis

Topics: Networking ESG on Location