Jason Edelman - Network Programmability and Automation: Skills for the Next-Generation Network Engineer

by Jason Edelman , Scott S. Lowe , and Matt Oswalt

Copyright 2015 Jason Edelman, Scott Lowe, Matt Oswalt. All rights reserved.

Printed in the United States of America.

Published by OReilly Media, Inc. , 1005 Gravenstein Highway North, Sebastopol, CA 95472.

OReilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles ( http://safaribooksonline.com ). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com .

• Editors: Mike Loukides and Brian Anderson
• Production Editor: FILL IN PRODUCTION EDITOR
• Copyeditor: FILL IN COPYEDITOR
• Proofreader: FILL IN PROOFREADER
• Indexer: FILL IN INDEXER
• Interior Designer: David Futato
• Cover Designer: Karen Montgomery
• Illustrator: Rebecca Demarest

• January -4712: First Edition

See http://oreilly.com/catalog/errata.csp?isbn=9781491931219 for release details.

The OReilly logo is a registered trademark of OReilly Media, Inc. {{ TITLE }}, the cover image, and related trade dress are trademarks of OReilly Media, Inc.

While the publisher and the author(s) have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author(s) disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.

978-1-491-93121-9

[FILL IN]

Are you new to Software Defined Networking (SDN)? Have you been hung up in the SDN crazy for the past several years? Whichever bucket you fall into, do not worry. Even though this book is centered around network automation and programmability, this chapter is going to highlight and provide an introduction on several of the major trends throughout the network industry that often end up in conversations on the topic of SDN. Well get started by reviewing how Software Defined Networking made it into the main stream.

The Rise of Software Defined Networking

If there was one person that could be credited with all the change that is occurring in the network industry, it would be Martin Casado, who is currently a VMware Fellow, Senior Vice President, and General Manager in the Networking and Security Business Unit at VMware. He has had a profound impact on the industry, not just from his direct contributions including OpenFlow and Nicira, but by opening the eyes of large network incumbents and showing that network operations, agility, and manageability must change. Lets take a look at this in a little more detail.

OpenFlow

What is it?

For better or for worse, OpenFlow has served as the Hello World of the Software Defined Networking (SDN) movement. OpenFlow is the protocol that Martin Casado worked on while he was achieving his PhD at Stanford University under the supervision of Nick McKeown. It is simply a protocol that allows for the de-coupling of a network devices control plane from the data plane. In simplest terms, the control plane can be thought of as the brains of a network device and the data plane can be thought of as the hardware or ASICS that actually perform packet forwarding.

Figure 1-1. De-coupling the Control Plane and Data Plane with OpenFlow

Running OpenFlow in Hybrid Mode

The figure above depicts the network elements having no control plane. This represents a pure OpenFlow-only deployment. Many devices also support OpenFlow hybrid mode meaning OpenFlow can be deployed on a given port, VLAN, or even within a normal packet forwarding pipeline such that if there is not a match in the OpenFlow Table, then use the existing forwarding tables (MAC, Routing, etc.) making it more analogous to Policy Based Routing (PBR).

History of Programmable Networks

OpenFlow was not the first protocol or technology used to de-couple control functions and intelligence from network devices. There is a long history of technology and research that predates OpenFlow, although OpenFlow is the technology that started the SDN revolution. A few of the technologies that predated OpenFlow includes ForCes (Forwarding and Control Element Separation), Active Networks, Routing Control Platform (RCP), and Path Computation Element (PCE). For a more in depth look at this history, take a look at a paper titled The Road to SDN: An Intellectual History of Programmable Networksby Jen Rexford, Nick Feamster, and Ellen Zegura.

What this means is OpenFlow is a low-level protocol that is used to directly interface with the hardware tables (example: Forwarding Information Base, or FIB) that exist on networking devices instructing the device how to forward traffic, e.g. traffic to destination 1 should egress port 48.

Because the tables OpenFlow uses support more than destination address as compared to traditional routing protocols, there is more granularity (matching fields in the packet) to determine the forwarding path, so the actual outcome is analogous Policy Based Routing (PBR) in hardware. Policy Based Routing is also a good example to use that shows what OpenFlows true value strives to be --- it is that to create an abstraction layer for the diverse set of hardware that exists in that new features can be rolled out that would be optimized in hardware independent of having purpose-built ASCIS. As we know, the industry waited for years to get PBR in hardware as well as other features such as GRE in hardware. With OpenFlow abstracting out the underlying hardware, it becomes possible to enhance the capabilities of the network infrastructure without waiting for the next version of hardware from the manufacturer.

Note

Policy Based Routing has been around for years and allowed network administrators to create route policies based on source/destination address, protocol, etc., but until recent years, the caveat was all policy based network traffic ended up being software switched hitting the CPU, not to mention what it does to the complexity of the network. Leveraging OpenFlow simplifies this.

Note

OpenFlow is a low level protocol manipulating flow tables directly impacting packet forwarding. OpenFlow was not built to be a management plane protocol to configure general parameters on devices such as passwords, SNMP, AAA, etc. although there are some rumblings of a new spec called OF-config that may take some of this into consideration

Why OpenFlow?

While its important to understand what OpenFlow is, its even more important to understand the reasoning behind the research and development effort of the original OpenFlow spec that led to the rise of Software Defined Networking.