POWERING ENTERPRISE COMMUNICATIONS WITH SOFTWARE-DEFINED NETWORKS

(1)

POWERING ENTERPRISE

COMMUNICATIONS WITH

SOFTWARE-DEFINED NETWORKS

Terry Slattery

Chesapeake Netcraftsmen

Principal Consultant

CCIE #1026

(2)

Agenda

• Introductions & Objective

• What is SDN?

– Attributes of SDNs

• SDN Architecture

• SDN Standards

• How SDN Works

• Detractors

• SDN and UC

• Network Topologies for SDN

• Troubleshooting and Management

• Getting Started with SDN

(3)

Objective: Become Conversant in SDN

• What is SDN?

– Why should you care

• How SDN works

– General overview

• SDN and Unified Communications

– How SDN will affect UC

• SDN Operations

– Changes to management and troubleshooting

(4)

My Introduction to SDN

• Learned about it around 2010-2011

• Positioned to be a way for researchers to

experiment with new protocols

• Customer asked me to look into it - saw a lot of

progress

• More importantly, I saw several major benefits

– Virtualized networking

– Agility

– Efficiency

This will change networking!

(5)

SDN Is Not New

• Ipsilon General Switch Management

Protocol 1996

• IETF ForCES (Forwarding and Control

Element Separation) 2003

• IETF Path Computation Element 2005

• Clean Slate 4D 2005

• Ethane – Stanford research 2006

Good reading:

Jennifer-Rexford-The-road-to-SDN-programming-language

(6)

Why SDN?

• Protocol research mechanism

– Develop new protocols

– Evaluate on production networks (at least a part of a

production network)

• Networks are hard to manage and evolve

– Element management (vs network management)

– Need agile networks that adapt at compute & storage

virtualization speeds

– Network changes are slow

– Few organizations use automation

• No single device knows the

network state

(7)

Why SDN?

• Need ways to validate network

connectivity

– Validate security

– Can A talk to B after a network topology change?

– Detect loops

– Prove that two groups isolated

• Need conceptual models that hide the

complexity of networking

– New abstractions

– Simplify thinking about networking

• Treat the network as a system, not a collection

of devices

(8)

Definition of SDN

• SDN is a vague term

– Network hardware uses extensive software

– So what's different?

• Separation of control and data plane

– Logically centralized control

– Has a view of the entire network

– Better forwarding decisions

“SDN is the physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices.”

Open Networking Foundation

• Low-cost switches perform forwarding

– New forwarding path selection algorithms

(9)

Lexicon: Data Plane

• Fast, efficient packet forwarding machinery

– Lookup in the forwarding table

• Packet filtering, tagging, queuing, and

forwarding

• Control packets sent up to controller

(10)

Lexicon: Control Plane

• Loads forwarding entries into the data plane

• Participates in routing and switching protocols

• Provides configuration and troubleshooting

interface

10 Forwarding Table Egress Interface Ingress Interface Control Plane Data Plane

(11)

Who Runs a Wireless Network?

(12)

Who Uses Lightweight

APs and Wireless

Controllers?

(13)

You’ve Been Using a SDN

• Easier to manage

– Centralized control and management

– LWAPP communication protocol

– Policies and configuration on the controller

– Improved RF management

• Easier to deploy new access points

– Touchless install

• Lower cost APs

– Higher cost controller

(14)

Panel Discussion Points

• Why is SDN such a hot topic?

• What can SDN (or SDN-like) provide?

• Are there alternatives to, or other variants of

SDN?

Reading:

http://resources.idgenterprise.com/original/AST-0110940_SDN_Challenge_doc_FINAL.pdf

(15)

What We’re Seeking with SDN

• Agility

• Simplicity

• Provability

• Innovation

• New Abstractions

Decoupling from the hardware provides these

(16)

Agility

• Based on either central or distributed control

• Match compute and storage configuration

times

• Some proponents stop here

– SDN is more than agility and programmability

16

Si

(17)

Agility

• Based on either central or distributed control

