ACI Launch

Tech Field Day brought me to the Cisco Application Centric Infrastructure launch event last week in New York. I attended at someone else's expense, but that doesn't mean my opinions are for sale, etc...

If you're totally unfamiliar with ACI (formerly Insieme), I recommend listening to Episode 12 of the Class C Block podcast with guest Joe Onisick. This was far more informative than anything I encountered at the actual launch event, probably because the Tech Field Day crew went straight from the John Chambers presentation into a room where we recorded a roundtable discussion. There may have been some technical discussion going on next door, but I missed it.

There's no shortage of people expressing opinions about ACI and what it will or won't do for you, most of whom have beaten me to the punch by several days. I'm going to post instead about a few details of the launch that I found interesting.

Defining Policy Might Not Be Easy
ACI requires that applications (really application owners) express to it the relationships between nodes before any traffic is allowed to flow. There are countless ways this might happen, but they all boil down to figuring out which ports on virtual or physical switches need to communicate to make the application run. There are the obvious flows, like the ones between middleware and database, and then the less obvious ones like syslog, DHCP, DNS, RADIUS, etc... All communications will need to be identified to the ACI controller, and I worry that it will turn out to be nontrivial.

While commercial applications generally have their requirements spelled out pretty clearly for firewall purposes, I've found that in-house applications often do not. The application developers know their components, but often don't know what's really happening under the covers. Too often I have conversations about firewall policy that include statements like the following: "It's not UDP or TCP. I keep telling you, I'm using an MQ library!"

Canned Policies?

Somebody (I think it was Pete Welcher?) speculated that software vendors might decide to ship ACI policies with their products. In the same way that we deploy virtual appliances, large software packages could come with canned ACI policies. That would certainly make things easy for rollout of a multi-tier software package onto an ACI environment.

Ultimately, The Policy Expresses What Now?

If I understand things correctly, the policy exists to fit switchports into categories and then to express which categories of ports may talk to one another. The categorization can be based on all sorts of criteria including things that might be reminiscent of firewall policy. The Cisco folks even evoke firewall notions when they explain that the system defaults to no communication: "Hosts can't talk without a policy explicitly allowing it."

The security angle is compelling, but don't confuse it with a packet filter. Think of it more like a policy which assigns assets to VLANs in a router-free environment. Once the assignment is done, any and all communication is possible between assets which have been bucket-ized together. The "express communication requirements to the network in application terms" business isn't a packet filter.

About ASICs

