The OpenFlow Longbow

Posted on November 25, 2013 by networkingnerd

carck_longbow

The label of disruption seems to be thrown around quite a bit. I’ve heard tablets being called the disruptive technology when it comes to PCs. I’ve also heard people talking about software defined networking (SDN) as the disruptive technology to the way that we’ve been doing networking for the last decade. Nowhere is that more true than with OpenFlow. But what does this disruption mean? Aren’t we still essentially forwarding packets the same way we have in the past? To get a frame of reference, let’s look at one of my favorite disruptive technologies – the longbow.

Who Are Yew?

The Welsh yew longbow had been a staple of the English military as far back as 600AD. The recurve shape of the bow provided for a faster, longer arrow flight than the shorter bows used by foot soldiers and mounted calvary. The wood was especially important, as the yew tree was only really found in abundance in Wales. Longbows existed in one form or another in many armies in Europe, but the Welsh bow was the only one that was feared.

The advantage was never more apparent than during the Hundred Years War between England and France. The longbow was deployed as a mid-range artillery to harass advancing troops. There are questions about whether or not the arrows were able to pierce the plate armor used by knights at the time, but the results of archery corps can’t be denied. Especially in the Battle of Agincourt. The English used longbows to slow the advance of French forces in armor, tiring them out as they crossed the field and holding them at bay until the heavier foot soldiers of the English army could be repositioned to take the advancing enemy apart. Agincourt was a win for the English and fives years later, the war was over.

The longbow proved itself to be a very disruptive technology. Not because it killed soldiers better or faster than a mace or broadsword. It was disruptive because it changed the way generals composed their armies. Instead of relying on heavy assault troops in armor to punch a hole in the enemy lines, the longbow forced a soldier to become more mobile with less armor to be able to cross the range of the bow much more quickly and close to a range where the technology advantage was negated. Bowmen were at a distinct advantage at point-blank range. Armies grew more mobile all the way up to the point where a new technology disrupted the reign of the longbow: gunpowder. Once musketeers became more prevalent, they replaced the role traditionally held by the longbow archer.

Disrupting the Flow

How does this history lesson apply to OpenFlow? OpenFlow is poised to disrupt networking in the same way as the longbow forced people to take a new look at their armies. OpenFlow takes something we know about and turns it on its head. It gives us much more control over how a switch forwards packets. It also makes us ask questions about how we build our networks.

Questions about big core switches, spine-and-leaf topologies, and the intelligence of edge devices all become very pertinent in an OpenFlow design. Should I put a larger switch at the edge since it’s going to be doing a lot of heavy lifting? Should I use a fabric in place of a three-tier design? Will my controller allow me to use different interconnects to ensure high-speed traffic flows east and west in the data center?

OpenFlow is taking over some vendors offerings. NEC and HP have already committed to OpenFlow designs. Even companies that haven’t really embraced OpenFlow have decided to offer it rather than dismiss it. Arista and Cisco are offering new switches that have support for OpenFlow, even if that support may not extend to more proprietary enhancements right now. Just like the longbow, OpenFlow is forcing the opposition to reconfigure the way they fight the battle. They may not like it. They may even say in private that they’re just doing it to mollify a part of the customer base looking for specific points in an proposal. But they are still dedicating time and effort to OpenFlow all the same.

Tom’s Take

Disruption happens all the time. We don’t use cell phones in bags hardwired into our vehicles any more. Our computers are the size of a broom closet and run off of punch cards. Just like weapons in the ancient world, whoever comes up with a more effective way of winning battles enjoys a distinct advantage for a time. Eventually, something comes along that disrupts the disruption. OpenFlow is currently the king of the SDN battlefield. It holds that title by virtue of how many people are racing to interoperate with it. Eventually, it will be dethroned just as the longbow was. They key will be recognizing the next new thing first and using it to your advantage. And arming your archers with it.

Should Microsoft Buy Big Switch?

Posted on November 4, 2013 by networkingnerd

MSBSN

Network virtualization is getting more press than ever. The current trend seems to be pitting the traditional networking companies, like Cisco and Juniper, against the upstarts in the server virtualization companies, like VMware and OpenStack. To hear the press and analysts talk about it makes one think that these companies represent all there is in the industry.

Whither Microsoft?

One company that seems to have been left out of the conversation is Microsoft. The stalwarts of Redmond have been turning heads with their rapid pace of innovation to reach parity with VMware’s offerings. However, when the conversation turns to networking Microsoft is usually left out in the cold. That’s because their efforts at networking in the past have been…problematic. They are very service oriented and care little for the world outside their comfortable servers. That won’t last forever. VMware will be able to easily shift the conversation away from feature parity with Hyper-V and concentrate on all the networking expertise that it has now that is missing in the competitor.

Microsoft can fix that problem with a small investment. If you can innovate by building it, you need to buy it. Microsoft has the cash to buy several startups, even after sinking a load of it into Nokia. But which SDN-focused company makes the most sense for Microsoft? I spent a lot of time thinking about this very question and the answer became clear for me: Microsoft needs to buy Big Switch Networks.

A Window On The Future

