In Network Evolution, SDN

I remember the first times I thought technology was really cool or important.  It’s been a long journey since those days, and while some tech has kept my geek meter from zeroing out, I’ve slowly started to become the crusty, bearded, over nostalgic nay-sayer of many new things.  That is, until I first understood what Plexxi was doing.  For the first time in a very long time I’m in that wonderful place where the biggest problem is choosing amongst all the things that are possible.  Let’s start from the beginning though…

A long time ago in a galaxy far, far away….

Way back when I was 7 years old, and sadly beardless, I remember watching the original Star Wars.  In that movie there is a scene where R2D2 hacks in to a console of the Death Star.  A 3D wireframe map of the empire’s deadly ship appeared.  R2D2 navigated this map to find the location of Princess Leia.  I remember thinking to myself how awesome it would be, even if remotely possible, if a robot could hack another system.  At the time, the wireframe map was insanely cool too, even though it was monochrome.  Arguably, this scene was a defining moment for me and my life long affair with technology.

Let’s fast forward to 2013.  I’ve been a developer, operator, engineer, and architect through the years.  I can say this with absolute certainty:  Automating a network is really hard to do.  You need a component that can figure out the topology (actually, multiple layers topologies!) and calculate paths through it according to a set of constraints.  This is made especially harder when dealing with the bag of protocols and layers associated with legacy technologies.  Adding another layer of complexity to the problem is the need for a multi-vendor solution.  Even with newer SDN technologies, this isn’t substantially easier for the average network person or even the average DevOps person.  The math is really hard.  That, and, regardless of the underlying technology, solutions must be consumable by humans.  By “humans” I mean people other than just super-geeks and hardcore engineers.  “Barely functional and unbelievably cryptic” is no longer acceptable.  As with other areas of IT and technology in their lives, people want their network to work for them, not the other way around.

So, all we have to do is:

  1. Automate network provisioning and operations
  2. for an inherently distributed multi-vendor system
  3. and present the user with an intuitively simple way of interacting with it
  4. using the semantics of the systems, applications, and services the network supports.

Couldn’t be easier, right?  Plexxi is working hard to do exactly this.  Having been on the customer side for 17 years, let me tell about some of the things at Plexxi that really have me excited about technology again!

The Affinity

First, Plexxi has managed to describe, at the most fundamental level, what the purpose of a network is.  This is called an Affinity.  What is an Affinity?  Let’s oversimplify this initially and say that an affinity is a way to describe that some set of “things” must talk to some other set of “things” in a certain “way.”  In effect, we are describing a conversation.  Currently that means some endpoints attached to the network, identified by their MAC addresses, must talk to some other endpoints.  When we say “a certain way” we mean that the path of this traffic should have certain properties.   For instance, the path should be isolated from paths that are carrying traffic for other affinities, or the path should have a minimal hop-count.  Can you imagine being able to tell the network “these web servers talk to these load-balancers” or “these phones talk to this IP PBX, isolate this traffic” and have it be so?  “This stuff needs to talk” forms the basis of all network requests.  Affinities allow you to tell the network what you need it to do in simple, intuitive terms.  Affinities can be controlled and monitored and reported on as first class citizens of your network, too.  Did I mention Affinities can be automatically discovered in various ways?

Self Documentation

This leads me to the second thing:  Imagine, a self-documenting network that not only tells you the structure of your network but can help you understand application data-flows passing through it.  Are there any developers out there that remember “Data Flow Description” documents?  We haven’t had those in a while, at least not in a meaningful way.  Now we can have these made for us automatically!  Let’s be honest, here.  In a lot of environments people don’t know what endpoints are having conversations, much less exactly what ports or protocols are being used.  Having a tool that can help us identify this is enormously powerful, especially when stuff is broken or when auditors are “bringing the pain.”


While Affinities and Self-Documentation are great, it’s not helpful if they only deal in network semantics.  We are building a library of connectors that will enable operators and automation teams to use semantics native to systems and applications connected to the network.  Instead of specifying MAC addresses in your policy, for instance, you can specify VM names.  Connectors for SAN systems, IP PBX’s, server systems, EC2, or anything you can think of, are all possible.  If we can’t get to it fast enough, then any sufficiently motivated operator or DevOps team could get there first using Python.  Diagrams produced via self-documentation can be decorated and enriched with meaningful information extracted from other IT systems, rather than just IP and MAC addresses.  The Plexxi framework is built for this kind of extensibility.


Lastly, the Plexxi solution has been built from the ground up to be programmable.  Imagine my geek delight when, after 20 minutes of fiddling with the controller CLI, I realized (duh!) that it was a Python shell with a network-wide view of the Plexxi switches, including what is attached to them.  Now you can write Python scripts that do really cool things.  What if you could find the location of an endpoint in your network using contextualization?  For instance, “tell me where phone extension x4-7711 is” or “tell me where any rogue Linksys MAC addresses are.”  The fact that the controller has knowledge of the whole network makes writing such scripts trivial.  A hacker with a little more ambition might find the set of paths between two sets of end points and search for any interface errors or drops:  “tell me if there are errors between database servers with these tables… and the storage devices holding those tables.”

I’ll close with this question: If the network truly worked *for you,* what would you have it do?  Let me know, because my goal is to do exactly that:  I want the network to work for you, truly.  Once again, I feel like anything is possible.  Failure only means we didn’t avail ourselves of this opportunity.  Talk to us, leave comments, and let us share this excitement with you!

Leave a Comment

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Start typing and press Enter to search