0
Software Defined Networking – Beyond the Obvious

Peter van der Voort
Senior Solution Architect
peter@yenniq.nl
January 20...
Software Defined Networking – Beyond the Obvious
Everyone working in the field of networking, or even somehow being involv...
Software Defined Networking – Beyond the Obvious
Brocade SDN switches .......................................................
Software Defined Networking – Beyond the Obvious
This is a pretty abstract description but another description
on the same...
Software Defined Networking – Beyond the Obvious
by Deutsche Telekom, Facebook, Google, Microsoft, Verizon
and Yahoo!. The...
Software Defined Networking – Beyond the Obvious
supports flexible application provisioning of physical and
virtual resour...
Software Defined Networking – Beyond the Obvious
The Floodlight controller supports OpenFlow v1.0 and
works with physical-...
Software Defined Networking – Beyond the Obvious
Network Functions Virtualization complements SDN but
both do not depend o...
Software Defined Networking – Beyond the Obvious
With SDN, when a packet arrives at the switch, the switch
will forward th...
Software Defined Networking – Beyond the Obvious
A similar statement can be found with other switch models
as well. Howeve...
Software Defined Networking – Beyond the Obvious
devices (100 – 200 being typical) and is able to handle 1.8
million new f...
Software Defined Networking – Beyond the Obvious
The Contrail vRouter is a forwarding plane (of a distributed
router) whic...
Software Defined Networking – Beyond the Obvious
Brocade SDN switches

Brocade uses virtual routers which can be deployed ...
Software Defined Networking – Beyond the Obvious
The affinities look like what Cisco is doing with ACI with
the configurat...
Software Defined Networking – Beyond the Obvious
segments the network and when being used with, for
example, the OpenStack...
Software Defined Networking – Beyond the Obvious
would like and are not able to respond to changes and
customer demand.
Ho...
Software Defined Networking – Beyond the Obvious
desired (layer 2) separation can be realized with the SDN
controller.
Bec...
Software Defined Networking – Beyond the Obvious
Layer 2 connectivity
When an enterprise is comprised of multiple,
geograp...
Software Defined Networking – Beyond the Obvious
traditional load balancer may possibly become superfluous.
When SDN goes ...
Software Defined Networking – Beyond the Obvious
Communication between switches and controller can also
be run over standa...
Software Defined Networking – Beyond the Obvious
The OpenFlow specification allows the use of multiple SDN
controllers in ...
Software Defined Networking – Beyond the Obvious
Many manufacturers jumped onto SDN. Many of those
support open standards ...
References
1 www.opennetworking.org
2 www.openstack.org
3 www.cisco.com/go/one
4 www.cisco.com/go/aci
5 www.cisco.com/go/x...
Upcoming SlideShare
Loading in...5
×

SDN - beyond the obvious

1,647

Published on

