Plexxi is a SDN company founded by CEO Dave Husak. For those who have been following the SDN market you likely already know about Plexxi. For those who don’t, you can read about them at Plexxi.com. What I find truly interesting about Plexxi isn’t the Plexxi Switch or Plexxi Switch 2, which hasn’t officially launched yet. What I find awesome is the Plexxi Data Services Engine. Before I get into the DSE, let’s build a little Plexxi foundation.
The Plexxi Basics
We know that the networking world consists of hardware and software. Plexxi makes hardware in the form of the Plexxi Switch, and soon to be released Switch2, along with Plexxi Control. What’s neat about the way Plexxi works is that the switches self form into the network with an optical fabric, thus creating a system of switches that operate as one. The switches are then managed through the controller.
The Plexxi Software is a design of policy ponstructs that are similar to a prefix-list or ACL. But to leave it at that would be an unjust act. Derick Winkworth @cloudtoad explained it well at Networking Field Day 6. You can watch the entire video embeded below. For those who choose not to watch the video I’m still going to attempt to break down the elements.
These policy constructs are called Affinity Links, and inside these constructs are Affinity Groups. These are enpoint containers that hold various characteristics of the traffic on the network. You find more than just a prefix in an affinity group. You could find MAC address or prefix, port, VLAN, Subnet and so on. All the meta data about an endpoint is what you would find in an affinity group. These Affinity groups are relative to the policy applied to a conversation.
Now let’s say we want to have communication between two enpoints treated a certain way. We can do that with an Affinity Link. Let’s say we want to control the path to and from a container. We can do that with Affinity Links. Let’s say we want to apply Security ACLs. We can do that with Affinity Links.
The policy is pulled into a Fitting Engine, along with the meta data and is run against the topographical information for the network. Based on those policies and topography Plexxi calcualtes a series of forwarding rules that are scored and then pushed down to the nodes in the network. The best scoring topology becomes the active topology. As you apply policies they are all evaluated to minimize the risk of stepping on previous policies. Plexxi also calculate a series of alternate topologies ready to go if there is a failure.
Policies, Containers, and Endpoints.
So how does Plexxi handle all this information? This is where it gets interesting. The Plexxi software could be used to add all this information. But manually populating the affinities doesn’t scale and isnt “SDN”. So let’s look at the image below.
As so eloquently described by Derick, Plexxi has a pretty good way of handling this. Note that OpenStack, Chef, Plexxi, and an sFlow Archive are depicted in this image, and they all have interrelated data about a specific node. They all present the data in different ways.
I really recommend watching the video because Derick goes into some really good detail here. He also has a swig of Stone IPA, which he claims is a very good beer. (I tend to agree with that)
So this highlights the questions on how easy the data is to access, to get into a usable format, and to know when it’s changed.
So to answer these questions, Plexxi has developed a component of the architecture called the Data Services Engine, and this is really cool stuff!
The Data Services Engine and SDN
The DSE could have a Data Service that keeps certain information in a referencable state. You could later use this information to determine the state of condition of something, and then use this in the applicaiton of your Affinity Links (Think Policy). So essentialy you are asking the infrastructure about some form of data and replies with what it knows. That’s really cool!
Now I put my spin on this. I’m running the DSE in my network, which has a firewall, an IPS, some load balancers and so on. I could gather data about the converstions, types of machines, flow’s and so on, and use that information to apply firewall policy, IPS policy, load balancing rules and so on. The possibilities just keep coming to mind the more you think about the data you can gather.
By the way, this is nothing new in Security. CS-MARS tried to do this by gathering a great deal of information from numerous vendor devices. It integrated with Cisco Security Manager which could then push policy. That was staples and duct tape compared to this.
Take it a step further, throw up multiple DSE’s and publish the services to one another.
I think the DSE is a big deal. By having so much information you can clearly “Control” what’s happening in the network. Things get a little funny though when I step back and put my security hat on again. I can’t help but think of how cool it would be to use the DSE with an ASA and be able to control my modular policy as conditions change. The Problem: Lack of API could be one issue. Lack of protocol support maybe? The ASA could potentially be a source of information to DSE, but it’s not easy to provision remotely. ASDM basically throws CLI commands at the ASA. That’s not how DSE is meant to provision a node I’m sure, but hopefully you get the point.
And there’s more that DSE can do I’m sure. We are just touching the very tip of capabilities we have in the SDN world. SDN has a nice initiative behind it and if others get involved with DSE it could have a huge impact on how we do things in a network. I like it, and I think Plexxi is heading in the right direction.
Plexxi was a sponsor of Networking Field Day 6. In addition to a presentation, Plexxi may have provided marketing material and a tasty unicorn burger (or similar swag). At no time did they ask for, nor where they promised any kind of consideration in the writing of this review. The opinions and analysis provided within are my own and any errors or omissions are mine and mine alone. For more informaiton on Networking Field Day, or any other Field Day for that matter, please visit http://techfieldday.com.