Workshop on Software Defined
Networks
Spring 2014
Groups
group 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:
Packet
Action
Header
Statistics
• Possible Actions:
– Forward packet to a given port (or ports)
– Encapsulate packet and forward to controller
– Drop packet
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 ID
Group ID
Group ID
Bucket
Group ID
Group ID
Group ID
Instruction
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
10.0.0.*
192.168.*.*
Port:1
VLAN: 3
Port:1
VLAN: 3
MAC:
B
MAC:
A
Port:2
VLAN: *
10.0.0.*
MAC:
D
MAC:
E
MAC:
C
Router
• Network input:
– Links
Port:1
VLAN: 3
10.0.0.*
MAC:
B
Port:3
VLAN: 4
10.0.0.*
192.168.*.*
Port:1
VLAN: 3
Port:2
VLAN: 4
MAC:
A
Port:2
VLAN: *
MAC:
D
MAC:
E
MAC:
C
Router
• Objective:
– Shortest path routes
Port:1
VLAN: 3
10.0.0.*
MAC:
B
Port:3
VLAN: 4
10.0.0.*
192.168.*.*
Port:1
VLAN: 3
Port:2
VLAN: 4
MAC:
A
Port:2
VLAN: *
MAC:
D
MAC:
E
MAC:
C
Load balancer
• Split clients to servers
replicas
Internet
Source IP Address
End
61.26.188.55
Action
Server r3
61.26.188. 56
61.37.255.0
Server r1
61.37.255.1
93.2.100.50
Server r2
93.2.100.51
…..
127.0.64.40
………
Drop
……
…
Start
0.0.0.0
Load balancer
• Avoid rule expansion
Start
125.26.188. 56
125.37.255.1
End
125.37.255.0
126.2.100.50
Action
Server A
Server B
Pattern
Action
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 A
125.[00100101]. 255.*
Server B
125.[00100101]. *.*
Server A
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]
Server B
Load balancer
• Add/remove servers when needed
replicas
Internet
…
Source IP Address
Firewall
• Manage sessions
Internet
Intranet
Constraints
Action
Port = 80,
Allow
Src_ip∈ [192.168.1.1 - 192.168.3.128]
3600<port<3650,
Allow + Log
Src_ip∈ [192.168.2.1 - 192.168.4.255]
Dst_ip∈ 10.∗.∗.∗
DMZ
Firewall
• Consider rule expansion
Start
125.26.188. 56
125.37.255.1
End
125.37.255.0
126.2.100.50
Action
Server A
Server B
Pattern
Action
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 A
125.[00100101]. 255.*
Server B
125.[00100101]. *.*
Server A
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]
Server B
Firewall
• Manage sessions
Internet
Intranet
• Features:
–
–
–
–
DMZ
Actions are Allow, Allow+Log, Block, Block+Log
Statefull
Consistency models (per flow/packet)
FIN detection
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 SDN
controller
Sub SDN
controller
Sub SDN
Hierarchical controller
controller
controller
Sub SDN
controller
Sub SDN
controller
Sub SDN
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