Javier Guillermo – InFocus Blog | Dell EMC Services https://infocus.dellemc.com DELL EMC Global Services Blog Thu, 13 Dec 2018 11:38:05 +0000 en-US hourly 1 https://wordpress.org/?v=4.9.7 Demystifying Software-defined Networks Part VI: SD-WAN Adoption Accelerates as Platforms Mature https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networks-part-vi-sd-wan-adoption-accelerates-as-platforms-mature/ https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networks-part-vi-sd-wan-adoption-accelerates-as-platforms-mature/#respond Wed, 19 Sep 2018 18:30:12 +0000 https://infocus.dellemc.com/?p=36230 It’s been a few years since the promising new future technology called SD-WAN came on the scene, so is this related to SDN or a new concept? SD-WAN stands for Software-defined Networking in a Wide Area Network. It shares key pillar concepts of SDN like separating the control plane from the data plane and the […]

The post Demystifying Software-defined Networks Part VI: SD-WAN Adoption Accelerates as Platforms Mature appeared first on InFocus Blog | Dell EMC Services.

]]>
It’s been a few years since the promising new future technology called SD-WAN came on the scene, so is this related to SDN or a new concept?

SD-WAN stands for Software-defined Networking in a Wide Area Network. It shares key pillar concepts of SDN like separating the control plane from the data plane and the centralized control of the network via the SDN controller. They both allow the enablement of automation and orchestration of network devices. So, what’s the difference then? It’s like a forest from the trees expression as SDN has multiple use cases: Application Delivery Networks, Central Policy Control, Terminal Access Point Aggregation (TAP), Data Center Optimization, Virtual Core and Aggregation, SD-WAN, etc.

SD-WAN is an application (one of the many applications) of SDN technology with a focus on Wide Area Networks, allowing companies to build higher performance WANs using lower-cost internet access technologies.

SDN

Figure 1: SDN Use Cases.

The Benefits of SD-WAN

SD-WAN was designed with the idea of solving challenges like optimizing network connectivity between conventional branch offices and data centers and MPLS (Multi-Protocol Label Switching), deploying or modifying existing services in a much faster and efficient way, network congestion, packet loss, jitter, latency, etc. The reality is that “old traffic flows” are not designed for the explosion of traffic and bandwidth due to the success of cloud computing and on demand multimedia applications (think of live music, video streaming, etc.). The other major issue is not a technical one but about Operational Cost (OPEX). T1 or MPLS circuits are expensive, the former may have better point to point performance, but it is static, while the latter is highly configurable. SD-WAN technologies are aiming to bring the cost per Mbyte down by at least 60%, according to latest estimates.

Another added benefit of SD-WAN is that will work over a variety of media (for example you can also use a wireless connection), allowing service chaining, policy based centralized control, application intelligence, automation, flexibility and elasticity, etc. The reason why Internet connections weren’t used for enterprise WAN services was that the internet was always a conglomerate of different technologies best effort networks. Simply put: It wasn’t reliable or secure enough for most corporate needs. SD-WAN was designed to change all of that.

Some of you may be thinking, yes, all of that sounds fantastic Javier, but like with other implementations of SDN, you will need to make a huge investment as most solutions consist on both a central controller (often hosted in the cloud) and access nodes on-premises that support the technology, meaning you will have to throw away a lot of old equipment and make a big investment in new premises equipment, right? And how about what you mentioned at the beginning about SD-WAN being mainstream already, aren’t we really years from that?

Yes and no.

Leaders in the SD-WAN Space

Remember the blogs we wrote about the three different kinds of SDN (Open, APIs and Overlays)? While Open SDN would require a higher CAPEX investment but will bring additional innovations and advantages, SDN over overlays and SDN over APIs will be ideal for brown field development and reuse of legacy equipment. To help make SD-WAN a reality for companies, two of the leaders in this area: Cisco and VMware have made some bold moves.

Cisco bought Viptela for $610 Million and it is going to make its SD-WAN technology available not only on all ISR and ASR routers but will also on ENCS 5000 routers that are around 4 years old. That will mean in practical terms, that Cisco will push SD-WAN in over 1,000,000 routers in a question of weeks, the most massive mainstream implementation of this technology. This is great, right? Not if you’re a customer that has spent years trying to uncouple themselves from vendor lock in.  One of the key benefits for SDN implementation was to avoid closed systems, utilize inexpensive white boxes instead, avoiding vendor hegemony and lock-in again.

