Over a million developers have joined DZone.

Cisco’s Insieme, Revealed at Last: All Your Policy Are Belong to Us

DZone's Guide to

Cisco’s Insieme, Revealed at Last: All Your Policy Are Belong to Us

· ·
Free Resource


It’s finally here.

After tantalizing the industry for more than 18 months, Cisco is revealing the software-defined networking (SDN) products and plan that Insieme has been working on. As expected, the spin-in is producing a new switch family, the Nexus 9000.

But the real star of Insieme’s show is the Application Policy Infrastructure Controller (APIC), the central brains for policy, configuration, and management. APIC is a data-center fabric, setting up connections between switches — but it also assigns and sometimes enforces policy, doing so automatically by watching the health of the network. It’s a software-based command center.

It’s the APIC that really drives Cisco’s Application-Centric Infrastructure (ACI), although there’s a catch: ACI won’t be available until the second quarter of 2014. It also requires a software upgrade, even on the Nexus 9000s.

In the meantime, what Insieme has are some but not all of the Nexus 9000 family: the 9396PX and 93128TX top-of-rack switches, and the 9508 chassis, which are available immediately (or within days of the launch, at least, Insieme says). In general, the 9000s extend the Nexus family to 40 Gb/s and add some new features — but they do so by running an enhanced version of Cisco’s NX-OS operating system. They’re also line-card-incompatible with the Nexus 7000s.

In that sense, Insieme did what a good startup would do: It went for the jugular to disrupt someone’s existing franchise.

Cisco had dropped hints in June that made it sound like it will support two data-center models, one being Insieme, the other being the installed base running what’s called Dynamic Fabric Automation technology. It’s now clear that they are indeed separate models, and while the presence of that huge installed base makes this separation necessary, it’s going to be a lot of baggage for Cisco to carry.

Insieme is nonplussed about all this. “Internal to Cisco, it really looks like another product introduction,” says Ish Limkakeng, Insieme’s vice president of product management.

Oh, by the way: For all its badmouthing of network overlays, Insieme is using VXLAN, the encapsulation protocol that’s used for building overlay networks. It’s an ACI-internal protocol and not an endorsement of the overlay model, Insieme says.

Interlude: Insieme Gets Spun In

Amid all this hubbub, Cisco is also announcing that it’s acquiring Insieme — which is no surprise, of course. The release doesn’t suggest when the deal might close. Cisco owned 84 percent of Insieme as of September, according to an SEC filing.

In the end, the total purchase price for Insieme will have been $863 million or less, depending on the revenues Insieme generates. Cisco has put $135 million into the spin-in so far.

Policy: How APIC Drives Cisco’s ACI

Policy is crucial to SDN. Cisco CTO and Chief Architect David Ward said as much in early 2012, shortly after Insieme’s existence became known. If the network understands and can apply policy, then it can automatically provision services and, when necessary, move them around the cloud, all without the user or the IT department doing anything.

Those jobs fall to APIC. In addition, it can handle network inventory and software upgrades, and it’s the place for partners’ northbound and southbound interfaces to tap into Cisco’s ACI. It’s a busy little element.

At its lowest level, though, APIC is a fabric, one that can knit connections between any of 1 million endpoints stored in a database. These connections are 40-Gb/s tunnels between leaf and spine switches, built using VXLAN.

APIC oversees all. Image source: Cisco. APIC oversees all. Image source: Cisco.

APIC is also aware of network policy — which includes such factors as quality-of-service and security requirements — and that’s where things really get interesting.

In ACI, policy is divorced from the network infrastructue. Instead, ACI creates policy profiles for services and distrubutes them around the network, tying the same policy to app instantiations running on physical or virtual gear.

This ought to simplify things, Insieme says. The IP network normally shoulders the policy burden in the form of access control lists (ACLs) that build up over time. Under ACI, policy is inherent to the application and is applied automatically if desired. Policy can also be built into configurations created through tools such as Puppet and Chef.

Defining that policy can be done in a number of ways — through ACI extensions to OpenStack or to the OpenDaylight controller, for instance.

What you don’t have to do is send a service request through multiple departments — server teams and storage teams, for example. “What we allow is the collaboration of these IT teams into more of a DevOps model,” or at least allow them to work in parallel, Limkakeng says.

A Partner Ecosystem

Insieme does not expect to go it alone with this policy stuff. Part of Wednesday’s launch is an ecosystem of partners that provide input to, or make use of, ACI’s policy.

Management and orchestration tools could provide APIC with information to help run the network, for instance. Or, in the other direction, APIC could configure other vendors’ Layer 4-7 services based on its policy database.

Insieme is stressing the openness of this ecosystem. The APIC data model is available on open-source terms, and of course the APIs are available to partners. The goal is to build a community of developers around ACI, Limkakeng says — but of course, it all comes back to Insieme’s software sitting in the conductor’s chair.

Oh Yeah … The Nexus 9000s …

Finally, we get to the actual Nexus 9000 switches, the first of which should be shipping within days of this article going to press, or possibly earlier, Limkakeng says.

As noted above, the Nexus 9000 is running an “optimized” version of NX-OS, as Cisco phrases it. The Nexus 7000s will get access to this version after Insieme gets acquired.

But all Nexus switches, even the 9000 family, will require a software upgrade to get to “ACI mode,” where they’ll participate in ACI and work with Insieme’s APIC. Since APIC isn’t available until the second quarter of 2014, it seems reasonable to say ACI mode won’t be available until then either.

Not all Nexuses (Nexi?) will get upgraded to ACI mode. Presumably, many owners of Nexus 7000s just want a 40-Gb/s upgrade without all this SDN claptrap. Long-term, they’ll keep using “standalone” NX-OS mode, Limkakeng says.

The Nexus 9000 family is based on Insieme-designed ASICs, but they also use merchant chips, mainly for “rear-view mirror” functions, as Soni Jiandani, Insieme’s senior vice president, revealed in June. These are presumed to be Broadcom’s new Ethernet switch chips, the Trident II line that’s also being used by Arista, white-box vendors, and a host of others.

Initially, Insieme is shipping three switches:

  • Nexus 9396PX — A fixed-configuration switch with 48 10-Gb/s ports and 12 40-Gb/s ports.
  • Nexus 93128TX — Another fixed-cofniguration switch: 96 10-Gb/s ports and eight 40-Gb/s ports. Both of these switches aim for top-of-rack or middle-of-row deployments.
  • Nexus 9508 — a modular, eight-slot switch fitting in one-third of a 7-foot rack. At most, it can fit 1,152 10-Gb/s ports or 288 40-Gb/s ports.

More varieties of Nexus 9000s should start shipping during the next six months:

  • More end-of-row and top-of-rack 10-Gb/s switches in the first quarter of 2014
  • 40-Gb/s fixed and modular spine switches in the second quarter of 2014.

In the second half of 2014, Insieme will start bringing Cisco’s gear into the equation, integrating Cisco’s Unified Computing System (UCS), for example. Around this time, the Nexus 7000 and ASR 9000 will become configurable via the APIC and will be usable as leaves in an ACI leaf-spine arrangement.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}