Transcript How SDN will shape networking - James Hongyi Zeng

Formal checkings in networks
James Hongyi Zeng
with Peyman Kazemian,
George Varghese, Nick McKeown
Software Defined Network (SDN)
Control
Programs
Control
Programs
Control
Programs
Abstract Network View
Network Virtualization
Global Network View
Network OS
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
1.
2.
3.
4.
5.
6.
7.
Packet
Forwarding
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
1.
2.
3.
4.
5.
6.
7.
1.
2.
3.
4.
5.
6.
7.
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …
7. …
“S” for Software
Policy/Control SW
Configuration
Data plane
1. Static Checking
(“compile time”)
“Is my configuration
correct?”
2. Dynamic checking
(“run time”)
“Is my data plane
behaving correctly?”
With SDN we will:
1. Formally verify that our networks are
behaving correctly.
2. Identify faults, then systematically
track down their root cause.
1. Static checking
Is my configuration correct?
Motivations
In today’s networks, simple questions are hard
to answer:
– Can host A talk to host B?
– What are all the packet headers from A that can
reach B?
– Are there any loops in the network?
– Is Group X provably isolated from Group Y?
– What happens if I remove a line in the config file?
Software Defined Network (SDN)
Control
Programs
Policy
Control
Programs
Control
Programs
“A can talk to B”
Abstract Network View
“Guests can’t reach
PatientRecords”
Network Virtualization
Static
Checker
Global Network View
Network OS
1.
2.
3.
4.
5.
6.
7.
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
1.
2.
3.
4.
5.
6.
7.
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
How it works
Header Space Analysis
Header Space Analysis
2
3
1
4
1
2
3
4
Port ID
Header Space Analysis
2
3
1
4
1
2
3
4
Port ID
Can A talk to B?
2
3
1
4
1
2
3
4
Port ID
Header Space Analysis
Consequences
1.
2.
3.
4.
Finds all packets from A that can reach B
Find loops, regardless of protocol or layer
Can prove that two groups are isolated
Protocol Independent
Proves if network adheres to policy
Works on existing networks and SDNs
Stanford Backbone
1) DST IP: 172.26.66.96/28, VLAN: 330
2) DST IP: 171.64.2.128/27, VLAN: 206
3) DST IP: 172.20.10.64/27, VLAN: 10
4) DST IP: 172.24.2.128/27, VLAN: 206
5) DST IP: 172.26.4.80/29, VLAN: 206
6) DST IP: 172.26.4.88/29, VLAN: 208
7) IP Protocol: TCP
DST IP: 171.64.2.24
SRC IP: 172.28.148.27
VLAN: 206
.
.
.
40) IP Protocol: UDP
UDP DST Port: 514
750,000 IP forwarding rules.
1,500 ACL rules.
100 VLANs.
Tool
Hassel
1.
2.
3.
4.
Reads Cisco IOS Configuration
Checks reachability, loops and isolation
10 mins for Stanford Backbone to check loops
Easily made parallel: 1 sec is feasible
Hassel is available for free, for you to run
https://bitbucket.org/peymank/hassel-public/
2. Dynamic Checking
Is my data plane behaving correctly?
Motivations
Configurations might correctly reflect the policy,
but…hardware might not follow configurations
1.
2.
3.
4.
5.
Hardware errors (e.g. memory or ASIC errors)
Link failure
Congestion
Table overflow
Intermittent problems
Such errors cannot be detected by static checking.
Need a independent checker
to test the data plane
Software Defined Network (SDN)
Control
Programs
Control
Programs
Control
Programs
Abstract Network View
Network Virtualization
Global Network View
1.
2.
3.
4.
5.
6.
7.
Network OS
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
1.
2.
3.
4.
5.
6.
7.
Packet
Forwarding
1.
2.
3.
4.
5.
6.
7.
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
Testing the network
1. Monitor the network by sending test packets
2. Locate the faults with test results
Not a new idea…
– Network admins already use
ping/traceroute to test the network
• Ad-hoc test case generation
• Coarse granularity / Low coverage
• Lacks fault localization
What is the minimum number of
test packets to
1. Test every rule in every table?
2. Isolate any fault?
Test Packets
Fault Localization
How it works
Automatic Test Packet Generation
Automatic Test Packet Generation
Test Packets
How many packets needed?
Stanford Backbone
– 16 routers
– 4,000 packets (vs. 750,000 rules)
Internet2
– 9 routers
– 30,000 packets (vs. 100,000 IPv4 rules)
Testing 10x per second, requires <1% of link-rate
Fault Localization
• Given: a set of pass/fail results
• Output: the minimum set of (potential) faulty
rules
Demo
What’s next
• Automatic performance testing
Example
Application mapped to a congested router queue
Automatic Test Packet Generation will
– Identify the queue
– Determine which headers (applications)
incur poor performance
“S” for software
Policy/Control SW
Configuration
Data plane
1. Static Checking
(“compile time”)
“Is my configuration
correct?”
2. Dynamic checking
(“run time”)
“Is my data plane
behaving correctly?”
With SDN we will:
1. Formally verify that our networks are
behaving correctly.
2. Identify faults, then systematically
track down their root cause.
Will you?