How SDN will shape networking - James Hongyi Zeng
advertisement
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?