Cisco, like most networking manufacturers, want to keep their hardware hegemony as long as possible, for obvious reasons, and they are not shy about touting the advantages of one end-to-end Cisco SD-WAN solution.

Figure 2: Why Cisco SD-Branch is Better than a ‘White Box.’

The other leader in this space, VMware, also recently purchased (November 2017) a leader in SD-WAN technology: VeloCloud, for an estimated $449 million (according to Futuriom). Although VeloCloud offers multiple x86 appliances options with the software preloaded, it was designed to run on any x86 multi core hardware and offer some additional features like active network performance measurement (BFD), Forward error control and comes on several flavors (Premises or Cloud for Viptela and Internet, Hybrid SD-WAN or Premises for VeloCloud). Both Viptela and VeloCloud work as an overlay, support zero touch provisioning, have North bound REST and support Policy provisioning via the controller.

Although VMWare has a full SDN-NFV ecosystem with its NFV3.0 (including VIM, SDN Controller NSX, vRO for Orchestration, etc.), it is not trying to force customers into a monolithic approach.  In fact, VMware is even allowing a closer integration with Openstack thanks to VIO (VMware Integrated Openstack) and VeloCloud also works with a non-VMware ecosystem as well.

Customers will have to weigh the pros and cons of a closed system versus a vendor independent approach. If Cisco’s bet on the closed system pays off, they will be bringing back the vendor lock-in approach of the 90s, having an all end to-end-Silo from the hardware at the bottom, to the NFVI, VNFs and Orchestration.

Figure 3 – Vendor hegemony Trojan Horse? (Source: Martin Kozlowski)

Summary

SD-WAN is becoming completely mainstream but the old discussion of having open multivendor systems where the customer chooses the best for their needs versus a single vendor silo seem to be making a comeback. In total fairness, every option has pros and cons, one silo of a company could theoretically provide better end-to-end support and seamless integration between different components. On the other hand, open multivendor systems will increase innovation speed, customer freedom and speed of adoption.

Part of the SDN Blog Series

Demystifying Software-defined Networks Part V: A Decade Later, Where Are We Now? (Part II)

Demystifying Software-defined Networks Part IV: A Decade Later, Where Are We Now?

Demystifying Software-defined Networks Part III: SDN via Overlays

Demystifying Software-defined Networks Part II: SDN via APIs

Demystifying Software-defined Networks Part I: Open SDN Approach

Sources

Why Cisco SD-Branch is better than a ‘white box’

www.futuriom

www.sdxcentral.com

 

The post Demystifying Software-defined Networks Part VI: SD-WAN Adoption Accelerates as Platforms Mature appeared first on InFocus Blog | Dell EMC Services.

]]>
https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networks-part-vi-sd-wan-adoption-accelerates-as-platforms-mature/feed/ 0
Demystifying Software-defined Networks: A Decade Later, Where Are We Now (Part II)? https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networks-a-decade-later-where-are-we-now-part-ii/ https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networks-a-decade-later-where-are-we-now-part-ii/#comments Mon, 09 Jul 2018 09:00:22 +0000 https://infocus.dellemc.com/?p=35646 In part IV of this SDN/NFV blog series, I talked about how we arrived to the present situation of SDN, a bit of its history, as well as future plans. In addition, I cited the key implementation of Google’s SDN as an example. Deployment Example #2 Another company that is making use of SDN is […]

The post Demystifying Software-defined Networks: A Decade Later, Where Are We Now (Part II)? appeared first on InFocus Blog | Dell EMC Services.

]]>
In part IV of this SDN/NFV blog series, I talked about how we arrived to the present situation of SDN, a bit of its history, as well as future plans. In addition, I cited the key implementation of Google’s SDN as an example.

Deployment Example #2

Another company that is making use of SDN is Gap Inc. – yes, it’s not a technology company but the American fashion icon and parent company of Old Navy, Banana Republic and Intermix. They’re using an application of SDN to connect its Internet stores to one another in the corporate network. In the words of the Mr. Patel, Senior Network Architect and CTO of the SD-WAN-SDN project at GAP, “This software approach is about 50% less expensive than the conventional method of connecting stores together in a wide area network. Companies with many stores or branch offices are beginning to look at SDN networking to connect their stores together, but Gap is one of the first to implement this technology at scale and make public its efforts.”

Deployment Example #3

