FOR THE DEVOPS CREW
20 Years in Networking
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
These views are his own, and in no way
represent the views of the company he works for.
Why all the fuss?
A bit of history
Just enough networking (no TLAs!)
Where's Waldo (=Software)
Mind the (Reality) Gap
Choice and Control is largely determined by the end-customer
Software running in the CPU determines the purpose of the server/VM
Choice and Control are determined by the end-customer (Linux example)
Choice and Control is largely determined by the manufacturer (vendor)
Leads to "appliance" based approaches for specific networking functions
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
Packet processing "engines"
Typically done in hardware
Specific functions - switching, routing, load-balancing
Generally at wire-speed
packet lookup "databases" for specific
functions, such as L2, L3, L4-L7
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
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
built on IT
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.)
Each CONTROL PLANE protocol maintains its own separate "database"
of configuration and operational (ephemeral) state
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
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
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
OpenFlow is a CONTROL PLANE
protocol that instructs the
FORWARDING PLANE packet
OVERLAY AND UNDERLAY
Overlay is a Virtual Networking construct
and managed separately from the physical
Contrail (Juniper Networks)
Hypervisor based software to perform
packet "tunneling" [encap/decap]
Centralized "Controller" to orchestrate
Northbound APIs into other IT systems like
OpenStack, Cloudstack, etc.
Nuage Networks (ALU)
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
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
Software Defined Networking (Wiki)
Open Networking Foundation
Network Functions Virtualization (Wiki)
MSDC = Mega-scale datacenter .... small number of significantly large customersGeneral focus is on datacenter applicationsLarge enterprise = global/WAN/distributed; could be Universities, global corps, GVT.general enterprise > Fortune 5000, not terribly significant to the discussion.
generally speaking, commodity hardware.some specialized hardware like blade serversIBM mainframes still exist
Apple vs. Linux vs. Windows ...
yellow denotes very significant vendor investment/intellectual property
"S/W" - could be microcode in NPU, FPGA, ASIC, or similar devices. Not traditional software like running in CPU.
"DevOps" is considered by some as the "evolution/revolution" of server admin.Networking has not reached our "Pivot Point". SDN, NFV, etc. is talked about as being this Pivot. We haven't made it thru the other side yet.Hubot: http://hubot.github.com/Boxen: http://boxen.github.com/
akin to basic infrastructure for servers.
akin to basic infrastructure for servers.
"Any hardware that supportsOpenFlow""Any controller that supports OpenFlow"Open Source Projects include OpenDayLightsource for graphics: www.sdncentral.com
Parece que tem um bloqueador de anúncios ativo. Ao listar o SlideShare no seu bloqueador de anúncios, está a apoiar a nossa comunidade de criadores de conteúdo.
Atualizámos a nossa política de privacidade.
Atualizámos a nossa política de privacidade de modo a estarmos em conformidade com os regulamentos de privacidade em constante mutação a nível mundial e para lhe fornecer uma visão sobre as formas limitadas de utilização dos seus dados.
Pode ler os detalhes abaixo. Ao aceitar, está a concordar com a política de privacidade atualizada.