1. Shadow Configurations: A Network Management Primitive Richard Alimi, Ye Wang, and Y. Richard Yang Laboratory of Networked Systems Yale University February 16, 2009

2. Yale University2 Configuration Leads to Errors Source: The Yankee Group, 2004 Source: Juniper Networks, 2008 “... human error is blamed for 50-80% of network outages.” “80% of IT budgets is used to maintain the status quo.” Why is configuration hard today?

3. February 16, 2009Yale University3 Configuration Management Today Simulation & Analysis  Depend on simplified models Network structure Hardware and software  Limited scalability  Hard to access real traffic Test networks  Can be prohibitively expensive OSPF eBGP VPNs ACLs TE SLAsiBGPTraffic Software Hardware Why are these not enough?

4. February 16, 2009Yale University4 Analogy with Programming Programming Network Management Program Target System Configs Target Network

5. February 16, 2009Yale University5 Analogy with Databases Databases Network Management INSERT... DELETE... UPDATE... INSERT... DELETE... UPDATE... STATE A STATE B ip route... ip addr... STATE A ? router bgp... STATE B STATE C router ospf... STATE D

6. February 16, 2009Yale University6 Enter, Shadow Configurations OSPF eBGP VPNs ACLs TE SLAsiBGPTraffic Software Hardware Key Benefits  Realistic (no model)  Scalable  Access to real traffic  Transactional Key ideas  Allow additional (shadow) config on each router  In-network, interactive shadow environment  “Shadow” term from computer graphics

7. February 16, 2009Yale University7 Roadmap Motivation and Overview System Basics and Usage System Components  Design and Architecture  Performance Testing  Transaction Support Implementation and Evaluation

8. February 16, 2009Yale University8 What's in the shadow configuration?  Routing parameters  ACLs  Interface parameters  VPNs  QoS parameters Shadow config Real config Shadow header marked “1” Real header marked “0” System Basics

9. February 16, 2009Yale University9 Example Usage Scenario: Backup Path Verification Primary Backup

10. February 16, 2009Yale University10 Example Usage Scenario: Backup Path Verification Send test packets in shadow

11. February 16, 2009Yale University11 Example Usage Scenario: Backup Path Verification Disable shadow link XX

12. February 16, 2009Yale University12 Example Usage Scenario: Backup Path Verification

13. February 16, 2009Yale University13 Example Usage Scenario: Configuration Evaluation Video Server

14. February 16, 2009Yale University14 Example Usage Scenario: Configuration Evaluation Video Server

15. February 16, 2009Yale University15 Example Usage Scenario: Configuration Evaluation Video Server Duplicate packets to shadow

16. February 16, 2009Yale University16 Roadmap Motivation and Overview System Basics and Usage System Components  Design and Architecture  Performance Testing  Transaction Support Implementation and Evaluation

17. February 16, 2009Yale University17 Design and Architecture Management Control Plane Forwarding Engine Configuration UI BGP OSPF IS-IS Interface 0 Interface 1 Interface 2 Interface 3 FIB

18. February 16, 2009Yale University18 Design and Architecture Management Control Plane Forwarding Engine Configuration UI BGP OSPF IS-IS Shadow-enabled FIB Shadow Bandwidth Control Interface 0 Interface 1 Interface 2 Interface 3

19. February 16, 2009Yale University19 Design and Architecture Management Control Plane Forwarding Engine Configuration UI Shadow Management Commitment BGP OSPF IS-IS Shadow-enabled FIB Shadow Bandwidth Control Interface 0 Interface 1 Interface 2 Interface 3

20. February 16, 2009Yale University20 Design and Architecture Management Control Plane Forwarding Engine Configuration UI Shadow Traffic Control FIB Analysis Debugging Tools Shadow Management Commitment BGP OSPF IS-IS Shadow-enabled FIB Shadow Bandwidth Control Interface 0 Interface 1 Interface 2 Interface 3

21. February 16, 2009Yale University21 Design and Architecture Management Control Plane Forwarding Engine Configuration UI Shadow Traffic Control FIB Analysis Debugging Tools Shadow Management Commitment BGP OSPF IS-IS Shadow-enabled FIB Shadow Bandwidth Control Interface 0 Interface 1 Interface 2 Interface 3