Microsoft Azure is my third example. The Redmond giant is actively implementing SDN for its Azure Public Cloud. In the words of Albert Greenberg, Microsoft lead technologist: “One of the key principles behind Azure’s SDN is its ‘Virtual Layer 2 Architecture,’ a Layer 3 Cross-Fabric that spans the entire data center.” He continues, “Automation is key to managing a massive, high-bandwidth network built with commodity components. The network state service that Azure uses as its control plane abstracts away the individual networks.”

To be able to mix and match the best network element hardware, Microsoft followed a very similar approach to Facebook, using the open source Switch Abstraction Interface (SAI) API to program the ASICs of the switches.

We also have major carriers like AT&T with its Domain 2.0 initiative and Telefonica with Unica. AT&T had a data traffic increase of 100,000% on its wireless network (not a typo) since 2009 to present day. That’s why they needed SDN and NFV implemented across their network because it’s the only technology that allows adding capacity faster with automated deployment and pushes out fast upgrades at the speed of the Internet. AT&T is still planning to have 75% of their network virtualized by 2020.

So What’s the Conclusion?

SDN and NFV are both a bit of hype and disruptive reality. I concur on the view that if SDN and NFV were just bubbles, they would have burst by now. It’s because there’s a real need for both of these technologies that the industry has kept investing in them.

If we think about it, we have been using CLI to configure L2-L3 Network elements for the last 35+ years without many major changes. It is true that we have new protocols, the bandwidth, processing power, and capacity has skyrocketed, as well as the complexity of the networks, but the job of network engineers didn’t change much until we started pushing for SDN/NFV[1]. The paradigm changed – centralized control, separation of planes, abstraction, generic hardware, open source, etc. It is also worth noting that part of the difficulty of its implementation is not just technical, but cultural: In most organizations, networking is typically siloed from the rest of the IT organization. The new approach to networking, SDN and DevOps, requires a different mindset and it takes convincing, training, effort and time.

SDN Forecasts

According to a report from BCC research, the estimation for SDN global revenues will jump to over $56 billion in 2020, plus, in the near future, 100G will be the norm and manual control won’t be enough. We will need to have automation all across the network from the top to the bottom. The agility that SDN and NFV technologies provide will be key soon.

I believe these technologies have spearheaded the biggest leap in networking technology over the last 20 years, it’s just taking a bit longer to completely take over. Once we have the problematic interoperability and standardization figured out, we’ll have massive implementations across the board.

Initial focus of OPNFV was in between 2008-2015; present and future focus is 21016-onward.

We have many initiatives, like ONAP and OPNFV, just around the corner. ONAP (a project combining AT&T’s ECOMP and Open-O[2]) provides for automatic, policy-driven interaction of these functions and services in a dynamic, real-time cloud environment. It’s not just a run-time platform; it includes graphical design tools for function/service creation, delivering capabilities for the design, creation, orchestration, monitoring, and lifecycle management of VNFs, SDNs and high level services. OPNFV is focusing on the higher layers with quality open source software for the virtualization layer, specifically on the ETSI NFV interfaces VI-Ha, Vn-Nf, Nf-Vi, Vi-Vnfm, and Or-Vi in the diagram above (from ETSI architecture)[3].

Summary

As a closing thought, I’d say 2020 will be the date for the massive implementation of SDN/NFV. We’ve come a long way in just 10 years but work needs to be done on the higher layers in particular; on orchestration and consolidation of the platforms we have in place, and improving the interoperability on automation features.

Part of the Blog Series

Demystifying Software-Defined Networks Part IV: A Decade Later, Where Are We Now?

Demystifying Software Defined Networks Part III: SDN via Overlays

Demystifying Software-Defined Networks Part II: SDN via APIs

Demystifying Software-Defined Networks Part I: Open SDN Approach

Sources

[1] SDN | sdx central

[2] How ONAP Will Merge Millions of Lines of Code from ECOMP and Open-O

[3] ETSI Standards

 

The post Demystifying Software-defined Networks: A Decade Later, Where Are We Now (Part II)? appeared first on InFocus Blog | Dell EMC Services.

]]>
https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networks-a-decade-later-where-are-we-now-part-ii/feed/ 1
Demystifying Software-defined Networks: A Decade Later, Where Are We Now (Part I)? https://infocus.dellemc.com/javier_guillermo/demystifying-sdn-a-decade-later-where-are-we-now/ https://infocus.dellemc.com/javier_guillermo/demystifying-sdn-a-decade-later-where-are-we-now/#comments Wed, 27 Jun 2018 09:00:15 +0000 https://infocus.dellemc.com/?p=35594 The joke goes around that the true meaning of Software Defined Networking (SDN) is “Still Don’t Know.” SDN is a technology that allows network administrators to no longer be reliant on static architecture of traditional hardware/networks, but freed to centrally and dynamically manage the network via open, programmatic interfaces. This is accomplished by separating the […]