• Match compute and storage configuration

times

• Some proponents stop here

– SDN is more than agility and programmability

17

Si

(18)

Simplicity – Is This It?

(19)

Networking by “Bag of Protocols”

• L2

– PPP, STP, TRILL, ACLs, VXLAN, NVGRE

• L3

– ARP, IP, NAT, ACLs, IPv6, GRE

• Routing

– OSPF, EIGRP, EBGP, MP-BGP, MPLS

• L4

– UDP, TCP, Stateful Firewall, IPSEC

• Have a new problem?

– Create a new protocol

• This is not the path to simpler networking!

(20)

Provability

• Connectivity validation

– Prove that A can or can not talk to B

– Prove group isolation (e.g., PCI compliance)

– Identify the communication paths

• What-if analysis

– Does redundancy really exist?

– Do communication paths traverse desired control

points (firewalls, load balancers, etc)?

– What happens after a failure?

20 PSTN Gateway Call Controller X

X

(21)

Innovation

• Hardware innovation cycles are long

– 1-1.5 years ASIC development

– 1-3 years hardware design & deployment

– Expensive hardware replacement and upgrade

• Software innovation can be fast

– 3-6 months

– Software upgrade

– Hardware fast enough

to make software viable

(22)

Lexicon: Abstractions

• "In computer science, abstraction is the

process by which data and programs are

defined with a representation similar in form to

its meaning, while hiding away the

implementation details." – Wikipedia

• Allow thinking at a higher level while hiding

complex details

• Provide ways to think about networks in ways

that can be used to validate them

Note: Someone has to understand the internals

(23)

New Abstractions

• Forwarding domains

– Equivalent to MPLS L3VPN

– Hides implementation details (VLAN, ACLs, MP-BGP,

MPLS VRF)

• Profile definitions

– Collection of characteristics about an entity

– Interface profiles: identify forwarding domain

– Application profiles: flow processing definitions

• Device models

– Simplifies and standardizes configurations

– Detractor: limits functionality to common functions

(24)

Memory Management Analogy

24

• Memory management used to be manual

– Limited physical memory

(PDP11: 64KB – 256KB)

– Programmer manually designed overlays

(25)

Memory Management Analogy

• Virtual memory eliminated manual

process

– Memory manager code

controls overlays

– Program contents automatically

read from disk or saved to disk

– Increased programmer

productivity

– Enabled new innovation

in software

– Required memory management

hardware and some CPU cycles

• Abstraction:

Large memory space

(26)

Disk System Virtualization

• Partitioning and layouts

– Similar to memory management

– Now done by storage virtualization

– Abstraction: LUNs

• Flexible partitioning

– Grow/shrink partitions

– GUI interface

• Decoupled from the hardware

– Logical partitions can span drives

– Improve utilization

– Facilitates new functionality

• De-duplication

• RealTime backups

(27)

Compute virtualization

• Decoupled from the hardware

– Hypervisor provides common virtual compute

instances

• Abstraction: Virtual Machines (VMs)

– Less administration, more consistency

– Increase utilization (greater ROI)

(28)

Common Themes

• Hide complexity

– Internals are complex, perhaps even more so

– Those internals are hidden during normal use

– Provides new ways to think of the systems

– Enables innovation

• Avoid manual processes

– More flexible and dynamic

– No longer functions at human speeds

– Machines take care of the details

(that humans don’t handle well)

• Seems to imply unacceptable overhead

– Automated processes often provide gains

– Productivity gain is worth the cost

(29)

We Need to Virtualize Networks

29 Midokura image

(30)

Panel Discussion Points

• What else does SDN bring to the table?

• Why do New Abstractions rarely surface as a

key factor?

• Do we really need to virtualize networking?

• Will performance suffer by decoupling from

hardware?

(31)

An SDN Architecture

