Learning OpenDaylight E-Book

Reza Toghraee

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 314

Veröffentlichungsjahr: 2017

Beschreibung

OpenDaylight is an open source, software-defined network controller based on standard protocols. It aims to accelerate the adoption of Software-Defined Networking (SDN) and create a solid foundation for Network Functions Virtualization (NFV).
SDN is a vast subject; many network engineers find it difficult to get started with using and operating different SDN platforms. This book will give you a practical bridge from SDN theory to the practical, real-world use of SDN in datacenters and by cloud providers.
The book will help you understand the features and use cases for SDN, NFV, and OpenDaylight.
NFV uses virtualization concepts and techniques to create virtual classes for node functions. Used together, SDN and NFV can elevate the standards of your network architecture; generic hardware-saving costs and the advanced and abstracted software will give you the freedom to evolve your network in the future without having to invest more in costly equipment.
By the end of this book, you will have learned how to design and deploy OpenDaylight networks and integrate them with physical network switches. You will also have mastered basic network programming over the SDN fabric.

Leseprobe

Title Page

Learning OpenDaylight

The art of deploying successful networks

Reza Toghraee

BIRMINGHAM - MUMBAI

Copyright

Learning OpenDaylight

Copyright © 2017 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

First published: May 2017

Production reference: 1260517

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham 

B3 2PB, UK.

ISBN 978-1-78217-452-3

www.packtpub.com

Credits

Author   

Reza Toghraee

Copy Editor  

Gladson Monteiro

Reviewers  

Pradeeban Kathiravelu

Moiz Raja

Project Coordinator  

Virginia Dias

Commissioning Editor  

Kartikey Pandey

Proofreader  

Safis Editing

Acquisition Editor  

Rahul Nair

Indexer  

Francy Puthiry

Content Development Editor  

Sweeny Dias

Graphics  

Kirk D'Penha

Technical Editor  

Prashant Chaudhari

Production Coordinator  

Shraddha Falebhai

About the Author

Reza Toghraee, CCIE 22518, is a network and security expert. For the last 15 years, he has designed and deployed many large campus and data center projects, leveraging his skills in networking, security, virtualization, compute, and storage. He has worked with all networking vendors. In 2013, he started exploring the hardware and software of Ethernet switches and was inspired to build an Audio Video Bridging (AVB) Ethernet switch by designing hardware and software protocols. Soon, he discovered SDN and early SDN controllers, and dedicated his time to promoting and contributing to SDN and the OpenNetworking community. He works as a freelance consultant for SDN, NFV, network automation, network virtualization, and cloud projects.He can be reached via his e-mail: [email protected].

Acknowledgments

First of all, I would like to thank all of you readers. Thanks for reading this book, and I hope it can help you start your SDN journey. Since this is my first book, it might not be perfect--there may be a few mistakes. Please accept them as my first book-authoring experience.

Thanks to Packt Publishing, who gave me the opportunity to write this book. Thanks to all members of the editorial team for their contributions that made this book what it is.

I would like to thank the London OpenDaylight meetup group, a very friendly group with amazing folks. Special thanks to Stace Hipperson, Giles Heron, and Nathan Sowatskey for all their contribution to the group.

A big thanks to Aseem and Aneeta Gupta for their inspiration that helped me build a new me.

I will use this opportunity to thank folks from the Linux Foundation, who are in charge of OpeDaylight and OPNFV.

Thanks to the great people form Inverse for their support and providing the PacketFence SDN-NAC plugin for OpenDaylight.

At the end, a big thanks to my wife, Neda, and my daughter, Hanna, for their motivation and allowing me to spend lots of family time on this book.

About the Reviewers

Pradeeban Kathiravelu is an open source evangelist. He is a PhD researcher at INESC-ID Lisboa/Instituto Superior Técnico, Universidade de Lisboa, Portugal, and Université Catholique de Louvain, Belgium. He is a Fellow of Erasmus Mundus Joint Degree in Distributed Computing (EMJD-DC), researching a software-defined approach to quality of service and data quality in multi-tenant clouds. He holds a master of science degree, Erasmus Mundus European Master in Distributed Computing (EMDC), from Instituto Superior Técnico, Portugal and KTH Royal Institute of Technology, Sweden. He also holds a first class bachelor of science in engineering (Hons) degree, majoring in computer science and engineering, from the University of Moratuwa, Sri Lanka. His research interests include software-defined networking (SDN), distributed systems, cloud computing, web services, big data in biomedical informatics, and data mining. He is very interested in free and open source software development and has been an active participant of the Google Summer of Code (GSoC) program since 2009, as a student and as a mentor. He has also reviewed OpenDaylight Cookbook (ISBN:978-1-78646-230-5).

