1. Formal checkings in networks James Hongyi Zeng with Peyman Kazemian, George Varghese, Nick McKeown

2. Software Defined Network (SDN) Global Network View Network Virtualization Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Abstract Network View Control Programs Control Programs Packet Forwarding Packet Forwarding Network OS 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. …

3. “S” for Software 1.Static Checking (“compile time”) “Is my configuration correct?” 2.Dynamic checking (“run time”) “Is my data plane behaving correctly?” Policy/Control SW Configuration Data plane

4. With SDN we will: 1.Formally verify that our networks are behaving correctly. 2.Identify faults, then systematically track down their root cause.

5. 1. Static checking Is my configuration correct?

6. 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?

7. Software Defined Network (SDN) Global Network View Network Virtualization Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Abstract Network View Control Programs Control Programs Packet Forwarding Packet Forwarding Network OS 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … Static Checker 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … “A can talk to B” “Guests can’t reach PatientRecords” “A can talk to B” “Guests can’t reach PatientRecords” Policy

8. How it works Header Space Analysis

9. Header Space Analysis 1 2 3 4 1 2 3 4 Port ID

10. Header Space Analysis 1 2 3 4 1 2 3 4 Port ID

11. Can A talk to B? 1 2 3 4 1 2 3 4 Port ID

12. Header Space Analysis Consequences 1.Finds all packets from A that can reach B 2.Find loops, regardless of protocol or layer 3.Can prove that two groups are isolated 4.Protocol Independent Proves if network adheres to policy Works on existing networks and SDNs

13. 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 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. 750,000 IP forwarding rules. 1,500 ACL rules. 100 VLANs.

14. Tool Hassel 1.Reads Cisco IOS Configuration 2.Checks reachability, loops and isolation 3.10 mins for Stanford Backbone to check loops 4.Easily made parallel: 1 sec is feasible Hassel is available for free, for you to run https://bitbucket.org/peymank/hassel-public/

15. 2. Dynamic Checking Is my data plane behaving correctly?

16. Motivations Configurations might correctly reflect the policy, but…hardware might not follow configurations 1.Hardware errors (e.g. memory or ASIC errors) 2.Link failure 3.Congestion 4.Table overflow 5.Intermittent problems Such errors cannot be detected by static checking. Need a independent checker to test the data plane

17. Software Defined Network (SDN) Global Network View Network Virtualization Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Abstract Network View Control Programs Control Programs Packet Forwarding Packet Forwarding Network OS Packet Forwarding Packet Forwarding 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. … 1. 2. 3. 4. 5. 6. … 7. …

18. 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

19. 1.Test every rule in every table? 2.Isolate any fault? What is the minimum number of test packets to

20. Test Packets

21. Fault Localization

22. How it works Automatic Test Packet Generation

23. Automatic Test Packet Generation Test Packets

24. 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

25. Fault Localization Given: a set of pass/fail results Output: the minimum set of (potential) faulty rules Demo

26. 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

27. “S” for software 1.Static Checking (“compile time”) “Is my configuration correct?” 2.Dynamic checking (“run time”) “Is my data plane behaving correctly?” Policy/Control SW Configuration Data plane

28. With SDN we will: 1.Formally verify that our networks are behaving correctly. 2.Identify faults, then systematically track down their root cause.

29. Will you?