Microsoft needs SDN expertise. They have no current networking experience outside of creating DHCP and DNS services on their platforms. I mean, did anyone ever use their Network Access Protocol solution as a NAC option? Microsoft has traditionally created bare bones network constructs to please their server customers. They think networking is a resource outside their domain, which coincidentally is just how their competitors used to look at it as well. At least until Martin Casado changed their minds.

Big Switch is a perfect fit for Microsoft. They have the chops to talk OpenFlow. Their recent shift away from overlays to software on bare metal would play well as a marketing point against VMware and their “overlays are the best way” message. They could also help Microsoft do more development on NV-GRE, the also ran to VxLAN. Ivan Pepelnjak (@IOSHints) was pretty impressed with NV-GRE last December, but it’s dropped of the radar in the wake of VMware embracing VxLAN in NSX. I think having a bit more development work from the minds at Big Switch would put it back into the minds of some smaller network virtualization companies looking to support something other than the de facto standard. I know that Big Switch has moved away from the overlay model, but if NV-GRE can easily be adapted to the work Big Switch was doing a few months ago, it would be a great additional offering to the idea of running everything in an SDN-enabled switch OS.

Microsoft will also benefit from the pile of SDN applications that Big Switch has rumored to be sitting around and festering for lack of attention. Applications like network taps sell Big Switch products now. With NSX introducing the ideas of integrated load balancers and firewalls into the base product, Big Switch is going to be hard pressed to charge extra for them. Instead, they’re going to have to go out on a limb and finish developing them past the alpha stage and hope that they are enough to sell more product and recoup the development costs. With the deep pockets in Redmond, finishing those applications would be a drop in the bucket if it means that the new product can compete directly on an even field with VMware.

Building A Bigger Switch

Big Switch gains in this partnership also. They get to take some pressure of their overworked development team. It can’t be easy switching horses in mid-stream, especially when it involves changing your entire outlook on how SDN should be done. Adding a few dozen more people to the project will allow you to branch out and investigate how integrating software into your ideas could be done. Big Switch has already done a great job developing Project Floodlight. Why not let some big brains chew on other ideas in the same vein for a while.

Big Switch could also use the stability of working for an established company. They have a pretty big target on their backs now that everyone is developing an SDN strategy. Writing an OS for bare metal switches is going to bring them into contention with Cumulus Networks. Why not let an OS vendor do some of the heavy lifting? It would also allow Microsoft’s well established partner program to offer incentives to partners that want to sell white label switches with software from Big Switch to get into networking much more cheaply than before. Think about federal or educational discounts that Microsoft already gives to customers. Do you think they’d be excited to see the same kind of consideration when it comes to networking hardware?

Tom’s Take

Little fish either get eaten by bigger ones or they have to be agile enough to avoid being snapped up. The smartest little fish in the ocean may be the remora. It survives by attaching itself to a bigger fish and providing a benefit for them both. The remora gets the protection of not being eaten while also not taking too much from the host. Microsoft would do well to setup some kind of similar arrangement with Big Switch. They could fund future development into NV-GRE compatible options, or they just by the company outright. Both parties get something out of the deal: Microsoft gets the SDN component they need. Big Switch gets a backer with so much industry clout that they can no longer be dismissed.

SDN and NFV – The Ups and Downs

Posted on August 26, 2013 by networkingnerd

TopSDNBottomNFV

I was pondering the dichotomy between Software Defined Networking (SDN) and Network Function Virtualization (NFV) the other day. I’ve heard a lot of vendors and bloggers talking about how one inevitably leads to the other. I’ve also seen a lot of folks saying that the two couldn’t be further apart on the scale of software networking. The more I thought about these topics, the more I realized they are two sides of the coin. The problem, at least in my mind, is the perspective.

SDN – Planning The Paradigm

Software Defined Networking telegraphs everything about what it is trying to accomplish right there in the name. Specifically, the “Definition” part of the phrase. I’ve made jokes in the past about the lack of definition in SDN as vendors try to adapt their solutions to fit the buzzword mold. What I finally came to realize is that the SDN folks are all about definition. SDN is the Top Down approach to planning. SDN seeks to decompose the network into subsystems that can be replaced or reprogrammed to suit the needs of those things which utilize the network.

As an example, SDN breaks the idea of switch down into things like “forwarding plane” and “control plane” and seeks to replace the control plane with alternative software, whether it be a controller-based architecture like OpenFlow or an overlay network similar to that of VMware/Nicira. We can replace the OS of a switch with a concept like OpenFlow easily. It’s just a mechanism for determining which entries are populated in the Content Addressable Memory (CAM) tables of the forwarding plane. In top down design, it’s easy to create a stub entry or “black box” to hold information that flows into it. We don’t particularly care how the black box works from the top of the design, just that it does its job when called upon.

Top Down designs tend to run into issues when those black boxes lack detail or are missing some critical functionality. What happens when OpenFlow isn’t capable of processing flows fast enough to keep the CAM table of a campus switch populated with entries? Is the switch going to fall back to process switching the packets? That could be an big issue. Top Down designs are usually very academic and elegant. They also have a tendency to lack concrete examples and real world experience. When you think about it, that does speak a lot about the early days of SDN – lots of definition of terminology and technology, but a severe lack of actual packet forwarding.