1. <Match, Action> 2. <Match, Action> 3. <Match, Action> 4. <Match, Action> 5. <Match, Action> 6. … 7. … 1. <Match, Action> 2. <Match, Action> 3. <Match, Action> 4. <Match, Action> 5. <Match, Action> 6. … 7. … 1. <Match, Action> 2. <Match, Action> 3. <Match, Action> 4. <Match, Action> 5. <Match, Action> 6. … 7. … 1. <Match, Action> 2. <Match, Action> 3. <Match, Action> 4. <Match, Action> 5. <Match, Action> 6. … 7. …

Static

Checker

Global Network View

Network Virtualization Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding

Abstract Network View

Control

Programs ProgramsControl

Control Programs Packet Forwarding Packet Forwarding Network OS 1. <Match, Action> 2. <Match, Action> 3. <Match, Action> 4. <Match, Action> 5. <Match, Action> 6. … 7. … 1. <Match, Action> 2. <Match, Action> 3. <Match, Action> 4. <Match, Action> 5. <Match, Action> 6. … 7. … 1. <Match, Action> 2. <Match, Action> 3. <Match, Action> 4. <Match, Action> 5. <Match, Action> 6. … 7. … 1. <Match, Action> 2. <Match, Action> 3. <Match, Action> 4. <Match, Action> 5. <Match, Action> 6. … 7. … 1. <Match, Action> 2. <Match, Action> 3. <Match, Action> 4. <Match, Action> 5. <Match, Action> 6. … 7. … 1. <Match, Action> 2. <Match, Action> 3. <Match, Action> 4. <Match, Action> 5. <Match, Action> 6. … 7. … 1. <Match, Action> 2. <Match, Action> 3. <Match, Action> 4. <Match, Action> 5. <Match, Action> 6. … 7. … 1. <Match, Action> 2. <Match, Action> 3. <Match, Action> 4. <Match, Action> 5. <Match, Action> 6. … 7. … 1. <Match, Action> 2. <Match, Action> 3. <Match, Action> 4. <Match, Action> 5. <Match, Action> 6. … 7. … 1. <Match, Action> 2. <Match, Action> 3. <Match, Action> 4. <Match, Action> 5. <Match, Action> 6. … 7. …

“A can talk to B” “Guests can’t

reach PatientRecords”

Policy

(32)

Why Separate Control and Data Plane?

• Forwarding based on more than destination

address

– More optimal path selection: Valiant Load Balancing*

– Improves network utilization:

• Google reports nearly 100% WAN utilization

• Time critical traffic gets priority

• Remaining bandwidth filled with bulk data

• Better routing due to higher level network view

• Avoid special protocols/configuration for policy

routing

– Simplifies configuration

– Easier troubleshooting

* Valiant Load Balancing is discussed later

(33)

Why Separate Control and Data Plane?

• Run Control software on modern, multi-core

processors

– Faster processing

– Update the control algorithms more frequently

• Simpler data plane implementation

– Lower cost switches

• Platform for protocol

development

(34)

Data Plane Abstractions

• We already have them

• Separation of layers

– Changes in one layer don’t

affect other layers

– Details of lower layers are hidden

from upper layers

• Reasonable conceptual model

• Caveat: L2 VLAN and L3 subnet

must be congruent

34 Application Application Presentation Presentation Session Session Transport Transport Network Network Data Link Data Link Physical

(35)

Control Plane Abstractions

• Abstractions or mechanisms?

• Bag of protocols

– Protocol de jour – Mixing protocols?

• Complexity is exposed

– No layering or hierarchy

– Many, many details to

manage

• For every problem, we’ve

created a new bandage

(protocol)

(36)

Networking Technology is NOT Improving!

• New protocol for each problem or function

– For each problem, we slap on a new bandage

– Bandages on top of other bandages

• Interactions between protocols

– ARP and switch CAM timers (CCIE test question)

– Ex: QoS hooks into several protocols

36

L2 Header MPLS Label EXP S+TTL IP Packet

MPLS EXP: 3bits for QoS

DST MAC TPID PCP DEI+VLID Payload

802.1Q PCP: 3bits for CoS

SRC MAC Length FCS

Ver DSCP Remaining Header Payload