22. February 16, 2009Yale University22 Shadow Bandwidth Control Requirements  Minimal impact on real traffic  Accurate performance measurements of shadow configuration Supported Modes  Priority  Bandwidth Partitioning  Packet Cancellation

23. February 16, 2009Yale University23 Observation: in many network performance testing scenarios,  Content of payload is not important  Only payload size matters Idea: only need headers for shadow traffic Piggyback shadow headers on real packets Piggybacked shadow header Packet Cancellation

24. February 16, 2009Yale University24 Packet Cancellation Details Output interface maintains real and shadow queues  Q r and Q s

25. February 16, 2009Yale University25 Packet Cancellation Details Output interface maintains real and shadow queues  Q r and Q s

26. February 16, 2009Yale University26 Packet Cancellation Details Output interface maintains real and shadow queues  Q r and Q s

27. February 16, 2009Yale University27 Packet Cancellation Details Output interface maintains real and shadow queues  Q r and Q s

28. February 16, 2009Yale University28 Forwarding Overhead IP Looku p Without Packet Cancellation: IP Looku p With Packet Cancellation: Cancellation may require routers to process more packets. Can routers support it?

29. February 16, 2009Yale University29 Routers can be designed for worst-case  L : Link speed  K min : Minimum packet size  Router supports packets per second Load typically measured by link utilization  α r : Utilization due to real traffic (packet sizes k r )  α s : Utilization due to shadow traffic (packet sizes k s ) We require: Forwarding Overhead Analysis

30. February 16, 2009Yale University30 Routers can be designed for worst-case  L : Link speed  K min : Minimum packet size  Router supports packets per second Load typically measured by link utilization  α r : Utilization due to real traffic (packet sizes k r )  α s : Utilization due to shadow traffic (packet sizes k s ) We require: Forwarding Overhead Analysis Example: With α = 70%, and 80% real traffic utilization Support up to 75% shadow traffic utilization

31. February 16, 2009Yale University31 Commitment Objectives  Smoothly swap real and shadow across network Eliminate effects of reconvergence due to config changes  Easy to swap back

32. February 16, 2009Yale University32 Commitment Objectives  Smoothly swap real and shadow across network Eliminate effects of reconvergence due to config changes  Easy to swap back Issue  Packet marked with shadow bit 0 = Real, 1 = Shadow  Shadow bit determines which FIB to use  Routers swap FIBs asynchronously  Inconsistent FIBs applied on the path

33. February 16, 2009Yale University33 Commitment Protocol Idea: Use tags to achieve consistency  Temporary identifiers Basic algorithm has 4 phases

34. February 16, 2009Yale University34 Commitment Protocol Idea: Use tags to achieve consistency  Temporary identifiers Basic algorithm has 4 phases  Distribute tags for each config C-old for current real config C-new for current shadow config 0 0 0 0 1 1 0: C-old 1: C-new 1 0 1 0 1 0 0

35. February 16, 2009Yale University35 Commitment Protocol Idea: Use tags to achieve consistency  Temporary identifiers Basic algorithm has 4 phases  Distribute tags for each config C-old for current real config C-new for current shadow config  Routers mark packets with tags Packets forwarded according to tags C-old C-new C-old C-new C-old C-new 1 0 1 0 1 0 0

36. February 16, 2009Yale University36 C-old C-new C-old C-new 0: C-new 1: C-old 1 0 1 0 1 0 1 C-new C-old Commitment Protocol Idea: Use tags to achieve consistency  Temporary identifiers Basic algorithm has 4 phases  Distribute tags for each config C-old for current real config C-new for current shadow config  Routers mark packets with tags Packets forwarded according to tags  Swap configs (tags still valid)

37. February 16, 2009Yale University37 Commitment Protocol Idea: Use tags to achieve consistency  Temporary identifiers Basic algorithm has 4 phases  Distribute tags for each config C-old for current real config C-new for current shadow config  Routers mark packets with tags Packets forwarded according to tags  Swap configs (tags still valid)  Remove tags from packets Resume use of shadow bit 0 0 1 0 1 0 1 0 1

