Seeing Tetration in action – NFD16

One of the highlights of Network Field Day 16 was a Cisco Tetration presentation by Tim Garner. Launched by Cisco last June, Tetration is a heavy lifting, data crunching platform that soaks up telemetry on all your network packets, uses machine learning algorithms on that data, and produces security policies templates based on the flow information received. This process gives engineers in-depth analytics, an impressive level of visibility, and supplies automagically crafted baseline security policies.  The latter truly shines when you are working with developers and application owners who have absolutely no clue what server needs to talk to what other server(s), much less what ports are required to do so securely.

With Tetration, you can use hardware sensors in the form of Nexus 9K switches with an -X in the SKU, or you can use software agents that can be installed just about anywhere. Or you can use a combination of both.  These sensors look at every single packet going in and out and generate telemetry packets that get shuffled off to Tetration where the real magic happens.

In addition to software agents and hardware sensors that natively generate Tetration metadata packets, you can also stream data from load balancers, firewalls, and other networking devices.  Some devices such as Citrix and F5 are natively supported, but others might take your doing a little work to get the data into a format that Tetration will accept – JSON being one of the acceptable formats.

Another interesting option for getting metadata into Tetration is the use of virtual machines set up as ERSPAN destinations.  Each VM can take in up to 40 gig of traffic, generate telemetry data for this traffic, and stream the data to the Tetration cluster.  Tetration can also take in NetFlow data using this VM method as a NetFlow receiver. NetFlow data is sampled though, so Tetration would not be seeing metadata on every packet as with the other options listed.

Once the data gets to the Tetration cluster, the snazzy machine learning algorithms built into the box start telling you cool things like what hosts are talking to what hosts and what “normal” network behavior looks like, and thereby, what abnormal network behavior would look like.

If your development servers should never be talking to your production servers, Tetration can tell you not only if that what’s happening now, but also if that behavior changes in the future.  Using a Kafka broker* you can have Tetration feed notifications to applications such as Splunk or Phantom, which can in turn communicate with hardware and software devices that perform actions such as host isolation when anomalous traffic is detected.

The automatic whitelists built by Tetration will require some care and feeding by an engineer. Importing policies from ACI is also an option as well. Tetration generated whitelists can be reviewed and tweaked, and an audit of what will be blocked when implementing or making policy changes is an excellent job preserving idea. Checking policies against the four to six months of network traffic data stored by the cluster gives you a good sense of what to expect when enforcement is actually turned on. That being said, you can also run your policies in audit mode for a few months to see what traffic hits the crafted policies.

If you want to see Tetration in action, I highly recommend this video below. The demo starts at about 16 minutes, but Tim Garner is such an excellent presenter, you’ll be glad you watched the whole thing.


*Kafka broker service was new to me, basically it’s a notification message bus, I used a few of these links below to get the idea:


Disclaimer: While Networking Field Day, which is sponsored by the companies that present, was very generous to invite me to this fantastic event and I am very grateful for it, my opinions are totally my own, as all redheads are far too stubborn to have it any other way.


Published 10/6/2017


Urban sprawl – New York city is the quintessential example of this phenomena. Why do I bring it up?  One, because I’m currently writing this from a not-so-cushy chair in the bloggers lounge of Interop, hosted in New York.  Two, because it’s the image that for a couple reasons comes to mind while processing all of the information that have been dumped into my overly saturated brain this week.

Reason one this comes mind: network sprawl. Networks just keep growing and growing, constantly bombarded with changes that risk the comforting hierarchal design allowing us OCD geeks to sleep at night.  Every time we wake someone else is demanding we modify our rock solid architecture to incorporate some new fangled something or other.  We grudgingly graft these new devices/endpoints/services into our designs but at a cost. In not too long, our once pristine work of art starts to strongly resemble the monster in Shelley’s Frankenstein – and frankly, we as geeks resent it.

Reason two this comes to mind: networking company sprawl.  Sounds odd, I know, but it’s an apt description when pondering the large, big name, been-around-forever, companies that we’re all familiar with in the networking community. These large companies are all faced with an exigent need to be innovative and encumbered by the weight of supporting past business decisions.  The sheer extent of the empire often results in a series of disjointed business units, complex product lines, incomprehensible licensing models, isolated pools of talent, and a customer base sitting on the edge of their chairs waiting anxiously to see how it all falls out. For the record, we geeks intensely resent this as well.

So when companies like HP Networking announce they are simplifying their product names, I perk up. It’s an immediate sign that someone, somewhere realized that sprawl has gone unchecked for too long and monster creation needs to be mitigated. Hints of such recognition have also been made by other big players, including Cisco, and every time I hear it I get giddy.  I dream of a world with simplified licensing models, BOMs that don’t take a PhD to comprehend, and companies with clearly articulated, streamlined direction. In a word, focus.

I’ve only seen hints though.  I want to see more.  Simplifying product names represents an awesome step in the right direction.  Now how about eliminating confusing redundant products? Cisco’s stance on getting back to core competencies sets my heart a flutter, now how about eliminating cripplingly complexities in the licensing models?

I love that HP Networks invited myself and other front line engineers to their briefings and honest feedback was both requested and given.  I’m sure they are not the only company doing so and for good reason. Listening to the folks doing the implementations can only help in the attempts to narrow focus and reclaim simplicity in the business.

Letting geeks in on company direction is a total win as well.  As geeks we know that change is constant, technology is always in flux, and everyone is just guessing at the next big thing.  We can handle that.  What we can’t abide is a lack of direction, goals, a sense of purpose in all the chaos.  In the words of Douglas Adams “we demand rigidly defined areas of doubt and uncertainty.” So bring us in, spill the beans, and we’ll be more than happy to help you sort through it all.  It’s what we do every day, it’s in our nature, and the results are a windfall for those who seek us out. Leave us in the dark, make us guess, send mixed messages and we’ll drop you like a bad habit. It’s what we do.

For some more great coverage of HP and Interop, check out these bloggers whom I had the great honor of meeting this week as well. I can confirm they are all fabulously awesome in meatspace too:

Aaron Paxson

Andrew VonNagy

Brad Casemore

Ethan Banks formerly at

Matthew Norwood

Stu Miniman

*A special thanks to @hp_networking who took excellent care of us bloggers, always keeping us fed and in constant supply of caffeine.