IP: 6bits for ToS/DSCP

(37)

Increasing complexity

(38)

Why Enterprises Are Excited About SDN

• Agility

– Match compute & storage

configuration speeds

– Adapt to migrating VMs

– Deploy new apps quickly

– Match workloads with

compute & storage

• Simplification

– Configuration, operation, troubleshooting

– Configuration consistency from one control system

• Utilization

– Google increased utilization from 30-40% to 100%

– Search for “Google OpenFlow Vahdat”

(39)

Why Enterprises are Excited About SDN

• Innovation

– Software speeds feature development

– Hardware is typically 5 year dev & deployment

• Lower costs

– Less expensive switches

– Offset by controller cost?

– Lower operational costs

(40)

SDN Example: Big Internet App

• App needs more processors to handle the load

– App asks VM controller for more compute

– New VMs assigned from available pool

• SDN controller configures the network for VMs

– SDN controller acks to VM controller

• What if VMs are in a bad location?

– SDN controller tells VM controller to change VMs

– Process repeats

40

Web Tier

(41)

Panel Discussion Points

• Why do we trend towards more complexity?

• Can SDN help break the cycle of a new protocol

for each problem?

• Is SDN continuing the cycle of a new protocol

for each new problem?

• Will SDN really make things simpler?

• Are there other SDN architectures?

• Why are your customers interested in SDN?

(42)

Objective: Become Conversant in SDN

• What is SDN?

• How SDN works

• SDN and Unified Communications

• SDN Operations

(43)

SDN Standards

• Openflow

– Southbound interface, Controller to Switch

– 1.2 or 1.3 generally accepted; 1.4 published

– Standardize only what’s required

43

Open Networking Foundation Working Groups and Committees

Extensibility OF wire protocol, extensible match & error messages, forwarding model

Configuration & Management Protocol & schema for configuration of a switch Testing & Interoperability Interoperabilty tests, plug-fests, conformance

test suites, performance benchmarks Hybrid programmable forwarding

plane

Insertion of OF into legacy network: hybrid switches, hybrid networks

OpenFlow Future Future of OF and interfaces to other protocols Northbound API & SDN

abstractions

Object & service models, virtualization,

characterization, interaction (WGrp Oct 2013) Market Education Defining use cases, SDN lexicon, SDN tutorials

(44)

How OpenFlow-Based SDN Works

44 Specifies behavior… Of a virtual network… Controlled by OpenFlow… Via the OpenFlow protocol.

(45)

OpenFlow-Based SDN

• OpenFlow protocol

– Controller to switch communications

– Usually encrypted with TLS

– Add, delete, update flow entries

• Controller loads flow tables

– Flow tables define forwarding

rules

– Multiple tables chained

– Group table facilitates multicast,

multipath, fast failover

(46)

Flow Entry

• Packet match in flow tables:

– Action to take

(forward, drop, modify, etc)

– Counters increment

46 Switch

Port MACsrc MACdst typeEth VLANID SrcIP DstIP ProtIP sportTCP dportTCP

Match

Action

Stats

1. Forward packet to port(s)

2. Encapsulate and forward to controller 3. Drop packet

4. Send to normal processing pipeline

+ mask

(47)

Switch Lookup Mechanism: Web

Ingress Port Eth Src Eth Dst Eth Type VLAN ID IP Dst IP Src TCP Dst TCP Src IP Proto Action Port 0/1 * * * * 10.1.1.10/32 * 80 * * Port 0/3 * * * * * 10.5.5.0/24 10.1.0.0/16 80 * * Port 1/1, Q1 * * * * * 10.5.5.0/24 10.2.2.0/24 * * * Port 2/2, Q2 Port 3/2 * * * * 10.1.1.0/24 * 25 * * Port 0/2 * * * * * * * * * * To Controller 47 Port 0/1 * * * * 10.1.1.10 10.2.2.20 80 1111 * Packet header Flow Table Lookup

Action Bucket Send packet to Port 0/3, default queue, increment counters Port 0/3 Output

