software defined networking coms 6998- 8 , fall 2013
DESCRIPTION
Software Defined Networking COMS 6998- 8 , Fall 2013. Instructor: Li Erran Li ( [email protected] ) http://www.cs.columbia.edu/ ~lierranli/coms6998-8SDNFall2013/ 10/1/2013: SDN Programming language and Verification. Outline. SDN programming language - PowerPoint PPT PresentationTRANSCRIPT
Software Defined NetworkingCOMS 6998-8, Fall 2013
Instructor: Li Erran Li ([email protected])
http://www.cs.columbia.edu/~lierranli/coms6998-8SDNFall2013/
10/1/2013: SDN Programming language and Verification
Software Defined Networking (COMS 6998-8) 2
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) 3
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 Source: Andreas Voellmy, Yale
Software Defined Networking (COMS 6998-8) 4
Example Algorithmic Policy in Java
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); }}
Does not specify flow table configutation
10/1/13 Source: Andreas Voellmy, Yale
Review of Previous Lecture (Cont’d)
Software Defined Networking (COMS 6998-8) 5
NetKAT
Flow tables
OpenFlow messages
Compiler
Run-time system
Optimizer
•Each level of abstraction formalized in Coq
•Machine-checked proofs that the transformations between levels preserve semantics
•Code extracted to OCaml and deployed with real switch hardware
Certified NetKAT Controller
10/1/13 Source: Nate Foster, Cornell
Review of Previous Lecture (Cont’d)
Software Defined Networking (COMS 6998-8) 6
Verification of Network Properties
10/1/13 Source: P. Kazemian, Stanford
• Motivations• NetPlumber: Real time policy checking tool– How it works– How to check policy– How to parallelize
• Evaluation on Google WAN• Conclusions
Software Defined Networking (COMS 6998-8) 7
Network debugging is hard!
• Forwarding state is hard to analyze!
...
RuleRule
Rule
...
RuleRule
...
RuleRule
Rule
Rule
10/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8) 8
Network debugging is hard!
• Forwarding state is hard to analyze!1. Distributed across multiple tables and boxes2. Written to network by multiple independent
writers (different protocols, network admins)3. Presented in different formats by vendors4. Not directly observable or controllable
• Not constructed in a way that lend itself well to checking and verification
10/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8) 9
Header Space Analysis: Snapshot-based Checking
TA
TB
TD
TC
a
bCan host a talk to host b?
Is there any forwarding loop in the network?
10/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8) 10
Real-Time Incremental Checking
+ - +-
Time
10/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8)
Real-Time Incremental Checking
+-+
-
?
Set of Policies/Invariants
Yes/No
Time
Prevent errors before they hit networkReport a violation as soon as it happens
10/1/13 11Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8)
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
1210/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8)
NetPlumber
13
Controller
App App App App
NetPlumber
• The System for real time policy checking is called NetPlumber
State updatesLogically centralized location to observe the state changesSNMP Trap
10/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8) 14
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
R1 R2
Switch 1 Switch 2
10/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8) 15
NetPlumber – Nodes and Edges
S
S
0 1 X X
10/1/13 Source: P. Kazemian, Stanford
1 0 0 1
1 0 X X
Software Defined Networking (COMS 6998-8) 16
NetPlumber – Intra table dependency
S
S
10/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8) 17
ProbeNode
NetPlumber – Computing Reachability
S
S
A
B
?
SourceNode
10/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8) 18
NetPlumber – Computing Reachability with Updates
S
S
A
B
?
SourceNode
1) Create directed edges
10/1/13 Source: P. Kazemian, Stanford
New rules installed
Software Defined Networking (COMS 6998-8) 19
NetPlumber – Computing Reachabilitywith Updates
S
S
A
B
?
SourceNode
-
1) Create directed edges2) Route flows 3) Update intra-table dependency
10/1/13 Source: P. Kazemian, Stanford
20
NetPlumber – Checking Policy
S
S
A
B
?
SourceNode
Policy: packets go through RED box. 10/1/13
Software Defined Networking (COMS 6998-8)
1) Back-tracing to check if 0010 packets go through RED box
21
NetPlumber – Checking Policy
S
S
A
B
?
SourceNode
Policy: packets go through RED box. 10/1/13
Software Defined Networking (COMS 6998-8)
1) Back-tracing to check if 0010 packets go through RED box
2) Update policy checking with rule deletion
Software Defined Networking (COMS 6998-8) 22
Checking Policy with NetPlumber
...
...
...
......
...
...
...
Policy: Guests can not access Server S.
S
?
G1
G2
10/1/13
Software Defined Networking (COMS 6998-8) 23
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 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8) 24
Checking Policy with NetPlumber
...
...
...
......
...
...
...
Policy: traffic from client C to server S should go through middle box M.
C
?
S
M
10/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8) 25
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)
Distributed NetPlumber
26
S
?
10/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8)
Dependency Graph Clustering
27
S
?
10/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8)
?
28
?
10/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8) 29
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 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8)
Experiment On Google WAN
• Google Inter-datacenter WAN.– Largest deployed SDN, running OpenFlow– ~143,000 OF rules
3010/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8)
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
31
?
10/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8)
Experiment On Google WAN
32
Default/Aggregate Rules
Not much more benefit!
Run time with Hassel > 100s
10/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8) 33
Benchmarking Experiment
• For a single pairwise reachability check.
10/1/13 Source: P. Kazemian, Stanford
Software Defined Networking (COMS 6998-8) 34
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) 35
Questions?
10/1/13