Cisco's "merchant silicon plus" strategy with the Nexus 9500 speaks volumes about the future of packet forwarding hardware. There's a proud tradition of using in-house ASICs at Cisco, and they're backing away from it. Sure, they're shipping ACI-specific hardware along with the Broadcom Trident II. It does things that the Broadcom Trident II can't do, like routing between VXLAN and NVGRE overlays. I'm betting that the ACI-specific hardware will sit completely idle at a large percentage of customers, meaning that the Nexus 9500 is a commodity switch running stripped down (there was a slide about this, but I can't find a citation - edit: Gideon Tam shares this slide from the presentation) version of NX-OS.

Fabric Modules

Nexus 7000 fabric modules aren't much to look at. They're inexpensive (compared to the rest of the platform components), don't generate much heat, etc... Nexus 9500 represents a big departure from the arbiter-controlled fabric of the 7000 series, because they've got switching ASICs (two to four Trident IIs per fabric module) onboard, making the Nexus 95xx a "clos-in-a-box" architecture. I'm anxious to see the packet walk for multicast and broadcast traffic from the Cisco Live presentation next year.

No Midplane

Apparently the 9500 is entirely open from front to back, which is new for Cisco. I guess the line cards and fabric modules connect directly to one another (I haven't seen it yet). This is nifty, because it allows front-to-back airflow without lots of crazy ducting like the Nexus 7010, which seems like it's half duct/half switch.

BiDi Optics

This is cool stuff. Is it unique to Cisco? There's no QSFP module with an LC connector listed on Finisar's site right now.

These modules run 40Gb/s Ethernet for up to 150m over just two strands of MMF. Prior to the introduction of this module, 40Gb/s Ethernet required a 12 strand MPO connector. I've been advising customers for years to populate their data centers with pre terminated MPO stuff, I particularly like the high density offerings from Corning.

Customers who already have MPO don't have any worries, but for folks with minimal LC connectors at top of rack, Cisco claims their QSFP-40G-SR-BD module is a big cost saver because no new fiber needs to be installed for the upgrade from 10Gb/s to 40Gb/s. Yes, the idea of saving money with Cisco optics is hilarious. :) Pricing isn't out yet.

Stuff Spirent didn't cover at NFD6

Spirent presented their Avalanche NEXT product at Gestalt IT's Network Field Day 6 event in September of this year.

Disclaimers:

1. I attended the event, somebody else picked up the tab, yada yada.
2. I like Spirent. I've used their products, worked with their people and been to their offices several times, and have gradually become a fan. This fact might be coloring my opinions :)

What's Avalanche NEXT?

Avalanche NEXT is a software frontend for performing tests of security hardware (firewalls and whatnot). It's a modular system that allows simple creation of test components (clients, servers, subnets, protocols, etc...), mixing of modules to create various tests, scaling of the test, application fuzzing, etc... Check out 1:14 - 1:30 in the video below to get a flavor of how slick the interface is. I love that interactive pie chart.

This sort of testing is critical because security devices have some of the most misleading data sheets of anything we're likely to work with as network folks. Security box performance numbers depend heavily on what you're asking them to do. Will your current device survive if you enable SSL offload, application inspection, or similar features? You can try it out (fingers crossed!), or you can test.

If you're interested in the NFD presentation on Avalanche NEXT, check out the Tech Field Day page.

So, what didn't Spirent tell us at NFD6?
Two things jumped out at me as deserving more attention than they got during the presentation.

PCAP replay?
The Spirent folks explained that you could use the tool to run canned synthetic traffic through a firewall, or you could load your PCAPs of your own applications into the tool, and replay those.

It sounds straightforward, but I think they're underselling this feature, or at least glossing over how much is going on under the hood. This is nothing like dumping data onto the wire with TCPreplay, for example. Even in the simplest case of a generic TCP application, to play captured data through a firewall, they need to:

• Extract application transactions from the captured data
• Setup new transactions with unique 5-tuple identifiers
• Speak independently on behalf of both the client and server
• Process TCP and IP data independently, taking into account the mangling done to it by the device(s) under test: loss/fragmentation/segmentation/etc...

Factor in application-layer awareness, like rewriting SIP invites to include the correct synthetic client ID and you're dealing with new stuff throughout every layer of the stack, and (so they say), doing it at line rate with 10Gb/s interfaces.

It's way more complicated and interesting than merely "playing back pcaps" at high rates, and it's awesome.

VPN?

The Spirent guys focused their presentation on testing the transit ability (packet forwarding and deliberate dropping) of security appliances, but didn't mention that they can also do VPN stuff. Testing site-to-site VPN is obvious: just get two of the appliances, configure them, and blast application traffic through the tunnel.

It turns out that Spirent can also run these test suites from thousands of (simulated) VPN users. This is the capability that was most interesting to me because of a network I'm working on these days. Apparently they can simulate several types of VPN user, including Cisco AnyConnect clients. With this sort of test, the VPN believes that many users are online, and they all run the Spirent-controlled suite of application tests.

Tests I was previously familiar with include:

• Transit load testing (throughput/latency type stuff)
• Application server loading and fuzzing
• Synthetic network devices (1000 OSPF neighbors-in-a-box)

Synthetic VPN users, each running synthetic application load was a new one on me, and is relevant to my network.

SDN Themes from ONUG - Community Matters!

I was privileged to attend the Open Networking User Group (ONUG) Conference, ONUG Academy and mini Tech Field Day event hosted by JP Morgan Chase on October 29 and 30.
I attended at someone else's expense. Disclaimer. Additional disclaimer: I have a personal relationship with one of the people behind the ONUG conference. That fact will not color the opinions I express about ONUG. If I say I like something, it's because I like it, okay? :)

SDN Joke from Brent Salisbury's awesome ONUG
presentation.
I don't know these cats nor the owner of the photo.

Community Matters
ONUG is founded on the idea that the Software Defined Network (SDN) user community needs to stand up for itself. Prior to ONUG the direction of SDN was set by a handful of players including:

• Vendors who are interested in shaping the SDN marketplace and standards bodies around the capabilities of their products, rather than around the problems being faced by their customers.
• Powerful end users who needed SDN to solve their own peculiar problems. The problems they're solving, and the techniques they're using do not align well with the challenges nor capabilities of mere enterprise users.
• Researchers, who took SDN in directions that were academically interesting but didn't necessarily overlap with real world problems.

ONUG provides a forum where end users of network technology can contemplate the promise of SDN,  commiserate about challenges faced, unmask the realities of available offerings, and gain new perspective on the marketplace in a user-centered environment.

Vendors and media were not welcome in many of the discussions, giving typically taciturn customers (especially the financial folks) some freedom to talk openly about their experiences. Real customers talking about real environments proved to be a strong antidote to vendor propaganda. I'm sure that everyone who attended left with something new: knowledge, friends, contacts, perspective, business, etc...

Without ONUG, we'd be forced to buy what the vendors are selling. ONUG shouldn't be missed because it unifies a potentially vocal community which will shape the SDN marketplace.

If you're interested in SDN, you should probably be attending ONUG conferences.