SDN AND OPENFLOW
THE HYPE AND THE HARSH REALITY
This material is copyrighted and licensed for the sole use by Manju Devaraj ([email protected] [202.156.243.240]). More information at http://www.ipSpace.net/Webinars
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
ipv6 document ..............., Essays (university) of Cyberlaw and Internet Law
ipv6 explanation ........................
Typology: Essays (university)
2016/2017
1 / 271
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download ipv6 document ............... and more Essays (university) Cyberlaw and Internet Law in PDF only on Docsity!
SDN AND OPENFLOW
THE HYPE AND THE HARSH REALITY
© Copyright ipSpace.net 2014 Page ii
SDN AND OPENFLOW
THE HYPE AND THE HARSH REALITY
Ivan Pepelnjak, CCIE#1354 Emeritus
Copyright © 2014 ipSpace.net AG
WARNING AND DISCLAIMER
This book is a collection of blog posts written between March 2011 and the book publication date, providing independent information about Software Defined Networking and OpenFlow. Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. Read the introductory paragraphs before the blog post headings to understand the context in which the blog posts have been written, and make sure you read the Introduction section_._
The information is provided on an “as is” basis. The authors, and ipSpace.net shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book.
© Copyright ipSpace.net 2014 Page iv
FOREWORD
Ivan asked me to write the intro for his latest book on Software Defined Networking and I'm a bit mystified why. Granted, he's like the control plane to my forwarding plane. The brilliant technical insights I've gathered from Ivan's web site and webinars have provided me with valuable content and creative inspiration ever since I first discovered it. In fact, I almost feel like I'm cheating at my job. Every time I clarify SDN in a conversation with, "It's the decoupling of the logical from the physical," I want to insert a footnote referencing him.
I remember the first time I heard him on a podcast, I thought to myself "This guy must be super smart, because he sounds like a Bond villain and I can only grasp 50% of what he's saying." I started telling colleagues about him, "Hey, check this guy out. His webinars will make your brain bleed out of your ears!" Trust me, in my circle that's a HUGE compliment.
When I was chosen to attend my first Tech Field Day event, I was most excited because I would finally get to meet Ivan in person. All my engineering friends were jealous and I was almost apoplectic when the moment finally arrived, fearful I would do something foolish like confuse SMTP and SNMP. This is when I discovered a really wonderful aspect to Ivan, if you're ever lucky enough to interact with him personally (stalking doesn't count), you'll find him to be witty, friendly, generous and gracious. He never makes you feel stupid for not understanding a protocol, the details of an RFC or an IEEE standard.
He's the consummate educator and a giving mentor to almost anyone who asks. The more I know him, the more I admire and respect his dedication to engineering. It truly is a vocation for him.
© Copyright ipSpace.net 2014 Page v
I guess I need to say something about SDN now, so here goes. While it could be the idea that finally revolutionizes networking, data centers and even security, I advise caution. Vendors will latch onto this new buzzword like a pitbull and promote it like the industry's new secret sauce. With this book, you'll be able to separate facts from hype and make some educated decisions regarding your own infrastructure.
Michele Chubirka Security architect, analyst, writer and podcaster December 2013
© Copyright ipSpace.net 2014 Page vii
Introduction to OpenFlow, from architectural basics to protocol details, and deployment and forwarding models (Chapter 3); OpenFlow implementation notes, describing the peculiarities of hardware and software implementations of OpenFlow switches (Chapter 4); OpenFlow scalability challenges, from control-plane complexity to packet punting and limitations of flow table updates (Chapter 5); OpenFlow use cases, from production deployment @ Google to interesting ready-to-use architectures and musings on potential future uses (Chapter 6); SDN beyond OpenFlow (Chapter 7), covering BGP-based SDN, NETCONF, I2RS, Cisco’s OnePK and Plexxi’s controller-based data center fabrics.
You’ll find additional SDN- and OpenFlow-related information on ipSpace.net web site:
Start with the SDN, OpenFlow and NFV Resources page; Numerous ipSpace.net webinars describe SDN, network programmability and automation, and OpenFlow (some of them are freely available thanks to industry sponsors); 2-day SDN, NFV and SDDC workshop will help you figure out how to use SDN, network function virtualization and SDDC technologies in your network; Finally, I’m always available for short online or on-site consulting engagements.
As always, please do feel free to send me any questions you might have – the best way to reach me is to use the contact form on my web site (www.ipSpace.net).
Happy reading! Ivan Pepelnjak July 2014
1 THE INITIAL HYPE
Academic researchers were working on OpenFlow concepts (distributed data plane with centralized controller) for years, but in early 2011 a fundamental marketing shift happened: major cloud providers (Google) and Internet Service Providers (Deutsche Telekom) created Open Networking Foundation (ONF) to push forward commercial adoption of OpenFlow and Software Defined Networking (SDN) – or at least their definition of it.
Since then, every single vendor started offering SDN products. Almost none of them come even close to the (narrow) vision promoted by the Open Networking Foundation (centralized control plane with distributed data plane), NEC’s ProgrammableFlow being a notable exception.
Most vendors decided to SDN-wash their existing products, branding their existing APIs Open, and claiming they have SDN-enabled products.
MORE INFORMATION
You’ll find additional SDN- and OpenFlow-related information on ipSpace.net web site:
Start with the SDN, OpenFlow and NFV Resources page; Read SDN- and OpenFlow-related blog posts and listen to the Software Gone Wild podcast; Numerous ipSpace.net webinars describe SDN, network programmability and automation, and OpenFlow (some of them are freely available thanks to industry sponsors); 2-day SDN, NFV and SDDC workshop will help you figure out how to use SDN, network function virtualization and SDDC technologies in your network; Finally, I’m always available for short online or on-site consulting engagements.
© Copyright ipSpace.net 2014 Page 1-
In March 2011, industry media quickly picked up the buzz created by the Open Networking Foundation (ONF) press releases and started exaggerating the already extravagant claims made by ONF, prompting me to write the following blog post.
OPEN NETWORKING FOUNDATION – FABRIC
CRAZINESS REACHES NEW HEIGHTS
Some of the biggest buyers of the networking gear have decided to squeeze some extra discount out of the networking vendors and threatened them with open-source alternative, hoping to repeat the Linux/Apache/MySQL/PHP saga that made it possible to build server farms out of low-cost commodity gear with almost zero licensing costs. They formed the Open Networking Foundation, found a convenient technology (OpenFlow) and launched another major entrant in the Buzzword Bingo – Software-Defined Networking (SDN).
Networking vendors, either trying to protect their margins by stalling the progress of this initiative, or stampeding into another Wild West Gold Rush (hoping to unseat their bigger competitors with low-cost standard-based alternatives) have joined the foundation in hordes; the list of initial members reads like Who’s Who in Networking.
Now, let’s try to figure out what SDN might be all about. The ONF Mission Statement (on the first page) says “ SDN allows owners and operators of networks to control and manage their networks to best serve their needs. ” Are the founding members of ONF trying to tell us they have no control over their networks and lack network management systems? It must be something else. How about this one (from the same paragraph): “ OpenFlow seeks to increase network functionality while lowering
© Copyright ipSpace.net 2014 Page 1-
the cost associated with operating networks. ” Now we’re getting somewhere – I told you it was all about reducing costs (starting with the networking vendors’ margins).
(Some of) the industry media happily joined the craze, parroting meaningless phrases from various press releases. Consider, for example, this article from IT World Canada.
“ SDN would give network operators the ability to virtualize network resources, being able to dynamically improve latency or security on demand ” If you want to do it, you can do it today, using dynamic routing protocols or QoS (latency), vShield/VSG (on-demand security) or a number of virtualized networking appliances.
Also, protocols like RSVP to signal per-session bandwidth needs have been around for more than a decade, but somehow never caught on. Must be the fault of those stupid networking vendors.
“ Sites like Facebook, Google or Yahoo would be able to tailor their networks so searches would be blindingly fast ” I never realized the main search problem was network bandwidth. I always somehow thought it was related to large datasets, CPU, database indices ... Anyhow, if the network bandwidth is the bottleneck, why don’t they upgrade to the next-generation Ethernet (10G/40G). Ah, yes, it might be expensive. How about deploying Clos network architecture? Ouch, might be a nightmare to configure and manage. How exactly will SDN solve this problem?
“ Stock exchanges could assure brokerage customers on the other side of the globe they’d get financial data as fast as a dealer beside the exchange. ” Will SDN manage to flatten & shrink the earth, will it change the speed of light, or will it use large-scale quantum entanglement?
“ It could be programmed to order certain routers to be powered down during off-peak power periods. ” What stops you from doing that today?
© Copyright ipSpace.net 2014 Page 1-
Not surprisingly, the OpenFlow hype did not subside, and totally inaccurate articles started appearing in industry press, prompting me to write yet another rant in April 2011.
OPENFLOW FAQ:WILL THE HYPE EVER STOP?
Network World has published another masterpiece last week: FAQ: What is OpenFlow and why is it needed? Following the physics-changing promises made during the Open Network Foundation launch, one would hope to get some straight facts; obviously things don’t work that way. Let’s walk through some of the points. While most of them might not be too incorrect from an oversimplified perspective, they do over-hype a potentially useful technology way out of proportions.
NW: “ OpenFlow is a programmable network protocol designed to manage and direct traffic among routers and switches from various vendors. ” This one is just a tad misleading. OpenFlow is actually a protocol that allows a controller to download forwarding tables into one or more switches. Whether that manages or directs traffic depends on what controller is programmed to do.
NW: “ The technology consists of three parts: [...] and a proprietary OpenFlow protocol for the controller to talk securely with switches. ” Please do decide what you think proprietary means. All parts of the OpenFlow technology are defined in publicly available documents under BSD-like license.
NW: “ OpenFlow is designed to provide consistency in traffic management and engineering by making this control function independent of the hardware it's intended to control. ” How can a low- level flow-table-control API provide what this statement claims it does? It all depends on the controller implementation.
© Copyright ipSpace.net 2014 Page 1-
NW: “ The programmability of the MPLS capabilities of a particular vendor's platform is specific to that vendor. ” And the OpenFlow-related capabilities of individual switches will depend on specific implementations by specific vendors. Likewise, the capabilities of an OpenFlow controller will be specific to that vendor. What exactly is the fundamental change?
NW: “ MPLS is a Layer 3 technique while OpenFlow is a Layer 2 method ” Do I need to elaborate on this gem? Let’s just point out that OpenFlow works with MAC addresses, IP subnets, IP flow 5- tuples, VLANs or MPLS labels. Whatever a switch can do, OpenFlow can control it.
But wait ... OpenFlow has no provision for IPv6 at all. Maybe Network World is so futuristic they consider a technology without IPv6 support a layer-2 technology.
© Copyright ipSpace.net 2014 Page 1-
Learn from the past bubble bursts. Whenever someone makes an extraordinary claim about OpenFlow, remember the “it can’t do anything you couldn’t do before” fact and ask yourself:
Did we have a similar functionality in the past? If not, why not? Was there no need or were the vendors too lazy to implement it (don't forget they usually follow the money)? Did it work? If not, why not? If it did - do we really need a new technology to replace a working solution? Did it get used? If not, why not? What were the roadblocks? Why would OpenFlow remove them?
Repeat this exercise regularly and you’ll probably discover the new emperor’s clothes aren’t nearly as shiny as some people would make you believe.
© Copyright ipSpace.net 2014 Page 1-
The OpenFlow pundits quickly labeled me as an OpenFlow hater, but I was just my grumpy old self ;) Here’s the blog post (from May 2011) that tried to set the record straight (not that such things would ever work).
FOR THE RECORD: I AM NOT AGAINST OPENFLOW
... as some of its supporters seem to believe every now and then (I do get severe allergic reaction when someone claims it will change the laws of physics or when I’m faced with technical inaccuracies not to mention knee-jerking financial experts). Even more, assuming it can cross the adoption gap, it could fundamentally change the business models of networking vendors (maybe not in the way you’d like them to be changed). You can read more about my OpenFlow views in the article I wrote for SearchNetworking.
On the more technological front, I still don’t expect to see miracles. Most OpenFlow-related ideas I’ve heard about have been tried (and failed) before. I fail to see why things would be different just because we use a different protocol to program the forwarding tables.
© Copyright ipSpace.net 2014 Page 1-
Most vendors have sensible answers. They are addressing different parts of the big problem, they talk about different technologies, but the answers aren’t bad. For example, every time I spotted a scalability issue, they were aware of it and/or had good answers (if not a solution).
Layer-2 is fading away (again). While every switching vendor will tell you how you can build large L domains with their fabric, nobody is actually pushing them anymore. And the only time layer-2 Data Center Interconnect (DCI) appeared on a slide, there was a unicorn image next to it. Even more, two vendors actually said they think long-distance VM mobility is not a good idea (you’ll have to watch the videos to figure out who they were).
We’re cutting through the hype. Even the OpenFlow symposium was hypeless. It’s so nice being able to spend three days with highly intelligent people who are excited about the next great thing (whatever it is), while being perfectly realistic about its current state and its limitations.
You’ll see lots of new things in the future. Even if you’re working in an SMB environment, you might get exposed to OpenFlow in the not-too-distant future (more about that in an upcoming post).
Get ready for a bumpy ride. Lots of exciting technologies are being developed. Some of them make perfect sense, some others less so. Some of them might work, some might fade away (not because they would be inherently bad, but because of bad execution). Now is the time to jump on those bandwagons – get involved (hint: you just might start with IPv6), build a test lab, kick the tires, figure out whether the new technologies might be a good fit for your environment when they become stable.
Disclosure : vendors mentioned in this post indirectly covered my travel expenses. Read the full disclosure (or a more precise one by Tony Bourke).
© Copyright ipSpace.net 2014 Page 1-
Even more, the real-life approach of numerous vendors I’ve seen during those two events made me overly optimistic – I thought we just might be able to get to real-life OpenFlow and SDN use cases without the usual vendor jousting and get-rich-quick startup mentality. This is what I wrote in October 2011:
I APOLOGIZE, BUT I’M EXCITED
The last few days were exquisite fun: it was great meeting so many people focusing on a single technology (OpenFlow) and concept (Software-Defined Networking, whatever that means) that just might overcome some of the old obstacles (and introduce new ones). You should be at least a bit curious what this is all about, and even if you don’t see yourself ever using OpenFlow or any other incarnation of SDN in your network, it never hurts to enhance your resume with another technology (as long as it’s relevant; don’t put CICS programmer at the top of it).
Watching the presentations from the OpenFlow symposium is a great starting point. I would start with the ones from Igor Gashinsky (Yahoo!) and Ed Crabbe (Google) – they succinctly explained the problems they’re facing in their networks and how they feel OpenFlow could solve them. If you’re an IaaS cloud provider, this is the time to start thinking about potentials OpenFlow could bring to your network, and if you’re not talking to NEC, BigSwitch or Nicira, you’re missing out. I would also talk with Juniper (more about that later).
Next step: watch the vendor presentations from the OpenFlow symposium. Kyle Forster presented a high-level overview of Big Switch architecture, Curt Beckmann from Brocade added a healthy dose of reality check (highly appreciated), David Meyer (Cisco) presented an interesting perspective on robustness and complexity (and several OpenFlow use cases), Don Clark from NEC talked about