I would like to thank Prof. Luís Veiga, my MSc and PhD advisor, for his continuous guidance and encouragement throughout my 5 years at Instituto Superior Técnico.

Moiz Raja is a software developer with more than 20 years' experience in building enterprise software. His primary experience is in building highly scalable distributed applications, but he also has years of experience building front-end software for Windows and the Web.

Moiz has worked at several large enterprise software companies, such as Avaya and Cisco. At Avaya, he built the Contact Center software, which included the Avaya Interaction Center and Avaya one-X Agent. At Cisco, Moiz served as a committer on the OpenDaylight controller project, where he contributed to building the MD-SAL distributed data store. He was voted a top-10 developer 2 years in a row while working on OpenDaylight and was also a presenter at the OpenDaylight summit in 2015.

Moiz is currently employed as a principal engineer at Viptela, which is a leading SD-WAN software startup, where he is helping build a highly scalable network management controller.

www.PacktPub.com

For support files and downloads related to your book, please visit www.PacktPub.com.

Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.comand as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.

At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.

https://www.packtpub.com/mapt

Get the most in-demand software skills with Mapt. Mapt gives you full access to all Packt books and video courses, as well as industry-leading tools to help you plan your personal development and advance your career.

Why subscribe?

Fully searchable across every book published by Packt

Copy and paste, print, and bookmark content

On demand and accessible via a web browser

Customer Feedback

Thanks for purchasing this Packt book. At Packt, quality is at the heart of our editorial process. To help us improve, please leave us an honest review on this book's Amazon page at https://www.amazon.com/dp/1782174524.

If you'd like to join our team of regular reviewers, you can e-mail us at [email protected]. We award our regular reviewers with free eBooks and videos in exchange for their valuable feedback. Help us be relentless in improving our products!

Dedication

To my parents, Bahman and Soheyla, who have always been supporting me in all situations without any expectations.

Table of Contents

Preface

What this book covers

What you need for this book

Who this book is for

Conventions

Reader feedback

Customer support

Downloading the example code

Downloading the color images of this book

Errata

Piracy

Questions

Introduction to SDN - Transformation from Legacy to SDN

Why are we going towards SDN?

Components of an SDN

Controlling the fabric

Difference between direct fabric programming and overlay

Futuristic view on networking and SDN

BUM (broadcast, unknown, multicast)

SDN controllers

OpenDaylight

Core features of SDN

SDN use cases

Core differentiator between SDN controllers

Current SDN controllers

OpenDaylight as an SDN controller

Traditional networking terms and features in the world of SDN

Summary

Overview of OpenDaylight

Overview of OpenDaylight components

OpenDaylight modules

Authentication, Authorization, and Accounting

Application-Layer Traffic Optimization (ALTO)

BGP LS PCEP

Bit Indexed Explicit Replication

CAPWAP

Cardinal monitoring service

Controller shield - unified security

Device Identification Driver Management (DIDM)

DluxApps the UI

Energy management (EMAN)

Fabric As A Service

Federation

Genius generic network interfaces

Internet of Things Data Management (IoTDM)

L2 switch

Link Aggregation Control Protocol

Messaging4Transport

Network Address Translation (NATApp)

NETCONF as a southbound protocol

NetVirt

NeutronNorthbound

The ODL-SDNi SDN interface

The OF-CONFIG OpenFlow configurator

The OpenFlow protocol library

OpFlex

OVSDB southbound integration

Service function chaining

SNMP4SDN - using SNMP as a southbound protocol

VPNService

Virtual Tenant Network (VTN)

The NeXt UI

Summary

OpenDaylight Installation and Deployment

Plan to deploy OpenDaylight

ODL basics

Prerequisites

Virtual machine size

Operating system

Java

ODL distribution