The post Demystifying Software-defined Networks: A Decade Later, Where Are We Now (Part I)? appeared first on InFocus Blog | Dell EMC Services.

]]>
The joke goes around that the true meaning of Software Defined Networking (SDN) is “Still Don’t Know.” SDN is a technology that allows network administrators to no longer be reliant on static architecture of traditional hardware/networks, but freed to centrally and dynamically manage the network via open, programmatic interfaces. This is accomplished by separating the control plane (the system that decides where the network traffic will go) from the data plane (the systems that forward the traffic onto their destination).

Introduction – The Journey

Although we can trace the origins of SDN to the early 2000s, we’ve just reached the decade mark when the creator of the controllers (Ethane) first released Openflow. In 2008, we saw the birth of NOX and the first Openflow Switches. Later on, we saw the entry of Nicira (acquired by VMware in 2012, now part of Dell Technologies), the creation of Google’s B4 project, and the Open Network Foundation (2011) and the development of ONOS.

He Said, She Said

Looking to the present, we see that with SDN, similar to many new emerging technologies of the past, seems to have developed two well-defined perspectives at opposite extremes. On one side, you have people who focus on the negative aspect and believe that SDN hasn’t lived up to the hype over the last decade. On the other side, you have folks who believe SDN will continue to grow and will explode in the 2020s, making bold predictions on market share and expansion rates[1].

But where is SDN really, now that a decade has gone by?

We all know that SDN is complicated, but is it an acronym for ‘Still Don’t Know?’

I believe we are somewhere in the middle of these two extreme perspectives. It’s true that we still have many experts claiming that NFV is not going to be good enough for high performance applications, that you will always have better performance on dedicated HW/SW. But then again, not everything that is going to be virtualized requires the absolute best performance and the priority is how easy it is to deploy, automate, reuse and its resulting CAPEX/OPEX savings.

On the SDN side, there were plenty of controllers five years ago and all efforts were being centered on Open Daylight (there are many commercial controllers based on this architecture, such as Floodlight, ONOS and NSX). The consolidation is good, but has it lived up to the hype that started in 2012-2013? Has it been massively adopted and implemented everywhere?

Not quite.

In the words of Diego Lopez, chair of ETSI NFV ISG[2] and a senior technology expert at Telefonica, “Perhaps we rushed to commercialize NFV (and SDN) before we laid down the proper foundations and principles for the technology. We can all agree that the initial timeframes given six years ago were too optimistic and will need to be more realistic in the future, and there are still numerous problems left to be solved.”

The main issue customers face with technology adoption is the lack of standardization, especially on the higher layers and interoperability. We’ve come a long way from just having SDN in research centers and academia at top tech universities, to several practical massive implementations in the “real world.”

#1 Deployment Example

The key deployment was spearheaded by Google[3], which manages one of the largest (if not the largest, with the permission of AWS) enterprise and cloud deployment in the world. It is no secret that Google has been a strong supporter of Open Daylight and Openflow, while continuing to encourage other controllers like ONOS. According to Amin Vahdat “the fundamental design philosophy was that the network should be treated as a large-scale distributed system, leveraging the same control infrastructure we developed.”

The company strategy is based on four pillars:

  1. Jupiter is a data center interconnect capable of supporting more than 100,000 servers and 1Pb/s of bandwidth.
  2. B4 WAN interconnect is Google’s implementation of SD-WAN[4] which constructs B4 to connect its data centers to one another and replicate data in real-time between individual campuses. “It’s built on white boxes with our software controlling it,” said Vahdat.
  3. Andromeda is a network functions virtualization (NFV) stack that delivers the same capabilities available to its native applications all the way to containers and virtual machines running on the Google Cloud Platform.
  4. Espresso, not the coffee (!), is the fourth and perhaps more challenging piece of the strategy. It extends SDN to the peering edge of Google’s network where it connects to other networks across the planet (Google exchanges data with ISPs at 70 metros and takes up to 25% of all internet traffic). The Espresso technology allows Google to dynamically choose from where to serve individual users based on measurements of how network connections are performing in real time. Espresso allows us to maintain performance and availability in a way that is not possible with existing router-centric Internet protocols, separating the logic and control of traffic management from the confines of individual network boxes. This translates to higher availability and better performance through Google Cloud than is available through the Internet at large.