All papers tell exactly what SDN is. But what is the current status? And what are practical applications? This paper dives into other matters than just the obvious ones.

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,647
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
91
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "SDN - beyond the obvious"

  1. 1. Software Defined Networking – Beyond the Obvious Peter van der Voort Senior Solution Architect peter@yenniq.nl January 2014
  2. 2. Software Defined Networking – Beyond the Obvious Everyone working in the field of networking, or even somehow being involved in IT, can not have missed it: there’s a new hype on its way, Software Defined Networking (SDN). At first glance, this designation seems a bit strange. Surely, every random router or switch is controlled by software, and so the network is controlled by software. Thus, has networking ever been NOT software defined? does it really mean for a company which wants to adopt this technology? Executive Summary If trying to define “Software Defined Networking” it could be said that SDN is an approach in which control of routing/switching is decoupled from switch hardware and control is being passed on to a software application, a controller. In other words, the data-plane is decoupled from the control-plane. When looking at the adoption of IPv6, we could conclude that many companies did not (yet) do much with it, even though IPv6 will truly become a necessity. So if companies do not line up to get this implemented, what does that mean for the adoption of SDN? For now, it’s mainly the suppliers of network equipment who are really into SDN and its derivatives. Following this definition, the subject is touched in many presentations, documents and whitepapers, which deal with the decoupling of data- and control-plane in great detail. And although that indeed is the basis for SDN, there’s much more to tell about it, like practical applications, but also the current state of affairs. Because when reading different articles, one could get the impression that a fully functional SDN solution can be bought off the shelf and implemented. But the question is whether that is really the case. This whitepaper highlights other items than just the obvious. But since the separation of data- and control-plane is still the basis, there will be a word about that as well. Further, we’ll have a look at different initiatives from different vendors and see what they really support at this moment in time, at least based on the information (or the lack thereof) on their own websites. Another question that can be asked in relation to SDN: Is it a hype? Or is “hype” perhaps not the right word? The fact of the matter is that everyone is talking about SDN and how this is going to change the future of networking. But what Next, there will be an overview of use-cases, limitations, security and practice, followed by a brief look into the future. 2 of 23
  3. 3. Software Defined Networking – Beyond the Obvious Brocade SDN switches ................................................................................... 13 Table of Contents Plexxi ................................................................................................................. 13 Executive Summary................................................................................................. 2 Plexxi SDN switches ....................................................................................... 14 Woods and trees ..................................................................................................... 4 Big Switch .......................................................................................................... 14 Software Defined Networking (SDN) .................................................................. 4 Big Switch SDN switches................................................................................ 14 OpenFlow ............................................................................................................ 4 Use cases ............................................................................................................... 15 OpenStack ........................................................................................................... 5 Network Access Control..................................................................................... 16 Cisco ONE and OnePK ......................................................................................... 5 Multi tenant network ........................................................................................ 17 Application Centric Infrastructure (ACI) .............................................................. 6 Quality of Service (QoS) ..................................................................................... 17 Application Policy Infrastructure Controller (APIC) ............................................. 6 Layer 2 connectivity........................................................................................... 18 Cisco ONE SDN Controller ................................................................................... 6 Limitations............................................................................................................. 18 Cisco eXtensible Network Controller (XNC) ......................................................... 6 Collateral damage ................................................................................................. 18 OpenDaylight ...................................................................................................... 7 Security .................................................................................................................. 19 Floodlight ............................................................................................................ 7 Practice.................................................................................................................. 21 Network Functions Virtualization (NFV) ............................................................. 7 Future .................................................................................................................... 21 The obvious ............................................................................................................. 8 References ............................................................................................................. 23 Initiatives ................................................................................................................ 9 Cisco .................................................................................................................... 9 Cisco SDN switches ......................................................................................... 9 HP ..................................................................................................................... 10 HP SDN switches ........................................................................................... 11 Juniper Networks .............................................................................................. 11 Juniper SDN switches .................................................................................... 12 Brocade ............................................................................................................. 12 3 of 23
  4. 4. Software Defined Networking – Beyond the Obvious This is a pretty abstract description but another description on the same site says: Woods and trees When diving into SDN it quickly becomes clear that there are many new terms associated with it. Some terms are generic, others are made up by the vendors. Some abbreviations describe specific techniques. This chapter provides an overview of the most important terms and relevant techniques. OpenFlow enables networks to evolve, by giving a remote controller the power to modify the behaviour of network devices, through a well-defined "forwarding instruction set". This description makes more sense already. But what does it actually mean in the real world? It means that a controller has the possibility to push flow entries to a switch. These flow entries decide how a specific packet is going to be forwarded. Software Defined Networking (SDN) This is most likely the most important abbreviation, Software Defined Networking. SDN is about decoupling data- and control plane of a switch, in which control is being delegated to an external controller. SDN is an umbrella term for several different initiatives. So what OpenFlow does is the following: When a switch (an OpenFlow switch) receives a packet which is part of a flow of which the switch does not yet have a flow entry in its flow table, the switch will forward the packet to the controller. The controller then decides about what to do with the packet (or rather, the flow of which this packet is part of). It can be dropped or an entry is going to be made in the flow table of the switch so that the switch knows how to handle consecutive packets of the same flow. OpenFlow OpenFlow is an open standard which is managed by the “Open Networking Foundation”1 (ONF) and is defined on their site as follows: OpenFlow is an open standard that enables researchers to run experimental protocols in the campus networks we use every day 4 of 23 OpenFlow is not the same as SDN. SDN is the umbrella term and OpenFlow is part of SDN. The OpenFlow protocol is maintained by the Open Networking Foundation. The OpenFlow switching specification was created in 2008 by several universities and the ONF was launched in 2011
  5. 5. Software Defined Networking – Beyond the Obvious by Deutsche Telekom, Facebook, Google, Microsoft, Verizon and Yahoo!. The initial members of ONF were: Broadcom, Brocade, Ciena, Cisco, Citrix, Dell, Ericsson, Force10, HP, IBM, Juniper, Marvell, NEC, Netgear, NTT, Riverbed and Verizon. Today, the ONF has more than 100 member companies. Just as with OpenFlow, this is quite a broad concept. Basically it’s a solution for creating, managing and deploying cloud services, specifically “Infrastructure as a Service” (IaaS). With this, it becomes easy to create and deploy virtual servers. OpenStack also adopted SDN which makes it possible to not only create virtual servers but also define network characteristics. So OpenStack is combined with SDN, specifically with OpenFlow. Version 1.0 of OpenFlow was released on December 31, 2009. The current version of OpenFlow is version 1.4 (released October 15, 2013). That being said, there are currently no switches which support version 1.4 so for real implementations version 1.3 (released June 25, 2012) is used. Cisco ONE and OnePK The “Cisco Open Network Environment” (ONE) 3 was announced by Cisco in June 2012. ONE is an extensive solution to open up networks, make them better programmable and above all, make them application aware. The first version of OpenFlow had some serious limitations which were resolved in version 1.1. Because of these limitations, the recommendation is to use at least version 1.3. However, only a few vendors actually support this version on their hardware. Cisco ONE is a programmable framework which consists of three parts: 1. Controllers and agents 2. Programmable interfaces 3. Virtual network overlays OpenStack The official description of OpenStack2 is: OpenStack is a global collaboration of developers and cloud computing technologists producing the ubiquitous open source cloud computing platform for public and private clouds 5 of 23 Cisco ONE provides a real-time feedback loop based on these three parts, giving the application the possibility to directly communicate with the network, giving the network the opportunity to interactively respond. In cases where there is much demand from the application side, for example because many users want to view a
  6. 6. Software Defined Networking – Beyond the Obvious supports flexible application provisioning of physical and virtual resources. The APIC will be released in the second quarter of 2014. specific video, ONE takes care (by the means of orchestration, or programmable interfaces) that the virtual infrastructure (virtual machines) is scaled up as needed and there is enough bandwidth available on the network. Cisco ONE SDN Controller ONE complements the current SDN approach. As part of ONE there is the “One Platform Kit” (OnePK) which provides an API platform for developers. The OnePK platform offers, according to Cisco, more possibilities than OpenFlow can. In February 2013, Cisco expanded the OpenFlow approach with the new Cisco ONE Software Controller. The ONE controller supports both OpenFlow and OnePK. The ONE controller was developed by Cisco but also supports OpenFlow switches from other vendors. Application Centric Infrastructure (ACI) In April 2013, Cisco donated a large part of the code of their ONE controller to the OpenDaylight project. In November 2013 Cisco introduced the “Application Centric Infrastructure” (ACI)4. ACI is, according to Cisco’s description, a comprehensive architecture with centralized automation and application profiles which are based on policies. ACI is developed as an open architecture and Cisco is working with about 20 companies amongst which are BMC, F5, Microsoft, NetApp and Red Hat. Cisco eXtensible Network Controller (XNC) The “eXtensible Network Controller”5 (XNC), part of the “Open Network Environment”, is a software application and is the first commercial version of the OpenDaylight controller. It runs on a Linux-based server, like the Cisco “Unified Computing System” (Cisco UCS). The XNC is based on the OpenDaylight controller but has a few additions to it. At this point in time, the XNC only supports OpenFlow version 1.0 Application Policy Infrastructure Controller (APIC) The “Application Policy Infrastructure Controller” (APIC) is the central point of automation en management for the Application Centric Infrastructure. The Cisco APIC provides central access to switch-fabric information, optimizes the application lifecycle (for scaling and performance) and 6 of 23
  7. 7. Software Defined Networking – Beyond the Obvious The Floodlight controller supports OpenFlow v1.0 and works with physical- and virtual switches. OpenDaylight OpenDaylight6 is an Open Source project, organized by the Linux foundation, and was announced in February 2013. The common goal is to promote the adoption and innovation of Software Defined Networking by creating a common, industry supported framework. The Floodlight controller is capable of handling mixed OpenFlow and non-OpenFlow networks. It can manage multiple “islands” of OpenFlow hardware switches. Additionally, there is support for the OpenStack cloud orchestration platform. OpenDaylight supports, but is not limited to OpenFlow. The OpenDaylight project has supporters like Arista Networks, Brocade, Cisco, Dell, IBM, HP, Juniper, Microsoft, etc. Network Functions Virtualization (NFV) The idea behind “Network Functions Virtualization” (NFV), as presented in a whitepaper from a group of network operators in October 20129, is to virtualize network functions and have them run on generic server hardware. So network functions are being virtualized and move from purpose-built appliances to generic server hardware. The functions can then be started at random places in the network, there were it’s needed, without the need to install specific (physical) appliances. In April 2013, Cisco donated a large part of the code of their ONE controller to the OpenDaylight project. The company “Big Switch Networks” (an SDN start-up) went into disagreement with Cisco about this and stepped back from their leadership position in the OpenDaylight project. BigSwitch’s argument was that the ONE controller is a year behind on the controller of themselves. Floodlight The advantages are, amongst others, a reduced Capex and Opex because less appliances need to be purchased or managed, reduced time-to-market for new services, increased flexibility to scale up or scale down and savings on power consumption. Floodlight7 is a project which was launched by “Big Switch Networks”8 in January 2012. Floodlight is a Java-based, Open Source SDN controller, developed by an open community of developers, and forms the core of the “Big Network Controller”, the commercial controller of Big Switch Networks. 7 of 23
  8. 8. Software Defined Networking – Beyond the Obvious Network Functions Virtualization complements SDN but both do not depend on each other. NFV can be deployed without SDN and vice versa. However, when deployed together they can strengthen each other. Despite the fact that the functions are virtualized, these functions still need to be controlled. This controlling can well be done by an SDN controller. And so SDN can be utilized regardless of the network being physical or virtual. Yet, there are functions that can be executed by either SDN or NFV. NFV could do tasks which are equal to tasks of the SDN controller. But since both SDN and NFV are still under development, all options are open. The data plane is always located within the physical switch. With a traditional switch, also the control plane is located in the physical device and this control plane makes decisions about how and where to send packets. In the SDN model, the control plane is detached from the physical switch and is located, in the form of a software application, on separate hardware. This is called the “SDN controller”. The SDN controller is capable of communicating with business applications so that these applications can request (for example) network resources with the SDN controller. Although NFV gained visibility in October 2012, and ETSI published10 the first specifications for it in October 2013, the concept is obviously not new. For a long time there has been virtual firewalls (although not always running on general purpose hardware) and virtual router software like Mikrotik’s RouterOS11 or Quagga12. The obvious The principle of Software Defined Networking is decoupling the control plane and data plane of a switch, see below figure. In a traditional switch, when a packet arrives at the switch, the control plane inside the switch decides what needs to happen with the packet, like forwarding out a specific switch port. Every packet with the same destination will always be switched out of the same switch port. 8 of 23
  9. 9. Software Defined Networking – Beyond the Obvious With SDN, when a packet arrives at the switch, the switch will forward the packet to the SDN controller to decide what needs to happen with the packet. Then, with a protocol like OpenFlow, the controller will configure the switch with a flow entry in the flow table (or forwarding table) so that the switch knows what to do with consecutive packets. Actions that can be taken include forwarding out of a specific switch port or dropping the packet so that effectively a firewall is created. Cisco As described above, Cisco has the “Open Network Environment” which is focussed to make networks more open, better programmable and make networks application aware. Coupled with this is OnePK, the API platform for developers. In November 2013 Cisco introduced the “Application Centric Infrastructure” (ACI) which should even better collaborate with applications to make resources ondemand available. ACI is mostly positioned at datacenters. Because the SDN controller has a complete overview of the entire network, all other switches in the path of the flow can be configured at the same time. Cisco makes use of the “eXtensible Network Controller” (XNC) which currently supports OpenFlow version 1.0. The SDN controller will monitor the entire network and can at any desired moment adjust a flow entry, based on for example the utilization of a specific path within the network. Cisco SDN switches Going by the information on the Cisco site, several switches can be utilized for SDN. When looking at, for example, the Catalyst 3850, its description says: Initiatives The heart of Cisco Catalyst 3850 is the new ASIC with programmability for future features and intelligence with investment protection. The new ASIC provides a foundation for converged APIs across wired and wireless, softwaredefined networking (SDN) support, and Cisco One Platform Kit (OnePK). Many manufacturers of networking equipment jumped on the SDN train. Additionally, many new companies seeing possibilities in SDN, were born. Below is an (non exhaustive) overview of companies which are developing initiatives. 9 of 23
  10. 10. Software Defined Networking – Beyond the Obvious A similar statement can be found with other switch models as well. However, looking at the datasheets of these switches, nothing can be found about SDN or the support for OpenFlow or ONE. So it’s not clear to what extend these switches can really be deployed in an SDN infrastructure. The same goes for the Nexus 3000 and Nexus 3100 series of switches. The general description mentions support for OpenFlow and OnePK but nothing in this regard in the datasheet. The Nexus 9000 series is built for Application Centric Infrastructure (although these switches can also be deployed in non-ACI mode, then these switches are “regular” Nexus switches). So far, the Nexus 9000 is the only product line which can be deployed for ACI-mode. Control of the Nexus 9000 switches in ACI-mode happens via the “Application Policy Infrastructure Controller” (APIC). The APIC is expected to be available in the second quarter of 2014. The Southbound protocol between APIC and switches is Cisco proprietary so this does not leave room for other switch manufacturers. However, there are southbound APIs by which firewalls or load balancers of other manufacturers can be integrated (providing these manufacturers make their equipment suitable) and as such can be part of the ACI network. HP HP is member of the Open Network Foundation and participates in OpenStack and the OpenDaylight project. HP’s SDN solution is not just positioned at the datacenter but is also suited for campus and branch offices. The SDN strategy of HP is based on open standards and delivers an SDN solution via a framework called “Virtual Application Networks”. HP was one of the first companies to announce support for OpenFlow on their Ethernet switches. The result is that currently more than 40 HP switch types support OpenFlow. In contrast to Cisco, HP implemented OpenFlow in a hybrid mode, making it possible to easily migrate from a traditional network to an SDN solution, without having to bulk-replace all routers and switches. An own SDN controller was developed, the “HP Virtual Application Networks SDN Controller”13. This controller is available as software or as an appliance and communicates with switches using OpenFlow. Besides this, support for OpenStack and CloudStack is integrated for fully automated provisioning of network, storage and compute. HP is one of the few who actually provides specifications of their SDN controller. It is claimed that the controller is capable of handling a maximum of 80000 OpenFlow ports (1000 – 2000 being typical), a maximum of 2000 OpenFlow 10 of 23
  11. 11. Software Defined Networking – Beyond the Obvious devices (100 – 200 being typical) and is able to handle 1.8 million new flows per second. Security is one of the main things with SDN. HP is using the “Sentinel Security Application” which is capable of stopping threats even before these reach the network. One of the possible applications of Sentinel is a DNS firewall which can stop threats at the moment a user wants to visit a malicious website. HP SDN switches The portfolio of HP holds several switches which provides support for OpenFlow: 2920 series, 3500 series, 3800 series, 5400 series, 8200 series, but also the HP Flexfabric 12900 datacenter core switch (although this switch is not available yet). HP supports OpenFlow version 1.3 on their switches since May 2013. The HP Virtual Application Networks SDN Controller can be downloaded from the HP website (60-day trial version) and supports both version 1.0 and version 1.3 of the OpenFlow protocol. Juniper Networks In December 2012, Juniper acquired “Contrail Systems”, a company that was founded earlier in 2012 and in which Juniper was a strategic investor. At September 16, 2013, Juniper announced the “Contrail”14 SDN solution being available. Juniper Networks Contrail (previously “JuniperV Contrail”) entails all components needed to create a virtual overlay network. This solution was tested at more than 40 clients worldwide. Juniper looks beyond just OpenFlow. Where OpenFlow mainly speaks about separation of flow control and packet forwarding, Juniper adds another two dimensions: Network Services and System Management. OpenFlow is being seen as “just a protocol and probably not the most important one”, where OpenFlow can not solve the most important problems, which can be done with a broader SDN approach. The Contrail system consists of two main components: The Contrail SDN controller and the Contrail vRouter. The Contrail SDN controller is a logically centralized, but physical distributed SDN controller which is responsible for management, control and analytical functions of the virtualized network. 11 of 23
  12. 12. Software Defined Networking – Beyond the Obvious The Contrail vRouter is a forwarding plane (of a distributed router) which runs on the hypervisor of a virtual server. It extends the network of physical routers and switches in a datacenter to a virtual overlay network. The protocol between the Contrail SDN controller and the Contrail vRouters (Southbound protocol) is based on the XMPP protocol which was already supported as a control protocol by most of the Juniper hardware. Contrail is designed to operate in an Open Source cloud environment and integrates with, for example, OpenStack and CloudStack. By using open standards, vendor lock-in is prevented. Contrail is available under the Apache 2.0 license. This means that everyone can use and modify the code without being obliged to disclose the modifications. Additionally, there is a commercial version of Contrail for which Juniper can provide support. The Open Source version has exactly the same functionality and scalability as the commercial version. Juniper SDN switches Because Juniper is using XMPP as Southbound protocol which is already used as control protocol for Juniper hardware, several different switches are compatible. In March 2013 Juniper introduced its first “programmable core switch”, the EX9200. Unfortunately, there is no upgrade path from the existing EX8200 core switch to the EX9200 and line cards of the EX8200 are not forward compatible. Juniper also has the “MX Series 3D Universal Edge Routers” which are closely aligned with Juniper’s SDN and NFV strategy. The architecture of these routers provides separation between control, management, services and forwarding planes. Brocade Brocade is one of the first members of the OpenDaylight project and follows a hybrid approach in regards to the implementation of OpenFlow on the MLXe platforms. This ensures that one switch port can use traditional routing or routing via OpenFlow at the same time. This is called hybrid-port mode. Brocade is supporter of open solutions and believes that openness is crucial for the success of SDN. The OpenDaylight project is in line with this vision. Because Brocade is compliant to the OpenFlow standard they can work with every controller, Open Source or proprietary, which also complies to this standard. Brocade works with OpenDaylight to design and build a common and open controller. 12 of 23
  13. 13. Software Defined Networking – Beyond the Obvious Brocade SDN switches Brocade uses virtual routers which can be deployed for Network Functions Virtualization. These virtual routers were developed by a company called “Vyatta”, which was acquired by Brocade in November 2012. At this moment, the “Vyatta 5400 vRouter” is already available. The “Vyatta 5600 vRouter” will be available in spring 2014. These virtual routers are more related to NFV rather than SDN. With respect to physical devices offers the MLX series support for OpenFlow version 1.0 in hybrid-port mode. Additionally, OpenFlow (v1.0) is supported by the NetIron XMR series, the NetIron CER2000 series and the NetIron CES2000 series. Plexxi The starting point of Plexxi is that conversations on the network should be able to determine how the network looks like, or at least how the path between two endpoints look like. And although network conversations are important, some conversations are more important than others. Therefore it is important to determine relationships between communicating elements en determine what is important within these conversations, like bandwidth, jitter, latency, security or something else. With this in mind, Plexxi developed an SDN controller, the “Plexxi Control”15, which has a real-time, comprehensive overview of the entire network to determine the most efficient path for a specific communication flow. Plexxi has named this “Affinity Driven Networking”. Affinity refers to different resources within a datacenter network which are needed to run a specific application or to provide a specific service. These resources are (physical or virtual) compute, storage and networking. This collection of resources is called an “Affinity Group”. A traditional network strives to make these affinities irrelevant so that a uniform network can be deployed and all applications can have the same resources available. However, it would probably be better when resources are made available based on what is needed for specific applications. Therefore, the network should be organized non-uniform so that the largest amount of available resources is there where it is needed most (and average at places where capacity is less needed). The software of the Plexxi Controller discovers automatically which capacity is needed for specific affinities and configures the network dynamically to meet this capacity requirements. The affinities can be configured manually or being discovered automatically, for example based on TCP/UDP port numbers. 13 of 23
  14. 14. Software Defined Networking – Beyond the Obvious The affinities look like what Cisco is doing with ACI with the configuration of policies and the mapping of relationships and flows. Both the policies of Cisco and the affinities of Plexxi specify things like priority of a specific flow. It is striking to see that both Plexxi and Cisco talk about “Application Centric infrastructure”. Plexxi SDN switches Plexxi offers two types of switches for connecting servers: the “Plexxi Switch 1” and the “Plexxi switch 2”. The first one provides a switching capacity of 1.28 Tbps, the second switch a capacity of 2.56 Tbps. Both switches are controlled by the Plexxi Controller using a proprietary protocol. Next to these two switches there’s the “Plexxi Switch Interconnect” switch, which is connected in a ring-topology. The server switches are in turn connected to this ring. Communication between controller and switches is done via a proprietary protocol. In contrast to many other manufacturers, Plexxi does not use OpenFlow. Big Switch Big Switch Networks is an SDN start-up and was founded in 2010. To their own saying, they are market leader in Open Source SDN products. Big Switch has developed their own, commercial SDN controller, the “Big Network Controller”16. This controller forms the basis for the “Open SDN Suite” which provides for network-wide automation en dynamic response to realtime events. The “Big Network Controller” is based on the Floodlight controller of the Project Floodlight. The Big Network Controller is a centralized control system with a distributed data store for redundancy and scalability. Multiple controller nodes can be configured in a cluster for high-availability. These controllers can then switch-over to each other in case of issues. The controller comes in both a virtual edition and a physical appliance. As the Big Network Controller is based on the Floodlight controller, both support the same version of the OpenFlow protocol, which is version 1.0. Big Switch SDN switches Big Switch does not build any hardware switches themselves but provides, in the form of “Switch Light”, an Open Source software platform for physical, bare-metal switches and switches within hypervisors. Switch Light provides an OpenFlow data plane for SDN. Besides the Switch Light, there’s the “Big Virtual Switch”, a network virtualization appliance for the datacenter, based on an OpenFlow switching fabric. This switch dynamically 14 of 23
  15. 15. Software Defined Networking – Beyond the Obvious segments the network and when being used with, for example, the OpenStack plugin, the Big Virtual Switch can dynamically discover whether there are new workloads or whether existing workloads have changed. Following this, new virtual network segments can be created, in line with previously defined policies. Each virtual network segment supports broad security possibilities, Quality of Service and other policies. Use cases Before diving into possible applications for SDN, let’s see what the actual reason is for SDN. In the past 20 years there were many innovations in equipment that is used to interact with applications and services. Additionally, individuals are using more and more devices per person and all of these devices need access to the network. The network itself however, has never changed. And while in the area of server virtualization there has been great progress in, for example, speed of deployment, the network has lagged behind. Therefore, it is time for change so that the network can adopt quickly to necessary changes. From a traditional point of view, the best performing and most stable networks are those which are built with purpose-built hardware, like routers and switches. But it takes a lot of time to design this kind of hardware, build it, and write appropriate software for it. That means that adding features on an ad-hoc basis is nearly impossible. So customers in need of some new functionality almost always get to deal with the roadmap of manufacturers. These limitations with respect to hardware, and this limitations with respect to flexibility are the main reasons why companies are not able to innovate at the speed they 15 of 23
  16. 16. Software Defined Networking – Beyond the Obvious would like and are not able to respond to changes and customer demand. However, now is the time to change. Thanks to advances in “off the shelf” hardware, it becomes possible to make a shift from “networking in hardware” to “networking in software”. And this shift is what forms the basis of SDN and NFV technologies: software can be detached from hardware. The resulting benefits include, but are not limited to: • Reduction of Capex: Network functionality runs on standard, off the shelf hardware; • Reduction of Opex: Because network components are easy to program, it becomes easier to design, deploy and manage infrastructures; • Flexibility: Organisations are able to quicker deploy new applications to respond to changing demands; • Innovation: Organizations become able to design new types of applications, new services and new business models; • It becomes possible to provide new network services without the need to configure individual devices and without being dependant on manufacturers for providing new functionality. With this is mind, possible uses of SDN can be explored. The emphasis is on “possible” because some uses may not be easy, or even impossible to implement in real networks. Network Access Control The idea behind SDN is that every allowed flow should be defined on forehand. This way, one can determine which PC (or user) is allowed access to which server, application, internet, etc. When a PC wants to send data via the network, the first packet that reaches the (OpenFlow) switch will be forwarded to the SDN controller. The SDN controller will check who the originator of the packet is, what the destination is, and whether the flow is allowed or not. This form of access control can be used to allow or deny users access to the network or specific resources. But this form of access control can also be used for wireless clients and Bring Your Own Device (BYOD) applications. Also allowing guests to the company network will become quite easy because these guests can be placed in a virtual network within the company network and allowed access to, for example, only the internet. In this situation, there is no need to create separate vlans or to do any devicespecific configuration at all. It will still be necessary to authenticate users but this action can be delegated by the SDN controller to an authentication server. For an additional level of security, traditional vlans make use of private vlans so that devices within the same vlan are not able to communicate with each other. With SDN, configuration of private vlans is no longer needed and the 16 of 23
  17. 17. Software Defined Networking – Beyond the Obvious desired (layer 2) separation can be realized with the SDN controller. Because the security policy is defined centrally on the SDN controller, it is easy to audit this policy. Or at least easier than having to audit multiple rule bases on multiple physical firewalls and access-lists on routers. Multi tenant network One of the most obvious applications of SDN is probably the multi tenant network. As described above, when guestusers can be placed inside their own virtual network, that of course is also possible with multiple tenants inside a datacenter. On a logical level, tenants can be completely separated from each other while still using the same physical infrastructure. The advantage over the configuration of vlans (besides the fact that device-level configuration is no longer needed) is that tenants are now allowed to use overlapping IP-space, something that is not just possible inside a traditional network. Quality of Service (QoS) As mentioned in the “Network Access Control” section, it is the aim that every allowed flow is specified in advance. With this configuration it is also specified which priority should be given to a specific flow. In other words, what the QoS settings should be. In traditional networks, QoS can be configured quite well. But once configured, it is static. With SDN is becomes possible to execute specific policies based on different circumstances. Internet Service Providers (ISPs) would get the possibility to easily rate-limit Over The Top (OTT) traffic (like video) and it would become easier to enforce the “Acceptable Use Policy”. But also other types of companies could benefit from a dynamic QoS, like: • Prioritize video traffic when there’s an in-company webcast; • Prioritize HTTP traffic during lunch time; • Prioritize SAP traffic during an end-of-month run; • Prioritize Citrix traffic when many people are working from home. The possibilities are probably endless. And the result is that resources are available there where the business needs it to be. 17 of 23
  18. 18. Software Defined Networking – Beyond the Obvious Layer 2 connectivity When an enterprise is comprised of multiple, geographically dispersed datacenters, it may be useful to have layer 2 connectivity between the different locations. When layer 2 connectivity is established, it no longer matters where a (virtual) server is active. The only possible drawback is the location of the layer 3 gateway. It could be possible that a server runs in one datacenter while the layer 3 gateway is active in another datacenter, causing traffic to travel across the interconnect between the datacenters. When using SDN, it doesn’t matter where a specific server runs. Because routing is provided by the SDN controller, there is no need for a layer 3 gateway. This makes it possible to stretch layer 2 across multiple locations and still route traffic in an optimal way. Limitations When using OpenFlow as a protocol to configure flow entries in a switch, it should be realized that a specific entry is for a specific flow. All consecutive packets in the same flow will follow the same path as the initial packet. It is not possible to do “per packet” forwarding, for example to load balance. Because if that would be done, not only the first packet of a flow would need to be sent to the SDN controller but also all following packets. The SDN controller would therefore be in the forwarding path of the flow, and would most likely become the bottleneck in regards to performance. Another limitation, or at least a challenge, is troubleshooting. Because traffic flows are determined in a dynamic way, it is possible that traffic from source A to destination B will be routed via another path than a flow from source A to destination C, even though destinations B and C are in the same subnet. And it’s also possible for a flow to follow path A at one point in time, but go via path B a moment later, based on (external) circumstances. Collateral damage Some functions which are traditionally taken care of by specific appliances can now be done using SDN. For example, functions like firewalling and load balancing. But also routing is done by SDN. So are these types of appliances become obsolete when SDN is going to be introduced? When looking at a firewall as a simple packet filter, it seems like that functionality can easily be handled by the SDN controller. After all, it’s the SDN controller where a flow is defined – and thus permitted. In regards to load balancing it is not possible to do perpacket load balancing. But balancing per flow is possible. And with that functionality in the SDN controller, a 18 of 23
  19. 19. Software Defined Networking – Beyond the Obvious traditional load balancer may possibly become superfluous. When SDN goes one step further and actively monitors how busy a specific server is, and can balance flows based on that information, then also for that kind of functionality a load balancer is no longer needed. functionality could still be provided by a router. Then again, software like “Quagga” (previous “Zebra”) makes it possible to do BGP peering on general-purpose hardware. Security Routers make decisions about where to send a packet. That intelligence is taken over by the SDN controller, so no router is needed anymore. Looking at these examples it is clear that some functionalities are going to be replaced by SDN. But when more is needed than just packet filtering (like deep packet inspection) there is still going to be a need for a dedicated appliance. The SDN controller will then just make the decision to route a certain flow via a firewall for inspection. In this setup, by the way, it is not necessary for the firewall to be in the “physical” path of the flow. The need for load balancers will probably decrease, for sure when more intelligent SDN solutions will be implemented in which the SDN controller gets feedback from the network and from the applications. Within a LAN environment, routers will not really be needed anymore, all that is needed is SDN enabled switches. For connections with the outside world things may not be so obvious. BGP peerings will still be needed as a way to exchange external route information. This Why would security be of extra concern with SDN? Well, one of the reasons is that SDN technology is still very premature. So almost guaranteed there will be security flaws. Besides, when all control about flows is with one device, it is clear that this device needs protection. Because he who controls the controller, controls the network and thus the application behaviour. The OpenDaylight controller can be configured with different types of users like “System Admin”, “Network Admin” and “Network Operator”. HP’s SDN controller does not (yet) support any form of role-based access. Before controller and switch can communicate with each other, they need to know about each others existence. Therefore, a switch will be (manually) configured with the IP-address of the controller. Then, a switch can initiate a TLS-encrypted connection with the controller and both the switch and controller authenticate using certificates. This process prevents someone from installing a rogue controller in the network. 19 of 23
  20. 20. Software Defined Networking – Beyond the Obvious Communication between switches and controller can also be run over standard TCP. In this case, additional security measures should be taken to prevent eavesdropping. making it possible for such an application to claim disproportionate resources with the SDN controller. It could be possible for some internal server to be compromised after which an attacker could use this server as step stone to the rest of the internal network. In a traditional environment, access to systems is controlled with for example an access-list of firewall. However, if such a measure is not in place the attacker would have free access due to the fact that routing is just available. In the context of security it is also important to think about availability. What happens when the controller fails? The OpenFlow protocol describes two failure modes: “fail secure mode” and “fail standalone mode”. One of these modes will be chosen, depending on the configuration of the switch. It is up to the switch to detect failure of the connection with the controller, for example using timeouts for echo-requests. In an SDN infrastructure, there is only routing for defined flows. That means that a random server does not have routing to the SDN controller. So because of the lack of routing, it could be argued that an SDN infrastructure is more secure than a traditional infrastructure. In “fail secure mode”, the existing flows will continue to be active but creation of new flows won’t be possible because there won’t be any communication with the SDN controller. The existing flows are subject to configured timeouts, so eventually all flows in a switch may be gone. An attacker could cause quite some damage when taking over the SDN controller, like shutting down the entire network. But it’s also possible that the attacker has other goals and only wants to manipulate specific flows, which can be of importance with stock-trading. In “fail standalone mode”, the switch will behave like a traditional switch and all packets will be forwarded as with a traditional Ethernet switch. The “failure standalone mode” is usually only available on hybrid switches. Related to availability is the question about how to make a backup of the SDN controller configuration, and especially how to restore this backup. Because, when the controller is down, there is no routing in the network so how is a file from the backup server going to be send to a new controller. The conclusion that follows is that a controller should never be a single machine. It is also important to look at the security of the APIs that a controller has to have for communicating with applications. Besides the fact that the SDN controller itself is a software application which will undoubtedly contain bugs, also software applications of third parties will contain bugs, 20 of 23
  21. 21. Software Defined Networking – Beyond the Obvious The OpenFlow specification allows the use of multiple SDN controllers in which one can take the role of “master”. The Cisco ACI solution dictates the use of at least three controllers. Practice Although Google is one of the companies that implemented SDN, it seems like there are not many real implementations besides some setups in university networks. One of the reasons for this is probably the lack of real implementations causing companies to be reluctant to implement SDN. So a chicken-and-egg situation. Also, there are some serious issues to be resolved first before an extensive implementation can take place. One thing is scalability, how many switches is a controller capable of programming within an acceptable timeframe? Or how many flow entries can be pushed to a switch within a reasonable amount of time? Obviously it is possible to define flows on forehand and push these to the switches. In that way, there is central control over flow entries but after that it’s a relatively static environment. Probably comparable with a traditional network. Also the migration path will play an important role. Some manufacturers offer hybrid switches, making it possible to gradually migrate. Other manufacturers do not offer a hybrid solution so there would need to be a “big bang” scenario rather than a migration. And that may be a frightening thought. In regards to a hybrid solution, this should not only go for a switch but there should also be the possibility to combine OpenFlow switches with traditional networking equipment like routers, switches and firewalls. Future Despite the fact that SDN is still in its infancy, it most definitely offers new possibilities. It’s just the question whether companies will need these possibilities or at least recognize the value of it. And although SDN is still in the “hype-phase” there is also a clear movement to reality. Nevertheless, as described in the introduction, looking at the speed of adoption of IPv6 it remains the question how fast SDN will be adopted. The usefulness and necessity will have to become very clear. SDN will most likely add real value when implemented as complete framework in which virtual servers can be spinned up automatically, and in which there is a solid feedback loop from the network. 21 of 23
  22. 22. Software Defined Networking – Beyond the Obvious Many manufacturers jumped onto SDN. Many of those support open standards like OpenFlow and develop their own standard at the same time. The question remains which system will end up as best. Cisco with it’s ACI platform uses a proprietary Southbound protocol but offers APIs so that third parties can interface as well. Juniper uses XMPP as Southbound protocol and although that is an open protocol, if no other controller- or switch manufacturer is going to adopt it, there will still be a reasonable chance to vendor lock-in. HP opened an “AppStore” for SDN applications, offering unlimited possibilities for developers. Undoubtedly many new, SDN related companies will be born over the next few years, providing more and new applications which no one has thought of before. To date, there are a lot of SDN flavours already and many will appear in the coming years. For companies which want to adopt SDN, it is not going to be easy to make a choice between all the vendors and all the offerings without running the risk to vendor lock-in and without running the risk to an unsupported network when a start-up company doesn’t survive. For now, the marketing machines will run at full speed! 22 of 23
  23. 23. References 1 www.opennetworking.org 2 www.openstack.org 3 www.cisco.com/go/one 4 www.cisco.com/go/aci 5 www.cisco.com/go/xnc 6 http://www.opendaylight.org/ 7 www.projectfloodlight.org/ 8 www.bigswitch.com 9 http://portal.etsi.org/NFV/NFV_White_Paper.pdf 10 http://www.etsi.org/news-events/news/700-2013-10-etsi-publishes-first-nfv-specifications 11 http://www.mikrotik.com/software.html 12 http://www.nongnu.org/quagga/ 13 http://h17007.www1.hp.com/us/en/networking/products/network- management/HP_VAN_SDN_Controller_Software/index.aspx#tab=TAB1 14 http://www.juniper.net/us/en/products-services/sdn/contrail/ 15 www.plexxi.com/products/plexxi-control/ 16 http://www.bigswitch.com/products/SDN-Controller All opinions expressed in this paper are my own and do not reflect those of the company I work for © 2014 – Peter van der Voort – peter@yenniq.nl
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×