Standalone installation

IP address settings

Java installation

Downloading and installing ODL

First run with ODL

Distributed installation

Step 1 - Editing the Akka configuration file

Step 2 - Editing the module-shard configuration file

Step 3 - Starting the ODL

Step 4 - Enabling MD-SAL clustering in ODL

Verifying the installation and accessing the web interface

Topology

Node

YANG UI

Running ODL on a Docker container

What's going on behind the scenes of Docker on Windows?

How did we create the ODL container image for Docker?

Summary

Building a Virtual SDN Test Lab with Virtual Switches

What is Mininet?

How to stepwise build a Mininet-enabled virtual switch

Step 1 - Downloading

Step 2 - Importing the Mininet OVF file to a hypervisor

Step 3 - Powering on

Step 4 - Setting the IP address

Step 5 - Basic connectivity testing

Integrating a Mininet virtual switch with OpenDaylight

Mininet commands

Viewing the flow mappings

Using OVS as an SDN-capable virtual switch

Summary

Basic Networking with OpenDaylight

Layer 2 switching in OpenDaylight

Handling the flows

Building the topology

Implementing VLANs and host isolation in OpenDaylight

Virtual Tenant Network (VTN)

VTN Manager

VTN coordinator

OpenDaylight VLAN LAB

Step 1 - Setting up the environment in Mininet

Step 2 - VTN configuration on OpenDaylight

Step 3 - Setting up and building our REST client

Step 4 - Using a REST API to create the virtual tenant and virtual bridges in OpenDaylight

Creating a VTN

Creating the first virtual bridge (vbr1)

Assigning VLAN 100 to virtual bridge 1 (vbr1)

Creating the second virtual bridge (vbr2)

Assigning VLAN 200 to vbr2

Step 5 - Testing

Peering with the outside world using BGP

Enabling BGP

BGP lab

Configuration of OpenDaylight

Step 1 - Changing the RIB configuration

Step 2 - Configuring VyOS

Security - user management

Link aggregation

Configuring LACP

Summary

Overview of OpenDaylight Applications

OpenDaylight applications and why we use them

Communication between modules (apps) in MD-SAL

Service producers and consumers

Declarative versus imperative

Creating MD-SAL applications

Provider implementation

Maven archetype

What is YANG?

What exactly is YANG?

How does ODL use YANG?

Our very first application, HelloWorld

Summary

Building SDN Applications for OpenDaylight

Introduction to network access control via OpenDaylight

What is NAC?

Building the NAC SDN application (web authentication method)

Which NAC software can be used to integrate with OpenDaylight?

Attaching the NAC plugin to OpenDaylight

Implementation of the OSGi component - PacketHandler

Summary

Network Function Virtualization

Virtual network functions (VNFs)

Data centers and enterprises

Service providers

OPNFV and its role in service provider NFV

How OpenDaylight and OPNFV integrate and implement NFVs in service provider networks

Service chaining using OpenDaylight

Examples of forcing traffic to go through a firewall and load balancer

Standalone mode

Example of network traffic broker and capturing

Summary

Building a Software-Driven Data Center with OpenDaylight

Software-defined data center

What happened to compute and storage?

Hyper-converged infrastructure

The limitations of current networking technologies

Can SDN solve the problem?

The integration of OpenStack into OpenDaylight

Multi-tenancy

OpenDayLight's Virtual Tenant Networks

Virtual network components

vBridge functions

vRouter functions

Flow filter functions - access control and policy-based routing

VTN coordinator

VTN installation

How ODL's ML2 plugin works

Automatic network provisioning

Network orchestration

Service providers

Open Network Automation Platform

Software-defined optical networking

Summary

Preface

OpenDaylight is an open source, software-defined network controller based on standard protocols. It aims to accelerate the adoption of software-defined networking (SDN) and create a solid foundation for network functions virtualization (NFV). SDN is a vast subject; many network engineers find it difficult to get started with using and operating different SDN platforms. This book will give you a practical bridge from legacy networking and SDN theory to the practical, real-world use of SDN in data centers and by cloud providers. The book will help you understand the features and use cases for SDN, NFV, and OpenDaylight. It also provides hands-on examples to build and use OpenDaylight in a test and lab environment on your computer. NFV uses virtualization concepts and techniques to create virtual network functions such as routers, firewalls, and load balancers using standard x86 servers. Used together, SDN and NFV can elevate the agility of your network architecture; generic hardware-saving costs and the advanced and abstracted software will give you the freedom to evolve your network in the future without having to invest more in costly equipment. By the end of this book, you will have learned how to design and deploy OpenDaylight networks. You will also have mastered basic network programming over the SDN fabric.