NFV – Working From The Ground Up

Network Function Virtualization takes a very different approach to the idea of turning hardware networks into software networks. The driving principle behind NFV is replication of existing technology in a software state. This is classic Bottom Up design. Rather than spending a large amount of time planning and assembling the perfect system, Bottom Up designers tend to build as they go. They concentrate on making something work first, then making their things work together second.

NFV is great for hands-on folks because it gives concrete, real results almost immediately. Once you’ve converted an load balancer or a router to a purely software-based construct you can see right away how it works and what the limitations might be. Does it consume too many resources on the hypervisor? Does it excel at forwarding small packets? Does switching a large packet locally cause a fault? These are problems that can be corrected in the individual system rapidly rather than waiting to modify the overall plan to account for difficulties in the virtualization process.

Bottom Up design does suffer from some issues as well. The focus in Bottom Up is on getting things done on a case-by-case basis. What do you do when you’ve converted all your hardware to software? Do your NFV systems need to talk to one another? That’s usually where Bottom Up design starts breaking down. Without a grand plan at a higher level to ensure that systems can talk to each other this design methodology falls back to a series of “hacks” to get them connected. Units developed in isolation aren’t required to play nice with everyone else until they are forced to do so. That leads to increasing complex and fragile interconnection systems that could fail spectacularly should the wrong thread be yanked with sufficient force.

Tom’s Take

Which method is better? Should we spend all our time planning the system and hope that our Powerpoint Designs work the right way when someone codes them in a few months? Or should we say “damn the torpedoes” and start building things left and right and hope that someone will figure out a way to tie all these individual pieces together at some point?

Surprisingly, the most successful design requires elements of both. People need to have a basic plan at the least when starting out on a plan to change the networking world. Once the ideas are sketched out, you need a team of folks willing to burn the midnight oil and get the ideas implemented in real life to ensure that the plan works the right way. The guidance from the top is essential to making sure everything works together in the end.

Whether you are leading from the top or the bottom, remember that everything has to meet in the middle sooner or later.

A Guide to SDN Spirit Animals

Posted on July 18, 2013 by networkingnerd

The world of computers and IT has always been linked with animals. Whether you are referring to Tux the Penguin from the world of Linux or the various zoological specimens that have graced the covers of the O’Reilly Media library you can find almost every member of the animal kingdom represented. Many of these icons have become mascots for their users. In the world of software defined networking (SDN), we have our own mascot as well. However, I’m going to propose that we start considering a few more as well.

The Horned Wonder

If you’ve read any kind of blog post about SDN in the last year, you’ve probably seen reference to a unicorn at some point. Unicorns are mythical creatures that are full of magic and wonder. I referenced them once in a post concerning a network where I had trouble understanding how untagged packets were traversing VLANs without causing a meltdown. When the network admin asked me how it was happening I replied, “They must be getting ferried around on the backs of unicorns!” That started my association of magical things happening in networks and their subsequent attribution to unicorns. Greg Ferro (@etherealmind) is fond of saying that new protocols without sufficient documentation must be powered by “unicorn tears”. Ivan Pepelnjak (@ioshints) is also a huge fan of the unicorn, as evidenced by this picture:

Ivan rides his steed into battle

The unicorn is popular because it represents a fantastic explanation for a difficult problem. However, people that I’ve talked to recently are getting tired of attributing mythical properties of various SDN-related technologies to the mighty unicorn. I thought about it and realized that there are more suitable animals depending on what technology you’re talking about.

King of Beasts

griffin

If you ask most SDN companies, they’ll tell you that their spirit animal is the griffin. The griffin is a mythical creature with the body and hindquarters of a lion combined with the head, wings, and front legs of an eagle. This regal beast is regarded as a stately amalgam of the king of beasts and the king of birds. It typically guards important and sacred treasures. It is also a popular animal in heraldry, where it represents courage and boldness.

You can tell from that description that anyone writing an API for their existing OS or networking stack probably has one of these things hanging in their cubicle. It stands for the best possible joining of two great ideas. Those APIs guard the sacred treasures for those that have always wanted insight into the inner workings of a network operating system. The griffin is the best case scenario for those that want to write an effective API or access methodology for enabling SDN. But as we all know, something the best strategies are sometimes poorly implemented.

Design by Committee

Chimera

The opposite of the griffin would have to be the chimera. A chimera is a mythical beast that has the body, head, and front legs of lion. It has a goat’s head jutting from the middle of the body and a snake’s head for a tail, although some sources say this is a dragon head with the associated dragon wings as well. This nightmarish beast comes from Greek mythology where it was an omen of disaster when spotted.

The chimera represents what happens when you try to combine things and end up with the worst possible combination. Why is there a goat’s head in the middle? What good does a snake head for a tail really do? In much the same way, companies that are trying to create SDN strategies by throwing everything they can into the mix will have end results that should use a chimera for a mascot. Rather than taking the approach of building the product with the best and most useful features, some designers feel the need to attach every thing they can in an effort to replicate existing non-useful functionality. “Better to have it and not need it” is the rallying cry most often heard. This leads to the kind of unwieldy and bloated applications that scare people away from SDN and back to traditional networking methodology.