38. February 16, 2009Yale University38 Commitment Protocol Idea: Use tags to achieve consistency  Temporary identifiers Basic algorithm has 4 phases  Distribute tags for each config C-old for current real config C-new for current shadow config  Routers mark packets with tags Packets forwarded according to tags  Swap configs (tags still valid)  Remove tags from packets Resume use of shadow bit 0 0 1 0 1 0 1 0 1

39. February 16, 2009Yale University39 Transient States Definition: State in which some packets use C-old and others use C-new. C-old C-new Transient State

40. February 16, 2009Yale University40 Transient States Definition: State in which some packets use C-old and others use C-new. C-old C-new C-old

41. February 16, 2009Yale University41 Transient States Definition: State in which some packets use C-old and others use C-new. Possible overutilization! Should be short-lived, even with errors C-old C-new C-old

42. February 16, 2009Yale University42 Error Recovery During Swap If ACK missing from at least one router, two cases: (a) Router completed SWAP but ACK not sent (b) Router did not complete SWAP Transient State C-new C-old

43. February 16, 2009Yale University43 Error Recovery During Swap If ACK missing from at least one router, two cases: (a) Router completed SWAP but ACK not sent (b) Router did not complete SWAP Detect (b) and rollback quickly  Querying router directly may be impossible Transient State C-new C-old

44. February 16, 2009Yale University44 Error Recovery During Swap If ACK missing from at least one router, two cases: (a) Router completed SWAP but ACK not sent (b) Router did not complete SWAP Detect (b) and rollback quickly  Querying router directly may be impossible Solution: Ask neighboring routers Transient State Do you see C-old data packets? If YES: Case (b): rollback other routers Otherwise, Case (a): no transient state C-new C-old

45. February 16, 2009Yale University45 Roadmap Motivation and Overview System Basics and Usage System Components  Design and Architecture  Performance Testing  Transaction Support Implementation and Evaluation

46. February 16, 2009Yale University46 Implementation Kernel-level (based on Linux 2.6.22.9)  TCP/IP stack support  FIB management  Commitment hooks  Packet cancellation Tools  Transparent software router support (Quagga + XORP)  Full commitment protocol  Configuration UI (command-line based) Evaluated on Emulab (3Ghz HT CPUs)

47. February 16, 2009Yale University47 Static FIB  300B pkts  No route caching With FIB updates  300B pkts @ 100Mbps  1-100 updates/sec  No route caching Static FIB 300B pkts No route caching

48. February 16, 2009Yale University48 FIB storage overhead for US Tier-1 ISP Evaluation: Memory Overhead

49. February 16, 2009Yale University49 Evaluation: Packet Cancellation Accurate streaming throughput measurement  Abilene topology  Real transit traffic duplicated to shadow  Video streaming traffic in shadow

50. February 16, 2009Yale University50 Evaluation: Packet Cancellation Limited interaction of real and shadow  Intersecting real and shadow flows CAIDA traces  Vary flow utilizations

51. February 16, 2009Yale University51 Evaluation: Packet Cancellation Limited interaction of real and shadow  Intersecting real and shadow flows CAIDA traces  Vary flow utilizations

52. February 16, 2009Yale University52 Evaluation: Commitment Applying OSPF link-weight changes  Abilene topology with 3 external peers Configs translated to Quagga syntax Abilene BGP dumps

53. February 16, 2009Yale University53 Evaluation: Commitment Applying OSPF link-weight changes  Abilene topology with 3 external peers Configs translated to Quagga syntax Abilene BGP dumps Reconvergence in shadow

54. February 16, 2009Yale University54 Evaluation: Router Maintenance Temporarily shutdown router  Abilene topology with 3 external peers Configs translated to Quagga syntax Abilene BGP dumps

55. February 16, 2009Yale University55 Evaluation: Router Maintenance Temporarily shutdown router  Abilene topology with 3 external peers Configs translated to Quagga syntax Abilene BGP dumps C-old C-new 41 ms latency 51 ms latency

56. February 16, 2009Yale University56 Conclusion and Future Work Shadow configurations is new management primitive  Realistic in-network evaluation  Network-wide transactional support for configuration Future work  Evaluate on carrier-grade installations  Automated proactive testing  Automated reactive debugging

57. February 16, 2009Yale University57 Thank you!