CONMan : A Step Towards Network Manageability

1. CONMan: A Step Towards Network Manageability Hitesh Ballani, Paul Francis Cornell University Presented by Lam Chan, Patrick Wong

2. Current Issues • Network management requires detailed knowledge of many different network components • Rising management costs, network downtime. • 80% of IT budgets in various enterprises  maintenance • 62% of network downtime due to configuration errors

3. Why Does It Happen? • “Protocols and devices expose their internal details, leading to a deluge of complexity that burdens the management plane” • Perception differs from reality • Error-prone configuration • Fragmentation of tools • Lack of dependency maintenance

4. Why Does It Happen? • Perception differs from reality • Error-prone configuration • Fragmentation of tools • Lack of dependency maintenance

5. Why Does It Happen? • Perception differs from reality • Error-prone configuration • Fragmentation of tools • Lack of dependency maintenance

6. Why Does It Happen? • Perception differs from reality • Error-prone configuration • Fragmentation of tools • Lack of dependency maintenance

7. Why Does It Happen? • Perception differs from reality • Error-prone configuration • Fragmentation of tools • Lack of dependency maintenance

8. Solution • “The management interface of data-plane protocols should contain as little protocol-specific information as possible.” • Allows data-plane protocols to have a generic yet simple interface

9. Solution - CONMan • Complexity Oblivious Network Management • All protocols and devices express their capabilities and functionalities using generic expressions. • Management plane can understand potential of underlying network from these abstractions. • Configures network in line with high-level policies • In other words, restrict protocol complexity to their implementation.

10. CONMan – Architecture • Protocols should not expose their gory details

11. CONMan – Module Abstraction • Switching packets under performance constraints while filtering unwanted traffic.

12. CONMan – Module Abstraction • Modules may depend on other modules for doing their job.

13. CONMan – Module Abstraction • Abstractions model the capabilities and dependencies of modules • Applies to almost all data plane modules.

14. CONMan – Network Manager • Network Manager (NM): • Determines the network topology • Achieve high-level network configuration goals by creating/deleting pipes and module components

15. CONMan – Network Manager (Primitives) • NMs use primitives to facilitate their management • showPotential – returns a list of modules with their abstractions (determines a device’s capabilities) • showActual – returns a state of modules in a device (pipes, switches, filters) • create/delete – creates or deletes pipes, filter rules, switch rules, and performance enforcement state • conveyMessage – allows modules to convey messages through the NM – this is a ‘module’ command • listFieldsandValues – queries target module for low level fields and values

16. Implementation • GRE Tunneling • Protocol that encapsulates a network protocol in another network protocol

17. GRE Tunneling – Today’s Configuration #!/bin/bash # Inserting the GRE-IP kernel module insmod /lib/modules/2.6.10-1/ip_gre.ko # Creating the GRE module with the appropriate key ip tunnel add name greA mode remote 128.84.223.112 local \ 128.84.222.111 ikey 2001 okey 1001 icsumocsumiseqoseq ifconfiggreA 192.168.1.3 # Enable routing echo 1 > /proc/sys/net/ipv4/ip-forward # Create IP routing state from customer to tunnel echo 202 tun-1-2 > /etc/iproute2/rt_tables ip rule add iff eth0 table tun-1-2 ip route add default dev greA table tun-1-2 # Create IP routing state from tunnel to customer echo 203 tun-2-1 > /etc/iproute2/rt_tables ip rule add iffgreA table tun-2-1 ip route add default dev eth0 table tun-2-1

18. GRE Tunneling – Today’s Configuration #!/bin/bash # Inserting the GRE-IP kernel module insmod /lib/modules/2.6.10-1/ip_gre.ko # Creating the GRE module with the appropriate key ip tunnel add name greA mode remote 128.84.223.112 local \ 128.84.222.111 ikey 2001 okey 1001 icsumocsumiseqoseq ifconfiggreA 192.168.1.3 # Enable routing echo 1 > /proc/sys/net/ipv4/ip-forward # Create IP routing state from customer to tunnel echo 202 tun-1-2 > /etc/iproute2/rt_tables ip rule add iff eth0 table tun-1-2 ip route add default dev greA table tun-1-2 # Create IP routing state from tunnel to customer echo 203 tun-2-1 > /etc/iproute2/rt_tables ip rule add iffgreA table tun-2-1 ip route add default dev eth0 table tun-2-1 End point IP addresses Key Values

19. GRE Tunneling • Human goal • Create a virtual connectivity between the customer-side interface for Customer-1.

20. GRE Tunneling • We translate this as a CONMan goal • CONMan goal • Configure connectivity between the customer-side interfaces <ETH, A, e> and <ETH, B, e>

21. GRE Tunneling – NM Implementation • NM gets CONMan abstractions from all the modules involved < showPotential() > • NM maps a path from (1) to (11) that meets the requirement of the high-level goals

22. GRE Tunneling – NM Implementation • Configuration at Router A create (pipe, e, a) create (pipe, a, d) create (switch-state, a, pipe-2, pipe-3) create (pipe, d, b) create (pipe, b, c) • Protocols incorporate the complexity of determining the low-level parameters.

23. GRE Tunneling – NM Implementation • NM includes a path-finder component that finds all paths between any two modules in such a graph • Depth-first search, cycle avoiding • Choose the path that minimizes the total number of pipes instantiated in the routers • What about other metrics such as security or performance capabilities of modules? • We acknowledge this as an avenue for future work

24. GRE Tunneling – Some things to consider… • Humans need not see or write CONMan scripts • Since there is little protocol-specific information in CONMan scripts… • …an automated NM can generate the commands and other details algorithmically without incorporating protocol-specific knowledge

25. CONMan – Future Considerations • Abstraction • The abstraction provides just enough information for the NM to build a potential path graph • Scalability • NMs can specialize, thus divide and conquer. • Multiple NMs • Many NMs with specialized job that can communicate with each other

26. CONMan – Future Considerations (cont’d) • Specifying high-level goals • A more systematic language to describe the goals • Deployment strategies • Relatively young project • More consideration in the future

27. THANK YOU