A Networking View for the DevOps Crew: SDN

”“

A NETWORKING VIEW FOR THE DEVOPS CREW

Jeremy Schulman

2014 FEBRUARY@nwkautomaniacnwkautomaniac@gmail.com

SOFTWARE DEFINED NETWORKING

ABOUT JEREMY20 Years in Networking

SW Eng(12)

Sales Eng(8)

Bizdev(5)

my.com(7)

Strategic Alliances

(3)

Puppet, Chef, Ansible, Salt

Junos "EZ"Ruby, Python

IT Automation

(2)

Open Sourcenwkautomaniac@gmail.com

Juniper Networksjschulman@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

CHOICEand

CONTROL

HISTORYTwo separate, unrelated, but timely events

Google~~~

OpenFlow

MARKET SEGMENTATIONNetworking vendor perspective

SERVICEPROVIDER

ENTERPRISE

MSDC

"LARGE"ENTERPRISE

Copyright © 2013 Juniper Networks, Inc.

QUICK REVIEW SERVERS

SERVER HARDWARE ARCHITECTURE BLOCKS

CPU MEMORY

INTERNAL

STORAGE

EXTERNAL

STORAGE

NETWORK

INTERFACES

PHYSICAL

ENCLOSURE

S/W

Choice and Control is largely determined by the end-customer

SERVER SOFTWARE ARCHITECTURE BLOCKS

CPU

Operating

System

Middleware Middleware Middleware

App AppApp

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

Copyright © 2013 Juniper Networks, Inc.

JUST ENOUGHNETWORKING

S/W

NETWORK HARDWARE ARCHITECTURE BLOCKS

CPU MEMORY

INTERNAL

STORAGE

PHYSICAL

ENCLOSURE

ASIC

FPGA, NPU

S/W

S/W

Choice and Control is largely determined by the manufacturer (vendor)

Leads to "appliance" based approaches for specific networking functions

NETWORK

INTERFACES

NETWORK SOFTWARE ARCHITECTURE BLOCKS

Forwarding

Plane

Management

Plane

Services

Plane

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

Control

Plane

S/W

NETWORK SOFTWARE FORWARDING PLANE

Forwarding

Plane

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

packet in

db db db

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

packet(s) out

S/W

NETWORK SOFTWARE MANAGEMENT PLANE

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

CLI SNMP

SYSLOG

APIs

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

S/W

DevOps FOR NetOps?

DevOps Evolution / Revolution • Server Virtualization and Cloud

• History over +7 years

• Open-Source Community

manuallyconfigured

ad-hoc bashperl scripting

puppet, chefsalt, ansible,other IT frameworks

infra.appsbuilt on ITframeworks

physical,virtual, cloudorchestration

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.)

Control

Plane

ForwardingPlane

Ma

na

ge

me

nt

Pla

ne

Control

Plane

ForwardingPlane

Ma

na

ge

me

nt

Pla

ne

Control

Plane

ForwardingPlane

Ma

na

ge

me

nt

Pla

ne

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

"The Network"

Router-A Router-B Router-C

NETWORK SOFTWARE SERVICE PLANES/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

Copyright © 2013 Juniper Networks, Inc.

WHAT ISSDN? ...

SDN IS TO NETWORKINGAS 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

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

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

Separation of Control Plane, Forwarding Plane, and Services Plane

OVERLAY AND UNDERLAY

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

Hypervisor based software to perform packet "tunneling" [encap/decap]

Centralized "Controller" to orchestrate tunnels

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

Contrail (Juniper Networks)

Nuage Networks (ALU)NSX (VMware)

WHITE-BOX NETWORKINGAND 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 end-customer 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 Foundationhttps://www.opennetworking.org

Open Daylighthttp://www.opendaylight.org/

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

Copyright © 2013 Juniper Networks, Inc.

Q & A

Copyright © 2013 Juniper Networks, Inc. www.juniper.net

THANK YOU