(48)

Switch Lookup Mechanism: Phone

48 Ingress Port Eth Src Eth Dst Eth Type VLAN ID IP Dst IP Src TCP Dst TCP Src IP Proto Action Port 0/1 * * * * 10.1.1.10/32 * 80 * * Port 0/3 * * * * * 10.5.5.0/24 10.1.0.0/16 80 * * Port 1/1, Q1 * * * * * 10.5.5.0/24 10.2.2.0/24 * * * Port 2/2, Q2 Port 3/2 * * * * 10.1.1.0/24 * 25 * * Port 0/2 * * * * * * * * * * To Controller 48 Port 5/1 * * * * 10.5.5.5 10.2.2.10 2443 1111 * Packet header Flow Table Lookup

Send packet to Port 2/2, Queue 2, increment counters Action Bucket Port 2/2 Queue2 Output

(49)

Switch Lookup Mechanism: Unknown

49 Ingress Port Eth Src Eth Dst Eth Type VLAN ID IP Dst IP Src TCP Dst TCP Src IP Proto Action Port 0/1 * * * * 10.1.1.10/32 * 80 * * Port 0/3 * * * * * 10.5.5.0/24 10.1.0.0/16 80 * * Port 1/1, Q1 * * * * * 10.5.5.0/24 10.2.2.0/24 * * * Port 2/2, Q2 Port 3/2 * * * * 10.1.1.0/24 * 25 * * Port 0/2 * * * * * * * * * * To Controller 49 Port 5/3 * * * * 10.6.6.6 10.2.2.20 80 1111 * Packet header Flow Table Lookup

Send packet to Controller, increment counters Action Bucket Punt to Controller Output

(50)

OpenFlow Table Actions

• Forward packet

– Group table: multicast, broadcast

• Drop packet

– ACL functionality, Not stateful firewall

• Push/Pop new header

– Encapsulation (tunnel, IPSec, etc)

– VLAN or MPLS tag

• Modify header fields

– Decrement TTL, QoS DSCP/CoS, NAT

• Forward to controller

– Unknown destination (ARP lookup required)

• Counters kept on all flow entries

– Useful for management, troubleshooting, tuning

(51)

Table Processing Mechanism

• Find highest-priority matching flow entry

• Apply instructions

– Modify packet & update match fields

– Update Action Set (add or delete actions)

– Update metadata

• Send match data and action set to next table

• At interface output, execute Action Set

(52)

Example Table Processing

• Ingress ACL table:

– Match src addr fails: Drop

else:

– Push VLAN tag, Decrement TTL, send to next table

• QoS table:

– Match addrs, protocol, port: set_queue

• Dst addr table:

– Match dst addr: set group or output interface

else:

– Forward to controller (punt)

• If group actions:

– Apply group actions and output on interface(s)

else:

– Apply actions; output packet on specified interface

(53)

OpenFlow 1.1 Features

• Interface groups

– Link aggregation

– Multicast/broadcast

• MPLS & VLAN tags

• Virtual/Logical ports

– Tunnels, loopback, etc

• Multiple flow tables

– Reduces overall

table size

• Controller connection failure

– Run disconnected

– Revert to normal switch forwarding behavior

53 Match address (select output interface) Match ingress ACL (permit/deny) Match egress ACL (permit/deny)

(54)

OpenFlow 1.2 Features

• Extensible match support

– Variable length matching – increases flexibility

• Basic IPv6 support

• Controller role-change mechanism

– Allows for master/secondary controller

54

2001:0DB8:10BA::4559:1FE2

Master Secondary

(55)

OpenFlow 1.3 Features

• Expanded IPv6 support

• Per-flow meters

– Facilitates rate limiting functions (QoS, security)

– Basic management functionality

• Provider backbone bridging tagging

– Allows multi-tenant OpenFlow networks

• Tunnel ID metadata

– Used to specify the encapsulation to be used

55 Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Tunnel0 Tunnel1

(56)

OpenFlow 1.4 Features