What this book covers

Chapter 1, Introduction to SDN - Transformation from Legacy to SDN, explains SDN basics and covers SDN controllers and the position of OpenDaylight in the SDN ecosystem. It will help transform a traditional, legacy networking mind into an SDN mindset.  It also covers a translation of how legacy network features, terms, protocols, and functions such as routing, switching, VLANs, and link aggregations are implemented in SDN.

Chapter 2, Overview of OpenDaylight,  is about the OpenDaylight project and its components, history, and versions. OpenDaylight is a complex project based on multiple components that are tightly integrated. The aim is to make you familiar with the architecture of OpenDaylight in order to have a better understanding of how OpenDaylight works and the logic behind it.

Chapter 3, OpenDaylight Installation and Deployment, provides step-by-step installation instructions for OpenDaylight in a virtual environment. You will learn how to install it from scratch and in a Docker container.

Chapter 4, Building a Virtual SDN Test Lab with Virtual Switches, helps you build a virtual lab using mininet virtual-SDN-enabled switches.

Chapter 5, Basic Networking with OpenDaylight, is dedicated to performing basic network operations using OpenDaylight and SDN. You will learn basic networking operations and managing the fabric using OpenDaylight.

Chapter 6, Overview of OpenDaylight Applications, is about OpenDaylight applications. You will learn about OpenDaylight application programming using model-driven SAL (MD-SAL) in very basic steps.

Chapter 7, Building SDN Applications for OpenDaylight, helps you build an SDN application on top of OpenDaylight. We will go through SDN-based network access control (NAC) to understand how to hook up to OpenDaylight and take control of packet flow decision process.

Chapter 8, Network Function Virtualization NFV, gets you familiar with the role of OpenDaylight in an NFV ecosystem. You will learn about network function virtualization (NFV) basics, the OPNFV framework, and existing NFV projects. You will also learn about service chaining, which is one of the main use cases of SDN and OpenDaylight.

Chapter 9, Building a Software-Driven Data Center with OpenDaylight, summarizes and uses all the learning of this book by integrating it into a responsive software-driven data center use case. You will learn how to integrate and automate networking tasks from OpenStack to OpenDaylight, as well as understanding the role of network orchestration in a service-provider network by evolving OSS and BSS.

What you need for this book

In order to keep up with the book, you will need to spend some time learning basic coding. Ensure that you have the following software installed:

 Oracle VirtualBox Or VMware workstation

 Ubuntu 16 server as base operating system for installation of OpenDaylight

Mininet virtual appliance

 OpenDaylight Beryllium-SR4

 VTN coordinator

 PacketFence module for OpenDaylight

Who this book is for

This book is for network professionals, network automation engineers, and developers who are working on software defined networking, network orchestration, and the cloud, in both service-provider and enterprise segments. This book tries to transform a legacy networking mindset to a software-defined networking one. Knowledge of networking is required.

Conventions

In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.

Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "We can include other contexts through the use of the include directive."

A block of code is set as follows:

01 <?xml version="1.0" encoding="UTF-8" standalone="no"?> 02 <flow xmlns="urn:opendaylight:flow:inventory"> 03 <flow-name>Flow1</flow-name> 04 <id>258</id> 05 <instructions>

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

01 <?xml version="1.0" encoding="UTF-8" standalone="no"?> 02 <flow xmlns="urn:opendaylight:flow:inventory">

03 <flow-name>Flow1</flow-name>

04 <id>258</id> 05 <instructions>

Any command-line input or output is written as follows:

scp $path/controller-upgrade-2013.02.13.0921.pkg [email protected]:"

New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "Clicking the Next button moves you to the next screen."

Warnings or important notes appear in a box like this.

Tips and tricks appear like this.

Reader feedback

Feedback from our readers is always welcome. Let us know what you think about this book-what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.