Espresso improves user experience on two fronts: Firstly, it automatically selects the best data center location to server a specific tenant/user, based on real time statistics and formulas. Secondly, it separates the logic and traffic control from the individual routers, following the tenant of SDN of the separation of planes. A single distributed system with an aggregated vision of the overall network will always perform and make better decisions than an individual hardware router.

Summary

There is no clear agreement in the question ‘did SDN live up to the hype a decade later?’ Its adoption has been growing steadily but hasn’t replaced “traditional” networking yet. Once consolidation/ standardization and interoperability within the higher layers is achieved, its adoption may be unstoppable and major implementations like Google’s may become the norm.

Our team of expert Dell EMC Services consultants and advisers, as always, are here to answer your questions and advise a solution that best fits your needs.

Sources

[1] Software Defined Networking: Technology and Global Markets

[2] ETSI Standards

[3] Espresso makes Google cloud faster, more available and cost effective by extending SDN to the public internet

[4] SDxInsights on SD-WAN

Blog Series

Demystifying Software Defined Networking Part III: SDN via Overlays

Demystifying Software-Defined Networks Part II: SDN via APIs

Demystifying Software-Defined Networks Part I: Open SDN Approach

 

The post Demystifying Software-defined Networks: A Decade Later, Where Are We Now (Part I)? appeared first on InFocus Blog | Dell EMC Services.

]]>
https://infocus.dellemc.com/javier_guillermo/demystifying-sdn-a-decade-later-where-are-we-now/feed/ 2
Demystifying Software-defined Networks Part III: SDN via Overlays https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networking-part-iii-sdn-via-overlays/ https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networking-part-iii-sdn-via-overlays/#comments Mon, 26 Mar 2018 09:00:46 +0000 https://infocus.dellemc.com/?p=34457 SDN is no longer ‘the next big thing’ on the networking horizon, but a reality and inevitability for enterprises and service providers. IDC estimates the SDN market has grown from a $406 million industry in 2013 to more than a $6.6 billion market in 2017, and predicts it will continue to grow at a 25.4% […]

The post Demystifying Software-defined Networks Part III: SDN via Overlays appeared first on InFocus Blog | Dell EMC Services.

]]>
SDN is no longer ‘the next big thing’ on the networking horizon, but a reality and inevitability for enterprises and service providers. IDC estimates the SDN market has grown from a $406 million industry in 2013 to more than a $6.6 billion market in 2017, and predicts it will continue to grow at a 25.4% compound annual growth rate to $13.8 billion by 2021[1].

This proliferating nature of SDN deployments is the catalyst for my writing a blog series to ‘demystify’ its architectural approach to making network technology agile and flexible as the virtualized server and storage infrastructure of the modern data center.

In Demystifying Software Defined Networking Part I and Part II, I reviewed:

  • The basics of SDN and how networking is evolving
  • The separation between the control plane and the data plane
  • The three main types of SDN: Open SDN, SDN by APIs and SDN via Overlays
  • The principles of the first approach, Open SDN, as well as the principles of the second approach, SDN by APIs

In this post I’ll describe the principles of the technology by overlays, a method used by software and networking giants like VMware, Cisco and Juniper Networks. I will also discuss the pros and cons of SDN via Overlay deployments.

Figure 1: A typical multi-layer network: the physical layer, the optical layer (fiber cables, optical attenuators, filters, etc.), the SONET/SDH layer (multiplexer, digital cross connects, etc.) and the IP layer (L2-L3 equipment, mainly switches, routers and gateways).

 

So, what’s in an overlay network?

A simple definition is a network built on top of another network, as shown in Figure 1. This concept of overlays is not something new. We have been universally using overlay networks prior to the creation of the Internet.

What makes the overlay networks concept unique, compared to the other two approaches I’ve discussed, is that the current physical network is left untouched with networking devices and their configurations unchanged. On top of that network, SDN hypervisor-based networks are created; an ideal scenario for an enterprise/carrier that doesn’t want to incur major hardware expenses.

Note: a network hypervisor is a piece of software that provides an abstraction layer for network hardware, allowing network engineers to create virtual networks that are completely decoupled and independent from the underlying physical network (see Figures 2 and 3).

Figure 2: Overlay Networks and Physical Network

The beauty of this SDN technology is that the virtual network traffic runs above the physical network infrastructure, hypervisors inject traffic into the overlay network, and receive traffic from it. The network traffic of the overlay networks is passed through physical devices, at the end points, but the endpoints are completely unaware of the details of the physical topology, as well as the routing thought process or any other kind of advanced or basic network functions.

