1 / 19

Troubleshooting SDNs

Troubleshooting SDNs. Peyman Kazemian Stanford University. Why SDN Troubleshooting. SDN decouples software (control plane) from hardware (data plane). Opens doors for innovation in networks. More competition. Brings down the capex .

stasia
Download Presentation

Troubleshooting SDNs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Troubleshooting SDNs Peyman Kazemian Stanford University

  2. Why SDN Troubleshooting • SDN decouples software (control plane) from hardware (data plane). • Opens doors for innovation in networks. • More competition. • Brings down the capex. • Makes network management task easier and hence reduce opex. • SDN software stack is a complex distributed system working in an asynchronous environment, which introduces new bugs and troubleshooting challenges. • Hardware, Network OS and Apps could come from different vendors. What will happen when things break? Who to blame?

  3. Why SDN Troubleshooting • SDN gives us a unique opportunity for systematic troubleshooting. • Decouples control plane from data plane. • State changes pushed from a logically centralized location. • Easier to access/observe the state of the network. • SDN architecture provides clear abstraction for control plane functionality. Richer troubleshooting techniques.

  4. SDN Architecture Policy • Bug = Mistranslation between different layers App App App Logical View Network Hypervisor == Physical View Network OS Device State Firmware Firmware Hardware Firmware

  5. Reactive Troubleshooting of SDNs [Operator Intent] Policy “Apps” Logical View Yes No ? ? ? ? ? NetHypervisor No = = = = = Yes Physical View Yes No NetOS No Device State No Firmware Yes Hardware [Actual Behavior] One possible Binary Search to detect where error happens reactively.

  6. Proactive Troubleshooting of SDNs [Operator Intent] Policy “Apps” Logical View Yes No ? ? ? ? ? NetHypervisor No = = = = = Physical View Yes NetOS No Device State No No Firmware Yes Hardware [Actual Behavior] One possible Binary Search to detect where error happens proactively.

  7. Research works on sdn troubleshooting

  8. Troubleshooting SDNs [Operator Intent] Policy “Apps” Logical View ? ? ? ? ? ? NetHypervisor = = = = = = Physical View NetOS Device State Firmware Hardware [Actual Behavior] NDB (Where is the debugger for my software defined network, HotSDN’12) ATPG: (Automatic Test Packet Generation, CoNEXT’12)

  9. Troubleshooting SDNs [Operator Intent] Policy “Apps” Logical View ? ? ? ? ? ? NetHypervisor = = = = = = Physical View NetOS Device State Firmware Hardware [Actual Behavior] AntEater (Debugging the dataplane with AntEater, Sigcomm’11) HSA (Header Space Analysis: static checking for networks NSDI’12) VeriFlow (Verifying Network-wide invariants in real time, HotSDN’12)

  10. Troubleshooting SDNs [Operator Intent] Policy “Apps” Logical View ? ? ? ? ? ? NetHypervisor = = = = = = Physical View NetOS Device State Firmware Hardware [Actual Behavior] OFRewind (Enabling record and replay troubleshooting for networks, ATC’11) NICE (a NICE way to test OpenFlow applications, NSDI’12)

  11. Troubleshooting SDNs [Operator Intent] Policy “Apps” Logical View ? ? ? ? ? ? NetHypervisor = = = = = = Physical View NetOS Device State Firmware Hardware [Actual Behavior] Bi-Simulation (What, Where and When: Software Fault localization for SNDs, UC Berkeley tech report)

  12. Troubleshooting SDNs [Operator Intent] Policy “Apps” Logical View ? ? ? ? ? ? NetHypervisor = = = = = = Physical View NetOS Device State Firmware Hardware [Actual Behavior] RIB == FIB? Compare device state against the actual bits and bytes in TCAMs, etc.

  13. What else is needed?

  14. Policy Expression Language • Rarely the policies are maintained anywhere, except in the mind of network admins! • Systematic troubleshooting requires such clear policy description. • Easy-to-use, expressive and standard network policy description language.

  15. Better Troubleshooting Tools • Not just detect where the problem is, but also find its root cause -- automaticaly. • Some of these tools can partially do that. • Challenges: • What Information is needed? • Packet history (NDB)? • Control message history (OFRewind)? • “Logic” behind control/data plane? • … • What is the expected output? • The sequence of events that lead to the error? • The exact (relevant) state of control software and hardware? • Looks like a mix of networking and symbolic execution and formal verification.

  16. Automated Troubleshooting • Automatically run the search through different layers to pinpoint the error. • Example: a complete system could do • Real time monitoring of data plane with test packets. • Real time checking of network policy against control messages. • Problem in data plane (e.g. link down, congestion, etc) • Report it to a control application to reroute traffic around the troubled area. • Problem in control plane • Prevent the change from hitting data plane.

  17. Policy Driven SDN • Use these techniques in reverse – try to derive correct state/configurations from the policy. • Challenges: • A policy can be implemented in zillion ways. How to reduce the search space? • Avoid conflicting implementation. • What is the correct level of human involvement?

  18. Thank You!

  19. References • A. Wundsam, D. Levin, S. Seetharaman, and A. Feldmann. OFRewind: enabling record and replay troubleshooting for networks In Proceedings of USENIX- ATC2011. • H. Zeng, P. Kazemian, G. Varghese, and N. McKeown. Automatic Test Packet Generation. In Proceedings of CoNEXT 2012, Nice, France, December 2012. • A.Khurshid, W.Zhou, M.Caesar and P.B.Godfrey. Veriflow: verifying network-wide invariants in real time. In Proceedings of HotSDN2012. • P. Kazemian, G. Varghese, and N. McKeown. Header space analysis: static checking for networks. In Proceedings of NSDI’12, 2012. • N. Handigol, B. Heller, V. Jeyakumar, D. Mazie ́res, and N. McKeown. Where is the debugger for my software- defined network? In Proceedings of HotSDN2012. • M.Canini, D.Venzano, P.Peresini, D.Kostic ́ andJ.Rexford. A NICE wayto test openflowapplications. InProceedingsof NSDI 2012. • H. Mai, A. Khurshid, R. Agarwal, M. Caesar, P. B. Godfrey, and S. T. King. Debugging the data plane with anteater. In Proceedings of SIGCOMM 2011 • C. Scott, A. Wundsam, K. Zarifisand S. Shenker. What, where and when: Software fault localization for SDN. UC Berkeley technical report.

More Related