A Networking View for the DevOps Crew: SDN

NETWORKING VIEW
FOR THE DEVOPS CREW
A

SOFTWARE
DEFINED
NETWORKING
Jeremy Schulman
2014 FEBRUARY
@nwkautomaniac
nwkautomaniac@gmail.com

ABOUT JEREMY
20 Years in Networking
my.com
(7)

SW Eng

Sales Eng

(12)

Junos "EZ"
Ruby, Python

Puppet, Chef,
Ansible, Salt

IT
Automation

(8)

(2)

Strategic
Alliances
(3)

Bizdev
Open Source
nwkautomaniac@gmail.com

(5)

Juniper Networks
jschulman@juniper.net

DISCLAIMER

This is a community presentation. Views
expressed in this post are the original thoughts
posted by Jeremy Schulman, Director of
Automation Concept Engineering at Juniper
Networks.
These views are his own, and in no way
represent the views of the company he works for.

SDN TOPICS
 Why all the fuss?
 A bit of history
 Just enough networking (no TLAs!)

 Where's Waldo (=Software)
 Mind the (Reality) Gap

ECONOMICS AND INNOVATION

CHOICE
and

CONTROL

HISTORY
Two separate, unrelated, but timely events

Google
~~~

OpenFlow

MARKET SEGMENTATION
Networking vendor perspective

MSDC

SERVICE
PROVIDER

"LARGE"
ENTERPRISE

ENTERPRISE

QUICK REVIEW
SERVERS

Copyright © 2013 Juniper Networks, Inc.

SERVER HARDWARE
ARCHITECTURE BLOCKS
Choice and Control is largely determined by the end-customer

EXTERNAL

S/W

CPU

MEMORY

INTERNAL

NETWORK

PHYSICAL

STORAGE

INTERFACES

ENCLOSURE

STORAGE

SERVER SOFTWARE
ARCHITECTURE BLOCKS
Software running in the CPU determines the purpose of the server/VM
Choice and Control are determined by the end-customer (Linux example)
S/W

CPU

App

App

App

Middleware

Middleware

Middleware

Operating
System

JUST ENOUGH
NETWORKING


NETWORK HARDWARE
ARCHITECTURE BLOCKS
Choice and Control is largely determined by the manufacturer (vendor)

Leads to "appliance" based approaches for specific networking functions

S/W

CPU

MEMORY

S/W

INTERNAL

ASIC

STORAGE

FPGA, NPU

NETWORK

S/W

INTERFACES

PHYSICAL
ENCLOSURE

NETWORK SOFTWARE
ARCHITECTURE BLOCKS
Networking "software" is designated into "planes" of execution that is
distributed across the CPU, ASICs, FPGAs, NPUs, etc.
Leads to highly integrated (tested) vertical stacks of software
Choice and Control determined by manufacturer
S/W

Management

Services

Plane

Plane

Control
Plane

Forwarding
Plane

NETWORK SOFTWARE
FORWARDING PLANE





Packet processing "engines"
Typically done in hardware
Specific functions - switching, routing, load-balancing
Generally at wire-speed
S/W

Forwarding

packet in

packet(s) out

Plane

db

db

db

packet lookup "databases" for specific
functions, such as L2, L3, L4-L7

NETWORK SOFTWARE
MANAGEMENT PLANE
S/W runs on CPU / Operating System
Central point for all operations such as configuration and troubleshooting
Interfaces with external systems via CLI, SNMP, programming APIs
APIs
CLI

Management
Plane

SNMP
SYSLOG

S/W

Significant interest in the context of "SDN" around network automation using
vendor APIs (REST, XML, JSON, etc.)
Interest in adapting existing DevOps tools for networking: Puppet, Chef, etc.

DevOps use-cases are still different from Networking

DevOps FOR NetOps?
DevOps Evolution / Revolution
• Server Virtualization and Cloud
• History over +7 years
• Open-Source Community
physical,
virtual, cloud
orchestration

manually
configured

ad-hoc bash
perl scripting

puppet, chef
salt, ansible,
other IT
frameworks

infra.apps
built on IT
frameworks

DevOps
paradigm pivot-point!

