Cisco today announced two new products aimed at cloud providers and enterprises and unveiled more details on its Cisco ONE SDN controller. The two new major products are the Nexus 6000 family, which is a new set of switches based on Cisco’s proprietary switching fabric, and the Nexus 1000V InterCloud, which creates an encrypted tunnel between two cloud providers, allowing traffic to flow between private and public clouds, or between public clouds.

The impetus behind the announcement is Cisco’s desire to serve the new multi-cloud ecosystem emblematic of many of today’s enterprises and service providers. Specifically, the Nexus 6000 family aims to improve the scale of the datacenter fabric with the 4RU Nexus 6004 available in Q1 2013. This switch is capable of forwarding all packet sizes at line rates in L2/L3 mode across 384 10GbE ports or 96 40GbE ports with 1 microsecond of latency—pretty impressive. The Nexus 6000 supports a wide range of features, including vPC, FabricPath/TRILL, Adapter FEX/VM FEX as well as NAT and tunneling. The lower-end Nexus 6001 will be available in Q2. For more technical details around the Nexus 6000 family, check out fellow blogger Greg Ferro’s excellent write-up on Network World of his first impressions. In addition to the 6000 announcement, Cisco also tacked-on an announcement of the Network Analysis Module, the first service module for the Nexus 7000, that will be available in Q2. The NAM will enable performance analytics of media traffic and provide application-level visibility with DPI capabilities.

Cisco’s NX1000V gets a shot in the arm with a new ability to span clouds via 1000V InterCloud. InterCloud provides an encrypted tunnel between two cloud providers that supports many of the NX1000V features such as vPath, allowing for movement of applications and data into the cloud, all controlled via the Virtual Network Management Center (VNMC). It’s not clear whether this uses any of vCider’s technology that Cisco acquired last year. Regardless, Cisco expects InterCloud to support all the typical L4-7 services, interoperate with other vSwitches (though we’re not sure how), and provide service chaining as a feature. InterCloud will GA in the summer and we expect to see Amazon as one of the first cloud partners to support it.

Most relevant to our SDN members is be the unveiling of the OnePK Cisco ONE SDN controller. Much more detail has been revealed on ONE, its Java roots and overall programmatic interfaces. ONE’s marketing-architecture (markitecture) diagram goes a little something like this:

We’ve already seen similar diagrams previously, but in their briefing Cisco provided more details around new controller applications:

• Network slicing (previously announced) - partitioning of the network using logical associations provided by the ONE controller’s centralized view
• Network Tapping (new, and not surprising—sounds familiar to our readers who read our coverage of Big Switch’s announcements) - monitor, analyze, and debug network flows using conventional network switches
• Custom Forwarding (new) – using unique parameters such as low latency to program specific forwarding rules

In addition to the above, Cisco is working on other applications (some with 3rd parties) including traffic engineering, route analysis etc. Cisco is also purportedly using onePK to develop new features internally and the onePK API is supposedly a first-class citizen (i.e. internal applications and external applications see the same APIs, no hidden APIs). Furthermore, the onePK API works within a hybrid control plane model, co-existing with other access to existing switches, including CLIs and XML, and respecting RBAC/AAA already in place. The ONE controller will speak both onePK to Cisco devices, but also support OpenFlow, and has integration points into OpenStack.

The API services that onePK will expose are categorized into 7 base service sets:

The onePK framework provides for additional security via code isolation, application signing, CLI, app isolation and resource consumption control. It’s meant to ensure that applications can’t take down a controller or perform functions they are not meant to perform. When it ships, we’ll see if it meets the necessary security requirements for an SDN framework that were codified by Phil Porras and his team over at SRI in the FortNOX project.

The ONE controller is expected to GA in Q2 and is already in early field trials at various institutions (we know some of our friends in the EDU space are already playing with it).

Our take:

• The NX6000 will allow Cisco to continue to drive its dominance in the datacenter space, particularly with cloud providers and enterprises with sizable private clouds. At the same time, without a complete L4-7 integrated offering, it’s still not a replacement for the venerable Cat 6500.
• NX1000V InterCloud is an interesting addition and provides a basic foundation for an overlay network (not unlike Nicira/VMware) across datacenters—without details on actual performance and capabilities, it’s hard to gauge if it’ll have uptake whether it is a viable defense against VMware’s move into virtual networking.
• Cisco ONE is close to GA reality and it appears that Cisco is sticking to providing a dual protocol offering supporting OpenFlow and onePK. Cisco is definitely investing in the controller platform and looking to ship a comprehensive system with strong application management and security. If we believe their literature, this is positioned to be the first enterprise-class commercial controller platform that is meant to be generic application platform (i.e. not like Nicira’s app-specific NVP). As to the suitability of the northbound APIs for general applications, or the reliability and performance of the southbound controls via both OpenFlow and onePK, no one knows until we see wider trials of the APIs and more discussion in open forums. I do know though that SDxCentral’s lab engineers are eager to get their hands on it.