35
Software Defined Networking It’s Not Just a Buzz Word Presentation at San Francisco Juniper Meetup August 25 2015 By Chris Jones @ SDN Essentials

Sdn not just a buzzword

Embed Size (px)

Citation preview

Page 1: Sdn not just a buzzword

Software Defined Networking

It’s Not Just a Buzz Word

Presentation at San Francisco Juniper Meetup August 25 2015By Chris Jones @ SDN Essentials

Page 2: Sdn not just a buzzword

2Who the heck is THIS guy?

Chris JonesSDN Engineer, SDN EssentialsJuniper AmbassadorJuniper Ingenious [email protected]: @IPv6Freely

CertificationsJNCIE-ENT #272CCIE #25655 (R&S)JNCIP-SPJNCIS-SECJNCIS-QF

PublicationsDay One: Junos for IOS EngineersDay One: Ambassadors’ Cookbook For EnterpriseJNCIE-ENT Preparation Workbook

Okay, moving on...

Page 3: Sdn not just a buzzword

3Agenda

• The OTHER buzz word in our industry• Some SDN definitions• OpenFlow, Overlays, and APIs… Oh my!• Network today is wonderful… or is it?• Open your mind to the possibilities• That blank box at the top of the block diagrams• Let’s discuss!

Page 4: Sdn not just a buzzword

4Let’s talk about cloud computingNo, seriously.

Page 5: Sdn not just a buzzword

5We’ve all seen these…

Page 6: Sdn not just a buzzword

6… but we also know this isn’t the whole story• Not just a server sitting in a datacenter somewhere• Cloud implies pools of resources: storage, networking, and compute• Multi-tenancy is an important aspect• The entire point is that we just don’t care about the physical aspect

Page 7: Sdn not just a buzzword

7Okay, how is this relevant?I’m getting to it!

Page 8: Sdn not just a buzzword

8The classic definition of SDN

The physical separation of the networkcontrol

planefrom the forwarding plane , and where a control plane controls several devices.

Page 9: Sdn not just a buzzword

9Is this definition…

Vague?Morphed or Skewed?Entirely meaningless?

Let’s clarify!

Page 10: Sdn not just a buzzword

10To be clear:

SDN is not a technology.Like cloud

computing, SDN is a concept!However…

Page 11: Sdn not just a buzzword

11The definition has been skewed by vendors• Everyone seems to have their “SDN strategy”• It doesn’t seem to matter how close to the original

definition it may be• It’s become confusing

• What is SDN? • What isn’t SDN?• Are protocols used in an SDN solution now considered SDN?

• Vendors aren’t helping this• We’re now classifying SDN in one of three flavors

Page 12: Sdn not just a buzzword

12Open SDN

• The flavor of SDN that most closely resembles the original vision• Complete separation of control and forwarding• Utilizes some sort of central SDN controller• Simplified forwarding elements• Northbound interface for programmability• Southbound interface protocol usually

OpenFlow• Commercial: Brocade, BigSwitch, NEC, HP• Open Source: OpenDaylight, Ryu, NOX, Trema

OpenFlow

REST API

Network Element

Forwarding

SDN ControllerControl

Management

Page 13: Sdn not just a buzzword

13SDN With Overlays

• Still separates control from forwarding• Typically implemented in the hypervisor• Creates tunnels between hypervisors and/or physical

network devices• VXLAN• GRE• NVGRE• EVPN

• Enables multi-tenant Data Centers• Does not address the underlay• Northbound interface for programmability• Southbound interface protocol varies by vendor• Juniper Contrail, VMware NSX, Plumgrid, Nuage

HypervisorNetwork Plug-in

A1 B1

HypervisorNetwork Plug-in

A2 B2

Page 14: Sdn not just a buzzword

14SDN via API

• Adds an API layer for programmability to existing network elements• Control plane remains distributed• Not... really... SDN, but vendors who use it call

it SDN so we have to talk about it• Enables central network policy management• Southbound interface: OpFlex• Stopgap for investment protection• Cisco

TraditionalNetwork Element

ForwardingControl

Management

ManagementAPI

OpFlex

Page 15: Sdn not just a buzzword

15Okay, so...

Hopefully that helps to clarify what SDN is.

Page 16: Sdn not just a buzzword

16So, why do we need SDN?Good Question!

Page 17: Sdn not just a buzzword

17

In this business we shouldn’t forget what the purpose of the network is: to serve the needs of the application. And the network stopped doing that a while ago.

Art Fewell, Network World

Page 18: Sdn not just a buzzword

18A bit more detail, please!

• Traditional networking has some issues:• High operational costs• Difficult to manage• Network scalability has always been a problem• Unable to adapt to changing traffic patterns and flows• Decentralized• Monolithic software

• Over-provisioning to aim for worst case scenario• L2/L3 load balancing far from perfect• Non-best path forwarding requires some kind of static

configuration

Page 19: Sdn not just a buzzword

19Alright, so we have issues. How can SDN help?

SDN enables a new way of looking at networks. Here, I’ll show you!

Page 20: Sdn not just a buzzword

20It Starts in the Data Center

• The data center is the natural starting point for software defined networking• Overlays solve an immediate need