Tom’s Take

Every project needs a mascot. Every product needs an icon or a fancy drawing on the product page. Sooner or later, those mascots come to symbolize everything the project stands for. Content penguins aside, most projects are looking for something cute or cuddly. Security vendors are notorious for using scary looking animals to get the point across that they aren’t to be messed with. I think that using mythologic creatures other than the unicorn to symbolize SDN projects is the way to go. It focuses the developers to ground themselves in real features. Hopefully it helps them avoid the mentality that could create nightmarish creatures like the chimera.

Juniper and the Removal of the Human Element

Posted on April 11, 2013 by networkingnerd

Our final presentation of Network Field Day 5 came from Juniper. A long-time contributor to Network Field Day, Juniper has been making noise as of late in the software defined networking (SDN) space with some of their ideas. We arrived on site for a nice hardy breakfast before settling in to hear what Juniper is bringing to the greater software networking space and how I later learned that it might be best to start phasing out the human element in the network.

First up was Jeremy Schulman (@nwkautomaniac) talking to us about Puppet integration into Junos. Jeremy opened with a talk about his involvement in automating things. Customers have been using infrastructure automation tools like Puppet and Chef for a while to provision servers. This allows you to spin up a new piece of hardware and have it quickly setup with basic configuration as soon as it boots up. Jeremy told us that reinventing the wheel when it comes to automation was unnecessary when you could just put a Puppet agent in Junos. So that’s what he did. As a side note here, Jeremy brings up a very good point about the future of networking. If you don’t know how to program in a real programming language, I suggest you start now. Most of the interfaces that I’ve seen in the last 6-9 months have a high degree of familiarity based on the old CLI interface conventions. But these interfaces only really exist to make us old school networking guys feel safe. Very soon, all the interfaces to these devices will be only be accessible via API – which means programming. If you don’t know how to write something in Python or Perl or even Java, you need to begin picking it up. For something like Python, you might consider Codecademy. It’s free and easy to pick up and follow whenever you want. Just a thought.

Demo time! There’s also a great overview of Puppet on Junos over on Packet Pushers written by none other than Anthony Burke (@pandom_). The basic idea is that you write the pertinent configuration snippets into a task that can be transformed into a workflow rather than being a CLI jockey that just spends time typing the command blindly into a Telnet or SSH session. Because you can also parse these tasks before they are sent out via the Puppet master, you can be sure your configs are sanitized and being sent to the appropriate device(s). That means that there are no humans in the middle of the process to type in the wrong address or type the right commands on the wrong device. Puppet is doing its part to remove the possibility of mistakes from your base configurations. Sure, it seems like a lot of work today to get Puppet up and running for the advantage of deploying a few switches. But when you look at the reduction of work down the road for the ability to boot up a bare metal box and have it be configured in a matter of minutes I think the investment is worth it. I spend a lot of time preconfiguring devices that get shipped to remote places. If I could have that box shipped the the remote location first and then just use Puppet to bring it online, I’d have a lot more time to devote to fine tuning the process. Which leads to greater efficiency. Which leads to more time (and so on and so on).

Next up, we got a sneak peek at Juniper’s next generation programmable core switch. While I didn’t catch the name at the time, it turns out that it was the new EX9200 that has been making some waves as of late. This switch is based on custom silicon, the Juniper One ASIC, rather than the merchant silicon in QFabric. Other than the standard speeds and feeds that you see from a core switch of this type, you can see that Juniper is going to support the kitchen sink of SDN with the EX9200. In addition to supporting OpenFlow and Puppet automation, it will also support VXLAN and NVGRE overlays as well as other interesting things like OpenStack and VMWare plugins in the future. Make no mistake – this platform is Juniper’s stalking horse for the future. There’s been a lot written about the longevity of the previous platforms compared to the new MX-based EX9200. I think that Juniper is really standing behind the idea that the future of networking lies in SDN and that a platform with support for the majority of the popular methods used to reach high levels of programmability and interoperability is critical going forward. Where that leaves other switching platforms is the realm of speculation. Just ask yourself this question: Are you planning on buying a non-SDN capable switch in the next refresh? Is regular packet forward fine for you for the next 3-5 years? That is the critical question being asked in strategy meetings and purchasing departments all over the place right now.

Parantap Lahiri stepped up next to present on the Contrail acquisition. Those of you interested in the greater SDN picture would do well to watch the whole video. Especially if you are curious about things like VMware’s new NSX strategy, as the Contrail idea is very similar, if not a bit more advanced. The three use cases outlined in the video are great for those not familiar with what SDN is trying to accomplish right now. In fact, commit this diagram to memory. You are going to see it again (I promise):

ContrailDiagram