• Synchronized tables

– Replicates table changes

– Useful where two tables contain the same data (e.g.,

MAC addresses for learning and forwarding)

• Optical interface support

– Configure and monitor laser operational parameters

• Bundled table updates

– Enables quasi-atomic changes to make changes

simultaneously

– Add a flow handling entry:

ACL, QoS, IP Addr, TCP/UDP port number, …

(57)

SDN Controllers (a partial list)

• Beacon

– Stanford Univ research project, Java-based

• Floodlight

– Java-based controller Open Source from Big Switch

– Derived from Beacon

• NOX and POX

– The first OpenFlow research controller, C++/Python

• Open Daylight

– Cisco & others

• ProgrammableFlow

– NEC controller (commercial, closed source)

• Big Network Controller

– BigSwitch Networks (commercial, closed souce)

(58)

Panel Discussion Points

• How important are standards?

– Northbound API

– Management API

– Security API

• What’s been your experience at SDN

interoperability plugfests?

• SDN is currently relatively simple; Will that

change?

• Will SDN remain Open?

– Will vendor extensions hurt SDN?

(59)

Hybrid SDN

• Switches include traditional forwarding tables

– Progression to a future SDN architecture

– SDN doesn’t know how to forward, then use Normal

method

• Centralized control with local backup

– Distributed control system needed anyway for

resilience

• Forwarding state maintained

locally and by SDN

– Challenge: Synchronize

state with other switches

– Avoid forwarding loops

(60)

Programming SDNs

• App developers write SDN apps?

– App developers don’t know how networks work

– High risk of bugs

• Suggestion: App vendors should develop

modules

– Verified by vendors

– Validated by customers

– Example: Big web app (Amazon AWS) with

middleware and backend DB

– Example: Dynamic UC bandwidth and QoS

• Developers will assemble validated modules

– Fewer bugs!

– Faster development time (lower cost)

(61)

But It Won’t Work!

• SDN doesn’t scale up

– We’ll need a separate control network

• Forwarding table size limits in switches

– New silicon developed by researchers

– Programmable ASICs from Juniper, Cisco, others

• Round trip delay from switch to controller

– Microseconds to milliseconds

• New technology has similar detractors

– Recall routing vs switching wars?

“Switch when you can, route when you must!”

• Prediction:

– We will learn how to optimize SDN

(62)

Interfacing With the Rest of the Network

• Yes, SDN will need to run network protocols

• Routing protocols

– The full suite:

RIPv2, OSPF, EIGRP, IS-IS, BGP

– SDN domain = OSPF

area or IS-IS area?

– Emulate a big router

at its edge? 62 Si SiSi Si SiSiSiSi SiSiSiSi SiSiSiSi OSPF BGP

I-Net WAN Sites

(63)

Interfacing With the Rest of the Network

• Spanning tree protocol

– Not needed internally; controller should create

loop-free topology

– Required to interface with STP L2 domains

• Interface protocols

– Bidirectional Forwarding Detection (BFD)

– LLDP & related link protocols

(64)

Panel Discussion Points

• What is your model for SDN programming?

– API only

– Functional libraries

• Do SDN detractors have any valid points?

– Especially scaling arguments

• There’s a lot of hype around SDN

– What is real and what isn’t?

• How will SDNs interface with the rest of the

network?

– Exchange routes

– Avoid loops

– Efficiently use all paths

(65)

Objective: Become Conversant in SDN

• What is SDN?

• How SDN works

• SDN and Unified Communications

• SDN Operations

(66)

What Does SDN Mean to UC?

• Agility

– Eliminate static configurations

– Replace manual processes

• Better service

– Support UC QoS marking to untrusted endpoints (the

desktop)

– Traffic prioritization based on LDAP login (e.g.,

CEO login)

• Increased efficiency

– Higher network utilization (better ROI)

– Policy routing without complex mechanisms

(67)

UC Example: SDN Outside the Data Center

67

I-Net

Remote Site

• UC location with 10 concurrent calls expected

