9 - Software Defined Networking Flashcards

1
Q

Network Management

A

Process of configuring network to achieve a variety of tasks

  • load balance
  • security
  • business relationships

Configuring net ]work mistakes lead to:

  • Oscillation
  • loops
  • partitions
  • black-holes
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Why is configuration hard?

A
  1. Defining correctness is hard
  2. Interactions between protocols->unpredictability
  3. Operators make mistakes
    Device-level configuration SDN changes this
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What operators need (and what SDN provides)

A
  1. Network-wide views
    - topology
    - traffic
  2. Network-level objectives
    - load balance
    - security
  3. Direct Control
    - > direct manuplation of data plane
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Routers should (to make network operations easier) …

A

+ Forward packets
+ Collect measurements
- Compute Routes -> can be (logically) centralized

Software Defined Networking == “Remove Routing from Routers”

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What is an SDN?

A

Data Plane: forward traffic
Control Plane: Compute routing tables
Today: Control + Data on routes
SDN: 1. Logically centralized control 2. network-wide control

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Advantages of SDN

A
  1. Coordination
  2. Evolve
  3. Reasoning

All of these characteristics are rooted in the fact that the control plane is separate from the data plane

This allows to provide CS techniques to networking problems

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

SDN infrastracture

A

Control Plane: Software Program (Python, C)

Data Plane: Programmable hardware (“switch”)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

SDN Applications

A
Data centers
Backbone networks
Enterprise networks
Internet Exchange Points (IXPs)
Home Networks
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Job of Control Plane

A

To compute state that ultimately ends up in the data plane

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Control Plane

A

Logic that controls forwarding behavior

Examples: routing protocols, configuration for network middleboxes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Data Plane

A

Forward traffic according to control plane

Examples: forwarding, switching

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Why is separating data and control a good idea

A
  1. Independent evolution
    - > software & hardware can evolve independently
  2. Control from high-level program
    - > debug/check behavior more easily
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Opportunities for better network management (separation of control and data plane)

A
  1. Data centers: VM migration
  2. Routing: More control over decision logic
  3. Enterprise networks: security
  4. Research: coexistence w/production
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Reasons for separating data and control

A
  • Independent evolution of data and control plane
  • Separating vendor hardware from control logic
  • Easier reasoning about network behavior
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Example of where SDN can provide huge wins

A

Data Centers

Problem: Provisioning/migration in response to load
Solution: Program switch state from a central database

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

How does control/data separation make managing data centers easier?

A
  • Monitoring/control of routes from a central point

- Migrating VMs without renumbering host addresses

17
Q

Challenges with SDN

A
  1. Scalability: Hundreds to thousands of switches
  2. Consistency: Ensuring different replicas see same view
  3. Security/Robustness: Failure or compromise?
18
Q

Ways to cope with scalability challenges

A
  • Eliminate redudant data structures
  • Only perform control-plane operations for a limited # of operations
  • Cache forwarding decisions in switches
  • Run multiple controllers
19
Q

Different SDN Controllers

A
  • Nox
  • Ryu
  • Floodlight
  • Pyretic
  • Frenetic
  • Procera
  • RouteFlow
  • Trema
20
Q

NOX

A
  • First-generation OpenFlow controller
    • -> open-source, stable, widely used
  • Two flavors
    • “Classic”: C++/Python
    • “New NOX”: C++ only, fast, clean

Characteristics:
C++
OpenFlow 1.0
Model Event-based -> event handlers

+Performance

  • Low level open flow commands
  • C++
21
Q

NOX Architecture

A

Components

  1. Switches
  2. Network-attached servers

Abstraction: Switch Control

Control: flow granularity

22
Q

flow

A

header is 10-tuple

Actions might include Forward, drop, send to controller

When a switch receives a packet:

  1. Updates counters for counting packets that belong to that flow
  2. Applies corresponding actions
23
Q

Basic Programmatic Interface for the NOX Controller

A

Based on events, such as a switch join/leave, packet in or receive method, stats etc

Controller keeps track of network view which includes a view of the underlying network topology

also speaks control protocol to the switches in the network

That control protocol effectively allows controller to update the state in the network switches

The NOX controller implements the OpenFlow protocol

24
Q

When to use Pox

A

Class project and university research

Does not perform as well as other controllers

25
Q

Ryu

A

Python
Openflow 1.0, 1.2, 1.3
Open Stack

Disadvantage:
Does not perform as well as other SDN controllers such as Nox because it is written in python

26
Q

FloodLight

A

Java
OpenFlow 1.0
Fork from “Beacon”

maintained by big switch networks

Advantages:
Documentation
REST
Performance

Disadvantages:
Hard to Learn

27
Q

Nox

A

C++
OF 1.0

Advantage:
Performance

Disadvantage:
Slow programming/debugging

28
Q

Pox

A

Python
OF 1.0

Advantage:
Easy to program

Disadvantage:
Performance

29
Q

Pox Algorithm for Switch

A
  1. Update address/port table
  2. If multicast, flood
  3. If no table entry, flood
  4. If src = dst, drop
  5. Install flow table entry
30
Q

Caching

A
  1. Packets only reach controller if no flow table entry at switch
  2. When controller decides on action, installs in switch
  3. Decision/flow table entry is cached