Note that further in the video, Parantap goes over one of the features of Contrail that is going to get many people excited. Via use of GRE tunnels, this solution can create a hybrid cloud solution to burst your traffic from the private data center into a public provider like AWS or Rackspace as needed. That, if nothing else, is the message that you need to consider with the “traditional” vendors that are supporting SDN. Cisco and Juniper and even VMware don’t want you to start buying whitebox servers and turning them into switches. They don’t want a “roll your own” strategy. What Juniper wants if for you to buy a whole bunch of EX9200s and then build a Contrail overlay system to manage it all. Then, when the workloads get to be too great for your own little slice of private cloud you can use Contrail to tunnel into the public cloud and move those workloads until the traffic spike subsides. Maybe you even want to keep some of those migrated workloads in the cloud permanently in order to take advantage of cheap compute and ease overall usage in your private data center. The key is flexibility, and that’s what Contrail gives you. That’s where the development is going to be for the time being.

The last presentation came from the Juniper Webapp Secure team. You may recognize this product by its former moniker – Mykonos. In fact, you may recognize this presentation from its former delivery at NFD4. In fact, I said as much during the demo:

As I said last time, Juniper Webapp Secure (nee Mykonos) is the greatest trolling security program I’ve seen. #NFD5

— Tom Hollingsworth (@NetworkingNerd) March 8, 2013

There’s a market for a security tool like this for lots of websites. It gets the bad guys without really affecting the good guys. I’m sure that Juniper is going to sell the living daylights out of it. They’re trying their best right now based on the number of people that I’ve seen talking about it on Twitter. The demo is engaging because it highlights the capabilities as well as injecting a bit of humor and trollishness. However, based on what I’ve seen at NFD4 and NFD5 and what people have told me they saw when they were presented, I think the Webapp Secure demo is very scripted and fairly canned. The above video is almost identical to the one from NFD4. Compare:

Guys, you need to create a new Generic company and give us some more goodies in the demo. Having a self-aware web firewall that doesn’t need human intervention to stop the attackers is a big deal. Don’t use Stock Demo Footage to tell us about it every time.

Tom’s Take

What does the Juniper strategy look like? The hint is in the title of this post. Juniper is developing automation to reduce the amount of people in the network making critical decisions without good information or tools to execute. As those people begin to be replaced by automated systems, the overall intelligence in the network increases while at the same time reducing the amount of time that it takes to take action to bring new nodes online and reconfigure on the fly to support things we thought might have been impossible even three years ago. Through device deployment orchestration, flexible platforms supporting new protocols with programmability built in and even to new technology like overlay networking and automated security response for critical systems, Juniper is doing their best to carve out a section of the SDN landscape just for themselves. It’s a strategy that should pay off in the long run provided there is significant investment that stays the course.

Tech Field Day Disclaimer

Juniper was a sponsor of Network Field Day 5. As such, they were responsible for covering a portion of my travel and lodging expenses while attending Network Field Day 5. In addition, they also provided breakfast for the delegates. Juniper also gave the delegates a copy of Juniper Warrior, a mobile phone charger, emergency battery pack, and a battery-powered pocket speaker. 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.

Plexxi and the Case for Affinity

Posted on April 8, 2013 by networkingnerd

Plexxi Logo

Our last presentation from Day 2 of Network Field Day 5 came from a relatively new company – Plexxi. I hadn’t really heard much from them before they signed up to present at NFD5. All I really knew was that they had been attracting some very high profile talent from the Juniper ranks. First Dan Backman (@jonahsfo) shortly after NFD4 then Mike Bushong (@mbushong) earlier this year. One might speculate that when the talent is headed in a certain direction, it might be best to see what’s going on over there. If only I had known the whole story up front.

Mat Mathews kicked off the presentation with a discussion about Plexxi and what they are doing to differentiate themselves in the SDN space. It didn’t take long before their first surprise was revealed. Our old buddy Derick Winkworth (@cloudtoad) emerged from his pond to tell us the story of why he moved from Juniper to Plexxi just the week before. He’d kept the news of his destination pretty quiet. I should have guessed he would end up at a cutting edge SDN-focused company like Plexxi. It’s good to see smart people landing in places that not only make them excited but give them the opportunity to affect lots of change in the emerging market of programmable networking.

Marten Terpstra jumped in next to talk about the gory details of what Plexxi is doing. In a nutshell, this all boils down to affinity. Based on a study done by Microsoft in 2009, Plexxi noticed that there are a lot of relationships between applications running in a data center. Once you’ve identified these relationships, you can start doing things with them. You can create policies that provide for consistent communications between applications. You can isolate applications from one another. You can even ensure which applications get preferential treatment during a network argument. Now do you see the SDN applications? Plexxi took the approach that there is more data to be gathered by the applications in the network. When they looked for it, sure enough it was there. Now, armed with more information, they could start crafting a response. What they came up with was the Plexxi Switch. This is a pretty standard 32-port 10GigE switch with 4 QSFP ports.. Their differentiator is the 40GigE uplinks to the other Plexxi Switches. Those are used to create a physical ring topology that allows the whole conglomeration to work together to create what looked to me like a virtual mesh network. Once connected in such a manner, the affinities between the applications running at the edges of the network can now begin to be built.