What mechanism makes all of this possible, you ask?

Network encapsulation – the inclusion of one data structure within another structure where the first data structure is hidden for the time being.

Figure 3: Network Encapsulation

Virtual Tunnel Endpoint (VTEP)

When a packet enters the edge of the virtual network at the source, the networking device (usually the hypervisor) will take the packet in its entirety and encapsulate it within another frame. This edge of the virtual network is called a virtual tunnel endpoint or VTEP. The Network hypervisor then takes this encapsulated packet and based on information programmed by the controller, sends it to the destination’s VTEP. This VTEP decapsulates the packet and forwards it to the destination host and then the encapsulated packet is sent across the physical infrastructure. The IP addresses are those of the source and destination VTEP.

This process is also known as MAC in IP tunneling because the entire MAC frame is encapsulated.

Different vendors have developed different technologies to archive this process with different pros and cons, but the underlaying idea is the same. (VMware and Cisco use VXLAN, but Microsoft prefers NVGRE.)

Examples of SDN via Overlays:

There are two major products for this type of SDN implementation.

Juniper Networks

Juniper launched the SDN controller Contrail using NETCONF and XMPP protocols instead of OpenFlow. Confusing for some is that Contrail released the code of Contrail and Open Contrail with varying technical Support levels provided by the company.

But let’s not confuse Open Source with Open SDN as defined in Demystifying Software Defined Networking I. Keep in mind that the southbound API of Contrail is XMPP and indeed a standards-based approach. Since the control plane still resides on those virtual switches and XMPP is not directly programming the data plane, I would not consider it Open SDN, but an SDN via hypervisor-based overlays approach.

VMware Network Virtualization Platform (NVP) and Network Security (NSX)

Prior to Nicira’s acquisition by VMware in 2012, Nicira’s Network Virtualization Platform (NVP) was a very popular SDN via hypervisor-based overlays offering in the market.

Since the acquisition, NVP is now bundled with VMware’s vCloud Network and Security (vCNS) and is marketed as VMware NSX where it continues to enjoy considerable market success, according to Gartner market data (2016) [2]. VMware’s NSX also includes an open source virtual switch called Open vSwitch (OVS) that works with the hypervisors in the NVP architecture. Open vSwitch has become the most popular Open Source virtual switch implementation, even outside of NVP implementations. Interestingly, NVP uses OpenFlow as the southbound interface from its controller to the OVS switches that form its overlay network. Thus, technically speaking, this solution is both an SDN via hypervisor-based overlays and an Open SDN implementation.

What are the Pros and Cons of Deploying NVP and NSX?

The Pros:

  • It’s great for data centers as any modern data center would already have some kind of virtualization running for compute and storage, and perhaps a hyperconverged solution.
  • It minimizes the amount of CAPEX required to bring some of the benefits of SDN to your data center as well as reduce the impact to changes on the running configuration.
  • It addresses, efficiently and cheaply, issues like the MAC address explosion for cloud and data centers, as in all these devices MACs are hidden within the encapsulated frames
  • It allows implementation of centralized automation and agility to deploy new networks, taking a fraction of time compared to deploying an entirely new physical network over existing physical ones.
  • It addresses VLAN limitations, tunneling all the traffic and not needing VLANs for supporting multiple tenants isolated from one another.
  • Using a solution like VMware NSX is coupled with a robust software product and its technical support provides a distinct advantage.

The cons:

  • SDN via Overlays does not “open” the devices as with Open SDN (see Demystifying Software Defined Networking I).
  • Leaving the physical infrastructure unchanged, you will still be required to do some manual or script-based configuration and maintenance of the physical network.
  • You won’t be able to handle traffic prioritization on the physical network.

Summary

SDN is emerging out of the early adopter and into the early mainstream stage of its development and will play a role in shaping the next-generation of networks for use cases such as SD-WAN, microsegmentation and IoT.

Our team of expert Dell EMC Services consultants and advisers, as always, are here to answer your questions and advise a solution that best fits your needs.

As an additional resource, feel free to reference Laddie Suk’s blog Failure to Migrate: A Case Study in NFV Deployment and his newly published whitepaper “Bridging the Operational Gap to Accelerate NFV Deployment.”

Sources

[1] Network World: What SDN is and where it’s going

[2] Here’s Who Made Gartner’s 2016 Magic Quadrant For Data Center Networking

 