NETWORK SOFTWARE
CONTROL PLANE
S/W runs on CPU, often in the FORWARDING PLANE as well
Responsible for Network Protocols: Spanning Tree, OSPF, BGP, MPLS, etc
A means for networking devices to converge on L2 and L3 infrastructure
services (basic switching and routing, e.g.)

Plane
Forwarding
Plane

Control

Plane
Forwarding
Plane

Router-C
Management
Plane

Control

Router-B
Management
Plane

Management
Plane

Router-A

Control

Plane
Forwarding
Plane

"The Network"

Each CONTROL PLANE protocol maintains its own separate "database"
of configuration and operational (ephemeral) state

NETWORK SOFTWARE
SERVICE PLANE
S/W runs on CPU and FORWARDING PLANE
A Service is generally a unit of function that provides a capability with a
agreed measure of success / failure. Typically multiple end-points.
• Layer-2 Virtual Private Network ... Metro Ethernet Service
• Layer-3 Virtual Private Network ... Wide Area Networking
• IPSec (secured) Private Networks
• Multi-Tenant Datacenter / Cloud Virtual Networks
• "Underlay" for "Overlay"

Services are delivered when the
CONTROL PLANE protocols provide
the necessary and sufficient
infrastructure; e.g. routing reachability

WHAT IS
SDN? ...


SDN IS TO NETWORKING
AS CLOUD IS TO SERVERS ....
Depends who you ask and their point of reference ...

But there are emerging "patterns" around CHOICE and CONTROL ....

CENTRALIZED CONTROLLERS AND
OpenFlow
Separation of Control Plane,
Forwarding Plane, and Services Plane
The "Controller" instructs each of the
network device endpoints using the
OpenFlow protocol. The Northbound
"Well-defined Open API" is used by
the SERVICES PLANE, i.e. enable
3rd-parties to create their own network
services

OpenFlow is a CONTROL PLANE
protocol that instructs the
FORWARDING PLANE packet
processing engine

OVERLAY AND UNDERLAY
 Overlay is a Virtual Networking construct
and managed separately from the physical
infrastructure ("underlay")

Contrail (Juniper Networks)

 Hypervisor based software to perform
packet "tunneling" [encap/decap]
 Centralized "Controller" to orchestrate
tunnels

 Northbound APIs into other IT systems like
OpenStack, Cloudstack, etc.

NSX (VMware)

Nuage Networks (ALU)

WHITE-BOX NETWORKING
AND LINUX AS A NETWORK OS
•

Buy hardware direct from Original Direct Manufacturer (ODM) rather than
traditional networking vendor (Cisco, Juniper, HP, etc.) - promoted as a
significant Capital Expense (CapEx) saving + Choice and Control of hardware

•

Obtain a Linux distribution that works for that hardware, e.g. Cumulus Linux.
Generally a yearly license fee - promoted as a "open" platform to enable endcustomer Choice and Control of software

•

End-customer is responsible for selecting, integrating, validating, and deploying
"software stack" specific to their business needs

•

No "one throat to choke" for support - think Linux pre-Red Hat

•

Configuration Management tends to be a good fit for DevOps tools like Puppet,
Chef, Ansible, Salt

•

Network Operational Management not necessarily a good fit; troubleshooting
complex CONTROL PLANE and SERVICE PLANE interactions not well
understood or proven

NETWORK FUNCTIONS
VIRTUALIZATION (NFV)
•

Originated out of the Service Provider market
as a means to deliver Services utilizing
standard virtualization technologies, as
opposed to vendor specific appliances

•

Complimentary to the aspirations of SDN. The
originators identified NFV as independent and
orthogonal to SDN developments.

•

Open Daylight (ODL) is a industry
wide, multi-vendor, open-source project
to create a framework and platform for
NFV solutions

RESOURCES
 Software Defined Networking (Wiki)
http://en.wikipedia.org/wiki/Software-defined_networking

 SDN Central
http://www.sdncentral.com/

 Open Networking Foundation
https://www.opennetworking.org

 Open Daylight
http://www.opendaylight.org/

 Network Functions Virtualization (Wiki)
http://en.wikipedia.org/wiki/Network_Functions_Virtualization

Q&A


THANK YOU


www.juniper.net

A Networking View for the DevOps Crew: SDN

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to A Networking View for the DevOps Crew: SDN (20)

Recently uploaded (20)

A Networking View for the DevOps Crew: SDN

Editor's Notes