• Tunnels using VXLAN or EVPN provide DCI options• Routing instances on tunnel endpoints (VTEPs) enable multi-tenancy

• SDN complements existing orchestration platforms• An increased focus on east/west traffic for applications

• Large firewalls hair-pinning traffic north/south is inefficient• Micro-services are becoming more prevalent

• Programmability and automation are key in today’s data centers• The network must be reactive to application needs

Page 21: Sdn not just a buzzword

21But what about the underlay?

• The underlay is irrelevant to the overlay• However, care must be taken to ensure the underlay does not

become the bottleneck• L2 networks do not scale well enough• CLOS IP fabrics allow L3 equal-cost load balancing

• The underlay may be a good place for OpenFlow• Some vendors handle both the overlay and underlay, and

correlate the two

Page 22: Sdn not just a buzzword

22The WAN is a good place for SDN, too.

• Traffic engineering is largely proactive and requires manual configuration• With SDN, reactive TE path computation based on network flows

is possible• Path failure recovery can be signaled from a central SDN

application and the controller• The central TE server has a full network view and can program paths directly

• Eliminates over-provisioning• Google is already doing this

Page 23: Sdn not just a buzzword

23A Brief Overview of OpenFlowBut by no means comprehensive!

Page 24: Sdn not just a buzzword

24OpenFlow (Over)simplified

• If we started over…• OpenFlow is the southbound interface protocol between

SDN controllers and forwarding elements• Enables programmability of the forwarding plane• Forwarding elements (switches) can run in one of two

modes:• OpenFlow-only mode means that the switch uses OpenFlow for all

forwarding decisions• Hybrid mode means the switch uses OpenFlow on some interfaces

and traditional switching on othersSDN Controller Forwarding ElementOpenFlow

Page 25: Sdn not just a buzzword

25Flow Matching

• OpenFlow versions before 1.2 used simple match fields• Versions 1.2+ use TLVs. Not backwards compatible

IngressPort

MACSrc

MACDst

EthType

VLANId

VLANPrior

IPSrc

IPDst

IPProt

IPToS

TCP/UDPsport

TCP/UDPdport

• Match: perform associated action/instruction• No match: drop or forward to controller

Page 26: Sdn not just a buzzword

26Flow Tables

• Prioritized list of Flow Entries• Evaluated in order, execute first match found• Each flow has a timeout (‘idle’ and ‘hard’)

Priority Match Fields Actions Stats Timer

sPriority Match Fields Actions Stats Timer

sPriority Match Fields Actions Stats Timer

sPriorit

y Match Fields Actions Stats Timers

. . .

Page 27: Sdn not just a buzzword

27Flow Matching Examples (1 of 2)

Ingress

PortMACSrc

MACDst

EthType

VLANId

VLANPrior

IPSrc

IPDst

IPProt

IPToS

TCP / UDPsport

TCP / UDPdpor

t

* * * * * * * * * * *3 Output: Port 5

* * * * * * * * * * *08:2c:67

:81:3f:06

Output: Port 23

* * * * * * * * * * *10.2.8.0/24

Output: Port 82

Action

Page 28: Sdn not just a buzzword

28Flow Matching Examples (2 of 2)

Ingress

PortMACSrc

MACDst

EthType

VLANId

VLANPrior

IPSrc

IPDst

IPProt

IPToS

TCP / UDPsport

TCP / UDPdpor

t

* * * * * * * * * * *08:2c:67:81:3f:

06

Modify-field:VLAN Id = 22

* * * * * * * * * * *85

* * * * * * * * * 80(HTTP)

0x0800(IP)

0x06(TCP)

Action

Modify-field:VLAN Pri = 7

Modify-field:IP ToS = 0x22

Page 29: Sdn not just a buzzword

29And how is this useful?The possibilities are endless, really.

Page 30: Sdn not just a buzzword

30What OpenFlow can do… in theory

• Think about all the possibilities in a network where there is a single complete view• L2 or L3 routing no longer has to rely on information from

neighbors for path computation• Spanning-Tree becomes unnecessary• Routing protocols like OSPF aren’t needed

• Applications that forward to multiple end hosts are inherently supported• Okay, so I’m not suggesting these things are going to happen

immediately, but…

Page 31: Sdn not just a buzzword

31That leads me to my final point(Time to wake up!)

Page 32: Sdn not just a buzzword

32We need that killer app!

Network Element

Forwarding

SDN ControllerControl

Orchestration

Network Element

Forwarding

Network Element

Forwarding

Network Element

Forwarding

Application 2????????Management Application 1

?????????

Page 33: Sdn not just a buzzword

33In closing

• Overlays are a great solution in the datacenter, but don’t address many of the current underlay restrictions• Open SDN shows tremendous promise, but will require an

open mind and significant re-thinking of how networks are built• There are ways to go about it in a phased approach• Still need a “killer app” in order to provide business case• We’re still a ways away from mass adoption, by all accounts

• Automation is an excellent precursor to SDN, and being made possible by our good friends in the DevOps movement

Page 34: Sdn not just a buzzword

34I’d like to hear your thoughts!

Not your everyday Q&AI want to hear where you

could see SDN being useful to you

Page 35: Sdn not just a buzzword

35Thank you!Please feel free to contact me: [email protected]