Let’s forget about all of this recent SDN washing and go back to virtual networking basics. Most of us by now know what a software switch is. It is also known as a vswitch or virtual switch. This is arguably the most critical piece of real estate in the next generation data center network. So, who owns this property?
What’s the foundation of the next generation data center network, i.e. this thing some call the software defined virtual data center network? Many companies have recently re-branded their products and jumped on the Software Defined Networking (SDN) bandwagon in some way, shape, or form, and for good reason. It has the potential to truly change networking as we know it today. IDC has even stated SDN could be a $2B market by 2016.
Let’s forget about all of this recent SDN washing and go back to virtual networking basics. Most of us by now know what a software switch is. It is also known as a vswitch or virtual switch. This is arguably the most critical piece of real estate in the next generation data center network. So, who owns this property?
1 Comment
For those who visit here often know I'm a bit of an SDN purist , maybe even a Revolutionary. But this article, it stemmed from several recent conversations on how the network will EVOLVE over time. This pertains to data center only, so it's more relevant to the topic of *Empowering* the Software Defined Data Center (SDDC). It was also meant to be a high level quick start guide regarding these trends. For more details, I've written other posts and there are definitely a lot of others out there too.
Here it goes. Network Virtualization & Software Defined Networks As an infrastructure and IT professional, you are probably overwhelmed with the amount of information and hype right now regarding topics such as OpenFlow and Software Defined Networking (SDN). Rest assured you are not alone. My goal is to simplify this messaging, review what can be done in the world of software and virtual networking today to meet the demands of Cloud, but will also lay the foundation for the next generation network. There is no better time than now to be in the world of networking. While it is changing significantly without many taking notice, we have exciting times ahead of us. Many of us, including me, may even be out of a job in a few years once networking becomes truly automated, but for now, let’s embrace the change and see what happens! Just in the past few months we’ve seen Nicira, vCider, and now Vyatta get acquired, not to mention the other SDN startups getting more VC funding, the most recent of this bunch, Big Switch Networks. But, today’s announcement is clearly about Vyatta getting acquired by Brocade.
It was just announced Riverbed will be acquiring OPNET. With the growth of BYOD, Cloud, SDN, and Collaboration just to name a few of today’s hottest trends, it is now more important than ever before to have deeper visibility into both the network and the applications riding over the network. For the mid-size Enterprise in my experience, they usually rely just on SNMP, WMI, and sometimes NetFlow to gain visibility to the network. However, this data on its own is not enough to really know what’s going on throughout the network. From my perspective, network and application performance management (APM) solutions are those that the incumbent network vendors should have been selling for the past decade. These are what’s really needed. How can you make a better network or make applications run smoother if there isn’t direct integration between the network and the applications (via an APM tool)?
If we use last year’s Interop as the OpenFlow/SDN coming out party, it took just over a year for Cisco to fully develop and announce a comprehensive multi-segment strategy. Their SDN encompassing strategy is called Cisco Open Network Environment (ONE). Congratulations, Cisco! If they got David Ward back from Juniper sooner, maybe the strategy would have already been announced. Joke…I really don’t have any insight as to who was or is responsible for the strategy, but would imagine it to be a fairly extensive team.
I think it was a good move to announce during Cisco LIVE. Customers worship Cisco, not just for the products, solutions, architectures they develop, but also for this week long party where they receive gifts and gadgets, and soak up some of the most technical content in the industry, but most importantly can be around like-minded individuals. That is the most important thing for those that are technically inclined and is often not understood by those who aren’t “down in the weeds.” Greg Ferro does a nice job here directly stating the networking incumbents should step up with an SDN strategy. I agree 100%. Brad Casemore also chimes in with his thoughts. If you aren’t already reading their blogs, I encourage you to do so because you’re missing out.
Several companies have announced they have OpenFlow-enabled switches, but for these companies, there is still no strategy and no reasoning as to why their switch should be used when deploying an OpenFlow based SDN. Furthermore, they lack a strategy overall looking at the various components of a Software Defined Network. From a hardware standpoint, some of the same features and characteristics (buffers, table sizes, etc.) will still need to be compared as we already do today in traditional networks, but even that, isn’t documented in these announcements. A lot of these vendors think they are on the offensive [vs. Cisco] announcing OpenFlow enabled switches (without a controller), but they really aren’t, in my opinion. [Before you start reading, I need to give a big thanks to Christian Esteve Rothenberg, Research Scientist at CPqD. I asked if he wouldn't mind reading through this post prior to posting to ensure I didn't botch up anything on RouteFlow, and sure enough he immediately helped out and provided great feedback. Christian also provided us with the picture you'll eventually see below and many of the RouteFlow links as well. There was much more information he provided that I'll hope to get out soon too. Thanks again, Christian.]
So...let's get to it. Understanding “flow based protocols” and RouteFlow can change the way you think about networking and the protocols we use on daily basis. I’m referring to control plane protocols such as Spanning Tree, OSPF, EIGRP, and BGP. Based on the traction from this blog, I can see many people are searching for answers on what SDN means for the industry and what the future will be for a network engineer, etc. If you are one of those people, first, ready my last post. It’s a quick synopsis of a presentation at ONS that covers some interesting automated tools already available for controller based networks. And second, keep reading here. I mentioned in my previous post Nick McKeown, uber smart Entrepreneur and Professor at Stanford, gave what I thought was the finest presentation of the week at the Open Networking Summit hosted in Santa Clara this week. As I wait to board my plane back to the East coast, here is a more detailed recap of the presentation and what I took away from it…
Here is a quick summary on what I think worked well, what didn't work, and some thoughts on improving ONS next year.
What worked?
With just a few minutes to spare until the 5:30 start of the evening event and exhibits, I thought I’d give a really quick summary of Day 1 at the Open Networking Summit 2012. Note there were two tutorial sessions today and I attended the one for engineers.
The first thing you noticed by seeing everyone’s badges/name tags with associated company, and was confirmed by Brandon’s presentation in the first slide, was there was and is a truly broad audience here. There are the obvious participants from the big name manufacturers, but also, there are between 1-3 people from at least 60 “other” companies, which is the category I fall into since I’m the only one representing BlueWater from NY/NJ. I also had the pleasure of sitting next to the sole person from Aruba Networks as well. Not sure what that tells you about their SDN strategy. The term Software Defined Networking (SDN) has seemingly become main stream in the past several months being one of the hotter topics, if not the hottest, for the blog and twitter communities. But, has it really gone main stream? I’m not so sure. In fact, I’ll say it hasn’t for sure. The Open Networking Foundation (ONF) formed last year is largely made up of hyper scale web companies, “traditional” network companies, some niche network/services providers, new SDN companies focused on developing software and hardware, and Goldman Sachs. But, does it really matter who is on the ONF from an end user’s standpoint? Do Enterprise’s really care that companies are spending the $30,000 or so per year to be part of the ONF? Do they [Enterprises] care that Facebook, Google, and Yahoo are exploring OF/SDN and are on the board of directors? Doubt it. They care about their requirements that need that of some fixin’. 99% of the environments out there do not replicate that of these hyper scale web companies. If anything, they are more represented by that of Goldman Sachs, right? While Goldman is likely still in the early stages of their SDN R&D, they are who I’d like to hear from. Several years ago I was on the SE team at Cisco that supported Goldman. I didn’t support them directly, but a peer of mind did. These guys/gals at GS are smart, really smart, and it’s no surprise GS looks at the network from a business perspective. Should they realize the benefit of SDN, it’ll be adopted. If they adopt, others will follow, especially those on Wall Street. Pay attention to them and their ONF efforts.
But….as a week full of SDN will be starting shortly, here are some other thoughts relating to the topic of SDN. Many of which could be controversial =). I’ve started thinking about the SDN ecosystem and realized there are A LOT of companies making announcements, but really, who is doing what, how do they all fit together, and what products can be purchased today? That’s what I’m hoping to get across in this post.
Before I get started, I’ll say upfront, for some of the companies in the ecosystem, they have clear and concise messaging – exactly what they are working on and what they have planned, which is great for all of us. However, for a quite a few, I don’t know much (maybe you do) about what they are working on, but they are calling themselves next generation SDN companies. Their websites couldn’t be vaguer, but I guess that’s all we can expect from companies in stealth mode. With that said, feel free to comment if you have further information or corrections to make on anything that you see below. 12/27/2013 - New post here on various players in the SDN Ecosystem. First, I’ll say in advance that this post probably won’t be one of my best…if the flow seems off, it is because it was pieced together over the past few weeks from various email and general conversations I’ve had regarding SDN. The main theme here is Think Different (well, I think Steve Jobs said it first).
Private/Public/Hybrid cloud is seemingly where 99% of the focus is when it pertains to OpenFlow and Software Defined Networking (SDN) in any article/blog/etc. Personally, I think the industry (at this point it’s just consultants, vendors, and a FEW SDN users) need to think outside the box. As much evangelizing as is going on right now, it’s still the same few that are probably reading into it over and over…that’ my perception anyway. Network Operators still aren’t familiar with these concepts from a high level and it is the average IT organization that can possibly really benefit from SDN. Dimitri said it best – mid-market is forgotten about to a large extent. 100% agree with him and this is where I spend much of my time consulting, so I see it all the time! Security. It’s an interesting topic when it comes to networking within Enterprise IT. There are those that are truly focused on an end to end view of security or just freakishly enjoy security and then those that are usually okay with just implementing a perimeter FW and maybe an IDS/IPS. So, when it comes to your “typical” Enterprise LAN, all hosts are inherently trusted so communication between clients and servers, clients and clients, and servers and servers, is unprotected. I will say, in 2011, I've seen this starting to change and infrastructure security is becoming even more critical for the average “mid-market” customer for various reasons, but heavily attributed to the wide adoption smart phones, tablets, and the whole “Bring Your Own Device” (BYOD) mantra being driven by the consumer.
Anyway, what does this have to do with OpenFlow/SDN? Nothing…yet, but the question that came to me while I was in a meeting with a NYC based financial firm last week was, “How will security be perceived with running a *real* virtualized network with control plane separation happening at a controller?” Before I go any further, here is some background… For those that aren’t aware, I was proudly in a fraternity in college and our motto was simple, “Loved, Hated, but Never Ignored,” and we wore it proudly on our fraternity t-shirts. The same motto seems to be true for Software Defined Networks in the industry at this moment. There is a community of folks that see the potential, but not everyone is on board, not everyone thinks it’s for real, some call it hype, some call it a technology for Cloud Providers, and some think that it was built by the academic community and that’s where it will stay for the long term, but you know what, people keep talking about it, and that’s a great thing…because you don’t want to be ignored ;). There have been many blogs, tweets, and announcements in this space with the most recent coming from Nicira.
Without describing basic WLAN forwarding, OpenFlow, or SDN, I’m going to jump in and start discussing HREAP and close with questions and thoughts pertaining to protocols of choice for achieving a “controller based network.”
For those that aren’t familiar with Cisco HREAP, it is a design for Wireless LANs in which only control traffic gets tunneled back to the controller and the data traffic stays local on the switch. The IEEE protocol used to communicate between an AP and a controller is called CAPWAP. There are various use cases for the technology, not described here, but that is the 100,000 foot overview. So, looking at the diagram below, we see a very basic implementation of HREAP. It's a little late, but this blog post was motivated after reading the following write up at GigaOm from back in March.
http://gigaom.com/2011/03/23/are-home-networks-destined-for-cloud-based-networking/#react-tabs Taking a look at Software Defined Networking and then again at what Meraki is doing, I wonder if there are synergies behind the scenes or if there will be in the future? Meraki is focused on simplified network device management, calling it Cloud Networking, which can even be seen as a SAAS based offering for a network management tool on steroids. Pretty slick demo shown at the latest Wireless Tech Field Day 2. And I do agree with Om Malik that something like this could be the future of home networking. Partnering with Meraki, it could be a nice offering for the cable providers out there simply by adding a Meraki device and simplified management to a consumer's cable bill. Only time will tell, but SDN could very well be the future of networking. It will drive innovation, allow for new competition, and decrease the time to market of new features in the network. Ideally, it will also drastically improve operational efficiencies with a suite of applications to more easily manage the network infrastructure. Doesn’t it seem obvious by now that the hardware and software that are now so tightly integrated for every vendor should be de-coupled?
In this post, I’m going to write about possible SDN applications that I’ve been thinking about for the past few days. It’s more thinking out loud than anything else, but I’m not talking about OpenFlow applications, but rather the next layer up, which will include the integration of applications between an OF/SDN controller and other existing or new applications located in an Enterprise Data Center. I was initially thinking, what existing devices are aware of the overall state of the applications, systems, and security in a data center? What other controllers, head-end systems, and manager of manager’s are out there that could make sense to integrate with an OpenFlow controller to create a smarter network? Embrane officially launched this past Monday as you all are probably aware of already. By Monday evening, Brad, Ivan, and Greg had already posted their take and impact of Embrane’s heleos platform. If you haven’t read them yet, I’d highly recommend doing so to get more acquainted with the solution. There are some great comments on Brad’s post as well.
Prior to reading their write-ups, I did however, take a look at the whitepaper, FAQ (focus on Licensing and Bill secton), and also watched the videos by Dante Malagrinò on Embrane’s website. What really caught my eye after going through the material was the Embrane Pricing Model. Based on my customer experiences (Enterprise to mid-market), heleos would do wonders for them, although they are NOT cloud service providers (CSPs), and that is who much of Embrane’s marketing material is targeted at…for now. After reading Ivan Pepelnjak’s (ipspace) and Martin Casado’s (networkheresy) blogs recently, I noticed they were making general comparisons on network tunneling protocols. These protocols are nothing new, for example using UDP, GRE, EoMPLS, VPLS, and a new one being mentioned over the past several months, VXLAN. However, what caught my attention was CAPWAP was also a protocol each of them used to compare to GRE, UDP, and VXLAN. As you’ll recall in my recent OpenFlow post, I spent quite a bit of time comparing OpenFlow to CAPWAP in the sense OpenFlow is being used to separate the control and data planes on switches and CAPWAP is being used to separate the control and data planes on Access Points.
I figured, why not, let’s google CAPWAP and OpenFlow together and see what comes up. No surprise, you see the post from Matt Davy at IU who was drawing a similar comparison to OF/SDN to CAPWAP/WLAN, my recent blog, Ivan’s blog, Martin’s blog, and then finally the reason why I’m writing this – I saw a link to openvswitch.org that talked about building support for CAPWAP into the open vswitch. Interesting, right? Well, to me it is! So after digging further, it looks like Jesse Gross (from Nicira, the company who does much of the development work on open vswitch) had some comments in the commit log for this feature. There have been numerous articles, blogs, and columns written over the past few months on OpenFlow and Software Defined Networking, but I still feel like many of them aren’t breaking it down for the typical Enterprise Network Engineer. Having followed OpenFlow since mid 2010, I do not claim to be an expert in this space, but I will give my take on what could be the game changer for the networking industry.
Let me also apologize up front because this post is longer than I originally intended it to be! What is OpenFlow? OpenFlow is simply a protocol that is used to communicate between a server, i.e. controller and network switches that allows the switch control plane to be separated from the data plane. Now what does that mean and what is a controller? This is where there are many analogies being made on what this actually looks like from a low level. The most common comparison made is that it’s “the x86 instruction set for networking.” For those academics or developers out there, this may mean a lot, but for me, it means absolutely nothing, and I consider myself pretty in tune with the mind set of someone designing Enterprise Data Center and Campus Networks, with the latest technology out there. For me, the analogy that I use when explaining OpenFlow is directly relating it to the past and present Enterprise WLAN market. |
AuthorJason Edelman, Founder of Network to Code, focused on training and services for emerging network technologies. CCIE 15394. VCDX-NV 167. Top PostsThe Future of Networking and the Network Engineer Categories
All
Archives
May 2015
|