To send us general feedback, simply e-mail [email protected], and mention the book's title in the subject of your message.

If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.

Customer support

Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.

Downloading the example code

You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/ support and register to have the files e-mailed directly to you.

You can download the code files by following these steps:

Log in or register to our website using your e-mail address and password.

Hover the mouse pointer on the SUPPORT tab at the top.

Click on Code Downloads & Errata.

Enter the name of the book in the Search box.

Select the book for which you're looking to download the code files.

Choose from the drop-down menu where you purchased this book from.

Click on Code Download.

You can also download the code files by clicking on the Code Files button on the book's webpage at the Packt Publishing website. This page can be accessed by entering the book's name in the Search box. Please note that you need to be logged in to your Packt account.

Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:

WinRAR / 7-Zip for Windows

Zipeg / iZip / UnRarX for Mac

7-Zip / PeaZip for Linux

The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Learning-OpenDaylight. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Downloading the color images of this book

We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from https://www.packtpub.com/sites/default/files/downloads/LearningOpenDaylight_ColorImages.pdf.

Errata

Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books-maybe a mistake in the text or the code-we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.

To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.

Piracy

Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.

Please contact us at [email protected] with a link to the suspected pirated material.

We appreciate your help in protecting our authors and our ability to bring you valuable content.

Questions

If you have a problem with any aspect of this book, you can contact us at [email protected], and we will do our best to address the problem.

Introduction to SDN - Transformation from Legacy to SDN

You might have heard about Software-Defined Networking (SDN). If you are in the networking industry this is a topic that you probably have studied initially when you heard about the SDN for the first time.

To understand the importance of the SDN and SDN controller, let's look at Google. Google silently built its own networking switches and controller called Jupiter, a home grown project that is mostly software driven and supports such massive scale of Google.

Similar to all other technologies, we were in a hype for SDN for the last three years, everyone was talking about it, while it was still un-matured enough. The technology hype is a cycle for each and every new technology being introduced to the world. You can recall other hypes such as SD-WAN and IOT, where marketing and people start talking about them and industry leaders start giving ideas, publishing papers, and developing the idea while still there is not enough maturity in technology to become as a product.

The IT and computing industry is all about change. It changes its models, forms, or services from time to time. Even it goes back to a previous model where it was deprecated and ceased by a technology successor. For example, computers back in the 1970s, were all a central computing system in the form of a main frame, with multiple terminals. People were using a central system for executing their day to day computing requirements. This model slowly evolved by introducing micro and personal computers in the late 1980s and started to become a distributed computing. Mainframes started ceasing off, and were deprecated and replaced by standalone servers.

In the last five years, by explosion of the cloud, again we are going back to a central model, a model where a central cloud will perform all the computing, storage, networking, and security, without the need of any on-premises infrastructure.

Similarly, in the networking world, we are evolving to a central brain model. In the networking industry, we had standard protocols for more than 20 years. BGP, OSPF, ISIS, spanning tree, and so on are protocols and concepts that you deal with on a daily basis. These protocols were built on a very important basis, no one has a full picture of a network. However, in SDN, we are changing the basis. The SDN base is There is a controller who knows the whole network.

OpenDaylight (ODL) is an SDN controller. In other words, it's the central brain of the network.

Going back to SDN and this book, we will go for a practical experience with SDN and we will learn:

What is and what is not SDN

Difference between SDN and overlay

The SDN controllers

BUM (broadcast, unknown, and multicast)

OpenDaylight as an SDN controller

Understanding the flows, tables, and flow mappings

Traditional networking terms and features in the SDN world.

Why are we going towards SDN?

Everyone who is hearing about SDN should ask the question why we are talking about SDN? What problem is it trying to solve?

If we look at traditional networking (layer 2 and layer 3 with routing protocols such as BGP and OSPF), we are completely dominated by what is called protocols.

These protocols in fact have been very helpful to the industry. They are mostly standard. Different vendors and products can communicate using standard protocols with each other. A Cisco router can establish a BGP session with a Huawei switch or an open source Quagga router can exchange OSPF routes with a Juniper firewall.

The routing protocol is a constant standard with solid bases. If you need to override something in your network routing, you have to find a trick to use protocols, even by using a static route.