– More concurrent calls start occurring

– Need more call bandwidth on the link

• UC controller asks SDN controller for increase

– If BW available, apply QoS, allocate BW, permit call

– SDN controller denies if network is at capacity

• UC controller may switch to

lower BW codecs to handle new calls

(68)

• Setting QoS on untrusted endpoints

– Classification has typically been problematic

• UC controller tells SDN controller about the call

– 10.1.1.50 <-> 10.2.2.100, UDP, QoS marking EF

– Other traffic marked QoS BE

• SDN controller configures QoS according to

policies

– Search: “How-an-SDN-API-could-improve-Microsoft-Lync-performance”

UC Example: UC on Workstations

68 Untrusted Traffic Mark for Best Effort RealTime (Voice) Traffic

Mark for EF

10.1.1.50

10.2.2.100

(69)

Policies Drive Operations

• Business policies dictate SDN actions

– Define the network reaction when something

changes

– Change may be good or bad

• New call setup

• Failed link or device

• Will need tools & templates to help build good

policies

(70)

• Multi-tier network

– Central failure

– NMS must detect and report

• Network bandwidth reduced

to 50%

– Multiple failure points

– Redundant but perhaps

not resilient

– Reduced bandwidth

with one failure

Network Resilience

70 Call Controller Failure!

X

Compute & Storage

(71)

Network Resilience

• Leaf/Spine network (folded CLOS)

– Recent data center design

– SDN controller detects failure and reroutes flows

– Can be non-blocking

– Spine switches are not interconnected

• Network bandwidth reduced by 1/N

– N = number of spine switches

– Graceful degradation

– Scales easily

– Search:

“folded clos network”

71 Si Si Si Si SiSiSiSi SiSiSiSi SiSiSiSi Failure!

X

(72)

Panel Discussion Points

• Are there other examples of SDN for UC?

• Is SDN primarily a data center technology?

• What do you predict for SDN and UC?

(73)

Objective: Become Conversant in SDN

• What is SDN?

• How SDN works

• SDN and Unified Communications

• SDN Operations

(74)

Operational Impact

• Networking and applications team

communications must improve

– Learn each other’s language

– Develop team approach to troubleshooting

• Networking must embrace automation

– Staff is trained to use the CLI

– Fear of breaking the network faster than manual

methods can fix it

– Helpful to learn basic scripting (Python)

• New management & troubleshooting processes

– SDN management systems

– Troubleshooting application problems

– Working with SDN-based routing protocols

(75)

Monitoring and Management

• Network performance

– Still need to detect Layer 1 problems

– Track and report utilization

• Switch health

– Forwarding table utilization

– Device functions (fans, power)

• Mapping

– Virtual network to underlying

physical network

– Finding a VM’s location

– Locating App servers

– Search: “sdn management risks and challenges” 75 PSTN Gateway Call Controller Errors! Drops!

(76)

Troubleshooting

• Application deployment maps

– Where are the VMs for an app?

– High latency: some VMs are in a remote data center

• Mapping overlay to underlay

– Identify physical infrastructure when a problem is

detected

• Typical problems

– Duplex mismatch

– Controller to switch communications failure

– VM controller to SDN controller comm failure

– Underlay failure that isolates part of the network

– Duplex mismatch on SDN controller; could happen!

– SDN controller running in a VM

(77)

Getting Started with SDN

• Start small

– Two racks of blade servers

– VM and SDN controllers

– No need to go fast; SDN will evolve over time

• Learn how to…

– Connect SDN domain to the rest of the network

– Monitoring and management

– Troubleshooting

– Transition to SDNs

(78)

Panel Discussion Points

• What are the challenges for monitoring SDNs?

• Will troubleshooting change significantly?

• Recommendations for starting with SDN

• What is your prediction for SDN?

(79)

Summary

• SDN will happen

– Network virtualization is needed

– The exact form isn’t clear

• Start learning

– You are here today… That’s good

– Follow your vendor’s progress

– Determine how SDN could be deployed in your

network