San Francisco Juniper Meetup Held at Chartboost Headquarters in San Francisco August 25th 2015

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

2. Who the heck is THIS guy?
Chris Jones
SDN Engineer, SDN Essentials
Juniper Ambassador
Juniper Ingenious Champion
chris@sdnessentials.com
Twitter: @IPv6Freely
Certifications
JNCIE-ENT #272
CCIE #25655 (R&S)
JNCIP-SP
JNCIS-SEC
JNCIS-QF
Publications
Day One: Junos for IOS Engineers
Day One: Ambassadors’ Cookbook
For Enterprise
JNCIE-ENT Preparation Workbook
2
Okay, moving on...

3. Agenda
• 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!
3

4. Let’s talk about cloud computing
No, seriously.
4

5. We’ve all seen these… 5

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
6

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

8. The classic definition of SDN
The physical
separation of the
network
8
control plane
from the forwarding
plane, and where a
control plane
controls several
devices.

9. Is this definition… 9
Vague?
Morphed or Skewed?
Entirely meaningless?
Let’s clarify!

10. To be clear: 10
SDN is not a technology.
Like cloud computing,
SDN is a concept!
However…

11. The 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
11

12. Open 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
12
OpenFlow
REST API
Network
Element
Forwarding
SDN Controller
Control
Management

13. SDN 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
13
Hypervisor
Network Plug-in
A1 B1
Hypervisor
Network Plug-in
A2 B2

14. SDN 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
14
Traditional
Network
Element
Forwarding
Control
Management
Management
API
OpFlex

15. Okay, so... 15
Hopefully that helps to
clarify what SDN is.

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

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
17

18. A 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
18

19. Alright, so we have issues. How can SDN help?
SDN enables a new way of looking at networks. Here, I’ll show you!
19

20. It 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
20

21. But 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
21

22. The 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
22

23. A Brief Overview of OpenFlow
But by no means comprehensive!
23

24. OpenFlow (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 others
24
SDN Controller Forwarding Element
OpenFlow

25. Flow Matching
• OpenFlow versions before 1.2 used simple match fields
• Versions 1.2+ use TLVs. Not backwards compatible
25
Ingress
Port
MAC
Src
MAC
Dst
Eth
Type
VLAN
Id
VLAN
Prior
IP
Src
IP
Dst
IP
Prot
IP
ToS
TCP/
UDP
sport
TCP/
UDP
dport
• Match: perform associated action/instruction
• No match: drop or forward to controller

26. Flow Tables
• Prioritized list of Flow Entries
• Evaluated in order, execute first match found
• Each flow has a timeout (‘idle’ and ‘hard’)
26
Priority Match Fields Actions Stats Timers
Priority Match Fields Actions Stats Timers
Priority Match Fields Actions Stats Timers
Priority Match Fields Actions Stats Timers
. . .

27. Flow Matching Examples (1 of 2) 27
Ingress
Port
MAC
Src
MAC
Dst
Eth
Type
VLAN
Id
VLAN
Prior
IP
Src
IP
Dst
IP
Prot
IP
ToS
TCP /
UDP
sport
TCP /
UDP
dport
* * * * * * * * * * *3 Output: Port 5
* * * * * * * * * * *
08:2c:67:
81:3f:06
Output: Port 23
* * * * * * * * * * *
10.2.8.0
/24
Output: Port 82
Action

28. Flow Matching Examples (2 of 2) 28
Ingress
Port
MAC
Src
MAC
Dst
Eth
Type
VLAN
Id
VLAN
Prior
IP
Src
IP
Dst
IP
Prot
IP
ToS
TCP /
UDP
sport
TCP /
UDP
dport
* * * * * * * * * * *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

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

30. What 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…
30

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

32. We need that killer app! 32
Network
Element
Forwarding
SDN Controller
Control
Orchestration
Network
Element
Forwarding
Network
Element
Forwarding
Network
Element
Forwarding
Application 2
????????
Management
Application 1
?????????

33. In 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
33

34. I’d like to hear your thoughts! 34
Not your everyday Q&A
I want to hear where you
could see SDN being
useful to you

35. Thank you!
Please feel free to contact me: chris@sdnessentials.com 35