Further more the legacy networking and switching gears are based on a tied control plane and forwarding plane on a single box. Each switch or router runs a control software (AKA firmware or operating system) which includes components such as spanning tree, BGP, OSPF, link aggregation, LLD, and so on. Each device uses these protocols to build a network from its own perspective.

This tide integration between software and hardware, or control and data plane limits the scalability of the network because of a lack of having a single, know all, network brain.

This integration also has a cost impact as each vendor will charge extra for a software running on their switches.

One of the main objectives of SDN is to dis-aggregate the control and data plane. That means to have a single control plane software (the SDN controller) and multiple bare metal SDN-enabled data plane gears (such as pure OpenFlow switches).

SDN can help us to come out of the routing protocol cage, look at different ways to forward traffic. SDN can directly program each switch or even override a route that is installed by routing protocols.

There are high-level benefits of using SDN, a few of which we have explained in the following list:

An integrated network

: We used to have a standalone concept in traditional networks. Each switch was managed separately; each switch was running its own routing protocol instance and was processing routing information messages from other neighbors. In SDN, we are migrating to a centralized model, where the SDN controller becomes the single point of configuration of the network, where you will apply the policies and configuration.

Scalable layer 2 across layer 3

: Having a layer 2 network across multiple layer 3 networks is something that all network architects are interested in and until now we have been using proprietary methods such as OTV or by using a service provider VPLS service. With SDN, we can create layer 2 networks across multiple switches or layer 3 domains (using VXLAN) and expand the layer 2 networks. In many cloud environments, where the virtual machines are distributed across different hosts in different data centers, this is a major requirement.

Third-party application programmability

: This is a very generic term, isn't it? But what I'm referring to is to let other applications communicate with your network. For example, in many new distributed IP storage systems, the IP storage controller has the ability to talk to networks to provide the best, shortest path to the storage node. With SDN we are letting other applications control the network. Of course this control has limitations and SDN doesn't allow an application to scrap the whole network.

Flexible application based network

: In SDN, everything is an application. L2/L3, BGP, VMware Integration, and so on all are applications running in the SDN controller.

Service chaining

: On the fly you add a firewall in the path or a load balancer. This is

service insertion

.

Unified wired and wireless

: This is an ideal benefit, to have a controller that supports both wired and wireless network. OpenDaylight is the only controller that supports CAPWAP protocols that allows integration with wireless access points.

Components of an SDN

A software-defined network infrastructure has two main key components:

The SDN controller (only one, could be deployed in a highly available cluster)

The SDN-enabled switches (multiple switches, mostly in a Clos topology in a data center) as shown in the following figure:

An SDN controller is the single brain of the SDN domain. In fact, an SDN domain is very similar to a chassis-based switch. You can imagine the supervisor or management module of a chassis-based switch as an SDN controller and the rest of the line card and I/O cards as SDN switches. The main difference between an SDN network and a chassis-based switch is that you can scale out the SDN with multiple switches, where in a chassis-based switch you are limited to the number of slots in that chassis:

Controlling the fabric

It is very important that you understand the main technologies involved in SDN. These methods are used by SDN controllers to manage and control the SDN network.

In general, there are two methods available for controlling the fabric:

Direct fabric programming

: In this method, the SDN controller directly communicates with SDN-enabled switches via southbound protocols such as OpenFlow, NETCONF, and OVSDB. The SDN controller programs each switch member with related information about fabric, and how to forward the traffic. Direct fabric programming is the method used by OpenDaylight.

Overlay

: In the overlay method, the SDN controller doesn't rely on programming the network switches and routers. Instead it builds a virtual overlay network on top of the existing underlay network. The underlay network can be an L2 or L3 network with traditional network switches and router, just providing IP connectivity. The SDN controller uses this platform to build the overlay using encapsulation protocols such as VXLAN and NVGRE. VMware NSX uses overlay technology to build and control the virtual fabric.

Difference between direct fabric programming and overlay

Let's look at how the standard switch or router performs a frame forwarding. For our understanding we will look at a generic layer 3 switch (1G or 10G) from any vendor:

An Ethernet switch is a very simple device, it's just a silicon chipset, which is from one of the large silicon manufacturers such as Broadcom or Marvel, a CPU (which is either a x86 or a low power ARM-based processor), which runs the vendor's software (vendor here is referring to switch vendor such as Cisco or Juniper or Arista, and so on.):