Plexxi has a controller that sits above the bits and bytes and starts constructing the policy-based affinities to allow traffic to go where it needs to go. It can also set things up so that things don’t go where they’re not supposed to be, as in the example Simon McCormack gives in the above video. Even if the machine is moved to a different host in the network via vMotion or Live Migration, the Plexxi controller and network are smart enough to figure out that those hosts went somewhere different and that the policy providing for an isolated forwarding path needs to be reimplemented. That’s one of the nice things about programmatic networking. The higher-order networking controllers and functions figure out what needs to change in the network and implements the changes either automatically or with a minimum of human effort. This ensures that the servers don’t come in and muck up the works with things like Dynamic Resource Scheduler (DRS) moves or other unforeseen disasters. Think about the number of times you’ve seen a VM with an anti-affinity rule that keeps it from being evacuated from a host because there is some sort of dedicated link for compliance or security reasons. With Plexxi, that can all be done automagically. Derick even showed off some interesting possibilities around using Python to extend the capabilities of the CLI at the end of the video.

If you’d like to learn more about Plexxi, you can check them out at http://www.plexxi.com. You can also follow them on Twitter as @PlexxiInc

Tom’s Take

Plexxi has a much different feel than many of the SDN products I’ve seen so far. That’s probably because they aren’t trying to extend an existing infrastructure with programmability. Instead, they’ve taken a singular focus around affinity and managed to tun it into something that looks to have some very fascinating applications in today’s data centers. If you’re going to succeed in the SDN-centric world of today, you either need to be front of the race as it is being run today, like Cisco and Juniper, or you need to have a novel approach to the problem. Plexxi really is looking at this whole thing from the top down. As I mentioned to a few people afterwards, this feels like someone reimplemented QFabric with a significant amount of flow-based intelligence. That has some implications for higher order handling that can’t be addressed by a simple fabric forwarding engine. I will stay tuned to Plexxi down the road. If nothing else, just for the crazy sock pictures.

Tech Field Day Disclaimer

Plexxi was a sponsor of Network Field Day 5. As such, they were responsible for covering a portion of my travel and lodging expenses while attending Network Field Day 5. In addition, they also gave the delegates a Nerf dart gun and provided us with after hours refreshments. 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.

Additional Coverage of Plexxi and Network Field Day 5

Smart Optical Switching – Your Plexxible Friend – John Herbert

Plexxi Control – Anthony Burke

Brocade Defined Networking

Posted on April 4, 2013 by networkingnerd

Brocade stepped up to the plate once again to present to the assembled delegates at Network Field Day 5. I’ve been constantly impressed with what they bring each time they come to the party. Sometimes it’s a fun demo. Other times its a great discussion around OpenFlow. With two hours to spend, I wanted to see how Brocade would steer this conversation. I could guarantee that it would involve elements of software defined networking (SDN), as Brocade has quietly been assembling a platoon on SDN-focused luminaries. What I came away with surprised even me.

Mike Schiff takes up the reigns from Lisa Caywood for the title of Mercifully Short Introductions. I’m glad that Brocade assumes that we just need a short overview for both ourselves and the people watching online. At this point, if you are unsure of who Brocade is you won’t get a feel for it in eight short minutes.

Curt Beckman started off with fifteen minutes of discussion about where the Open Networking Foundation (ONF) is concentrating on development. Because Curt is the chairman of the ONF, we kind of unloaded on him a bit about how the ONF should really be called the “Open-to-those-with-$30,000-to-spare Networking Foundation”. That barrier to entry really makes it difficult for non-vendors to have any say in the matters of OpenFlow. Indeed, the entry fee was put in place specifically to deter those not materially interested in creating OpenFlow based products from discussing the protocol. Instead, you have the same incumbent vendors that make non-OpenFlow devices today steering the future of the standard. Unlike the IETF, you can’t just sign up for the mailing list or show up to the meetings and say your peace. You have to have buy in, both literally and figuratively. I proposed the hare-brained idea of creating a Kickstarter project to raise the necessary $30,000 for the purpose of putting a representative of “the people” in the ONF. In discussions that I’ve had before with IETF folks they all told me you tend to see the same thing over and over again. Real people don’t sit on committees. The IETF is full of academics that argue of the purity of an OAM design and have never actually implemented something like that in reality. Conversely, the ONF is now filled with deep pocketed people that are more concerned with how they can use OpenFlow to sell a few more switches rather than now best to implement the protocol in reality. If you’d like to donate to an ONF Kickstarter project, just let me know and I’ll fire it up. Be warned – I’m planning on putting Greg Ferro (@etherealmind) and Brent Salisbury (@networkstatic) on the board. I figure that should solve all my OpenFlow problems.

