Transcript document
CONMAN: A STEP TOWARDS NETWORK MANAGEABILITY Hitesh Ballani, Paul Francis Cornell University Presented by Lam Chan, Patrick Wong 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 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 WHY DOES IT HAPPEN? Perception differs from reality Error-prone configuration Fragmentation of tools Lack of dependency maintenance WHY DOES IT HAPPEN? Perception differs from reality Error-prone configuration Fragmentation of tools Lack of dependency maintenance WHY DOES IT HAPPEN? Perception differs from reality Error-prone configuration Fragmentation of tools Lack of dependency maintenance WHY DOES IT HAPPEN? Perception differs from reality Error-prone configuration Fragmentation of tools Lack of dependency maintenance 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 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. CONMAN – ARCHITECTURE Protocols should not expose their gory details CONMAN – MODULE ABSTRACTION Switching packets under performance constraints while filtering unwanted traffic. CONMAN – MODULE ABSTRACTION Modules may depend on other modules for doing their job. CONMAN – MODULE ABSTRACTION Abstractions model the capabilities and dependencies of modules Applies to almost all data plane modules. CONMAN – NETWORK MANAGER Network Manager (NM): Determines the network topology Achieve high-level network configuration goals by creating/deleting pipes and module components 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 IMPLEMENTATION GRE Tunneling Protocol that encapsulates a network protocol in another network protocol 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 icsum ocsum iseq oseq ifconfig greA 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 iff greA table tun-2-1 ip route add default dev eth0 table tun-2-1 GRE TUNNELING – TODAY’S CONFIGURATION #!/bin/bash # Inserting the GRE-IP kernel module End point IP insmod /lib/modules/2.6.10-1/ip_gre.ko addresses # 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 icsum ocsum iseq oseq ifconfig greA 192.168.1.3 Key Values # 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 iff greA table tun-2-1 ip route add default dev eth0 table tun-2-1 GRE TUNNELING Human goal Create a virtual connectivity between the customerside interface for Customer-1. 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> 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 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. 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 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 CONMAN – FUTURE CONSIDERATIONS Abstraction Scalability The abstraction provides just enough information for the NM to build a potential path graph NMs can specialize, thus divide and conquer. Multiple NMs Many NMs with specialized job that can communicate with each other 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 THANK YOU