The switch silicon is like a comparison table. It maps the frames to ports. When a switch receives a packet, it looks into its content-addressable memory (CAM) table to find out what needs to be done to this frame received on port X. The CAM table, which is already programmed and filled by the switch software, will have an entry to tell the switch silicon what needs to be done on that frame. For example, send it out of port Y and change the destination MAC to switch burned in MAC. Or any other decision such as sending it to the switch CPU for processing (if it's a routing protocol packet, for example an OSPF LSA).

So in simple terms, in standard switches the CAM table of a switch is filled by entries that are programmed and controlled by switch CPU or switch software.

In SDN, we have a slightly different scenario, you can imagine that the SDN controller will control the CAM table of all switches. The terms are changed slightly and it is called a flow table. A flow table is nothing but the same CAM entries in the switch, but it's called a flow table and each entry is called a flow entry.

SDN controller programs each switch CAM table via a protocol that is called southbound protocol. There are multiple southbound protocols where the most famous and standard one is OpenFlow; however, the others such as NETCONF and OVSDB also exist in standard protocol groups. Cisco's OpFlex (https://tools.ietf.org/html/draft-smith-opflex-03) is also an open source protocol which is a southbound protocol between Cisco APIC controller and Cisco Nexus switches. OpFlex is also supported on OpenDaylight.

OpenFlow is a protocol that allows SDN controller to program each switch in the SDN network. Please remember that the OpenFlow is a piece of software, it's a protocol. The OpenFlow agent runs on each switch and starts communicating with the OpenFlow server piece on SDN controller.

You may have heard about overlays. Especially if you have heard about the SD-WAN, which is completely based on overlay networking. An overlay is a network built on top of an underlay network. Seems complex? Let me provide a more familiar example. An SSL VPN tunnel is an overlay on top of a IP network. In SSL VPN, the underlay is IP, and an overlay is an SSL.

The real packets are encapsulated as new payload inside the SSL packets. You can make more examples of overlays, GRE, IPSEC, and also the new overlays such as VXLAN and NVGRE:

Overlays are also considered as part of the SDN family. Yes, they are software defined. They are created and managed by software. Overlays are not dependent on the underlay IP network; therefore deploying an overlay network is much easier than deploying a full SDN with SDN controller and switches. In data center overlay networks there are two main protocols used for encapsulation: VXLAN and NVGRE.

VXLAN is a UDP packet, which encapsulates the whole IP packet as a UDP payload and sends over the other end. VXLAN endpoints are called Virtual Tunnel End Points (VTEP). VTEPs create virtual tunnels between each other and transmit the UDP packets that are all having the packets encapsulated inside the UDP payload.

VXLAN uses an identification number for networks called virtual network ID (VNID), which identifies which packet belongs to which virtual network.

VXLAN is very common between most of the vendors and are very well supported.

Network Virtualization using GRE (NVGRE) is another protocol similar to VXLAN, but it is not very popular. Microsoft is one of the promoters of NVGRE on their SONIC switch operating system.

The most important overlay solution on the market is VMware NSX.

Now we have learned very briefly about SDN and overlays, let's have a comparison between these two technologies:

Direct fabric programming

Overlay

Can work in co-existance with existing underlay IP network

Yes or No depending on switch type.

Yes

Requires to use an encapsulation protocol such as VXLAN, NVGRE

No

Yes

Scalable

Yes

Yes

In summary, SDN and overlays are somehow completing each other, but they are different. Some people don't consider overlays as SDN, and some do.

OpenDaylight is an SDN controller, it is not an overlay.

Futuristic view on networking and SDN

The future of SDN might be a generic platform on which the network application would be written and create a new industry of network application service. We may expect different network applications to be released, which all tend to add intelligence to the network and get integrated with other applications and software. Many services are changing to some kind of anycast that requires an intelligent network to decide which client's request must be directed to which server. Some of these services are available now, for example the new NAS servers with anycast support integration with OpenFlow to the SDN network (products from Coho Data).

Similar to a computer operating system that delivers computing resources to an application, an SDN network operating system might be able to deliver packets to the application. The application decides how they would like to use the services.