The post Demystifying Software-defined Networks Part III: SDN via Overlays appeared first on InFocus Blog | Dell EMC Services.

]]>
https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networking-part-iii-sdn-via-overlays/feed/ 2
Demystifying Software-defined Networks Part II: SDN via APIs https://infocus.dellemc.com/javier_guillermo/demystifying-sdn-sdn-via-apis/ https://infocus.dellemc.com/javier_guillermo/demystifying-sdn-sdn-via-apis/#respond Mon, 16 Oct 2017 09:00:52 +0000 https://infocus.dellemc.com/?p=32850 in my previous blog, I explained the basics of Software Defined Networking (SDN), how SDN has evolved to this point, the separation between the control plane and data plane, plus we named the three main flavors of SDN: Open SDN, SDN by APIs and SDN via overlays. We also covered the principles of the first […]

The post Demystifying Software-defined Networks Part II: SDN via APIs appeared first on InFocus Blog | Dell EMC Services.

]]>
in my previous blog, I explained the basics of Software Defined Networking (SDN), how SDN has evolved to this point, the separation between the control plane and data plane, plus we named the three main flavors of SDN: Open SDN, SDN by APIs and SDN via overlays. We also covered the principles of the first approach, Open SDN.

In this blog, I will cover the implementation of this technology via APIs, a preferred method used by traditional networking hardware companies.

SDN implementation via APIs refers to southbound APIs that configure and program the control plane active on the device. There are a number of legacy network device APIs in use that offer different degrees of control (SNMP, CLO, TL1, RADIUS, TR-069, etc.) and a number of newer ones (NETCONF/YANG, REST, XMPP, BGP-LS, etc.) that offer different degrees of control over the network devices, data plane, topology, etc., each having different advantages and disadvantages. I won’t cover them in depth in this blog post but I want to make sure we all understand one key difference between them and the Open SDN approach: OpenFlow is used to directly control the data plane, not just the configuration of the devices and the control plane.

SDN by APIs Overview

REST-API-LEGACY-API

 

Let’s start with some understanding on how network configuration and management is traditionally done. In the networking world of today, we still configure most devices though a Command Line Interface (CLI) by either connecting to the console of a device or through telnet/ssh of the device. Each device is then configured individually. That has been networking configuration 101 for more than 25 years.

The new SDN approach I covered in my previous blog has many technological and operational advantages, but it requires a company, institution or operator to replace old hardware for new hardware that supports the technology, and in some cases, new protocols like OpenFlow.

Obviously, no company is going to replace all of their hardware overnight, as it would require considerable expense, implementation and architecture challenges that, until resolved, could impact company operations. In addition, there would be plenty of non- technical issues, like employees knowing device X and networkOSY like the palm of their hands and not looking forward to the time it might take to learn new technology and processes.

When a company decides to transform to a software defined networking infrastructure, they may not get support from their existing Network hardware vendor, which may have been enjoying hefty margins in network hardware sales and not thrilled to push a technology that will make their expensive boxes replaceable for cheap vendor agnostic white boxes.

Architectural views of SDN by API

Architectural views of SDN by API

The left image shows an architecture view of a traditional network device (router, switch, etc.) with the software components and applications (Upper Rectangle) and hardware components (Lower Rectangle) such as ASIC (application specific integrated circuit for packet processing) and memory.

By adding a RESTful API interface we add an additional abstraction layer and upgrade legacy devices allowing to be controlled by an SDN controller using non OpenFlow standards.

SDN by API Vendors

Juniper Networks
We can argue that Juniper was one of the SDN pioneers in this area, through JunOS SDK, providing a rich set of tools for programmability and automation for all JunOS compatible devices. Some of the options available would allow you to control data plane packet processing, plus a wide variety of device functions. This SDK was created before SDN was popular, but as academia was already working on the SDN idea though Ethane back in 2007, perhaps Juniper was already looking to the SDN future back then. In present day, Juniper launched the SDN controller contrail, using NETCONF and XMPP protocls instead of OpenFlow.

Cisco Networks
We can’t talk about networking without talking about Cisco Networks. Cisco originally had its own proprietary program called Cisco onePK, consisting of a broad set of APIs that were proprietary for Cisco devices. Cisco now has two SDN-via-API controllers: the APIC-EM (Application Policy Infrastructure Controller-Enterprise Module) and the the APIC-DC (focused on Data center). Cisco is also implementing a new policy based protocol called OpFlex.

Arista
Arista Software Driven Cloud Networking (SDCN), combines the principles that made cloud computing the unstoppable force that it is: automation, self service provisioning, and linear scaling. Arista’s SDCN Is based around its API-centric definition of SDN and about the scaling of the existing control plane with different APIs.

OpenDaylight
Opendaylight is a bit of a hybrid, on one site it uses OpenFlow so we may be tempted to think it is purely an OpenSDN approach.. However the ODL controller also supports southbound APIs that program the legacy control plane on network devices, using plugins such as NETCONF and BGP-LS/PCE-P. There are different companies, for example, Fujitsu, that is developing its SDN Controller (Virtuora) based on OpenDaylight and no longer being Open Source.

Summary

SDN via APIs is a hybrid approach that will make the transition to the controller-based networking technology model more gradual and easier, especially for companies with a lot of legacy equipment or with close ties to specific proprietary networking vendors. Another plus is not having the centralized point of failure you may face in a pure OpenSDN. Compared to the other two approaches Tt ranks in-between for scale and performance..

On the negative side you won’t have support for Stateful Flow awareness or Deep packet Inspection plus it won’t escalate easily to mega data centers.

For additional information, please check part I of this series; Demystifying SDN: Open SDN Approach and view information on our just released Dell EMC NFV Ready Bundle for VMware.

The post Demystifying Software-defined Networks Part II: SDN via APIs appeared first on InFocus Blog | Dell EMC Services.

]]>
https://infocus.dellemc.com/javier_guillermo/demystifying-sdn-sdn-via-apis/feed/ 0
Demystifying Software-defined Networks Part I: Open SDN Approach https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networking-open-sdn-approach/ https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networking-open-sdn-approach/#comments Tue, 05 Sep 2017 09:00:17 +0000 https://infocus.dellemc.com/?p=32257 The joke goes around that the true meaning of Software Defined Networking (SDN) is “Still Don’t Know”.  In short, SDN is a technology that allows network administrators to no longer be reliant on static architecture of traditional hardware/networks, but freed to centrally and dynamically manage the network via open, programmatic interfaces.  This is accomplished by […]

The post Demystifying Software-defined Networks Part I: Open SDN Approach appeared first on InFocus Blog | Dell EMC Services.

]]>
The joke goes around that the true meaning of Software Defined Networking (SDN) is “Still Don’t Know”.  In short, SDN is a technology that allows network administrators to no longer be reliant on static architecture of traditional hardware/networks, but freed to centrally and dynamically manage the network via open, programmatic interfaces.  This is accomplished by separating the control plane (the system that decides where the network traffic will go) from the data plane (the systems that forward the traffic onto their destination).

Software Defined Networking (SDN): Business Drivers

What’s driving the need to change from the transitional method of managing networks and move towards a SDN approach?  There are three key catalysts in the industry driving the need for network change as show in the graphic below.

SDN Business Drivers

Mobility, cloud, and IoT are three very real ways in which business is being digitally transformed and I will cover them in more detail in future blogs.

SDN, along with Network Function Virtualization (NFV) and other network virtualization technologies, are key to successfully transitioning to a data center that can adopt and deliver cloud solutions.  In this series of short blogs, I hope to give you some insights on topics important to better understanding SDN.

There are also three main ways to approach Software Defined Networking (SDN):

1. Open SDN

2. SDN by APIs

3. SDN by overlays

In this blog, I will be focusing on the Open SDN approach.  What is meant by Open SDN?  Both SDN and NFV technologies have a large open source community, committed to contributing to projects that promote open standards. As you see in the image below, separating the control and forwarding planes removes the controlling software from the device and onto a controller.  The device then handles the forwarding and data plane functions, while the controller handles the control plane functions.

Software Defined Networking_2

This approach tends to be focused around OpenFlow (OF), which is considered to be one of the first SDN standards, and allows a SDN controller to directly interact with network devices (routers, switches, etc.) as you see in the image below.  OF is just the protocol, so you could have Open SDN with other protocols if you choose.

This approach you see in the image below provides:

  • Simplified devices
  • A centralized controller
  • Enforcement of rules implemented by devices
  • Open environment for research and innovation
  • Interoperability
  • True network operating system
  • OF as the southbound standard protocol

Software Defined Networking_3

 

Check back for the next blog in the series where I will cover the SDN Approach by API.

Looking for more information on SDN and NFV? Check out NFV Operating Models – How to Mix Oil and Water (also known as IT Operations and Network Operations)

The post Demystifying Software-defined Networks Part I: Open SDN Approach appeared first on InFocus Blog | Dell EMC Services.

]]>
https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networking-open-sdn-approach/feed/ 2