The long presentation of this hour was all about OpenFlow and hybrid switching. I’ve seen some of the aspects of this in my day job. One of the ISPs in my area is trying to bring a 100G circuit into the state for Internet2 SDN-enabled links. The demo that I saw in their office was pretty spiffy. You could slice off any section of the network and automatically build a path between two nodes with a few simple clicks. Brocade expanded my horizons of where these super fast circuits were being deployed with discussions of QUILT and GENI as well as talking about projects across the ocean in Australia and Japan. I also loved the discussions around “phasing” SDN into your existing network. Brocade realizes that no one is going to drop everything they currently have and put up an full SDN network all at once. Instead, most people are going to put in a few SDN-enabled devices and move some flows to them at first both as a test and as a way to begin new architecture. Just like remodeling a house, you have to start somewhere and shore up a few areas before you can really being to change the way everything is laid out. That is where the network will eventually lead to being fully software defined down the road. Just realize that it will take time to get there.

Next up was a short update from Vyatta. They couldn’t really go into a lot of detail about what they were doing, as they were still busy getting digested by Brocade after being acquired. I don’t have a lot to say about them specifically, but there is one thing I thought about as I mulled over their presentation. I’m not sure how much Vyatta plays into the greater SDN story when you think about things like full API programmability, orchestration, and even OpenFlow. Rather than being SDN, I think products like Vyatta and even Cisco’s Nexus 1000v should instead be called NDS – Networking Done (by) Software. If you’re doing Network Function Virtualization (NFV), how much of that is really software definition versus doing your old stuff in a new way? I’ve got some more, deeper thoughts on this subject down the road. I just wanted to put something out there about making sure that what you’re doing really is SDN instead of NDS, which is a really difficult moving target to hit because the definition of what SDN really does changes from day to day.

Up next is David Meyer talking about Macro Trends in Networking. Ho-ly crap. This is by far my favorite video from NFD5. I can say that with comfort because I’ve watched it five times already. David Meyer is a lot like Victor Shtrom from Ruckus at WFD2. He broke my brain after this presentation. He’s just a guy with some ideas that he wants to talk about. Except those ideas are radical and cut right to the core of things going on in the industry today. Let me try to form some thoughts out of the video above, which I highly recommend you watch in its entirety with no distractions. Also, have a pen and paper handy – it helps.

David is talking about networks from a systems analysis perspective. As we add controls and rules and interaction to a fragile system, we increase the robustness of that system. Past a certain point, though, all those extra features end up harming the system. While we can cut down on rules and oversight, ultimately we can’t create a truly robust system until we can remove a large portion of the human element. That’s what SDN is trying to do. By allowing humans to interact with the rules and not the network itself you can increase the survivability of the system. When we talk about complex systems, we really talk about increasing their robustness while at the same time adding features and flexibility. That’s where things like SDN come into the discussion in the networking system. SDN allows us to constrain the fragility of a system by creating a rigid framework to reduce the complexity. That’s the “bow tie” diagram about halfway in. We have lots of rules and very little interaction from agents that can cause fragility. When the outputs come out of SDN, the are flexible and unconstrained again but very unlikely to contribute to fragility in the system. That’s just one of the things I took away from this presentation. There are several more that I’d love to discuss down the road once I’ve finished cooking them in my brain. For now, just know that I plan on watching this presentation several more times in the coming weeks. There’s so much good stuff in such a short time frame. I wish I could have two hours with David Meyer to just chat about all this crazy goodness.

If you’d like to learn more about Brocade, you can check out their website at http://www.brocade.com. You can also follow them on Twitter as @BRCDcomm

Tom’s Take

Brocade gets it. They’ve consistently been running in the front of the pack in the whole SDN race. They understand things like OpenFlow. They see where the applications are and how to implement them in their products. They engage with the builders of what will eventually become the new SDN world. The discussions that we have with Curt Beckman and David Meyer show that there are some deep thinkers that are genuinely invested in the future of SDN and not just looking to productize it. Mark my words – Brocade is poised to leverage their prowess in SDN to move up the ladder when it comes to market share in the networking world. I’m not saying this lightly either. There’s an adage attributed to Wayne Gretskey – “Don’t skate where the puck is. Skate where the puck is going.” I think Brocade is one of the few networking companies that’s figured out where the puck is going.

Tech Field Day Disclaimer

Brocade was a sponsor of Network Field Day 5. As such, they were responsible for covering a portion of my travel and lodging expenses while attending Network Field Day 5. In addition, Brocade provided a USB drive of marketing material and two notepads styled after RFC 2460. 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.

Network Field Day 4

Posted on September 27, 2012 by networkingnerd

I am once again humbled and honored to accept an invitation to my favorite industry event – Network Field Day (now in its fourth iteration). Network Field Day 4 (NFD4) will be coming to you from San Jose October 10-12th. The delegate lineup has a bunch of new faces that I’m excited to catch up with and/or meet for the first time:

	Anthony Burke	@Pandom_
	Bob Plankers	@Plankers
	Brad Casemore	@BradCasemore
	Brent Salisbury	@NetworkStatic
	Colin McNamara	@ColinMcNamara
	Greg Ferro	@EtherealMind
	Michael McNamara	@mfMcNamara
	Paul Stewart	@PacketU

This is a great crew with a lot to say and I’m anxious to see them unleashed on our assembled sponsors:

Brocade – I’m betting that VCS is going to be up on the block this time around. We got a chance to play with it a while back and we had a blast. With the annoucements that you’ve made around Brocade Tech Day, I’d like to hear more about the VCS strategy and how it will dovetail into your other product lines. I’d also like to hear more about the ADX and how you plan on terminating VXLAN tunnels in hardware. Please be sure that you can talk about these in decent depth. Being told over and over again that something is NDA when it shouldn’t be a huge mystery is a bit disconcerting. Also, if Jon Hudson isn’t presenting, at least have him show up for a few minutes to say hello. We love that guy.During Wireless Field Day 3, Gregor Vučajnk (@GregorVucajnk) had a great blog post about attending that had something that I’m going to borrow for this NFD outing. He called out each of the participating sponsors and gave them a short overview of what he wanted to see from each of them. I loved the idea, as it gives a bit more direction to the people making the decisions about presentation content.

Cisco Borderless – Please, please, oh please tell me what Borderless really means. Even if it’s just “everything but data center and collaboration”. I really want to know how you’re pulling all these product lines together to create synergy. Otherwise, it’s still just going to be the routing BU, switching BU, and so on. We had a great time listening to the last presentation about ASA CX and Wireshark on the Cat 4500. More of that good stuff, even if it means you have to shave your presentation down a bit to accommodate. Remember, we ask lots of questions.

Juniper – Firstly, I want a bit of talk about Ivan’s post exploring all the gooey details around QFabric. I understand that in this case it may be a bit like the magician telling how the trick is done, but this is the kind of thing that fascinates me. I’m also sure there’s going to be discussion around SDN and the Juniper approach to it. The presentation at NFD2 was so great I want to see you keeping up the good work.

OpenGear – Hello there. I know nothing about you beyond the cursory Google search. It looks like you’ve got some interesting technology that could be of great use to network professionals. Case studies and anecdotes about using a 3G console failover to prevent global chaos would be awesome. Also, allowing us the opportunity to poke around on a box for a few minutes would rock. I want to think about how I can use your product to make my life less miserable when it comes to offline console access.

Spirent – Hello again to you. I didn’t know anything about Spirent last time, but now I see them everywhere I look. Spirent is like the Good Housekeeping seal for network gear. Lets dive deeper into things. I know you’re squeamish about showing off GUIs and things like that, but we nerd out on those things. Also, I want to talk about how you plan on building testing rigs to handle all the coming 100GigE traffic. Show me how Spirent is going to keep up the Ginger Rogers mystique that I’ve associated with it.

Statseeker – Network Performance Management and monitoring can be a bit of a dry subject, but doing it with an accent from the Land Down Under could be a bit of a treat. After your recent Packet Pushers episode, I want to drill down more into how you go about keeping all the monitoring data. I’ve seen what overwhelming an NMS with data can do, and while it was a pretty light show, I want to prevent it from happening again. I don’t expect you to bring one of your famous Minis to give away to the delegates, but don’t underestimate the power of bribery via Tim Tam.

Tech Field Day – Audience Participation

For those of you that like to follow along with the Tech Field Day delegates from the comfort of your office chair or recliner, you are more than welcome. I’ve even seen people talking about taking the day off from work or making sure they aren’t on a remote site. We will be streaming each of the presentations live at http://techfieldday.com. Note that this stream does use uStream, so we aren’t optimized for mobile devices just yet. We’re working on it, though. We will also be spending a lot of time on Twitter discussing the presentations and questions about them. Just make sure to use the hashtag #NFD4 and you can be a part of the discussion. I love seeing discussion and commentary from all the people watching online. I always make sure to keep my Twitter client at the forefront so I can ask questions from the home audience when they arise. That way, I’m truly a delegate representing people and giving them a say in what shapes the events.

If you’d like to learn a little more about Tech Field Day, you can head over to http://techfieldday.com and read up on things. You can also apply to be a delegate at this link. I look forward to seeing you online and hearing from you at this Tech Field Day event.

Standard Tech Field Day Sponsor Disclaimer

Tech Field Day is a massive undertaking that involves the coordination of many moving parts. It’s not unlike trying to herd cats with a helicopter. One of the most important pieces is the sponsors. Each of the presenting companies is responsible for paying a portion of the travel and lodging costs for the delegates. This means they have some skin in the game. What this does NOT mean is that they get to have a say in what we do. No Tech Field Day delegate is every forced to write about the event due to sponsor demands. If a delegate chooses to write about anything they see at Tech Field Day, there are no restrictions about what can be said. Sometimes this does lead to negative discussion. That is entirely up to the delegate. Independence means no restrictions. At times, some Tech Field Day sponsors have provided no-cost evaluation equipment to the delegates. This is provided solely at the discretion of the sponsor and is never a requirement. This evaluation equipment is also not a contingency of writing a review, be it positive or negative.

The Networking Nerd

Networking With A Side of Snark

Tag Archives: SDN

The OpenFlow Longbow

Should Microsoft Buy Big Switch?

SDN and NFV – The Ups and Downs

A Guide to SDN Spirit Animals

Juniper and the Removal of the Human Element

Plexxi and the Case for Affinity

Brocade Defined Networking

Network Field Day 4

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: