Workshop on Software Defined Networks

Workshop on Software Defined Networks

Spring 2014

Groupsgroup id group members ex1 last sub. project name project sel. date

1 Liza Mash, Kostya Berestizhevsky, Idan Shaby 17.4.14 Firewall 30.4

2 , , מערוף אבו חוסאם כהן רועי לוי רועי 3.5.14 firewall 4.5

3 , , אהרון מוריה חמו בועז פינסקר שי 13.4.14

4 Or Keret, Ofir Shohet, Gal Bitensky 17.4.14

5 Nir Avnon, Chen Shoval, Roi Klien 18.4.14

6 Ori Lentzitzky, Guy Engel 1.5.14

7 , שרפי בן מרטון ירדן 4.5.14

8 Elad levi, Hanan Rofe Haim 4.5.14

9 Roy Moyal, Liraz Segal 5.5.14 Load Balancer 5.5

10 Michal Shagam, Dekel ? 8.5.14

OpenFlow Switch Specification

• Flow-Table entry:

• Possible Actions:– Forward packet to a given port (or ports)– Encapsulate packet and forward to controller– Drop packet

Packet Header

Action

Statistics

OpenFlow Switch Specification

• The header fields matched in OpenFlow switch (Type0):

• Support for normal traffic is achieved by:– A 4th action; forward packet through normal pipeline– Dedicated VLANs

OpenFlow1.3 Specification

• A pipeline of forwarding tables:

– Aggregated Action Set– Internal metadata– optional group classification

OpenFlow1.3 Specification

• Extended match header fields:

OpenFlow1.3 Specification

• Counters:

OpenFlow1.3 Specification• Each packet carries an Action set.

– Empty at the start– Updated while packet is processed– Executed at the end.

• Each Forwarding table entry is associated with an Instruction Set– Predefined (updated by controller)– Executed when entry is matched– Influences packet processing course and updates its action set.

• More actions:– Update TTL– Tag push– Tag pop– Set field– QoS

OpenFlow1.3 Groups

• Groups can be applied on a packet while processed

• Groups are defined in the group table

Group ID Group IDGroup ID

Group IDBucket Group ID

Group IDGroup IDInstruction

Out port

OpenFlow1.3 and RYU

• http://osrg.github.io/ryu-book/en/html/index.html

• http://sdnhub.org/tutorials/openflow-1-3/

PROJECTS

Router

• User input:– Routers addresses– Subnets assignments

MAC: A

10.0.0.* Port:1VLAN: 3

192.168.*.*Port:2

VLAN: *

MAC: B

10.0.0.*Port:1VLAN: 3

MAC: D

MAC: C

MAC: E

Router

• Network input:– Links

MAC: A

10.0.0.* Port:1VLAN: 3

192.168.*.*Port:2

VLAN: *

MAC: B

10.0.0.*Port:1VLAN: 3

MAC: D

MAC: C

MAC: E

Port:3VLAN: 4

Port:2VLAN: 4

Router

• Objective:– Shortest path routes

MAC: A

10.0.0.* Port:1VLAN: 3

192.168.*.*Port:2

VLAN: *

MAC: B

10.0.0.*Port:1VLAN: 3

MAC: D

MAC: C

MAC: E

Port:3VLAN: 4

Port:2VLAN: 4

Load balancer

• Split clients to servers

Action End StartServer r3 61.26.188.55 0.0.0.0Server r1 61.37.255.0 61.26.188. 56

Server r2 93.2.100.50 61.37.255.1

Drop 127.0.64.40 93.2.100.51…… ……… …..

Source IP Address

replicasInternet

…

Load balancer

• Avoid rule expansion

Action End StartServer A 125.37.255.0 125.26.188. 56Server B 126.2.100.50 125.37.255.1

Action PatternServer A 125.26.188. [00111***]

Server A 125.26.188. [*1******]

Server A 125.26.188. [10******]

Server A 125. [00011011].*.*

Server A 125. [000111**].*.*

Server A 125. [001000**].*.*

Server A 125.[00100100].*.*

Server A 125.[00100101]. 255.0

Server B 125.[00100101]. 255.*

Server A 125.[00100101]. *.*

Server B 125.[001*****].*.*

Server B 126. 1.*.*

Server B 126. 2. [00******].*

Server B 126. 2. [010*****].*

Server B 126. 2. [011000**].*

Server B 126. 2. 100.[0010****]

Server B 126. 2. 100.[00110001]

Server B 126. 2. 100.[00110010]

Load balancer• Add/remove servers when needed

Source IP Address

replicasInternet

…

Firewall• Manage sessions

InternetIntranet

DMZAction ConstraintsAllow Port = 80,

Src_ip192.168.1.1 - 192.168.3.128]Allow + Log 3600<port<3650,

Src_ip192.168.2.1 - 192.168.4.255]Dst_ip

Firewall

• Consider rule expansion

Action End StartServer A 125.37.255.0 125.26.188. 56Server B 126.2.100.50 125.37.255.1

Action PatternServer A 125.26.188. [00111***]

Server A 125.26.188. [*1******]

Server A 125.26.188. [10******]

Server A 125. [00011011].*.*

Server A 125. [000111**].*.*

Server A 125. [001000**].*.*

Server A 125.[00100100].*.*

Server A 125.[00100101]. 255.0

Server B 125.[00100101]. 255.*

Server A 125.[00100101]. *.*

Server B 125.[001*****].*.*

Server B 126. 1.*.*

Server B 126. 2. [00******].*

Server B 126. 2. [010*****].*

Server B 126. 2. [011000**].*

Server B 126. 2. 100.[0010****]

Server B 126. 2. 100.[00110001]

Server B 126. 2. 100.[00110010]

Firewall• Manage sessions

• Features:– Actions are Allow, Allow+Log, Block, Block+Log– Statefull– Consistency models (per flow/packet)– FIN detection

InternetIntranet

DMZ

Multicast Traffic

Multicast Traffic

• Input– Routers– Links– User location and request– Link and server cost

• Objective– Route streams (optimally)– Assign servers (optimally)

Distributed controller

Distributed controller

• Controller state is saved in distributed storage.• Handling an event is a transaction.• Prevent dead-locks and live-locks.• Use a simple application as an example.• Based on paper “Towards an Elastic

Distributed SDN Controller” by Dixit et. al. appeared in HotSDN2013.

Hierarchical controller

controller

Sub SDNSub SDN

Sub SDN

controllercontroller

Hierarchical controller

controller

Sub SDNSub SDN

Sub SDN

controllercontroller

controller

Fault tolerant SDN• Without the controller, an OpenFlow switch

forwards packets according to:– Static configuration – Links status– Packet header– Input port

• We want to ensure that if the network is physically connected then any packet will reach its destination (eventually).

• We prefer one instance of the packet at all time (without broadcast).

Fault tolerant SDN• Non Fault tolerant solutions:

– Source and destination based rules– Port based rules

• Our approach:– Use packet header for storing state

• Algorithms:– Module (Naïve) – DFS– BFS (very complicated)

Module Algorithm

DFS Algorithm