Software Defined Networking
COMS 6998-8, Fall 2013
Instructor: Li Erran Li
(lierranli@cs.columbia.edu)
http://www.cs.columbia.edu/~lierranli/coms
6998-8SDNFall2013/
10/1/2013: SDN Programming language and
Verification
Outline
• SDN programming language
– Maple: generic programming language syntax such as
Java, Python (previous lecture)
– Frenetic NetCore/NetKAT: domain specific
programming language (previous lecture)
– Pyretic by Josh Reich
• SDN Verification
– Verification of controller correctness (previous
lecture)
– Verification of network properties
10/1/13
Software Defined Networking (COMS 6998-8)
2
Review of Previous Lecture
What is algorithmic policies
• Function in a general purpose language that describes
how a packet should be routed, not how flow tables are
configured.
• Conceptually invoked on every packet entering the
network; may also access network environment state;
hence it has the form:
• Written in a familiar language such as Java, Python, or
Haskell
10/1/13
Software Defined Networking (COMS 6998-8)
Source: Andreas Voellmy, Yale
3
Review of Previous Lecture (Cont’d)
Example Algorithmic Policy in Java
Does not specify flow
table configutation
Route f(Packet p, Env e) {
if (p.tcpDstIs(22))
return null();
else {
Location sloc = e.location(p.ethSrc());
Location dloc = e.location(p.ethDst());
Path path = shortestPath(e.links(), sloc,dloc);
return unicast(sloc,dloc,path);
}
}
10/1/13
Software Defined Networking (COMS 6998-8)
Source: Andreas Voellmy, Yale
4
Review of Previous Lecture (Cont’d)
Certified NetKAT Controller
• Each level of abstraction
NetKAT
formalized in Coq
• Machine-checked proofs
that the transformations
between levels preserve
semantics
• Code extracted to OCaml
and deployed with real
switch hardware
10/1/13
Compiler
Optimizer
Flow tables
Run-time system
OpenFlow messages
Software Defined Networking (COMS 6998-8)
Source: Nate Foster, Cornell
5
Verification of Network Properties
• Motivations
• NetPlumber: Real time policy checking tool
– How it works
– How to check policy
– How to parallelize
• Evaluation on Google WAN
• Conclusions
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
6
Network debugging is hard!
• Forwarding state is hard to analyze!
Rule
Rule
.
.
.
Rule
10/1/13
Rule
Rule
.
.
.
Rule
Software Defined Networking (COMS 6998-8)
Rule
Rule
.
.
.
Rule
Source: P. Kazemian, Stanford
7
Network debugging is hard!
• Forwarding state is hard to analyze!
1. Distributed across multiple tables and boxes
2. Written to network by multiple independent
writers (different protocols, network admins)
3. Presented in different formats by vendors
4. Not directly observable or controllable
• Not constructed in a way that lend itself well
to checking and verification
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
8
Header Space Analysis: Snapshot-based Checking
a
TA
TD
TC
TB
Can host a talk to host b?
b
Is there any forwarding loop in the network?
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
9
Real-Time Incremental Checking
+
-
-
+
Time
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
10
Real-Time Incremental Checking
Time
Set of Policies/Invariants
+
?
+
Yes/No
Prevent errors before they hit network
Report a violation as soon as it happens
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
11
Verification of Network Properties
• Motivations
• NetPlumber: Real time policy checking tool
– How it works
– How to check policy
– How to parallelize
• Evaluation on Google WAN
• Conclusions
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
12
NetPlumber
• The System for real time policy checking is
called NetPlumber
App
App
App
App
Controller
Logically centralized location
to observe theNetPlumber
state changes
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
13
NetPlumber
• The System we build for real time policy
checking is called NetPlumber
– Creates a dependency graph of all forwarding
rules in the network and uses it to verify policy
– Nodes: forwarding rules in the network
– Directed Edges: next hop dependency of rules
10/1/13
Switch 1
Switch 2
R1
R
2
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
14
NetPlumber – Nodes and Edges
0
1 X
X
1 001
1 0XX
S
S
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
15
NetPlumber – Intra table dependency
S
S
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
16
NetPlumber – Computing Reachability
A
B
Source
Node
S
S
?
Probe
Node
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
17
NetPlumber – Computing Reachability
with Updates
1) Create directed edges
A
B
Source
Node
S
S
?
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
18
NetPlumber – Computing Reachability
with Updates
1) Create directed edges
2) Route flows
3) Update intra-table dependency
A
B
Source
Node
S
S
?
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
19
NetPlumber – Checking Policy
1) Back-tracing to check if 0010 packets go
through RED box
A
B
Source
Node
S
S
?
Policy:
10/1/13
packets go through
Software Defined Networking (COMS 6998-8)
RED box.
20
NetPlumber – Checking Policy
1) Back-tracing to check if 0010 packets go
through RED box
2) Update policy checking with rule
deletion
A
B
Source
Node
S
S
?
Policy:
10/1/13
packets go through
Software Defined Networking (COMS 6998-8)
RED box.
21
Checking Policy with NetPlumber
Policy: Guests can not access Server S.
G1
S
G2
.
.
.
.
.
.
.
.
.
10/1/13
.
.
.
.
.
.
.
.
.
.
.
.
?
.
.
.
Software Defined Networking (COMS 6998-8)
22
Checking Policy with NetPlumber
Policy: http traffic from client C to server S doesn’t go through more than 4 hops.
C
S
HTTP
.
.
.
.
.
.
.
.
.
10/1/13
.
.
.
.
.
.
.
.
.
.
.
.
?
.
.
.
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
23
Checking Policy with NetPlumber
Policy: traffic from client C to server S should go through middle box M.
C
M
S
.
.
.
.
.
.
.
.
.
10/1/13
.
.
.
.
.
.
.
.
.
.
.
.
?
.
.
.
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
24
Why the dependency graph helps
• Incremental update
– Only have to trace through dependency sub-graph
affected by an update
• Flexible policy expression
– Probe and source nodes are flexible to place and
configure
• Parallelization
– Can partition dependency graph into clusters to
minimize inter-cluster dependences
10/1/13
Software Defined Networking (COMS 6998-8)
25
Distributed NetPlumber
S
?
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
26
Dependency Graph Clustering
S
?
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
27
?
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
28
Verification of Network Properties
• Motivations
• NetPlumber: Real time policy checking tool
– How it works
– How to check policy
– How to parallelize
• Evaluation on Google WAN
• Conclusions
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
29
Experiment On Google WAN
• Google Inter-datacenter WAN.
– Largest deployed SDN, running OpenFlow
– ~143,000 OF rules
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
30
Experiment On Google WAN
• Policy check: all 52 edge
switches can talk to each
other
• More than 2500 pairwise
reachability check
• Used two snapshots taken 6
weeks apart
• Used the first snapshot to
create initial NetPlumber
state and used the diff as a
sequential update
10/1/13
Software Defined Networking (COMS 6998-8)
?
Source: P. Kazemian, Stanford
31
Experiment On Google WAN
Default/Aggregate Rules
1
0.9
Run time with Hassel > 100s
0.8
0.7
F(x)
0.6
0.5
0.4
Single instance
2 instances
3 instances
4 instances
5 instances
0.3
0.2
0.1
0
−2
10
10/1/13
−1
10
0
1
10
10
Run Time of NetPlumber (ms)
2
10
Software Defined Networking (COMS 6998-8)
3
10
Not much more benefit!
Source: P. Kazemian, Stanford
32
Benchmarking Experiment
• For a single pairwise reachability check.
10/1/13
Software Defined Networking (COMS 6998-8)
Source: P. Kazemian, Stanford
33
Conclusions
• Designed a protocol-independent system for
real time network policy checking
• Key component: dependency graph of
forwarding rule, capturing all flow paths
– Incremental update
– Flexible policy expressions
– Parallelization by clustering
10/1/13
Software Defined Networking (COMS 6998-8)
34
Questions?
10/1/13
Software Defined Networking (COMS 6998-8)
35