1 / 27

CONMan : A Step Towards Network Manageability

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.

ember
Télécharger la présentation

CONMan : A Step Towards Network Manageability

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. 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

More Related