Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A Networking View for the DevOps Crew: SDN

3,336 views

Published on

The slides presented at the Triangle DevOps meeting 2014-Feb-19

Published in: Technology
  • Be the first to comment

A Networking View for the DevOps Crew: SDN

  1. 1. NETWORKING VIEW FOR THE DEVOPS CREW A SOFTWARE DEFINED NETWORKING Jeremy Schulman 2014 FEBRUARY @nwkautomaniac nwkautomaniac@gmail.com
  2. 2. 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
  3. 3. 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.
  4. 4. SDN TOPICS  Why all the fuss?  A bit of history  Just enough networking (no TLAs!)  Where's Waldo (=Software)  Mind the (Reality) Gap
  5. 5. ECONOMICS AND INNOVATION CHOICE and CONTROL
  6. 6. HISTORY Two separate, unrelated, but timely events Google ~~~ OpenFlow
  7. 7. MARKET SEGMENTATION Networking vendor perspective MSDC SERVICE PROVIDER "LARGE" ENTERPRISE ENTERPRISE
  8. 8. QUICK REVIEW SERVERS Copyright © 2013 Juniper Networks, Inc.
  9. 9. 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
  10. 10. 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
  11. 11. JUST ENOUGH NETWORKING Copyright © 2013 Juniper Networks, Inc.
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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!
  17. 17. 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
  18. 18. 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
  19. 19. WHAT IS SDN? ... Copyright © 2013 Juniper Networks, Inc.
  20. 20. 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 ....
  21. 21. 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
  22. 22. 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)
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. Q&A Copyright © 2013 Juniper Networks, Inc.
  27. 27. THANK YOU Copyright © 2013 Juniper Networks, Inc. www.juniper.net

×